Привет, Хабр! Меня зовут Дима, я руковожу отделом информационных технологий бэк-офиса в “Петрович-Тех”. Мы разрабатываем ИТ-решения для Петровича, крупного федерального ретейлера в сегменте DIY и строительных товаров.

За последние несколько лет компания существенно выросла (в продажах – в 10 раз за 10 лет, до 119 миллиардов рублей без НДС в 2022). Требования к надежности и стабильности ИТ — росли соответственно. 

Наверное, каждый из вас сталкивался с ситуацией, когда ИТ-сервис был недоступен в самый неподходящий момент. Чтобы не ходить далеко за примерами: такое случается даже с распространенными коробочными решениями уровня “практически индустриальный стандарт”, вроде JIRA или Confluence. 

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

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

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

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

В чем конкретно проблема с непрозрачностью

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

Например, 1С помогает оформлять заказы покупателей, ИТ-система управления шлагбаумом помогает ограничить доступ на склад – и то, и другое будет попадать под определение ИТ-сервиса в контексте этой статьи.

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

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

В результате получается, что бизнес имеет завышенные и нереалистичные ожидания («у наших сервисов должна быть доступность 100% и ни минуты даунтайма!»), а коллеги из ИТ живут в ситуации, когда от них ждут невыполнимых результатов, ими постоянно недовольны.

Казалось бы, тут все понятно, о чем вообще разговор? Надо просто договориться, получить от бизнеса требования к качеству, а от ИТ — реалистичную оценку и возможность этим требованиям соответствовать. Концептуально – да, но на деле – возникает масса неочевидных нюансов. Давайте разбираться вместе.

Пилотный проект

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

В литературе это называется «процесс управления уровнем сервиса». На начальном этапе нужно сделать две вещи – определить целевой и фактический уровень. А потом уже можно сравнивать требования и текущие положение дел; формировать план по достижению желаемых показателей.

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

У нас в компании есть понятие “строительный торговый центр” (далее просто СТЦ) – это основной бизнес-юнит в ретейле. Также в компании очень важную роль играет Контакт-центр (КЦ). Мы решили пилотировать проект на одном СТЦ и КЦ.

План был такой:

• Внимательно исследуем наши ИТ-сервисы, с которыми работают в СТЦ и КЦ. Фиксируем список используемого, ранжируем важность для бизнеса.

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

• В процессе дорабатываем и внедряем инструменты контроля — например, сбалансированную систему показателей (BSC), где можно мониторить динамику и исполняемость требований.

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

• В финале – разрабатываем план, как это все внедрять дальше на всю компанию.

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

Теперь — к деталям.

Разбираемся на примерах

Чтобы понять, что измерять и какие целевые показатели реалистичны, давайте взглянем на наш каталог в поддержке. У нас есть сервисы (например, «Услуга печати»), они делятся на компоненты («Подключение и настройка оборудования для печати», «Проблемы с оргтехникой») и ИТ-функции («Принтер», «МФУ»).

Для СТЦ каталог состоит из 17 ИТ-сервисов, которые делятся на 33 компонента, а те, в свою очередь, еще на 33 ИТ-функции.

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

На момент запуска пилотного проекта, мы договорились на целевое значение для всех сервисов на СТЦ – 80%. То есть время реакции не должно превысить заданный показатель более, чем на 20% (в каждом случае – свое значение).

Поначалу тут возникала сложность с ожиданиями от бизнеса: на старте пришлось объяснять, «а почему не все ИТ-проблемы чинятся за 5 минут». Нам помог подход «покажи реальную ситуацию». 

Например, в некоторых СТЦ есть один ИТ-специалист, и он физически не может решить моментально все проблемы. На деле в диалоге с руководителем пилотного СТЦ оказалось, что время решения не так важно, как время реакции — бизнес понимал, что если мы возьмем задачу в работу, то сделаем (рано или поздно). А вот если не возьмем, это может стать проблемой. Поэтому тут KPI — это время реакции на инцидент.

Для примера, есть ИТ-функция «Проводная сеть» — это локальная сеть для сотрудников и терминалов. Целевое время реакции на проблему там составляет не более 30 минут, а время решения — не более 4 часов. Все это — с понедельника по пятницу, с 8:00 до 17:00.

Откуда взялись такие цифры? Бизнес, конечно, хотел бы 0% даунтайма для любого оборудования, но это физические устройства, и иногда они ломаются, выключаются. От момента обнаружения инцидента до реакции время должно быть меньше 30 минут — это реалистичный показатель, к тому моменту мы так уже делали. А вот показатель «время на решение» — уже до 4 часов. Это не много, если учитывать, что иногда уходит значительный объем времени на поиск причины, сетевое оборудование может выйти из строя и приходится его заменять на физическом уровне.

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

Завершающим этапом в пилотном проекте мы назначили ответственных за целевые показатели в ИТ.

Пилот завершен, что дальше

Сначала мы попробовали подход на пилотных СТЦ и в КЦ, потом распространили на все СТЦ в Москве, сейчас масштабируемся на Санкт-Петербург и Северо-Западный федеральный округ. У нас стало заметно больше вовлеченных людей — руководители СТЦ подключаются к процессу, присоединяются к диалогу, помогают развивать систему. Сейчас на СТЦ уровень сервиса выполняется на 94%.

Мы заручились поддержкой от бизнеса и всего ИТ; смогли собрать и систематизировать довольно много данных относительно проблемных мест в поддержке и сопровождении. Сейчас у нас есть актуальные (фактические) результаты работы ИТ-поддержки, есть согласованные с коллегами из операций целевые показатели доступности, времени реакции и устранения проблемы.

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

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

Мораль истории: в любой непонятной ситуации нужно договариваться. Бизнес хочет от нас нереальных результатов – идем договариваться. Ждут, что все будет готово вчера – снова идем договариваться. Не слышат аргументы, не получается договориться – все равно идем договариваться. Чем раньше, тем лучше. Чем более конкретные договоренности, тем проще потом будет с ними жить.

Пусть с вашими договоренностями все сложится успешно! 

Расскажите в комментариях, а как у вас устроена поддержка в плане метрик — как работаете с SLA, KPI и прочими страшными словами?