CC BY
81
Электронный журнал Cloud of Science. 2015. T. 2. № 2
http:/ / cloudofscience.ru ISSN 2409-031X
Формирование требований к информационной системе предприятия
М. В. Некрасов, В. В. Белов
Рязанский государственный радиотехнический университет, 390005, Рязань, ул. Гагарина, 59/1
e-mail: [email protected]
Аннотация. В статье рассматривается применение корпоративных информационных систем для нужд управления предприятием, приводится обзор наиболее актуальных тенденций в сфере формирования и представления требований к информационной системе.
Ключевые слова: корпоративные информационные системы, сервис-ориентированная архитектура, Business Process Execution Language, Business Process Management.
В условиях рыночной экономики целесообразно рассматривать корпоративные информационные системы как бизнес инструмент. Стоит отметить, что корпоративные информационные системы весьма удобны для руководителей компаний, которым необходимо принимать решения, учитывая весьма широкий спектр факторов внешней и внутренней среды. Очевидно, что человеку зачастую не под силу удержать столь обширный объем информации в голове, и при принятии решений следует опираться на какой-то достоверный и полный источник информации, которым и является корпоративная информационная система.
Статья написана, основываясь на опыте анализа процесса внедрения КИС «Флагман» на одном из машиностроительных предприятий Рязанской области и подготовкой плана дальнейшей автоматизации. Система «Флагман» состоит из отдельных контуров [1]. На данном предприятии внедрение системы было решено начать с контура управления основным производством. Распараллелить процесс внедрения и автоматизировать всю деятельность предприятия сочли не рациональным. В последствии выяснилось, что одного этого контура не достаточно. Кроме того были существенно превышены запланированные сроки внедрения. Одной из причин задержки стало очень долгое изучение специфики завода специалистами компании-разработчика системы. Усложнялось все это наличием оборонной продукции в номенклатуре завода. В тоже время не смотря на все усилия разработчиков они не являются сотрудниками завода, а следовательно не до конца поняли ряд аспектов его деятельности, что привело к некорректности организации работы системы. Внедрение коробочных систем на крупных предприятиях далеко не всегда эффективно, а объяснить сотрудникам сторонних организаций всю специфику ра-
СИСТЕМНЫМ АНАЛИЗ И МОДЕЛИ В ЭКОНОМИКЕ
боты предприятия не всегда возможно. Возникает вопрос о более эффективных инструментах организации информационных систем подобных предприятий.
Корректность формулировки требований определяет качество информационной системы. Необходимость определения требований к информационной системе возникает в следующих случаях:
- в момент выбора новой информационной системы;
- при подготовке тендерной документации;
- при заключении договора на разработку или настройку выбранной информационной системы;
- при уточнении (детализации) потребностей бизнеса в процессе разработки или настройки системы;
- при необходимости внесения изменений в систему в ходе эксплуатации.
Рассматривая информационные системы как средство управления бизнес-
процессами организации следует уточнить что мы подразумеваем под термином бизнес-процесс.
Бизнес-процесс — это последовательность действий, направленных на преобразование информационных и материальных потоков в целях увеличения их ценности для клиента, или на создание добавленной стоимости продукта, или на оказание услуг, удовлетворяющих потребности клиента [2]. Таким образом, бизнес-процесс — это последовательность действий, направленных на решение какой-либо предпринимательской задачи.
В контексте рассмотрения информационных систем, бизнес-процесс — это множество внутренних шагов (функций), начиная с входных данных и сырья и заканчивая конкретным продуктом или услугой, организованных с помощью кис предприятия.
Применение информационных технологий для решения управленческих задач практикуется еще со времен появления первых ЭВМ. В начале 1990-х годов активно развивалась тенденция реинжиниринга. Основатели реинжиниринга Том Давен-порт, Майкл Хаммер и Джеймс Чампи исходили из идеи несовершенности существующих бизнес-процессов а следовательно необходимости их коренного изменения [3]. Ими была разработана концепция реинжиниринга бизнес-процессов BPR (Business Process Redesign или Business Process Reengineering) — концепция реинжиниринга бизнес-процессов, развивающая идею необходимости кардинальной перестройки всех бизнес-процессов на предприятии перед началом автоматизации работы данного предприятия. Однако, не смотря на очевидную необходимость перестройки бизнес-процессов, данная концепция обладала существенным недостатком: в процессе резкого переходе с одного типа организации на другой неизбежен
период, когда старое уже не работает, а новое еще не работает. Более того, сама программа перехода часто оказывается несостоятельной по следующим причинам:
1) информация о текущем положении дел на предприятии, зафиксированная в модели AS-IS, может устареть — некоторые бизнес-процессы, подлежащие изменению, оказываются уже измененными по причине их вопиющей нерациональности; отделы, подлежащие расформированию и объединению с другими отделами, оказываются уже объединенными, но вовсе не с предполагаемыми планом реинжиниринга и т. п.;
2) представления о рациональной схеме построения бизнес-процессов, зафиксированные в модели TO-BE, могут измениться непосредственно во время их перестройки, — время вносит коррективы. Альтернативой данной концепции является BPМ.
BPM (Business Process Management) — концепция постоянного (перманентного) улучшения бизнес-процессов предприятия, то есть изменений эволюционного характера [ 4]. Продуктивность данной концепция обусловлена появлением BPMS (Business Process Management System / Tool) — принципиально нового класса программных продуктов, предназначенных для реализации концепции BPM [5], основанный на трансляции схем бизнес-процессов в исполняемый код с помощью BPEL. BPEL (Business Process Execution Language) — языка, явившегося первым средством класса BPMS, который поддерживает управление данными, позволяя определить последовательность выполнения сервисов в различных процессах. Отличительной чертой данной концепции стала изменение роли IT-специалистов в проектировании и автоматизации бизнес-процессов. До недавнего времени требовалось глубокое погружение разработчика во все детали функционирования предприятия. BPMS реализует подход отстранения IT-специалистов от проектирования и реализации бизнес-процессов. Менеджеры компании сами принимают решения о реорганизации и сами с помощью графических средств создают модель новых бизнес-процессов, затем эти модели автоматически трансформируются в коды.
Назначение BPMS — трансляция схем (графических диаграмм) бизнес-процессов в исполняемый код.
Именно возможность такой трансляции позволяет реализовать идею постоянного усовершенствования бизнеса:
1) процессы предприятия описываются и автоматизируются в системе BPMS в исходном виде, — в котором они воплощены на текущий момент;
2) затем на основе анализа статистики поведения процессов, процессы постепенно, но непрерывно, совершенствуются. Любое изменение модели процессов немедленно приводит к перегенерации программного кода, реализующего эти процессы.
СИСТЕМНЫМ АНАЛИЗ И МОДЕЛИ В ЭКОНОМИКЕ
Заметим, что изложенное разрушает важнейшее положение реинжиниринга бизнес-процессов, неизменно повторяемое во всех учебниках и публикациях, — недопустимо автоматизировать текущие бизнес-процессы, поскольку они нерациональны. Новая идея BPM — автоматизировать процессы «как есть», а затем медленно их улучшать на основе принципиально нового IT-инструмента BPMS — это наглядное проявление действия закона философии, называемого отрицанием отрицания.
Первым средством класса BPMS явился основанный на XML язык BPEL (Business Process Execution Language), ставший стандартом проектирования и исполнения бизнес-процессов. Первый вариант BPEL появился в 2003 году. BPEL поддерживает управление данными и работу с сообщениями в формате XML, позволяя определить последовательность выполнения сервисов в различных процессах [6].
Применение BPEL в моделировании бизнес-процессов обеспечивает не только устранение разрыва между моделированием и исполнением процессов, но и объединение моделирования с исполнением в единый комплекс.
Для получения кода на языке BPEL часто используют различные BPEL-инструменты, позволяющие на основе визуальной диаграммы автоматически генерировать код, создавая приложение [7]. Такие приложения можно представить как совокупность бизнес-логики описываемого процесса и непосредственно операций, выполняемых сервисами. Использование BPEL приводит к реализации концепции сервисов и SOA (Service-Oriented Architecture) — модульного подхода к разработке программного обеспечения, основанного на использовании распределенных, слабо связанных (loose coupling) заменяемых компонентов, оснащенных стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам. Основопологающим принципом данного подхода является разбиение информационной системы на несколько функционально законченных узлов, называемых сервисами, взаимодействующих между собой. Концепция SOA — это развитие идеи компонентно-ориентированного проектирования систем. Появились новые формы строительных блоков — веб-сервисы, взаимодействующие по собственному протоколу SOAP, которые становятся доминирующими формами компонентов информационной системы [8].
Для данного языка созданы графические редакторы, позволяющие представить BPEL-программы в виде блок схем, однако эти схемы дают скудное представление об исполняемом бизнес-процессе. Для наглядного графического представления процессов используют BPMN (Business Process Modeling Notation) — это система условных обозначений (нотация), предназначенная для моделирования бизнес-процессов.
Моделирование в BPMN осуществляется посредством диаграмм с небольшим числом графических элементов. Выделяют четыре основных категории элементов, показанные на рис. 1.
BPMN
Рисунок 1. Элементы BPMN
Элементы этих четырех категорий позволяют строить простейшие диаграммы бизнес-процессов. Для повышения выразительности модели спецификация BPMN разрешает создавать новые типы объектов потока управления и артефактов.
Объекты потока управления. Объекты потока управления разделяются на три основных типа: события (events), действия (activities) и шлюзы, называемые также логическими операторами (gateways) [2].
События означают нечто случившееся в предметной области и изображаются окружностью. События инициируют действия или являются их результатами.
События категорируются:
1) по месту расположения в процессе — начальные (start), промежуточные (intermediate), завершающие (end);
2) как события обработки или генерации;
3) по типам.
Классификация событий в BPMN показана на рис. 2.
Простые события (plain events) это нетипизированные события, использующиеся, чаще всего, для того, чтобы показать начало или окончание процесса.
События-сообщения (message events) показывают получение и отправку сообщений в ходе выполнения процесса.
События-таймеры (timer events) моделируют события, регулярно происходящие во времени. Также позволяют моделировать моменты времени, периоды и таймауты.
СИСТЕМНЫМ АНАЛИЗ И МОДЕЛИ В ЭКОНОМИКЕ
События Обработка Гене] зация Комментарии
Простые (plain events) О О ID Нетипнзированные события, используются для указания начала или окончания процесса.
Сообщения (message events) <§> © в Показывают получение и отправку сообщений в ходе выполнения процесса.
Таймеры (timer events) ® © Моделируют события, происходящие регулярно моменты времени, периоды и таймаугы.
Ошибки (error events) © 0 Моделируют генерацию и обработку ошибок в процессе. Ошибки могут иметь различные типы.
Отмены (cancel events) © © Инициируют или реагируют на отмену транзакции.
Компенсации (compensation events) © ® ® Инициируют компенсацию или выполняют действия по компенсации.
Условия (conditional events) (D ® Позволяют интегрировать бизнес правила в процесс.
Сигналы (signal events) ® © ¡3 Рассылают и принимают сигналы между процессами. Один сигнал может обрабатываться несколькими получателями (широкое вешание).
Составные (multiple events) © © ® ш Моделируют генерацию и моделирование одного события из множества.
Ссылки (link events) © в Межстраничные соединения. Пара ссылок эквивалентна потоку управления.
Остановы (terminate events) в Приводят к немедленному завершению всего бизнес процесса (во всей диаграмме).
I - Начальные события | | - Промежуточные события ЦЦ - Завершающие события
Рисунок 2. Типы событий в BPMN
События-ошибки (error events) позволяют смоделировать генерацию и обработку ошибок в процессе. Ошибки могут иметь различные типы.
События-отмены (cancel events) инициируют или реагируют на отмену транзакции.
События-компенсации (compensation events) инициируют компенсацию или выполняют действия по компенсации.
События-условия (conditional events) позволяют интегрировать бизнес правила в процесс.
События-сигналы (signal events) рассылают и принимают сигналы между несколькими процессами. Один сигнал может обрабатываться несколькими получателями. Таким образом, события-сигналы позволяют реализовать широковещательную рассылку сообщений.
Составные события (multiple events) моделируют генерацию одного события из множества.
События-ссылки (link events) используются как межстраничные соединения. Пара соответствующих ссылок эквивалентна потоку управления.
События-остановы (terminate events) приводят к немедленному завершению всего бизнес процесса (во всей диаграмме).
Действия изображаются прямоугольниками со скругленными углами. Среди действий различают задания и подпроцессы. Графическое изображение свернутого подпроцесса снабжено знаком плюс у нижней границы прямоугольника. Типы действий в BPMN показаны на рис. 3.
Рисунок 3. Типы действий в BPMN
Задание (task) — это единица работы, элементарное действие в процессе.
Множественные экземпляры (multiple instances) действия показывают, что одно действие выполняется многократно, по одному разу для каждого объекта. Например, для каждого объекта в заказе клиента выполняется один экземпляр действия. Экземпляры действия могут выполняться параллельно или последовательно.
Циклическое действие (loop activity) выполняется, пока условие цикла верно. Условие цикла может проверяться до или после выполнения действия.
Ad-hoc-подпроцесс (ad-hoc subprocess, ad hoc, лат. — «специально для этого») содержит задания. Задания выполняются до тех пор, пока не выполнено условие завершения подпроцесса.
Свернутый подпроцесс (collapsed subprocess) является сложным действием и содержит внутри себя правильную диаграмму бизнес-процессов.
Развернутый подпроцесс (англ. expanded subprocess) также является составным действием, но скрывает детали реализации процесса.
СИСТЕМНЫМ АНАЛИЗ И МОДЕЛИ В ЭКОНОМИКЕ
Шлюзы, или логические операторы изображаются ромбами и представляют точки принятия решений в процессе. С помощью логических операторов организуется ветвление и синхронизация потоков управления в модели процесса. Типы логических операторов показаны на рис. 4.
Оператор исключающего НЛП, управляемый данными Оператор исключающего ИЛИ, управляемый событиями Оператор включающего ИЛИ Оператор И Сложный оператор
Рисунок 4. Типы логических операторов в BPMN
Оператор исключающего «или», управляемый данными (data-based exclusive gateway). Если оператор используется для ветвления, то поток управления направляется лишь по одной исходящей ветви. Если оператор используется для синхронизации, то он ожидает завершения выполнения одной входящей ветви и активирует выходной поток.
Оператор исключающего «или», управляемый событиями (event-based exclusive gateway) направляет поток управления лишь по той исходящей ветви, на которой первой произошло событие. После оператора данного типа могут следовать только события или действия-обработчики сообщений.
Оператор включающего «или» (inclusive gateway) активирует одну или более исходящих ветвей, в случае, когда осуществляется ветвление. Если оператор используется для синхронизации, то он ожидает завершения выполнения одной входящей ветви и активирует выходной поток.
Оператор «и» (parallel gateway), использующийся для ветвления, разделяет один поток управления на несколько параллельных потоков. При этом все исходящие ветви активируются одновременно. Если оператор используется для синхронизации, то он ожидает завершения выполнения всех входящих ветвей, после чего активирует выходной поток.
Сложный оператор (complex gateway) имеет несколько условий, в зависимости от выполнения которых, активируются исходящие ветви. Оператор затрудняет понимание диаграммы, так как условия, определяющие семантику оператора, графически не отображаются на диаграмме. Вследствие этого использование этого оператора нецелесообразно.
Соединяющие объекты. Объекты потока управления связаны друг с другом соединяющими объектами. Существует три вида соединяющих объектов: потоки управления; потоки сообщений; ассоциации [9].
Поток управления изображается сплошной линией, оканчивающейся закрашенной стрелкой. Поток управления задает порядок выполнения действий. Если линия потока управления исходит из ромба, то она символизирует условный поток. Если линия потока управления перечеркнута диагональной чертой со стороны узла, из которого она исходит, то она символизирует поток, выполняемый по умолчанию. Типы потоков управления в BPMN показаны на рис. 5.
Рис. 5. Типы потоков управления в BPMN
Поток сообщений изображается штриховой линией, оканчивающейся открытой стрелкой (рис. 6). Поток сообщений показывает, — какими сообщениями обмениваются участники.
О----------[>• Поток сообщений
Рисунок 6. Поток сообщений в BPMN
Ассоциации изображаются пунктирной линией, заканчивающейся стрелкой. Ассоциации используются для связывания артефактов — данных, групп или текстовых аннотаций с объектами потока управления. Типы ассоциаций в BPMN показаны на рис. 7.
Рисунок 7. Типы ассоциаций в BPMN
СИСТЕМНЫМ АНАЛИЗ И МОДЕЛИ В ЭКОНОМИКЕ
Роли. Практически все современные методологии моделирования бизнес-процессов имеют механизм разделения элементов модели (в BPMN — это объекты потока управления, связывающие объекты и артефакты) на категории, ассоциируемые с конкретным исполнителем или местом исполнения действий. Такие механизмы принято называть плавательными дорожками, или по-английски swim lane [ 10]. В BPMN средства разделения элементов модели по исполнителям и местам называются ролями. Существует два типа ролей:
Дорожки — это полосы на диаграмме, ассоциируемые с конкретным исполнителем или местом исполнения действий. В рамках этих полос размещаются элементы диаграммы — объекты потока управления, связывающие объекты и артефакты. Внутри дорожек могут располагаться вложенные дорожки.
Пулы — это совокупности дорожек. Они изображаются прямоугольником, содержащим полосы дорожек. Существует понятие сложенного пула, — изображаемого в виде прямоугольника с названием. Схема организации ролей в BPMN показана на рис. 8.
я
а
§
я о
1 о Q. Ч
Cl. я £ 1
>> с ^
С о п. о
я ч:
I
О
о.
о
е=С
Свёрнутый пул
Рисунок 8. Организация ролей в BPMN
Артефакты. Традиционно в теории моделирования систем артефактами принято называть материальные предметы (документы, программы и базы данных), создаваемые в процессе создания или функционирования системы. В ВРМК артефактами называются несколько иные вещи — средства, повышающие наглядность и содержательность диаграммы. Определены три вида артефактов: 1) данные; 2) группы; 3) текстовые аннотации.
Данные показывают читателю, какие данные необходимы для реализации действий и какие данные действия производят. Изображаются в виде прямоугольного листа бумаги с загнутым правым верхним углом. Чисто внешне, но не содержа-
тельно, изображение данных в BPMN совпадает с изображением примечаний в ИМЬ [11].
Группа изображается прямоугольником с закругленными углами, граница которого — штриховая линия. Группа позволяет объединять различные действия, но не влияет на поток управления в диаграмме. Семантически — это полный аналог пакетов в ИМЬ.
Текстовые аннотации используются для уточнения значения элементов диаграммы и повышения ее информативности. Семантически — это полный аналог примечаний в ИМЬ, но имеющий совсем иное изображение.
Изображения артефактов в диаграммах BPMN показаны на рис. 9.
Рисунок 9. Артефакты в BPMN
Соединив выше перечисленные элементы в единое целое можно получить детальную модель взаимодействия бизнес-процессов. На рисунке 10 показано два взаимодействующих процесса, локализованные пулами «Обработать полученный счет» и «Запланировать платежи». Взаимодействие между процессами осуществляется посредством потоков сообщений. Рассылкой сообщений занимается специальный элемент — действие типа «Свернутая задача» с пиктограммами +, О и =. При этом пиктограмма = (символические строки текста) означает тот факт, что данное действие манипулирует с сообщениями. Пиктограмма + символизирует тип действия, О символизирует тот факт, что из этого действия возможен переход к завершению процесса. На диаграмме представлено два типа потока сообщений: 1) пересылка данных в базу — не человеку; 2) выдача документа для прочтения человеком. Первый тип потока сообщений не имеет «шарика» в начале пунктирной стрелки, символизирующей пересылку данных. Стрелки второго типа всегда замыкаются на события типа «Сообщение», в нашем примере это события с метками «Отказано» и «Одобрено». Восприемником этих событий наряду с событием «Время истекло» является сотрудник финансового отдела, реализующий шлюз (логическую операцию) «Исключающее или» — ромбик с пентаграммой.
СИСТЕМНЫМ АНАЛИЗ И МОДЕЛИ В ЭКОНОМИКЕ
Рисунок 10. Детальное представление процесса «Обработка полученного счета»
Следует отметить, что с помощью языка BPEL осуществляется важнейшая составляющая реализации бизнес-процессов в SOA — оркестровка [11]. Язык BPEL основан на XML, поэтому его конструкции легко разбираются программно и одновременно доступны для чтения и редактирования человеком. BPEL имеет два оператора задающих действия — присваивание и вызов Web-сервисов. Остальные операторы являются управляющими, — они обеспечивают надлежащую последовательность и повторения присваиваний и вызовов сервисов. Каждый BPEL-процесс имеет точки входа и выхода. Эти точки не соответствует понятиям «начало» и «конец» на схеме алгоритма. Точка входа — это указание BPEL-машине на необходимость создания и запуска экземпляра бизнес-процесса. Точка выхода — это уведомление вызвавшей процесс системе о том, что процесс запущен. Через точку выхода можно возвращать в вызвавшую систему PID (Process ID) — идентификатор процесса, уникальный номер, который в системах класса UNIX назначается каждому активному процессу. После выдачи уведомления о запуске процесс начинает исполняться.
XML-текст BPEL-описания процесса сохраняется в .bpel-файле. Этот файл подлежит развертыванию на сервере выполнения бизнес-процессов, таком как ActiveBPEL Engine. Для реализации процедуры развертывания создается bpr-архив — файл, включающий в себя следующие составляющие:
1) XML-текст BPEL-описания процесса;
2) метаинформацию;
3) набор WSDL-файлов, описывающих вызываемые Web-сервисы и сам бизнес-процесс как Web-сервис.
Поскольку BPEL-процесс внешне является Web-сервисом, то запуск процесса представляет собой вызов Web-сервиса [ 13]. Это означает полную автономию BPEL-процесса относительно средства его запуска: это средство (ActiveBPEL Engine) можно менять, не меняя описания процессов.
Естественно, при рассмотрении BPEL весьма интересен вопрос о том, каким образом осуществляется процесс формирования .bpel-файла с исполняемым XML-кодом. Ручное написание этого кода хотя и вполне возможно, но мало привлекательно по причине существенной трудоемкости. Поэтому обычно используются средства графического представления операторов языка BPEL, т. е. графические редакторы, позволяющие рисовать блок-схемы, элементы которой взаимнооднозначно связаны с изобразительными средствами (операторами) BPEL [ 14]. Эти схемы легко трансформируются в необходимый XML-код. К средствам получения .bpel-файла через графические схемы относятся:
- Eclipse BPEL;
- ActiveBPEL Designer (плагин для Eclipse);
- IBM Integration Developer;
- NetBeans SOA-плагины;
- Oracle JDeveloper.
В настоящее время термин «BPEL» воплощает в себе три понятия:
1) язык представления исполняемых бизнес-процессов;
2) стандарт интеграции приложений (сервисов);
3) средство интеграции приложений.
BPEL — это язык реализации бизнес процессов, который был создан с целью облегчения процедуры интеграции корпоративных приложений. Его предшественниками и источниками идей являются языки, разрабатываемые компаниями Microsoft (язык XLANG) и IBM (язык WSFL) для решения задач системной интеграции. BPEL — это специализированный, интеграционный диалект XML, имеющий все преимущества XML — простоту синтаксиса и кроссплатформенность. Описание бизнес-процесса на BPEL — это XML-код, в котором взаимодействующие в рамках одного бизнес-процесса сервисы представлены в виде партнеров, обменивающихся сообщениями. Синтаксисом BPEL поддерживаются очень важные для построения реально работающих бизнес-процессов механизмы — транзакции, асинхронные вызовы, обработка ошибок. Предусмотрена вложенность бизнес-
СИСТЕМНЫМ АНАЛИЗ И МОДЕЛИ В ЭКОНОМИКЕ
процессов: несколько бизнес-процессов могут выступать «строительными блоками» для общего бизнес-процесса.
BPEL — это не только язык, но и стандарт, развитием которого занимается комитет OASIS BPEL Technical Committee. Наиболее активными участниками этого комитета являются BEA Systems, IBM, Microsoft, Oracle, SAP, Sun Microsystems.
Использованию BPEL предшествует создание набора сервисов — приложений и/или бизнес-компонент, оформленных в виде Web-сервисов. Эти сервисы могут создаваться специально для вновь создаваемой ИС, но могут и принадлежать к категории legacy, т. е. быть наследуемыми от ранее существовавших систем автоматизации. Дополненный сервисной шиной предприятия (ESB) указанный набор сервисов превращается в систему способных к взаимодействию элементов, т. е., по сути дела, ESB — это уже средство интеграции различных, в том числе и гетерогенных разноплатформенных приложений. Для того чтобы интегрированная совокупность сервисов заработала, необходим механизм управления взаимодействием. Этот механизм реализуется с помощью BPEL.
Интеграция систем автоматизации в рамках общих бизнес процессов — это основная сфера применения BPEL. Сегодня BPEL является лучшим интеграционным решением не только для Web сервисов, но и для Java, JCA (J2EE Connector architecture provides) и JMS (Java Message Service). BPEL проявил себя как эффективное средство сокращения затрат на реализацию корпоративных интеграционных проектов, уменьшения их сложности и повышения гибкости.
Даже готовые проектные решения, такие как SAP, имеющие в своем составе собственные встроенные инструменты для интеграции бизнес процессов, в ближайшем будущем будут поддерживать и BPEL. Чтобы обеспечить совместимость текущих инсталляций с BPEL, производители популярных типовых проектных решений рекомендуют использовать продукты третьих фирм, экспонирующие функции используемого приложения в виде Web-сервисов[ 13].
В настоящее время сформировалось мнение: применение концепции BPM (использование средств BPMS и интеграция приложений с помощью BPEL) экономически оправдано, если автоматизации подвергаются так называемые сквозные процессы, т. е. процессы масштаба предприятия («enterprise process»). Сквозной процесс («end-to-end process») — это бизнес-процесс, замкнутый по входу и выходу на внешнего клиента (потребителя, заказчика) и проходящий более чем через одно подразделение верхнего уровня.
Сквозной процесс практически всегда представляет собой совокупность нескольких асинхронно протекающих процессов. Их, конечно же, можно наглядно отобразить средствами BPMN. При этом отдельные процессы представляют последовательности действий, локализованных рамками одного пула. Параллельно асин-
хронно протекающие процессы обмениваются сообщениями. Эти сообщения определяют (изменяют) порядок выполняемых действий конкретного процесса. В исполняемом процессе каждое действие типа «Задание» — это вызов соответствующего сервиса.
В современной системной архитектуре (SOA) каждое действие типа «Задание» представляет собой вызов соответствующего сервиса, а исполняемый процесс — это последовательность вызовов сервисов [15].
При этом последовательность и логика выполнения заданий в рамках одного процесса называется оркестровкой («process orchestration»). Логика асинхронного, координируемого при помощи сообщений, выполнения нескольких процессов называется хореографией («process choreography»). Хореографию можно рассматривать как определение последовательности условий, при выполнении которых несколько относительно независимых бизнес-процессов обмениваются сообщениями с целью решения некоторой общей бизнес-задачи. Цель хореографии заключается в обеспечении многостороннего взаимодействия для достижения общей цели. Цепочку условий, вызывающих передачу сообщений, а значит и хореографию, можно рассматривать как некоторый абстрактный процесс, результатом которого является решение конкретной задачи [16].
Естественно, сквозной процесс чаще всего представляется хореографией, а не оркестровкой. Исключением являются бизнес-процессы очень малых предприятий, которые, будучи локализованными рамками одного пула (одного места исполнения или одного исполнителя), тем не менее, замыкаются по входу и по выходу на внешнего клиента. Таким образом, если процесс прост, то он представляется оркестровкой. Если же процесс состоит из нескольких асинхронных информационно взаимодействующих процессов, то он представляется хореографией.
На рис. 11 показаны места оркестровки и хореографии в модели бизнес-процесса.
Хореография описывается с помощью языка WSCI — Web Service Choreography Interface, который с 2002 года развивается рабочей группой Web Services Choreography Working Group консорциума W3C, деятельность которого поддерживается такими IT-гигантами как BEA Systems, Intalio , SAP, Sun Microsystems. С помощью WSCI описывается поток сообщений от Web-служб, участвующих во взаимодействия (в хореографии) с другими службами. Описание выражает условия временных и логических зависимостей между Web-сервисами, обменивающихся сообщениями, показывая последовательность правил [17].
СИСТЕМНЫМ АНАЛИЗ И МОДЕЛИ В ЭКОНОМИКЕ
Рисунок 11. Оркестровка и хореография бизнес-процесса
Информационная система, как и любой другой инструмент, должна иметь свои характеристики и требования, в соответствии с которыми можно было бы определить ее функциональность и эффективность. Разумеется, для каждого конкретного предприятия требования к информационной системе будут различными, так как должна учитываться специфика каждой организации [1].
Основой требований является техническое задание, которое состоит из двух самостоятельных частей или разделов [1]:
- прикладной раздел, т. е. бизнес-раздел, отражающий специфику бизнес-логики и передаваемую между функциональными модулями информацию (перевод свойств BPMS можно классифицировать как эффективное средство автоматизации процесса формирования ТЗ);
- 1Т-раздел, определяющий интерфейс, интеграцию с внешними приложениями, способы хранения и защиты данных.
Естественно, первая часть является наиболее ответственной и трудоемкой. Поэтому свойство BPMS без программирования переводить в код графическое представление схем бизнес-процессов можно квалифицировать как эффективное средство автоматизации процесса формирования ТЗ.
Получаемый машинный код может использоваться непосредственно. Разработчикам ТЗ не приходится домысливать прикладную часть бизнес-процесса. Это позволяет сосредоточиться исключительно на ГГ-разделе ТЗ — оптимизации поль-
зовательских интерфейсов, интеграции с внешними приложениями, хранении и защите данных.
На рис. 12 показан пример структуры технического задания.
Рисунок 12. Структура технического задания
Таким образом, разработчикам не приходится домысливать прикладную часть бизнес-процесса, что позволяет им сконцентрироваться исключительно на ГГ-разделе. При этом разработка технического задания, проектирование и кодирование информационной системы осуществляется в фоновом режиме, в то время как бизнес-процесс уже находится в эксплуатации. Это способствует эффективному разделению труда между экономистами и программистами, и, как следствие, более эффективной работе предприятия в целом.
Литература
[1] КИС «Флагман» [Электронный ресурс] // http://www.infosoft.ru/index.php/resheniya/kis-йа^ап
[2] Белов В. В., Чистякова В. И. Проектирование информационных систем : учеб. пособие для студ. учреждений высш. проф. образования / под ред. В. В. Белова. — М. : Изд. центр «Академия», 2013.
[3] Хаммер М., Чампи Дж. Реинжиниринг корпорации. Манифест революции в бизнесе. — М. : Манн, Иванов и Фербер, 2007.
СИСТЕМНЫМ АНАЛИЗ И МОДЕЛИ В ЭКОНОМИКЕ
[4] BPM Think Tank Day 2: Panel on Business Value of Process Standards [Электронный ресурс] http://www.ebizq.net/blogs/column2/2006/05/bpm_think_tank_7.php
[5] Стандарты BPM [Электронный ресурс] http://bpms.ru/library/standards/index.html
[6] Olavsrud T. Will BPEL and WSCI Come Together? [Электронный ресурс] http://www.internetnews.com/infra/article.php/2211121
[7] Matjaz B. J. Business Process Exexution Language for WebServices, 2nd Edition. — Birmingham, UK: Packt Publishing Ltd., 2006.
[8] Margolis B., Sharpe J. SOA for the Business Developer: Concepts, BPEL, and SCA, First Edition — ABF, 2007.
[9] Business Process Management Initiative [Электронный ресурс] http://www.bpmn.org/
[10] Swenson K. Directly Executing BPMN [Электронный ресурс] http://kswenson.wordpress. com/2008/10/29/directly-executing-bpmn/
[11] Unified Modeling Language [Электронный ресурс] http://www.uml.org/
[12] Bhuvaneswari N. S., Sujatha S. Integrating Soa and Web Services. — River Publishers, 2011.
[13] Standards and Web services [Электронный ресурс] http://www.ibm.com/developerworks/ webservices/standards/
[14] Swenson K. The BPMN-XPDL-BPEL value chain [Электронный ресурс] http://kswenson. wordpress.com/2006/05/26/bpmn-xpdl-and-bpel/
[15] Eben H. Java SOA Cookbook. — Sebastopol, USA : O'Reilly Media, Inc., 2009.
[16] Оркестровка и хореография Web-сервисов [Электронный ресурс] http://www.osp.ru/ os/2004/11/184785/
[17] Decker G. BPMN 2.0 takes dancing lessons — do we need choreographies? [Электронный ресурс] http://www.bpmn.info/2008/10/15/bpmn-20-takes-dancing-lessons-do-we-need-choreographies/
[18] Титоренко Г. А. Информационные системы и технологии управления : учебник. — М. : Юнити-Дана, 2012.
Авторы:
Белов Владимир Викторович — доктор технических наук, профессор, профессор кафедры вычислительной и прикладной математики Рязанского государственного радиотехнического университета.
Некрасов Михаил Васильевич — магистрант кафедры вычислительной и прикладной математики Рязанского государственного радиотехнического университета.
Formation of Requirements for the Information System Company
M. Nekrasov, V. Belov
Ryazan state radio engineering University, 390005, St. Gagarina, 59/1, Ryazan, Russia
e-mail: [email protected]
Abstract. In this article discusses the using of corporate information systems for the needs of enterprise management, provides an overview of the most relevant trends in the sphere of forming and representation of requirements for the information system.
Key words: corporate information systems, Business Process Execution Language, Business Process Management, Service-Oriented Architecture.
Reference
[1] Flagman. Available: http://www.infosoft.ru/index.php/resheniya/kis-flagman (In Rus)
[2] Belov V. V., Chistjakova V. I. (2013) Proektirovanie informacionnyh system. Moscow, Akad-emija. (In Rus)
[3] Hammer M., Champi D. (2007) Reinzhiniring korporacii. Manifest revoljucii v biznese. Moscow, Mann, Ivanov i Ferber. (In Rus)
[4] BPM Think Tank Day 2: Panel on Business Value of Process Standards. Available: http://www.ebizq.net/blogs/column2/2006/05/bpm_think_tank_7.php
[5] Standarty BPM. Available: http://bpms.ru/library/standards/index.html (In Rus)
[6] Olavsrud T. Will BPEL and WSCI Come Together? Available: http://www.internetnews. com/infra/article.php/2211121
[7] Matjaz B. J. (2006) Business Process Exexution Language for WebServices, 2nd Edition. Birmingham, UK: Packt Publishing Ltd..
[8] Margolis B., Sharpe J. (2007) SOA for the Business Developer: Concepts, BPEL, and SCA, First Edition. ABF.
[9] Business Process Management Initiative. Available: http://www.bpmn.org/
[10] Swenson K. Directly Executing BPMN. Available: http://kswenson.wordpress.com/ 2008/10/29/directly-executing-bpmn/
[11] Unified Modeling Language. Available: ttp://www.uml.org/
[12] Bhuvaneswari N. S., Sujatha S. (2011) Integrating Soa and Web Services. River Publishers.
[13] Standards and Web services. Available: http://www.ibm.com/developerworks/webservices/ standards/
СИСТЕМНЫМ АНАЛИЗ И МОДЕЛИ В ЭКОНОМИКЕ
[14] Swenson K. The BPMN-XPDL-BPEL value chain. Available: http://kswenson.wordpress. com/2006/05/26/bpmn-xpdl-and-bpel/
[15] Eben H. (2009) Java SOA Cookbook. Sebastopol, O'Reilly Media, Inc.
[16] Orkestrovka i horeografija Web-servisov. Available: http://www.osp.ru/os/2004/11/184785/ (In Rus)
[17] Decker G. BPMN 2.0 takes dancing lessons — do we need choreographies? . Available: http://www.bpmn.info/2008/10/15/bpmn-20-takes-dancing-lessons-do-we-need-choreographies/
[18] Titorenko G. A. (2012) Informacionnye sistemy i tehnologii upravlenija. Moscow, Juniti-Dana. (In Rus)
