Как часто вы встречали прикладных админов которые любят заниматься решением инцидентов?

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

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

О том, как мы это делали и с какими трудностями столкнулись, мы расскажем вам в этой статье.

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

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

Традиционный процесс поддержки в Банке был построен по классической схеме и выглядел следующим образом


рис.1 Схема организации процесса сопровождения (было)

Запрос проходил через первую, вторую и третью линии поддержки, распределялась между ними в следующих пропорциях: 15:75:10.

Первая линия — Service Desk — прием, обработка, маршрутизация обращений с использованием следующих каналов коммуникации:

• телефон — 8% от всего количества обращений
  портал самообслуживания — 83% от всего количества обращений
  электронная почта — 4% от всего количества обращений
  чат-бот в Viber и Telegram — 5 % от всего количества

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

Вторая линия — команды сопровождения прикладного ПО + инфраструктура + DBA + …,

Третья линия — это команды разработки.

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

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

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

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

В целях минимизации времени решения инцидентов, как пилотный проект, мы решили создать кроссфункциональную объединенную команду из сотрудников первой и второй линии для решения инцидентов в фронт системах Банка – интернет-банк, мобильный банк, сервисы отправки сообщений (sms и push) + основная фронт — офисная система Банка.

Эта команда является промежуточной между первой и второй линиями — полуторная линия поддержки, которую мы назвали “Frontline”.

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

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

Местом локации «Frontline» стал ИТ-Центр Банка в городе Обнинск.

Первый состав команды полуторной линии поддержки выглядел следующим образом:

• два сотрудника первой линии поддержки
• два сотрудника группы сопровождения фронт-офисной системы
• два сотрудника группы сопровождения Интернет-банка и мобильного банка
• один сотрудник группы сопровождения сервисов информирования клиентов (sms & push)

Основной фокус команды был сконцентрирован на 3-х показателях:

• СКОРОСТЬ — 70% запросов, поступающих в команду, необходимо решать не более чем за 8 рабочих часов
• КОЛИЧЕСТВО — команда может маршрутизировать на вторую линию поддержки не более 20% запросов
• КАЧЕСТВО — доля переоткрытых пользователями инцидентов не должна быть более 3%

рис. 2 Процесс обработки инцидентов с участием Frontline

Следующая трудность, с которой мы столкнулись в начале пилота, это — отсутствие команды в изначальном нашем ее понимании, при ее наличии.

Несмотря на то, что сотрудники «Frontline» находились рядом в одном помещении, попыток перехода к кроссфункциональности, обмена опытом, значительного взаимодействия внутри не возникало. Каждый участник, как и ранее, был сосредоточен на решении запросов по своей системе, в результате — кто-то был “завален” инцидентами, кто — то был явно более свободен.

Было решено «поменять системы» внутри команды, например, чтобы представитель сопровождения Интернет-банка больше не решал инциденты по своей системе, а начал обрабатывать запросы по фронт офисной системе, а представитель сопровождения фронт-офисной системы стал решать инциденты по сервисам оповещения и т.д.

Зачем?

1. Попытаться прийти к универсальности, чтобы сотрудники могли переключаться между инцидентами разных систем, тем самым распределяя равномерно нагрузку на всех участников;
2. Наделить ребят достаточными знаниями по смежным системам, которые помогут им быстрее выявлять причину возникновения интеграционной ошибки;
3. Наладить коммуникации внутри команды;

Сделали необходимые учетные записи, предоставили достпы к логам приложений и баз данных, и вперед! :)

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

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

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


рис.3 Дашборд эффективности Frontline

Здесь нужно сказать отдельное «спасибо» руководителю команды сопровождения фронт-офисной системы Банка, который взял на себя функции лидера и культивировал развитие командны изнутри — Алексей, спасибо! :)

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

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


рис.4 Пилотный проект Frontline, первые показатели

Очень скоро стало понятно, что пилот успешно “взлетел”, и целесообразно проект масштабировать.

Постепенно, мы начали добавлять в команду компетенции по другим системам, выводить сотрудников второй линии и добавлять сотрудников из Service Desk.

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


рис. 4 Сравнительная статистика за 2018 год по времени решения запросов между Frontline и командами сопровождения второй линии

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

Для второй линии поддержки «Frontline» сегодня — это надежный «щит», который значительно снижает поток обращений приходящий к ним.


рис.5 Количество и доля инцидентов решенных во «Frontline» (на рис. — Team1) по отношению к инцидентам, решенным на второй линии по всем системам Банка

Сегодня все участники «Frontline» — это сотрудники из Service Desk, которые решают инциденты по основным фронт системам Банка, выдерживая заданные целевые показатели.

Так же «Frontline» — это следующая ступень для сотрудников Service Desk в нашей карьерной лестнице, перед переходом на вторую линию поддержки.