Несколько лет назад наша компания столкнулась с задачей организации поддержки системы SAP BI для нескольких наших постоянных клиентов. В рамках поддержки требовалось осуществлять: разбор инцидентов от пользователей системы с уровнем исполнения SLA 95% семь дней в неделю с 9-00 до 20-00 (2-я и 3-я линии обработки заявок), мониторинг и восстановление работы периодических заданий загрузки данных семь дней в неделю, 24 часа в сутки, архитектурный контроль, а также контроль качества разработок и документации при приемке нового функционала на поддержку в динамично развивающейся системе. В договоре был определен трехмесячный период стабилизации, в рамках которого целевой показатель выполнения SLA мог нарушаться без санкций к исполнителю.

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

• Сложный график доступности сервиса

Для консалтинговой компании графики 10х7 (10 часов в сутки, 7 дней в неделю) и 24х7 (24 часа в сутки, 7 дней в неделю) не является типичными. Предоставлять услуги в таком режиме ранее мы не умели. Задача организации доступности сервиса по такому графику сама по себе является сложной, даже без учета прочих проблем, связанных с поддержкой. Никто не любит работать ночью, это отрицательно сказывается на качестве жизни, мешает социализации.

• Выгорание команды

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

• Отсутствие на рынке подготовленных кадров, желающих заниматься поддержкой системы

Работа в поддержке требует тех же навыков работы с системой, что и на внедрении/развитии. Однако внедрение и развитие систем, с точки развития специалиста имеет ряд, как объективных, так и субъективных преимуществ:

• Красит резюме количеством проектов и технологий
• Позволяет участвовать в создании архитектуры, а не разбираться с уже существующими
• По какой-то причине считается, что дает больше опыта за тот же период времени по сравнению с поддержкой
• Ну и поддержка: это как-то фу-фу-фу не модно

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

Одной из главных задач, которые предстояло решить, была организация мониторинга и восстановления работоспособности ночных периодических заданий загрузки и расчета данных в ночное время. Работа высококвалифицированного специалиста в ночные часы стоит дорого, и крайне мало специалистов на рынке согласятся такую работу выполнять на постоянной основе. В первую очередь была проведена работа над оптимизацией и повышению стабильности периодических заданий. Это позволило сократить продолжительность ночных периодических заданий и сконцентрировать их в промежутке с 04-00 до 09-00. Повышение стабильности ночных процессов позволило сократить трудозатраты по восстановлению работоспособности заданий. В результате получилось драматически сократить время привлечения специалиста поддержки к мониторингу и ограничить его периодом с 07-00 до 09-00, при этом пользователи системы гарантированно получали корректные данные в системе к началу рабочего дня (10-00). Дальнейшая работа по разбору и классификации возникающих проблем позволила частично автоматизировать перезапуск ошибочно завершенных процессов, и частично описать решения проблем в подробных инструкциях. Что в свою очередь позволило привлекать на эту работу стажеров и младших специалистов, которые обращались за помощью к высококвалифицированному дежурному специалисту, только в случае если проблема новая и не описана в инструкции.

Еще одной сложностью, стала организация доступности сервиса 2-й линии обработки инцидентов в выходные и праздничные дни. Здесь компания заняла позицию предоставления команде полной свободы действий. Команда сама определила в каком режиме им было бы комфортно работать, с учетом распределения нагрузки между будними и выходными днями. Итоговым вариантом стал смешанный график работы - часть команды работала в режиме 4х4(четыре работаем с 9-00 до 20-00, четыре - отдыхаем), часть команды в привычном режиме, согласно производственному календарю. Таким образом требования к доступности сервиса с 9-00 до 20-00 семь дней в неделю были выполнены.

Вообще, по любым вопросам организации работ Компания занимала позицию предоставления Команде полной свободы действий. Ребята сами могли определить комфортные для себя условия работы и своими решениями напрямую влиять на процесс предоставления услуги. Единственным обозначенным условием был выход на целевые показатели выполнения SLA к концу периода стабилизации (3 месяца). Это позволило создать в команде комфортную атмосферу и нацеленность ребят на результат. Выполнение SLA, закрепленный в договоре, как индикатор удовлетворенности заказчика, всегда обозначался Команде единственным критерием качества сервиса и успешности работы их. Исходя из этого была принята прозрачная и понятная схема финансовой мотивации команды, с ежемесячной премиальной частью, выплата которой была завязана только на выполнение SLA сервиса, закрепленного в договоре с Заказчиком.

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

• Классификация инцидентов и разработка подробных инструкций по для специалиста 2-й линии по каждому типу инцидентов. Что позволяло снизить и время на включение нового специалиста в работу.
• Разработка стажерской программы, состоявшей из двух важнейших частей. В первой части стажер получал общие теоретические и практические навыки работы со всеми поддерживаемыми системами и продуктами. Вторая часть была нацелена на изучение документации и закрепление практических навыков на разборе типовых инцидентов, являвшихся прототипами инцидентов из продуктивной системы, с которыми стажер столкнется в первые же дни своей работы в команде.

Вторая «практическая» часть позволила еще больше сократить время включения нового участника команды. В итоге время на включение нового человека составляло один месяц стажировки и от двух до четырех недель работы в команде до того, как стажер полностью вовлекался в работу на равных с другими участниками команды.
Запуск стажерской программы позволил организовать ротацию команду полностью за счет стажеров, и не обращаться к рекрутингу людей с опытом со рынка. Плановая ротация из поддержки в консалтинг позволила избежать выгорания команды и деградации качества сервиса. А также, что немаловажно, стала источником младших специалистов, привыкших к ответственной работе, для консалтингового направления бизнеса компании.

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

Результаты в целом отличные, за три года работы ключевой показатель выполнения SLA после периода стабилизации не опускался ниже 95% ни разу. Также период стабилизации при подключении нового клиента фактически сократился с трех месяцев до одного. Также расширился технический стек поддерживаемых систем. На старте мы поддерживали хранилища данных на технологиях SAP BW на базах данных SAP HANA, визуализация на SAP Analysis и SAP Business objects. Сейчас мы расширили техническую линейку, добавив Greenplum и Clickhouse.