ITIL v3 на практике: lifecycle вместо процессов, и что это меняет в SLA

Клиент пришёл с нетривиальным запросом: «мы хотим внедрить ITIL v3». Не «улучшить поддержку», не «сделать SLA», а именно v3 - потому что прочитали, что это новее и правильнее, чем v2. Пришлось потратить несколько встреч не на внедрение, а на разбор того, что вообще изменилось и зачем.

Оказалось, что разговор получился полезным. Для нас тоже.

Чем v3 отличается от v2 концептуально

ITIL v2, которую большинство российских компаний знает по книжкам «Service Support» и «Service Delivery», - это набор процессов. Incident Management, Problem Management, Change Management и так далее. Процессы существуют как бы сами по себе, и компания встраивает их в свою оргструктуру как умеет.

ITIL v3 перестраивает картину вокруг жизненного цикла услуги. Пять фаз: Service Strategy, Service Design, Service Transition, Service Operation, Continual Service Improvement. Процессы никуда не делись, но теперь они привязаны к фазам цикла, а не висят отдельными блоками. Логика такая: сначала определяешь, какие услуги нужны бизнесу и зачем (Strategy), потом проектируешь их (Design), потом вводишь в эксплуатацию (Transition), потом поддерживаешь (Operation), потом улучшаешь (CSI).

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

Где это всё ломается о реальность

У клиента - средний производственный холдинг, IT-отдел из восьми человек, helpdesk на базе самописной системы заявок. Что-то похожее на Incident Management уже есть. Change Management - формально нет, но на практике есть неформальный «созвон с руководством перед изменением». Problem Management в зачатке.

Первая ловушка - каталог услуг. В ITIL v3 каталог услуг становится центральным артефактом: именно из него вырастают SLA, именно он определяет, что IT делает для бизнеса. У нашего клиента каталога не было вообще. Была устная договорённость «поддерживаем всё, что есть».

Начали составлять. Первая же итерация показала: люди из IT и люди из бизнеса называют одно и то же разными словами и ожидают разного. IT думает, что поддерживает «сервер 1С». Бизнес думает, что покупает «возможность работать в 1С без перебоев». Разница принципиальная: первое - компонент, второе - услуга. Вот где суть перехода от v2 к v3 проявляется практически.

SLA: переписывать или переосмыслять

Когда у клиента появился черновик каталога на шесть услуг (включая «корпоративная электронная почта», «доступ в интернет», «ERP-система»), встал вопрос про SLA.

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

Переход к сервисному SLA означает, что ты берёшь ответственность за услугу целиком - со всеми её зависимостями. Это и страшнее, и честнее.

Для управляемого сопровождения это вопрос не теоретический: именно так мы и работаем с клиентами - отвечаем за результат, а не за конкретное железо. Но когда это надо зафиксировать в документе в духе ITIL v3, оказывается, что нужно сначала нарисовать все зависимости услуги - Service Dependency Map - и только потом писать SLA с реалистичными обязательствами.

Карту для почтовой услуги клиента мы набросали прямо на встрече. Получилось примерно так:

Корпоративная почта
├── Exchange Server 2007 (физ. сервер)
├── Active Directory (DNS, аутентификация)
├── Хранилище (SAN, репликация)
├── Интернет-канал (провайдер А + резерв провайдер Б)
└── Антиспам-шлюз (внешний сервис)

Как только это нарисовано, сразу видно: SLA «99,5% доступности» при одном провайдере без резервирования - это разговор ни о чём. Либо надо резервирование, либо надо честно написать «доступность в рабочее время при отсутствии инцидентов на стороне провайдера» - что, конечно, звучит менее красиво.

Что реально делаем прямо сейчас

Мы договорились с клиентом на поэтапный подход:

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

Второе - пересмотр SLA под сервисную логику. Не «время реакции на заявку», а «время восстановления услуги» с учётом всех компонентов. Отдельно - SLA для критичных и некритичных услуг.

Третье - минимальный Change Management. Формализовать то, что уже есть неформально: фиксировать изменения в журнале, оценивать риски хотя бы по трёхбалльной шкале, иметь план отката. Без этого Service Transition из ITIL v3 - просто слова.

До Service Strategy и CSI мы пока не доходим - слишком большой прыжок для отдела из восьми человек. Книжки по v3 написаны для организаций с выделенными ролями, процессными менеджерами и бюджетами на трансформацию. Применять их буквально к небольшому IT-отделу - значит тратить время на документацию вместо работы.

Где это всё сейчас

Каталог услуг в черновике существует. SLA - в процессе переписывания. Клиент доволен тем, что разговор про ITIL v3 оказался не абстрактным, а привязался к конкретным проблемам, которые у него есть.

Сертификации на соответствие ITIL, разумеется, нет и не планируется - это не стандарт с аудитом, это методология. Главное, что компания начала думать об IT в категориях услуг для бизнеса, а не в категориях железа и процессов поддержки. Это и есть суть перехода.