Меня зовут Светлана Долгополова. Я менеджер бизнес-приложений в Ингосстрахе и уже несколько лет отвечаю за сопровождение систем и сервисов, используемых в нашей компании.
Моя зона ответственности – стабильность работы сервисов на проде.
В 2025 году наша команда техподдержки столкнулась с ростом нагрузки в связи с увеличением количества поддерживаемых систем, а следовательно, и с ростом заявок.
Ниже – мой опыт участия во внедрении методов улучшения наших внутренних процессов работы с заявками и сокращения воронки обращений от пользователей.
Статья полезна для тем, кто отвечает за метрики поддержки и хотел бы их улучшить.
Управление заявками в поддержку
Моя основная задача – оптимизировать процессы взаимодействия специалистов техподдержки и пользователей на всех этапах сопровождения ПО. Расскажу подробнее, как устроена работа наших инженеров.
Как у любой команды техподдержки, у нас есть внутренние метрики и SLA (Service Level Agreement). Нам в Управлении сопровождения информационных систем (Далее – УСИС) важно, чтобы сервисы были максимально доступны, поэтому мы отслеживаем их состояние. Мы анализируем данные мониторингов и пользовательские обращения в ITSM.
В работу мы принимаем разные типы запросов: инциденты, запросы на обслуживание или на доступ и проводим консультации для пользователей. Для ответа на эти запросы у наших инженеров техподдержки есть инструменты анализа, база знаний и скрипты для решения типовых задач.
Когда бэклог обращений набирает свою критическую массу, встает вопрос сервис-менеджмента, то есть управления не только инцидентами и проблемами, но и консультациями, запросами на обслуживание, изменения и корректировки.
Трансформация процессов
Одним февральским утром 2025 года наше подразделение получило от руководства следующую информацию:
Под «кейсом» мы понимали следующее:
Кейс – это совокупность заявок, объединенных одной причиной и имеющих однотипное решение.
Пример кейса: пользователь не может самостоятельно изменить куратора договора, если сам договор находится в определенном статусе или установить взаимосвязь между договором и конкретным типом платежа через интерфейс приложения.
Для нас такая «акция» – принципиально новый вид деятельности, не похожий на наши рутинные задачи и поручения руководства. Это внутренний опыт нашей команды, который позволил нам применить нестандартные навыки исследований, координации и организации принципиально нового процесса.
Для участия в «акции», кейс должен состоять из более 10 заявок в месяц в течение 3-х месяцев (не обязательно подряд, чтобы исключить нерелевантные месяцы). Сейчас в виде исключения и с целью покрыть кейсами максимальное количество обращений, мы регистрируем и кейсы, где количество заявок ниже этого значения.
Методология
Перед нами стояла задача снизить поток обращений в поддержку и высвободить ресурсы для новых амбициозных целей: нам предстояло принять в сопровождение несколько новых сервисов без нарушения сроков SLA по нынешним и без увеличения численности инженеров.
Согласно ITIL 4, повторяющиеся инциденты с общей причиной классифицируются как Problems. Но как объединить между собой похожие консультации, заявки на корректировки, заявки на доступ?
Мы адаптировали принципы управления проблемами (Problem Management) и создали внутреннюю сущность «CASE» для систематизации не только инцидентов, но и повторяющихся запросов на обслуживание, доступ и консультаций.
Важно учесть, что обращения приходят к нам разными способами, что влияет на структуру и наполнение самой заявки. Например, заявка, оформленная на портале, придет более структурированная и будет обладать большей полнотой информации, чем заявка, пришедшая к нам по почте.
Прежде всего, мы обозначили, что точно является кейсом, а что – нет. Например, совокупность обращений, относящихся к одному массовому инциденту, вызванному ошибкой в коде или крупному техническому сбою, отдельным кейсом не считается.
Определили, как именно можно не только «вскрыть», то есть обнаружить и зафиксировать его, но и разрешить сам кейс.
Также определили условия, по которым кейс считаем решенным, и кто может заниматься решением кейсов.
Далее встал вопрос, где хранить информацию о найденном кейсе и минимизировать дублирование кейсов.
Первоначально хранили в Excel. Этот способ выбрали как наиболее простой и доступный и использовали первое время, в ожидании более удобного и проработанного инструмента
От ведения таблицы в Excel мы смогли постепенно отказаться после реализации ряда доработок в itsm системе (о них – чуть ниже).
После появления в itsm отдельной сущности «CASE» появилась возможность «привязать» к кейсу то или иное обращение пользователя. Кейс считается зафиксированным, когда карточка по этому кейсу заполнена.
Не сразу пришло понимание, что процесс заполнения карточки кейса лучше также прописать и согласовать. В противном случае, процесс поиска и фильтрации, а также решения кейсов осложнялся.
Поиск кейсов
Как найти схожие обращения в скоупе заявок от пользователей?
Каждая заявка относится к той или иной услуге, имеет критерий «критичности», классификацию (инцидент, запрос на обслуживание, консультация или доступ). В редких случаях используется набор тех или иных тегов.
Однако такой типизации недостаточно для того, чтобы находить «идентичные заявки», для которых подойдет одно решение.
Чем вообще характеризуется ИТ-поддержка в страховании? Прежде всего, узкой специализацией в области сложных бизнес-процессов, «вшитых» в наши продукты. «Вшитых» железно.
Часть инцидентов лежали на поверхности: например, львиная доля обращений, регистрируемых через наш агентский сайт, просто направлялась в Операционный Центр.
Способы поиска кейсов:
-
по отчету о выполнении: например, фильтрация по значению «выполнена корректировка» (изменение настроек в меню администратора сервиса, изменения в БД, справочниках или иное).
-
по ключевым словам, или словосочетаниям (это может быть или название справочника, конкретный e-mail, настройка или иной параметр, по которому можно однозначно отделить этот кейс от всей массы заявок), использование в поиске регулярных выражений.
-
Фильтры по конкретным пользователям – инициаторам заявки.
-
Фильтр по тексту ошибки (не всегда помогал, так как иногда ошибку можно увидеть только на скрине).
-
Фильтр по группе инженеров, решающих те или иные инциденты
В дальнейшем мы планируем делегировать поиск кейсов искусственному интеллекту.
Техническая реализация
В первоначальном варианте Excel кейс выглядел в виде строки с определенными атрибутами. После добавления в ITSM отдельного, специально выделенного для кейсов пространства, появилась возможность фиксировать кейсы, присваивать им статус, и визуализировать работу с ними.
Для того, чтобы поиск кейсов разными специалистами в одной базе заявок был максимально удобным и прозрачным, а фиксация найденного кейса сразу была заметна всему подразделению, реализовали доработку ITSM.
К имеющимся инструментам мы добавили:
-
Новую сущность «Case» с такими атрибутами, как:
– уникальный номер,
– краткое описание,
– статус,
– список связанных заявок,
– время, затраченное на обработку всех связанных заявок,
– информация о решении,
– ответственный за кейс исполнитель; -
Возможность связать каждую заявку с тем или иным кейсом;
– форма связи инцидента при редактировании уже созданного кейса выглядит так:
В строке поиска необходимо ввести номер инцидента, который хотим связать с кейсом.
-
Дашборды для визуализации найденных кейсов за последний месяц и за все время для каждого отдела и общий по всем отделам управления.
– форма добавления нового кейса теперь выглядит так:
Итоговая статистика
В результате удалось сформировать следующие дашборды:
-
Топ наиболее «затратных» кейсов. Величину трудозатрат выражали в человеко-часах путем автоматического суммирования затрат на работу с каждым отдельным обращением в поддержку:
-
Топ кейсов – лидеров по количеству обращений:
Оба дашборда реализованы как для открытых, так и для уже закрытых кейсов.
Здесь самым удивительным оказалось, что в топе по трудозатратам находились в том числе кейсы, обращения по которым приходят всего раз в месяц.
Начиная с декабря 2025 года привязка к кейсу каждой заявки в поддержку является для нас обязательной.
Так мы смогли:
-
типизировать наши обращения;
-
визуализировать временные затраты для решения обращений;
-
создать потенциал для дальнейшей оптимизации работы поддержки;
-
улучшить пользовательский путь.
Самой полезной для меня оказалась возможность оперативно оценить трудозатраты, которые тратит поддержка на закрытие заявок, относящихся к тому или иному кейсу. Такие данные существенно помогают в спорах, что дешевле: стоит ли проводить ту или иную доработку в коде или продолжить решать проблему силами поддержки.
Но пол дела – отыскать и зарегистрировать кейс. Самое главное – решить его.
В качестве решения предполагалось:
-
передать часть функциональности ответственным бизнес-пользователям;
-
сделать некую доработку, итог которой бы снизил поток обращений в поддержку по данной теме;
-
найти корневую причину появления обращений и устранить ее;
-
провести дополнительное обучение, прописать инструкции пользователям или поддержке,
-
добавить нужные подсказки на портале самообслуживание и много чего еще.
Передача рутины по обработке поступающих обращений в другое подразделение технической поддержки не считалась решением кейса.
По каким критериям можно было считать кейс решенным?
Количество заявок, относящихся к данному кейсу, должно сократиться более чем на 70% (либо совсем закрыться и не появляться) в течение следующих трех месяцев по сравнению с 3-х месячным средним количеством заявок.
Примером решенного кейса можно назвать передачу определенной группе бизнес-пользователей функции редактирования справочника, после чего запросы на корректировки в рамках данного бизнес-процесса снизились на 95% за последующие 3 месяца.
Довольно быстро мы поняли, что решение кейса не всегда может быть таким простым, как кажется. Иногда мешало нечеткое понимание зон ответственности между подразделениями, задействованными в данном кейсе, но опыта работы с этими подразделениями мы на тот момент не имели.
Эксперт по анализу и систематизации кейсов
Для того, чтобы помочь нам в навигации среди различных способов решения кейсов, а также следить за появлением возможных дублей кейсов и своевременном их закрытии, выделили конкретного ответственного, который отлично разбирался и в нашей внутренней структуре, и в ограничениях (и возможностях) нашего itsm.
На роль «эксперта по кейсам» назначили руководителя одного из наших отделов, имеющего более чем 15-летний опыт работы в поддержке наших сервисов и глубокое понимание бизнес-процессов наших страховых продуктов.
Это позволило упорядочить сами кейсы, оперативно актуализировать их статус, и главное – существенно увеличить количество закрытых кейсов (и – довольных пользователей, ведь им больше не нужно тратить время на то, чтобы писать нам в поддержку, ожидать решения,
отвечать на дополнительные вопросы и другое). Также в обязанности эксперта входит проверка, действительно тот или иной кейс можно считать решенным, верно ли он оформлен, корректен ли его статус, достаточно ли по нему информации для перевода в статус «решен».
Выводы
Эта акция действительно помогла нам выйти на новый уровень. Теперь благодаря успешному решению кейсов бизнес-пользователи могут самостоятельно загружать нужные файлы и формировать документы, не обращаясь в техподдержку, а методологи – вносить новые коды пользовательских ошибок в справочник.
Конечно, не обошлось без сложностей. Самым трудным было найти пути решения для такой нестандартной задачи, как поиск и решение кейсов. Было сложно принять тот факт, что единого алгоритма решения кейса нет. Стало ясно, что изобрести ту самую универсальную схему, которую можно использовать постоянно, невозможно в таком сложном процессе, как общее решение для разных типов обращений.
Но зато мы получили вдохновляющие отзывы коллег об успешной коллаборации различных кросс-функциональных команд в решении кейсов. И это самое ценное для нас.
Поделюсь результатами, которых мы добились через год после внедрения кейсов в работу с обращениями:
-
Обнаружили и зафиксировали кейсы более чем в 100 наших системах/сервисах.
-
Закрыли около 20 кейсов. Только по одному кейсу за 2,5 месяца и до момента закрытия самого кейса мы успели принять и отработать 252 заявки. Целевое решение данного кейса позволило впоследствии сэкономить нам более 25 часов рабочего времени ежемесячно.
-
Провели серии встреч с пользователями для повышения их уровня владения продуктами.
-
Сформировали шаблоны и обучающие инструкции для передачи части функциональности от поддержки к ответственным пользователям.
-
Отметили лидеров по числу закрытых кейсов, в том числе кейсов наиболее крупных.
Расскажите, как процесс оптимизации входящих заявок в поддержку устроен у вас?
Автор: idalia
