ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL

Взаимоотношения с Процессом Управления Релизами

Многие ИТ-услуги состоят в предоставлении аппаратного обеспечения вместе со сделанным на заказ или готовым программным обеспечением. Процесс Управления Релизами ведет мониторинг соглашений, заключенных в рамках Процесса Управления Уровнем Сервисов, о предоставлении аппаратного и программного обеспечения. Процесс Управления Уровнем Сервиса подготавливает отчеты о качестве ИТ-сервисов на основе информации, получаемой из отчетов Процесса Управле­ния Релизами.

Взаимоотношения с Процессом Управления Непрерывностью ИТ-услуг

Процесс Управления Непрерывностью ИТ-услуг отвечает за быстрое восстановление ИТ-сервисов в случае катастрофы, а также он ведет мониторинг действий и процедур, необходимых для осуществ­ления этого восстановления. Соглашения с заказчиком по данным вопросам заключаются в рамках Процесса Управления Уровнем Сервисов. Предпринимаемые в случае бедствия меры и связанные с ними затраты затем входят составной частью в Соглашение об Уровне Сервиса. Также может быть достигнута договоренность, что в случае чрезвычайных обстоятельств некоторые ИТ-сервисы не бу­дут использоваться или будут временно сокращены.

Изменения в услуге и связанном с ней соглашении SLA могут потребовать модификации уже разра­ботанных мер и процедур по обеспечению непрерывности услуг.

Взаимоотношения с Процессом Управления Безопасностью

Для эффективно действующего Процесса Управления Уровнем Сервиса большое значение могут иметь меры безопасности, связанные с ИТ-сервисом. Как у ИТ-организации, так и у заказчика могут быть определенные требования к безопасности. Соответствующие договоренности определяются в рамках Соглашения об Уровне Сервиса. Управление безопасностью гарантирует, что принимается согласованные меры безопасности, ведется их мониторинг и составляются отчеты для Процесса Уп­равления Уровнем Сервисов.

Взаимоотношения с Процессом Управления Конфигурациями

Процесс Управления Конфигурациями отвечает за ввод детальной информации о компонентах ус­луг (Конфигурационных Единицах) и документации (Соглашений об Уровне Сервиса – SLA) в Конфигурационную Базу Данных (CMDB) и предоставление информации из этой базы. Поэтому создание или модификация услуги или соглашения влечет за собой изменения в CMDB. Служба Service Desk использует Конфигурационную Базу Данных для определения степени воздействия сбоев на услуги и для получения информации из соглашений SLA о времени реагирования и време­ни разрешения сбоев. Информация из CMDB также используется при составлении отчетов о каче­стве Конфигурационных Единиц, что позволяет Процессу Управления Уровнем Сервиса подготав­ливать отчеты о качестве предоставляемых услуг.

Взаимоотношения с Процессом Управления Финансами ИТ

Если ИТ-организация выставляет заказчику счет за предоставленные услуги, то этот вопрос также должен быть отражен в SLA Это могут быть одноразовые платежи или платежи за специальные или дополнительные услуги. Управление финансами предоставляет Процессу Управления Уровнем Сер­виса информацию о затратах на предоставление услуг, а также информацию о методах и уровнях оп­латы, необходимых для покрытия затрат на предоставление услуг.

10.4. Виды деятельности

Ниже дается подробное описание этапов процесса, включая последовательность действий и виды работ.

10.4.1. Идентификация

По мере усиления зависимости бизнеса от ИТ-сервисов возрастает спрос на высококачественные ИТ-услуги. Приемлемость качества услуги определяется ожиданиями заказчика, постоянным упра­влением этими ожиданиями, стабильностью услуги и приемлемостью Уровня Расходов. Поэтому са­мый лучший способ обеспечить соответствующий Уровень Качества – обсуждение этого вопроса с самим заказчиком.

Опыт показывает, что часто заказчики сами не могут четко определить свои ожидания, они просто предполагают, что им будут предоставлены некоторые услуги без каких-либо определенных догово­ренностей. Такое восприятие заказчиком процесса предоставления услуг часто приводит к серьез­ному недопониманию. И это еще раз подтверждает, насколько необходимо Руководителю Процесса Управления Уровнем Сервиса хорошо знать своих заказчиков, чтобы помочь разобраться, какие Ус­луги и на каком Уровне им действительно необходимы и с каким Уровнем Затрат.

Требования заказчиков должны быть представлены в поддающихся измерению значениях, с тем что­бы можно было их использовать при разработке и мониторинге ИТ-услуг. Если метрики не согласо­ваны с заказчиком, то нельзя будет проверить, насколько услуги соответствуют достигнутым дого­воренностям. Процесс Управления Уровнем Сервиса играет ключевую роль в понимании и опреде­лении пожеланий заказчика.

Первым шагом к заключению Соглашения о предоставляемых в настоящий момент или в будущем ИТ-услугах должны стать идентификация и определение потребностей заказчика в виде Требова­ний к Уровню Услуг (Service Level Requirements – SLR). Помимо выполнения этого вида деятель­ности в самом начале данного процесса, рекомендуется делать это регулярно по запросам заказчи­ка или по инициативе самой ИТ-организации и охватывать ею как новые, так и уже существую­щие услуги.

10.4.2. Определение

Определение области (диапазона)[161] и глубины требований заказчика рассматривается как процесс дизайна (разработки) в рамках Процесса Управления Уровнем Сервисов. Согласно модели обеспе­чения качества стандарта ISO 9001 общий процесс дизайна состоит из следующих этапов: собствен­но дизайн, разработка, инсталляция и сопровождение. Для того чтобы результаты выполнения про­цесса дизайна отвечали требованиям заказчика, им необходимо управлять. На протяжении всего процесса дизайна термин "внешний" используется в отношении взаимоотношений с заказчиком, а "внутренний" – с технической поддержкой внутри ИТ-организации. Процесс дизайна включает в себя шаги, начиная с детализации требований заказчика и определения их в качестве стандартов и заканчивая разработкой технических условий для предоставления услуг.

Определение внешних стандартов

Первым этапом в составлении количественного описания[162] новых или существующих ИТ-услуг яв­ляется определение или "переопределение" ожиданий заказчика в отношении услуг в целом. Ожи­дания заказчика формализуются в Требованиях к Уровню Услуг (SLR), в разработке которых участ­вует вся организация заказчика. Обычно этот этап считается самой трудной частью Процесса Управ­ления Уровнем Сервисов. Перед началом данного этапа Руководитель Процесса должен подгото­виться к встрече с представителями заказчика. Первым вопросом, который следует задать, является: "Какой ИТ-сервис требуется и из каких элементов он должен состоять?" Предоставление сервиса может повлечь за собой использование определенной части инфраструктуры, например, такой как глобальная сеть (Wide Area Network – WAN). Этот сервис может быть частью составной/сложной услуги[163], такой как доступ ко всей информационной системе, включая всю инфраструктуру (WAN, LAN, рабочие станции, приложения и т. д.).

Участвующие в этих встречах пользователи должны быть поделены на группы. Руководитель Про­цесса Управления Уровнем Сервиса составляет список групп пользователей, их требований и полно­мочий. Следующая информация необходима для определения Требований к Уровню Услуг:

? описание функций, которые должен предоставить запрашиваемый сервис, с точки зрения заказ­чика;

? время и дни, в которые сервис должен быть доступен;

? требования к непрерывности сервиса;

? ИТ-функции, необходимые для предоставления сервиса;

? ссылки на текущие операционные методы и стандарты качества, которые должны учитываться при определении сервиса;

? ссылки на Соглашение об Уровне Сервиса, которое должно быть модифицировано или заменено там, где это необходимо.

Результатом этапа дизайна является документ, содержащий Требования к Уровню Услуг (Service Level Requirements – SLR) и подписанный Руководителем Процесса и заказчиком. Эти требования еще можно менять, пока соответствующее подразделение работает над разработкой услуги, внедрением и ведет соответствующие закупки. Изменения могут касаться, например, целесообразности предполагае­мых функций и ожидаемых затрат. Каждое такое изменение должно утверждаться обеими сторонами.

Преобразование во внутренние стандарты

На этапе составления спецификаций Требования к Уровню Услуг конкретизируются. Результатом работы на этом этапе будет получение следующей информации:

? однозначное и подробное описание ИТ-услуг и необходимых компонентов;

? спецификация метода внедрения и предоставления сервисов;

? спецификация процедуры контроля требуемого Уровня Качества.

Рис. 10.2. Этап составления спецификаций (источник: OGC)

На этапе составления спецификации рекомендуется разграничивать внешние и внутренние доку­менты (рис. 10.2). Спецификации для внешнего использования уточняют согласованные с заказчи­ком цели, и контроль процесса дизайна осуществляется с учетом этих целей. Такие спецификации составляются совместно с организацией заказчика, и они служат входной информацией для внут­ренних спецификаций.

Внутренние спецификации согласуются с внутренними целями ИТ-организации, достижение кото­рых означает удовлетворение потребностей заказчика. Разграничение между внутренними и внеш­ними спецификациями может оказаться особенно полезным уже после того, как Процесс Управле­ния Уровнем Сервиса запущен в работу. При таком подходе ИТ-организация не будет беспокоить заказчика различными техническими вопросами. Начиная с этого момента, Управление Уровнем Сервиса означает стремление поддерживать соответствие внутренних спецификаций внешним. Это­му содействуют выполнение таких действий, как Контроль документов и Внутренний анализ (ревью), в ходе которых ведется регистрация относящихся к данному вопросу документов, управление версиями и организуются регулярные аудиторские проверки.

Таблицы спецификаций[164] дают подробное описание того, что хочет заказчик (внешний элемент), и того, как пожелания заказчика отразятся на работе ИТ-организации (внутренний элемент). Табли­цы не обязательно должны подписываться двумя сторонами, но все равно они попадают в сферу де­ятельности по Контролю документов. Каталог услуг может составляться на основе спецификаций сервисов, поэтому любые изменения в Уровнях Услуг должны быть немедленно отражены в Таблице спецификаций и в Каталоге услуг. Вслед за этим пересматривается Соглашение об Уровне Сервиса в соответствии с измененными спецификациями.

План обеспечения качества услуг (Service Quality Plan – SQP)

Рекомендуется включать всю управленческую информацию (Ключевые показатели эффективности) и внутренние и внешние спецификации в единый документ для получения полной информации о вкладе каждого процесса Сервис-менеджмента в ИТ-услуги.

10.4.3. Договор

После завершения этапа составления спецификаций, ИТ-организация трансформирует бизнес-по­требности в ИТ-ресурсы и Конфигурационные Элементы. Далее эта информация будет использова­на для составления или модификации следующих документов.

Соглашение об Уровне Сервиса

При разработке структуры данного документа вначале рекомендуется определить общие аспекты, такие как сетевые услуги для всей компании, и разработать общую сервисную модель соглашений до начала переговоров с заказчиком. Соглашение может иметь иерархическую структуру, анало­гичную структуре организации заказчика, и может быть представлено в виде рамочного соглаше­ния с определенным количеством иерархических уровней. У каждого Уровня может быть своя сте­пень детализации. Верхние Уровни отражают договоренности по общим услугам, предоставляе­мым всей организации. На Нижних Уровнях содержится информация, имеющая отношение к кон­кретным заказчикам.

Структура Соглашения об Уровне Услуг зависит от ряда переменных, таких как:

? Физические аспекты организации:

? размер организации;

? сложность;

? географическое распределение.

? Аспекты культуры:

? язык, на котором составляются документы (для международных организаций);

? взаимоотношения между ИТ-организацией и заказчиком;

? политика выставления счетов[165];

? однородность бизнес-деятельности;

? тип организации: коммерческая или некоммерческая.

? Характер бизнес-деятельности:

? общие положения и условия;

? часы работы – 5x8 часов или 7x24 часа

Внешние Договоры и Операционные Соглашения об Уровне Услуг

Все имеющиеся Внешние Договоры (UC) и Операционные Соглашения об Уровне Услуг (OLA) должны быть пересмотрены на этапе дизайна. Участвующие в этой работе должны иметь информа­цию обо всех соглашениях OLA и договорах UC, которые относятся к предоставлению конкретной услуги. Ссылки в результате деятельности по Контролю документов могут помочь в уточнении свя­зей с таблицами спецификаций.

Каталог услуг

При составлении Каталога услуг могут быть полезны следующие рекомендации:

? используйте язык заказчика. Избегайте технического жаргона и используйте терминологию из со­ответствующей области бизнеса;

? постарайтесь взглянуть на проблему с точки зрения заказчика и придерживайтесь такого подхода при сборе нужной информации;

? создайте привлекательный макет каталога, так как ИТ-организация использует этот документ для своей презентации заказчикам;

? постарайтесь сделать этот документ доступным для наибольшего количества потенциальных за­интересованных лиц, например, путем опубликования его на сайте сети Интранет или на CD-ROM.

10.4.4. Мониторинг

Мониторинг Процесса Управления Уровнем Сервиса можно проводить, только если Уровни Услуг заранее четко определены и соответствуют внешним целям. Также должна существовать возмож­ность измерения Уровня Услуг с точки зрения заказчика. Мониторинг не должен ограничиваться техническими аспектами процесса, он также должен затрагивать процедурные вопросы. Например, до тех пор, пока пользователь не будет проинформирован о восстановлении сервиса, он будет счи­тать его недоступным.

Процессы Управления доступностью и мощностями обычно предоставляют информацию о достиже­нии технических целей, связанных с Уровнями Услуг. В некоторых случаях информация также по­ступает из Процессов Поддержки услуг, особенно от Процесса Управления Инцидентами. Однако недостаточно замерять только внутренние параметры, так как это не даст представления о воспри­ятии услуг заказчиком. Поэтому необходимо замерять/оценивать и такие параметры, как время реа­гирования, время эскалации и время, затраченное на поддержку. Полное представление о процессе можно получить только путем объединения информации, получаемой как от систем, так и от Сер­вис-менеджмента.

10.4.5. Создание отчетов

Отчеты заказчику (отчеты о сервисах) должны предоставляться в сроки, оговоренные в Соглашении SLA В этих отчетах сравниваются фактически предоставляемые Уровни Сервисов с согласованны­ми Уровнями. Примерами отчетов могут быть:

? доступность сервисов и время простоя в указанные периоды;

? среднее время реагирования в пиковые периоды;

? скорость транзакций в пиковые периоды;

? количество функциональных ошибок в ИТ-сервисе;

? частота и длительность периода деградации сервисов (Услуги не достигают согласованного Уровня);

? среднее количество пользователей в пиковые периоды;

? количество успешных и безуспешных попыток нарушить систему безопасности;

? количественное соотношение использованных мощностей[166] сервисов;

? количество завершенных и незавершенных (открытых) изменений;

? стоимость предоставленных услуг.

10.4.6. Анализ (ревью)

Уровень Сервисов нужно регулярно анализировать, уделяя при этом внимание следующим аспектам:

? Соглашению об Уровне Услуг с момента последнего анализа;

? проблемам, возникшим с услугами;

? выявлению тенденций работы услуг;

? изменению услуг в пределах Согласованных Уровней Сервиса;

? изменению процедур и расчетов стоимости дополнительных ресурсов;

? последствию сбоев при предоставлении Согласованных Уровней Услуг.

Если не удалось организовать предоставление ИТ-услуг на Согласованном Уровне, следует согласо­вать действия по исправлению ситуации, например:

? разработать Программу улучшения услуг (Service Improvement Program – SIP);

? выделить дополнительный персонал и ресурсы;

? изменить Уровни Сервисов, определенные в Соглашении SLA;

? модифицировать процедуры;

? модифицировать Соглашения OLA и Внешние Договоры UC.

Во многих организациях, в которых вводится Процесс Управления Уровнем Сервисов, ведутся обсу­ждения, требуется ли определение санкций в связи с несоблюдением договоренностей. Это трудный вопрос, поскольку Процесс Управления Уровнем Сервиса базируется на взаимодействии ИТ-под­разделения с пользователями ИТ-услуг, часто в рамках одной организации. В такой ситуации, когда и ИТ-подразделение, и пользователи работают над достижением одних и тех же корпоративных це­лей, маловероятно, чтобы применение санкций и тем более денежных штрафов отвечало бы корпо­ративным интересам. Было бы намного разумнее, исходя из общих интересов, договориться о совме­стных мерах по предотвращению сбоев в предоставлении Согласованных Уровней Услуг. Тем не ме­нее, возможно применение санкций в отношении внешнего поставщика. В этом случае, скорее всего, нужно заключать юридически обязывающий договор (Внешний Договор), а не Соглашение об Уров­не Сервиса.

10.5. Контроль процесса

Для оптимизации процесса и его контроля следует определить ряд критических факторов успеха, а также показателей качества для оценки и улучшения процесса.

10.5.1. Критические факторы успеха и ключевые показатели эффективности

Успех Процесса Управления Уровнем Сервиса зависит от следующих факторов:

? наличия Руководителя Процесса, обладающего знаниями как в области информационных техно­логий, так и в области бизнеса;

? четкости в формулировании целей процесса и роли процесса;

? проведения оповещения, в ходе которого люди получат информацию о процессе, будет достигнуто его понимание и поддержка с их стороны;

? четкости поставленных задач, полномочий и ответственностей в рамках процесса, разграничения контроля процесса и операционных задач (контактов с заказчиками).

Приведенные ниже показатели качества можно использовать для определения эффективности и ре­зультативности[167] Процесса Управления Уровнем Сервисов:

? параметры сервисов, включенные в Соглашения SLA;

? параметры Соглашения SLA, поддерживаемые Операционным Соглашением об Уровне Услуг (OLA) и Внешними Договорами (UC);

? параметры Соглашений SLA, за которыми ведется мониторинг, и о недостатках которых составля­ются отчеты;

? параметры Соглашений об Уровне Сервиса, которые регулярно анализируются;

? параметры Соглашений об Уровне Сервиса, для которых удалось достичь согласованных уровней сервиса;

? выявленные недостатки, включенные в план улучшений;

? действия, предпринятые по исправлению указанных недостатков;

? выявленные тенденции с учетом реального Уровня Сервиса.

10.5.2. Отчеты руководству[168]

Отчеты руководству в отличие от Отчетов об Уровне Сервисов предназначены не для заказчика, они нужны для целей контроля или Управления Процессом. В них могут входить метрики о реально су­ществующих Уровнях Сервисов и сведения о тенденциях, например:

? количество заключенных Соглашений SLA;

? количество случаев несоблюдения заключенных соглашений SLA;

? стоимость оценки и мониторинга Соглашений SLA;

? степень удовлетворенности заказчиков, определяемая по результатам опросов;

? статистические данные об инцидентах, проблемах и изменениях;

? результаты предпринимаемых действий по улучшению сервисов.

10.5.3. Функции и роли

Роли

Контроль за Процессом Управления Уровнем Сервиса осуществляет Руководитель Процесса. Он должен обеспечить эффективность процесса и достижение заданных результатов. Это не обязатель­но означает, что роль Руководителя Процесса обязательно исполняет один человек. Во многих организациях есть несколько Руководителей Процесса Управления Уровнем сервисов, каждый из кото­рых отвечает за одну или несколько услуг или групп заказчиков.

Ответственность

Руководитель Процесса Управления Уровнем Сервиса отвечает за:

? создание и обновление Каталога Услуг;

? создание и поддержание эффективного Процесса Управления Уровнем Сервисов, включая:

? определение структуры Соглашения об Уровне Сервиса;

? заключение Операционных Соглашений об Уровне Услуг с Внутренними Поставщиками;

? заключение Внешних Договоров с Поставщиками;

? обновление существующей Программы улучшения услуг;

? ведение переговоров с заказчиками, заключение и поддержка Соглашений об Уровне Сервиса, Операционных Соглашений об Уровне Услуг и Внешних Договоров;

? анализ качества работы ИТ-организации и улучшение качества по мере необходимости.

10.6. Проблемы и затраты

10.6.1. Проблемы

В процессе работы могут возникнуть следующие проблемы:

? В результате внедрения Процесса Управления Уровнем Сервиса установились деловые отношения с заказчиком, что требует привлечения всего ИТ-персонала к работе по заключенным соглашени­ям. В этой ситуации, возможно, потребуется изменение корпоративной культуры в компании.

? Заказчикам может потребоваться помощь в составлении Требований к Уровню Сервисов.

? Может оказаться очень трудным представить ожидания заказчиков в виде поддающихся оценке стандартов и конкретных цифр расходов.

? Руководитель Процесса должен быть умеренным и реалистичным в своих обещаниях при обсу­ждении соглашений, пока не будут разработаны инструментарии, процедуры, План обеспечения качества услуг (SQP) и Внешние Договоры. Лучше придерживаться стратегии постепенных улучшений.

? Легко ошибиться в расчетах накладных расходов, связанных с мониторингом и оценкой Уровней Сервисов. В больших организациях может потребоваться отдельный персонал на выполнение этих видов работ.

? На практике многие ИТ-организации приступают к составлению проекта Соглашения об Уровне Сервиса, пропуская этап анализа требований заказчика, этап дизайна и разработки Плана обеспе­чения качества сервисов (SQP). Это может привести к возникновению процесса, которым трудно управлять и у которого нет четких, поддающихся оценке стандартов.

? Документы, появляющиеся в рамках Процесса Управления Уровнем Сервиса и сам процесс могут стать самоцелью вместо достижения цели процесса – стать средством установления хороших от­ношений между заказчиком и поставщиком ИТ-сервисов.

10.6.2. Затраты

Расходы, связанные с внедрением Процесса Управления Уровнем Сервисов, можно разделить на следующие категории:

? расходы на персонал (Руководитель Процесса и команда проекта);

? расходы на обучение;

? расходы на документацию;

? расходы на помещение, аппаратное и программное обеспечение;

? расходы на операционные виды деятельности, связанные с обновлением Плана Обеспечения Каче­ства Сервисов (SQP), Соглашений об Уровне Сервиса и Каталога Услуг.

Глава 11 Управление Финансами ИТ

11.1. Введение

Для большинства людей ИТ-услуги являются необходимой поддержкой повседневной деятельно­сти, но мало кто понимает, что эти услуги стоят денег. По мере роста числа пользователей растет и бюджет ИТ. С увеличением бюджета заказчиков все больше начинают беспокоить расходы на ИТ, и становится все труднее без посторонней помощи соотнести эти расходы со своей деятельностью. При оплате счета за ИТ-услуги заказчику бывает трудно самому без посторонней помощи опреде­лить, насколько реальные затраты окупаются полученными бизнес-преимуществами.

Библиотека ITIL создавалась с целью содействовать структурированию Управления ИТ-инфрастру­ктурой, что способствовало бы эффективному и экономичному использованию ИТ-ресурсов. При этом одной из задач было обеспечить переход от организаций, ориентированных в своей деятельно­сти на фиксированный бюджет, к организациям коммерческого типа, которые имеют четкое пред­ставление о всех своих затратах.

Качество и затраты

Предоставление ИТ-услуг пользователям по разумной цене определяется тремя факторами:

? Качество – в плане операционной деятельности[169]:

? мощность (пропускная способность);

? доступность;

? производительность;

? восстановление после чрезвычайных обстоятельств;

? поддержка.

? Стоимость – в плане:

? расходов;

? инвестиций.

? Требования заказчика – стоимость и качество должны соответствовать потребностям бизнес-пользователя.

Первые два фактора часто находятся в противоречии друг с другом, так как повышение качества обычно означает увеличение затрат, а уменьшение затрат означает снижение качества. Однако эти два фактора могут быть сбалансированы за счет четкой ориентации на потребности заказчика. Осведомленность о затратах, связанных с предоставлением ИТ-услуг, и использование реалистич­ной системы выставления счетов ставит предоставление услуг на прочную основу. Это позволяет за­казчикам быть в курсе стоимости ИТ-услуг, они будут знать, что с них запрашивают разумную цену, и, как следствие, они будут разумнее использовать ИТ-ресурсы.

11.1.1. Основные понятия

Составление бюджета

Составление бюджета включает в себя прогнозирование затрат и контроль расходов. Часто этот про­цесс начинается с планирования потребностей заказчика в услугах и связанных с этим затрат. Прог­ноз может составляться на основе анализа накопленных статистических данных с возможными по­правками на текущие тенденции в бизнесе и с учетом персональных знаний специалиста, составляю­щего бюджет. Если статистические данные по конкретной услуге отсутствуют, то в качестве модели можно использовать аналогичные сервисы.

Бухгалтерский учет

Бухгалтерский учет – это мониторинг расходования финансовых средств ИТ-организацией. Здесь особенно важным является определение затрат по каждому заказчику, по каждому виду услуг, дея­тельности и т. д. В данном случае понимание вопроса в целом более важно, чем возможность рассчи­тать стоимость до копейки.

Выставление счетов

К выставлению счетов относятся все виды деятельности, связанные с подготовкой счетов заказчи­кам за предоставленные услуги. Данный процесс предполагает определение цели (целей) выставле­ния счетов, а также алгоритма (алгоритмов) расчета стоимости[170]. Для этого необходима эффективная система бухгалтерского учета, удовлетворяющая потребностям в детальной информации на различ­ных уровнях: анализа, расчета и отчетности.

Категории затрат

Эффективный контроль уровня затрат требует понимания их природы. Существует несколько спо­собов классификации затрат. Для каждого продукта или сервиса можно определить затраты, прямо или косвенно связанные с ним:

Прямые затраты[171]: затраты, связанные конкретно и исключительно с какой-либо ИТ-услугой. На­пример, виды деятельности и материалы, прямо и однозначно связанные с определенным серви­сом (аренда телефонной линии для доступа к сети Интернет).

Косвенные затраты[172]: затраты, не связанные прямо и однозначно с какой-либо ИТ-услугой. При­мерами могут быть затраты на помещения, услуги по поддержке (например, Управление Сетью) и административные расходы (включая затраченное время).

Одним из способов включения косвенных затрат в счет является их пропорциональное распределе­ние между услугами или заказчиками.

Другим способом является расчет затрат на основе деятельности (Activity Based Costing – ABC). Этот метод заключается в учете всех накладных расходов организации с последующим распределе­нием затрат на выполнение работ по продуктам и услугам, с которыми эти затраты связаны. В сущности, затраты распределяются по более сложному критерию, чем простое распределение прямых затрат. Метод ABC может быть полезен в тех случаях, когда большинство затрат не зависит напрямую от объема услуг. Вместо усредненного распределения косвенных затрат метод ABC пред­лагает распределять их на основе выполненной деятельности, связанной с конкретным продуктом и услугой.

Еще одним способом учета затрат является их разделение на постоянные и переменные.

Постоянные затраты[173] не зависят от объема предоставляемых услуг, к ним относятся инвестиции в аппаратное обеспечение, программное обеспечение и строительство. В большинстве случаев учи­тывается не закупочная цена, а ежемесячная или ежегодная сумма амортизационных отчислений и начисляемые проценты. Постоянные затраты присутствуют даже при снижении объема производ­ства (предоставления услуг) или их прерывании.

Переменные затраты[174] - это затраты, уровень которых меняется с изменением объема производст­ва. Примерами могут быть затраты на привлекаемый со стороны персонал, картриджи для принте­ров, бумагу, отопление и электричество. Эти затраты связаны с предоставляемыми услугами; с увеличением объема производства возрастают также и затраты.

Существует определенное различие между капитальными и операционными затратами.

? Капитальные затраты[175] связаны с закупкой активов, предназначенных для долгосрочного исполь­зования внутри организации. Амортизация этих затрат производится в течение несколько лет. Поэтому в затраты обычно включаются амортизационные отчисления, а не закупочная стоимость.

? Операционные затраты[176] представляют собой ежедневные затраты, не связанные с материальными производственными ресурсами. Примерами являются договоры на обслуживание аппаратного и программного обеспечения, стоимость лицензий, страховые взносы и т. д.

Типы затрат (виды затрат)

После определения структуры калькуляции затрат (например, по подразделениям, услугам или за­казчикам), может быть определена система типов затрат для разнесения затрат по счетам. Число ти­пов будет зависеть от размера организации. Типы затрат должны иметь четкое и понятное описание и структуру, чтобы не возникало трудностей при их распределении.

Типы затрат могут также подразделяться на элементы затрат. Методы распределения затрат по ним могут быть определены на более позднем этапе. Существует шесть основных видов затрат, относя­щихся или к прямым, или к косвенным затратам.

Рис. 11.1. Типы затрат и их составляющие (источник: OGC)

Примерами этих видов затрат могут быть:

? Затраты на оборудование (Equipment Cost Unit – ECU) – все затраты на аппаратное обеспече­ние, например:

? серверы;

? устройства хранения информации;

? связь и сети;

? принтеры.

? Затраты на программное обеспечение (Software Cost Unit – SCU) – прямые и косвенные затраты на поддержку функционирование системы, включая:

? системное программное обеспечение;

? транзакционную систему;

? систему Управления Базами Данных;

? систему разработки приложений;

? программные приложения.

? Организационные затраты (Organization Cost Unit – OCU) – прямые и косвенные затраты на персонал, которые могут быть постоянными или переменными, например:

? заработная плата;

? расходы на обучение;

? командировочные расходы.

? Затраты на размещение (Accommodation Cost Unit – ACU) – все прямые и косвенные затраты, связанные с размещением, например:

? серверные комнаты;

? офисы;

? другие помещения и оборудование, такие как испытательные лаборатории, учебные помещения, кондиционеры и т. д.

? Трансферные затраты (Transfer Cost Unit – TCU) – затраты, связанные с товарами и услугами, предоставляемыми другими подразделениями, т. е. внутренние расчеты между подразделениями организации.

? Учет затрат (Cost Accounting – СА) – затраты, связанные с деятельностью самого Процесса Уп­равления Финансами.

11.2. Цели процесса

Целью Процесса Управления Финансами является содействие ИТ-организации в эффективном Уп­равлении ИТ-ресурсами, необходимыми для предоставления услуг. Для этого в рамках процесса вы­полняется разбиение общих затрат на составляющие части и их распределение по предоставляемым ИТ-услугам. Таким образом, процесс обеспечивает поддержку принятия решений по вопросам инве­стиций и способствует разумному пользованию ИТ-средств с учетом их стоимости.

Для выставления счетов может быть выбран метод, нацеленный на полное возмещение затрат, на возмещение с учетом дополнительного финансирования (предусмотренного в бюджете), или на воз­мещение с целью получения определенной прибыли.

Преимущества использования процесса

При внедрении ИТ-организацией процесса Управления Финансами она получит возможность:

? определять затраты на ИТ-услуги;

? определять и классифицировать структуру затрат;

? правильно распределять затраты по ИТ-услугам, предоставляемым внутренним и внешним заказ­чикам;

? использовать различные методы выставления счетов за пользование ИТ-услугами, где это целесо­образно;

? управлять ИТ-отделом как бизнес-подразделением, где это требуется;

? возмещать все расходы, включая капитальные затраты (инвестиции, амортизационные отчисле­ния и банковские проценты) за счет заказчика;

? регулярно проверять счета на предмет их реалистичности и приемлемости для заказчика;

? формировать поведение заказчиков и пользователей путем уведомления их о затратах и привязы­вания затрат непосредственно к услугам.

Так как преимущества различны по своей природе, то делается разграничение между работами по Составлению бюджета[177], Ведению бухгалтерского учета[178] (который участвует в Расчете затрат[179]) и Вы­ставлением счетов[180].

Главное достоинство деятельности по Составлению бюджета и Ведению бухгалтерского учета со­стоит в том, что это дает руководству более полную информацию о затратах на предоставление ИТ-услуг. Такая информация позволяет сбалансировать затраты и качество и обеспечить заказчикам финансово-обоснованный ИТ-сервис.

Бюджетирование и ведение бухгалтерского учета позволяет руководителю ИТ-сервисов:

? принимать решения по каждой услуге на основе экономической эффективности;

? использовать коммерческий подход к принятию решений по ИТ-услугам и инвестициям в них;

? предоставлять больше информации для обоснования расходов, например, показывая возможные издержки в случае отказа от стратегических затрат;

? составлять бюджеты и планы на основе надежной информации.

Основным достоинством системы Выставления счетов является содействие развитию деловых от­ношений с заказчиком. Оплачивающий услуги заказчик имеет соответствующие права и может вы­двигать требования, но он будет использовать ресурсы более экономно, если будет понимать связь между выдвигаемыми им требованиями и получаемым счетом за услуги.

Выставление счетов позволяет ИТ-руководству:

? анализировать ИТ-услуги с коммерческой точки зрения и планировать инвестиции на основе принципа возмещения затрат;

? возмещать затраты на ИТ, увязывая их с получаемой от услуг пользой;

? влиять на поведение заказчика, например, назначая более высокие тарифы в периоды максималь­ной загрузки или просто предоставляя руководству информацию о стоимости и использовании услуг для принятия мер.

Использование системы Выставления счетов должно способствовать формированию поведения за­казчика, а не создавать ситуацию, при которой заказчик за плату получает все, что хочет. Вряд ли возможно удовлетворить индивидуальные требования всех пользователей по индивидуальным рас­ценкам, даже если они готовы платить. Система выставления счетов создает коммерческую среду для переговоров. В этом случае заказчики будут лучше осведомлены о затратах, связанных с исполь­зованием ИТ-средств.

11.3. Процесс

В последние годы роль информационных технологий значительно возросла. Поэтому ИТ-организа­ции столкнулись с возросшими требованиями к качеству и экономической эффективности ИТ-ус­луг. Развитие Интернета привело к тому, что ИТ-организации все чаще приходится иметь дело с внешними, по отношению к компании заказчиками и пользователями. Например, книжные магази­ны размещают свои каталоги в Интернете и обслуживают заказчиков по всему миру. Это приводит к расширению масштаба организации и необходимости получать более точную информацию о затра­тах. Для обеспечения рентабельности ИТ-сервиса необходимо также наличие соглашения о предос­тавлении услуг и определение разумных цен. ИТ-организации в своей деятельности должны приме­нять бизнес-ориентированный стиль работы, и внедрение эффективной системы контроля затрат является частью такого подхода. Эффективная система контроля затрат должна отвечать следующим требованиям:

? поддерживать разработку инвестиционной стратегии, способствующей гибкости предприятия за счет использования современных технологических средств;

? помогать в определении приоритетов в использовании ресурсов;

? обеспечивать покрытие затрат на все используемые организацией ИТ-ресурсы, включая обновле­ние информации;

? помогать руководству в принятии ежедневных оперативных решений, что позволит уменьшить финансовый риск при принятии долгосрочных решений;

? быть гибкой и способной быстро реагировать на изменения в бизнесе.

Процесс Управления Финансами оказывает поддержку бизнесу в планировании и достижении по­ставленных целей. Для получения наиболее оптимального результата от использования данного процесса он должен применяться постоянно в масштабе всей компании, с минимумом конфликтных ситуаций. В ИТ-организации процесс Управления Финансами реализуется через три основных про­цесса: Составление бюджета (Budgeting), Бухгалтерский учет (Accounting) и Выставление счетов (Charging). Этот цикл показан на рис. 11.2.

Рис. 11.2. Финансовый цикл (источник: OGC)

Процесс Управления Финансами ИТ-услуг взаимодействует почти со всеми другими процессами ИТ Сервис-менеджмента, но в особенности с приведенными ниже.

Взаимоотношения с бизнес-процессами

Управления Уровнем Сервиса имеет большое значение для определения концепции, стратегии и планирования в соответствии с бизнес-процессами (рис 11.3).

Рис. 11.3. Взаимоотношения с бизнес-процессами

Хотя эти виды деятельности находится вне сферы действия Процесса Управления Финансами, они важны для него. Это объясняется тем, что бизнес имеет концепцию действий на будущее, которая учитывается при определении реальных задач как для всех бизнес-подразделений, так и для самой ИТ-организации.

Следовательно, стратегия ИТ должна основываться на задачах бизнеса. По мере того, как ИТ-орга­низация будет все больше узнавать о целях и задачах бизнеса, будет появляться больше возможно­стей для эффективного использования новых информационных технологий. Затраты на внедрение и эксплуатацию ИТ-решений должны оцениваться по тому, насколько ИТ-технологии способствуют достижению бизнес-преимуществ в терминах снижения операционных затрат и увеличения оборота.

Взаимоотношение с Процессом Управления Уровнем Сервиса

Соглашение об Уровне Сервиса (SLA) определяет ожидания заказчика и соответствующие обяза­тельства ИТ-организации. Вид и объем услуг во многом определяются финансовыми ресурсами, вы­деляемыми для предоставления этих услуг. Руководитель Процесса Управления Финансами ИТ-ор­ганизации участвует в обсуждении с руководителем Процесса Управления Уровнем Сервиса таких вопросов, как затраты на удовлетворение текущих и будущих требований бизнеса, политика компа­нии в области выставления счетов и ее влияние на заказчика и его поведение. Чем больше различных уровней услуг для различных заказчиков предусматривается в Соглашении SLA, тем большее значение для ИТ-сервиса приобретает процесс выставления счетов и тем весомее будут получаемые преимущества. Но это также ведет к увеличению накладных расходов, связанных с составлением бюджета, ведением бухгалтерского учета и процедурой выставления счетов.

Взаимоотношения с Процессом Управления Мощностями

Мощности ИТ сервисов и уровень их доступности зависят от выделяемых финансовых ресурсов. Мо­жет возникнуть необходимость обсудить дополнительные затраты на предоставление улучшенных мощностей и повышенной доступности с заказчиком ИТ-услуг или со всей компанией в целом. Инфор­мация о соотношении между стоимостью услуг и бизнес-отдачей может повлиять на принятие решения о целесообразности приобретения дополнительных мощностей или увеличение уровня доступности.

Взаимоотношения с Процессом Управления Конфигурациями

Процесс Управления Конфигурациями определяет, идентифицирует и регистрирует все изменения во всех компонентах инфраструктуры. Использование информации, включая данные о затратах из конфигурационной базы данных CMDB, облегчает сбор статистической информации о стоимости услуг. Процесс Управления Конфигурациями может также участвовать в сверке данных об активах с информацией из финансовых систем.

11.4. Виды деятельности

11.4.1. Составление бюджета

Задачей подпроцесса Составления бюджета является планирование деятельности организации и ее контроль. В то время как корпоративное и стратегическое планирование учитывает долгосрочные бизнес-задачи, бюджетирование определяет финансовые планы для поставленных задач на задан­ный бюджетный срок. Обычно такой период составляет от одного года до пяти лет[181].

Методы составления бюджета

В зависимости от финансовой политики бизнеса выбирается один из следующих методов:

? Инкрементное (приростное) составление бюджета – в качестве основы для нового бюджета ис­пользуются цифры за прошлый год. Они корректируются в соответствии с ожидаемыми измене­ниями в деятельности организации, затратах и ценах.

? Составление бюджета "с нуля" – работа над бюджетом начинается с чистого листа бумаги "с ну­ля". Опыт прошлых лет не принимается в расчет. Это заставляет руководителей определять все потребности в ресурсах с учетом затрат, заложенных в их бюджеты. Это означает, что каждая ста­тья расходов должна быть проанализирована и принято решение о их целесообразности и величи­не. Очевидно, что этот метод более трудоемкий, поэтому обычно он используется раз в несколько лет. В промежутках используется метод инкрементного составления бюджета.

Составление бюджета

Составление бюджета начинается с определения ключевых факторов, сдерживающих рост компа­нии. Во многих случаях это объем продаж; однако, этими факторами могут также быть недостаток складского пространства, материалов и т. д. Часто бюджет определяют финансовые ограничения. Процесс составления включает в себя определение следующих вторичных бюджетов (мы опускаем процедуры согласования и утверждения, существующие в каждой компании):

? Бюджет отдела продаж и маркетинга – если бюджет определяется объемом продаж, то большая часть работы ложится на отдел маркетинга. Для составления хорошего бюджета крайне необходи­мы точная оценка и анализ заказчиков, рынков, регионов сбыта, продуктов и т. д.

? Производственный бюджет – включает подробную информацию о предоставляемых услугах: ко­личество, время поставки, необходимые затраты рабочей силы и материалов и т. д.

? Административные бюджеты – исходя из планируемых услуг необходимо определить бюджет на накладные расходы для соответствующих отделов, например, производственного отдела, отделов продаж и распространения, исследований и разработок и т. д.

? Бюджет на затраты и инвестиции – этот бюджет складывается из затрат, заложенных в вышеука­занные бюджеты. Бюджет инвестиций определяет расходы, связанные с заменой и приобретением средств производства. В нем могут также учитываться инвестиционные проекты, начатые в про­шлом году.

Бюджетный период

Лучшим выбором для бюджетного периода является финансовый год. Для проведения регулярного сопоставления фактических и запланированных в бюджете цифр бюджетный период делится на ме­сяцы или другие равные промежутки времени, например, четырехнедельные периоды.

В некоторых видах бизнеса составляется не только подробный годовой бюджет, но и делается общий прогноз на три года или пять лет. Такой прогноз дает высшему руководству информацию о перспек­тивах на более длительный период.

11.4.2. Бухгалтерский учет

Для того чтобы иметь возможность руководить ИТ-организацией как бизнес структурой, необходи­мо определять и понимать все затраты, связанные с использованием ИТ. Затраты должны быть оп­ределены, даже если соответствующий счет не выставляется заказчику Контроль затрат возможен только при их четком понимании. Здесь не столько важно определить второстепенные затраты, сколько определить способы структурирования затрат. Это даст лучшее понимание путей расходо­вания денег.

Одной из главных операций бухгалтерского учета является определение элементов затрат. Такая структура затрат определяется на один год, после чего она может быть пересмотрена. В большинстве случаев метод учета затрат выбирается в момент согласования структуры элементов затрат с бизнес-руководством. Поэтому она должна быть совместима с методами, используемыми в компании. Во многих случаях затраты учитываются по каждому подразделению, заказчику или продукту. Однако в идеале структура должна отражать предоставляемые услуги. Даже если этот процесс не использу­ется при выставлении счетов, ИТ-организация может посчитать полезным создать структуру затрат на основе структуры сервисов, определенных в Каталоге Услуг.

На рис. 11.4 показан пример иерархической структуры сервисных элементов, определенных ИТ-ор­ганизацией для предоставления услуг. В этой структуре сервисные элементы нижнего уровня под­держивают элементы более высокого уровня. Чем выше положение элемента в структуре, тем выше его значимость для бизнеса.

Рис. 11.4. Пример структуры сервиса

После определения сервисных элементов необходимо определить элементы затрат, которые затем подразделяются на единицы затрат, такие как персонал, аппаратное, программное обеспечение, на­кладные расходы и т. д.

Преимущество структурирования элементов затрат в соответствии с элементами сервиса заключает­ся в том, что становятся отчетливо видны расходы на аппаратное, программное обеспечение и под­держку услуг. В дополнение к структуре прямых затрат, показанной на рис. 11.4, возможно, компа­ния примет также решение о распределении косвенных затрат по услугам. Чем более детализиро­ванной будет структура сервиса, тем легче будет понять распределение затрат. В качестве альтерна­тивы в каталоге могут быть указаны только три стандартных рабочих станции, которые включают в себя все. В этом случае в схеме будет только три столбца и гораздо меньше элементов затрат. Такая структура может быть проще для понимания, но при этом уменьшится уровень детализации инфор­мации. Например, может быть непонятно, на какой элемент должны быть распределены затраты на поддержку сети, из-за чего будет невозможно определить необходимый для нее уровень поддержки.

Далее составляются бюджеты на следующий год по каждому элементу сервиса и затрат на основе прошлого опыта и с учетом предварительной оценки роста в следующем году. Производится ежеме­сячный мониторинг бюджетов с целью выявления изменений, таких как непредвиденный рост, и, в случае необходимости, для приведения бюджетов в соответствие с развитием бизнес-ситуации.

11.4.3. Выставление счетов

Ведение учета затрат, безусловно, не является новшеством, но оно приобретает все большее значе­ние. При этом выставление счетов за внутренние затраты — это относительно новое явление, кото­рое является эффективным средством поощрения пользователей к экономному использованию ИТ-ресурсов. Однако взимание платы за ИТ-услуги не принесет много пользы, если держатели бюджета в компании не будут оплачивать другие услуги, такие как телефон, помещение, почтовые услуги, питание, управление кадрами и т. д. Другими словами, практика выставления счетов должна соответст­вовать финансовой политике организации. Если такая практика существует, то держатели бюджета могут осуществлять управление текущими затратами, которые возможно включать в цену их проду­ктов и услуг.

Обычно практику выставления счетов вводят для возмещения всех возникающих затрат. В этом случае ИТ-организация работает как бизнес-подразделение компании. Но это осуществимо только в том случае, если известны реальные текущие затраты на ИТ-услуги.

Политика выставления счетов

Прежде чем определить тариф на услуги, рекомендуется проанализировать возможные варианты выставления счетов и определить политику в этой области.

Существуют несколько вариантов такой политики. Выбор подходящего метода зависит от целей, стоя­щих перед Процессом Управления Финансами. В то же время, если выставление счетов вводится поэ­тапно, то на каждом этапе могут использоваться различные правила. Политика выставления счетов это:

? Обмен информацией (Коммуникации) – руководителям, являющимся заказчиками ИТ-услуг, сообщают о тарифах, чтобы они были осведомлены о затратах их подразделений на ИТ-сервисы. Это может быть сделано двумя способами:

? расчет затрат по каждому подразделению[182] и информирование их руководителей;

? то же, но включая выставление счетов с использованием выбранного метода.

? Гибкость ценообразования – чаще всего тарифы определяются и затем используются на ежегод­ной основе. Если поставщик услуг проявляет инициативу по инвестициям в конкретную услугу в связи с ее частым использованием, то в контракт может быть включена статья о выставлении сче­тов на покрытие дополнительных затрат. Альтернативой является предложение образующейся до­полнительной мощности другим потенциальным заказчикам.

? Условное выставление счетов – затраты включаются в направляемые заказчику счета, но без тре­бования оплаты. Этот метод позволяет ИТ-организации накопить опыт по использованию процес­са и затем исправить ошибки в системе выставления счетов. Это также дает заказчику возможность привыкнуть к практике выставления счетов. Однако такой метод применим только в том случае, если в конце концов затраты действительно будут возмещены, в противном случае инфор­мирование о затратах будет бесполезным.

Тарифы[183]

Часто бывает трудно установить тариф на услугу. Установление тарифов включает следующие дей­ствия:

? определение цели выставления счетов;

? определение прямых и косвенных затрат;

? определение тарифов, существующих на рынке;

? анализ спроса на услуги;

? анализ количества заказчиков и конкуренции.

При определении тарифа за услуги организация должна сначала определить цель и ожидаемую вы­году для заказчика и ИТ-персонала.

Цена является одной из четырех составляющих маркетинга, куда входят: продукт, цена, продвиже­ние и место (четыре Р: Product, Price, Promotion, Place). Цена имеет значение не только при возме­щении затрат, но и при формировании спроса на продукцию. Гибкая стратегия ценообразования мо­жет использоваться для продвижения продуктов на рынок или для их снятия. Новая услуга, у кото­рой еще мало заказчиков, может субсидироваться за счет прибыли от продажи других услуг. Перед выбором стратегии ценообразования следует четко определить затраты на услугу.

Существуют разные типы политики ценообразования, например:

? Издержки плюс фиксированная прибыль – известно несколько вариантов, общей основой кото­рых является включение в цену затрат плюс чистая прибыль (стоимость + % наценки). Затраты и чистая прибыль могут определяться несколькими способами, такими как:

? все затраты плюс чистая прибыль;

? маржинальные затраты плюс маржа (наценка, достаточная для покрытия средних постоянных затрат, затрат на единицу продукции и стоимости капитала). Например, если доступ к LAN/WAN учитывается в счете за подключение к сети, эта составляющая уже не должна вклю­чаться в другие LAN-сервисы;

? один из вышеуказанных способов с маржой в 0%.

? Существующая ставка – для услуг, по которым уже существуют ценовые соглашения.

? Получение целевого дохода – для услуг, цена которых была определена заранее.

? Рыночная ставка (допустимая на рынке) – цены, которые сопоставимы с ценами внешних по­ставщиков.

? Согласованная договорная цена – эти цены согласуются с заказчиком. Если заказчику необходи­ма новая услуга, обсуждается вопрос о том, должна ли цена включать все затраты на инвестиции, или только их часть.

За услуги, на которые может быть снижена цена при увеличении объема, может предоставляться оп­товая скидка. С целью Управления Спросом (распределения спроса во времени) могут использо­ваться специальные тарифы в моменты пиковой загрузки и в периоды низкого спроса.

11.4.4. Отчетность

В зависимости от выбранной политики выставления счетов заказчик может получать либо счет за фактическое использование ИТ-услуг, либо информацию о реальном объеме использованных ИТ-сервисов. О затратах сообщается на регулярных встречах с заказчиком в рамках процесса Управле­ния Уровнем Сервиса. Поэтому Процессу Управления Уровнем Сервиса передается следующая ин­формация:

? затраты на ИТ-услуги в расчете на одного заказчика;

? разница между фактическими и расчетными затратами;

? используемые методы выставления счетов и методы бухгалтерского учета;

? все ценовые споры, их причины и варианты решения.

11.5. Контроль процесса

Бухгалтерский учет для ИТ является частью общей концепции ИТ Сервис-менеджмента, и им управляет руководитель Процесса Управления Финансами. Руководитель отвечает за внедрение и оперативное управление системой бухгалтерского учета и системой выставления счетов и от­читывается перед руководством ИТ. Руководитель Процесса Управления Финансами не обяза­тельно должен быть сотрудником ИТ-организации. Для оптимизации Процесса Управления Финансами могут использоваться отчеты, критические факторы успеха и ключевые показатели эффективности.

11.5.1. Отчеты для руководства

Предоставляемые руководству ИТ регулярные отчеты о Процессе Управления Финансами должны содержать следующую информацию:

? общие затраты на ИТ-услуги и получаемая бизнес-отдача (доход);

? анализ затрат по каждому ИТ-подразделению, аппаратной платформе или другим значимым разделам;

? затраты, связанные с системой Управления Финансами;

? планирование будущих инвестиций;

? возможности снижения затрат.

11.5.2. Критические факторы успеха и ключевые показатели эффективности[184]

Перед внедрением Процесса Управления Финансами следует проинформировать пользователей, персонал и руководство ИТ о цели внедрения процесса, затратах, преимуществах и потенциальных проблемах, связанных с данным процессом.

Эффективное внедрение системы выставления счетов зависит от следующих критических факторов успеха:

? пользователи должны знать, за какие услуги им выставляются счета;

? пользователи должны знать, какие методы выставления счетов используются, чтобы они могли контролировать затраты (например, с помощью соглашений или отчетов, составленных в терми­нах количественно измеримых показателей производительности);

? система мониторинга затрат должна предоставлять подробную информацию о расходах и их обос­нование;

? подход ИТ Сервис-менеджмента должен создать сбалансированную систему эффективных ИТ-сервисов, предоставляемых по разумной цене;

? руководство ИТ должно быть хорошо информировано о преимуществах внедрения Процесса Уп­равления Финансами и связанных с этим затратах, и подтвердить серьезность своих намерений в отношении данного процесса;

? Процесс Управления Конфигурациями должен предоставлять необходимую информацию о стру­ктуре услуг для организации соответствующей системы бухгалтерского учета.

Следующие ключевые показатели эффективности работ могут быть полезны для контроля процесса:

? точный стоимостной анализ[185] по предоставляемым услугам;

? удовлетворенность заказчиков используемыми методами выставления счетов;

? достижение ИТ-организацией ее финансовых целей;

? изменение потребления услуг заказчиками;

? своевременность отчетов для Процесса Управления Уровнем Услуг.

11.5.3. Функции и роли

В некоторых ИТ-организациях есть свои финансовые руководители, другие заключают соглашения с финансовым отделом, который тесно сотрудничает с руководством ИТ. Как и любой другой про­цесс, Управление Финансами должно иметь владельца процесса, отвечающего за развитие и под­держку финансовой системы.

Руководитель Процесса Управления Финансами должен работать на равных началах с руководст­вом других процессов и финансовым отделом для выработки основных направлений развития сис­тем Составления бюджета, Бухгалтерского учета и Выставления счетов.

11.6. Проблемы и затраты

11.6.1. Проблемы

Потенциальные проблемы могут быть следующими:

? деятельность по регистрации и мониторингу затрат часто является совершенно новой областью для ИТ-персонала, по которой существует не так много литературы;

? для мониторинга, калькуляции затрат и выставления соответствующих счетов часто требуется ин­формация о планировании услуг, не относящихся к ИТ, таких как строительство и т. д., по кото­рым трудно достать подробную информацию;

? трудно найти специалистов, знающих как ИТ, так и бухгалтерский учет,

? отсутствие четко сформулированной и документированной стратегии развития информационных систем, что затрудняет определение необходимых инвестиций;

? недостаточное понимание возможностей, предоставляемых процессом для оптимизации взаимо­действия между различными подразделениями;

? недостаточно серьезное отношение к процессу со стороны руководства может означать, что про­цесс не воспринимается организацией всерьез.

11.6.2. Затраты

Затраты на этот процесс можно разделить на две категории:

? административные и организационные затраты, связанные с планированием, внедрением и вы­полнением процесса;

? затраты на необходимые инструментальные средства, т. е. аппаратное обеспечение, базы данных и прикладное ПО.

Глава 12 Управление Мощностями

12.1. Введение

Задачей Процесса Управления Мощностями[186] является предоставление в нужное время и в экономи­чески эффективной форме необходимых мощностей для обработки и хранения данных, обеспечивая соответствующий баланс мощностей в ИТ-организации. Хорошее Управление Мощностями исклю­чает панические закупки в последнюю минуту или покупку самой большой системы "на всякий по­жарный случай". Подобные ситуации дорого обходятся. Многие центры обработки данных, напри­мер, постоянно работают с недогрузкой на 30-40% или больше. Это не так плохо, если у вас неболь­шое количество серверов. Но если у вас сотни и тысячи серверов, как у многих ИТ-организаций мас­штаба предприятия, то эти проценты означают потерю огромных финансовых средств.

Управление Мощностями отвечает за решение следующих вопросов:

? Оправдываются ли затраты на приобретение мощностей для обработки данных с точки зрения по­требностей бизнеса, и используются ли эти мощности наиболее эффективным образом (соотноше­ние стоимости и мощности)?

? Адекватно ли соответствуют имеющиеся мощности как текущим, так и будущим запросам заказ­чика (соотношение спроса и предложения)?

? Работают ли имеющиеся мощности с максимальной эффективностью (настройка производитель­ности)? Когда точно необходимо устанавливать дополнительные мощности?

Для выполнения задач Процессу Управления Мощностями необходима тесная связь с бизнес-про­цессами и ИТ-стратегией. Следовательно, данный процесс является как реактивным (измеряющим и улучшающим), так и проактивным (анализирующим и прогнозирующим).

12.1.1. Основные понятия

К важным понятиям по Управлению Мощностями относятся:

? Управление Производительностью (Performance Management): измерение, мониторинг и на­стройка производительности компонентов ИТ-инфраструктуры.

? Определение технических средств для приложения (Application sizing): определение мощности аппаратного обеспечения или пропускной способности сети, необходимых для поддержки новых или модифицированных приложений при ожидаемой рабочей нагрузке.

? Моделирование (Modeling): использование аналитических или имитационных моделей для оп­ределения требующейся для приложений мощности и выработка наилучшего решения. Модели­рование позволяет анализировать различные сценарии и задавать вопросы "что если?".

? Планирование мощностей (Capacity Planning): разработка Плана по мощностям, анализ текущей ситуации (предпочтительно с использованием сценариев) и прогнозирование будущего использо­вания ИТ-инфраструктуры и ресурсов, необходимых для удовлетворения ожидаемого спроса на ИТ-услуги.

12.2. Цели процесса

Процесс Управления Мощностями направлен на постоянное предоставление необходимых ИТ-ре­сурсов, соответствующих текущим и будущим потребностям заказчика, в нужное время (там, где они требуются) и за приемлемую цену.

Поэтому для Процесса Управления Мощностями необходимо понимание как ожидаемого развития бизнеса заказчика, так и прогнозируемого технического развития. Процесс Управления Мощностя­ми играет важную роль в определении возврата инвестиций и обосновании стоимости.

Преимущества использования процесса[187]

Выгодами внедрения Процесса Управления Мощностями являются:

? снижение рисков, связанных с существующими услугами, так как осуществляется эффективное Управление Ресурсами и постоянный мониторинг производительности оборудования;

? снижение рисков, связанных с новыми услугами, так как в результате определения конфигурации технических средств для приложения (application sizing) известно влияние новых приложений на существующие системы. То же относится и к модифицированным услугам;

? снижение затрат, так как инвестиции происходят в соответствующие моменты времени, не слиш­ком рано и не слишком поздно, что означает, что закупки не приходится делать в последнюю ми­нуту или покупать большие мощности впрок, раньше, чем они необходимы;

? снижение угрозы срыва работы бизнес-процессов за счет тесного взаимодействия с Процессом Управления Изменениями при определении воздействия изменений на мощности ИТ и телеком­муникационных средств и предотвращении экстренных изменений из-за неправильного расчета мощностей средств;

? составление более точных прогнозов при накоплении информации Процессом Управления Мощ­ностями, что позволяет быстрее реагировать на запросы заказчика;

? рост рациональности[188] работы за счет заблаговременного достижения баланса спроса и предло­жения;

? Управление Затратами или даже снижение затрат, связанных с мощностью средств, по причине их более рационального[189] использования.

Эти преимущества приводят к улучшению взаимоотношений с заказчиками. Процесс Управления Мощностями осуществляет взаимодействие с заказчиком на ранней стадии и позволяет предвидеть его требования. Также улучшаются взаимоотношения с поставщиками. Закупка, поставка, установка и обслуживание могут планироваться более эффективно.

12.3. Процесс

Как многие процессы библиотеки ITIL, Управление Мощностями берет свое начало от эры больших ЭВМ. Из-за этого, к сожалению, некоторые считают, что Управление Мощностями необходимо только в среде больших ЭВМ. Недооценка процесса усиливается значительным снижением цен на аппаратное обеспечение в последние годы. В результате многие просто покупают аппаратные средст­ва с избыточной мощностью, не осуществляя Управление Мощностями. Опасность заключается в том, что наибольшим источником затрат, рисков и возможных проблем в ИТ является не само аппа­ратное обеспечение. Другими словами, ненужное наращивание аппаратных средств создает пробле­мы менеджмента, которые обходятся более дорого, чем сами аппаратные средства.

Внедрение Процесса Управления Мощностями поможет предотвратить как ненужные инвестиции, так и проведение изменений мощностей случайным образом[190], так как последний аспект может осо­бенно отрицательно сказаться на предоставлении услуг. В настоящее время стоимость ИТ складыва­ется не столько из вложений в мощности средств ИТ, сколько из управления ими. Например, избыточное увеличение емкости дисковой памяти влияет на резервное копирование на внешний ленточ­ный носитель, так как поиск архивируемых файлов в сети займет больше времени. Этот пример ил­люстрирует важный аспект Процесса Управления Мощностями: качественное Управление Мощностями является, вероятно, наиболее важным фактором для изменения восприятия (и реального по­ложения) ИТ-организации: не как группы, увеличивающей накладные расходы, а как поставщика услуг. При хорошем Управлении Мощностями поставщик ИТ-услуг увидит, например, что восемнадцать стратегических инициатив, намеченных в ИТ в этом году, потребуют нового решения по резервному копированию. Понимая это, Руководитель Процесса Управления Мощностями может оп­ределить реальную стоимость этих инициатив, то есть учтет, что стоимость нового решения резерв­ного копирования распределена по этим восемнадцати инициативам. Это будет проактивным решением. С другой стороны, при отсутствии Управления Мощностями ИТ-организация отреагирует только после того, как мощности средств резервного копирования будут исчерпаны. В этом случае заказчик будет воспринимать ИТ-расходы как накладные, а ИТ-организацию – как "выпрашиваю­щую деньги", просто потому, что она не действовала проактивно в установлении и управлении ожиданиями заказчика и в заблаговременном планировании расходов.

Процесс Управления Мощностями направлен на предотвращение неожиданных и поспешных заку­пок путем лучшего использования имеющихся ресурсов, на своевременное наращивание мощности и на управление использованием текущих мощностей. Этот процесс может также помочь в коорди­нации различных компонент сервиса, что обеспечит рациональное использование инвестиций в со­ответствующие компоненты.

Современная ИТ-инфраструктура является чрезвычайно сложной. Это приводит к усилению зави­симостей между мощностями ее компонентов. В результате становится более трудно предоставлять заказчику сервис на согласованном уровне. Поэтому профессиональная ИТ-организация должна использовать комплексный подход к Управлению Мощностями.

На рис. 12.1 показаны основные виды деятельности, выполняемые в рамках Процесса Управления Мощностями.

Рис. 12.1. Процесс Управления Мощностями (источник: OGC)

Процесс Управления Мощностями состоит из трех подпроцессов (или уровней) анализа мощностей:

? Управление Возможностями Бизнеса – задачей этого подпроцесса является понимание бу­дущих потребностей пользователей. Оно может быть достигнуто за счет получения информа­ции от заказчика, например из его стратегических планов или за счет проведения анализа тенденций. Этот подпроцесс является проактивным. Он имеет тесную взаимосвязь с процессом Управления Уровнем Сервиса при определении и ведении переговоров о сервисных сог­лашениях.

? Управление Возможностями Сервиса – задачей этого подпроцесса является определение и пони­мание уровня использования ИТ-услуг заказчиками (продуктов и услуг, предоставляемых заказ­чикам). Для заключения подходящего Соглашения об Уровне Сервиса и гарантии его выполнения необходимо знать показатели производительности и пиковой нагрузки на системы.

? Управление Мощностями Ресурсов – задачей этого подпроцесса является определение и понима­ние использования ИТ-инфраструктуры. Примерами ресурсов могут быть полоса пропускания се­ти, мощность средств обработки данных и емкость дисковой памяти. Для эффективного[191] Управления Ресурсами необходимо заранее определить потенциальные проблемы. Необходимо также быть в курсе тенденций развития ИТ-инфраструктуры. В рамках этого подпроцесса важным ви­дом деятельности является активный мониторинг тенденций развития.

Так как Процесс Управления Мощностями и потребности бизнеса связаны между собой, Управле­ние Мощностями является существенным элементом процесса планирования. Однако нельзя недо­оценивать и поддержку, предоставляемую им для операционных процессов[192]. Ниже рассматриваются связи этого процесса с другими процессами Сервис-менеджмента.

Взаимоотношения с Процессом Управления Инцидентами

Управление Инцидентами информирует процесс Управления Мощностями об инцидентах, возник­ших из-за проблем с мощностью средств ИТ. Управление Мощностями может предоставить Управ­лению Инцидентами шаблоны (методики, описание шагов и действий)[193] для диагностики или реше­ния этих проблем.

Взаимоотношения с Процессом Управления Проблемами

Управление Мощностями поддерживает Процесс Управления Проблемами в его как реактивной, так и проактивной деятельности. Инструментарий Процесса Управления Мощностями, информация, накопленная в ходе его работы, знания и экспертиза могут использоваться для поддержки Процесса Управления Проблемами на различных этапах.

Взаимоотношения с Процессом Управления Изменениями

Сотрудники, участвующие в Процессе Управления Мощностями могут входить в состав Консульта­тивного совета по изменениям[194]. Управление Мощностями может предоставлять информацию о по­требности в мощностях и потенциальном воздействии изменений на предоставление услуг. Инфор­мация об изменениях является входными данными для составления Плана по мощностям[195]. Во время разработки этого плана Процесс Управления Мощностями может направлять Запросы на измене­ния (RFC)[196].

Взаимоотношения с Процессом Управления Релизами

Процесс Управления Мощностями поддерживает планирование распространения релизов при ис­пользовании компьютерных сетей для их тиражирования автоматическими и ручными средствами.

Взаимоотношения с Процессом Управления Конфигурациями

Между Базой Данных Мощностей[197] (CDB) и Конфигурационной Базой Данных (CMDB) существу­ет тесная взаимосвязь. Информация, предоставляемая Процессом Управления Конфигурациями, существенно необходима для разработки эффективной базы данных мощностей.

Взаимоотношения с Процессом Управления Уровнем Услуг

Процесс Управления Мощностями дает рекомендации Процессу Управления Уровнем Услуг по воп­росу реалистичности обсуждаемых Уровней Сервиса (например, скорости реакции приложения). Управление Мощностями осуществляет измерение и мониторинг производительности и предостав­ляет контрольную информацию для проверки исполнения согласованного Уровня Сервиса, а при необходимости и инициирует изменение Уровня Услуг и составляет необходимые отчеты.

Взаимоотношения с Процессом Управления Финансами ИТ

Управление Мощностями поддерживает составление плана инвестиций, анализ соотношения дохо­дов и расходов[198] и принятие решений по инвестициям. Кроме того, этот процесс предоставляет важ­ную информацию для выставления счетов по услугам, связанных с предоставлением мощностей, на­пример, выделение сетевых ресурсов.

Взаимоотношения с Процессом Управления Непрерывностью ИТ-услуг

Управление Мощностями определяет минимальную мощность, необходимую для продолжения ока­зания услуги в случае непредвиденных обстоятельств. Мощности, необходимые для Управления Непрерывностью ИТ-сервисов должны постоянно проверяться (пересматриваться), чтобы обеспе­чить их соответствие ежедневным изменениям в операционной среде.

Взаимоотношения с Процессом Управления Доступностью

Процессы Управления Мощностями и Управления Доступностью тесно связаны между собой. Проблемы с производительностью и мощностью могут привести к срыву работы ИТ-услуг. В дейст­вительности заказчик может считать малую производительность работы сервиса равнозначной не­доступности. Необходима эффективная координация этих двух процессов из-за их тесной взаимоза­висимости. В них используется большое количество одинаковых инструментальных средств и мето­дик, таких как анализ степени влияния сбоя компонентов (Component Failure Impact Analysis – CFIA) и анализ дерева сбоев (Fault Tree Analysis – FTA).

12.4. Виды деятельности

Ниже описываются виды деятельности в рамках Процесса Управления Мощностями с разделением по каждому подпроцессу.

12.4.1. Управление Возможностями Бизнеса (Business Capacity Management)

Управление Мощностями Бизнеса включает следующие виды работ:

Разработка Плана по мощностям[199]

В Плане по мощностям описываются текущие мощности ИТ-инфраструктуры и ожидаемые измене­ния спроса на ИТ-услуги, замена устаревших компонентов и планы технического развития. План по мощностям также определяет изменения, необходимые для предоставления услуг на согласованном в SLA уровне по приемлемой стоимости. То есть План по мощностям описывает не только ожидае­мые изменения, но и связанные с ними затраты. Этот план должен составляться ежегодно и прове­ряться ежеквартально для подтверждения его актуальности.

В определенном смысле План по мощностям является самым важным выходным документом Про­цесса Управления Мощностями. В выходные данные часто включают годовой план, согласованный по срокам с бюджетом или инвестиционным планом, долгосрочный план и ежеквартальные планы с подробной информацией о запланированных изменениях мощностей. Совместно это представляет собой комплект связанных между собой планов, где уровень детализации повышается с приближе­нием сроков планирования.

Моделирование

Моделирование является мощным инструментом Управления Мощностями, используемым для прогнозирования тенденций в инфраструктуре.

В рамках Процесса Управления Мощностями используется широкий диапазон инструментальных средств – от инструментариев оценки до средств всестороннего тестирования прототипов. Первые недороги и часто применимы в повседневной деятельности. Вторые обычно подходят только для крупномасштабных проектов внедрения.

Между этими двумя полюсами существует большое количество подходов, которые точнее оценок и дешевле крупных экспериментальных макетов. В порядке повышения их стоимости они включают в себя:

? анализ тенденции (самый дешевый способ);

? аналитическое моделирование;

? имитационное моделирование[200];

? тестирование в сравнении с некоторым базовым вариантом[201], также называемый бенчмаркинг (да­ет наиболее точную оценку).

Анализ тенденции может использоваться для получения информации о допустимой нагрузке, но не для предсказания времени реакции приложения. Аналитическое и имитационное моделирование имеют свои достоинства и недостатки. Например, имитационное моделирование может использо­ваться для точного предсказания производительности центрального компьютера[202], возможно, в рам­ках работ по определению необходимого размера технической платформы для работы ПО[203]. Однако этот метод связан с большими затратами времени. Аналитическое математическое моделирование обычно занимает меньше времени, но получаемая на выходе информация менее надежна. Тестирова­ние в сравнении с некоторым базовым вариантом (бенчмаркинг) означает, что создается среда с ре­альными условиями, например в вычислительном центре поставщика. Эта среда удовлетворяет тре­бованиям к производительности и используется для моделирования типа "что если" или моделиро­вания изменений. Например, таких как "что случится, если компонент приложения будет переведен на другую компьютерную систему?" или "что случится, если мы удвоим количество транзакций?".

Определение размера технической платформы для работы ПО[204]

На этом этапе происходит определение конфигурации технических средств, необходимой для рабо­ты новых или измененных приложений, например, таких, которые находятся в стадии разработки или которые могут быть закуплены по запросу заказчика. Эти расчеты содержат информацию об ожидаемом уровне производительности, необходимых аппаратных средствах и затратах. Такой порядок действий особенно актуален на начальных стадиях разработки ПО. Ясная информа­ция о требуемых аппаратных средствах и других ИТ-ресурсах, а также об ожидаемых затратах на начальной стадии представляет ценность для руководства. Это также помогает при разработке прото­типов новых Соглашений об Уровне Услуг (SLA).

Работы по определению размеров необходимой технической платформы могут потребовать значи­тельных усилий в крупных компаниях или в организациях со сложной ИТ-инфраструктурой. В на­чале в рамках Процесса Управления Мощностями происходит согласование с разработчиками Тре­бований к Уровню Сервиса, который должен быть реализован с помощью продукта. Когда продукт достигает этапа приемо-сдаточных испытаний, выполняется проверка достижения требуемого уров­ня сервиса в терминах производительности центрального процессора (CPU), устройств ввода-выво­да (I/O), сети, использования дисковой и оперативной памяти.

Одним из результатов этапа по определению размеров технической платформы являются показате­ли рабочей нагрузки. Они могут использоваться для прогнозирования необходимой мощности, на­пример, что будет, если число пользователей возрастет на 25%. Другими показателями рабочей на­грузки являются требования по мощности во времени (пиковые нагрузки в течение суток/неде­ли/года и перспективы будущего роста).

12.4.2 Управление Возможностями Сервисов и Управление Мощностями Ресурсов

Эти подпроцессы включают одинаковые виды деятельности, но с акцентом на различные аспекты. Управление Возможностями Сервисов обращается к предоставлению ИТ-услуг, а Управление Мощ­ностями Ресурсов – к технологическим аспектам их предоставления. Виды деятельности показаны на рис. 12.2.

Рис. 12.2. Управление Производительностью Ресурсов и Сервисов (источник: OGC)

Мониторинг

Мониторинг компонентов инфраструктуры ведется с целью гарантии выполнения согласованных Уровней Сервисов. Примерами ресурсов, в отношении которых может проводиться мониторинг, яв­ляются использование процессоров (CPU), диска, сети, числа лицензий (т. е., например, существует только десять свободных лицензий) и т. д.

Анализ

Данные мониторинга необходимо анализировать. Для прогнозирования будущего использования можно применять анализ тенденций. Результаты анализа могут привести к началу работ по повышению рациональности использования или к приобретению дополнительных ИТ-компонентов. Ана­лиз деятельности требует глубокого знания всей инфраструктуры и бизнес-процессов компании.

Настройка

Настройка выполняется с целью оптимизации систем для текущей или ожидаемой рабочей нагруз­ки на основе результатов анализа и интерпретации данных мониторинга.

Внедрение

Целью внедрения является ввод измененной или новой мощности. Если это связано с изменением, то внедрение вовлекает Процесс Управления Изменениями.

Управление Спросом

Управление Спросом нацелено на вопросы потребления ИТ-мощностей. Управление Спросом зани­мается изучением влияния различных факторов на спрос. Простой пример: пользователь запускает плохо написанный SQL-отчет в середине дня, преграждая другим пользователям доступ к базе дан­ных и создавая непомерный трафик. Руководитель Процесса Управления Мощностями предлагает запускать задание по составлению отчета ночью, так, чтобы пользователь получал результат на сво­ем столе утром.

Проведем различие между Управлением Краткосрочным и Долгосрочным Спросом:

? Управление Краткосрочным Спросом – в случае, если в ближайшем будущем есть угроза повторя­ющейся нехватки мощностей ИТ-средств и если доступ к дополнительным мощностям затруднен;

? Управление Долгосрочным Спросом – если не удается обосновать стоимость модернизации, хотя в определенные периоды времени (например, между 10:00 и 12:00) может возникать недостаток мощности.

Управление Спросом предоставляет важную информацию для составления, мониторинга и, возмож­но, корректировки как Плана по мощностям, так и Соглашении об Уровнях Сервиса. Управление Спросом может также использовать дифференцированную тарификацию (т. е. различ­ные тарифы в пиковое и не пиковое время) для воздействия на заказчика.

Заполнение Базы Данных Мощностей (CDB)

Создание и заполнение базы данных CDB означает сбор и обновление технической, бизнес- и любой другой информации, относящейся к Управлению Мощностями. Может быть, нереально хранить всю информацию по мощностям в одной физической базе данных. Руководители по сетевым и компью­терным системам могут использовать свои собственные методы. Часто база данных CDB содержит ссылки на различные источники информации по мощностям ИТ-систем.

Рис. 12.3. Источники информации для базы данных CDB.

12.5. Контроль процесса

Процесс Управления Мощностями наиболее эффективен в случае, если он тесно связан с другими процессами планирования, такими как Управление Доступностью, и с деятельностью по разработке приложений. Такая взаимосвязь способствует использованию проактивного подхода в работе Про­цесса Управления Мощностями.

12.5.1. Отчеты для руководства

Представляемые процессом отчеты для руководства содержат, с одной стороны, информацию об Уп­равлении Процессом в терминах показателей Плана по мощностям, ресурсов, используемых для ре­ализации процесса, и деятельности по совершенствованию процесса; а с другой стороны отчеты об отклонениях по таким вопросам как:

? расхождения между фактическим и плановым использованием мощностей;

? тенденции в расхождениях;

? воздействие на Уровни Сервиса;

? ожидаемое увеличение/уменьшение использования мощностей в краткосрочной и долгосрочной перспективе;

? пороговые значения, при достижении которых потребуется приобретение дополнительных мощ­ностей.

12.5.2. Критические факторы успеха и Ключевые Показатели Эффективности (КPI)

Управление Мощностями зависит от следующих критических факторов успеха:

? точной оценки бизнес-планов и ожиданий заказчиков;

? понимания ИТ-стратегии и планирования, а также точности планирования;

? оценки ведущихся технических разработок в компании;

? взаимодействия с другими процессами.

Следующие параметры могут служить Ключевыми Показателями Эффективности (KPI) работы Процесса Управления Мощностями:

? Предсказуемость потребностей заказчика: определение изменений рабочей нагрузки и тенден­ций, а также точность Плана по мощностям.

? Технология: различные варианты измерения производительности ИТ-сервисов, темпы внедрения новых технологий и возможность постоянно выполнять Соглашения об Уровне Услуг (SLA) даже при использовании старых технологических средств.

? Затраты: уменьшение числа срочных закупок, сокращение ненужных или дорогих избыточных мощностей и составление планов инвестиций на ранней стадии.

? Операционная деятельность ИТ[205]: уменьшение количества инцидентов из-за проблем с произво­дительностью, возможность удовлетворить спрос заказчика в любое время и степень серьезности в отношении компании к Процессу Управления Мощностями.

12.5.3. Функции и роли

Роль Руководителя Процесса Управления Мощностями заключается в руководстве процессом и в обеспечении разработки и поддержания Плана по мощностям, а также в гарантии актуальности базы данных мощностей (CDB).

Менеджеры систем, сетей и приложений также играют важную роль в Процессе Управления Мощ­ностями. Они не только являются ответственными за оптимизацию производительности, от них так­же ожидается использование их профессиональных знаний для преобразования потребностей биз­неса в профили[206] загрузки систем и определения на их основе необходимых мощностей ИТ-средств.

12.6. Проблемы и затраты

12.6.1. Проблемы

Потенциальные проблемы Процесса Управления Мощностями могут быть следующими:

? Нереалистичные ожидания – разработчики[207], руководители и заказчики часто имеют нереа­листичные ожидания из-за недостаточного понимания технических возможностей приложе­ний, компьютерных систем и сетей. Одной из задач Процесса Управления Мощностями явля­ется направление этих ожиданий, например, путем осведомления разработчиков о воздействии их разработок (например, базы данных) на мощности ИТ-средств и их производительность. Эффект от работы Процесса Управления Мощностями также может переоцениваться, особенно в отношении настройки системы и составления графика рабочей нагрузки. Если ра­бота системы требует значительной настройки, то, скорее всего, причина в недостатках дизай­на приложения или базы данных. В целом, настройка не может быть использована для дости­жения более высокого уровня производительности, чем тот, на который система была рассчи­тана изначально. Большинство крупных ИТ-систем имеют алгоритмы планирования загрузки, которые обычно более эффективны, чем вовлечение системных менеджеров. И конечно, суще­ствуют и затраты, связанные с настройкой: для высокооплачиваемого инженера не имеет смысла тратить недели на достижение 3%-го улучшения характеристик, если расширение па­мяти за 100 долларов даст улучшение на 10%. Еще более дорого обойдется Управление Систе­мами, которые не являются "простыми, как дважды два". Чрезмерное "дергание" параметров на различных блоках, приложениях или базах данных может повлечь непреднамеренные последствия и увеличит задержку всех процессов сервис-менеджмента, а также обслуживание и поиск неисправностей.

? Недостаток соответствующей информации – часто бывает трудно получить необходимую ин­формацию, например, для Плана по мощностям. Могут возникнуть затруднения в получении дос­товерной информации об ожидаемой рабочей нагрузке, так как планы заказчика неизвестны или почти неизвестны, в особенности в деталях. Это также вызывает трудности у заказчика, так как жизненный цикл продукта становится все короче. Единственное решение – это делать наилучшие возможные оценки и периодически обновлять их при получении большей информации.

? Информация от поставщика – при отсутствии информации о предыстории вопроса (например, когда закупается новая система), Управление Мощностями становится зависимым от информа­ции, предоставляемой поставщиками. Поставщики обычно используют результаты тестов[208] для предоставления информации об их системах, но из-за больших различий в методах тестирования часто бывает трудно сопоставить информацию, и она может ввести в заблуждение о действитель­ной производительности системы.

? Внедрение в комплексных ИТ-средах - внедрение в сложных распределенных средах является трудной задачей, так как значительное количество технических интерфейсов создает большое число взаимозависимостей параметров производительности.

? Определение подходящего уровня мониторинга – инструменты для мониторинга часто имеют много опций и могут провоцировать на чрезмерно подробные исследования. При покупке и ис­пользовании этих инструментов необходимо заранее решить, на каком уровне детализации дол­жен проводиться мониторинг.

Эти проблемы являются актуальными дня Управления Мощностями компьютерных систем, а также сетей, больших принтерных центров и телефонных АТС-систем[209]. Это может вызвать еще больше за­труднений, если за эти области отвечают несколько подразделений, что может привести к конфлик­там в ответственности за Управление Мощностями.

12.6.2. Затраты

Затраты на ввод в действие Управления Мощностями должны быть определены при подготовке вне­дрения процесса. Эти затраты можно разделить на следующие группы:

? закупка аппаратных и программных средств, таких как инструменты мониторинга, база данных мощностей (CDB), инструменты моделирования для имитационного моделирования и статисти­ческого анализа и инструменты генерации отчетов;

? затраты на Управление Проектом по внедрению процесса;

? затраты на персонал, обучение и поддержку;

? помещение и т. д.

После запуска процесса остаются текущие расходы на персонал, контракты на обслуживание и т. д.

Глава 13 Управление Непрерывностью ИТ-сервисов

13.1. Введение

Многие руководители считают Процесс Управления Непрерывностью ИТ-сервисов (IT Service Con­tinuity Management – ITSCM) роскошью, на которую у них нет средств. Однако, как показывает статистика, чрезвычайные ситуации стали часто встречающимся явлением.

Чрезвычайная ситуация (бедствие, катастрофа) – это событие, которое оказывает такое негативное воздействие на функционирование сервиса или системы, что требуются значительные усилия для восстановления изначального Уровня Производительности.

Как следует из данного определения, чрезвычайная ситуация намного серьезнее инцидента. Чрезвы­чайная ситуация – это приостановка бизнеса. Это означает, что весь бизнес или его часть будет на­ходиться "вне бизнеса" после возникновения чрезвычайной ситуации. Известны такие примеры чрезвычайных ситуаций, как пожары, удары молнии, наводнения, кражи, вандализм и акты насилия, широкомасштабное нарушение электроснабжения и сбои в работе аппаратного обеспечения. Атаки террористов, например, нападение на Всемирный торговый центр в Нью-Йорке, становятся реаль­ностью. Чрезвычайные ситуации возможны также и в Интернете, например, отказ сервиса (DoS)[210] может разрушить связь внутри всей организации. Некоторые организации могли бы предотвратить серьезные проблемы, если бы в свое время разработали План обеспечения непрерывности бизнеса. Бизнес все больше и больше зависит от ИТ-услуг, а это означает, что последствия потери сервиса становятся все более ощутимыми и все менее допустимыми. Фактически, сейчас во многих органи­зациях ведение бизнеса эквивалентно использованию информационных технологий (ИТ), и без них бизнес едва ли будет существовать. Поэтому необходимо решать, как защитить непрерывность биз­неса. Со времени опубликования модуля Планирование на случай чрезвычайных обстоятельств (Contingency Planning Module) ассоциацией CCTA многое изменилось в области информационных технологий и в том, как они используются в организациях. Ранее это планирование касалось только ИТ. В настоящий момент информационные технологии уже значительно интегрированы во многие аспекты бизнеса. Если раньше традиционный процесс планирования непрерывности работы и восстановления функционирования в основном носил реактивный характер (что делать в случае воз­никновения чрезвычайной ситуации), то теперь Процесс Управления Непрерывностью ИТ-серви­сов выполняет превентивную роль, т. е. работает над предотвращением катастроф.

13.2. Цель процесса

Цель Процесса Управления Непрерывностью ИТ-сервисов — оказывать поддержку Процессу Упра­вления Непрерывностью Бизнеса (Business Continuity Management – ВСМ). Такая поддержка озна­чает, что необходимая инфраструктура и ИТ-услуги, включая службу поддержки и службу Service Desk, могут быть восстановлены за заданный период времени после возникновения чрезвычайной ситуации. У данного процесса может быть и ряд других целей. Поскольку процесс ITSCM является составной частью Процесса Управления Непрерывностью Бизнеса, сфера действия Процесса Управ­ления Непрерывностью ИТ-сервисов (ITSCM) должна определяться, исходя из целей бизнеса. В ре­зультате при оценке рисков можно потом определить, попадают ли они в сферу действия данного процесса.

Преимущества использования процесса[211]

Поскольку бизнес во все большей степени зависит от ИТ-услуг, определить, во что может обойтись недостаточное планирование непрерывности предоставления ИТ-услуг и какие преимущества даст должное планирование этих вопросов, можно только с помощью анализа рисков. После того, как оп­ределен возможный риск для бизнеса, а не только для ИТ-сервиса, можно выделять средства для принятия превентивных мер и мер по борьбе с чрезвычайными ситуациями, например, разработка Плана восстановления после катастрофы.

Если чрезвычайная ситуация все же произошла, то использование процесса ITSCM даст бизнесу следующие преимущества:

? возможность управлять восстановлением своих систем;

? уменьшить простои в работе;

? свести к минимуму перерывы в ведении бизнеса.

13.3. Процесс

Процесс Управления Непрерывностью ИТ-сервисов отвечает за:

? оценку воздействия нарушений в работе ИТ-сервисов после возникновения чрезвычайной ситу­ации;

? определение критичных для бизнеса сервисов, которые требуют дополнительных превентив­ных мер;

? определение периода времени, в течение которого сервис должен быть восстановлен;

? принятие мер по предотвращению, обнаружению, подготовке к чрезвычайным ситуациям или по уменьшению степени их воздействия;

? определение общего подхода к восстановлению услуг;

? разработку, тестирование и поддержку плана восстановления с достаточным Уровнем Детализа­ции, который поможет пережить чрезвычайную ситуацию и восстановить нормальную работу за заданный период времени.

Поскольку наблюдается все большее взаимопроникновение бизнес-операций и информационных технологий, то эти две области вместе описываются в рамках ITIL:

? Процесс Управления Непрерывностью Бизнеса (Business Continuity Management – ВСМ) обес­печивает анализ и Управление Рисками, что позволяет организации во все времена гарантировать сохранение минимально требуемых производственных мощностей и Уровня Сервисов. Процесс ВСМ помогает уменьшить степень риска до приемлемого уровня и разработать Планы восстанов­ления бизнес-деятельности на случай, если она пострадает во время чрезвычайной ситуации.

? Процесс Управления Непрерывностью ИТ-сервисов (ITSCM) – это процесс, предназначенный для противодействия на случай чрезвычайных обстоятельств, затрагивающих ИТ-услуги, и вос­становления сервисов, необходимых для возобновления бизнес-операций.

Процесс Управления Непрерывностью ИТ-сервисов является частью общего процесса Управления Непрерывностью Бизнеса, и он зависит от информации, которую предоставляет процесс ВСМ. Дос­тупность ИТ-сервисов обеспечивается благодаря сочетанию мер по уменьшению степени риска (на­пример, использование высоконадежных систем) и способов восстановления (например, запасные и параллельно работающие системы). Для успешной реализации процесса требуются поддержка со стороны всей организации, твердое намерение руководства реализовать данный процесс и участие всего персонала.

Процесс Управления Непрерывностью ИТ-сервисов взаимодействует со всеми другими процессами ИТ Сервис-менеджмента, особенно с такими как:

? Управление Уровнем Сервиса: предоставляет информацию об обязательствах во предоставлению ИТ-услуг.

? Управление Доступностью: поддерживает процесс ITSCM в части разработки и внедрения пре­вентивных мер.

? Управление Конфигурациями: определяет базисные конфигурации и элементы ИТ-инфраструк­туры, информация о которых используется при восстановлении после чрезвычайной ситуации.

? Управление Возможностями: гарантирует поддержку требований бизнеса соответствующими ИТ-ресурсами.

? Управление Изменениями: обеспечивает правильность и актуальность всех планов в рамках про­цесса ITSCM благодаря вовлечению ITSCM в работу над всеми изменениями, которые могут по­влиять на превентивные меры и Планы восстановления.

13.4. Виды деятельности

На рис 13.1 показаны виды работ, выполняемые в рамках процесса ITSCM. Цифры обозначают под­разделы раздела 13.4, в которых описывается тот или иной вид деятельности.

Рис. 13.1. Модель Процесса Управления Непрерывностью ИТ-Сервисов (на основе модели OGC)

13.4.1. Определение охвата (области действия)[212] Процесса Управления Непрерывностью ИТ-сервисов

При инициализации процесса ITSCM необходимо рассмотрение всей организации в целом и выпол­нение следующих действий:

? Определение политики – определение политики организации в отношении Управления Непре­рывностью ИТ-сервисов следует осуществить по возможности быстрее и довести ее до сведения каждого сотрудника организации, чтобы все знали о необходимости процесса ITSCM. Руководст­во должно продемонстрировать свое твердое намерение реализовать данный процесс.

? Определение области действия процесса и других важных для процесса областей – при выборе подхода к оценке риска и Анализу воздействия на бизнес (Business Impact Analysis) и методов их выполнения используются страховые требования, стандарты качества, такие как серия ISO-9000, стандарты Управления Безопасностью, например, BS7799 и общие принципы определения поли­тики в области бизнеса. На этом этапе также определяются соответствующая структура менедж­мента и процессов на случай чрезвычайной ситуации.

? Выделение ресурсов – развертывание ИТ-среды на случай чрезвычайных обстоятельств потре­бует значительных затрат на персонал и ресурсы. Должно быть проведено обучение персонала для подготовки к выполнению второго этапа процесса ITSCM (Требования и стратегия).

? Подготовка проектной организации – рекомендуется использовать формальные методы Управ­ления Проектом, такие как PRINCE 2, совместно с программным обеспечением, предназначенным для целей планирования.

13.4.2. Анализ воздействия на бизнес[213]

Перед проведением анализа ИТ-услуг рекомендуется установить причины, почему компании необ­ходимо включать Процесс Управления Непрерывностью ИТ-сервисов в общий Процесс Управле­ния Непрерывностью Бизнеса, и определить потенциальное воздействие серьезных сбоев услуг. В некоторых случаях при возникновении чрезвычайной ситуации бизнес некоторое время еще может функционировать, и тогда основное внимание уделяется восстановлению услуг, в других случаях бизнес не может работать без ИТ-услуг, поэтому основное внимание уделяется предотвращению чрезвычайных ситуаций. В большинстве случаев необходимо найти баланс между этими двумя крайностями.

Среди возможных причин внедрения этого процесса могут быть следующие:

? защита бизнес-процессов;

? быстрое восстановление сервиса;

? необходимость выдержать конкуренцию;

? сохранение позиций на рынке;

? сохранение прибыльности;

? защита репутации компании.

Эти причины могут быть комбинированы. В финансовой сфере, например, в торговле валютными средствами, отсутствие информации о рынке ведет к приостановке торговли (основного бизнес-про­цесса), что означает потерю денег. Более того, если существует государственное требование регист­рировать все валютные операции с использованием специализированной системы, то можно про­должать ведение бизнеса даже в случае повреждения этой системы, но рано или поздно это требова­ние все равно будет нарушено, и тогда возможно наложение штрафа. В обоих случаях компания мо­жет потерять заказчиков и свои позиции на рынке.

Анализ сервисов

После того, как определена необходимость внедрения Процесса Управления Непрерывностью ИТ-сервисов, следует провести анализ ИТ-услуг, необходимых для бизнеса (например, информацион­ные системы, офисные приложения, бухгалтерские приложения, электронная почта и т. д.), которые должны быть доступны в соответствии Соглашениям об Уровне Сервиса. Для некоторых услуг не­высокой значимости могут быть достигнуты договоренности о предоставлении экстренного сервиса с ограниченными возможностями и доступностью. Уровни Сервиса во время восстановления могут быть изменены только по договоренности с заказчиком. Для критически важных услуг необходимо найти компромисс между превентивными мерами и способами восстановления.

Инфраструктура

После анализа сервисов выполняется оценка зависимостей между сервисами и ИТ-ресурсами. Ин­формация из Процесса Управления Доступностью используется для анализа степени критичности ИТ-ресурсов для поддержки описанных ранее ИТ-услуг. Процесс Управления Возможностями пре­доставляет информацию о необходимых мощностях, а также помогает определить, на какое время эти услуги могут быть приостановлены с момента сбоя сервиса до его восстановления. В последст­вии такая информация может быть использована для определения способов восстановления по каж­дой услуге.

13.4.3. Оценка рисков

Официальная статистика по чрезвычайным ситуациям отсутствует, но во всем мире известны такие катастрофы, как:

Анализ рисков способен помочь в определении рисков, угрожающих бизнесу. Такой анализ дает цен­ную информацию руководству, т. к. он позволяет выявить вероятные угрозы и виды уязвимости и определить соответствующие превентивные меры. Поскольку поддержка Плана восстановления по­сле чрезвычайной ситуации является относительно дорогим мероприятием, то сначала можно вос­пользоваться превентивными мерами. После того, как такие меры предприняты против наиболее серьезных рисков, следует определить, остались ли еще риски, для которых необходим План обеспе­чения непрерывности работы (Contingency Plan). На рис. 13.2 показаны связи между Анализом рис­ков и Управлением Рисками; они основываются на методе Анализа и Управления Рисками, разрабо­танного ассоциацией CCTA (CCTA Risk Analysis and Management Method – CRAMM).

Рис. 13.2. Метод оценки рисков ассоциации CCTA (источник: OGC)

Данная модель позволяет поддерживать эффективное планирование на случай чрезвычайных обсто­ятельств путем реализации поэтапного подхода.

Анализ рисков

? Во-первых, должны быть определены вовлеченные компоненты (активы), такие как здания, сис­темы, данные и т. д. Эффективная идентификация активов требует определения владельцев и на­значения активов.

? Следующий этап – анализ угроз и зависимостей, а также оценка вероятности возникновения чрезвычайной ситуации (высокая, средняя, низкая), например, комбинация ненадежной системы энергоснабжения и района с большим количеством бурь и гроз.

? Далее – идентификация и классификация (высокая, средняя, низкая) уязвимостей. Молниеотвод может дать некоторую защиту от ударов молний, но они все же могут серьезно повлиять на работу сети и систем.

? И последний этап – оценка угроз и уязвимостей в контексте ИТ-компонентов для получения оценки риска.

При оценке риска следует учитывать область действия[214] процесса; фактически такая оценка является частью начала внедрения Процесса Управления Непрерывностью ИТ-сервисов (этап 1). Например, незначительные проблемы можно решить с помощью мер, принимаемых Процессом Управления До­ступностью, в то время как другие риски для бизнеса могут выходить за сферу действия процесса ITSCM.

13.4.4. Стратегия обеспечения непрерывности ИТ-сервисов

Многие направления бизнеса стараются найти равновесие между сокращением степени риска и пла­нированием работ по восстановлению. Следует понимать разницу между такими понятиями, как со­кращение риска, работы по восстановлению бизнес-деятельности и способы восстановления ИТ. Ниже обсуждается связь между сокращением степени риска (предотвращение) и планированием восстановления (способы восстановления).

Угрозы никогда нельзя устранить полностью. Например, пожар в соседнем здании может повредить ваше здание. Уменьшение одного вида риска может вызвать повышение другого. Например, аутсор­синг может привести к повышению рисков в области безопасности.

Превентивные меры

Превентивные меры можно принимать на основе анализа рисков при тщательном учете затрат и ри­сков. Такие меры могут помочь в уменьшении вероятности непредвиденных обстоятельств или сте­пени их воздействия, и тем самым сократить сферу действия Плана восстановления. Превентивные меры действенны против пыли, чрезвычайно высоких или низких температур, пожаров, утечек во­ды, прекращения энергоснабжения и воровства. Остальные виды рисков будут учтены в Плане вос­становления.

Метод "Неприступной крепости"[215] является самой дорогой превентивной мерой. Он позволяет уст­ранить большинство видов уязвимости, например, путем строительства бункера с собственным энерго- и водоснабжением. Однако такой подход может привести к появлению других уязвимых мест, например, риску сбоя сети или появлению пробок на дорогах, что только затруднит восстанов­ление. Подход "Неприступной крепости" пригоден для крупных вычислительных центров, которые слишком сложны для разработки для них Плана восстановления. В наше время важно дополнять данный подход возможностью быстрого реагирования[216], т. е. возможностью направляться туда, где есть проблема, и быстро ее решать, пока она не вышла из-под контроля.

Выбор способов восстановления[217]

Если остались еще виды рисков, которые не удалось устранить с помощью превентивных мер, тогда для них производится планирование восстановления. Способы восстановления должны включать в себя:

? Персонал и размещение – помещение, мебель, транспорт, способ перемещения и т. д.

? ИТ-системы и сети – способы восстановления будут обсуждаться ниже.

? Вспомогательные службы – электро- и водоснабжение, телефон, почта и курьерская связь.

? Архивы – дела, документы, архив на бумажных носителях и справочные материалы.

? Услуги сторонних организаций – таких, как поставщиков услуг электронной почты и Интернета.

Существует несколько способов для быстрого восстановления ИТ-услуг:

? Ничего не делать – лишь немногие бизнес-организации могут себе это позволить. Это больше на­поминает стремление уйти от проблем, устраниться от решения. Подразделения, которые думают, что могут обойтись без средств восстановления ИТ-сервиса, создают о себе впечатление, как о структурах, ничего не значащих для целей бизнеса, которые могут не потребоваться в случае чрез­вычайной ситуации. Тем не менее для каждого ИТ-сервиса должна быть рассмотрена такая возможность.

? Возврат к ручной (на основе бумажных носителей) системе – этот способ обычно не подходит для услуг, критически важных для бизнеса, поскольку трудно найти достаточное количество пер­сонала, имеющего опыт работы с традиционными системами. Более того, бумажные системы, существовавшие в прошлом, теперь могут уже не существовать. Тем не менее такие системы можно использовать для менее важных, второстепенных услуг. Большинство планов восстановления включают в себя процедуры резервного копирования на бумажные носители. Например, способом восстановления для терминала кредитных карт может быть использование бумажных оттисков (слипов) с кредитных карт.

? Взаимные соглашения – этот способ можно использовать в том случае, когда две организации ис­пользуют одинаковое аппаратное обеспечение и между ними существует договоренность о предос­тавлении друг другу необходимых устройств в случае возникновения чрезвычайных обстоятельств. Для данного способа две бизнес-структуры должны заключить соглашение и координи­ровать все изменения, с тем, чтобы сохранить взаимозаменяемость двух сред. Процесс Управления Возможностями должен следить за тем, чтобы зарезервированные возможности не использова­лись для других целей или чтобы их можно было быстро освободить. В настоящее время этот спо­соб не очень привлекателен из-за роста использования онлайновых систем, таких как сети банко­матов (ATM) и онлайновые банковские системы для клиентов, т.к. эти системы должны быть до­ступны круглосуточно в течение всего времени.