Стратегия поддержки продуктивного запуска ERP-системы

Подробности

Опубликовано: 12.04.2022 09:00

Автор: Петров Сергей Владимирович

Просмотров: 1518

Аннотация: в статье дается описание того, что понимание и заблаговременная проработка активностей, необходимых для поддержки ERP-системы, обеспечивает безболезненный этап ее продуктивного запуска. Пользователям необходимо знать, к кому обращаться за помощью в случае возникновения вопросов, дефекты должны маршрутизироваться и разрешаться, а для обработки новых требований важно наличие специального регламента. Все это является содержанием стратегии поддержки продуктивной эксплуатации системы ERP.
Скачать: PDF (статья), PDF (выпуск №18).
Ключевые слова: поддержка запуска программного обеспечения, поддержка ERP систем, техническая поддержка ERP, поддержка SAP ERP, 1C ERP поддержка, поддержка ERP, продуктивная поддержка, продуктивный запуск, go live, hypercare, промышленная эксплуатация.

Введение

Продуктивный запуск является ключевым событием проекта внедрения ERP-систем. Обычно ему предшествуют весьма трудозатратные мероприятия продуктивной миграции, а также технического и бизнес катоверов. Поддерживающими продуктивный запуск документами являются: план Б, план обеспечения непрерывности бизнеса, план отказа и стратегия поддержки [1]. Каждый из документов предназначен для решения своей специфичной задачи, но все они служат лишь одному: максимально безболезненно запустить программное продуктивное решение и заставить пользователей в нем работать на регулярной основе.

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

Цель данной статьи представляется в рассмотрении особенностей поддержки продуктивного запуска ERP-системы, что должно обеспечить более «мягкий» ее запуск и слаженный механизм реагирования и исправления программных инцидентов.

1. Стратегия поддержки

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

Начнем с разрешения дефектов, возникающих при продуктивном запуске. Чаще всего на стороне заказчика организуется команда поддержки, которая в режиме реального времени способна собирать, маршрутизировать и разрешать ошибки ERP-системы с вовлечением проектной команды. В свою очередь время реагирования на ошибки системы различается для гиперопеки продуктивного запуска и поддержки регулярных процессов [3]. Для формализации порядка работы службы поддержки вводят термин линия поддержки. На практике выделяют 4-е линии поддержки: регистраторы дефектов, маршрутизаторы, эксперты и команда вендора:

• первая линия поддержки решает задачи регистрации обращений от пользователей и их заведения систему ITSM;
• распределение дефектов по ответственным функциональным командам для их анализа и решения осуществляется на второй линии;
• разрешение инцидентов силами экспертов ведется на третьей линии поддержки;
• в случае, если дефект представим недоработкой стандартного функционала ERP-системы, он передается на сторону вендора. 

Если в договоре на внедрение явно указан период гарантийной поддержки, то при наступлении гарантийного случая к разрешению инцидентов на 3-м уровне могут привлекаться специалисты исполнителя. Когда имплементирует «самописная» информационная система исполнителя, исправление ошибок ее базового функционала на 4-го уровне будет также его ответственностью.

Допустим, вы организовываете ИТ-службу, состоящую из 4-х линий поддержки, что дальше? Теперь нужно задать регламент их работы, приоритеты дефектов и время их обработки. Чем выше приоритет дефекта, тем быстрее он должен быть разрешен. Если служба ИТ-поддержки организуется «с нуля» в рамках проекта внедрения ERP-системы, требуется отрепетировать ее работу. Для чего усеченный состав команды ИТ, а также функционал технической инфраструктуры используются уже на этапе интеграционного теста программного решения.

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

Следующий важный момент, который следует упомянуть в стратегии поддержки, – вовлечение бизнес пользователей в разрешение дефектов. 1-я линия поддержки при обращении обычно ссылается на существующие инструкции и ключевых пользователей как носителей знаний. Регистрацию дефектов часто поручают делать исключительно ключевым, но не конечным пользователям. Тем самым знания постепенно накапливаются и генерируются внутри пользователей, т.е. владельцев ERP-системы.

В высококритичных проектах используют документы, поддерживающие запуск: плана Б и отката системы. Оба документа направлены на обработку исключительно неблагоприятных ситуаций, так первый подразумевает использование обходных путей в случае затягивания сроков разрешения критичных дефектов, а второй – полный отказ от недавно имплементированной ERP-системы, внедрение которой признали неуспешным.

2. План Б и откат системы

Предположим, в процессе поддержки запуска был зарегистрирован инцидент с самым высоким приоритетом. Однако даже в этом случае время его исправления может затянуться на целый рабочий день в виду как технических, так и организационных сложностей. Для обработки подобных ситуаций прорабатывается план Б. Формирование плана начинается на этапе приемочного тестирования, где определяются наиболее критичные функции ERP-системы в разрезе бизнес направлений, которые могут дать сбой именно при запуске. Далее для каждой функции выбирается обходной путь, позволяющий достичь тех же результатов иным способом. Классическим примером служит формирование сопроводительных документов: если в ERP-системе невозможно сформировать и распечатать форму ТОРГ-12, то обходным путем будет являться ее ручная подготовка вне системы в Excel-файле. Кроме того, прорабатываются и согласуются предпосылки для начала использования плана Б, так как его применение обязательно потребует дальнейших нестандартных действий в ERP-системе для отражения последующих корректировок. Обычно план Б готовится ключевыми пользователями, кто в последующем и будет его исполнять.

Крупномасштабное внедрение ERP-систем на предприятии обычно ведется через схему опытно-промышленной эксплуатации в рамках пилотного проекта. Так, целесообразность имплементации корпоративной информационной системы на всех подразделениях компании определяется по результатам ее использования на одном из тестовых предприятий. Если оказывается, что применение ERP-системы не дает ожидаемых результатов в тестовой организации, от нее отказываются, для чего применяется план отката. План отката описывает порядок шагов для отказа от использования нового ИТ-решения и перечень мероприятий для возобновления работы в «старой» системе. Если активности плана Б запускают после согласования с руководителем проекта, то план отката – в рамках обсуждения с управляющим комитетом, так как существенна финансовая сторона вопроса.

Заключение

Как мы видим, стратегия поддержки состоит в организации грамотной работы ИТ-команды, для обеспечения слаженного реагирования на возникающие недоработки внедряемой ERP-системы:

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

По результатам завершения этапа гиперопеки, заказчик получает ERP-систему в постоянное пользование и сопровождение. Поэтому порядок работы ИТ-службы должен быть изменен: задается согласованный уровень обслуживания системы, известный как SLA (Service Level Agreement), уточняется время реагирования на дефекты, определяется продолжительность работы команды поддержки в неделю, например, 8x5 или 24x7, и др. В общем случае, регулярную ИТ-поддержу может вести как сам заказчик, так и нанятая им организация по отдельному договору аутсорсинга.

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

Литература 

1. Петрова Е. А., Фокина Е. А. Информационный менеджмент. – М.: Лань, 2020. – 215 с.
2. Остроух А.В., Суркова Н.Е. Проектирование информационных систем. М.: Лань, 2019. 164 с.
3. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.

Выходные данные статьи

Петров С.В. Стратегия поддержки продуктивного запуска ERP-системы // Корпоративные информационные системы. – 2022. – №2(18). – С. 30-35. – URL: https://corpinfosys.ru/archive/issue-18/199-2022-18-erpgolivehypercare.

Об авторе

Петров Сергей Владимирович – эксперт по разработке программных решений в банковской, торговой и производственной сферах. Специализируется на языках программирования высокого уровня С++, Java и Transact SQL. Имеет более чем 10-летний опыт разработки приложений. Принимал участие в проектах разработки аналитических, экспертных, биотехнических и корпоративных систем. Электронный адрес:Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Статьи выпуска №18

1. Учет договоров с использованием HoneyCode (часть 1);
2. Становление корпоративных информационных систем в России;
3. Автоматизация процессов транспортной логистики (часть 2);
4. Стратегия поддержки продуктивного запуска ERP-системы;
5. Импортозамещение в проектах внедрения ERP-систем.