Стратегия является ключевым документом, описывающим предполагаемый подход к решению той или иной задачи. В области внедрения ERP-систем выделяют такие концепции доставки содержания, как: анализа, проектирование, реализация, ролей и полномочий, миграции, обучения, тестирования, технической подготовки системы, бизнес-катовера, изменений и поддержки. Основой использования стратегий в проектах имплементации ERP-систем служит теория корпоративных информационных систем, предложенная в работе [1]. Анализ литературных источников в области корпоративных информационных систем и стратегий доставки включает множество работ [2-14], однако в них лишь косвенно указана первопричина формирования концепции, что, следовательно, делает выбор того или иного способа недоказательным.
Для устранения указанных недостатков, в этой статье мы попытаемся вскрыть исходную проблематику, что порождает необходимость формирования стратегии доставки содержания, а также уточним и детализируем способы решения. Следует сразу сделать оговорку, что стратегии доставки содержания, ни в коей мере не противоречат и не заменяют активности фаз внедрения. По существу, они дополняют и максимально их уточняют. Поэтому существование фазы анализа как пример не исключает наличия одноименной стратегии.
1. Стратегии и риски
Отличительной особенностью любой стратегии является то, что она направлена на снижение того или иного риска. Это может вас сильно удивить, ведь эта ключевая мысль скрыта за беленой деталей всех ранее описанных стратегий, которые вы можете найти в указанных литературных источниках [2-14]. Поэтому в рамках этой работы мы попытаемся подойти к вопросу стратегий с позиции минимизации именно проектных рисков, дополняя и уточняя при этом все, что нам ранее удалось выяснить. Следовательно, стратегия доставки содержания будет предлагать способы, позволяющие эффективно снижать, исключать или передавать проектные риски. В таблице 1 приведены стратегии, задающие содержание и изменения ERP-проекта, а также предложены проектные риски.
Табл. 1. Стратегии и риски, обрабатываемые в них
№ |
Стратегия |
Риск |
1 |
Анализа |
Не идентифицированы все требования, обеспечивающие выполнение критических бизнес-процессов |
2 |
Проектирования |
Предлагаемое спроектированное решение может оказаться неработоспособным по результатам реализации |
3 |
Настройки и разработки |
Реализованный программный продукт отличается от спроектированного на предыдущем этапе, а также не решает исходной поставленной задачи |
4 |
Ролей и полномочий |
Пользователям выданы излишние права и полномочия в ERP-системе |
5 |
Миграции |
Низкое качество мигрированных данных, а также несвоевременное продуктивное мигрирование |
6 |
Тестирования |
Поверхностное или неполное тестирование разработанного программного продукта |
7 |
Технической подготовки системы |
Низкое качество, несвоевременная техническая подготовка ERP-системы |
8 |
Обучения |
Пользователи плохо обучены работе c ERP-системой, а также не готовы работать в ней |
9 |
Бизнес перехода |
Чрезмерно затянутый период блэкаута, а также низкая согласованность задач по запуску новой системы с регулярными бизнес-процессами компании |
10 |
Внедрения |
Большое число ошибок пользователей при работе с новой ERP-системой, а также чрезмерное высокое число программных дефектов |
11 |
Поддержки продуктивного запуска |
Вовлеченные стороны и конечные пользователи не понимают порядок обработки вопросов и дефектов запускаемой ERP-системы |
12 |
Изменений |
Внедренная программная система не используется пользователями в полной мере или игнорируется пользователями |
2. Способы понижения рисков
Давайте теперь рассмотрим способы обработки каждого из приведенных выше рисков. Так в стратегии анализа [3] предлагается идентификацию требований вести на базе заранее подготовленной типовой карты бизнес-процессов, сбор требований агрегировать в едином реестре (или матрице отслеживания требований), а приоритизацию потребностей поручить ключевым бизнес пользователям. Все предложения делаются для того, чтобы не упустить ни одно из важных для запуска бизнес требование.
Стратегия проектирования подразумевает прототипирование [4], использование демонстрационных баз и стендов, системы песочницы, дабы проверить гипотезу о том, что проектируемое решение будет действительно реализуемым.
Стратегию ролей и полномочий легче всего объяснить на примере их реализации в SAP ERP [5]. Так технические роли можно сконфигурировать в виде матрешки, где в композитную бизнес-роль вложены единичные наследуемые роли, а также роли меню. Каждая единичная роль позволяет выполнить лишь одну операцию над данными в разрезе единственной программы SAP. В виду трудоемкости задачи готовится матрица ролей и полномочий, включающая присвоения:
бизнес роль – список программ SAP для возможности запуска;
единичная SAP роль – проверяемые объекты полномочий в заданной программе SAP;
наследуемая SAP роль – единичная SAP роль – дополненные организационные данные;
роль меню SAP – список возможных для запуска программ SAP;
композитная роль SAP (бизнес роль) – наследуемая SAP роль и роль меню SAP.
Именно нетехническое описание «Бизнес роль – список программ SAP для возможности запуска» позволяет быстро осуществить контроль правильности присвоения ролей пользователям.
Стратегия реализации направлена на сравнение ранее спроектированного и уже сконфигурированного или запрограммированного решения, для чего часто проводят процедуру контроля качества программного кода, а также следуют утвержденному соглашению о наименовании технических объектов [6].
Стратегия обучения пользователей нацелена на передачу знаний по работе в ERP-системе от проектной команды будущим пользователям [7]. Обычно проектная команда обучает ключевых пользователей заказчика, а те – конечных. Оценивание качества обучение требует проведения процедур тестирования по результатам завершения занятий. Кроме того, в рамках стратегии готовятся пользовательские инструкции, а информация об их наличие и расположении доводится до будущих пользователей системы заранее.
Стратегия тестирования подразумевает проведение модульного, интеграционного и приемочного тестирования в формате непрерывного [8]. Испытания проводятся разными людьми: консультанты, ключевые и конечные пользователи, а в качестве входных данных применяются мигрированные данные 1-3 тестовых волн миграции.
Стратегия миграции предполагает порядка 3-х волн тестовой миграции, а также проведение ранней продуктивной миграции для снижения риска задержки подготовки данных для запуска [9]. Качество мигрируемых данных косвенно проверяется в контексте стратегии тестирования ...
Литературный источник:
Абазьева М.П. О стратегиях доставки содержания и изменений в проектах внедрения ERP-систем // Корпоративные информационные системы. – 2022. – №4 (20) – С. 17-24. – URL: https://corpinfosys.ru/archive/issue-20/204-2022-20-contentchangestrategies.
[реклама удалена мод.]