Реализация содержания проекта внедрения ERP-системы
Внедрение любой корпоративной информационной системы достаточно продолжительно по срокам и требует большого объема трудозатрат [1]. В среднем необходимо около одного года на имплементацию ERP-системы, а трудозатраты проектной команды со стороны исполнителя обычно колеблются в диапазоне 1000–3000 человеко-дней. Объем трудозатрат фактически задает перечень тех работ, которые обязуется выполнить интегратор для заказчика. Чем больше объем выполняемых работ, тем актуальнее становится задача по их группировке для более качественного планирования, исполнения и контроля.
Именно по этой причине в [2] выделяют уровни внедрения, такие как: процессы, приложения, данные и техника, а также управление проектом и изменениями. Однако и этого деления бывает недостаточно, так как каждый уровень по прежнему остается достаточно трудоемким. По этой причине в работах [3–4] вводится понимание концепции реализации содержания проекта, заключающейся в выделении наиболее критичных областей проекта внедрения ERP-систем, а также предложении состава и порядка выполнения работ для каждой из областей. Примерами областей служат задачи, относящиеся к анализу, проектированию, разработке, миграции, тестированию и др.
Состав работ определяется путем рассмотрения всевозможных способов, методов и подходов, позволяющих достигнуть необходимого результата с минимальными рисками задержки продуктивного старта ERP-системы. Объем необходимых работ дает возможность увидеть плановую потребность в человеческих ресурсах, что критично для формирования ресурсного плана проекта, а состав задач обеспечивает понимание всех тонкостей реализации предстоящего проекта. В рамках текущей статьи мы рассмотрим все критичные области ERP-проекта и суммируем способы реализации задач каждой из областей, тем самым расширяя содержание работы [4].
Цель работы состоит в рассмотрении стратегий реализации содержания для каждой из наиболее критичных областей внедрения ERP-системы. Достижение цели потребует проработки следующих задач:
обзор стратегий по реализации содержания ERP-проекта;
анализ наиболее используемых методов каждой из стратегий;
задание наиболее применяемой стратегии внедрения ERP-систем.
1. Обзор стратегий реализации содержания ERP-проекта
Стратегию реализации содержания ERP-проекта можно условно разложить на одиннадцать составляющих, часть из которых, совпадает по названию с фазами проекта внедрения, другая — представима уровнями внедрения, третья вообще не рассматривалась ранее (рис. 1). Стратегии покрывают все ключевые активности проекта внедрения и специфицируют подход к выполнению работ. Рассмотрим их более подробно и приведем наиболее используемые методы.
Рис. 1. Стратегия реализации содержания ERP-проекта
1.1. Стратегия анализа
Стратегия анализа определяет правила идентификации, приоритизации и оценки пользовательских требований. Концепция задается параметрами ниже, которые требуется подобрать до старта соответствующего этапа проекта:
способ выявления требований, подразумевающий прототипирование или демонстрацию системы;
метод оценки требований, в частности на основе экспертной оценки или оценщика.
Лучшей практикой считается стратегия, в которой требования выявляются в процессе демонстрации работающей копии системы, а также используется механизм оценщика для расчета трудозатрат (позволяет для пары «тип разработки/настройки-сложность» подобрать трудозатраты подготовки документов и реализации программы).
1.2. Стратегия проектирования
Стратегия проектирования характеризуется такими параметрами, как:
необходимость формирования карты бизнес-процессов;
использование нотации верхнеуровневого проектирования, преимущественно это ARIS VACD;
определение нотации низкоуровневого проектирования, из возможных ARIS eEPC и BPMN SLD;
глубина низкоуровневого описания, обычно задающаяся уровнями 3–5.
Практика показывает, что на начальных этапах достаточно формирование карты бизнес-процессов до 3 уровня, что позволяет упростить идентификацию требований. В качестве нотаций проектирования на верхних уровнях иногда применяется ARIS VACD, на нижних — нотация на базе SLD (Swim Lane Diagram), при этом детализация ведется до 4–5 уровней.
1.3. Стратегия ролей и полномочий
В контексте стратегии ролей и полномочий требуется определить, необходимо ли ограничится присвоением конечному пользователю лишь одной бизнес-роли, включающей максимальные полномочия на все, или допускается множество. Обычно выбирается второй подход, так как в этом случае создание и конфигурирование бизнес-ролей значительно упрощается.
1.4. Стратегия технической подготовки
Содержание стратегии технической подготовки ERP-системы определяется в зависимости от следующих параметров:
необходимость подготовки песочницы, как независимой системы или зависимой среды в контуре четырехуровневой архитектуре ERP-системы;
число копий среды контроля качества для проведения тестовых циклов миграции данных и функциональных испытаний;
потребность в создании копий среды контроля качества для ведения регрессионных и нагрузочных тестирований.
Опыт показывает, что систему песочницы правильнее конфигурировать так, чтобы она представляла независимую среду от трехуровневого контура ERP-системы. Такой подход обеспечивает возможность модификации критических функций и исключает возможность влияния на ERP-систему. Несмотря на высокие трудозатраты, самым безопасным и оправданным с точки зрения митигации продуктивных дефектов считается подход, в котором под все виды тестирований и миграций создаются отдельные копии среды контроля качества.
1.5. Стратегия управления изменениями
Стратегия управления изменениями подразумевает выбор параметров изменения, подлежащих оцениванию и определения для них мероприятий по достижению целевых значений. Примерами параметров являются: люди, знания, процессы, технологии, продукты, корпоративная культура и прочие, суммарно восемь штук. В случае внедрения ERP-систем обычно ограничиваются рассмотрением лишь трех параметров изменения: технологии, процессы и люди, их достаточно, чтобы обеспечить успешный продуктивный запуск программного решения.
1.6. Стратегия разработки и настройки
Рассмотрим следующую стратегию: стратегию разработки и настройки ERP-системы. Концепция характеризуется двумя основными пунктами:
необходимость создания/применения соглашения по наименованию технических объектов;
использование процедур контроля качества программ.
Соглашение по наименованию объектов обеспечивает единый подход к созданию и нэймингу новых сущностей ERP-системы. Контроль качества программных продуктов, в частности, использование константных переменных, обязательное указание оргуровней и проверка полномочий пользователей на их основе, позволяет предварительно исключить типовые алгоритмические ошибки. Лучшая практика по внедрению информационных систем, подразумевает применение как соглашения по наименованию, так и процедур контроля качества.
1.7. Стратегия миграции данных
Переходим к одному из самых критичных вопросов ERP-проекта: миграции основных и переменных данных. Стратегия миграции рассматривается сквозь призму следующих вопросов:
подход к организации команды миграции, функциональный или матричный;
количество тестовых волн миграции, 1–3;
%-загрузки данных для тестовых волн миграции;
необходимость ранней миграции основных данных.
Распространенной практикой внедрения корпоративных информационных систем является выделение отдельной команды, ответственной за миграцию основных данных. Тем самым говорят о функциональном подходе к организации команды по миграции. Снижение рисков некачественных данных обрабатывается путем выстраивания череды волн тестовых миграций. Количество тестовых миграций сопоставляют с числом испытаний: модульное, интеграционное и приемочное тестирования, таким образом три волны миграций. Каждая волна миграции требует моделирования загрузки определенного объема реальных данных, значение которого преимущественно сводят к 100%. Мероприятие весьма трудозатратное, однако позволяет отловить максимум ошибок в данных уже на начальных этапах проекта. В отличие от транзакционных данных, основные не так регулярно изменяются, поэтому их часто мигрируют задолго до даты продуктивного запуска. Цена вопроса — двойной ввод информации как в историческую, так и целевую системы.
1.8. Стратегия обучения
Обучение пользователей преимущественно проводят перед этапом тестирования разработанной системы и накануне продуктивного старта. Различают следующие параметры, задающие стратегию обучения:
вид обучающих материалов, с точки зрения глубины описания бизнес-процессов и полноты отражения E2E-процессов;
типы слушателей, ключевые или конечные пользователи;
способ обучения, силами проектной команды или ключевых пользователей.
В виду сложности и продолжительности ERP-проекта, проектные команды выбирают такой подход к проведению обучения, который обеспечивает максимальное сокращение трудозатрат. Поэтому готовятся не пользовательские инструкции, а обучающие материалы, содержащие техническое описание выполняемых операций. Обучаются ключевые пользователи заказчика, чтобы именно они в дальнейшем дообучили конечных пользователей.
1.9. Стратегия тестирования
Для проведения испытания разработанной ERP-системы готовится концепция тестирования, содержащая описание того:
какие виды тестирований ожидаются в объеме проекта, для выбора доступны модульное, интеграционное и непрерывное тестирования, а также нагрузочное и регрессионное испытания;
критерии успешного завершения тестирования, оцениваемые %-пройденных сценариев тестирования в зависимости от вида испытаний или числом открытых критических дефектов.
Чаще всего проводятся модульное, интеграционное и непрерывное тестирования, а в качестве критерия успешного завершения тестирования принимают число открытых критических дефектов, стремящееся к нулю или максимум 1–5 по результатам приемочного испытания …
Литературный источник:
Петров С.В. Стратегии реализации содержания в проектах внедрения ERP-систем // Корпоративные информационные системы. — 2018. — №4 — С. 61–68. — URL: https://corpinfosys.ru/archive/issue-4/137–2018–4-strategyimplementation.
