Bpmn курсовая работа

Моделирование процессов предприятия при помощи различных инструментов, моделирования данных в нотации IDEF1X. Оценка реинжиниринга процесса

Содержание

реинжиниринг база данные экономический

Введение

1. Моделирование процесса в нотациях
IDEF, DFD, EPC, BPMN и в соответствии с требованиями ГОСТ 19.701-90

.1 Модель IDEF0, IDEF3, DFD

.2 Модель в соответствии с ГОСТ
19.701-90

.3 Модель EPC, BPMN

. Моделирование процесса в нотации
UML

.1 Описание предметной области

.2 Диаграмма Use CASE

2.3 Диаграмма Class diagram

.4 Диаграмма Diagram collaboration

.5 Диаграмма Sequence Diagram

.6 Диаграмма Statechart Diagram

2.7 Диаграмма Activity Diagram с
дорожками

. Моделирование данных в нотации
IDEF1X

.1 Модель IDEF1X

.2 База данных

4. Эффективность реинжиниринга процесса

Заключение

Список использованных источников

Введение

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

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

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

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

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

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

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

Для
достижения поставленной цели необходимо решить следующие задачи: создать модели
процесса в BPwin, Aris Express, MS Visio, IBM Rational Rose и в соответствии с
требованиями ГОСТ 19.701-90, а также создать модель данных в Erwin и
сгенерировать базу данных в MS Access. После чего рассчитать экономическую
эффективность реинжиниринга данного процесса в BPwin.

1.
Моделирование процесса в нотациях IDEF, DFD, EPC, BPMN и в соответствии с
требованиями ГОСТ 19.701-90

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

.1 Модель IDEF0, IDEF3, DFD

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

Модель процесса «Деятельность компании WinEco»в нотации IDEF0
представлена на рисунке 3.

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

На рисунке 1 видно, что мы моделируем деятельность компании WinEco,
которая занимается производством окон. В дальнейшем будет проведена
декомпозиция основного процесса на большое количество различных подпроцессов.

Модель IDEF0 можно декомпозировать. На рисунке 4 представлена
декомпозиция процесса «Деятельность компании WinEc0», теперь процесс
состоит из четырёх фрагментов: Работа с поставщиками и клиентами, изготовление,
управление, обучение и реклама.

Рисунок 2 — Декомпозированная модель IDEF0

Рисунок 3 — Модель DFD (Работа с клиентами и поставщиками)

Рисунок 4 — Декомпозиция — изготовление

Рисунок 6 — Модель IDEF3 (Производство стеклопакетов)

Рисунок 7 — Модель IDEF0 (Окрашивание)

1.2 Модель в
соответствии с ГОСТ 19.701-90

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

Для изображения схем алгоритмов существует ГОСТ 19.701-90 «Схемы
алгоритмов, программ, данных и систем.

Условные обозначения и правила выполнения». ГОСТ 19.701-90
распространяется на условные обозначения (символы) в схемах алгоритмов,
программ, данных и систем и устанавливает правила выполнения схем, используемых
для отображения различных видов задач обработки данных и средств их решения.

Программа Microsoft Visio позволяет изображать схемы алгоритмов.

Схема алгоритма «Деятельность компании WinEco» представлена на
рисунках 8-10

Рисунок 8 — Модель в соответствии с требованиями ГОСТ 19.701-90

Рисунок 9 — Модель в соответствии с требованиями ГОСТ 19.701-90
(продолжение)

Рисунок 10 — Модель в соответствии с требованиями ГОСТ 19.701-90
(продолжение)

Рисунок 11 — Модель в соответствии с требованиями ГОСТ 19.701-90
(продолжение)

Рисунок 13 — Модель в соответствии с требованиями ГОСТ 19.701-90
(окончание)

.3 Модель
EPC, BPMN

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

На рисунках 14, 15, 16, показана диаграмма процесса «Деятельность
компании WinEco» в нотации ЕРС.- система условных обозначений (нотация)
для моделирования бизнес-процессов.

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

На рисунках 17, 18, 19, 20 показана диаграмма процесса «Деятельность
компании WinEco» в нотации BPMN.

Нотации EPC и BPMN выполнены в ARIS Express -программный продукт для
моделирования бизнес-процессов организаций.

Рисунок 14 — Модель EPC (общий вид)

Рисунок 16 — Модель EPC (окончание)

Рисунок 17 — Модель BPMN (общий вид)

Рисунок 18 — Модель BPMN

Рисунок 19 — Модель BPMN (продолжение)

Рисунок 20 —
Модель BPMN (окончание)

2.
Моделирование процесса в нотации UML

.1 Описание
предметной области

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

—         регистрация клиентов;

—         регистрация менеджеров по продажам;

—         учёт производимых окон(тип окна,
материалы, тип рамы);

—         регистрация договоров с клиентами и
поставщиками.

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

.2 Диаграмма
Use CASE

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

Рисунок 21 — Диаграмма Use CASE (начало)

Рисунок 22 — Диаграмма Use CASE (окончание)

2.3 Диаграмма
Class diagram

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

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

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

На рисунке 22 изображена диаграмма классов процесса «Деятельность
компании WinEco». Диаграмма состоит из следующих классов: исполнитель,
информация об инструментарии, модель ASIS.

Классы имеют атрибуты и операции.

Рисунок
23 — Class diagram

.4
Диаграмма Diagram collaboration

Главная особенность диаграммы кооперации (diagram collaboration)
заключается в возможности графически представить не только последовательность
взаимодействия, но и все структурные отношения между объектами, участвующими в
этом взаимодействии.

В диаграмме коопераций процесса «Деятельность компании WinEco»
следующая последовательность взаимодействия (рисунок 24):

Рисунок
24 — Diagram collaboration

2.5
Диаграмма Sequence Diagram

На диаграмме последовательности (Sequence Diagram) изображено
упорядоченное во времени взаимодействие объектов, участвующие во взаимодействии
объекты и последовательность сообщений, которыми они обмениваются. Одно из
основных назначений данной диаграммы — отобразить последовательность действий
для части или целого варианта использования (use case). Как правило, по
вертикали отображена временная ось, а по горизонтали указаны объекты,
участвующие в данном процессе (рисунок 25).

Рисунок
25 — Sequence Diagram

.6
Диаграмма Statechart Diagram

Для описания реакции объекта на подобные внешние воздействия и
используются диаграммы состояний (Statechart Diagram). Главное предназначение
этой диаграммы — описать возможные последовательности состояний и переходов,
которые в совокупности характеризуют поведение элемента модели в течение его
жизненного цикла. Диаграмма состояний представляет динамическое поведение
сущностей, на основе спецификации их реакции на восприятие некоторых конкретных
событий. Диаграмма состояний по существу является графом специального вида.
Вершинами этого графа являются состояния и некоторые другие типы элементов
(псевдосостояния), которые изображаются соответствующими графическими
символами. Дуги графа служат для обозначения переходов из состояния в состояние
(рисунок 26).

Рисунок
26 — Statechart Diagram

.7
Диаграмма Activity Diagram с дорожками

Диаграммы деятельности могут быть использованы не только для спецификации
алгоритмов вычислений или потоков управления в программных системах. Не менее
важная область их применения связана с моделированием бизнес-процессов. Действительно,
деятельность любой компании (фирмы) также представляет собой не что иное, как
совокупность отдельных действий, направленных на достижение требуемого
результата. Однако применительно к бизнес-процессам желательно выполнение
каждого действия ассоциировать с конкретным подразделением компании. В этом
случае подразделение несет ответственность за реализацию отдельных действий, а
сам бизнес-процесс представляется в виде переходов действий из одного
подразделения к другому. Для моделирования этих особенностей в языке UML
используется специальная конструкция, получившее название дорожки (swimlanes).
Имеется в виду визуальная аналогия с плавательными дорожками в бассейне, если
смотреть на соответствующую диаграмму. При этом все состояния действия на диаграмме
деятельности делятся на отдельные группы, которые отделяются друг от друга
вертикальными линиями. Две соседние линии и образуют дорожку, а группа
состояний между этими линиями выполняется отдельным подразделением (отделом,
группой, отделением, филиалом) компании.

Рассмотрим диаграмму деятельности с дорожками процесса «Деятельность
компании WinEco» (рисунок 27) Группами компании являются руководитель и
исполнители. Этим подразделениям будут соответствовать две дорожки на диаграмме
деятельности, каждая из которых специфицирует зону ответственности группы. В
данном случае диаграмма деятельности заключает в себе не только информацию о
последовательности выполнения рабочих действий, но и о том, какое из
подразделений должно выполнять то или иное действие.

 

Рисунок 27 —
Диаграмма Activity Diagram с дорожками

3.
Моделирование данных в нотации IDEF1X

.1 Модель
IDEF1X

X является методом для разработки реляционных баз данных и использует
условный синтаксис, специально разработанный для удобного построения
концептуальной схемы. Концептуальной схемой называется универсальное
представление структуры данных в рамках коммерческого предприятия, независимое
от конечной реализации базы данных и аппаратной платформы. Использование метода
IDEF1X наиболее целесообразно для построения логической структуры базы данных
после того, как все информационные ресурсы исследованы и решение о внедрении
реляционной базы данных, как части корпоративной информационной системы, было
принято.

На рисунке 28 представлена модель IDEF1X, созданная в программе ERWin,
для процесса «Деятельность компании WinEco». Из рисунка видно, что
база данных в дальнейшем будет состоять из таблиц: Dogovor, Okno, Klient,
Personal, Izgotovl.

Таблица 1 — Данные логической модели

	Атрибут	Тип		Атрибут	Тип
Personal
1	KodP	uniqueid	2	FIO	text(100)
3	Adress	text(100)	4	Tel	text(100)
Dogovor
5	KodD	uniqueid	6	Nomer	large binary
7	Data	Date/Time
Klient
8	KodPr	uniqueid	9	FIO	Text(100)	Adres	Text(100)	11	Tel	Text(100)
Okno
12	KodO	uniqueid	13	Chislo_Kam	Long integer
14	Tip_Okna	text(100)	15	Tip_ramy	text(100)
16	Razmer	Text(100)	17	Tip_plenki	Text(100)

3.2 База
данных

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

Рисунок 29 — Схема данных

Рисунок 30 — Таблица «Dogovor»

Рисунок 31 — Таблица «Klient»

Рисунок 32 — Таблица «Okno »

Рисунок 33 — Таблица «Personal »

Рисунок 34 — Таблица «Izgotov»

4.
Эффективность реинжиниринга процесса

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

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

Указанные аспекты связаны с показателями эффективности системы, к которым
относятся такие, как время выполнения процессов, величина стоимостных затрат,
надежность процессов. К косвенным показателям эффективности относятся объем
производства, производительность труда, скорость оборота капитала,
рентабельность и т.д.

Для расчета показателей эффективности системы, реализующей модель
бизнес-процессов, как правило, используются статические методы стоимостного
анализа процессов (ABC — activity-based costing) и динамические методы
имитационного моделирования. Набор средств моделирования процессов в настоящее
время поддерживается с помощью CASE-средств или средств моделирования
компонентных технологий, центральным элементом которого является репозиторий
(словарь данных). Он представляет собой специализированную базу данных,
предназначенную для отображения состояния проектируемой системы в каждый момент
времени. Объекты всех моделей синхронизированы на основе общей информации репозитория,
которая используется при выработке проектных решений.

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

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

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

Рисунок 35 — Модель
IDEF0 со стоимостью

Рисунок 36 — Декомпозиция модели IDEF0 со стоимостью

Заключение

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

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

Наиболее удобным языком моделирования бизнес-процессов является IDEF0.
Наличие в диаграммах DFD элементов для описания источников, приемников и
хранилищ данных позволяет более эффективно и наглядно описать процесс
документооборота. Однако для описания логики взаимодействия информационных
потоков более подходит IDEF3. Для описания и моделирования отдельных процессов
компании или процессов нижнего уровня модели компании, созданной в нотации
IDEF0, применяют нотации EPC и BPMN.

На основании диаграмм в нотациях IDEF, DFD, EPC, BPMN и алгоритмом,
созданным в соответствии с требованиями ГОСТ 19.701-90 создаются UML диаграммы.
Язык UML предназначен не только для описания абстрактных моделей приложений, но
и для создания таких моделей, для которых возможна автоматическая генерация
программного кода (или фрагментов кода) соответствующих приложений. Более того,
природа моделей UML такова, что возможен и обратный процесс: автоматическое
построение модели по коду готового приложения. Для проектирования логической
структуры БД создается модель в нотации IDEF1X. Сама база данных создается в
Microsoft Access.

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

Список
использованных источников

1.       Левоникин
К.М. Реинжиниринг бизнес-процессов. Полный курс MBA, М.: Ронд, 2007.

.         Робсон
М., Уллах. Реинжиниринг бизнес-процессов / М.: Юнити , 2007.

.         Репин
В., Бизнес процессы — моделирование, внедрение, управление. Манн, Иванов и
Фербер, 2012.

.         ГОСТ
19.701-90 Единая система программной документации. Схемы алгоритмов, программ,
данных и систем. Условные обозначения и правила выполнения, 1992.

.         Яблочников
Е.И, Молочник В.М, Фомина Ю.Н. Реинжиниринг бизнес-процессов проектирования и
производства Учебное пособие — СПб: СПбГУИТМО, 2008.

6.       Моделирование
бизнес-процессов и инфраструктуры — URL:
<http://bpmsoft.org/aris-express/> (дата обращения 14.06.15)

.         Моделирование с Erwin express modeler (fb2). URL:
http://www.interface.ru/home.asp?artId=48&cId=1 (дата обращения
13.06.2015).

.         Тебайкина Н.И.
«Case-средства» учебное пособие. — Екатеринбург: УрФУ, 2010.

2013

2

Saint-Petersburg State University

Mathematics and Mechanics Faculty

Software Engineering Department

Implementation of informational system business processes source code generation based on BPMN diagrams in REAL-IT/.NET

Graduate paper by

Ruslan Mokaev

Scientific advisor

……………… Professor A.N. Terekhov

Reviewer

……………… A.V. Nesterov

“Approved by” ……………… Professor A.N. Terekhov

Head of Department

Saint-Petersburg

2013

	3
Оглавление
Введение…………………………………………………………………………………………………………………………………	4
Постановка задачи…………………………………………………………………………………………………………………	6
Выбор редактора диаграмм……………………………………………………………………………………………………..	6
Реализация необходимой логики в библиотеках поддержки исполнения…………………………………..	6
Внесение изменений в генераторы и шаблоны экранных форм и базы данных………………………….	6
Апробация полученных генераторов на примере ИС………………………………………………………………..	7
Обзор редакторов диаграмм………………………………………………………………………………………………..	8
Bizagi Process Modeler……………………………………………………………………………………………………………..	8
Signavio Process Editor …………………………………………………………………………………………………………….	8
Yaoqiang BPMN Editor…………………………………………………………………………………………………………….	8
Microsoft Visio ………………………………………………………………………………………………………………………..	8
Дизайнер ELMA……………………………………………………………………………………………………………………..	9
ARIS Express…………………………………………………………………………………………………………………………..	9
Modelio …………………………………………………………………………………………………………………………………..	9
Enterprise Architect ………………………………………………………………………………………………………………….	9
QReal…………………………………………………………………………………………………………………………………….	10
Обзор языков моделирования бизнес-процессов…………………………………………………………	11
BPEL…………………………………………………………………………………………………………………………………….	11
BPMN …………………………………………………………………………………………………………………………………..	12
Описание решения……………………………………………………………………………………………………………….	14
Выбор редактора диаграмм…………………………………………………………………………………………………..	14
Генерация кода бизнес-процессов…………………………………………………………………………………………	16
Создание служебных состояний…………………………………………………………………………………………….	16
Работа со статическими классами, сохраняющими состояние уникальных объектов……………….	17
Получаемые из диаграммы бизнес-процессов ограничения и действия …………………………………..	18
Изменение библиотек поддержки исполнения ……………………………………………………………………….	19
Апробация……………………………………………………………………………………………………………………………..	20
Заключение …………………………………………………………………………………………………………………………..	25
Направления дальнейшей работы……………………………………………………………………………………	25
Список литературы ……………………………………………………………………………………………………………..	26

4

Введение

Такой сегмент рынка разработки программного обеспечения, как создание систем, направленных на сбор, хранение и обработку информации, всегда был одним из самых популярных. Как и все остальное в мире ИТ он развивается стремительно, вследствие чего разрабатываются разнообразные подходы для автоматизации процесса разработки. Одним из них является разработка с использованием объектно-ориентированного визуального моделирования с использованием CASE-средств для создания моделей системы [2].

На кафедре системного программирования Санкт-Петербургского государственного университета была разработана технология REAL-IT, основанная на использовании объектно-ориентированного CASE-пакета REAL, также разработанного на математико-механическом факультете СПбГУ. Технология REAL-IT позволяет создавать и поддерживать приложения, ориентированные на сбор, хранение и обработку данных.

Разработка информационных систем на тот момент осуществлялась на языке Visual Basic 6.0, что вводило ограничения на возможности по разработке графического пользовательского интерфейса. Также к проблемам, возникавшим перед пользователями и разработчиками, относилось отсутствие инструментария для установки автоматических обновлений и устаревшая среда разработки. Поэтому в 2007 году в рамках дипломной работы Антона Нестерова был реализован перенос технологии REAL-IT на платформу Microsoft .NET.

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

5

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

Таким образом, генерация кода на основе нескольких независимых моделей, каждая из которых описывает систему со своей точки зрения, является очень важной нерешенной проблемой [1].

Содержание:

Введение

Более двух ста лет тому назад Адамом Смитом было сделано существенное открытие: любой производственный процесс должен быть разделен на составляющие подпроцессы. Данным открытием он продемонстрировал тот факт, что разделение труда напрямую влияет на уровень производительности. Это связано с тем фактом, что люди, сосредоточенные на одной производственной задаче выполняют данную задачу более качественно. В итоге на протяжении более двух веков люди использовали принцип разделения труда Адама Смита в организации и развитии компаний и фирм. При этом если посмотреть на деятельность любой крупной современной фирмы, можно увидеть что в ее деятельности присутствует ряд повторяющихся бизнес-процессов, каждый из которых состоит из определенных действий, выполнение которых приводит к некоторой цели.

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

Актуальность данного исследования заключается в большой популярности и значимости проведения анализа бизнес процессов в деятельности предприятия.

Объект исследования – бизнес процессы.

Предмет исследования – методология моделирования бизнес процессов.

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

Для достижения поставленной цели необходимо решить следующие задачи:

1. Изучить теоретические основы моделирования бизнес процессов;
2. Изучить методологию и программные продукты моделирования бизнес процессов;
3. Осуществить анализ и построение модели бизнес-процесса «продажи».

Глава 1. Теоретические аспекты моделирования бизнес процессов

1.1. Бизнес-процессы на предприятии, методы описания и представления

Бизнес процессом называют определенный набор действий, выполняющихся в некоторой последовательности, имеющих входы, в итоге достигающие некоторый выход, использующих определенные ресурсы и выполняемых на основании некоторого управляющего воздействия. Результатом бизнес процесса часто называют реализованную работу или услугу для клиента компании или фирмы [5]. В различных источниках дается еще определение бизнес процесса, согласно которому это ряд из нескольких связанных друг с другом операций или процедур, которые в совокупности выполняются для достижения основной цели производства, которая выполняется в рамках имеющейся организационной структуры предприятия, отражающей уровень взаимоотношений между участниками [14].

Рисунок 1 – Общее представление бизнес-процесса

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

В стандарте ENISO 9001:2000 бизнес процесс называют набором взаимосвязанных средств и действий, благодаря которым вход преобразуются в результат. Еще процессы зачастую называют изменением определенного объекта.

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

• Вид деятельности: в зависимости от данного параметра различаются процессы производственные или процессы оказания услуг. В результате выполнения производственного процесса получаются какой-либо материальный продукт, а в результате процессов оказания услуг получают нематериальный продукт;
• Вид выполнения: в зависимости от данного параметра различают процессы оперативные (расчет, обработка и т.п.), а также диспозитивные (планирование, управление);
• Создание стоимости: по данному критерию различают процессы, которые прямо изменяют объект, и процессы, косвенно влияющие на стоимость, либо косвенно корректирующие её;
• Комплексность: макропроцессы, описывающие общие бизнес процесс на предприятии, и микропроцессы, являющиеся составными частями макропроцесса;
• Коммерческий успех: ключевые, управленческие и поддерживающие процессы. Ключевые процессы являются специфическими для компании и имеют особое значение для достижения общей цели компании.

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

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

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

• стратегическое развитие компании;
• долго- и среднесрочное планирование в компании;
• развитие персонала;
• инвестиционное планирование;
• мотивация персонала и др.

Поддерживающие процессы содержат необходимые задания и работы для поддержания ключевых процессов, но не приводящие к непосредственной ценности для клиента, например:

• обработка данных;
• техническое обслуживание;
• логистика;
• административные процессы и др.

1.2. Анализ методик моделирования бизнес-процессов предприятия

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

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

Процессы моделирования и анализа бизнес процессов проводится в двух направлениях:

1. Описание процессинга. В данном направлении моделирование применяют с целью способствовать получению внешнего взгляда на рабочий процесс, добиться увеличения эффективности бизнес процесса.

2. Нормирование деятельности. В данном направлении моделирование применяют с целью добиться увеличения уровня производительности изучаемых процессов.

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

• Функциональный анализ бизнес-процессов – подразумевает описание основных этапов деятельности предприятия с учетом временной последовательности;
• объектный анализ – подразумевает описание процессов с учетом их взаимодействия с заранее выбранным объектом;
• имитационный анализ – подразумевает проведение на внешних объектах и учитывает внутренние и внешние составляющие процесса;

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

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

Наиболее известные принципы выполнения моделирования бизнес процессов:

• Декомпозиционный принцип заключается в разделении процесса на отдельные элементы, представляемые в виде иерархии.
• Фокусирующий принцип заключается в отвлечения внимания от деталей процесса и имеющий цель сфокусировать внимание на корневые аспекты бизнес процесса.
• Документирующий принцип подразумевает реализацию специализированных документирующих систем.
• Достаточность и полнота подразумевает реализацию оценки влияния изучаемого бизнес процесса на рабочие механизмы в целом. Также данный принцип разрешает не включать в модели процесса несущественные элементы.
• Принцип непротиворечивости подразумевает отсутствие противоречащих изъяснений для элементов бизнес процесса.

Наличие большого количества методик моделирования процессов позволяет разработчикам сфокусироваться на различных момента деятельности. К данным методикам относят:

• Схемы потоков деятельности – представляют собой графический метод отображения данных, операций и элементов рабочего процесса путем применения специальных символов. Данный метод позволяет отображать логические последовательности действий, а существенным плюсом методики называют её гибкость.
• Диаграммы потоков информации – данный вид диаграмма позволяет наглядно представить процесс передачи данных от одного процесса к другому. Данная методика является основой для структурного анализа, на основании которого осуществляют разбиение бизнес процессов на составляющие. При использовании данного метода каждый элемент может быть разделен на более мелкие составляющие, а уровень детализации постоянно повышаться. Данная методика применяется при анализе потоков данных.
• Диаграммы ролей используются для выполнения анализа взаимодействия сотрудников организации в процессе выполнения ими должностных обязанностей. Ролью называют организующую функцию сотрудника предприятия. Данные диаграммы применяют с целью выяснения уровня ответственности за успешность деятельности сотрудников.

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

Наиболее популярным стандартом моделирования бизнес процессов является стандарт BPMN (Business Process Modeland Notation), разработчиком которого является рабочая группа OMG. Основная цель данного стандарта заключается в обеспечении пользователей доступной нотацией описания бизнес процессов, будь то бизнес-аналитики, реализующих схемы бизнес процессов, или руководители данных бизнес процессов. Исходя их вышесказанного можно сказать что BPMN основной целью имеет снижение уровня расхождений между моделью бизнес процесса и их реализацией.

BPMN 2.0 в своем составе имеет описание трех моделей процессов: это приватный процесс, публичный процесс и хореография. За счет использования вышеперечисленных моделей специалистами могут быть созданы самые различные варианты диаграмм бизнес процессов. Ниже приведен перечень подмоделей бизнес процессов, которые могут быть реализованы с применением BPMN 2.0:

• Высокоуровневые невыполняемые;
• Действия (нефункциональный анализ);
• Детализированный выполняемый Бизнес-процесс;
• Бизнес-процесс «As-is» (устаревший);
• Бизнес-процесс «To-be» (новый);
• Хореография (Choreography);
• Детализированный приватный Бизнес-процесс (как выполняемый, так и невыполняемый), включающий взаимоотношения между одним или более внешними участниками (Процесс типа «черный ящик»);
• Два или более детализированных выполняемых взаимодействующих Процесса;
• Детализированный выполняемый Бизнес-процесс, взаимодействующий с Хореографией;
• Два или более публичных Процесса;
• Публичный процесс, взаимодействующий с Хореографией;
• Два или более детализированных выполняемых Бизнес-процесса, взаимодействующих посредством Хореографии.

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

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

• Элементы потока и другие элементы диаграммы МОГУТ носить текстовые метки (labels) (например, имя потока и/или названия других его атрибутов). Текстовые метки могут помещаться как внутри фигуры, так и над или под ней. Месторасположение текстовых меток, а также их направление может быть любым в зависимости от задумки разработчика модели или программы моделирования.
• Заливка графического элемента МОЖЕТ БЫТЬ как белого цвета, так и прозрачной.
• Графическая нотация может допускать использование какого-либо другого цвета заливки для удовлетворения требований разработчика модели или программы моделирования (например, выделение значения атрибута объекта). Однако следует помнить о следующих правилах:
• События, определяющие дальнейший ход потока, должны иметь темную заливку.
• Дорожки Участников в фигуре Хореографии или Подхореографии должны иметь светлую заливку в том случае, если Хореография/Подхореография (Choreography/Sub-choreography) не запускают Действие.

BPMN 2.0 описывает механизм, позволяющий расширять список атрибутов для стандартных графических элементов диаграммы. При необходимости разработчиком модели или программой моделирования могут быть задействованы нестандартные атрибуты графических элементов или Артефакты, такие, как уникальные требования для вертикальной области. Для того, чтобы не нарушить логику, описываемую в BPMN, такие атрибуты НЕ ДОЛЖНЫ противоречить семантике использования любого их графических элементов BPMN. Необходимо отметить, что, несмотря на возможность добавления новых атрибутов, должны быть сохранены все основные принципы построения и наглядность диаграммы для лучшего её восприятие пользователем любого уровня подготовки. Помните, что фигуры основных элементов потока (События, Действия и Шлюзы) не должны видоизменяться.

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

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

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

1. Vantage Team Builder (Westmount I-CASE) – представляет собой интегри-рованный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО.
2. Designer – является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer поддержку полного ЖЦ ПО для систем, использующих СУБД ORACLE.
3. Silverrun (Сomputer Systems Advisers, Inc. (CSA)) используется для анализа и проектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моде-лей (диаграмм потоков данных и диаграмм «сущность-связь»).
4. CA AllFusion ERwin Data Modeler – включает в себя 2 средства: ERwin — средство концептуального моделирования БД, использующее методологию IDEF1X, реализующее проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД и BPwin — средство функционального моделирования, реализующее методологию IDEF0.
5. S-Designor представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству Erwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжиниринг БД.
6. Rational Rose – предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на универсальной нотации для моделирования объектов (UML — Unified Modeling Language).
7. Продукт IBM® WebSphere® Business Modeler (далее – Modeler) – это лучший в отрасли инструмент для моделирования и имитации бизнес-процессов. С помощью Modeler бизнес-аналитики и другие нетехнические пользователи могут создавать бизнес-модели для документирования своих процессов, а затем осуществлять их имитационное моделирование, чтобы понять поведение этих процессов «в динамике». Пользователи могут генерировать отчеты на основе модели процесса и по результатам имитационного моделирования. Пользователи могут экспортировать свои модели в такие среды как WebSphere Integration Developer (Integration Developer), WebSphere Process Server (Process Server) и IBM FileNet P8 и хранить их в таких системах как Rational® ClearCase и Rational Asset Repository. Модели могут быть опубликованы с помощью компонента WebSphere Business Modeler Publishing Server (Publishing Server), что позволяет авторизованным пользователям просматривать эти модели с помощью Web-браузера. Эти модели могут также быть связаны с требованиями в продукте Rational RequisitePro и повторно использованы в продукте Rational Software Architect.

Глава 2. Моделирование бизнес процесса продажа с примнеением методологии IDEF0

2.1. Разработка верхнего уровня описания процесса «Продажи»

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

Цель моделирования процесса продажи:

1) Почему моделируем? Моделируем для описания процесса «Продажа» с целью анализа составляющих процесса.

2) Что будет показывать модель? Модель процесса «Продажа» будет демонстрировать все составляющие процесса продажи.

3) Для чего будет использоваться? Модель процесса «Продажа» будет использоваться для анализа процесса продажи.

Цель: Реализация модели процесса «Продажа» для анализа реализации данного процесса, участвующих в процессе исполнителей и используемой документации.

Точка зрения: Разработчик системы

Таблица 1

Данные и функции процесса для разработчика системы

Данные (объекты)	Функции
Менеджер	Обслуживание клиента Выписка счет-фактур
Руководитель	Контроль рабочего времени
Бухгалтер	Прием денежных средств Выдача кассового и товарного чека
Кладовщик	Выдача товара
Служба доставки	Доставка товара

Диаграмма A0 в нотации IDEF0 представлена на рисунке 2.

Рисунок 2 –Диаграмма A0 в нотации IDEF0

На диаграмме отображены основные составляющие процесса: данные о клиенте и денежные средства на входе, прибыль и продажи на выходе, нормативно-правовые акты РФ в качестве инструментов регулирования процесса, и сотрудники магазина, являющие механизмами выполнения процесса продаж.

2.2. Другие виды анализа процесса «Продажа»

Для выполнения других видов анализа бизнес процесса «Продажа» были представлены диаграмма потоков данных, изображенная на рисунке 3, а также диаграммы декомпозиции первого и второго уровня IDEF0, изображенные на рисунках 4 – 8.

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

Рисунок 3 – DFD диаграмма потоков данных

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

Рисунок 4 – Декомпозиция IDEF0 диаграммы A0

Декомпозиция диаграммы А0 представляет основные подпроцессы процесса продажи: выбор товара, оформление заказа, оплата заказа, а далее либо клиент самостоятельно получает товар, либо заказывает его доставку по необходимому ему адресу.

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

Рисунок 5 – IDEF0 диаграмма первого уровня «Выбор товара»

Рисунок 6– Декомпозиция второго уровня блока «Оформление заказа»

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

Рисунок 7– Декомпозиция второго уровня блока «Оплата заказа»

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

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

Рисунок 8 – Декомпозиция второго уровня блока «Доставка товара»

Для детализации процесса продажи необходимо построить диаграмму IDEF3 процесса «Продажа». Процесс представлен в виде последовательности операций на диаграмме IDEF3 (рисунок 9).

В процессе приобретения товара в магазине были выделены следующие операции:

1. Выбор товара. В случае с приобретением товара клиент может осуществить свой выбор полностью самостоятельно, так и прибегнуть к консультации менеджера и выбрать требуемый товар.
2. Далее менеджер оформляет необходимую документацию на товар – это накладная на получение товара со склада, счет-фактура для оплаты товара, и гарантийный талон.
3. Следующим шагом клиенту необходимо оплатить товар на кассе. Здесь клиенту к документам прикрепляется кассовый чек, а также ставиться печать и подпись кассира для придания документам юридической силы.
4. Далее клиент может пройти на пункт выдачи на складе и получить свой товар. Либо оформить доставку товара.

Рисунок 9 – IDEF3 диаграмма процесса продажи

2.3. Функционально-стоимостной анализ процесса «Продажа»

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

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

Рисунок 10 – Перечень источников расходов

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

• Автомобильная техника;
• Вычислительная техника;
• Заработная плата.

Рисунок 11 –Заполнение затрат на реализацию проекта

В результате заполнения стоимостных затрат на диаграмме А0 будет представлена итоговая сумма затрат на реализацию процесса продажа

На рисунке 11 представлена диаграмма Node Tree, наглядно демонстрирующая стоимость реализации процесса в общем, и каждого из его подпроцессов в частности.

Рисунок 12 – Диаграмма Node Tree стоимостных затрат проекта

Отчет по выполнению расчетов представлен в текстовом виде на рисунке 13.

Рисунок 13 – Отчет по стоимостным затратам бизнес процесса

Заключение

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

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

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

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

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

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

Список использованных источников

1. Аверченков В. И. Информационные системы в производстве и экономике: учебное пособие 2–е изд., стер. – М.: Флинта , 2013.
2. Балдин К. В. Информационные системы в экономике. Учебник – М.: Дашков и Ко , 2012.
3. Барановская Т. П. Информационные системы и технологии в экономике, М.: Финансы и статистика, 2014.- 416 с.
4. Божко В. П. Информационные технологии в статистике, М.: Финстатинформ, 2016.- 144 с.
5. Брусакова И. А. Информационные системы и технологии в экономике – М.: Финансы и статистика , 2014.
6. В. В. Ильин – Моделирование бизнес-процессов. Практический опыт разработчика. 2015
7. Всё о методологии и ПО ARIS. Информационный менеджмент – системный анализ. [Электронный ресурс].
8. Герасимова Л.Н. Информационное обеспечение маркетинга, М.: Маркетинг, 2016. – 120 с.
9. Григорович В.Г. Информационные методы в управлении качеством. — М.: РИА «Стандарты и качество», 2015-200 с.
10. Давид Марка, Клемент Марк Гоуэн. Методология структурного анализа и проектирования: Пер. с англ. – М: 2014. — 240 с.
11. Ивлев В., Попова Т. Методология Функционально-Стоимостного Анализа ABC (ФСА). Компания «ВИП-Анатех» — М.: РИА «Стандарты и качество», 2014.
12. Информационные системы и технологии в экономике и управлении. Учебник 4–е изд., перераб. и доп. – М.: ЮРАЙТ , 2013.
13. Йордон Э., Аргила К.. Объектно–ориентированный анализ и проектирование систем: Москва: Лори, 2015. 264 стр.
14. Истомин Е. П., Новиков В. В., Новикова М.В.. Высокоуровневые методы информатики и программирования Москва: Андреевский Издательский дом 2016 г. 228 стр.
15. Калянов Г.Н. – Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. 2015.
16. Карминский А.М., и др. Информатизация бизнеса. Концепции, технологии, системы, Москва: Астрэль 2014. 624 стр.
17. Крачтен, Филипп. Введение в Rational Unified Process. 2-е изд. М.: Издательский дом «Вильямс», 2014.
18. Кролл П., Крачтен Ф. Rational Unified Process – это легко. Руководство по RUP. М.: КУДИЦ-ОБРАЗ, 2013.
19. Курьян А.Г., Серенков П.С. Использование IDEF0 для описания и классификации процессов в рамках системы качества МС ИСО серии 9000. – Минск: 2014.
20. Липунцов Ю.П. Управление процессами. Методы управления предприятием с использованием информационных технологий. М.: Компания АйТи, 2008.
21. Мишенин А. И. Теория экономических информационных систем. Учебник 4–е изд., доп. и перераб. – М.: Финансы и статистика , 2016.
22. Репин В.В., Елиферов В.А. Процессный подход к управлению . Моделирование бизнес- процессов. — М.: РИА «Стандарты и качество», 2015, 405 с.
23. Репин В.В.. Сравнительный анализ нотаций ARIS/IDEF и продуктов их поддерживающих (ARIS Toolset/BPWin). // Web: http://www.finexpert.ru/
24. Репина В.В., Елиферова В.Г. «Процессный подход к управлению. Моделирование бизнес-процессов», М.: РИА «Стандарты и качество», 2017.- 248 с.
25. С. М. Патрушина Информационные системы в экономике. / М.: Бизнес , 2014. – 238 с.
26. Смирнов Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем: Учебник – М.: Финансы и статистика, 2016. – 542с.:ил.
27. Шеер Август-Вильгельм. Бизнес-процессы. Основные понятия. Теория. Методы. Издание 2-е, переработанное и дополненное /Научная редакция и предисловие: канд. техн. наук Каменнова М.С., канд. хим. наук Громова А.И. Переводчик: Михайлова Н.А. М.: «Просветитель», 2014. – 216 с.

Процессы BPMN.doc

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

на новый заказ в Автор24. Это бесплатно.

BPMN нотация представляет собой описание графических элементов, используемых для построения схемы протекания бизнес-процесса. В курсовой работе был использован программный продукт Bizagi Process Modeler.
На рисунке 2.8 представлен процесс анализа продаж и маркетинга.
Рисунок 2.8 – Процесс «Анализ продаж. Маркетинг» в BPMN
Для улучшения продаж необходимо регулярно проводить маркетинговые исследования текущего рынка косметики. Важно проводить исследование предприятия розничной торговли с целью получения информации о реальных объемах сбыта товаров отдельных производителей и торговых марок, а также проведение анализа текущего рынка с целью выявления новых, либо популярных предложений. На предприятии маркетингом занимается менеджер по закупкам, результатом процесса является заявки на закупку новой продукции.
Таблица 2.7 – Описание процесса «Анализ продаж

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

. Маркетинг»
Наименование процесса Анализ продаж. Маркетинг
Цель процесса Обновление ассортимента
Результат процесса Перечень товаров на закупку
Вид процесса Вспомогательный
Владелец процесса Генеральный директор
Исполнители процесса Менеджер по закупкам
Актуальная документация Отчет продаж, Маркетинговые исследования
Используемые прикладные ИС База данных компании
Информация об автоматизации Автоматизация отсутствует
Взаимодействие между подразделениями —
Требования к результатам процесса и параметры оценки —
Потребитель Покупатель
На рисунке 2.9 отображен процесс доставки товара и внутренней логистики товара между складом и торговым залом. Товар может быть доставлен за счет средств Поставщика, либо компании в зависимости от обговоренных ранее условиях.
При оплате доставки поставщиком после закупки товара идет ожидание поставки.
При оплате доставки своими средствами Товаровед оформляет заявку на поставку товара в Транспортную компанию и оплачивает их услуги

50% курсовой работы недоступно для прочтения

Закажи написание курсовой работы по выбранной теме всего за пару кликов. Персональная работа в кратчайшее
время!

Реферат: Полный цикл управления бизнес-процессами с применением инструментов, поддерживающих стандарты

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

Bhagat Nainani

Введение

Бизнес-процессы – это основа любой успешной компании. Эти процессы объединяют системы, партнеров и сотрудников для достижения ключевых стратегических и тактических целей. Возрастающее число компаний присматриваются к Web-сервисам и сервис-ориентированной архитектуре (Service Oriented Architecture, SOA) для решения проблем интеграции, возникающих при соединении приложений. BPEL и другие стандарты в области Web-сервисов предлагают открытый, переносимый и стандартизованный способ решения типичных проблем развития приложений. Они позволяют создавать решения на базе SOA, которые обеспечивают гибкость бизнеса при максимальном использовании уже задействованных ресурсов и минимизации стоимости развертывания новых приложений.

Желание располагать адаптивными бизнес-процессами, которые могут быть тонко настроены и оптимизированы, чтобы соответствовать изменяющимся условиям бизнеса, нормативным требованиям законодательства и давлению конкуренции, привело к системам управления бизнес-процессами полного цикла (closed loop Business Process Management (BPM) systems). Oracle BPEL Process Manager + инструменты моделирования других производителей – это полная и легкая в применении платформа для проектирования и развертывания BPM-решений полного цикла.

Рис. 1. BPM-решение полного цикла

Жизненный цикл процесса состоит из следующих шагов или задач:

Моделирование процесса (Model the process) – во время этого шага владельцы бизнес-процессов создают высокоуровневую модель, состоящую из задач, которые должны выполняться, и нужных для этого ресурсов. Кроме того, делаются некоторые предположения о времени выполнения и стоимости каждой задачи.

Имитация и анализ (Simulate and Analyze) — полученная высокоуровневая модель используется для “прогона” некоторых гипотетических сценариев с целью обнаружения критических участков (paths) и “узких горлышек” (bottlenecks). Полученная информация применяется для тонкой настройки процесса перед его развертыванием.

Внедрение и документирование (Implement and document) — во время этого шага высокоуровневый бизнес-процесс, точнее его описание высокого уровня, преобразуется в модель исполняемого процесса. Сам же процесс документируется для того, чтобы он мог использоваться для обучения и сопровождения в будущем.

Развертывание и исполнение (Deploy and Execute) – этот шаг включает развертывание процесса для BPM-“движка” (BPM-engine) и его исполнение для реализации сквозных (end to end) потоков [управления и данных] между системами и людьми.

Мониторинг (Monitor) – во время этого шага происходит мониторинг бизнес-процессов с целью получения ключевых индикаторов эффективности и других метрик. Это шаг выполняется, как правило, с применением средства мониторинга бизнес-активности (Business Activity monitoring tool) совместно с BPM-“движком”.

Оптимизация и перепроектирование (Optimize and Redesign) – после того, как над системой в течение некоторого времени проведен мониторинг, полученные за это время метрики (historical metrics) могут быть использованы для дальнейшей оптимизации процесса. Реальная пропускная способность процесса и метрики использования могут быть введены в инструмент имитации, чтобы получить оптимальную исполненительную модель.

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

II. Моделирование процессов с применением BPMN

В качестве стандарта для моделирования бизнес-процессов получает признание BPMN (Business Process Modeling Notation — нотация моделирования бизнес-процессов), разработанная организацией Business Process Modeling Initiative (BPME.org).

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

BPMN напрямую отображается на языки исполнения бизнес-процессов, такие как BPEL и BPML. BPMN предоставляет нотацию для моделирования, а BPEL является языком описания исполнения процессов.

К ключевым особенностям BPMN относятся:

Пулы и лейны (Pools and lanes — бассейны и дорожки) — эти сущности используются для демаркации процессов и систем. Пул используется, чтобы разделить различные бизнес-сущности или участников. Действия (activities) внутри пулов – это модульные (self-contained) процессы. Лейны (Lanes) используются для описания и разделения действий в пулах (как бы водные дорожки в бассейне – прим.ред). Они, как правило, используются для группирования действий по функциям или ролям.

События и действия (Events and activities) — События используются для представления того, что происходит в процессе бизнес-деятельности. У этих событий обычно есть причины/эффекты (следствия), и они могут влиять на сам поток. Действия ссылаются на работу, которая исполняется, либо как единая задача, либо как набор задач (подпроцесс).

Соединенные объекты (Connect objects) — различные сущности BPMN могут быть соединены через последовательность операций, поток операций (sequence flow), чтобы отметить порядок, в котором действия выполняются, поток сообщений, чтобы отметить сообщения между сущностями, или ассоциацию, используемую для ассоциирования текста и других артифактов с объектами потока (flow objects).

Проектирование сложного процесса (Complex process design) — BPMN может использоваться, как для высокоуровневого описания процессов, так и для описания сложных процессов со многими уровнями детализации. Процессы могут включать детализирующие представления (drill down views) для описания деталей более низкого уровня (lower levels of detail) внутри отдельных диаграмм.

Моделирование и контроль сообщений (Model message and control) — в дополнение к спецификации порядка операций в потоке BPMN обеспечивает представление об объектах данных для моделирования того, как документы, данные и другие объекты используются и изменяются во время процессного потока.

BPMN предоставляет нотацию моделирования, которая обеспечивает переход от бизнес-определений к карте исполнения процесса (process execution map). Объекты BPMN обладают богатым набором атрибутов, которые позволяют легко отображать эти объекты в описания BPEL, стандарт defacto для исполнения процессов.

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

Рассмотрим пример процесса LoanFlow (), который используется типичным брокером займов (loan broker). Этот брокер займов принимает запрос от клиента, выполняет кредитную проверку (credit check) с обращением к внешней службе и затем направляет это прошение к двум различным агентствам по предоставлению займов (loan agencies). После получения предложений от них лучшее будет отобрано и клиент будет уведомлен об этом.

На этапе моделирования обычно специфицируются участники (LoanBroker, CreditRating service, StarLoanService, UnitedLoanService и клиент). Процесс LoanFlow оркестрирует взаимодействия между этими сервисами. Для этого необходимо специфицировать последовательность событий и поток сообщений между этими сущностями, используя BPMN. Рис. 2 иллюстрирует высокоуровневую модель процесса в BPMN и детализацию для подмножества этого процесса, когда соответствующий менеджер (loan offer) обращается к двум различным агентствам по предоставлению займов.

III. Имитация и анализ

Для выполнения имитации во время этого этапа жизненного цикла процесса должны быть сделаны следующие оценки:

Время (период времени), необходимое для исполнения, и цена каждого действия

Определены нужные для каждой задачи ресурсы

Вероятность совершения различных событий или условий в потоке.

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

Вычислить среднее (average elapsed) время транзакции, полную, от начала до конца (end-to-end) пропускную способность и стандартные отклонения (deviation) для определения того, насколько эти отклонения соответствуют допустимым по соглашениям об уровне обслуживания SLA (Service Level Agreements);

Идентифицировать “узкие места” при использовании процесса и ресурсов;

Определить количественно человеческие и другие ресурсы, необходимые для завершения задач, чтобы соответствовать заданным SLA;

Вычислить ожидаемые оценки ошибок и рейтинги уровней обслуживания по 6 сигма (six sigma);

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

Продолжая пример LoanFlow из Секции II, можно смоделировать режим заполнения и время обработки прошений о займе для каждого агентства, о предоставлении займов, а затем “прогнать” имитацию, чтобы оценить пропускную способность или время ответа для сквозного потока. Также, если мы предположим, что есть некоторое, достаточное для выполнения этой задачи, количество агентов по займам в StarLoan и UnitedLoan, и мы зададим некоторое среднее время для обработки прошения о займе, то имитация поможет определить использование ресурсов и число нужных ресурсов на основе ожидаемых запросов на займы.

IV. Документирование и внедрение

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

Следующий после документирования шаг – это внедрение бизнес-процессов. Язык BPEL (Business Process Execution Language) становится очевидным стандартом внедрения для объединения множества синхронных и асинхронных сервисов в коллективные (collaborative) потоки и транзакции. При разработке BPEL воспользовались результатами более чем десяти исследований его предшественников – языков XLANG и WSFL. Он включает следующие концепции:

Web Services/WSDL — как компонентная модель

XML — как модель данных

Шаблоны синхронного и асинхронного обмена сообщениями

Детерминированная и недетерминированная координация потока

Иерархическое управление исключительными ситуациями

Долгоживущая единица работы/компенсации (Long-running unit of work/compensation)

Oracle BPEL Designer предоставляет графический и дружественный интерфейс для построения BPEL-процессов. Что выделяет Oracle BPEL Designer – так то, что BPEL – это его “родной” формат. Это означает, что процессы, построенные с применением этого инструмента, 100% переносимы, и, кроме того, он позволяет разработчикам просматривать и модифицировать исходный код на BPEL, не снижая полезности этого инструмента.

Если высокоуровневый процесс смоделирован на BPMN, он прежде всего экспортируется к скелетному (skeletal) BPEL-процессу, который как правило, состоит из областей действия процесса (process scopes), действий по вызову/получению (invoke/receive activities) и партнерских связей к соответствующим сервисам (partner links to the appropriate services).

Следующие шаги должны быть выполнены в Oracle BPEL Designer, прежде чем данный процесс может быть развернут:

Идентифицирование операций web-сервисов, которые вызываются различными сервисами;

Специфицирование типов XSD для сообщений, которыми обмениваются различные сущности;

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

Специфицирование положения конечных точек (endpoint) и параметров соединения для вовлеченных сервисов.

Если мы рассмотрим пример LoanFlow, описанный ранее, то для кода на BPEL, сгенерированного из средства моделирования BPMN, потребуется включение URL для этих сервисов, XSD для прошения об займе и предложения займа, а также определение трансформаций данных между документами, которые передаются между сервисами. Рис. 3 показывает процесс LoanFlow, смоделированный в Oracle BPEL Designer.

V. Развертывание и исполнение

Наиболее критичным этапом в жизненном цикле процесса является его развертывание на платформе, которая может оркестрировать поток и выполнять различные задачи этого процесса. Оркестрирование набора сервисов в сквозной поток процесса требует выполнения множества технических требований, включая соединение (binding) с разнородными системами, шаблоны для синхронного и асинхронного обмена сообщениями, манипулирование данными, координация в потоке, управление исключительными ситуациями, недетерминированные события, компенсирующие транзакции (compensating transactions), управление версиями, и т.д. Назначение стандарта BPEL – обеспечение более богатого, но в то же время более простого уровня абстракции/стандарта для удовлетворения этих требований. Продукт Oracle BPEL Process Manager обеспечивает наиболее зрелую, масштабируемую и полную реализацию механизма исполнения BPEL, доступную сегодня. Некоторые из ключевых функций этого сервера:

Поддержка стандартов — механизм включает непосредственную поддержку стандартов BPEL и web-сервисов;

Производительность и масштабируемость – высокопроизводительный BPEL-механизм исполняет одновременно множество BPEL-процессов и обеспечивает возможность “отжимки” («dehydration»), так что состояние долгоживущих потоков автоматически поддерживается в базе данных. Возможно применение кластеров для обеспечения масштабируемости и отказоустойчивости;

Продвинутые функции – другие важные функции включают автономную работу с версиями, секционирование процесса и продвинутое управление исключительными ситуациями;

Множество платформ развертывания — BPEL Server использует OC4J как базовый J2EE-сервер приложений с поддержкой большинства основных коммерческих серверов приложений;

Встроенные сервисы интеграции — они позволяют использовать продвинутые возможности соединений и трансформаций из стандартного BPEL-процесса. Эти возможности включают поддержку для трансформаций и соединений с использованием механизма XSLT/Xquery, а также множества тиражируемых приложений и унаследованных систем. Расширяемая схема соединения WSDL обеспечивает соединения по протоколам и форматам сообщений, другим нежели SOAP. Соединения доступны для JMS, электронной почты, JCA, HTTP и многих других протоколов для связи с сотнями внутренних (back-end) систем.

Сервис пользовательской задачи (User task service), предоставляется как встроенный BPEL-сервис для обеспечения интеграции людей и выполняемых ими вручную задач в BPEL-потоки.

BPEL Console предоставляет web-интерфейс для управления, администрирования и отладки процессов, развернутых на BPEL-сервере. Автоматически поддерживаются данные аудита и информация истории процесса и отчетов, и все это доступно через BPEL Console и Java API.

На рисунке 4 показана архитектура BPEL Process Manager и сопутствующих компонентов.

VI. Мониторинг

Измерение ключевых метрик процессов и “видимость” (visibility) в реальном времени исполнения процессов критичны для оценки производительности развернутых бизнес-процессов. Oracle Business Activity Monitoring (BAM) – это критичный компонент нашего полного BPM-решения.

BPEL-процессы могут быть инструментированы с датчиками (sensors), чтобы осуществлять мониторинг критических действий и переменных. BAM позволяет соединять эти индивидуальные метрики в составные события. Панель BAM позволяет реализовать мониторинг, анализировать и своевременно отвечать на события или исключительные ситуации, которые происходят внутри предприятия.

Ключевые концепции Oracle BAM таковы:

Бизнес-события (Business Events) – перехват таких интересных событий как изменение информации о клиентах, изменения в описи товаров, заказах на покупку из широкого ряда информационных систем предприятия (EIS).

Составные события (Composite events) – определение, агрегирование, соотнесение и фильтрация событий от различных конечных систем.

Метрики и ключевые индикаторы эффективности (КПЭ или KPI) – выполнение сложной обработки составных событий для генерации метрик и КАЭ.

Сигналы (Alerts) – уведомление пользователей через различные каналы (электронная почта, голосовая почта, пэйджеры,..) на основе превышения пороговых значений и/или порогов рисков для некоторых ключевых метрик.

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

Продолжим наш пример с LoanFlow из Секции II. После того, как процесс развернут, BAM-панель может быть использована, чтобы ответить на критические бизнес-вопросы:

(a) Запросы на займы, предоставленные сегодня, на этой неделе, в этом месяце.

(b) Предложения займов по агентствам

(c) Среднее время обработки одного займа

(d) средняя кредитная оценка (скоринг) лиц, желающих получить заем.

Также BAM-панель может отобразить сигналы:

(a) были предоставлены займы многим лицам с низкой скоринговой оценкой

(b) процент отвергнутых прошений о займах больше 10%.

Последний факт можно использовать для переоценки критериев отбора или для того, чтобы предпринять некоторые предупредительные действия. Рисунок 6 показывает BAM-панель с некоторыми ключевыми метриками для процесса LoanFlow.

VII. Оптимизация и перепроектирование

BAM закрывает отсутствующее звено между исполнением процесса и перепроектированием. Традиционно имитация процессов основана на предположениях и догадках. Проблема такого подхода в том, что надежны только результаты, а предположения делались на этапе моделирования. При применении BAM, как данные реального времени, так и исторические данные, накопленные за период времени, могут быть использованы, чтобы промоделировать процесс “как есть” (“as-is”) и создать оптимальный процесс “как должно быть” («to-be»). Благодаря таким успешным итерациям процесс может быть тонко настроен, что приведет к значительной экономии ресурсов и средств.

События в BAM также могут быть использованы для оптимизации развернутых процессе в реальном времени, благодаря изменениям потока бизнес-процесса. Сигналы (alerts) BAM также могут начать новые бизнес-процессы для обработки исключительных ситуаций или быть использованы для прерываний процессов.

Еще раз рассмотрим пример LoanFlow. На этапе оптимизации должны использоваться данные реальной обработки на основе ежедневных/ежемесячных отчетов и затем прогоны инструмента имитации для обнаружения возможных узких мест и уровней обслуживания (predict SLA). Это может привести к перепроектированию процесса. Например, к добавлению новых сервисов при оформлении займа, что соответствовать требованиям по времени ответ. Некоторые из этих метрик также могут использоваться в реальном масштабе времени. Например, если какое-то из агентств слишком долго не отвечает, процесс может продолжать работу только с одним предложением займа (применительно к одному агентству), чтобы удовлетворить SLA-требованиям обслуживания.

VIII. Партнеры

Корпорация Oracle установила партнерские отношения с рядом поставщиков, чтобы предоставить средства моделирования и имитации вместе с Oracle BPEL Process Manager и инструментом Oracle Business Activity Monitoring. В число этих поставщиков входят Popkin Systems and Software Ltd (www.popkin.com) — продукты Popkin System Architect и Popkin Simulator II могут быть использованы для моделирования и анализа процессов. При этом применяется BPMN и экспорт в формате BPEL для развертывания на платформе Oracle.

За более подробной информацией о моделировании процессов с использованием этих средств, их внедрении и развертывании с Oracle BPEL Process Manager, обращайтесь по адресу www.oracle.com/technology/products/integration/index.html

IX. Заключение

BPM-системы полного цикла критичны для разработки эффективных бизнес-процессов, которые должны быстро реагировать на изменяющиеся бизнес-условия. Oracle AS Integration – это в настоящее время наиболее полная BPM-платформа на рынке. Она обеспечивает реализацию всего жизненного цикла процесса, включая моделирование, имитацию, внедрение, исполнение, мониторинг и оптимизацию бизнес-процессов.