Как мы делали поддержку прозрачнее для бизнеса с помощью сервисного подхода
Привет, Хабр! Меня зовут Дима, я руковожу отделом информационных технологий бэк-офиса в «Петрович-Тех». Мы разрабатываем ИТ-решения для Петровича, крупного федерального ретейлера в сегменте 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 и прочими страшными словами?
