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

В 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 проблем нет )))