Введение
Продуктивный запуск является ключевым событием проекта внедрения ERP-систем. Обычно ему предшествуют весьма трудозатратные мероприятия продуктивной миграции, а также технического и бизнес катоверов. Поддерживающими продуктивный запуск документами являются: план Б, план обеспечения непрерывности бизнеса, план отказа и стратегия поддержки [1]. Каждый из документов предназначен для решения своей специфичной задачи, но все они служат лишь одному: максимально безболезненно запустить программное продуктивное решение и заставить пользователей в нем работать на регулярной основе.
Поддержка продуктивного запуска пользователей или, как часто ее называют, гиперопека, преимущественно длится 4-е недели, после чего программное решение передается на сопровождение ИТ-службе заказчика. Обычно 4-х недель продуктивной поддержки хватает для помощи заказчику в закрытии одного бухгалтерского и налогового периодов в новой ERP-системе, однако бывает случаи, когда ее продлевают на более длительный период [2]. Сложность и продолжительность гиперопеки зависит также от того, имеется ли на стороне заказчика специально выделенная и организованная ИТ-служба поддержки.
Цель данной статьи представляется в рассмотрении особенностей поддержки продуктивного запуска ERP-системы, что должно обеспечить более «мягкий» ее запуск и слаженный механизм реагирования и исправления программных инцидентов.
1. Стратегия поддержки
Для начала давайте определимся, что же такое стратегия и какие задачи она призвана решать. Стратегия поддержки характеризует один из подходов к решению проектной задачи, что применительно к продуктивному запуску есть обеспечение своевременного и качественного устранения программных ошибок, а также передача ответственности за систему пользователям. В контексте стратегии должно быть описано, как указанные сложности будут разрешаться.
Начнем с разрешения дефектов, возникающих при продуктивном запуске. Чаще всего на стороне заказчика организуется команда поддержки, которая в режиме реального времени способна собирать, маршрутизировать и разрешать ошибки ERP-системы с вовлечением проектной команды. В свою очередь время реагирования на ошибки системы различается для гиперопеки продуктивного запуска и поддержки регулярных процессов [3]. Для формализации порядка работы службы поддержки вводят термин линия поддержки. На практике выделяют 4-е линии поддержки: регистраторы дефектов, маршрутизаторы, эксперты и команда вендора:
- первая линия поддержки решает задачи регистрации обращений от пользователей и их заведения систему ITSM;
- распределение дефектов по ответственным функциональным командам для их анализа и решения осуществляется на второй линии;
- разрешение инцидентов силами экспертов ведется на третьей линии поддержки;
- в случае, если дефект представим недоработкой стандартного функционала ERP-системы, он передается на сторону вендора.
Если в договоре на внедрение явно указан период гарантийной поддержки, то при наступлении гарантийного случая к разрешению инцидентов на 3-м уровне могут привлекаться специалисты исполнителя. Когда имплементирует «самописная» информационная система исполнителя, исправление ошибок ее базового функционала на 4-го уровне будет также его ответственностью.
Допустим, вы организовываете ИТ-службу, состоящую из 4-х линий поддержки, что дальше? Теперь нужно задать регламент их работы, приоритеты дефектов и время их обработки. Чем выше приоритет дефекта, тем быстрее он должен быть разрешен. Если служба ИТ-поддержки организуется «с нуля» в рамках проекта внедрения ERP-системы, требуется отрепетировать ее работу. Для чего усеченный состав команды ИТ, а также функционал технической инфраструктуры используются уже на этапе интеграционного теста программного решения.
Зарегистрированный дефект маршрутизируется на последующую линию поддержки. В случае отнесения дефекта к категории, характеризующей новое требование, еще не реализованное в системе, необходимо проработать порядок последующего управления изменениями (запросами на изменения, Change Request). В частности, для каждого запроса потребуется сформулировать бизнес обоснование, задать критичность для бизнеса, привести предварительный расчет трудозатрат и стоимости реализации. Для подобных запросов организуются дополнительные встречи с управляющим комитетом, на котором запрос рассматривается, защищается, принимается решение о его включении/невключении, объем текущей реализации.
Полный текст статьи: https://corpinfosys.ru/archive/2022/issue-18/199-2022-18-erpgolivehypercare
