Введение
Корпоративная информационная система представляется набором информационных систем, каждая из которых позволяет автоматизировать заданную бизнес область предприятия. Проект внедрения по существу представляет собой разработку и настройку приложения, в состав которого входит множество независимых программ [1]. Если мы говорим о реализации отдельно стоящих разработок, здесь обычно не возникает сложностей, все организуется в единственном программном экземпляре системы. При настройке и разработке ERP-системы появляются проблемы более высоких порядков, так как наличие набора программ подразумевает частые их изменения, которые определенно не могут быть сделаны в той же среде, где обрабатываются продуктивные данные.
Не забудьте про активности миграции данных и тестирования, каждая из которых так или иначе связана с использованием существующего экземпляра системы. Отдельно стоит упомянуть про пакеты обновлений, регулярно выпускаемые производителями программных решений. Как таковых сложностей с их установкой нет, сложности заключаются в том, что они косвенно могут повлиять на уже существующие клиентские доработки. Поэтому имплементация обновлений требует тщательного анализа ожидаемых изменений, который определенно должен вестись подальше от продуктивной среды.
И, наконец, поговорим о настройках. ERP-система представляет собой коробочное решение, позволяющее по умолчанию реализовать типовые бизнес-процессы предприятия. Функциональный дефицит, образующийся в случае, если требование не реализовано изначально в ERP-системе, может быть обработан за счет доработки или донастройки системы. Сложность состоит в том, что определенные настройки являются необратимыми, один раз активировав настройку, вы уже не сможете отменить ее обратно. Преимущественно подобные настройки относятся к критичным функциям ERP-системы, пронизывающим все бизнес-процессы коробочного решения. Поэтому поспешное выполнение таких настроек может привести к краху всей ERP. Все это подчеркивает необходимость формирования разумной стратегии по технической подготовке ERP-системы.
Цели и задачи
Цель работы заключается в рассмотрении стратегии технической подготовки системы в ERP-проектах внедрения и развития. Это позволит реализовывать проекты в срок, обеспечивая при этом стабильное функционирование ERP-системы. Достижение цели потребует проработки следующих задач:
- рассмотрение классической трехуровневой архитектуры ERP-системы;
- обзор влияния активностей по миграции и тестирования данных;
- подготовка стратегии технической подготовки ERP-системы.
1. Разработка и настройка ERP-системы
К разработке ERP-системы не совсем правильно применять те же принципы, что используются при реализации изолированных программ. Хотя ERP и представляет множество взаимодействующих между сбой программ, рассматривать их нужно вместе, но не порознь. Поэтому ситуация, когда одна программа из состава ERP работает отлично в продуктивном режиме эксплуатации, вторая – находится на испытаниях по устранению технического дефекта, третья – еще только реализуется, является весьма распространенной. Для того, чтобы ее обработать в ERP-системе используется трехуровневая архитектура. Трехуровневая архитектура состоит из отдельных, соединенных между собой программных систем:
- среда разработки, для ведения разработки и настройки ERP-системы;
- среда контроля качества, где проводятся интеграционные и непрерывные испытания настроенной и разработанной системы;
- продуктивная среда, в которой пользователи работают в режиме реального времени.
Как только настройка или разработка выполнена в среде разработок, ее переносят в систему контроля качества для выполнения тестирования. Убедившись, что функционал работает корректно, он переносится в продуктивную среду. Перенос между средами может выполняться в автоматизированном или полностью ручном режимах, все зависит от технических особенностей ERP-системы. Таким образом бизнес-требование последовательно проходит свою обработку в двух системах, перед тем как стать доступной конечному пользователю в продуктивной среде. Трехуровневая архитектура ERP-системы является минимально необходимой с точки зрения числа сред, в зависимости от потребностей проекта их количество может быть увеличено [2]. Например, в проектах развития ERP-систем нередко используют предпродуктивную среду, основное назначение которой хранить слепок данных продуктивной системы для ограниченного временного интервала, что бывает важным для проведения тестирования.
Иногда необходимо выполнить необратимую настройку, которую невозможно откатить обратно. Делать ее в среде разработки чрезвычайно опасно, ведь сложно оценить последствия: как она повлияет на существующий функционал. В этом случае используется экземпляр системы, который часто называют «песочницей». Особенность песочницы состоит в том, что она физически не соединена ни с одной из сред трехуровневой архитектуры ERP-системы. Поэтому все реализуемые настройки и разработки остаются исключительно в ней. Песочница используется для проверки гипотез, выполнения критических интеграционных разработок, внедрения малоизвестных обновлений и активации необратимых настроек. Как правила, песочница полностью перезатирается и обновляется на регулярной основе. Достаточно часто песочницей называют систему, соединенную со средой разработки, т.е. фактически речь идет уже о четырех уровневой архитектуре ERP-систем. В этом случае среда является песочницей лишь формально, так как она не позволяет выполнять свою основную задачу: вести критические настройки и разработки, не боясь нанести вред трехуровневой ERP-архитектуре.
Полный текст статьи: https://corpinfosys.ru/archive/2018/issue-4/131-2018-4-systemprepstrategy
