Главная проблема ITIL Expert'ов

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

Примерно так начинается деловая игра 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

В зависимости от охвата системы управления услугами и роли процесса управления изменениями упрощённая¹ схема взаимодействия перечисленных процессов может выглядеть примерно так:

Рисунок 1. Взаимодействие процессов при решении задачи поддержки бизнес-инициатив (вариант а – «ITSM в пределах среды эксплуатации»)

Рисунок 2. Взаимодействие процессов при решении задачи поддержки бизнес-инициатив (вариант а – «ITSM для полного жизненного цикла ИТ-решений»)

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

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

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

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

Рисунок 5. Взаимодействие двух контуров управления – «поддержка бизнес-инициатив» и «минимизация потерь»

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

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

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

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

Сноски

1. Подробнее о вариантах реализации ITSM-процессов и влиянии охвата системы управления услугами на дизайн отдельных процессов см. статью Дмитрия Исайченко «Управление уровнем ИТ-услуг. Часть 2. Каталог ИТ-услуг и процессы»