Поддержка пользователей в период запуска
Составляющие успешного перехода в эксплуатацию при запуске корпоративной системы управления
Каждый запуск системы поддержки бизнеса сопровождается переходным периодом, который всегда является стрессом для многочисленных пользователей системы. И подходя к моменту старта, руководитель проекта пытается заглянуть в будущее и увидеть сколько будет инцидентов, какие ресурсы потребуются, как организовать процесс, чтобы победить в столкновении пользователей с новшествами и улучшениями.
Расскажу об о показательном опыте запуска большой корпоративной системы, который можно масштабировать и ответить для себя на эти волнующие вопросы.
Мы подошли к запуску, когда система была еще весьма сырой. Не успели доделать все расширения, которых было в общей сложности около 3.5 тысяч, обучение пользователей (общее количество до 3000 человек) провели экспрессом, рассчитывая на их опыт работы в предыдущей версии системы. Тем не менее решение о запуске было принято, ибо откладывать его было слишком дорого - и с точки зрения денег, и из-за потенциальных репутационных потерь руководства.
Понимая, что проблем будет много, мы готовились к необходимости исправлять ошибки уже после запуска. Для этого была нужна сильная команда поддержки.
Понимая, что проблем будет много, мы готовились к необходимости исправлять ошибки уже после запуска. Для этого была нужна сильная команда поддержки.
Текущая служба поддержки компании состояла из 20 человек, 12 из которых - диспетчеры, работающие круглосуточно, 8 человек - в дневную смену. Задача диспетчеров - разобрать входящие инциденты и направить в нужном направлении. Остальные должны были решать вопросы по существу.
Специалисты службы поддержки привлекались на финальном этапе проекта к тестированию системы, дабы они успели с ней познакомиться. Сразу стоит сказать, что это мало помогает. Знаний, полученных в ходе обучения и тестирования для решения проблем не достаточно.
Для поддержки пользователей в переходный период сразу было запланировано участие всей проектной команды на период три месяца после запуска. Проектная команда состояла из консультантов подрядчика (35 человек) и специалистов заказчика (более 100 человек). Плюс разработчики, работающие удаленно.
Специалисты службы поддержки привлекались на финальном этапе проекта к тестированию системы, дабы они успели с ней познакомиться. Сразу стоит сказать, что это мало помогает. Знаний, полученных в ходе обучения и тестирования для решения проблем не достаточно.
Для поддержки пользователей в переходный период сразу было запланировано участие всей проектной команды на период три месяца после запуска. Проектная команда состояла из консультантов подрядчика (35 человек) и специалистов заказчика (более 100 человек). Плюс разработчики, работающие удаленно.
Вся проектная команда была разделена на функциональные группы, и диспетчеры (1ая линия поддержки) распределяли запросы на группы. Внутри группы запрос брали сначала специалисты заказчика (2ая линия) - из проектной команды или службы поддержки. Не всегда они могли решить вопрос самостоятельно и отправляли наиболее сложные случаи консультантам (3я линия). По итогам трех месяцев мы посчитали, что 60% запросов были закрыты ИТ специалистами заказчика, 30% - специалистами от бизнеса, и 10%, самых сложных - консультантами.
Половину запросов заявляли представители двух направлений Запасы и Закупки (наибольшее количество пользователей) и Бухгалтерия (в период закрытия периода).
Специалисты группы разбирали запросы из поступившего пула самостоятельно. Если бы мы поставили внутри группы регулировщика, он бы сразу стал узким местом. Запросов было очень много, и только слаженные действия команды помогли в конце концов справиться с этим валом. Руководитель группы смотрел, чтобы отдельные запросы не зависали.
Половину запросов заявляли представители двух направлений Запасы и Закупки (наибольшее количество пользователей) и Бухгалтерия (в период закрытия периода).
Специалисты группы разбирали запросы из поступившего пула самостоятельно. Если бы мы поставили внутри группы регулировщика, он бы сразу стал узким местом. Запросов было очень много, и только слаженные действия команды помогли в конце концов справиться с этим валом. Руководитель группы смотрел, чтобы отдельные запросы не зависали.
На рисунке можно видеть количество поступающих и закрытых инцидентов за день через месяц после запуска. Это был пиковый период.
Самое начало работы системы не сопровождается большим количеством операций, т.к. еще идет конвертация остатков. Через 2-3 недели пользователи начинают работать в полную силу. А когда подходит время закрывать период, начинается самое интересное...
Самое начало работы системы не сопровождается большим количеством операций, т.к. еще идет конвертация остатков. Через 2-3 недели пользователи начинают работать в полную силу. А когда подходит время закрывать период, начинается самое интересное...
На графике видно, что команда поддержки не успевала сразу закрывать поступившие инциденты и навёрстывала в выходные. Около полутора месяцев работали без выходных.
Каждый день снимали статистику - количество поступивших запросов, решенных, остаток не закрытых на конец дня и количество просроченных.
К концу второго месяца количество незакрытых вопросов начало снижаться - это была победа!
Каждый день снимали статистику - количество поступивших запросов, решенных, остаток не закрытых на конец дня и количество просроченных.
К концу второго месяца количество незакрытых вопросов начало снижаться - это была победа!
Для срочного доступа были установлены дополнительные телефоны, их номера довели до пользователей. Однако требовали, чтобы в любом случае была оформлена заявка в Сервис-деске.
Для регистрации запросов использовался Сервис-деск на основе 1С. Эту систему выбрал заказчик из-за широких возможностей конфигурирования и доработки. Однако его быстродействие стало настоящим кошмаром и сильно мешало работе.
Система позволяет регистрировать запрос через web-интерфейс либо через почту. Запросы через почту составляли 80%. Чтобы запрос создавался автоматически, использовался шаблон письма, в котором была структура, в которой обязательно нужно было заполнить описание проблемы, полномочие пользователя, скриншот.
Диспетчеры по заранее определенному алгоритму назначали приоритет запроса и проверяли корректное назначение на функциональную группу. Приоритет определялся влиянием проблемы на выполнение бизнес-процессов. Некоторые процессы, напиример, отгрузка готовой продукции, по умолчанию ставились высоким приоритетом.
Много времени занимает прояснение проблемы. Редко, когда пользователь может четко объяснить, что случилось. Очень помогают скриншоты и прикрепленные логи из системы, а также удаленный доступ к рабочим местам через TeamViewer.
Для регистрации запросов использовался Сервис-деск на основе 1С. Эту систему выбрал заказчик из-за широких возможностей конфигурирования и доработки. Однако его быстродействие стало настоящим кошмаром и сильно мешало работе.
Система позволяет регистрировать запрос через web-интерфейс либо через почту. Запросы через почту составляли 80%. Чтобы запрос создавался автоматически, использовался шаблон письма, в котором была структура, в которой обязательно нужно было заполнить описание проблемы, полномочие пользователя, скриншот.
Диспетчеры по заранее определенному алгоритму назначали приоритет запроса и проверяли корректное назначение на функциональную группу. Приоритет определялся влиянием проблемы на выполнение бизнес-процессов. Некоторые процессы, напиример, отгрузка готовой продукции, по умолчанию ставились высоким приоритетом.
Много времени занимает прояснение проблемы. Редко, когда пользователь может четко объяснить, что случилось. Очень помогают скриншоты и прикрепленные логи из системы, а также удаленный доступ к рабочим местам через TeamViewer.
Для решения проблему устанавливались следующие нормативы (SLA):
В стабильном режиме служба поддержки закрывает 95% запросов в срок. Но в период стабилизации системы этот процент упал до 76% и приблизился к 90% только через 3 месяца после запуска.
- Критический (полная недоступность системы - 4 часа
- Высокий - 8 часов
- Средний - 12 часов
- Низкий - 16 часов
В стабильном режиме служба поддержки закрывает 95% запросов в срок. Но в период стабилизации системы этот процент упал до 76% и приблизился к 90% только через 3 месяца после запуска.
Все ошибки планирования, все волевые решения руководства о запуске в срок, ложатся потом на плечи команды поддержки. Спасибо всем за то, что вытянули, вынесли систему на руках и дожали проект до успешного завершения!
