Comments 34
Так всё таки 'как начать моделировать бизнес-процессы в BPMN'? Краткое описание bpmn уже здесь на хабре 1000 и один раз всевозможные авторы описывали. Все статьи точь-в-точь совпадают между собой. И в вашей ну ни грамма нет ничего нового или другого. Даже по выводам сходство полное.
На последок. А Вы хоть раз какой-нибудь сложный процесс таким способом моделировали, и так, чтобы это не для галочки было, а именно работающий процесс? Что при этом вы поняли для себя, для продвижения этой темы в массы? Что надо ещё раз азбуку описать?
Потому что читаю Ваши слова
Однако, избыточный алфавит нотации, особенно слишком большой набор событий и шлюзов, затрудняют разработку и чтение дидиаграмм.
И думаю, а это правда для экспертного использования или так - поиграться? Хотя о чём я? Ведь ваши слова говорят за себя.
Наконец, при разработке любой диаграммы нужно помнить о главном правиле аналитика: независимо от нотации, ваша схема должна быть МАКСИМАЛЬНО простой и понятной читателю БЕЗ знания тонкостей процессного моделирования!
мне кажется, что Вы ошибаетесь. Музыкальные ноты не должны быть понятны любому человеку, никогда не изучающих музыку. Также и электрические схемы останутся для многих непонятными, которые не знают, что такое транзистор, резистор, конденсатор итд. Так-же и языки программирования и диаграммы bpmn. Если они кому непонятны, но есть правильные - это не недостаток диаграмм, а незнания этой нотации.
Короче не очень хорошее впечатление от Вашей статьи. Жаль. Тк. тема очень интересная.
Так всё таки 'как начать моделировать бизнес-процессы в BPMN?
Наш рецепт:
Познакомиться с алфавитом нотации
Познакомиться с примерами диаграмм
Изучить рекомендации и алгоритм
Выбрать инструмент
Применить рекомендации и алгоритм
Все части в статье есть.
Краткое описание bpmn уже здесь на хабре 1000 и один раз всевозможные авторы описывали. Все статьи точь-в-точь совпадают между собой. И в вашей ну ни грамма нет ничего нового или другого.
Мы посмотрели другие статьи. Мы не нашли ни одной статьи, где было собрано всё необходимое — и развернутое описание алфавита и примеры и правила-алгоритм и рекомендации инструментов. Всё это разбросано по отдельным статьям. Нам хотелось сделать единую точку входа в тему.
> А Вы хоть раз какой-нибудь сложный процесс таким способом моделировали, и так, чтобы это не для галочки было, а именно работающий процесс?
Да, автор давно занимается работой в области бизнес-анализа и моделирования бизнес-процессов с применением разных нотаций. Вот тут можно почитать другие 15 статей автора на тему BPMN.
И да, мы решили, что для новичков надо начать с того, с чего начали мы.
Вы даёте не правильный подход. Из одной из ваших статей из вашего линка
Поэтому, перед тем, как представлять конечному потребителю описание проанализированного вами бизнес-процесса, задайте сами себе простой вопрос и дайте на него честный ответ: собеседник поймет вашу схему? Если потребитель информации, представленной аналитиком, не понимает ее, это – проблема аналитика.
Это вредные советы. Которые приводят к примитивному подходу описания процессов, которые с реальными процессами не будут иметь ничего общего. Поэтому я Вас и спрсил - Вы писали эти диаграммы для фирм и для проектов? Вы поддерживали реальные процессы с описаниями какое-то количество лет? Обучением теории не в счёт. Тем более оторванное от практики.
Музыкальные ноты не должны быть понятны любому человеку, никогда не изучающих музыку. Также и электрические схемы останутся для многих непонятными, которые не знают, что такое транзистор, резистор, конденсатор итд. Так-же и языки программирования и диаграммы bpmn. Если они кому непонятны, но есть правильные - это не недостаток диаграмм, а незнания этой нотации.
Мы это много лет подряд проходили c UML, SysML, OCL и т.д. Если язык имеет замороченную нотацию, его не понимают и не применяют.
Так что мы стоим на позиции, что те диаграммы, которые предназначены для людей, должны быть понятны людям.
Диаграммы деятельности компании — это не rocket science, не электрические схемы, и даже не музыка.
Идея, что каждый сотрудник компании, задействованный в автоматизации пойдёт и освоит курс по IDEF0, ARIS eEPС, UML, Archimate – не опрадавалась.
Посмотрите например на Event Storming — он ещё дальше идёт в смысле простоты освоения, показывает, что для бизнеса критически важно, чтобы люди могли здесь и сейчас описывать бизнес-деятельность, а не изучать языки.
Так что мы стоим на позиции, что те диаграммы, которые предназначены для людей, должны быть понятны людям.
Извините, но высказывание в корне не верно. Да, иногда неосведомленным людям о bpmn надо на доске набросать общие черты какого-нибудь сложного процесса. Но bpmn диаграммы создаются не просто людям и не для любых людей, а именно для тех, кто это может прочитать и с этим может работать. Для этого надо быть в курсе. Я постоянно сталкиваюсь с такими описаниями процессов, которые созданы простыми людьми. С добрыми пожеланиями. Но эти процессы не будут работать. Потому что многое в описание невалидно. Да, используя разный уровень абстракции, можно создать и упрощенную карту процессов, для менеджмента, который только пару квадратиков и пары стрелочек между ними увидит и вроде даже поймёт, как работает процесс. Но с перспективы птиц. Не зная многих деталей. Поэтому и говорю вам - вы неправильно определяете группу людей, которая с этим должна работать. А отсюда и желание, использовать как можно меньше компонентов из списка возможных.
Диаграммы деятельности компании — это не rocket science, не электрические схемы, и даже не музыка.
этоо вообще какой-то нонсенс. Bpmn - это не диаграммы деятельности компании, а способ описания процессов. И они бывают разные. Технические, специализированные, только внутренние, как например 'запрос для прав на какие-либо данные', так и внешние, где клиенты участвуют. И каждый из этих процессов может быть простым, а может быть и очень сложным. И без domain знаний и без знания bpmn невозможно будет разобраться. И это будет проблема не диаграмм, а тех, кто это не может читать без необходимых знаний.
"Я постоянно сталкиваюсь с такими описаниями процессов, которые созданы простыми людьми"
Мы нигде не писали, что диаграммы должны быть созданы «простыми людьми», речь шла про читателей, а не авторов.
Работа аналитика сделать запутанное и сложное понятным и простым, и эта работа отнюдь не простая и не для всех.
Работа аналитика сделать запутанное и сложное понятным и простым.
Сделать что-то простым - желание неплохое. Но мой вопрос и касался того, что процессы в фирмах как-вы не хотели - сложные. И обрисовать их в общих чертах - дело не сложное. Но очень часто - пустая трата времени. Потому что на это тратится время, но с этим никто работать не будет. Потому что настоящий процесс будет отличаться от картинки для 'всех'. И этот опыт приходит, когда с этим сталкиваешся на практике при работе на фирмах, в проектах итд. В теории-же это так классно - нарисовать в общих чертах что-то, что поймёт любой дурак. Поэтому желаю вам выйти из-за стола и поинтересоваться, а что из теории на самом деле работает или не работает? Это помогает, и потом опыт, которым захочется поделиться будет не оторваным от реальности. Потому что она - хотим мы или нет - комплексная. Но это просто совет. Вам решать - следовать ему или нет.
"А отсюда и желание, использовать как можно меньше компонентов из списка возможных."
Так расскажите о своём опыте. Почему от вас нет ни одной не то что статьи, а даже заметки?
Короче не очень хорошее впечатление от Вашей статьи.
Судя по вашим комментариям к другим статьям вида «Обожаю эту ноитациюя», вы давно знакомы c нотацией.
В таком случае полезно читать про неё книги, смотреть выступления международных авторов.
Наша статья для тех, кто не знаком с нотацией и раньше никогда в ней не моделировал.
Если у вас есть конкретные предложения, чего добавить — пишите.
А то сейчас похоже на old man yells at a cloud.
Наша статья для тех, кто не знаком с нотацией и раньше никогда в ней не момоделировал.н
Но эта статья точь в точь с сотнями других, которые уже только тут на хабре есть. Почему я должен вам говорить, что вам делать? У вас что вашей головы на плечах нет. Вы не хотите что-то другое написать, не то, что уже n-ое количество раз существует?
Обожаю эту ноитациюя
Вам больше нечего сказать, как указать на грамматическую ошибку, которая при скором вводе на мобильнике выскочила?
«Почему я должен вам говорить, что вам делать?»
Ну вы же говорите, какие нам статьи писать, а какие не писать.
Это не про голову на плечах, а про конструктивную критику. Если вам есть что добавить — добавляйте. Но сейчас нет конструктивной критики, есть огульное беспредметное хаяние.
Пл совместительству с работой в бизнесе, преподаю в частном университете. Если у меня студент со своей дипломной работой не проходит тест на плагиат, или жаже на 90 -ти страницах не раскрывает тему работы, то получает ту оценку, которую заслужил. Ок, в вашем случае - это полностью личная инициатива и вы имеете полное право писать статью, которая мало чем отличается от сотни других, которые тоже доступны. Похожее делают и агильные евангелисты.. Желаю Вам большего требования к себе.
Вы оцениваете мои слова как огульное беспредметное хаяние. Что-же, тоже Ваше право. Я так не считаю, потому что уже во многих строках, написанных уже только здесь - даю понять, на что стоит обратить внимание. Но отторжение любой критики Вас не делает лучше, а Ваш тон мне неприятен.
Почему я не пишу статьи здесь - на то есть причины. Но делиться кои-каким опытом , даже посредством комментариев - тоже считаю конструктивным.
По-возможности не буду Вам ничего больше говорить.
«Вам больше нечего сказать, как указать на грамматическую ошибку, которая при скором вводе на мобильнике выскочила?»
Это не про грамматическую ошибку, а про ваш опыт.
Про грамматическую ошибку, если уж на то пошло — у вас в профиле написано «электронника», не «электронщик» и не «электроника» — это тоже мобильник на ходу? Если у вас постоянный тремор конечностей, может заняться здоровьем и своей жизнью, а не анонимные комменты в интернетах строчить?
Спасибо за статью. Грамотный русский (в отличие от), термины, много примеров, особенно с событиями. Некоторые рисовалки не знал.
Да хорошая статья. И то, что она с примерами, ее выгодно отличает от других.
Я привык, что ИЛИ это бинарный оператор: два значения на входе, одно на выходе. Это легко обобщается до любого другого количества значений на входе больше двух, но на выходе все равно - одно.
В примере "Процесс утреннего пробуждения" ромбик справа вполне соответствует привычному определению.
Но у ромбика слева один вход и два выхода, а обозначение точно такое же. Тут нет ошибки, может здесь нужно использовать другой стмвол? Буду признателен за пруф, желательно ссылкой на описание в спецификации BPMN.
Несколько я понимаю, сам по себе оператор BPMN не является логической функцией. Вместо этого, логическая функция "связывает" его входы либо выходы, управляя возможностью токенов проходить по ним.
Так, в случае оператора "ИЛИ" с двумя выходами это самое "ИЛИ" означает, что токен может выйти через первый выход ИЛИ через второй выход.
Интересно было ознакомиться со статьей. Хорошо что есть общее описание элементов и верхнеуровневая схема сбора пр.
Чего не хватило:
Отличие от других языков описания процессов UML, IDEF0. В каких случаях лучше использовать BPMN? А в каких лучше воздержаться?
ФразаКогда нужно детально и наглядно показать последовательность и логику взаимосвязи действий, событий, исполнителей и объектов бизнес-процесса
описывает сценарий но не сравнение
Статья говорит о начале моделирования. При этом на выходе хорошо бы получить модель, которую можно применять. А для этого надо на старте понять сколько это может занять времени. Было бы здорово описать верхнеуровнево/ссылочно оценки трудоемкости описания процесса в этой локации. Насколько долго его описывать (возможно от каких то параметров)?
Ну и про завершение. Как понять, что описан именно нужный процесс с учетом того, что реальные бизнес-пользователи с которых снималась модель могут не знать нотификацию?
В примере для приготовления пищи ребенку мама почему-то не моет руки при приготовлении. Есть разные уровни абстракции? На каком лучше останавливаться?
Отличие от других языков описания процессов UML, IDEF0. В каких случаях лучше использовать BPMN? А в каких лучше воздержаться?
BPMN уже доминирует в вакансиях для аналитиков, поэтому у них зачастую не стоит выбора, надо нотацию знать и применять. Вы можете сравнить варианты описаний в статье и сделать для себя выводы о применимости.
Общее правило такое — применяем ту нотацию, с которой умеют работать читатели диаграмм.
В целом IDEF0 удобно применять, если использовать среду моделирования, которая поддерживает контроль ссылочной согласованности, например, ту же Business Studio.
Многим заказчикам наиболее нагляден и понятен красочный формат описаний ARIS eEPC.
UML Activity можно считать частным случаем Flow Chart и по наглядности он уступает ARIS eEPC, его можно применять для описания не столько процессов, сколько процедур, если её читатели — ИТ-команда и ей подходит UML Activity.
BPMN фактически является более строгой разновидностью Swimlane и Flowchart и победил благодаря своей опоре на такие традиционные для бизнеса форматы, а также хорошей связке с автоматизацией через BPMS и BPEL.
Было бы здорово описать верхнеуровнево/ссылочно оценки трудоемкости описания процесса в этой локации.
Давайте так:
Если описать процесс текстом (регламентом, процедурой, юскейсом) у вас займёт X времени, то
Описать этот же процесс диаграммой у вас в общем случае займёт 2 X времени, пока вы не наработаете библиотеку типовых фрагментов и не набьёте руку.
Как понять, что описан именно нужный процесс с учетом того, что реальные бизнес-пользователи с которых снималась модель могут не знать нотификацию?
Тут же дело не в нотации, а в полноте отображения действий и событий.
Контроль соответствия модели реальности обычно делается с помощью ревью диаграммы и типовых вопросов к рецензентам, для модели AS IS:
Все ли виды известные вам для этого процесса действия показаны? Каких на ваш взгляд не хватает? Что лишнее? Что непонятно и запутано?
Все ли виды известные вам для этого процесса события показаны? Каких на ваш взгляд не хватает? Что лишнее? Что непонятно и запутано?
И т.д.
В примере для приготовления пищи ребенку мама почему-то не моет руки при приготовлении. Есть разные уровни абстракции? На каком лучше останавливаться?
Не факт, что мама не моет руки) Мама, как автор диаграммы, некоторые действия выполняет автоматически, они проходят вне сознания, поэтому из него вытесняются :)
В бизнесе помогает то, что мы имеем N рецензентов.
Ну и да, некоторые детали могут отображаться на отдельных диаграммах, как в примере с «пойти в кафе».
Разделение одной диаграммы на несколько сейчас представляет собой в большей степени ремесло и искусство, чем технологичную практику. В основном авторы руководствуются 2-мя принципами:
Какие именно события и действия в большей степени влияют на суть и результат процесса?
Правило кошелька Миллера.
В моем понимании, формализация бизнес-процессов жизненно важно для любой деятельности, требующей предсказуемого результата. Заниматься формализацией должен руководитель (менеджер), т.к. это его основная функция (управлять процессом, а не людьми). Кроме того, исполнитель всегда охотней выполняет действия, смысл которых ему понятен. Т.е. все участники процесса должны (как минимум) легко читать такие диаграммы (понимать как именно процесс работает). Сама по себе идея нотации BPMN конечно замечательная, но как правильно указано в статье, чрезвычайно избыточная. Даже краткий справочник по разновидностям обозначений (все на одном листе) повергает при первом ознакомлении в шок, а уж полное описание в несколько сот страниц и вовсе отбивает желание данную нотацию использовать на практике.
Нотация BPMN (Business Process Modeling Notation) нужна для...
BPMN = Business Process Model AND Notation
Для этого используются специализированные системы BPMS (Business Process Modelling System), поддерживающие эту нотацию...
А здесь вроде должно быть Management, а не Modeling?
Автору от меня мега-благодарность! Вопрос: ссылки на приложение "А" нет в статье или я пропустила?
--
До недавнего времени успешно обходилась текстами, таблицами и mindmap'ами, но тут прилетела задача такого уровня, что не хватало ничего - либо описание на много букв, либо было не наглядно, либо не оказалось нужных отношений (в MindMap).
И тут внезапно попалась такая статья, плюс оказалось, что движок wiki поддерживает draw.io, и там есть все нужные хотя бы на первое время элементы. Хотя бы не придётся думать письменно в одном месте, а публиковать в другом. "Я понял, это намёк".
Других статей не видела ещё, буду учиться и пробовать с нуля.
пропустили, в секции «События» https://drive.google.com/file/d/1VT2L07nFZcsmuSYpT_wYqUZid58Tb9Yi/view
У меня маленький опыт использования этой нотации. Считаю полезным данную расскладку, особенно расширение подачи информации через Приложения.
Как начать моделировать бизнес-процессы в BPMN