2. Постоянное улучшение в ITIL: как поставить процесс на поток

Суть Continual Improvement в ITIL 4

Это практика, которая отвечает за непрерывный процесс улучшения в команде. Вот тебе жизненная ситуация: ты видишь проблему, придумываешь решение, внедряешь его. Через месяц всё откатывается к старому. Знакомо? А теперь представь, что у тебя есть система, которая не даёт откатиться назад и постоянно ищет новые косяки для исправления.

Вместо хаотичных попыток “а давайте вот это исправим” у тебя появляется система, которая:

• Сама находит, что нужно улучшать (по данным, а не по настроению)
• Приоритизирует улучшения по реальной пользе
• Следит, чтобы изменения не откатились через месяц
• Превращает улучшения в культуру, а не в разовые акции

Зачем тебе это? Потому что разница между “я улучшил процесс” и “у нас культура постоянных улучшений” – это как разница между тем, чтобы один раз убраться дома и поддерживать порядок постоянно.

Если хочешь, чтобы твоя команда становилась лучше каждый день, а не только когда у тебя есть настроение что-то исправить – читай дальше.

Проще понять на примере:

У тебя служба поддержки отвечает на тикеты в среднем за 2 дня. Пользователи недовольны.

Без Continual Improvement: 
Ну да, медленно, но что поделать, работы много. 300 заявок в месяц. Жи есть.

С Continual Improvement:

• Анализируешь: где процесс зависает больше всего? (много тикетов висит в очереди в ождании уточнений от пользователей)
• Находишь решение: завести портал, который позволят пользователям выбирать тип проблем и сразу заполнить доп. поля по ней, чтоб ускорить процесс решения
• Внедряешь изменение
• Измеряешь: время ответа сократилось в два раза
• Ищешь следующее узкое место

Какие проблемы решает этот подход?

1. Эффект “Дня сурка” 🔄
   Когда команда наступает на одни и те же грабли из года в год, и все уже привыкли, что “так у нас заведено”. Например, каждый релиз – это ад, но никто не пытается сделать процесс лучше.
2. Синдром “Потому что так надо” 🤷‍♂️
   Когда на вопрос “почему мы делаем это именно так?” отвечают “потому что так надо” или “так всегда делали”. И никто не помнит, зачем вообще этот процесс придумали.
3. Эффект “Лебедь, рак и щука” 🦢🦀🐟
   Когда каждый отдел тянет одеяло на себя, оптимизирует свои метрики, а в результате команда как целое не становится эффективнее.
4. Синдром “Мы внедрили Agile/ITIL/DevOps и всё” 📚
   Когда методологии превращаются в религию, а не в инструмент. Внедрили – забили забыли.
5. Эффект “Тушения пожаров” 🔥
   Когда все ресурсы уходят на решение срочных проблем, и никогда не доходят руки до системных улучшений, которые предотвратили бы эти пожары.

Когда пора этим заняться?

Если у тебя стартап из трех человек, которые пилят первую версию продукта – можешь забить.
Но пора задуматься о постоянном улучшении, если:

• Ты замечаешь, что одни и те же проблемы возникают снова и снова
• Сотрудники выгорают и уходят, потому что “задолбало это дерьмо”
• Клиенты жалуются на одно и то же месяцами, а воз и ныне там
• Конкуренты внедряют новые фишки за недели, а у вас на это уходят месяцы
• Все процессы вроде как есть на бумаге, но по факту все делают как получится

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

Как это обычно работает на практике

Вот тебе пошаговая инструкция для чайников:

Ключевая модель: 7-Step Improvement Process

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

Шаг 1: Определи, что улучшать

• Смотри на бизнес-цели компании (если не знаешь их – спроси у CEO)
• Найди процессы, которые мешают достижению этих целей
• Выбери 1-3 направления (не больше, иначе распылишься)

Шаг 2: Определи, что измерять

• Для каждого направления выбери 2-3 конкретные метрики
• Метрики должны быть понятными и связанными с бизнесом
• Пример: не “улучшить поддержку”, а “сократить время ответа с 2 дней до 4 часов

Шаг 3: Собери данные

• Настрой автоматический сбор (где возможно)
• Зафиксируй текущие значения – это твоя точка отсчета
• Не забудь про мнения людей: опросы, интервью, жалобы

Шаг 4: Обработай данные

• Очисти от ошибок
• Сделай данные понятными: графики, таблицы
• Найди закономерности и аномалии

Шаг 5: Проанализируй информацию

• Ищи корневые причины, а не симптомы
• Используй “5 почему”: почему произошла проблема? А почему это? А почему то?
• Определи, какие изменения дадут максимальный эффект

Шаг 6: Докажи необходимость изменений

• Подготовь простые и понятные отчеты
• Покажи, сколько денег/времени/нервов сэкономят улучшения
• Получи одобрение руководства на внедрение

Шаг 7: Внедри улучшение

• Начни с небольшого пилота
• Измеряй результаты и корректируй подход
• Если работает – масштабируй на всю компанию
• Если не работает – анализируй и пробуй по-другому

Главное: это цикл, а не линейный процесс.

Как внедрить это?

Шаг 1: Подготовка

• Заручись поддержкой руководства (без этого все бессмысленно)
• Выбери, кто будет отвечать за улучшения (скорее всего это ты)
• Определи 1-2 ключевые метрики, которые хочешь улучшить
• Проведи базовый аудит текущего состояния (чтобы было с чем сравнивать)

Шаг 2: Пилот

• Выбери один процесс для пилота
• Собери команду энтузиастов (важно: не назначай людей насильно)
• Проведи серию воркшопов по выявлению проблем и генерации идей
• Выбери 1-2 идеи с быстрой отдачей и внедри их
• Измерь результат и не забудь рассказать кто тут молодец

Шаг 3: Масштабирование

• Создай простой и понятный процесс подачи и оценки идей улучшений
• Внедри регулярные встречи по улучшениям
• Обучи менеджеров базовым инструментам (5 почему для начала самое то)
• Создай базу знаний с успешными кейсами и уроками

Шаг 4: Автоматизация

• Настрой автоматический сбор метрик теста, чтоб не страдать
• Автоматизируй всё что можно, чтоб это не выжигало ресурс

Шаг 5: Культура (постоянно)

• Внедри систему поощрения за предложенные и реализованные улучшения
• Регулярно рассказывай истории успешного успеха на всю компанию
• В идеале – включи метрики по улучшениям в KPI

⚠️ Как обычно все идёт не по плану

Ошибка 1: Давайте соберем все идеи и ничего не сделаем

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

Как починить: Внедряй правило: каждая идея должна получить обратную связь в течение недели. И хотя бы 10% идей должны превращаться в реальные изменения.

Ошибка 2: Улучшение = сокращение затрат

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

Как починить: Балансируй. На каждую метрику эффективности должна быть метрика качества и удовлетворенности (клиентов или сотрудников).

Ошибка 3: Мы внедрили Agile/ITIL/DevOps и теперь всё само улучшится

Компании внедряют методологии, но не меняют культуру и мышление людей.

Как починить: Помни, что методология – это инструмент, а не серебряная пуля. Фокусируйся на изменении мышления и культуры, а не на формальном внедрении процессов.

Ошибка 4: Улучшения – это проект с дедлайном

Компании запускают программу улучшений как проект с началом и концом. Через полгода все забывают про улучшения и возвращаются к старым привычкам.

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

Ошибка 5: Мы не можем позволить себе улучшения, у нас и так дедлайны горят

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

Как починить: Выдели фиксированное время на улучшения (например, 10% рабочего времени или один день в две недели). И защищай это время любой ценой.

Заключение

Continual Improvement – это не про внедрение модных методологий и не про красивые презентации для руководства. Это про создание культуры, в которой каждый сотрудник каждый день думает: Как я могу сделать это лучше?

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