Шеер. Бизнес-процессы. Основные понятия. Теория. Методы

Подождите немного. Документ загружается.

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

С помощью перекрещивающихся линий можно убрать с экрана ненужные функции

бизнес-процесса, предлагаемого прикладной системой. На рис. 50 схематически изображена

процедура работы с моделями в системе SAP R/3. Сначала определяется модель-прототип

соответствующей области бизнеса, (розничная торговля, банковское дело, промышленность

и]т.]д.). В нашем примере мы взяли в качестве вертикального рынка «промышленность». В

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

примере это производство, закупка и продажа. Для получения бизнес-процессов,

специфических для данного клиента из данной области деятельности, из процессов,

представленных в виде диаграмм EPC, удаляются ненужные функции и зависящие от них

события. В процедуру правки заложены определенные правила, позволяющие проследить

возможные комбинации и взаимозависимости в рамках осуществляемых бизнес-процессов.

Например, отмена функции «хранение на складе» требует и удаления функции «выдача со

склада».

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

конфигурацией системы.

Каждая бизнес-функция позволяет ввести дополнительные параметры. Например,

функция «формирование заказа на поставку» может относиться к отделу отправки, стороннему

поставщику, складу или отделу продаж. Очевидно, что такой заказ требует более подробной

спецификации. Руководство по управлению реализацией (IMG) системы SAP R/3 содержит

дополнительные компьютеризованные средства поддержки. Как и в моделях процессов, для

конфигурирования стандартного программного обеспечения можно использовать другие типы

моделей, такие как модели данных, функциональные и организационные модели. Можно,

например, удалять информационные объекты из модели данных стандартной программы или,

напротив, добавлять новые. Можно удалять атрибуты или изменять их длину. Эта информация

также передается системе, которая автоматически изменяет настройку экранов.

Непосредственное взаимодействие между средствами моделирования, семантическими

моделями и прикладной системой видоизменяет стратегию реализации стандартного ПО.

Прежде было принято придерживаться жесткого разделения на фазы с применением анализа

«как есть» для выявления слабых мест. Позже были разработаны целевые концепции,

независимые от конкретного стандартного обеспечения, которые реализовывались с помощью

методов индивидуальной настройки. В настоящее время разные фазы все чаще реализуются

одновременно и во взаимодействии друг с другом, что открывает путь к тесному

сотрудничеству между теми, кто непосредственно занимается бизнесом, и персоналом по

внедрению системы, позволяя параллельно решать вопросы бизнеса и вопросы внедрения. Это

иллюстрирует пример на рис. 51. Для наглядности все четыре окна показаны отдельно. В

реальном приложении эти окна отображаются на одном экране, предоставляя пользователю

всю информацию сразу.

В верхнем правом окне представлен фрагмент модели бизнес-процесса, выполненной с

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

же добавляется дополнительная ветвь процесса, отсутствующая в стандартной программе.

Функция «формирование запроса» запрашивает пользователя, какой экран используется в

SAP R/3. В соответствии с моделью процесса щелкнув на этой функции (или выбрав команду),

пользователь может, не углубляясь в тонкости, вызвать SAP R/3. Этот экран изображен внизу

слева.

Для индивидуальной настройки этой функции вызывается инструмент настройки,

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

показаны доступные параметры функции.

С помощью инструмента моделирования результаты обсуждений, выбранные параметры,

нерешенные вопросы и]т.]п. сохраняются в функции, как показано в нижнем правом окне. Это

позволяет подробно документировать инжиниринг бизнес-процессов как с точки зрения самого

бизнеса, так и с точки зрения ИТ. Такая документация впоследствии поможет разрешить

проблемы, возникающие при использовании этого ноу-хау для мониторинга текущего проекта

и для реализации последующих.

Поскольку сопровождение высокоинтегрированных систем и оперативное обновление

руководств по обучению и документированию для всей системы требуют больших усилий, а

производители обычно «неповоротливы» с разъяснением их политики по основным версиям,

эти системы следует разбивать на более простые блоки (модули, компоненты, агенты, бизнес-

объекты). Для компонентов такие алгоритмы вполне удовлетворительны. Кроме того,

отсутствие жесткой связи между компонентами облегчает их сопровождение, а обновление их

документации менее трудоемко.

Разбиение прикладных систем на модули — идея не новая. Модули предоставляют в

распоряжение пользователей четко описанные интерфейсы, которые являются для них

единственным средством обмена информацией. Пользователи не обременены деталями,

связанными с реализацией модуля (эта информация от них «спрятана»).

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

И все же модульный принцип имеет один недостаток — во многих случаях он не

допускает никаких вариаций. Внесение модификаций в какой-нибудь модуль для некоторых

приложений немедленно требует изменений в программном коде. Иногда даже возникает

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

ограничивает возможность их многократного применения.

С другой стороны, объектно-ориентированные концепции описываются на уровне типов,

что позволяет при внесении изменений создавать подтипы определенного типа объекта,

устраняя необходимость изменять исходный тип объекта. Подтипы описывают лишь

отклонение от исходного типа объекта. Это придает системе гибкость и повышает

многократность использования спроектированных объектов.

Дробление монолитных прикладных систем на все более мелкие составные части

прекрасно согласуется с расширяющимися возможностями объектно-ориентированных

концепций. Это подводит нас к понятию «компонентного программного обеспечения», на

котором, собственно и базируется внедрение реальных приложений.

Г.4.2. Компонентное программное обеспечение

Основная идея компонентного ПО заключается в сборке прикладных систем из отдельных

стандартных компонентов, разработанных разными поставщиками. Обмен сообщениями

обеспечивает между компонентами нежесткую связь. Таким образом, при разработке программ

акцент с программирования смещается в сторону проектирования решений и сборки

компонентов. Концепция использования компонентов тесно связана с основными принципами

объектно-ориентированного подхода. Объектно-ориентированные концепции не новы, однако в

последние годы их роль в сфере создания реальных приложений заметно возрастает. Сегодня

новые приложения, как правило, разрабатываются на базе объектно-ориентированных

технологий: традиционное стандартное ПО разбивается на структуры объектов по принципу

«сверху вниз» и затем проводится по принципу «снизу вверх» весь цикл разработки новых

систем.

Г.4.2.1. Объекты

Объектная ориентация основана на концепции инкапсуляции объектов вместе с

соответствующими описаниями данных и применяемыми при этом методами (функциями).

Пользователи активизируют методы с помощью сообщений, открывающих доступ к данным.

Конкретные детали реализации метода от пользователя скрыты.

Системы разрабатываются на уровне типов, т.]е.]похожие объекты группируются в классы.

В этой книге мы не разграничиваем понятия «объект» (уровень экземпляров) и «классы»

(уровень типов), а говорим просто об объектах. О каком именно понятии идет речь, становится

ясно из контекста. Еще одной характеристикой объектов является их наследственная

функциональность. Она позволяет подчиненным классам наследовать методы и атрибуты,

присущие вышестоящим классам, посредством обобщения или специализации. Наследование

лежит в основе принципа многократного использования.

Очевидно, что характеристики объектно-ориентированных методов можно было бы

описать гораздо подробнее, однако для целей данной работы достаточно и беглого обзора. Рис.

52 иллюстрирует объектно-ориентированное описание процесса «обработка заказа»,

рассмотренного в разделе Б.1. Здесь представлены объекты, их имена, атрибуты и методы.

Показан также обмен сообщения ми, включая метод соответствующего целевого объекта,

передаваемые данные и данные, содержащиеся в ответе. В отличие от рис. 5, где приведен

информационный поток, здесь мы дифференцируем функции, активизирующие обмен

данными. Поток сообщений, который является результатом потока управления бизнес-

процессом, использовать необязательно, так как последовательность выполнения функций

внутри объектов не указана. Напомним, что бизнес-процессы характеризуются рядом потоков,

включая функциональный, выходной, информационный и организационный. В управлении

workflow акцент делается на функциональном потоке, тогда как в фокусе объектно-

ориентированной концепции находится поток сообщений между информационными объектами.

Рис. 52. Объектно-ориентированное представление процесса «обработка заказа»

Рис. 53. Бизнес-объекты в примере «обработка заказа»

Объектная ориентация лежит в основе различных языков программирования (Java, C++,

и]т.]д.). При разработке программ объектные библиотеки позволяют многократно использовать

протестированные объекты.

Однако реализация этих базовых принципов с помощью объектно-ориентированного

языка программирования ни в какой мере не гарантирует повышения эффективности по

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

причин громоздкости комплексных систем является чрезмерное структурирование их объектов.

К тому же сильно структурированные объекты трудно активизировать с помощью приемлемой

системы workflow. Именно поэтому объекты нередко объединяются в более крупные единицы

— так называемые «бизнес-объекты», включающие прикладную информацию о

взаимодействии внутренних объектов.

Г.4.2.2. Бизнес-объекты

Степень структурирования в рамках объектно-ориентированных концепций (и как

следствие программирования) для разработки «стиля сборки» программного обеспечения дает

слишком мелкие объекты. Для этой цели требуются логические блоки «покрупнее». Например,

объектно-ориентированная концепция UML предлагает использование так называемых

«пакетов», описывающих более крупные объекты в соответствии с их прикладной функцией.

Такой тип представления, рассчитанный на приложение, легче понять, если обозначить его как

«бизнес-объект». Бизнес-объекты включают бизнес-процессы вместе с соответствующими

данными и функциями, выполняемыми для их обработки. Таким образом, бизнес-объекты

содержат несколько объектно-ориентированных объектов, о которых говорилось выше. Их

характеристики, такие как инкапсуляция, многократное использование (благодаря

наследованию) и нежесткая связь (построенная на обмене сообщений), вытекают из объектно-

ориентированной концепции.

Пример обработки заказа, приведенный на рис. 52, содержит три бизнес-объекта: «прием

заказа», «заказ на поставку» и «изготовление». На рис. 53 эти бизнес-объекты представлены

через их характеристики. Интерфейсы различных объектов, активизируемых извне, «проходят

через» бизнес-объекты и обозначаются точками вдоль внешних границ объектов. Однако

интерфейсы, используемые только в рамках бизнес-объекта, остаются в пределах внутренних

объектов. Бизнес-объекты не предполагают заранее заданную степень структурирования.

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

единицы приложения, например на то, как тесно связаны их содержание и организационная

структура, насколько прочны внутренние связи (и насколько слабы внешние). При выборе ее

учитывается также возможность многократного использования бизнес-объектов и их

эффективности.

Бизнес-объекты не обязательно должны создаваться из индивидуальных, жестко объектно-

ориентированных объектов. Когда существующая система разбита по принципу «сверху-вниз»,

их можно формировать из обычных программных компонентов. Главным условием при этом

является соответствие бизнес-объекта объектно-ориентированным принципам, как это

реализовано, например, в SAP R/3. На сегодняшний день SAP предоставляет 170 бизнес-

объектов, хранящихся в репозитории бизнес-объектов (BOR). Их внутренняя структура описана

на языке АВАР 4GL, который (пока) не является объектно-ориентированным.

Г.4.2.3. Java-аплеты

Компонентное программное обеспечение поддерживается и программными концепциями,

где используются простейшие аппаратные клиенты — так называемые сетевые компьютеры.

Приложения хранятся в сети (Интернете или интрасетях) и запускаются клиентом по мере

надобности. В этом отношении функциональные возможности Java представляют особую

ценность. Благодаря использованию в качестве пользовательских интерфейсов Java-аплетов и

популярных Web-браузеров стала реальна платформно-независимая обработка.

Для создания Java-аплета разрабатывается исходный код в среде разработки Java в любой

системе. Затем законченная программа — так называемый байт-код — компилируется в среде

разработки, а не в исполняемой программе. Байт-код не зависит от платформы, и чтобы

обеспечить его соответствие техническим требованиям клиентской системы, перед

исполнением его необходимо еще раз интерпретировать. Это осуществляется при помощи

виртуальной машины Java (JVM) после загрузки. JVM адаптирует байт-код к различным

клиентским требованиям.

Язык Java можно использовать на трех уровнях. Команды могут вводиться прямо в текст

HTML-страницы как исходный код JavaScript. Этот код команд лишь отчасти идентичен Java,

хотя оба языка основаны на C++. Однако JavaScript позволяет реализовать лишь небольшие

приложения, например, для проверки значений или отображения «шапки» в строке состояния

браузера. Кроме того, JavaScript не способен обеспечить осуществлять прямую связь между

клиентом и сервером.

Далее байт-код аплета передается клиенту в дополнение к загружаемой HTML-странице.

Переданный байт-код проверяется и интерпретируется на клиенте, после чего аплет

выполняется. Аплеты запускаются только в среде браузера, без него их исполнение

невозможно. Однако в рамках аплетов может происходить дальнейшее общение между

сервером и клиентом. Аплеты способны загружать документы с сервера и обрабатывать их до

того, как они будут отправлены обратно на сервер для завершения процесса. Приложения могут

выполняться независимо от среды браузера. Все, что им нужно — это виртуальная машина Java

для передачи байт-кода. Приложения позволяют разрабатывать независимые приложения,

конструктивные блоки которых по мере необходимости загружаются на клиентский компьютер

через сеть. Как аплеты, так и приложения поддерживают компонентное ПО. Установка и

сопровождение ненужных модулей не требуются. Системы собираются индивидуально в

соответствии со спецификациями заказчика.

Эту концепцию можно включить в инфраструктуру АБИ (см. рис. 54). Процессы,

управляемые на уровне III системой workflow, описываются на уровне моделирования.

Приложения на уровне IV могут быть доступны в виде байт-кода на серверах глобально

распределенных приложений. При открытии папки для обработки какого-либо события система

workflow создает Web-страницу, соответствующую данному этапу обработки. Эта Web-

страница запускает аплет и вызывает сервер приложений. Подключившись к аплету,

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

передаются системе workflow.

Данные включают также информацию о времени и продолжительности процесса, которая

агрегируется с помощью системы workflow и возвращается для управления процессами. Этот

процесс поддерживает любую операционную систему и аппаратную платформу. Нужные для

обработки аплеты, включая обрабатываемый объект, загружаются через пользовательский

интерфейс браузера. Пользователи могут выполнять функции децентрализовано. Клиенты

имеют непосредственный доступ к любому методу. После обработки преобразованные объекты

возвращаются на сервер, который передает их на дальнейшую обработку.

В процессе обработки событий серверы workflow постоянно контролируют запуск любых

других серверов и обработку данных. Супервизоры могут запрашивать информацию о времени

и продолжительности процесса, а также о состоянии процесса в любой момент, хотя доступ к

объектам во время их обработки невозможен.

Г.4.2.4. Проблемы стандартизации

Для сборки прикладных систем из гетерогенных модулей необходимы стандартизованные

интерфейсы, особенно для связи со средами клиент-сервер. В настоящее время попытки такой

стандартизации предпринимают различные организации, в том числе Группа по технологии

управления объектами (Object Management Group — OMG) и Группа по разработке открытых

приложений (Open Application Group — OAG). Ту же цель преследуют промышленные

стандарты, разрабатываемые крупнейшими поставщиками (Microsoft, SAP и другие).

Консорциум OMG объединяет поставщиков разной продукции. В начале 1998 года эта

организация насчитывала более 800 членов. Предложенная ею архитектура управления

объектами (ОМА) представляет собой инфраструктуру для распределения и обеспечения

взаимодействия объектно-ориентированных программных модулей в сетевых гетерогенных

системах (см. рис. 55).

Рис. 54. Связывание аплетов со зданием ARIS

100