Г.4.1. Традиционные стандартные программные решения

 

Традиционные стандартные программные решения для различных аспектов бизнеса представляют собой интегрированные прикладные системы, управляемые транзакциями. Нередко эти решения состоят из интегрированных программ и предполагают программное управление процессами, что не вполне вписывается в концепцию АБИ, где управление реализуется системами workflow.

Однако при условии разбивки прикладных систем на компоненты и при наличии у них интерфейса для вызова удаленных процедур (RPC) системы workflow могут инициировать выполнение этих программных модулей или транзакций. Например, SAP R/3 располагает интерфейсом для вызова удаленных функций (RFC). При применении независимых систем workflow для управления стандартными программами последние разделяются на функции обработки и поток управления, поступающий от workflow. Это означает, что производитель больше не отвечает за целостность решения. Для переноса этого гибкого метода на архитектуру стандартных программных решений в этих решениях используются специализированные системы workflow для управления процессами. К сожалению, такие системы workflow зачастую тесно связаны с конкретной системой и не подходят для решений, в основе которых лежат гетерогенные системы.

Эти модели позволяют конфигурировать стандартные программы при условии, что такие программы описаны семантическими моделями, связанными с репозиторием системы.

Рис. 50. Индивидуализация моделей-прототипов

С помощью перекрещивающихся линий можно убрать с экрана ненужные функции бизнес-процесса, предлагаемого прикладной системой. На рис. 50 схематически изображена процедура работы с моделями в системе SAP R/3. Сначала определяется модель-прототип соответствующей области бизнеса, (розничная торговля, банковское дело, промышленность и т. д.). В нашем примере мы взяли в качестве вертикального рынка «промышленность». В рамках решения для вертикального рынка выбираются конкретные бизнес-процессы. В нашем примере это производство, закупка и продажа. Для получения бизнес-процессов, специфических для данного клиента из данной области деятельности, из процессов, представленных в виде диаграмм EPC, удаляются ненужные функции и зависящие от них события. В процедуру правки заложены определенные правила, позволяющие проследить возможные комбинации и взаимозависимости в рамках осуществляемых бизнес-процессов. Например, отмена функции «хранение на складе» требует и удаления функции «выдача со склада».

Информация о вносимых изменениях передается непосредственно модулю управления конфигурацией системы.

Каждая бизнес-функция позволяет ввести дополнительные параметры. Например, функция «формирование заказа на поставку» может относиться к отделу отправки, стороннему поставщику, складу или отделу продаж. Очевидно, что такой заказ требует более подробной спецификации. Руководство по управлению реализацией (IMG) системы SAP R/3 содержит дополнительные компьютеризованные средства поддержки. Как и в моделях процессов, для конфигурирования стандартного программного обеспечения можно использовать другие типы моделей, такие как модели данных, функциональные и организационные модели. Можно, например, удалять информационные объекты из модели данных стандартной программы или, напротив, добавлять новые. Можно удалять атрибуты или изменять их длину. Эта информация также передается системе, которая автоматически изменяет настройку экранов.

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

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

Функция «формирование запроса» запрашивает пользователя, какой экран используется в SAP R/3. В соответствии с моделью процесса щелкнув на этой функции (или выбрав команду), пользователь может, не углубляясь в тонкости, вызвать SAP R/3. Этот экран изображен внизу слева.

Для индивидуальной настройки этой функции вызывается инструмент настройки, содержащийся в Руководстве по управлению реализацией (IMG). В верхнем левом окне показаны доступные параметры функции.

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

Поскольку сопровождение высокоинтегрированных систем и оперативное обновление руководств по обучению и документированию для всей системы требуют больших усилий, а производители обычно «неповоротливы» с разъяснением их политики по основным версиям, эти системы следует разбивать на более простые блоки (модули, компоненты, агенты, бизнес-объекты). Для компонентов такие алгоритмы вполне удовлетворительны. Кроме того, отсутствие жесткой связи между компонентами облегчает их сопровождение, а обновление их документации менее трудоемко.

Разбиение прикладных систем на модули — идея не новая. Модули предоставляют в распоряжение пользователей четко описанные интерфейсы, которые являются для них единственным средством обмена информацией. Пользователи не обременены деталями, связанными с реализацией модуля (эта информация от них «спрятана»).

 

 

 

Рис. 51. Интерактивное построение бизнес-процесса и настройка стандартной программы

И все же модульный принцип имеет один недостаток — во многих случаях он не допускает никаких вариаций. Внесение модификаций в какой-нибудь модуль для некоторых приложений немедленно требует изменений в программном коде. Иногда даже возникает необходимость в разных версиях. Это приводит к нагромождению модульных концепций и ограничивает возможность их многократного применения.

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

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