BPM это хорошо, но считается, что BPM картинки нарисует консультант/ анал итик и все само заработает..... а на деле, что бы это хоть как-то запустилось, нужна куча жуткого XML, XSLT, огромная кучка if'ов и заглушек, т.ч. не только анал итик, но и не всякий программист разберется

В результате, иногда совсем не понятно, толи BPM жизнь упрошает, толи безумно усложняет. А если второе - то нафига он (в данном конкретном случае) нужен.

IMHO & AFAIK

Когда я начинал работать программистом (1991-1993) считалось, что
"бардак компьюторизировать не возможно" ( С ) - это аксиома

есть подозрения, что всякие BPM и прочие "рисовалки" придуманы именно для компьюторизации бардака, т.е. изначально (см. аксиома) ошибочная и не работающая идея.

Типа если бардак разрисовать в Power Point или в BPM, то бардак исчезнет и все само собой заработает... оно конечно в чем-то логично... нарисованный и документированный бардак чуть-чуть менее бардачный... но все равно, само собой не работает, красивые бумажки складываются в папки, а как бардак был, так он и остается.

Если же бардака нет, то и без BPM или "оркестровки" все делается в 10-ок строк кода.

IMHO & AFAIK

p.s. может конечно это мне с проектами не везло

Обычно пользователю нафиг не сдалась "голая" реализация тасков. Ему нормальная бизнес система (типа 1C) нужна. Ввел данные, нажал на кнопку, получил 100500 отчетов.

BPM и таски это конечно хорошо, но в реальной системе, это 1-5 % функционала.

Например OeBS и модуль закупки. Там есть workflow, процесс утверждения заказа на закупку - красивый, правильный и хороший. Но собственно процесс утверждения начальством, это максимум 5% от всего требуемого функционала.

А все остальное: оформление документов, расчет цен, прием на склад, возврат брака поставшику, планирование (min/max, just in time), ABC анализ и пр. и пр.... BPM вот вообще даром не нужен.

Видел OeBS. Из всех модулей (продажи, склад, открузка, закупки, финансы, кадры, зарплата)... единственный где более-менее осмысленно были нужны workflow - закупка и передача заказов из продаж в закупки. AFAIK Да и то потому, что процессы утверждение и оргструктура физически делалась на workflow. Но их __рисовать__ никогда не требовалось. Все настраивалось через таблички орг. структуры.

Единственный раз когда запускал Oracle Workflow Builder это был.. бл#$%... расчет себестоимости товаров на Workflow... пока модифицировал такую "алтернативно одаренную идею" я все проклял, при том, что нужны были совершенно минимальные правки.

IMHO & AFAIK

а у пользователя на экране что ?

В BPL считается, что этот наскальный рисунок сделанный анал итиком еще можно и запустить и он будет работать.

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

Соответственно, программистам это радости не добавляет ))) Т.к. весь функционал этого рисунка, можно было бы описать в 10-15 строках простейшего и элементарнейшего кода, без всякого вреда для печени

IMHO

И в каком банке такое чудо ?
Что пользователь может увидеть СВОЮ заявку и реальный внутренний процесс утверждения в банке.

В ВТБ, утверждение заявки со стороны клиента/операционистки - заполнили заявку... нажали на кнопку... подождите пожалйста... ой, извините, но Вам ее не одобрили

Переодически помогаю допиливать Горячую Линию на OeBS. Заявка, статус заявки, подразделение которое в данный момент ее выполняет (или порожденная заявка, если сразу несколько подразделений) и т.д. Никакие картинки даром не нужны. (часть системы сделана на Oracle Script - где GUI можно мышкой рисовать ))) но опять таки, от этого Oracle Script больше проблем, чем удобств, а вот Oracle Workflow вообще не используется)

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

да хоть сотрудник
нафига ему эта картинка?

ему нужно заявку сплавить/перевести в другое подразделение
т.е. нужно какие заявки на нем сейчас, что он не сделал/не заполнил, почему она не переводится

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

на той недели девушка умерла, ну позвонил я в 911, с вопросом: врач был / мент был, пять часов прошло, когда "спецтехника" наконец приедет?.... посмотрели статус заявки: мы свою часть отработали, спецтехникой занимаются менты, звоните им.

В общем, это и без картинок в BPM понятно ))). 3-и организации: диспетчер, врачи, менты. Заявку принял, переслал по инстанциям, все.

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

На BPM картинке нарисовать конечно можно: смотрите какая сложная и крутая система получается.

Но в реальной жизни, __конкретному__ сотруднику, вся эта вселенская сложность даром не нужна. Диспетчеру нужно дозвониться до врачей/ментов и он свою работу сделал. Ментам нужно забрать тело и передать бумажку в прокуратуру. Бухому дяди Коли выкопать яму. Все остальные сложности - им даром на их рабочем месте не сдались.

Ну и BPM-аналитика: сколько в СПб одновременно копается ям - оно конечно интересно, но в большинстве случаев бессмысленно.

Не верю ( C )
по крайне мере на уровне картинок, без изменения кода прикладных систем


Видел эксплуатацию Document'ума.

Там народ регулярно DELETE'ами в базе (или не в базе, х.з. что там у Document'ума) прибивал непонятно какие процессы, которые висели в уже не существующих состояниях и никогда не могли завершится.

а что делают, когда все же "застряло" ?
В Document'уме тупо прибивали


а как же постулат "отдел эксплуатации сам" ?
при программере и без BPM проблем нет )))

Если он программист BPM, то ясен пень, базовые нотации и что они делают знать должен (и даже больше аналитика)

Другое дело, что считается, что нарисованного BPM достаточно, что бы начать что-то выполнять... Существуют даже целые проекты внедрения BPM, при этом BPM only . Но пользователю, нужен не BPM, а абстрактно 1C. И когда конечный пользователь, который ямы копает, видит нечто выданное в результате такого проекта BPM only - он может только покрутить пальцем у виска.

Наверное, если организация очень крупная, то там найдется место и для 1C и для BI и для BPM. Только, проблема в том, что при наличие нормальной учетной системы и нормальных программистов, для реализации конечного автомата с 5-7 состояниями, нормальным программистам никакой BPM или BPEL движок не особо и нужен. IMHO & AFAIK

p.s.
Участвовал в одной проекте BPM. С картинками было все хорошо. С системой плохо )))

Как я понимаю, внедрения BPM в Сбере (где-то 7 летней давности. 2010-2015 гг) закончилось примерно так же. Денег распилино очень много (миллиарды, десятки миллиардов), на выходе - красивые картинки.
p.p.s.
Так с большинством рисовашек. Был проект, где в течении полугода анал итики в Oracle Data Integrator картинки рисовали и программистов мучали им View для DI делать. Когда после анал итиков передали программисту, он еще в течении полугода мучался, но под конец просто плюнул и стал весь ETL делать на Pl/SQL... все стало работать в десяток раз быстрее, и что поразительно кода в Oracle (view, package) также же стало __меньше__

Да ничего он не ослабил. Базу переливали (по возможности только новое), ночью.

Когда "ночной batch процесс" перестал справлятся за ночь, то начальство наконец разрешило похоронить DI )))

Просто программусту значительно удобнее/проще алгоритмы выборки на PL/SQL написать (insert..select...), чем маяться дурью и мышкой в DI линии из одного поля в другое перетягивать. Ну и структура исходной базы была достаточно сложной, ее достаточно сильно трансформировать было нужно (для BI) в процессе перегонки.