Концепция поддержки продуктивного запуска ERP-системы
Продуктивный запуск является ключевым событием проекта внедрения ERP-систем. Обычно ему предшествуют весьма трудозатратные мероприятия продуктивной миграции, а также технического и бизнес катоверов. Поддерживающими продуктивный запуск документами являются: план Б, план обеспечения непрерывности бизнеса, план отказа и стратегия поддержки [1]. Каждый из документов предназначен для решения своей специфичной задачи, но все они служат лишь одному: максимально безболезненно запустить программное продуктивное решение и заставить пользователей в нем работать на регулярной основе.
Поддержка продуктивного запуска пользователей или, как часто ее называют, гиперопека, преимущественно длится 4-е недели, после чего программное решение передается на сопровождение ИТ-службе заказчика. Обычно 4-х недель продуктивной поддержки хватает для помощи заказчику в закрытии одного бухгалтерского и налогового периодов в новой ERP-системе, однако бывает случаи, когда ее продлевают на более длительный период [2]. Сложность и продолжительность гиперопеки зависит также от того, имеется ли на стороне заказчика специально выделенная и организованная ИТ-служба поддержки.
Для начала давайте определимся, что же такое стратегия и какие задачи она призвана решать. Стратегия поддержки характеризует один из подходов к решению проектной задачи, что применительно к продуктивному запуску есть обеспечение своевременного и качественного устранения программных ошибок, а также передача ответственности за систему пользователям. В контексте стратегии должно быть описано, как указанные сложности будут разрешаться.
Начнем с разрешения дефектов, возникающих при продуктивном запуске. Чаще всего на стороне заказчика организуется команда поддержки, которая в режиме реального времени способна собирать, маршрутизировать и разрешать ошибки ERP-системы с вовлечением проектной команды. В свою очередь время реагирования на ошибки системы различается для гиперопеки продуктивного запуска и поддержки регулярных процессов [3]. Для формализации порядка работы службы поддержки вводят термин линия поддержки. На практике выделяют 4-е линии поддержки: регистраторы дефектов, маршрутизаторы, эксперты и команда вендора:
- первая линия поддержки решает задачи регистрации обращений от пользователей и их заведения систему ITSM; - распределение дефектов по ответственным функциональным командам для их анализа и решения осуществляется на второй линии; - разрешение инцидентов силами экспертов ведется на третьей линии поддержки; - в случае, если дефект представим недоработкой стандартного функционала ERP-системы, он передается на сторону вендора.
Если в договоре на внедрение явно указан период гарантийной поддержки, то при наступлении гарантийного случая к разрешению инцидентов на 3-м уровне могут привлекаться специалисты исполнителя. Когда имплементирует «самописная» информационная система исполнителя, исправление ошибок ее базового функционала на 4-го уровне будет также его ответственностью.
Допустим, вы организовываете ИТ-службу, состоящую из 4-х линий поддержки, что дальше? Теперь нужно задать регламент их работы, приоритеты дефектов и время их обработки. Чем выше приоритет дефекта, тем быстрее он должен быть разрешен. Если служба ИТ-поддержки организуется «с нуля» в рамках проекта внедрения ERP-системы, требуется отрепетировать ее работу. Для чего усеченный состав команды ИТ, а также функционал технической инфраструктуры используются уже на этапе интеграционного теста программного решения ...
Петров С.В. Стратегия поддержки продуктивного запуска ERP-системы // Корпоративные информационные системы. – 2022. – №2(18). – С. 30-35. – URL: https://corpinfosys.ru/archive/issue-18/199-2022-18-erpgolivehy.
· 06.06
Про 4 уровня ТП. Я всегда думал, что тикеты должны закрываться как можно раньше в части уровня. Только регистрация и только маршрутизация на 1 и 2 - это как-то сильно модно. А попадание задачи на 3 и 4 уровни это дорого, такие специалисты и сами себе задач нарежут с огромной пользой.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён