Введение
Внедрение современных корпоративных информационных систем класса ERP/ERP2, представляющих сегодня по существу преднастроенные коробочные программные продукты, сильно отличается от имплементации решений, разрабатываемых в рамках проекта «с нуля». В ERP-системах реализация пользовательских требований может осуществляться как путем конфигурирования, так и разработки. Обычно порядка 30% требований покрываются за счет донастройки ERP-системы, остальная часть требует программной доработки.
После успешного продуктивного запуска ERP-системы, работа над ней не останавливается. Законодательные требования и рыночная обстановка диктуют новые требования, которые также должны быть реализованы в информационной системе. Поэтому поток программных изменений ERP-системы имеет место быть на протяжении всего ее жизненного цикла. Чем больше доработок осуществляется в корпоративной информационной системе, тем актуальнее становится вопрос качества программных разработок.
В отличие от гибких методологий внедрения, классические каскадные методы требуют изначального проектирования программы, что отражается в функциональной спецификации на разработку. Предполагаемые настройки же описываются в документах конфигурации. Оба документа являются ключевыми результатами фазы проектирования. Для обеспечения высокого качества реализации настроек и разработок согласно упомянутым документам необходимо единообразно подходить к вопросам конфигурирования и программирования, что обычно описывается в стратегии реализации. В рамках данной статьи мы остановимся на ключевых моментах подготовки такой стратегии.
Цели и задачи
Цель статьи заключается в рассмотрении стратегий реализации программных продуктов в проектах имплементации ERP-систем. Это позволит реализовать программное решение с высоким качеством и вовремя перейти в режим продуктивной эксплуатации, что столь значимо для заказчика. Достижение цели потребует решения следующих задач:
- рассмотрение соглашения по наименованию;
- обзор правил разработки программных продуктов;
- подготовка стратегии реализации.
1. Принципы наименования технических объектов
В процесс разработки ERP-системы формируется программный код, описывающий ту или иную функцию системы, объединенный в программу. Каждая программная разработка характеризуется уникальных наименованием. Однако это не единственный технический объект, генерируемый при разработке. Создаются новые объекты таблиц баз данных, фоновых задач, кодов транзакций, элементов данных, процедур и др., каждый из которых дифференцируется названием. Почему мы делаем такой акцент на названии, позвольте объяснить. Любой вендор регулярно высылает пакеты обновлений своих продуктов, выполняющие изменения программ и прочих системных объектов. Поиск программ для обновления ведется по названию. Поэтому, если вы изменили стандартную программу ERP-комплекта, то пакет обновлений может ее заменить, тем самым вы потеряете свои правки. Если мы говорим о системе SAP ERP, то в ней все клиентские программы могут начинаться только с символов X, Y или Z, чтобы избежать подобных недоразумений (рис. 1). Компании, в которых доработки поставлены на конвейер, пошли дальше и предложили правила (маски) наименования всех объектов ERP-системы. Допустим, первый символ характеризует клиентскую разработку, следующие несколько символов отводятся под код страны, далее задается функциональная область, тип разработки и т.д. Свод правил назвали соглашением по наименованию объектов (Naming convention), который преимущественно готовится на стороне заказчика силами программистов [1].
Рис. 1. Пример принципа наименования технических объектов
Поэтому, если в ERP-проекте готовятся документы спецификаций на разработку или настроек, то необходимо заблаговременно выяснить наличие правил наименования, в противном случае все придется переделывать и ретестировать.
Полный текст статьи: https://corpinfosys.ru/archive/issue-2/130-2018-2-developmentstrategy
