Внедрение любой корпоративной информационной системы достаточно продолжительно по срокам и требует большого объема трудозатрат [1]. В среднем необходимо около одного года на имплементацию ERP‑системы, а трудозатраты проектной команды со стороны исполнителя обычно колеблются в диапазоне 1000–3000 человеко‑дней. Объем трудозатрат фактически задает перечень тех работ, которые обязуется выполнить интегратор для заказчика. Чем больше объем выполняемых работ, тем актуальнее становится задача по их группировке для более качественного планирования, исполнения и контроля.

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

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

Цель работы состоит в рассмотрении стратегий реализации содержания для каждой из наиболее критичных областей внедрения ERP‑системы. Достижение цели потребует проработки следующих задач:

• обзор стратегий по реализации содержания ERP‑проекта;

• анализ наиболее используемых методов каждой из стратегий;

• задание наиболее применяемой стратегии внедрения ERP‑систем.

1. Обзор стратегий реализации содержания ERP-проекта

Стратегию реализации содержания ERP‑проекта можно условно разложить на одиннадцать составляющих, часть из которых, совпадает по названию с фазами проекта внедрения, другая — представима уровнями внедрения, третья вообще не рассматривалась ранее (рис. 1). Стратегии покрывают все ключевые активности проекта внедрения и специфицируют подход к выполнению работ. Рассмотрим их более подробно и приведем наиболее используемые методы.

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 по результатам приемочного испытания...