Стратегия реализации в проектах имплементации корпоративных информационных систем

Подробности
Опубликовано: 03.04.2018 10:26
Автор: Прядильников Егор Вячеславович
Просмотров: 3522
Стартапы

Аннотация: в статье содержится описание стратегии реализации ERP-систем. Рассматривается соглашение по наименованию технических объектов, задающее маску имен всех новых разрабатываемых и настраиваемых сущностей информационной системы. Анализируются требования из регламента разработки по вынесению константных переменных в отдельную подпрограмму, обязательному ведению на селекционном экране программы параметров, характеризующих оргуровни компании, а также проверке полномочий и ограничении выборки данных на их основе.
Скачать: PDF (статья), PDF (выпуск №2).
Ключевые слова: разработка ERP-системы, создание ERP-системы, настройка ERP, кастомизация ERP, кастомизации в 1С, naming convention, TVARVC SAP, селекционный экран SAP, транспортные запросы SAP, Z транзакция в SAP, SAP SPRO настройка, SAP IMG SPRO, ABAP SAP, ABAP/4, ABAP workbench, SE80.

Введение

Внедрение современных корпоративных информационных систем класса ERP/ERP2, представляющих сегодня по существу преднастроенные коробочные программные продукты, сильно отличается от имплементации решений, разрабатываемых в рамках проекта «с нуля». В ERP-системах реализация пользовательских требований может осуществляться как путем конфигурирования, так и разработки. Обычно порядка 30% требований покрываются за счет донастройки ERP-системы, остальная часть требует программной доработки.

После успешного продуктивного запуска ERP-системы, работа над ней не останавливается. Законодательные требования и рыночная обстановка диктуют новые требования, которые также должны быть реализованы в информационной системе. Поэтому поток программных изменений ERP-системы имеет место быть на протяжении всего ее жизненного цикла. Чем больше доработок осуществляется в корпоративной информационной системе, тем актуальнее становится вопрос качества программных разработок.

В отличие от гибких методологий внедрения, классические каскадные методы требуют изначального проектирования программы, что отражается в функциональной спецификации на разработку. Предполагаемые настройки же описываются в документах конфигурации. Оба документа являются ключевыми результатами фазы проектирования. Для обеспечения высокого качества реализации настроек и разработок согласно упомянутым документам необходимо единообразно подходить к вопросам конфигурирования и программирования, что обычно описывается в стратегии реализации. В рамках данной статьи мы остановимся на ключевых моментах подготовки такой стратегии.

Цель и задачи

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

  • рассмотрение соглашения по наименованию;
  • обзор правил разработки программных продуктов;
  • подготовка стратегии реализации.

1. Принципы наименования технических объектов

В процесс разработки ERP-системы формируется программный код, описывающий ту или иную функцию системы, объединенный в программу. Каждая программная разработка характеризуется уникальных наименованием. Однако это не единственный технический объект, генерируемый при разработке. Создаются новые объекты таблиц баз данных, фоновых задач, кодов транзакций, элементов данных, процедур и др., каждый из которых дифференцируется названием. Почему мы делаем такой акцент на названии, позвольте объяснить. Любой вендор регулярно высылает пакеты обновлений своих продуктов, выполняющие изменения программ и прочих системных объектов. Поиск программ для обновления ведется по названию. Поэтому, если вы изменили стандартную программу ERP-комплекта, то пакет обновлений может ее заменить, тем самым вы потеряете свои правки. Если мы говорим о системе SAP ERP, то в ней все клиентские программы могут начинаться только с символов X, Y или Z, чтобы избежать подобных недоразумений (рис. 1). Компании, в которых доработки поставлены на конвейер, пошли дальше и предложили правила (маски) наименования всех объектов ERP-системы. Допустим, первый символ характеризует клиентскую разработку, следующие несколько символов отводятся под код страны, далее задается функциональная область, тип разработки и т.д. Свод правил назвали соглашением по наименованию объектов (Naming convention), который преимущественно готовится на стороне заказчика силами программистов [1].

Пример принципа наименования технических объектов

Рис. 1. Пример принципа наименования технических объектов 

Поэтому, если в ERP-проекте готовятся документы спецификаций на разработку или настроек, то необходимо заблаговременно выяснить наличие правил наименования, в противном случае все придется переделывать и ретестировать.

2. Регламенты качества ПО и реализация программного кода

Помимо соглашения о наименовании объектов могут присутствовать регламенты качества разрабатываемого программного обеспечения [2]. Здесь речь идет об обязательной логике, которая должна быть реализована в приложении, в частности:

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

Реализация программного кода часто требует указания константных переменных. Одним из самых распространённых требований является запрет на указание конкретного значения в теле программы. Для выполнения этого правила, константные переменные выносятся в отдельную подпрограмму или настроечную таблицу, а в самой программе делается лишь ссылка. Кроме того, на одну и ту же константу могу ссылаться различные программы. Тем самым централизация ведения константных переменных исключает необходимость изменения каждой из программ в случае обновления значения константы. На рисунке 2 показан пример настроечной таблицы из системы SAP ERP, позволяющей вести константные переменные и их значения.

Пример настроечной таблицы для хранения константных значений

Рис. 2. Пример настроечной таблицы для хранения константных значений 

3. Организационные уровни разрабатываемой программы

Следующим распространенным правилом, предъявляемым к программным разработкам и их описанию в документах спецификаций и настроек, является обязательное указание организационных уровней на селекционном экране разрабатываемой программы. Под селекционным экраном подразумевается первая экранная форма приложения при ее запуске. ERP-системы являются транзакционными, т.е. ориентированными на обработку большого массива данных, поэтому, чтобы максимально ограничить выборку, применяется селекционный экран (рис. 3), где пользователь может задать критерии фильтрации. Помимо сокращения объема выбираемых данных, организационные уровни помогают выстраивать проверку ролей и полномочий пользователей. Это становится возможным и обязательным, так как сущность оргуровня является обязательным атрибутом технических ролей системы ERP.

Пример указания оргуровней на селекционном экране программы

Рис. 3. Пример указания оргуровней на селекционном экране программы 

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

4. Содержание стратегии разработки

Давайте разберемся, что же должно войти в содержание стратегии разработки и настройки ERP-системы, согласно рассмотренному выше материалу:

  • соглашение по наименованию технических объектов, в частности, требуется ли его создание «с нуля» силами исполнителя или соблюдение при наличии у заказчика;
  • процедура контроля качества разрабатываемых программных продуктов, а именно: ведется или нет контроль качества на стороне заказчика.

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

Заключение

Подведем итоги работы. Соглашение по наименованию технических объектов в проектах внедрения и развития ERP-систем определяет модель зрелости процессов разработки. При имплементации ERP-решения «с нуля» достаточно часто соглашение игнорируется или вовсе отсутствует, что частично можно понять из-за большого объема выполняемых проектных работ. Однако, если речь заходит о проектах развития информационных систем, проводимых намного позже базового ERP-внедрения, отсутствие соглашения свидетельствует о низкой культуре модификации программной системы. Что неминуемо приводит к беспорядку в системе, дублированию данных и сложностях при детективном анализе ошибок. Формирование стратегии реализации позволяет задать единое понимание правил выполнения настроек и ведения разработок, а также порядка контроля их качества. Максимальный эффект от использования стратегии реализации можно достичь лишь при ее применении совместно с концепциями тестирования и технической подготовки систем. О чем вы можете узнать из отдельных статей. 

Литература 

  1. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: уровень приложений / МГТУ МИРЭА. - М., 2017. – URL: 12-erp/52-erp-8-applicationlevel.
  2. Dmitry Yu. Stepanov, Mikhail N. Statsenko. Analysis of functional requirements relevant for developing corporate information systems // Естественные и технические науки. – 2021. – vol.160, №9. – p.98-103. – URL: https://stepanovd.com/science/article/113-2021-4-requirements .

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

Прядильников Е.В. Стратегия реализации в проектах имплементации корпоративных информационных систем // Корпоративные информационные системы. – 2018. – №2 – С. 10-16. – URL: https://corpinfosys.ru/archive/issue-2/130-2018-2-developmentstrategy.

Стратегия реализации в проектах имплементации корпоративных информационных систем

Об авторе

 Прядильников Егор Вячеславович Прядильников Егор Вячеславович – эксперт в области разработки программных решений для корпоративных информационных систем с использованием среды ABAP. Принимал участие в проектах по реализации отчетов, интерфейсов, программ обработки данных, формуляров и прочих расширений различной сложности. Опыт разработки программных приложений более 15 лет. Адрес контактной электронной почты: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра..

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

  1. Стартапы;
  2. Стратегия реализации в проектах КИС.
  3. Управление изменениями в проектах ERP-систем;
  4. Стратегия анализа в проектах внедрения ERP-систем;
  5. Использование SQL-запросов при подготовке спецификаций.