Главная проблема ITIL-экспертов

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

Примерно так начинается деловая игра Grab@Pizza, которую разработали в компании

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

Пару лет назад я придумал для этой игры подготовительное упражнение, которого не
было у авторов и которое я так люблю, что иногда провожу его как самостоятельное, без
собственно игры. В частности я всегда даю эту задачку будущим ITIL Expert’ам –
участникам курса ITIL Managing Across the Lifecycle, тем, кто должен видеть систему
управления ИТ-услугами не как набор процессов, но как целостный механизм,
работающий на благо бизнеса, видеть лес, а не только отдельные деревья.

Упражнение состоит из двух этапов.

Этап первый

Сначала я прошу участников представить себя на месте руководителя описанной

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

Как же это всегда бывает непросто. Чаще всего предлагается либо заключить SLA («цель:
заключить с бизнесом не менее трех SLA»), либо изменить качество конкретных услуг
(«цель: обеспечить доступность системы Sales на уровне 99,5% в месяц»). Крайне редко
мы поднимаемся над ИТ-процессами и ИТ-задачами и видим ситуацию глазами бизнеса.
И мне кажется, что именно способность увидеть работу ИТ-службы в бизнес-контексте,
понять, в чем состоит ИТ-зависимость компании, предложить решать проблемы
заказчика, а не собственные – это важнейшая характеристика хорошего ИТ-директора и
хорошего ITSM-консультанта. Мы же нередко стремимся применять ITIL, а не помогать
бизнесу.

Я не буду приводить здесь «правильных ответов» – во-первых, потому что единственно

правильного ответа не существует, а во-вторых, потому, что намерен использовать это
упражнение и дальше. Но вот метод, следуя которому, можно, как я полагаю, прийти к
хорошим вариантам применительно к вымышленной или реальной организации.
Напомню, ценность, привносимая ИТ в бизнес, может быть сведена к трем
составляющим: приносить пользу, не приносить вреда и делать это недорого. COBIT
использует более красивые формулировки: формирование выгод (benefit realization),
оптимизация рисков (risk optimization) и оптимизация ресурсов (resource optimization).

В чем могут состоять выгоды от использования ИТ в описанной выше ситуации? Каковы

главные ИТ-риски? Что такое «недорого» для конкретной организации? Сможем
сформулировать ответы на эти вопросы – получим бизнес-ориентированные цели для ИТ-
службы. Не сможем – не получим.

"Напомню, ценность, привносимая ИТ в бизнес, может быть сведена к трем

составляющим: приносить пользу, не приносить вреда и делать это недорого. COBIT
использует более красивые формулировки: формирование выгод (benefit realization),
оптимизация рисков (risk optimization) и оптимизация ресурсов (resource
optimization)"

В чем же может состоять польза от использования ИТ?

В зависимости от отрасли, в которой работает компания, ее места в конкурентной среде

внутри этой отрасли и глубины интеграции ИТ в бизнес-процессы, технологии могут:

 служить источником конкурентных преимуществ и средством трансформации

бизнес-процессов (пример: продажи услуг через мобильные приложения);
 давать возможность сократить затраты – прежде всего посредством автоматизации
отдельных операций или целых процессов (пример: электронный
документооборот);
 формировать масштабируемую инфраструктурную основу для реализации бизнес-
деятельности (пример: корпоративные системы коммуникаций – почта,
видеоконференции, порталы и пр.).

Характерно, что дополнительная (в сравнении с базовым состоянием) ценность может

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

В описанной выше ситуации основным видимым источником ценности для бизнеса

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

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

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

Мой опыт подсказывает, что сформулировать подобные цели ИТ-службе и ИТ-

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

Этап второй

Второй этап гораздо проще: теперь участники должны поставить себя на более привычное
место ИТ-директора и предложить набор процессов из арсенала ITIL (мы же на курсе),
который поддержал бы достижение поставленных бизнесом целей. А потом описать
модель взаимодействия этих процессов – так, чтобы было понятно, как будет устроена
работа ИТ-службы, направленная на поддержку бизнеса.

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

Второй частый камень преткновения – в построении модели взаимодействия. Очень

сложно рассуждать «от задач к процессам», а не «от процессов к возможностям». К тому
же оказывается, что процессы взаимосвязаны, что достижению каждой цели помогает не
один процесс, а несколько и что каждый процесс полезен для нескольких целей. В итоге
при попытке нарисовать модель взаимодействия процессов получаются паутинки, где все
связано со всем и непонятно, как все вместе работает.

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

1. Обеспечить поддержку бизнес-инициатив по преодолению кризиса (цель – 100%

необходимых изменений в ИТ реализованы полностью и вовремя).
 2. Обеспечить минимизацию потерь бизнеса из-за ИТ-инцидентов (время простоя
критичных бизнес-систем – 0 минут, потери выручки из-за ИТ-систем – 0 рублей).
3. Сумма текущих затрат на ИТ не должна превышать размера согласованного
операционного бюджета ИТ-службы, затраты должны быть прозрачными
(отчетность по согласованным статьям предоставляется в срок).

Выводы

Какие процессы управления ИТ-услугами будут наиболее полезны при решении первой
задачи? Прежде всего, это процессы управления изменениями (и релизами), уровнем
услуг. Могут пригодиться (в качестве отдельных процессов или в составе управления
уровнем услуг) и другие процессы группы «проектирование услуг». Если необходимые
для поддержки бизнес-инициатив изменения требуют создания новых или переработки
имеющихся ИТ-решений, то между проектированием и внедрением неплохо было бы
разработать или закупить эти решения. Подобная деятельность в ITIL почти не описана и
традиционно рассматривается за рамками системы управления ИТ-услугами, но с
практической точки зрения предусмотреть управление этой работой или же руководство
поставщиками, создающими ИТ-решения, необходимо.

В зависимости от охвата системы управления услугами и роли процесса управления

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

Рисунок 1. Взаимодействие процессов при решении задачи поддержки бизнес-инициатив

(вариант – «ITSM в пределах среды эксплуатации»)

Рисунок 2. Взаимодействие процессов при решении задачи поддержки бизнес-инициатив

(вариант – «ITSM для полного жизненного цикла ИТ-решений»)

Вторая задача – минимизация потерь – решается прежде всего с помощью управления

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

Рисунок 3. Взаимодействие процессов при решении задачи минимизации потерь бизнеса

(вариант без управления проблемами)

Рисунок 4. Взаимодействие процессов при решении задачи минимизации потерь бизнеса

(вариант с управлением проблемами)

При решении обеих задач многое зависит от эффективного управления изменениями и

релизами – планирования, координации и реализации изменений в среде эксплуатации. На
реализацию «своих» изменений точно в срок, а в некоторых случаях – как можно быстрее
претендуют и процессы проектирования услуг, и процессы поддержки и эксплуатации. И
ведь мы еще не ставили перед своей организацией задачу постоянно совершенствовать
услуги, а это неминуемо станет еще одним источником запросов на изменения.
Упрощенно взаимодействие двух контуров управления – «поддержка бизнес-инициатив»
и «минимизация потерь» – можно представить на рисунке 5.
Рисунок 5. Взаимодействие двух контуров управления – «поддержка бизнес-инициатив» и
«минимизация потерь»

Наконец, задача ограничения и прозрачности затрат требует реализации практик

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

Информация о затратах часто интересует бизнес-руководство не в разрезе таких статей,

как «ПО» и «Оборудование», и даже не в разрезе услуг. В рамках рассматриваемой
бизнес-ситуации руководителей прежде всего волнует стоимость достижения каждой из
поставленных перед ИТ-службой целей: удается ли поддерживать бизнес-инициативы в
рамках тех средств, что согласованы для каждой из них? Не превышает ли стоимость
минимизации потерь выделенных на эти цели сумм (а заодно и самих предотвращаемых
потерь)?

Рисунок 6. Сбор данных о затратах на поддержку ИТ-услуг и внедрение

новых/изменяемых услуг и предоставление информации о затратах и исполнении
бюджета ИТ

"Чтобы реализоваться в полной мере, необходимо стать экспертом в поддержке

бизнеса заказчиков, учиться видеть работу ИТ-службы в бизнес-контексте" 

Приведенные здесь формулировки целей и иллюстрации взаимодействия процессов

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

Роман Журавлев (r.jouravlev@cleverics.ru)