Как внедрить ITIL за несколько шагов

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

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

Что такой ITIL?

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

Какие проблемы с этим связаны?

Во-первых. ITIL – библиотека большая. Одних только основных процессов порядка десяти. А если посмотреть на всю совокупность процессов, то их свыше 40 (отмечу, что подсчет ITIL-процессов тоже задача нетривиальная, особенно если считать весь объем процессов). Соответственно, редко где удается внедрить все. Скорее даже в реальном мире будет использовано 3–7 процессов, 10 – почти нигде.

Во-вторых, накладные расходы. Я сейчас не про внедрение, а про функционирование. При внедрении ITIL, как правило, требует увеличения штата. Потому что обслуживать все активности, необходимые для нормального функционирования процессов, стоит определенных денег. И если для двух-трех процессов можно обойтись «и так», то для внедрения большего количества процессов, скорее всего, понадобится увеличение штата.

В-третьих, ITIL обычно требует адаптации или «заземления». Собственно, искусство внедрения и состоит именно в том, чтобы правильно адаптировать процессы. Что значит «правильно»? Найти баланс между «чистотой» процесса и вариантом его исполнения в каждом конкретном случае. Это один из тех аспектов, за что берут деньги многочисленные ITIL-консультанты.

Напомню, что основа ITIL – это служба service desk, а основными процессами являются: 

• Процесс управления инцидентами

• Процесс управления проблемами

• Процесс управления конфигурациями

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

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

• Процесс управления уровнем услуг

• Процесс управления мощностями (емкостью)

• Процесс управления доступностью

• Процесс управления непрерывностью

• Процесс управления финансами

С чего начинается ITIL?

Однозначно, с инвентаризации. Следует выявить, какие активности есть в наличии на конкретном предприятии. Имеется ли служба service desk? Как она функционирует? Где регистрируются инциденты? Как они обрабатываются? Как выявляются проблемы? Есть ли выделенный специалист по работе с проблемами? Есть ли SLA? Выдерживаются ли они? Когда последний раз они были пересмотрены? А в предпоследний раз? Сколько инцидентов решается в соответствии со SLA? Кто заказчик процесса? Устраивает ли его текущая ситуация? 

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

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

Во-первых, бизнес склонен к завышению ожиданий. 

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

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

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

А как?

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

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

Сразу же скажу, что нет универсального рецепта для внедрения ITIL, есть некая относительно проверенная последовательность действий.

Итак

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

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

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

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

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

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

SLA и дальше в лес?

Далее есть смысл рассматривать внедрение процесса управления уровнем услуг – теперь к нему почти все готово. Как его внедрять? Для начала составить каталог услуг, которые ИТ предоставляют бизнесу. Затем по каждой услуге подписать ее параметры. И наконец, составить SLA – реально выполнимый, для чего продумать, что именно надо сделать для него выполнения. Согласовать SLA с бизнесом. И наладить его мониторинг, анализ показателей и пересмотр SLA.

На выходе этого шага мы получим каталог услуг, метрики услуг и SLA, а также средства мониторинга и анализа показателей сервиса.

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

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

На выходе мы получаем полный или частичный контроль над ИТ-финансами, заодно переместив точку отчествами за них в ИТ.

И немного экзотики…

По сути, из базовых процессов осталось четыре «не внедренных». Последовательность внедрения ITIL-процессов - прямое следствие из бизнес-задач, поэтому сложно рекомендовать ту или иную последовательность внедрения процессов - она в каждом случае будет уникальна. Рассмотрю эти процессы без какой-либо структуры, просто в порядке очередности.

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

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

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

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

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

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

И наконец, процесс управления мощностями (емкостью). Это в достаточной степени «технический» процесс, направленный на то, чтобы исключить «панические закупки» и обеспечить максимально эффективную утилизацию имеющихся ресурсов.

На выходе внедрения данного процесса появится система, в которой требуемые мощности сбалансированы и управляемы.

The End выглядит так? 

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