ITIL 4 без догм: какие практики нужны в первый год внедрения ITSM, а какие подождут

Что такое ITIL, разобрано в глоссарии. Практики ITIL 4 запускают по очереди. Если коротко, с чего начать внедрение ITIL: в первый год запускают службу поддержки, запросы и инциденты, уровень услуг с минимальным каталогом, базовый контур изменений, постоянное улучшение и измерение.

Все 34 практики сразу не нужны: ITIL 4 даёт рекомендации без обязательного состава и порядка. Практики делятся на 14 общих, 17 управления услугами и 3 технического управления. Практика означает набор ресурсов для работы (люди, информация, инструменты, партнёры, процессы), а в ITIL v3 единицей был процесс.

Часть общих практик (проекты, риски, персонал, поставщики) в проекте ITSM (IT Service Management, управление ИТ-услугами) не внедряют, а стыкуют с корпоративными функциями.

По данным исследования «ITSM 2026: карта зрелости российского рынка» BPMSoft и Softline (около 40 крупных компаний, август 2026 года), инциденты автоматизировали 82% участников, CMDB (Configuration Management Database, база данных управления конфигурациями) только 26%, а 38% используют ITSM-систему лишь как Service Desk.

В начале 2026 года PeopleCert выпустила ITIL (Version 5): практик те же 34, группировка другая. Горизонты ниже это наша рабочая методика, ITIL порядка не задаёт.

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

Критерии удобно прикладывать к конкретному потоку создания ценности (value stream), например «от обращения до решения». Тогда последовательность внедрения процессов ITSM строится вокруг практик, которые этот поток задействует.

У каждого критерия есть проверочный вопрос. Ответ «да» добавляет практике балл.

· Боль бизнеса и видимость результата: заметят ли пользователи и руководство изменение в ближайший квартал?

· Зависимости между практиками: готовы ли практики, которые дают этой входные данные?

· Данные и владелец: есть ли у практики владелец с полномочиями и данные для работы?

· Текущая зрелость: что уже работает, пусть и неформально?

· Внешние требования: требуют ли практику регулятор, аудит или договор с подрядчиком сейчас?

· Трудоёмкость и готовность инструмента: можно ли запустить практику силами текущей команды и в выбранной системе?

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

Зрелость здесь оценивают коротко: что уже делается, где и кем.

Критерии продолжают два руководящих принципа ITIL 4. «Начинайте с того, где вы находитесь»: сначала описывают, как обращения обрабатываются сейчас, и сохраняют работающее. «Двигайтесь итерационно, используя обратную связь»: практику запускают в малом объёме и расширяют по итогам разбора. Так внедрение ITIL идёт короткими шагами, и каждый шаг проверяют данными.

В первый год внедряют минимальный набор практик ITIL 4: службу поддержки, управление запросами на обслуживание, инцидентами, уровнем услуг и каталогом услуг, содействие изменениям в базовом контуре, постоянное улучшение вместе с измерением и отчётностью. При службе поддержки тогда же заводят базу знаний. С этого набора стоит начинать внедрение ITIL: он даёт данные для второго года.

Какие процессы ITIL внедрять в первую очередь? Те же: в ITIL 4 процессы входят в практики. Запускают практику целиком, но в минимально жизнеспособном объёме, а не «по книге».

Это нижняя граница: то, что на старте сознательно не делают, поднимают, только если этого требует регулятор или аудит.

С Service Desk проект и начинается: у пользователей появляется единая точка контакта, у ИТ все обращения в одной системе. Каналов на старте немного (портал, почта, телефон), главное, чтобы каждое обращение регистрировалось.

Первое управленческое решение: развести запросы на обслуживание и инциденты. Запрос означает типовую просьбу (выдать доступ, установить программу), инцидент означает сбой или деградацию услуги. У них разные сроки, исполнители и метрики. Если их смешать, отчёт по инцидентам покажет «аварии», которых не было.

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

Рядом с инцидентами появляется база решений для первой линии. С неё начинается управление знаниями (knowledge management).

Сложные модели инцидентов и многоуровневые согласования на старте не делают: им нужна статистика, которой ещё нет.

Без целевых сроков реакции и решения не понять, хорошо ли работает поддержка, поэтому они нужны уже в первый год. Управление уровнем услуг пока сводится к внутренним целевым показателям и ежемесячному отчёту. SLA (Service Level Agreement, соглашение об уровне услуг) с подразделениями оформляют позже, когда сроки стабильно выполняются.

Сроки привязаны к услугам, поэтому параллельно собирают минимальный каталог: классификатор для обращений и основу для отчётов. Ориентир: короткий перечень, например 15-30 позиций, но это пример, а не норма, всё зависит от масштаба ИТ.

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

Постоянное улучшение и измерение идут сквозными практиками: реестр улучшений, 5-7 метрик (например, доля решённых первой линией) и ежемесячный разбор.

Откладывать обе практики нельзя: без них первый год не даёт материала для второго.

На второй год переносят практики, которым нужны данные и опыт первого года: управление проблемами, конфигурациями услуг (с полным контуром содействия изменениям) и ИТ-активами, развитое управление знаниями, мониторинг и управление событиями. Релизы и развёртывание добавляют при собственной разработке. Эти процессы ITIL 4 стартуют, когда готовы их входные данные.

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

Управление конфигурациями услуг (service configuration management) запускают в связке с полным контуром изменений. CMDB нужна прежде всего для оценки влияния изменений, поэтому стоит в очереди после журнала изменений и каталога: база без потребителя данных устаревает. Для старта нужны каталог, журнал и решение, с каких услуг начинать.

Управление ИТ-активами (IT asset management, ITAM) ведёт учёт оборудования и лицензий и во втором году связывается с конфигурациями. К старту нужны ответственный за учёт и источники данных (бухгалтерия, закупки, инвентаризация).

Управление знаниями выходит за пределы базы решений: у статей появляются владельцы и регламент обновления. Готовность: базой уже пользуется первая линия.

Мониторинг и управление событиями (monitoring and event management) связывают с инцидентами, чтобы значимые события становились обращениями. Нужны работающий мониторинг и стабильная классификация.

Управление релизами (release management) и развёртыванием (deployment management) нужны при собственной разработке. Им требуется работающий контур изменений.

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

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

Оговорка: отложить практику в ITSM-проекте не значит отказаться от неё. Информационную безопасность, риски, поставщиков, проекты и персонал обычно ведут корпоративные функции. Проекту остаётся стыковка: как инциденты безопасности попадают в службу поддержки, как договоры с поставщиками связаны с уровнем услуг.

Отложенная практика переходит в работу при одном из условий:

· появилось требование регулятора, аудита или договора;

· накоплены данные, на которых она может работать;

· нашёлся владелец с полномочиями и временем;

· она стала узким местом для уже работающих практик.

Все 34 практики раскладываются по четырём статусам.

· Первый год: служба поддержки, управление запросами на обслуживание, инцидентами, уровнем услуг и каталогом услуг, содействие изменениям в базовом контуре, постоянное улучшение, измерение и отчётность, управление знаниями (с развитием во втором году).

· Второй год: управление проблемами, конфигурациями услуг, ИТ-активами, мониторинг и управление событиями, управление релизами и развёртыванием.

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

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

Итог: девять практик в первом году, шесть во втором, остальные ждут или стыкуются с корпоративными функциями. Под свою компанию карту пересобирают по критериям.

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

1. Квартал 1: служба поддержки, запросы на обслуживание, инциденты, база решений. Все обращения регистрируются в одной системе, запросы отделены от инцидентов.

2. Квартал 2: минимальный каталог услуг, уровень услуг, измерение и отчётность. Обращения классифицируются по услугам, сроки реакции и решения измеряются.

3. Квартал 3: содействие изменениям в базовом контуре, постоянное улучшение. Появляются единый журнал изменений, реестр улучшений, ежемесячный разбор.

4. Квартал 4: стабилизация первого горизонта, подготовка второго. Выполнение целевых сроков измеряется несколько месяцев подряд, назначен владелец управления проблемами.

5. Квартал 5: управление проблемами, развитие управления знаниями. Повторяющиеся инциденты разбирают как проблемы, известные ошибки попадают в базу знаний.

6. Квартал 6: управление конфигурациями услуг, полный контур содействия изменениям. Изменения по критичным услугам оценивают по связанным конфигурационным единицам.

7. Квартал 7: управление ИТ-активами, мониторинг и управление событиями. Активы связаны с конфигурациями, события мониторинга передаются в инциденты.

8. Квартал 8: релизы и развёртывание (при собственной разработке), оценка отложенных практик. Готов план третьего года по критериям приоритизации.

Каждый квартал опирается на предыдущий. Нет входных данных, значит квартал сдвигают, а практику вслепую не запускают.

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

Между горизонтами стоят контрольные точки. Ко второму году переходят, когда выполнены три условия:

9. Регистрация обращений стабильна: обращения не теряются, запросы и инциденты разделены.

10. Выполнение целевых сроков измеряется регулярно, и по отчётам принимают решения.

11. Статистики инцидентов хватает для поиска повторяющихся причин.

Не пройдена хотя бы одна точка? Тогда второй горизонт откладывают и дорабатывают первый. Это дешевле, чем запускать управление проблемами или CMDB на неполных данных.

Последовательность внедрения процессов ITSM меняется в пяти ситуациях.

· Если отрасль регулируемая или идёт аудит, раньше поднимают полный контур изменений, непрерывность услуг и стыковку с информационной безопасностью.

· Если в компании собственная разработка и DevOps, управление релизами и развёртыванием переходит в первый год вместе с изменениями.

· Если проект запускали ради учёта активов и лицензий, управление ИТ-активами входит в первый год, служба поддержки идёт параллельно в минимальном объёме.

· Если ИТ-сервис отдан на аутсорсинг, раньше идут управление поставщиками и уровнем услуг: договор с подрядчиком без измеряемых сроков не работает.

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

Критерии во всех пяти случаях прежние, меняется вес внешних требований и текущей зрелости.

Запуск всех практик разом. Ни одна не доходит до рабочего состояния. Решение: ограничить первый год минимальным набором.

Старт с CMDB. База без потребителя данных устаревает раньше, чем понадобится. Решение: строить конфигурации под контур изменений во втором году.

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

Выбор практик под возможности купленной системы. В очередь попадает то, что есть в коробке, а не то, что болит. Решение: сначала критерии и поток ценности, потом настройка инструмента.

Практика без владельца и метрик. Регламент есть, работы нет. Решение: не запускать практику, пока не назван ответственный и две-три метрики.

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

Из поэтапного запуска следует требование к инструменту: внедрение ITSM-системы должно позволять стартовать с минимального набора и добавлять практики без смены платформы. Порядок система не задаёт и проектирование процессов не заменяет.

BPMSoft «Управление ИТ-услугами» построен на low-code платформе BPMSoft. Процессы настраивают и расширяют поэтапно, без программирования; в продукте есть управление ИТ-активами и конфигурациями.

На платформе BPMSoft работает и решение ITSM box партнёра Lasmera (ГК IT Expert). Оно охватывает более 20 процессов по ITIL 4.

Запросите демонстрацию «Управления ИТ-услугами» и обсудите с нами состав процессов первого этапа.

Сравнить свою очередь с рынком поможет исследование «ITSM 2026: карта зрелости российского рынка», его можно скачать.

Практика шире процесса. В ITIL 4 она объединяет людей, информацию, технологии, партнёров и процессы, нужные для работы, а ITIL v3 строил описание вокруг процессов. Для проекта отсюда следует: вместе с процессом назначают роли и владельца, выбирают данные и настраивают инструмент, иначе практика не заработает даже при хорошем регламенте.

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

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

В типовой дорожной карте это две-три практики за квартал, причём практики первого квартала тесно связаны и идут одной волной. Точное число зависит от размера команды и объёма каждой практики. Признак перегрузки простой: практика запущена, а владельца и метрик у неё нет. В таком случае лучше сдвинуть квартал.

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

Обязательной сертификации для старта нет. Полезно, чтобы владелец ITSM-процессов и основные участники понимали словарь и логику ITIL 4, например на уровне Foundation. Сертификаты ITIL 4 PeopleCert признаёт и после выхода новой версии. Остальной команде обычно хватает внутреннего обучения по регламентам проекта и инструкций в базе знаний.

Скорее нет. В ITIL (Version 5) сохранены те же 34 практики, изменилась их группировка, а модули ITIL 4 PeopleCert планирует вывести 31.12.2027. Порядок задают зависимости между практиками и данные компании, версия публикации на него не влияет.