IT ManagerИТ в бизнесеУправление

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

Александр Башкиров | 23.04.2019

Как внедрить 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-проектов, включая два больших) говорит о том, что даже на крупных и очень крупных проектах внедряются далеко не все базовые процессы. Чаще всего важно определить тот необходимый и достаточный минимум, который даст гарантированный результат для бизнеса, одновременно с этим, не увеличивая на него финансовую нагрузку.


ITIL

Горячие темы: Бизнес в цифре

Журнал: Журнал IT-Manager [№ 04/2019], Подписка на журналы


Поделиться:

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Также по теме

Другие материалы рубрики

Мысли вслух

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

Компании сообщают

Мероприятия