Язык
Про ITIL обычно вспоминают в двух ситуациях: когда нужно “навести порядок” в ITSM и когда в компании начинается очередной виток изменений — цифровизация, продуктовый подход, облака, DevOps, автоматизация, discovery/CMDB. И тогда почти неизбежно возникает вопрос: “мы сейчас на ITIL v3, а все говорят про ITIL 4 — это просто новая версия терминов или есть смысл менять подход?”
Смена версии — это не про “переписать регламенты”. Важно понять главное: ITIL v3 и ITIL 4 по-разному описывают логику управления услугами. ITIL v3 сильнее про порядок через жизненный цикл сервиса и процессную дисциплину. ITIL 4 — про управление созданием ценности как системой, где процессы остаются важными, но становятся частью более широкой картины.
ITIL v3 построен вокруг жизненного цикла сервиса. Логика понятная и линейная: есть стратегия сервиса, затем дизайн, затем переход/внедрение, потом эксплуатация и непрерывные улучшения. Для многих компаний это было и остаётся мощной рамкой, потому что помогает:
В v3 удобно учиться и удобно строить фундамент. Но проблема проявляется там, где реальная жизнь перестаёт быть “по этапам”. Сервисы развиваются постоянно, релизы становятся частыми, появляются гибридные инфраструктуры, подрядчики, облачные платформы и сложные цепочки поставки. И тогда организация всё меньше думает “на какой стадии жизненного цикла мы сейчас” и всё больше — “почему запрос превращается в результат так долго и где именно рвётся цепочка?”
ITIL 4 смещает центр тяжести: вместо “жизненного цикла” он предлагает смотреть на создание ценности и на то, как организация превращает спрос в результат через услуги. Это важно не как философия, а как практический способ управлять: не по “стадиям”, а по потокам работы (value streams).
Проще говоря, ITIL 4 помогает отвечать на вопросы другого типа:
В результате обсуждение ITSM становится менее “процессным ради процесса” и более “про результат и предсказуемость”.
Одна из ключевых изменений ITIL 4 — переход от языка “процессов” к языку практик. В ITIL v3 у многих закрепилось ощущение, что ITIL = набор процессов. В ITIL 4 процесс — это лишь часть практики. Практика шире: это способность организации делать что-то устойчиво, и она включает:
Почему это важно? Потому что в реальных внедрениях “процесс есть, а работает плохо” случается постоянно. Обычно дело не в схеме процесса, а в том, что не настроены роли, данные, интеграции или измерение результата. ITIL 4 легализует это как норму: управлять нужно не только шагами, а всей способностью.
ITIL 4 явно фиксирует четыре измерения service management. И это один из самых полезных элементов, если вы занимаетесь улучшениями или автоматизацией. Суть простая: нельзя менять только один слой системы и ожидать, что всё станет лучше. Типичные перекосы выглядят так:
Четыре измерения помогают держать баланс: люди и организация, информация и технологии, партнёры, потоки и процессы. На практике это хороший чек-лист: прежде чем “чинить” процесс или внедрять автоматизацию, вы проверяете, какие измерения проседают и где будет реальное узкое место после изменений.
Исторически многие воспринимали ITIL и Agile как конкурирующие миры: один — про контроль и регламент, второй — про скорость и гибкость. ITIL 4 гораздо спокойнее относится к реальности современной разработки и эксплуатации. Он не требует превращать ITSM в “бетон”, а предлагает управлять так, чтобы скорость не разрушала стабильность.
Здесь важно уточнение: ITIL 4 не говорит “делайте DevOps”. Он говорит: у вас могут быть разные способы работы, но вам всё равно нужна управляемость, прозрачность и воспроизводимый результат. И это снимает массу ненужных “религиозных” споров.
Если упростить, то ITIL v3 часто лучше подходит, когда вы строите базовую дисциплину: стандартизировать работу сервис-деска, описать процессы, договориться о SLA, сформировать понятную ответственность.
ITIL 4 сильнее проявляется, когда у вас такие приоритеты:
Хорошая новость: переход на ITIL 4 — это редко “переписать всё”. Обычно это смена фокуса и языка управления. Рабочая траектория выглядит так.
Сначала вы берёте 2–3 ключевых “потока” и описываете их от начала до конца. Например: “доступ → выдан доступ”, “инцидент → восстановили → предотвратили повтор”, “изменение → релиз → стабильная эксплуатация”. Цель — увидеть реальные узкие места: ожидания согласований, лишние шаги, возвраты, ручные операции, недостающие данные, слабые интеграции.
Потом вы переводите обсуждение из “правильности процесса” в “способность практики”. Вопросы становятся конкретнее: кто владеет, какие входы/выходы, какие данные должны быть живыми, какие интеграции критичны, какие метрики отражают результат. И только после этого вы решаете, что автоматизировать и как.
И параллельно вы используете идею четырёх измерений как фильтр: если улучшение упирается в данные, не спасёт ни новый регламент, ни новый инструмент. Если упирается в ответственность и роли, не спасёт даже идеальная CMDB. Баланс — это и есть “системность” ITIL 4.
Есть несколько типовых ловушек, которые делают проект дорогим и бесполезным.
Первая — переименовать процессы в практики и остановиться. Названия не создают способность.
Вторая — начать с идеального дизайна на год вперёд и без быстрых улучшений. В ITSM почти всегда выигрывает итеративный подход: улучшили один поток — получили эффект — масштабировали.
Третья — автоматизировать хаос. Если не упростить правила и не выровнять данные, инструмент просто закрепит то, что уже плохо работает.
Четвёртая — недооценить данные. Каталог услуг, база знаний, конфигурации и зависимости — это основа, без которой управление ценностью превращается в управление предположениями.
Если сказать совсем по-честному, ITIL v3 — это сильная рамка для наведения порядка через жизненный цикл и процессную дисциплину. ITIL 4 — это рамка для управления результатом через систему ценности, потоки работы и практики как устойчивые способности. Процессы никуда не исчезают — просто они перестают быть единственным центром управления.
