Многие считают ITIL (Information Technology Infrastructure Library) устаревшим набором практик, которые не работают на современных процессах. Опыт «Петрович-ТЕХа» доказывает обратное.

Привет, Хабр! Меня зовут Антон Скутин и я business relationship & service level manager в «Петрович-ТЕХ». Вырос из специалиста техподдержки в лида направления качества и сервиса, в компании уже шесть лет, веду телеграм-канал BRM о своей работе. Расскажу про опыт, как мы в «Петрович-ТЕХ» внедрили ITIL и получили реальный профит. В процессе роста компании мы выделили три временных этапа внедрения ITIL-практик.

Статья написана по мотивам моего доклада для конференции DevOps Conf.

Как мы начинали внедрение ITIL

«Петрович-ТЕХ» — основной цифровой партнёр строительного торгового дома «Петрович». Мы делаем для компании все сервисы, в том числе сайт, цифровые шоурумы и инфраструктуру для работы бэк-офиса. Всего у нас 16 продуктовых команд и больше 370 человек в штате, из которых половина — инженеры.

За восемь лет мы стали командой, которая обслуживает более 50 сервисов. Нас 120 человек и 7 отделов, появились кросс-командные взаимодействия, процессы усложнились и разрослись. Пришло время проанализировать и оптимизировать процессы.

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

Это было то, что нам нужно — и мы начали внедрение.

Что было на старте внедрения ITIL у нас с «Петровичем»:

• много офлайн-магазинов

• клиенты - как физлица, так и юрлица 

• множество сложных монолитных сервисов в продакшене, которые нужно было поддерживать.

Для нас клиент — это не только покупатель с сайта, но и сотрудник «Петровича», который принимает деньги в магазине, так как качество его работы в конечном счете влияет на доходы компании. А качество работы обеспечивается тем, что сотрудникам комфортно, у них всё открывается, чеки пробиваются, компьютеры не тормозят и так далее.

Поддержка

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

На старте мы осознанно последовательно ввели набор метрик по текущим продуктам и услугам, чтобы разобраться, эффективно ли работаем c сервисами в продакшне. Определили ключевые метрики:

• Время взятия в работу: как быстро мы откликаемся на запрос о помощи.

• Время закрытия: за сколько мы помогаем конечному пользователю.

• Удовлетворенность (CSAT).

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

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

Метрики, которые мы взяли на старте, до сих пор существуют:

• Время взятия в работу — 15 секунд (целевое значение по достижению этой метрики — 80%, то есть 80% обращений должны браться в работу за 15 или менее секунд). Метрика оценивает скорость, с которой обращение попадает в обработку 1 линией.

• Время обработки заявки первой линией — не более 10 минут (80% заявок должно решаться в пределах этого времени).

• Количество решённых вопросов от общего числа поступающих на первую линию — 60%. Это значит, что 40% входящих обращений первая линия превратит в заявки на следующие линии техподдержки.

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

Мы написали инструкцию, по которой на первой линии проверяют работу, сделали базу знаний. В результате первая линия за 10 минут решает вопрос. Здорово! Здорово же?

С точки зрения метрик не всё так однозначно. Давайте разберемся, какие изменения мы прогнозировали и что получилось на самом деле. 

Метрика очереди в 15 секунд — выросла с 67% до 82%, то есть отвечать на заявки быстро первая линия научилась.

Метрика времени обработки в 10 минут: на старте 100%, снизилась до 84%, так как при запуске первой линии поступали более простые обращения. Целевое значение мы закладывали на 80%, ведь предполагали повышение сложности запросов. 

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

Поэтому удовлетворённость (CSAT) у нас упала с почти 100% на старте до 90%. Эта метрика находится в красной зоне, мы работаем над ее улучшением.

Количество решённых вопросов тоже снизилось с 98% до 63%. Мы не случайно поставили цель в 60%, потому что понимали: популярность первой линии начнёт расти, и туда будут приходить нецелевые запросы. Людям стало удобно звонить на один номер или обращаться через единую форму заявки на портале, выросло число нецелевых обращений.

Неожиданным для нас оказалось то, как быстро сотрудники первой линии растут и переходят на новые позиции.

Процесс управления доступностью

Инциденты разобрали, но с поломками можно и нужно работать системно.

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

На этом этапе целью было показать топ-менеджменту самые горячие точки и причины сбоев. Мы измеряли и демонстрировали бизнесу среднюю длительность сбоя и перечень проблем, требовавших инвестиций для их решения. Пока не могли предсказать проблемы и решить их заранее, но могли “заготовить вёдра с водой”, чтобы в случае пожара оперативно его потушить.

Внутренние бизнес-показатели продающих подразделений СТД «Петровича» сильно зависели от доступности систем, поэтому бизнес собирал статистику по сбоям в 2020−2021 годах. 

С конца 2021 года мы в ИТ стали сами измерять доступность, добавлять наши системы и сервисы, обкладывать их метриками, настраивать мониторинг. На этом этапе мы только считали количество сбоев.

За счет построения инцидент-менеджмента к нам начало поступать большое количество обращений. 

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

И мы отправились в problem-менеджмент, чтобы решать вопросы системно.

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

На этом этапе появились новые метрики:

• Количество повторяющихся инцидентов

• Время на их поиск и устранение

• Количество открытых проблем

  

После запуска problem-management за 2 месяца мы обнаружили и решили первую системную проблему. К концу 2024 года нашли уже 37 проблем, которые решили или продолжаем решать сейчас.

Service level & service catalog management

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

А для этого, согласно следующему шагу в ITIL, мы должны найти общий язык метрик. Мы пошли в процессы управления уровнем сервиса и разработали каталог с услугами, которые ИТ-департамент, предоставляет бизнесу.

Service Catalog Management мы применили иначе, чем рекомендует ITIL. В классической модели ITIL SLA заключаются на каждый отдельный сервис — например, «электронная почта», «VPN», «CRM». Мы же сделали акцент не на сервисах, а на бизнес-подразделениях как на ключевых потребителях. Первым пилотным соглашение мы подписали с продающими подразделениями, затем подключили финансовый, юридический департаменты, оптовый отдел и другие. Таким образом, SLA у нас фиксируют обязательства по отношению к конкретным бизнес-командам, а не только к отдельным сервисам.

На этом этапе мы начали следить за тем, как выполняем договоренности с бизнес-заказчиками.

Сейчас подписано 37 SLA с бизнесом, и эта цифра продолжает расти.

Коротко о том, что прописываем в этих договорах, на иллюстрации ниже.

Как мы работаем с ITIL в 2025 году

Фокус на причинах инцидентов

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

Процесс управления уровнем сервиса: на примерах

Мы масштабируем service level management на все сервисы для бизнес-заказчика.

За два года (2023-2024) мы доросли до соблюдения 97% договоренностей с контакт-центром: ключевым продающим подразделением, с которого начинали запуск SLA.

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

Второе по важности продающее подразделение — это строительные торговые центры.

Здесь с запуска в 2023 году мы на 25% повысили уровень сервиса, пока есть слабые зоны.

Про эффект арбуза

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

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

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

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

Под стратегические коммуникации и работу с руководителями “в поле” мы, по ITIL, выделили отдельную роль Business Relationship Manager (BRM). В текущий момент её занимаю я. В других компаниях эта роль может быть интегрирована в, например, в IT бизнес-партнеров или аналитиков. Эта роль, по сути, сервис «одного окна» для топ-менеджеров, где важна скорость реакции, простота доступа к «кому-то в ИТ, кто поймет, в чем проблема»,  умение прогнозировать запрос и поддерживать безбарьерную коммуникацию между бизнесом и ИТ.

Мы видим результаты уже сегодня и продолжаем двигаться вперед.

Промежуточные результаты

Бизнес, увидев количество метрик, попросил выделить ключевые. Теперь основные метрики «Петрович-ТЕХа»:

• Уровень сервиса.

• Доступность бизнес-процессов.

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

У нас появилась линия поддержки 24/7. Так служба оперативного реагирования и мониторинга, если не может что-то сделать, знает, куда обратиться даже ночью или выходные. И, конечно, мы выстроили систему онбординга и мотивации сотрудников.

Начали «бить» в причины сбоев, искать первопричины, подключили RCA, использовали «5 почему», диаграмму Исикавы и так далее. Мы не навязывали определённую методологию, а советовали ответственным руководителям направлений искать, как удобнее. Но если случился пожар, вторая линия поддержки фиксировала его и собирала команду для решения.

Также наблюдаем за динамикой первопричин. Здесь появляется новая метрика — повторяемость сбоя по одной и той же причине. То есть если вы устранили неисправность, то, пожалуйста, гарантируйте то, что у вас из-за этого снова не загорится.  И действительно, в 2023-2024 годах мы на 25% сократили количество сбоев по вине «Петрович-Теха».

Дисклеймер: оказалось, есть ещё сбои по вине вендора, поставщика внешних сервисов и услуг, провайдера. С этим работать сложнее. На текущем этапе нам проще и эффективнее развивать процессы внутри.

С 2023 по 2024 год нам удалось на 60% сократить среднюю продолжительность одного сбоя. На изображении выше статистика критическим по сбоям: когда покупатель не может оплатить свой заказ или когда ему не могут его доставить. Самый долгий сбой в 2024 году был 3 часа, в 2023 — 10 часов.

Новая метрика — средняя повторяемость сбоя по одной причине.

Нам удалось сократить повторяемость в среднем в три раза. В 2024 году максимальная повторяемость сбоя по одной причине — 3, то есть пока нашли, пока выстроили план, пока реализовали его, три раза может загореться по этой причине. Это уже хороший результат, но мы продолжаем дальше.

Выводы: ITIL как путь

ITIL практики нам подошли, показали результаты и эффективность. Но есть ещё множество зон, которые предстоит, проанализировать и оптимизировать. Нельзя сказать, что путь окончен.

Опыт «Петрович-Теха» показывает: ITIL — это не про бюрократию, а про понятный язык общения с бизнесом, доверие и рост зрелости всей ИТ-функции. Мы адаптировали подходы под реальность ИТ-компании, где каждый SLA и каждый сбой влияют на выручку заказчика. Это помогает ИТ становиться не центром затрат, а центром пользы.

Говорю об этом в статье и планирую говорить на конференциях :)