ITIL: управление ИТ-услугами и информационными технологиями предприятия

Формулировка «повышение эффективности» ИТ-директору ничего не даёт. Работает другое — привязка симптома к практике.

Есть и вторая причина, чисто российская. С 2024–2025 годов миграция на отечественное ПО перестала быть рекомендацией. Компании, уходящие с ServiceNow и BMC, обнаруживают неприятное: процессы существовали только внутри зарубежной платформы, в виде настроенных workflow, и нигде не описаны. Перенести нечего — приходится проектировать заново под давлением сроков. Процессная модель, описанная отдельно от платформы, — страховка от такой зависимости.

Тридцать четыре практики распределены по трём группам, и распределение это подсказывает, кто в компании за них отвечает.

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

На практике основной эффект дают шесть позиций из тридцати четырёх. И очередь важнее количества:

Попытка запустить управление конфигурациями первым — классическая причина провала: CMDB наполняется вручную, никем не используется и за полгода расходится с реальностью.

Управление инцидентами ITIL

Инцидентом считается любая ситуация, когда услуга перестала работать или стала работать хуже оговорённого — без предупреждения и не по плану. Цель у практики ровно одна, и она устроена контринтуитивно для инженера: вернуть работоспособность максимально быстро. Не разобраться, почему сломалось, и не наказать ответственного — разбираться будет соседняя практика, о ней ниже.

Маршрут обращения выглядит так. Сначала фиксация — обращение попадает в систему из любого канала, но живёт дальше только там. Затем отнесение к категории и назначение приоритета. Дальше попытка решения силами первой линии, при неудаче — передача выше с сохранением исходного времени регистрации. Финал — восстановление работы и подтверждение со стороны того, кто обратился; закрытие в одностороннем порядке лишает статистику смысла.

Приоритет определяется пересечением влияния и срочности, а не громкостью заявителя:

Формат: время реакции / время восстановления. Значения пересматриваются под конкретный бизнес.

Метрики, за которые отвечает практика: доля решённых на первой линии (FCR, ориентир для зрелой службы — 60–75%), среднее время восстановления (MTTR), доля нарушений SLA, доля повторных обращений.

Отдельно стоит разделять инциденты и запросы на обслуживание:

• «Не работает почта» — инцидент. 
• «Дайте доступ к папке» — запрос. 

Смешивание этих потоков в одной очереди — самая частая причина ложной картины по SLA: массовые типовые запросы маскируют реальные аварии.

Управление проблемами

Если инцидент — это симптом, то проблема — то, что его порождает. Работа здесь идёт по двум направлениям: разбор уже случившегося и поиск мест, которые сломаются в обозримом будущем. Завершается разбор одним из двух исходов — причину либо устраняют, либо признают неустранимой сейчас и фиксируют обходной путь в базе знаний, чтобы следующая линия поддержки не изобретала его заново.

Управление проблемами невозможно без дисциплины: нужен регулярный разбор, выделенное время инженеров и владелец, который имеет право поставить задачу разработке. Без этих трёх условий практика существует только на бумаге.

Управление изменениями ITIL

Практика, которая быстрее всех окупается в крупной инфраструктуре, потому что напрямую снижает количество аварий, вызванных собственными руками.

Изменения принято сортировать на три корзины, и попадание в правильную корзину определяет всю дальнейшую судьбу заявки:

Практический момент, который редко описывают: процент стандартных изменений — главный показатель зрелости практики. Если через CAB проходит всё подряд, комитет превращается в очередь и его начинают обходить. Здоровая пропорция — 60–70% изменений выполняются как стандартные по готовым регламентам.

Обязательный элемент — post-implementation review для обычных и аварийных изменений и календарь изменений, доступный бизнесу. Второе закрывает большинство споров вида «нас не предупредили».

ITIL конфигурация: CMDB и управление конфигурациями

Управление конфигурациями услуг отвечает на вопрос «из чего состоит услуга и что сломается, если убрать этот элемент». Инструмент — CMDB, база конфигурационных единиц (CI) и связей между ними.

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

Что отличает работающую CMDB:

• Начинают с малого. 10–15 критичных услуг и их компоненты, а не весь парк. Расширение — после того как модель начала использоваться.
• Каждый CI имеет потребителя. Если ни один процесс не читает атрибут — его не надо вести.
• Автоматическое обнаружение вместо ручного ввода. Discovery-механизмы платформы плюс интеграция с системами мониторинга и учёта.
• CMDB встроена в управление изменениями. Изменение не закрывается, пока не обновлена конфигурация. Это единственный механизм, который держит базу живой.
• Есть регулярный аудит расхождений с показателем точности данных как KPI владельца практики.

Управление уровнем услуг: каталог и SLA

Каталог услуг — документ, из-за которого разговор ИТ с финансовым директором становится возможным. В нём каждая услуга описана в терминах бизнеса, а не инфраструктуры.

Фрагмент рабочего каталога:

Ключевое правило: SLA не назначается ИТ-службой в одностороннем порядке. Он согласуется с владельцем услуги со стороны бизнеса, и вместе с ним согласуется стоимость. Доступность 99,99% вместо 99,5% — это резервирование, дежурства и деньги. Когда бизнес видит цену девятки, требования становятся реалистичными.

Под каждым SLA должны лежать OLA — внутренние соглашения между подразделениями ИТ, и договоры с подрядчиками с сопоставимыми параметрами. Если внешний SLA обещает восстановление за час, а контракт с поставщиком канала предусматривает четыре, обязательство невыполнимо по построению.

Прежде чем выбирать систему, полезно честно определить текущий уровень.

На российском рынке ITSM больше десяти заметных вендоров, рост участники оценивают в 15–20% в год. Выбор осложняется тем, что функциональные таблицы у всех выглядят одинаково.

Критерии, которые действительно различают решения:

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

1. Выгрузить фактическую статистику: какие типы заявок, какие маршруты, какие интеграции используются реально, а не заведены.
2. Описать процессы в нотации, независимой от системы. Это и есть страховка от следующей миграции.
3. Перенести исторические данные по инцидентам минимум за год — без них не восстановить статистику для управления проблемами и расчёта SLA.
4. Запускать параллельно, а не в один день. Две-три недели двойного контура дешевле, чем неделя остановки поддержки.

ELMA365 Service Desk

ELMA365 Service Desk — решение для управления обращениями и внутренними услугами компании, созданное на платформе ELMA365. Система помогает организовать единый канал взаимодействия сотрудников с ИТ-службой и другими сервисными подразделениями: от регистрации заявки до контроля её исполнения.

Платформа связана с ITIL через автоматизацию ключевых сервисных практик: обработки инцидентов, выполнения запросов, управления уровнями сервиса и изменений. Её сильная сторона — гибкость: процессы поддержки можно перестраивать под действующие регламенты компании, а не подгонять регламенты под возможности стандартного Service Desk.

Преимущества ELMA365 Service Desk:

• настройка логики заявок, ролей и маршрутов с помощью low-code-инструментов;
• автоматическое распределение обращений, напоминания и уведомления;
• контроль сроков выполнения заявок и соблюдения SLA;
• применение для ИТ-поддержки, HR-сервисов, административных и других внутренних услуг;
• интеграция с корпоративными системами и сквозными бизнес-процессами.

SimpleOne ITSM

SimpleOne ITSM — платформа для построения сервисного управления в ИТ и смежных подразделениях. Она объединяет обращения пользователей, услуги, инфраструктурные объекты и работу сервисных команд в единой системе.

Решение поддерживает ITIL-подход к управлению ИТ-услугами: позволяет формализовать работу с инцидентами, запросами пользователей, проблемами и изменениями. SimpleOne ITSM подходит компаниям, которым важно развивать сервисную модель, вести каталог услуг и контролировать влияние изменений на ИТ-инфраструктуру.

Преимущества SimpleOne ITSM:

• поддержка основных ITIL-практик в одной среде;
• личный кабинет и портал самообслуживания для сотрудников;
• создание каталога внутренних и ИТ-услуг;
• управление приоритетами, сроками реакции и сервисными соглашениями;
• работа с конфигурационными единицами и зависимостями между системами;
• отчётность по обращениям, качеству сервиса и эффективности поддержки.

Какую платформу выбрать для внедрения ITIL

Выбор зависит от того, какую задачу ставит компания. Если Service Desk должен стать частью сквозных бизнес-процессов и требует нестандартных сценариев, стоит рассмотреть ELMA365 Service Desk. Если фокус направлен на развитие полноценной ITSM-модели, управление ИТ-услугами и инфраструктурой, более подходящим вариантом может стать SimpleOne ITSM.

Ниже — типовая последовательность проекта в компании на 3–8 тысяч пользователей.

1. Экспресс-аудит (3–4 недели). Интервью с руководителями ИТ и ключевыми заказчиками, выгрузка статистики обращений, оценка зрелости, карта текущих процессов. Результат — отчёт с приоритетами и оценкой эффекта.
2. Целевая процессная модель (4–6 недель). Проектирование выбранных практик, роли и RACI, матрица приоритетов, драфт каталога услуг. Здесь же — решение по границе автоматизации.
3. Выбор платформы (3–4 недели). Формирование требований из процессной модели, а не наоборот. Демо на своих сценариях, пилот на одной услуге.
4. Настройка и интеграции (8–12 недель). Первый контур: service desk, инциденты, запросы, база знаний, портал самообслуживания.
5. Опытная эксплуатация (4–6 недель). Работа на реальном потоке, обучение линий поддержки, корректировка маршрутов и SLA по факту.
6. Второй контур (8–12 недель). Изменения, конфигурации, уровень услуг.
7. Постоянное улучшение. Ежеквартальный пересмотр метрик, расширение каталога, вынос сервисной модели за пределы ИТ.

Критичный организационный момент: у проекта должен быть заказчик уровня правления. Процессный проект меняет полномочия — кто согласует изменения, кто имеет право на приоритет P1. Без административного веса эти решения не проходят.

Сколько это стоит и как считать эффект

Стоимость складывается из трёх частей: лицензии платформы, работы по внедрению, внутренние трудозатраты. Последнюю обычно забывают, а она составляет заметную долю: команда ИТ тратит на проект 15–25% рабочего времени в течение полугода.

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

Эффект считается по трём направлениям:

1. Сокращение простоев. Эффект = (MTTR_до − MTTR_после) × количество критичных инцидентов в год × стоимость часа простоя Стоимость часа простоя берётся из выручки подразделения или из стоимости остановки производственной линии. В рознице и на производстве это самая крупная статья эффекта.
2. Снижение стоимости обработки обращения. Перевод типовых запросов на портал самообслуживания и автоматизацию снижает нагрузку на первую линию. Ориентир: 25–40% типовых обращений закрываются без участия оператора при работающей базе знаний.
3. Сокращение аварий, вызванных изменениями. После постановки контроля изменений доля инцидентов, вызванных собственными изменениями, устойчиво снижается в течение первого года — при условии, что базовое значение зафиксировано до старта. Это прямо конвертируется в первую формулу.

Метрики, которые имеет смысл выносить на уровень правления, — не количество закрытых заявок, а доступность критичных услуг, соблюдение SLA по ним и стоимость услуги на пользователя.

1. Внедрять систему вместо процессов. Автоматизация неописанного процесса даёт автоматизированный беспорядок. Сначала процессная модель, потом требования к платформе.
2. Копировать ITIL дословно. Библиотека — набор рекомендаций, а не регламент. Компания, которая внедряет все 34 практики сразу, потратит два года и получит сопротивление службы.
3. Начинать с CMDB. Управление конфигурациями требует данных и дисциплины, которые появляются на предыдущих этапах.
4. Не назначать владельцев услуг со стороны бизнеса. Без них SLA — внутренний документ ИТ, который никого не обязывает.
5. Останавливаться после запуска. Процессы, которые не пересматриваются, за год расходятся с реальностью. Практика непрерывного улучшения — не декларация, а квартальный регламент с ответственным.

Чем ITIL отличается от ITSM? 

Первое — это конкретный свод рекомендаций, второе — сама идея работать сервисно. Разница того же порядка, что между сводом знаний PMBOK и проектным управлением как дисциплиной: одно описывает, как принято делать, другое отвечает на вопрос зачем.

Сколько процессов в ITIL 4? 

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

Обязательно ли внедрять все практики? 

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

Сколько стоит внедрение ITSM-системы? 

Бюджет складывается из лицензий, работ по внедрению и внутренних трудозатрат. Для компании среднего и крупного размера стоимость внедрения процессного контура обычно сопоставима со стоимостью лицензий или превышает её. Корректную оценку даёт только аудит: она зависит от количества услуг, интеграций и юрлиц в периметре.

Как долго внедряется управление инцидентами? 

Настройка в системе — 4–8 недель. Выход на устойчивую работу с соблюдением SLA — 3–4 месяца с учётом опытной эксплуатации и обучения линий поддержки.

Нужна ли сотрудникам сертификация ITIL? 

Полезна для менеджеров процессов и руководителей сервисных подразделений — она даёт общий язык. Для инженеров линий поддержки важнее внутреннее обучение по конкретным регламентам компании. Сертификация людей не заменяет проектирование процессов.

Как связаны ITIL и ISO/IEC 20000? 

Стандарт формулирует, чему компания обязана соответствовать, чтобы получить сертификат. Библиотека подсказывает, каким образом до этого соответствия дойти. На практике порядок обычно такой: сначала выстраивают работу по ITIL, потом сверяют получившееся с требованиями стандарта и закрывают расхождения.

Совместимы ли ITIL и Agile/DevOps? 

Да — четвёртая редакция писалась уже с оглядкой на них. Механизм заранее разрешённых изменений ровно для этого и предназначен: конвейер сборки и выкладки укладывается в него без противоречий. Трение появляется не между подходами, а тогда, когда каждую выкладку тащат на еженедельное заседание комитета.

Что делать с процессами при уходе с ServiceNow или BMC? 

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

Как измерить эффект от внедрения ITIL? 

Через три показателя: сокращение времени восстановления критичных услуг, умноженное на стоимость часа простоя; снижение доли обращений, требующих участия оператора; сокращение доли инцидентов, вызванных собственными изменениями. Базовые значения нужно зафиксировать до старта проекта — иначе эффект будет недоказуем.