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

Пару лет назад я придумал для этой игры подготовительное упражнение, которого не было у авторов и которое я так люблю, что иногда провожу его как самостоятельное, без собственно игры. В частности я всегда даю эту задачку будущим 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) – директор по развитию персонала компании Cleverics