В этой статье вы узнаете, что такое нотации, зачем они нужны, и какие виды моделирования бизнес-процессов существуют в природе. Сравним положительные и отрицательные стороны каждого из них. Более подробно погрузимся в, пожалуй, один из самых универсальных и удобных инструментов – BPMN 2.0. Разберем основные элементы и попрактикуемся на реальном примере. Я предоставлю вам базовые знания, которые позволят вам сразу после завершения знакомства с данной статьёй, спроектировать свою первую BPMN-диаграмму на любую актуальную для вас профессиональную тему.
Представьте, что вам, как, например, сотруднику молочной фермы, необходимо изменить статус животного, которое перешло в категорию "готовых к осеменению". Для этого будет действовать следующий алгоритм: Поступление задачи – проверка параметров животного – внесение изменений – завершение задачи. Кажется просто и повседневно. А теперь давайте перенесем этот алгоритм на более масштабную бизнес-задачу, в которой придется учитывать не только действия одного зоотехника, но взаимодействие с прочими элементами всей системы учета и управления молочных производством (регламентированное время, выгрузка данных из карточки животного, создание и фиксация результатов проверки, отражение документов в общей базе и т.п.) И, как только вы это себе представили, усложняем. Идентичный бизнес-процесс должен проводиться с определенной периодичностью на ферме с поголовьем в 1000 коров, каждая из которых может либо соответствовать требуемым условиям, либо нет.
Согласитесь, для того, чтобы реализовать такой проект на высшем уровне и без ошибок, потребуется детальный план действий, правильное распределение обязанностей и чёткий контроль. Кроме того, придется расставить реперные точки для промежуточного подведения итогов, мониторинга соблюдения сроков и оперативного принятия решений. Для этого, например, можно применить классическую методологию оптимизации бизнес-процессов «As is и To be» (Как есть и Как будет), которая призвана разграничить анализ текущей ситуации и планирование улучшений. Удержать весь этот объем информации в голове крайне сложно, а во избежание накладок и ошибок придется как-то организовать устойчивую оперативную связь между всеми участниками процесса. Вот здесь и появляется такой незаменимый помощник, как BPMN.
Проще, удобнее и быстрее будет спроектировать общую картину визуально, без лишних отвлекающих слов, пояснений и элементов. Такие графические модели бизнес-процессов и называются нотациями. На сегодняшний день существует несколько наиболее популярных и востребованных видов нотаций:
IDEF0 – строится слева направо и сверху вниз по диагонали от доминирующих объектов к объектам подчиненным. Такой метод имеет высокую степень детализации, но подходит для случаев, когда бизнес-процессы представляют собой одну цепочку без «развилок». Если же в данной цепи имеются условия, предполагающие выбор между двумя и более путями развития, то такой вид нотаций перестает быть простым и удобным.
eEPC – за счёт разнообразия фигур по форме и цвету, это визуально более интуитивная понятная модель. Структура бизнес-процессов строится сверху вниз и лучше подходит для создания сложных развилок и длинных параллельных рядов событий. При этом для каждого элемента можно создать отдельную схему, тем самым разложив его на более мелкие составные элементы. Главным минусом EPC является вынужденная перегруженность «событиями», которые приходится создавать для всех, даже самых незначительных этапов. При создании такой нотации неизбежным станет нагромождение повторяющихся простых элементов, таких, как, например, «определить исполнителя» или «согласовать» к каждому выделенному этапу.
UML – это унифицированный язык моделирования, отличающийся высокой подробностью и детализацией. Однако, среди недостатков выделяют часто неоправданную избыточность и сложность, а также неспособность входа одной системы воспринимать выход другой.
Используйте BPMN в Maker для моделирования бизнес-процессов
Удобный и простой инструмент: изменяйте и редактируйте всё парой кликов, просто перетаскивайте элементы, назначайте роли и задавайте условия.
Программный продукт является самостоятельным решением, разработанным на современной технологической платформе "1С:Предприятие 8.3" и позволяет автоматизировать основные бизнес-процессы производственных лабораторий, служб управления качеством и ОТК на предприятиях с дискретными и процессными типами производств, а также независимых и аккредитованных лабораторий.
Анкета-опросник по 1С: ЗУП, состоит из 70 вопросов. Используется до предпроектного обследования для проекта по автоматизации бизнес-процессов на базе 1С: ЗУП .
Обработка для создания ментальных карт / работы с графической схемой 1С / визуализации бизнес-процессов.
Гибкое управление: направление новых элементов / цвет элементов / типы линий / типы рамок / картинки / фигуры.
Дополнительные возможности: совместная/групповая работа со схемой через механизм Системы взаимодействия 1С.
Обработка открывает карту из файла в формате графической схемы и сохраняет в формате PNG и BMP. Будет полезна специалистам для оформления технической документации программного продукта.
После реализации проекта, основанного на бизнес-процессах - потребовался некий инструмент для администрирования задач исполнителя. Для отмены ошибочно выполненных задач и для отмены ошибочных переходов во вложенные бизнес-процессы.
Давно понял что нужен удобный инструмент построения схем при разработке, но не мог найти удобное. Мучался с UML и ER диаграммами. А тут вот случайно увидел недавно BPMN, сразу видно было что это то, что нужно. А тут научился как пользоваться. Спасибо за статью, ничего лишнего.
А где: "меня зовут вася, я работаю китайцем в 1С..."?
Вообще, нотаций полно. Самая простая, как мне кажется, EPC. С другой стороны, любой человек без справки с помощью квадратиков и стрелочек способен нарисовать любой процесс, в котором он разбирается. А все эти красоты - это все мало помогает выполнить основную функцию схемы - сделать процесс понятным любой официантке (с).
(4) "Самая простая, как мне кажется, EPC" - много аннотаций писать нужно, тот же таймер или исходящее сообщение.
Думаю зависит от подхода объясняющего, так же от объясняемого процесса. Операционные процессы легко и понятно на BPMN, с аналитическими и набором условий периодически закапываюсь.
(0) в то же время простой инструмент для создания проектов бизнес-процессов любого уровня сложности - не простой, сильно зависит от степени описания "объяснить", к выполнению человеком, к выполнению машиной.
"BPMN-диаграмм прекрасно подходит для прогнозирования сроков, а также оценки вероятных рисков и потенциальных проблем" - для оркестровки возможно, для высокого уровня использовали IDEF0 сейчас используют C4 https://infostart.ru/pm/1540208/, для риск анализа Диаграмма Исикавы
(4) По моему опыту, главная проблема всех этих нотаций в том, что постановщики задач на стороне заказчика не понимают этих замечательных картинок, даже если у них очень приличное базовое образование. Есть немалый риск, что они прикинутся, что все поняли.
Если речь идет об артефакте, который будет жить внутри проектной команды, то возможно оно некую ценность представляет. С заказчиком лучше в эти игры не играть и описывать его бизнес-процессы, сценарии работы пользователя и спецификации решения простым человеческим языком в MS Word.
С другой стороны, любой человек без справки с помощью квадратиков и стрелочек способен нарисовать любой процесс, в котором он разбирается.
Ага, на этапе сбора требований и предпроектного анализа задачи, "рисование на салфетках" - прекрасный метод, после которого спокойно можно садиться и готовить текст в MS Word на согласование.
(10) У меня сейчас заказчики, это компании, которые по среднесписочной численности сотрудников попадают под критерии среднего бизнеса, по выручке превосходят в полтора-два раза, крепкие такие региональные среднячки пара филиалов по регионам, 50+ рабочих мест пользователей. Там MS Word рулит. Вчера вот отправил текст в ворде в Москву, - не поверите, прочитали.
Я до кризиса осьмого года трудился в системной интеграции и привык к красивому и удобочитаемому формату документов, чтоб было приятно распечатку держать в руках. Когда приходится у заказчика проводить совещание по проекту, люди подтягиваются с распечатками моей писанины, цветными маркерами выделяют нужные куски, красота. Мне даже .rtf формата не всегда хватает.
Я до кризиса осьмого года трудился в системной интеграции и привык к красивому и удобочитаемому формату документов, чтоб было приятно распечатку держать в руках.
А я любил, как выглядит текст в Лесиконе - отличный был редактор. А потмо кто-то из демократов решил, что мы все купим у них )))
ЗЫ: мне вот текст консоли разукрашенной нравиццо. А распечатки - это прошлый век. Сейчас рулят интерактивные вебтехнолгичные диаграммы. И поверпоинты там уже не особо рулят. Все на расшаренных экранчиках в VKTeams и прочем отечественном софте. А динозабров - на свалку истории.
(14) Выглядит привлекательно, одно не понятно, каким образом участники проекта будут прикрывать свою задницу "интерактивной вебтехнологичной диаграммой". В рамках старой школы, каждый чих и каждый пых в проекте, должен быть письменно согласован с заказчиком и подписан ответственными. ИТ-проекты, это деятельность весьма рисковая, и риски несут все участники проекта - и со стороны исполнителя, и со стороны заказчика. Никому не интересно сливать свою карьеру в унитаз из-за чужих косяков или откровенных подстав. Задница должна быть прикрыта, в старину это называли принципом CYA - Cover Your Ass. Если у все в проекте задница прикрыта, то и эффективности больше и результаты лучше.
Самое главное что бы нотация писалась кодом, "все как код", и тогда можно хранить в git всю историю изменений.
Два основных плюса создания нотации кодом:
1. быстро можно накидать, изменить схему.
2. храним историю в git
BPMN - это максимально просто и интуитивно понятно? даже самых сложных алгоритмов??
И кому вы ее будете показывать? зоотехнику или бухгалтеру - не поймут, аналитику - утонет в переходах, особенно в условных и асинхронных (и не дай бог не утонет, а попросит веточку пририсовать), заказчику? - да он даже не поймет куда свои пожелания влепить...
Кто-то обозвал BPMN - "от программиста программисту". Согласна полностью, но с программистами надежнее договариваться глядя в код (когда он будет). А до этого - блок-схемку, можно docs-as-code, можно UML (только подходящую схему, а не объектную как в примере). Даже квадратики на салфетке подойдут. Но не рисовать же для программиста pools and lanes.
Так для кого она BPMN?
IDE под BPMN, конечно, зачетные. Но суть-то все-таки, не чтобы быстро нарисовать, а чтобы легко понять...
Может переубедит кто, а? Обещаю внимательно выслушать и проникнутся...