Выводы по ITIL v2

Записаться

Философия модели

В ITIL v2 (IT Infrastructure Library, версия 2) отсутствуют понятия бизнес-цели (business goal), бизнес-стратегии (business strategy) и соответствия услуг этим целям. Поэтому организация и ее услуги не рассматриваются как источник выгоды для бизнеса. Они воспринимаются как нечто необходимое, но в основном как центр затрат (cost center). Аналогия: электрическое освещение или отопление офиса — без них нельзя работать, но их связь с бизнес-выгодой неочевидна. В модели говорится о затратах, а не о выгодах.

Такая философия соответствовала времени появления ITIL v2. Сейчас взгляд изменился: бизнес-стратегии и цели тоже постепенно уходят в прошлое, но в ITIL v2 нет даже их.

Понятие ИТ-услуги

В ITIL v2 ИТ-услуга (IT service) не имеет общего определения. Если прочитать всю книгу и попытаться ответить, что такое ИТ-услуга, ответа нет. Приводятся только примеры: подготовка рабочей станции к работе, заправка принтера бумагой. Более общего определения не дается. Это отражает уровень понимания конца прошлого века. Тогда можно было сказать: ИТ-услуги — это услуги, которые оказывает ИТ-департамент. По аналогии: кадровые услуги — услуги департамента управления человеческими ресурсами, финансовые услуги — финансового департамента. В ходе изучения услуги пытались классифицировать: использовали таблицу, категории пользователей и заказчиков услуг, примеры.

Следующая версия — ITIL 2011 — движется в этом направлении: услуги имеют более сложную природу. Но в ITIL v2 этого нет.

Технологическая основа и формализация процессов

Технологическая основа модели процессов — справочник, который служит спецификацией услуг: база данных управления конфигурациями (Configuration Management Database, CMDB). Она обеспечивает целостность информации: одинаковость одних и тех же данных для всех потребителей и процессов, единый взгляд на информацию.

Наиболее формализованные процессы:

• управление инцидентами (Incident Management);
• управление релизами (Release Management);
• управление финансами (Financial Management);
• управление уровнем обслуживания (Service Level Management) — здесь понятно, что должно получиться: соглашение с понятной структурой и пунктами. Это позволяет формализовать подготовку соглашения.

Другие процессы, например управление конфигурациями (Configuration Management), формализовать сложно. Он взаимодействует с корпоративными процессами, о которых ничего не известно. Поэтому в этой части ITIL v2 сильно отклоняется от традиционной референтной процессной модели. Но такова жизнь.

Краткие итоги

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

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

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