Краткое описание нотации bpmn

Список материалов с термином «BPMS»

Материал BPTrends
В этом номере мы рассмотрим управление бизнес-процессами (Business Process Management, BPM) в 2010 году, а затем заглянем в будущее и поговорим о некоторых моментах, которые, на наш взгляд, будут показательными в текущем 2011 году.
Пол Хармон, Селия Вулф. Перевод портала www.FineXpert.ru.

Сегодня идею повышения эффективности управления путем улучшения бизнес-процессов взяли на вооружение многие крупные компании. Методология BPM (Business Process Management — управление бизнес-процессами) возникла в ответ на эту потребность. Какие новые возможности предоставляет предприятию применение BPM-систем? Какие технологические решения позволяют реализовать этот подход?
Вишневский Владимир, 2007 г.

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

Статья гуру, идеолога и практика BPM Ismael Chang Ghalimi. Статья подходит наверное больше в качестве вводной статьи для среднего уровня понимания BPM.
Ismael Chang Ghalimi, 2007 г.

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

Статья А. Коптелова «Тенденции в управлении бизнес-процессами»
«… Управление деятельностью компании как системой процессов позволяет достичь нового качества управления, причем для внедрения процессного управления наиболее эффективны системы класса Business Process Management. Теория управления бизнес-процессами уже давно используется..»

Резюме: Тони M. Браун (Tony M. Brown) описывает историю развития BPM и взгляды четырех первопроходцев в этой области.
(Перевод статьи выполнен специалистами ООО «ФИНЭКСПЕРТ.РУ»)

Рост значимости ИТ порой негативно сказывается на качестве управления организациями. Многие руководители начинают рассматривать информационные системы как универсальное решение управленческих проблем. В результате «автоматизация хаоса» только усугубляет негативные тенденции. Можно ли повышать эффективность бизнес-процессов без применения специализированной BPM-системы?
Статья В.В.Репина. 2007 г.

Статья Девида М. Говерана представляет интерес с точки зрения анализа развития взглядов на BPM. Переводить ее было достаточно сложно — язык автора статьи весьма витиеватый. Интересно отметить, что о простых вещах он умудряется говорить сложно, а о сложных – местами слишком поверхностно. Тем не менее, статья содержит много интересной информации по теме процессного подхода к управлению.
В.В. Репин. 2005 г.

2

Что моделируете, то и выполняете

На рис. 2 приведена обобщенная модель процессно-управляемого предприятия.

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

Такое описание — основа дисциплины BPM, позволяющей моделировать, автоматизировать, выполнять, контролировать, измерять и оптимизировать потоки работ, охватывающие программные системы, сотрудников, клиентов и партнеров в пределах и вне границ предприятия. Дисциплина BPM рассматривает все операции с бизнес-процессами (моделирование, исполнение и т.п.) как единое целое (рис. 3).

На данный момент в индустрии BPM еще не сложилась надлежащая система стандартов на форматы формального описания бизнес-процессов. Три наиболее популярных формата: BPMN (Business Process Modelling Notation, графическое представление моделей бизнес-процессов), BPEL (Business Process Execution Language, формализация исполнения взаимодействия между Web-сервисами) и XPDL (XML Process Description Language, www.wfmc.org, спецификация по обмену моделями бизнес-процессов между различными приложениями) были разработаны различными группами и для различных целей и, к сожалению, адекватно не взаимодополняют друг друга.

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

Как это неоднократно повторялось, в подобной борьбе интересы конечного потребителя мало принимаются во внимание — сегодня нет достаточно мощной организации, представляющей интересы конечного потребителя BPM (по аналогии с группой стандартов для HTML, успех которой объясняется принятием всеми разработчиками Web-браузеров единого теста ACID3 для сравнения своих продуктов). Идеальной ситуацией в BPM было бы стандартное определение семантики исполнения для BPMN-подобного описания бизнес-процессов

Именно стандартная семантика исполнения гарантировала бы одинаковую интерпретацию бизнес-процессов любым ПО. Дополнительно такое описание должно позволять адаптацию степени описания бизнес-процессов для нужд конкретного потребителя (например, пользователь видит грубую диаграмму, аналитик — более подробную и т.п.).

Все это не означает, что BPEL или XPDL станут ненужными — их использование будет скрыто, как это происходит в сфере подготовки электронных документов. Один и тот же электронный документ может одновременно существовать в XML, PDF, PostScript и т.п., но только один основной формат (XML) используется для модификации документа.

Принятие модели как стандарта

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

Следующая встреча была в Париже. Перед ней группа ученых в 2 или 3 часа ночи обновляла и копировала текст документа (вспоминаются студенты перед сессией). Забавный факт: 6 или 7 человек группы Бакмана поместились, а точнее навалились друг на друга, в маленькую французскую машину Юбера Citroën 2CV (Deux Chevaux), чтобы успеть на собрание. Цель, которая двигала Бакмана и его коллег вперед – это возможность использовать модель на практике, познакомить всех с понятием многоуровневой архитектуры. 

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

Начиная с 1977 года, ISO провела программу по разработке общих стандартов и методов создания сетей, но аналогичный процесс появился в некоммерческой организации по стандартизации информационных и коммуникационных систем (ECMA) и Международном консультативном комитете по телеграфу и телефону (CCITT). Делегаты от этих групп присутствовали на собраниях ISO, и все они работали над одной целью. Позже CCITT приняла документы, которые почти идентичны документам ISO, и группа стала сотрудничать с ISO.

В 1983 году документы CCITT и ISO были объединены, чтобы сформировать Базовую эталонную модель взаимодействия открытых систем или просто модель OSI. Общий документ был опубликован в 1984 году как стандарт ISO 7498.

Теперь немного подробнее о самой модели OSI и ее принципах.

Материалы

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

• Почитать об отличиях модели SNA и OSI можно в статье «SNA and OSI: Three Strategies for Interconnection» от Мэтью Тилмана (Matthew A. Tillman) и Дэвида Йена (David Chi-Chung Yen).

• В интервью Джеймса Пелки Чарльз Бакман отвечает на вопросы о модели OSI,  рассказывает о собраниях ISO и их участниках.

• Веб-сайт, созданный на основе книги Джеймса Пелки «The History of Computer Communications». Тут собраны личные рассказы людей, участвовавших в развитии компьютерных коммуникаций.

• В публикации на Habr представлен перевод статьи «OSI: Интернет, которого не было» Эндрю Л. Рассела. Если вы хотите узнать, как же TCP/IP превзошел OSI, то вам сюда.

• В видеоинтервью Гарденера Хендри Чарльз Бакман рассказывает про «Проект интегрированных систем 2» General Electric, который был предназначен для создания общей «Производственной информации и системы управления» или MIACS. Этот проект, в свою очередь, создал интегрированное хранилище данных (IDS), первую систему управления базами данных. Здесь он также упоминает и про OSI.

UPD: Citroën 2CV (Deux Chevaux) — это французский автомобиль, а не британский.

Инструменты

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

Моделирование и симуляция

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

• Диаграммы вариантов использования сделано Ивар Якобсон, 1992 (интегрирован в UML )
• Диаграммы деятельности (также принят UML)

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

• Модель и обозначение бизнес-процесса (BPMN)
• Язык моделирования жизненного цикла (LML)
• Предметно-ориентированное управление бизнес-процессами (S-BPM)
• Улучшенное познание Метод анализа информации на естественном языке (CogNIAM)
• Расширенный язык бизнес-моделирования (xBML)
• Цепочка процессов, управляемая событиями (EPC)
• Определение ICAM (IDEF0 )
• Единый язык моделирования (UML), расширения для бизнес-процессов
• Формализованная административная нотация (FAN)
• Харбарское моделирование процессов (HPM)

Инструменты языка программирования

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

Языки программирования, которые вводятся для BPM, включают:

• Язык выполнения бизнес-процессов (BPEL ),
• Язык описания хореографии веб-сервисов (WS-CDL ).
• Язык определения процессов XML (XPDL ),

Некоторые языки, зависящие от поставщика:

• Архитектура интегрированных информационных систем (ARIS) поддерживает EPC,
• Язык определения процессов Java (JBPM ),

Другие технологии, связанные с моделированием бизнес-процессов, включают: управляемая моделями архитектура и Сервис-Ориентированная Архитектура.

Зачем Pega сотрудникам компаний?

1. Исчезает излишняя «плохая» бюрократия — все ненужные звенья, согласования, влияния исключаются благодаря прозрачности системы.
2. Налаживается мониторинг — каждый сотрудник может следить за процессами в рамках своих компетенций, анализировать, предлагать улучшения и тем самым глубже включаться в работу, становиться ещё более необходимым сотрудником.
3. Снижаются затраты на организацию процессов, увеличивается удовлетворенность клиентов, растёт выручка. А большая выручка — хороший шанс получить увеличенную премию.
4. Все процессы абсолютно прозрачны: каждый участник может наблюдать за их ходом, видеть, у кого процесс находится. Перекладывание ответственности и человеческий фактор исчезают практически полностью. В такой ситуации улучшаются отношения внутри коллектива, растёт доверие.
5. Наконец, система BPM в компании — это дополнительная мотивация, поскольку каждый сотрудник может непосредственно участвовать в управлении компанией, ощущать свою полезность. А мотивированный работник — ключ к успеху всей команды.

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

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

Процессные модели – это средства:

• управления процессами организации;
• анализа эффективности процесса;
• описания изменений.

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

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

Шорт-лист

В итоге рассмотрим несколько систем.

1. Comindware. Компания с русскоязычными корнями изначально стартовала как международная с офисами в США и только в 2012 году вышла на рынок СНГ. Значимый вендор BPM системы для нашей страны.

2. Creatio. С 2011 года разрабатывалась как bpm’online, но в 2019 году компания изменила бренд и перепрыгнула российский рынок.

   

   

   

   

   

   

   

   

   

   

3. ELMA365. Компания ELMA выпускает BPM-продукты с 2008 года, а новый флагман вышел в свет в 2020 году.

4. Бипиум. Систему выкатили в 2015 году сотрудники, которые разрабатывали Oktell.

Creatio и ELMA — две наиболее известные и популярные системы в России. Компании делят первое место в топе BPM-систем по внедрению в СНГ.

Будем проводить сравнение BPM-систем между этими системами в определенных областях взаимодействия с пользователем или реальным бизнес-процессом. Список областей следующий:

1. Базовые функции. Старт-пак любой системы — пользователи в одном приложении могут исполнить поставленные задачи, запланировать встречу или обсудить вопрос с коллегами;

2. Готовые решения. Как быстро стартовать работу или донастроить систему;

3. Объектная модель. Как донастроить систему самостоятельно;

4. Процессы и моделирование. Смотрим на дизайнеры процессов, легкость настройки, читаемость карты, общие впечатления от работы;

5. CRM. Насколько готова основа для создания взаимоотношений с клиентами;

6. Документооборот. Наличие соответствующих задач по документам, процедуры работы с файлами;

7. Приложения. Мобилки или десктоп;

8. Дополнительная разработка. Как можно доработать систему новыми специальными возможностями;

9. Интеграция со сторонними системами;

10. Цена и пробный период.

Исполняемые и неисполняемые бизнес-процессы

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

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

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

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

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

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

Сетевая модель OSI – «это баааза»

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

Модель OSI

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

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

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

Цель: повышение производительности предприятия

Для управления своей производительностью большинство предприятий используют принцип обратной связи (рис. 1), позволяющий адаптироваться к внешней бизнес-экосистеме путем выполнения определенной последовательности действий:

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

2. Вычленение из внешней бизнес-экосистемы важных для предприятия событий (например, законов или новых потребностей рынка);

3. Определение стратегии развития бизнеса предприятия;

4. Реализация принятых решений (путем внесения изменений в бизнес-систему предприятия).

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

• обеспечение руководства надлежащей информацией и инструментами для принятия решения;

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

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

Как избежать ошибок в моделировании бизнес-процессов?

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

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

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

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

Топ-5 рекомендаций, как избежать ошибок при моделировании:

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

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

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

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

Мы желаем, чтобы все процессы в вашем бизнесе и вашей жизни были упорядочены и приносили желаемый эффект. Мы ждем вас на наших программах «ТРИЗ на практике: творческий подход на работе и в жизни» и «Лучшие техники самообразования». И предлагаем ответить на вопрос по теме статьи:

История

Методы моделирования бизнес-процессов, такие как блок-схема, функциональная блок-схема, блок-схема управления, Диаграмма Ганта, ПЕРТ диаграмма и IDEF возникли с начала 20 века. Диаграммы Ганта были одними из первых, кто появился около 1899 года, блок-схемы — в 1920-х, функциональные блок-схемы и PERT в 1950-х, диаграммы потоков данных и IDEF — в 1970-х. Среди современных методов есть Единый язык моделирования и Модель и обозначение бизнес-процесса. Тем не менее, это лишь часть методологий, используемых на протяжении многих лет для документирования бизнес-процессов. Термин «моделирование бизнес-процессов» был придуман в 1960-х годах в области системная инженерия С. Уильямс в его статье 1967 года «Моделирование бизнес-процессов улучшает административный контроль». Его идея заключалась в том, что методы для лучшего понимания физических систем управления можно было бы аналогичным образом использовать для деловые процессы. Этот термин стал популярным только в 1990-х годах.

В 1990-е годы термин ‘процесс ‘стала новой парадигмой производительности. Компаниям было рекомендовано думать процессы вместо функции и процедуры. Процессное мышление рассматривает цепочку событий в компании от покупки до поставки, от получения заказа до продаж и т. Д. Традиционные инструменты моделирования были разработаны для иллюстрации времени и затрат, в то время как современные инструменты ориентированы на межфункциональные действия. Эти кросс-функциональные виды деятельности значительно увеличились по количеству и значимости из-за роста сложности и зависимости. Новые методологии включают редизайн бизнес-процессов, инновации бизнес-процессов, управление бизнес-процессами, комплексное бизнес-планирование, среди прочего, все «нацелены на улучшение процессов по традиционным функциям компании».

В области программная инженерия термин «моделирование бизнес-процессов» противопоставил программный процесс моделирования, стремясь больше сосредоточиться на состоянии практики во время разработка программного обеспечения. В то время (начало 1990-х) все существующие и новые методы моделирования для иллюстрации бизнес-процессов были объединены в «языки моделирования бизнес-процессов».[нужна цитата ]. в Объектно-ориентированный подход, это считалось важным шагом в спецификации систем бизнес-приложений. Моделирование бизнес-процессов стало основой новых методологий, например, тех, которые поддерживали сбор данных, анализ потоков данных, диаграммы потоков процессов и средства отчетности. Примерно в 1995 году были представлены первые визуально ориентированные инструменты для моделирования и реализации бизнес-процессов.