Я уже рассказывал об основных типах описания бизнес-процессов и обозначил свое отношение к самой продвинутой из них .

Сравнительный анализ нотаций моделирования бизнес- процессов . СУБД. Модель процесса представляет собой взаимоувязанную интегрированную совокупность функциональной, поведенческой, информационной и организационной перспектив, однако многие модели, используемые сегодня в практике реинжиниринга, не удовлетворяют требованиям, предъявляемым к процессным моделям, и не могут называться процессными, поскольку дают неполное представление об объекте моделирования и не содержат всей информации, необходимой для создания исполняемой модели. Анализу подвергаются возможности нотаций EPC (Event- driven Process Chains) и BPMN (Business Process Modeling Notation), синтаксис, набор примитивов языка описания и т. Однако сравнивать нотации и языки описания бизнес- процесса путем анализа их функциональности некорректно — является ли модель функциональной или процессной, определяет не только нотация, но и методология. Часто методология моделирования подменяется нотацией, что приводит к серьезным ошибкам в проектировании бизнес- процессов и появлению некачественных моделей.

Система моделирования бизнес-процессов ARIS . Рассмотрим наиболее известные графические нотации описания процессов: IDEF0 . UML хорошо ориентирована на описание архитектуры .

Сложный объект, например бизнес- процесс, описывается совокупностью моделей, каждая из которых отображает ограниченный набор свойств, а все вместе они описывают объект моделирования полностью. Каждая из частных моделей . Выделяются четыре перспективы модели бизнес- процесса (см. Описывает состав выполняемых работ. Поведенческая: «Как работают участники?». Описывает очередность, расписание выполнения, бизнес- правила. Информационная: «Что обрабатывают участники?».

Описывает бизнес- сущности предметной области процесса. Организационная: «Кто выполняет работу?». Описывает состав и структуру исполнителей.

В последнем случае надо быть особенно внимательным, перспектива модели определяется именно главным вопросом, а не вспомогательным. Функциональная перспектива. Басни Крылова Школьная Программа. BPM со всех сторон.

С чем связан повышенный интерес к BPM и какие решения в данной области предлагаются сегодня отечественному бизнесу? Наталья Дубова. Функциональная модель описывает систему в статическом состоянии, помогает ответить на вопрос «что надо делать для достижения поставленной цели?». Ответом является перечень всех действий, которые необходимо выполнить, чтобы добиться запланированного результата. В управлении проектами широко применяется структурная декомпозиция работ (Work Breakdown Structure) — перечисленные в ней действия не связаны временной последовательностью. Аналогично, при моделировании процессов очень полезно создать структурную декомпозицию, которая поможет понять логику процесса и не забыть выполнить какую- либо важную функцию.

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

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

Аспекты поведенческой перспективы. Эталонная модель BPM. Сегодня производители ПО определяют и развивают BPM по- разному, однако более перспективный путь — это BPM, ориентированный на нужды конечных потребителей, и эталонная модель BPM может быть первым шагом по созданию единого понимания BPM. Александр Самарин. Поведенческая перспектива, описывающая динамику системы, отвечает на вопрос «как работают участники?». Для ее моделирования используется диаграмма потоков управления.

• К классическим стандартам описания бизнес процесса. Основные нотации: ERD (Нотация Чена), UML (Class Diargamm), IDEF1x.
• Business Process Model and Notation, нотация и модель бизнес-процессов). 4 Использование BPMN; 5 Пример. 5.1 Словесное описание бизнес-процесса; 5.2 Модель бизнес-процесса в BPMN. 6 BPMN 2.0; 7 См.
• Нии бизнес-процессов: нотации семейства IDEF, UML, BPMN.
• Инструменты управления и моделирования бизнес-процессов. Если вы хотите получить не только модели и описания бизнес-процессов, но и. Для построения моделей используется нотация BPMN 2.0.
• В ходе своей работы и преподавания я сталкиваюсь с описанием бизнес-процессов организации в нотации eEPC (Extended event .

Основной вопрос «как?» можно разделить на три: «В какой очередности выполняются операции, образующие процесс? В какое время выполняется операция?

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

Ответ на третий вопрос дают бизнес- правила, являющиеся декларативным описанием ограничений, накладываемых на процесс. Бизнес- логика процесса. Очередность операций, образующих процесс, принято называть бизнес- логикой, и для ее описания применяются диаграммы потоков работ (UML, EPC, ABC Flowchart — описания на базе блок- схем). Бизнес- логика содержит явные, предписывающие сведения о маршруте исполнения процесса, но лишь косвенно учитывает критерии принятия соответствующих решений. Ветвление есть элемент бизнес- логики, а условие, по которому осуществляется ветвление, есть бизнес- правило. Часто бизнес- аналитики не разделяют логику и правила и размещают на диаграмме элемент «ветвление», но опускают связанное с ним правило ветвления.

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

Как следствие, модель процесса на бумаге не соответствует логике работы ИТ- системы — именно эти неточности исходного описания бизнес- процесса приводят к многочисленным доработкам, которые возникают на этапе внедрения информационных систем. Бизнес- правила. Под бизнес- правилом принято понимать утверждение, определяющее или ограничивающее некоторые аспекты бизнеса. В отличие от процедурного описания, правила постулируют ограничения на исполнение процесса, но не определяют, как именно предполагается достичь результата. Специалист в области бизнес- правил Рональд Росс дает следующую классификацию бизнес- правил . Например, представим такую последовательность действий: вычислить величину скидки как функцию от размера текущего заказа (правило вычисления); классифицировать размер скидки: большая, средняя, низкая (правило классификации); отправить сделку на одобрение руководителю с соответствующим уровнем полномочий (правило поведения). Однако получила распространение порочная практика размещения на схеме элемента «ветвление» с включением прямо в него и правила поведения, и правила определения, что делает схему негибкой, а описание неполным. Итак, следует явно выделять все правила в отдельные конструкции на диаграмме потоков работ, что поможет аналитику четко локализовать соответствующую логику.

Расписание исполнения. Открытая BPM- платформа.

С увеличением сложности программных систем повышается роль моделирования, позволяющего интегрировать бизнес- процессы, но почему бы не построить инструмент моделирования на принципах Web 2. Геро Декер, Матиас Веске, Сергей Смирнов, Хаген Овердик. В области материального производства широко применяется график выполнения работ, используемый для расчета времени, затрачиваемого на производство изделия. Для бизнес- процессов расписание работ имеет более сложный вид, поскольку каждая операция может исполняться вовремя, а весь процесс — с опозданием, из- за возвратов назад на повторную обработку. Под событием понимается точка на шкале времени, не имеющая длительности. События используются для координации исполнения разных процессов или ветвей одного процесса.

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