Стратегии реализации содержания при имплементации ERP-систем

Корпоративные информационные системы и учетная политика организации при применении автоматизированной формы ведения учета

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

Введение

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

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

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

Цель и задачи

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

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

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

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

Стратегия реализации содержания ERP-проекта

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

1.10. Стратегия перехода

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

  • количество тестовых технических переходов, обычно 1-3;
  • необходимость репетиции остановки компании.

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

1.11. Стратегия поддержки продуктивного запуска

Финальной концепцией является стратегия поддержки продуктивного запуска, включающая такие характеристики как:

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

Обычно поддержка организуется следующим образом. Все возникшие вопросы от конечных пользователей проходят через ключевых сотрудников. Если ключевой пользователь не может дать ответ, то регистрируется дефект. Обычно служба поддержки организуется таким образом, что на 1-й линии работают представители Helpdesk заказчика, для сбора инцидентов, их приоритизации и распределения по ответственным. Проектная команда подключается лишь на 2-м уровне поддержки, когда дефекты уже распределены. Основным критерием завершения поддержки служит отсутствие открытых критических дефектов на протяжении 1-3 дней.

Заключение

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

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

Литература 

  1. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
  2. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: теория и практика // Российский технологический журнал. – 2015. – т.8, №3. – c.227-238. – URL: https://stepanovd.com/science/31-article-2015-2-erpthpr .
  3. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: модели и уровни внедрения корпоративных информационных систем / МГТУ МИРЭА. – М., 2017. – URL: https://stepanovd.com/training/12-erp/48-erp-3-models.
  4. Stepanov D.Yu. Strategy based ERP-system implementation approach // Fundamental problems of radioengineering and device construction. – 2017. – vol.17, №3. – p.697-700. – URL: https://stepanovd.com/science/36-article-2017-1-implappr.

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

Петров С.В. Стратегии реализации содержания в проектах внедрения ERP-систем // Корпоративные информационные системы. – 2018. – №4 (4) – С. 61-68. – URL: https://corpinfosys.ru/archive/issue-4/137-2018-4-strategyimplementation.

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

Об авторе

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

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

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