Введение
Внедрение любой корпоративной информационной системы достаточно продолжительно по срокам и требует большого объема трудозатрат [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. Стратегия ролей и полномочий
В контексте стратегии ролей и полномочий требуется определить, необходимо ли ограничится присвоением конечному пользователю лишь одной бизнес-роли, включающей максимальные полномочия на все, или допускается множество. Обычно выбирается второй подход, так как в этом случае создание и конфигурирование бизнес-ролей значительно упрощается.
Полный текст статьи: https://corpinfosys.ru/archive/2018/issue-4/137-2018-4-strategyimplementation
