alex55555,

Тухло все, если с "классическими" BPM (логику пишут/переносят с текстового BRD документа разработчики) всё условно хорошо - прекрасно решает задачи, где высокая доля "бизнеса" и нужен контроль со стороны "бизнеса" (Пример: IBM BPM - кредитный конвейер в банках), то с N все не очень, продуктов мало которые реализуют весь цикл именно это и есть BPMN (типа Bizagi), качество их посредственное , поддержка стандарта ~ в лучшем случае 15% + сам стандарт, включает "миллион" ненужных "артефактов" в стиле OMG головного мозга (мало им UML activity).

Кое, как подходят для решения задач с Human Task's (там, где без человека нельзя) - контроль работы "промоутеров", HR - служба, согласование чего-либо.

Но здесь большая конкуренция. Пример: согласование допустим можно и в jira при наличии плагина делать, и многим это удобнее (в jira тоже есть возможность строить процессы), там же, где и задачи, планы, сроки. Да у jira есть API и теоретически можно написать интеграцию BPMN-JIRA - на процесс согласования - но будет ли это удобно? задачи в одном месте согласование в другом.

Это я веду к тому, что сам BPMN никому не нужен это только "клей"(а тут мы встретим проблемы с производительностью мы же любим сервисы) для кубиков реализация, которых должная быть где-то еще, соответственно средство должно интегрироваться со всем чем можно (это ни разу не тривиальная задача, поддерживать это то еще адаще) и этим средства типа 1c часто выигрывают, т.к. тут все в одном процесс + реализация = монолит :), + часто они, позволяют строить процессы:


Проще купить готовое решение поддерживающие кастомизацию/допилку (customize).
Это уже позволяет уйти от "ВАЗ классика" к возможности модернизации (см. картинку).

К примеру "конфу" 1С, дополнительно дописать/поправить на её DSL(VB) недостающий функционал, на основе обычной BRD-->FSD документации ТЗ/и периодически поддерживать её в актуальном состоянии - чтобы она не разъезжалась с действительностью.
Да - бизнес процесс для бизнеса будет исключительно на бумаге(допустим текст + обычная блок-схема из квадратиков и в лучшем случае прямоугольников), да любое изменение ТЗ/разработка/тестирование, но в этом не ничего особенного, с BPMN в большинстве случаев будет аналогично (см. картинку).

Автомобили Porsche Cayenne и Volkswagen Touareg построены на общей платформе. В 2005 году Audi AG создала свой внедорожник Audi Q7 на той же платформе, убрав из неё все «спортивные примочки».

Чтобы успешно использовать BPMN - нужно, чтобы бизнес был в "теме", это очень сложно, в большинстве случаев бизнесу это не нужно, он хочет сказать "текстом" "Вася" СРОЧНО! выпустить карту "Еда в кредит" и интегрироваться с поставщиком "ХимПромСнаб№1" это нам принесет $$$$$$$ бабла из которых если в срок будет премия 0.00000001%, BA - проанализировал создал BRD, SA/ARCH - проанализировал создали FSD, разработчик накодил, тестеровщик протестировал, отравили в прод.

В случае с BPMN BA - должен при наличии всех необходимых кубиков сам всё сделать без SA/ARCH/Prog и отправить в тест, если кубика нет или его необходимо изменить, то цепочка B/BA/SA/ARCH/PROG/TEST сохраняется.

Вообщем BPMN это, как CD-Changer нужен ли он Вам? или предпочтете обычную магнитолу?

Petro123,

Практика вот тут:


link
https://www.nasdaq.com/symbol/pega/stock-chart

Кратко - конкурентов море, поляна давно освоена (для тех, кто не хочет тратить время на чтение множества букв).

Кроме, как для micro-бизнеса удачных внедрений BPMN(не классических BPM) не видел. Да и там это использовалось на "старте", пока выпиливается процесс в "гараже" в качестве прототипа, который может меняться несколько раз в день. Но опять же в этих проектах роли разделялись примерно так:
- Бизнес - он же BA, он же stockholder + еще пяток направлений - хранитель бабла, генератор бизнес идей --> в том числе рисует и отимизирует процессы (сам, лично). Не занимается проектированием модели/схемой данных, натягиванием интерфейса на БД или наоборот, поднятием серверов, exceptions.
- Разработчики же они архитекторы, системные-бизнес аналитики, техподдержка, тестировщики :) один из них с уклоном сисадмина, один с уклоном на БД, другой UI/UX, можно сказать "DevOps". --> В стиле 1C можно назвать их "конфигурастами" со знанием языков программирования --> тоесть они кодят конфигурацию БП. Т.к. БД он не в вакууме, то идет разработка, выбор соответствующих "сервисов", которые реализуют логику кубиков.
Как только они подросли BPMN был заменен у всех, ибо сложно тянуть всё в одиночку, да и стоит он хороших денег, тормозит хорошо, поддержка часто никакая - опять же успешный БП это 50% бизнеса- никто его просто так не отдаст - "скушал слона - жуй не спеша", а развитие заказной разработки БП на продажу не идет, т.к. её легко своровать, с конфигурациями это сделать посложней.
Имея рабочий БП - не составит труда на его основе реализовать ПО на "любом" языке и оформить в качестве CRM или даже ERP :).
До BPMN у них был Excel/SqLite + сценарии - они его и сейчас активно используют в работе.

Для понимания уровня работы в Bizagi (взят как пример, с activity/jbpm ещё в разы веселей, но там хоть код открыт).
Если Вы считаете, что спроектировать модель данных так просто, то флаг Вам в руки и барабан на шею, особенно когда пойдут задачки "болтик N входит в состав детали B;C;D; x - раз"
http://www.sql.ru/forum/840570-2/voprosy-po-bizagi
http://www.sql.ru/forum/1248265/baza-dannyh?hl=bizagi
http://www.sql.ru/forum/840570-6/voprosy-po-bizagi?hl=bizagi

Из этого следует, что разработчикам проще писать КОД по ТЗ/или таске на своих языках не вникая в бизнес, за интерфейс отвечает UI/UX+front разработчик+маркетол ... etc.

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

Что нужно бизнесу, так это возможность в приемлемые сроки изменения БП - тут рулят классические/не стандартные вариации BPM часто входящие в состав CRM/ERP..etc, для каждой предметной области со своими плюшками.

Для документооборота лучше использовать соответствующие системы, но в принципе и BPMN тут сгодиться --> кратко задачи human task.

Море таких задач - в страховании, продажах ... это в принципе большой рынок, но умеющий считать деньги. На "старте" там вовсю властвует Тетрадка/Excel/Access/Google Sheets... порог входа у которых гораздо ниже, документации, примеров море - в том числе на "могучем", реально можно самим без программистов, а БП можно и на доске нарисовать или раздать каждому сотруднику в качестве наборов сценариев.

Если задачи связанные с human task не основа вашего бизнеса, то Вам понадобится от вашего BPMN возможность полной интеграции(SOAP/REST..etc), чтобы её можно было встроить в соответствующую ERP/CRM, а не прыгать по программам - но зачем нам тогда пользовательский интерфейс? тут достаточно движка BPM с SOAP/REST интерфейсом и интерфейса для владельца БП. Тут приходит к продуктам IBM, даже шина, брокер от IBM позволяет кодить! быструю бизнес логику над системами(копозитные сервисы) и даже отчасти её визуализировать, на сколько это хорошо или плохо не мне решать, дополнительно у IBM есть рабочий BPM для страждущих.
Да и вообще если направлений бизнеса не много вероятно есть "основная" система/мы - так почему бы в неё не встроить этот движок в целях сохранения производительности и ресурсов? - да будет монолит.

И эта третья нога нужна только для одного, чтобы БП были прозрачными для бизнеса, чтобы "новый" BA/SA мог въехать быстро в процессы, и начать заваливать разрабов BRD, а не ждать пока SA/LID потратят море человеко-часов, разроют тонны протухшей документации попутно ковыряя в отладчике "гениальное" говно мамонта написанное толпой monkey coder_ов из интегратора "подешевле", восстанавливая/reverse engineering_гом БП ("ах оно ещё туда ходит и туда, а зачем у нас уже и этой системы нет...").

Наблюдал много историй, когда "все плохо" и ищут "волшебника на голубом вертолёте, который всех спасет" - и вот он BPMN(именно так его продают) - не прокатит.

И да, процесс "Бардака" при помощи BPMN спроектировать не получится, упретесь в ограничения нотации/средства проектирования или будете делать ad-hoc на ad-hoc ... и в конце концов вы его увидите, ужаснетесь и уберете BPMN с глаз долой.

Итог: на мой взгляд ниша BPMN (не BPM) - реализация бизнес процессов в которых обязательны требования к "human tasks" и выпилить их нельзя.

Много или мало таких? как по мне море, но и конкурентов океан.