Let’s consider the credit card issuance process:
Fig. 1. Credit card issuance with a “passive” task “Issue card”.
Business scenario: after the card is manufactured, the client must come to the bank branch within 45 days and request it. Now look at the task “Issue card”: if the average client comes in for the card after 10 days and the branch issues 100 cards per day then 1000 of these tasks will queue into bank clerk’s task list.
What’s worse, the clerk cannot actively execute this task. The client must come to the branch and request the card first and it’s beyond clerk’s control. Generally speaking, this is bad practice - a user should be able to actively execute the task assigned to him.
In order to get rid of the passive task an event catcher should be added to the diagram, the event being client’s card request message:
Fig. 2. “Request” message is sent to unidentified process instance.
But here is the question: how would the message from client John Smith find its way into specific process instance associated with him? Let’s not forget that there are about thousand of instances behind the single pool “Credit card issuance” shown in the diagram.
There is no such routing problem with the message “Application” because the process start isn’t a part of a process instance, it’s rather a unique “process factory”.
But when a message is sent into the middle of a process (i.e. to the intermediate event) one must specify the process instance ID. Moreover, the process instance ID is the internal BPMS data so we can’t expect that a message from an external entity (from collapsed pool on a BPMN diagram) would contain it explicitly. In our case it’s just client’s words “hello, I want my card.”
So before sending a message to the card issuance process that will activate “Issue card” task we must ask client’s name and maybe also his date of birth and / or passport number and find a particular process instance matching these data.
This is done within a separate process “Credit card request”:
Fig. 3. “Credit card request” process is an example of “Incoming Processor” pattern.
How it may look in practice: a clerk enters client’s data into the form, the system scans the issued cards databases for the record matching client’s data, fetches the process instance ID from the record found and forward the message to this instance.
Note that a positive search result is not guaranteed: the client may come to our bank by mistake or more likely to come too soon. In both cases the “Credit card request” process ends without sending a message.
Summary: The message from an external entity in BPMN may only go to the start of a process. If the message should reach an intermediate event then it must go through an “Incoming Processor” that will identify the proper process instance and forward the message to this instance.
The diagram shown at fig. 2 can be considered valid only with the assumption that there is a process following “Incoming Processor” pattern behind the “Request” message arrow that we imply but not depict to avoid clutter.
Recruitment process and associated Resume processing, the Sale process and the associated Cash income processing - I meet the “Incoming Processor” pattern all the time in my practice.
In this post we have considered the case where the message destination (a specific instance of the Credit card issuance process, the Recruitment process or the Sale process) is unknown but at least the message type is clear (a card request, a candidate’s resume or an income statement, respectively). Next time we’ll consider a situation where neither one nor the other is known a prior.
Anatoly:
A very important improvement opportunity:
After the credit card is issued, send it directly to the customer. The customer activates the card using the security codes the bank provided to communicate with the bank channels (the are not the codes to operate with the card).
It eliminates one moment of truth, It eliminates the annoying of getting back to the bank .
Cheers,
Alberto Manuel
http://twitter.com/albertomanuel
Alberto
Thank you for the suggestion. It’s pretty obvious but it won’t always work. Enough to say that legislature differs from country to country so client’s signature may be necessary to confirm the card delivery. The case in question isn’t imaginatory. I’m sure the bank considered the opportunity you propose yet had serious reasons not to take it.
Anyway the post wasn’t about optimal bank practices but about a common process pattern.
Анатолий, великолепный пример на определение границы между BPMS и другими информационными системами банка. Давайте внесем в задачку еще пару подробностей из реальной банковской деятельности:
Во-первых, большинство банков являются многофилиальными и карту выдают в конкретном офисе. Это важное условие, так как наличие записи о выпущенной карте не всегда позволяет её получить. Клиент пришел в одно отделение, а карта находится в другом. Обычно, клиент указывает отделение банка, в котором хотел бы получить карту при её заказе, однако, он может и передумать. Я уж не говорю про «зарплатные» проекты, когда карты возят по офисам. Другой момент: хороший банк не будет ждать клиента 45 дней, а свяжется с ним намного раньше, чтоб напомнить о выпущенной карте. Т.е. БД карт начнет генерировать вспомогательные процессы.
В общем, в силу этих причин модель процесса станет сложной и 90% банков «закопают» реализацию этого процесса в информационную систему, в которой хранятся карты. А там программист реализует процесс так, как сочтет нужным. В лучшем случае, следы бизнес-процесса всплывут в системе банковской отчетности. Выход из такой ситуации состоит в построении БД карт, как сервиса, SOA сервиса, если угодно, реализующего некоторый жизненный цикл ресурса «банковская карта», но это уже хорошая программная архитектура
PS: «плохой» программист загонит «БД карты» во внутрь BPMS и вот оттуда информацию по карте уже точно никто не достанет.
Максим
Вы пугаете, а мне не страшно
Повторюсь: этот пример я взял не из головы, а из BPMN-тренинга в одном из банков. На практическом занятии они сами выбрали этот процесс и сами смоделировали as-is. Ну да, очевидно, этот банк относится не к 90, а к 10 процентам.
Конечно же, я не стал тащить сюда весь их процесс со всеми его извивами, так как цель была в другом - проиллюстрировать паттерн в кристально чистом виде. Но Ваша логика мне не ясна. Вы пишете, что истинная модель процесса будет сложнее, чем я ее изобразил. Разумеется. Но вывод я из этого делаю прямо противоположный. Вы считаете, что банк “закопает” сложный процесс в информационную систему, я же - что чем сложнее процесс, тем больше стимулов его “выкопать” и “развесить на солнышке” в BPMS. Собственно, именно этим занимается банк-прототип и другие банки, внедряющие у себя BPM.
Кстати, Ваша вводная о нескольких офисах изменения схемы процесса не меняет: клиент, пришедший не в то отделение - это с точки зрения схемы процесса то же самое, что клиент, пришедший слишком рано. Один экземпляр процесса “Обращение за выдачей карты” закончится неудачей, а следующий, когда он придет уже в правильное отделение,- успехом.
БД выпущенных карт скорее всего уже есть в какой-то из банковских систем, тут Вы правы. И по-хорошему, процессу надо добираться до этой информации тем или иным способом: веб-сервисом, через проприетарный API, репликацию данных или еще как. Ну да, можно назвать это архитектурой. И…?
Что касается плохого программиста, то это оружие массового поражения. Но согласитесь, наличие BPMS ограничивает распространение этого оружия
И почему это “оттуда информацию точно никто не достанет”? Оттуда достать информацию больше шансов, чем из корпоративной системы. Я представляю какие проблемы вы испытываете с автоматизированными системами без программных интерфейсов, но автоматически переносить эти страхи на BPMS не следует - BPM без интеграции с унаследованными системами не бывает, и в BPMS с программными интерфейсами дело обстоит намного лучше, чем скажем в ERP.
Мне кажется, Вам пора попробовать BPMS в деле. Иначе страхи будут накапливаться, пока не превратятся в фобию
Hello Anatoly:
I do not want to ruin your objective, but I found more interesting discussing how to improve the process, rather than figure it out how to design it in BPMN.
Going back to the regulation and the need of get a customers signature, the bank can send a letter with an delivery receipt. This complies with the regulation and turns the process more lean.
Cheers,
Alberto Manuel
http://twitter.com/albertomanuel
Alberto
You can’t imagine how awful the post service is in some countries
OK, one may improve this particular process but it’s impossible to eliminate every moment of truth in every process - this is why design is more interesting than process optimzation for me.
The story isn’t about communications between bank and its clients, it’s about generic process pattern. Most people don’t understand what a message flow reaching an intermediate event in the middle of a process diagram really means.
Thank you
Anatoly
У меня прагматичный подход. BPMS не хуже и не лучше любой другой информационной системы. Вот с интегрируемостью у BPMS пока, конечно, дела обстоят не очень хорошо. Вернее с интероперабельностью, т.е. способностью внести свой посильный вклад в информационную систему предприятия. Но я оптимист. Со временем у BPMS появятся стандартизированные программные интерфейсы для доступа к каталогу реализованных бизнес-процессов, структуре групп и ролей пользователей, запуску и управлению экземплярами процессов, нотификации о возникших в процессе событиях и т.д.
Вот тогда и наступит время пригласить их в дружную семью корпоративных бизнес-приложений
Максим
Поясните пожалуйста о какой BPMS Вы говорите и на каком основании делаете вывод о не очень хорошем положении дел.
По-моему, у Вас сложилось ложное представление. В тех BPMS, с которым работаем мы, программные интерфейсы в наличии. И, повторюсь, в этом типичная BPMS принципиально отличается от типичной корпоративной системы: для первой это обязательное требование (без интеграции нет BPM), для вторых программные интерфейсы, в понимании разработчиков, это возможность использовать их системы не так, как они (разработчики) задумали и - о ужас - обращаться к ним из “чужих” программных средств; inside-out - пожалуйста, outside-in - ни-ни.
О стандартизованности API различных вендоров правда говорить не приходится, но где они вообще есть, стандартные API? Есть ODBC/JDBC, но это относительно низкоуровневые интерфейсы, CRUD. На уровне приложений все проприетарно.
Я пытаюсь разобраться с Process API от Oracle BPM.
Стандартные API существуют, тот же WS HumanTask, но BPM, как направление в целом, движется в в сторону проприетарных интерфейсов
- Your first purchase will be for free if you pick up the card within 2 days
- Make the request of a credit card so expensive that people don’t want a card
- Just stop providing credit cards
- Accept that the process just works this way because of law.
And what is actually the problem? Too expensive, too slow, bad customer experience? If there isn’t any problem why bother modelling the process at all?
Regards,
Procesje
OMG did anyone care to figure out what the post was actually about?!
I assumed it was about improving a process (see twitter of Gary C) , but probably it is just about showing a process pattern in a BPMN model.
There is no business issue in this point hence no room for serious process improvement.
Anatoly, this thread is hilarious. In America we have a saying: Let no good deed go unpunished.
Bruce,
Maybe the most hilarious thing is people spending a lot of time on modelling a process in BPMN without the intention to improve it.
Or is that not what you mean
Procesje
Not Bruce but dare to answer
1) It’s purely a matter of professional skill: whether one know how to model process in BPMN or do not. Your recommendation regarding process optimisation should not depend on what you can model with BPMN and what you can not, right?
2) What shall go first: process optimisation or process control? I’m more inclined to the latter: start with as-is, more or less, gain the control over the process with a help of BPMS/BAM and then look for improvement/optimization opportunities.
3) What is process optimization, anyway? In old days I believed it’s tuning a process here and there. Now I know that re-evaluating process scope gives much, much more than “process knitting”.
Oh my, am I writing a new post here?
1)I agree, but my actual point is that I see a lot of companies spending a lot of time on modeling their processes ending up in a lot of process models that are never used for more than “being a model”. It is like drawing building plans with no intention to build or change a house. That is why I think it is better to spend your time on other process-things than modeling. Should I start the “Process Model Liberation Front”?
2) I agree that the final objective must be to control/manage an organization in a process oriented way (at least if you think bpm is a good idea) . And what do you need for that? Processes. Then see if these processes meet their goals. If they do, why bother improving them? If they don’t: analyse, find the problem and improve them.
What I see a lot is that companies have a lot of process models, but don’t know what their real processes are and didn’t think about the right measurements to really see process performance.
So yes, the goal is to manage, but I wouldn’t like to manage useless processes. What brings us to point 3.
3) I don’t like the word optimization. It indeed sounds like tweeking the process a little bit. In my opinion it is about really being aware of your processes and their contribution to your organization goals. And to let your processes be valuable, improvement can mean a lot of things:
- Skip a whole process
- Making control more strict in a process
- Don’t steer strict anymore, but train your people to do what is best for your customers
- Better informationmanagement
- Delete useless business rules
- …..
Conclusion: In my opinion a process model is only useful when you experienced bad process performance and you decided to improve that process. Stop modeling, start improving (would be on the flag of the PMLF
I think we agree on a lot of things. Good luck with your new post
Procesje
It’s a pleasure to have this discussion with you.
So your point is that a lot of people model processes but don’t go any further - nor to executable processes neither to process improvements. I agree.
Now what shall we do about it? Is there a better way to process control/management/improvement that doesn’t need modeling? ACM? Sure - for certain processes but not for all. Something else?
I meet theese people all the time at my trainings. But I won’t say that their modeling activities is totally fruitless. Does it pay for the efforts spent? Sometimes yes, sometimes no. Probably yes for those who respect Pareto’s law.
What I’m trying to do is enlightning them - showing the power of executable processes models. For many of them it’s unbelievable. Just too good to be true. But they do it with their own hands at the training so it’s hard to deny. Nobody says it doesn’t make sence. For most of them it’s not easy to change the paradigm and get beyond pure modeling. It’s in the organization culture after all. But I’m optimistic in belief that right ideas finally get the right people.
Anatoly,
Modelling is absolutely not fruitless if you do it with the right purpose: to build or change the house! So the onlything I do lately is, like you, helping organisations take the next step.
And sometimes automation (wfm/acm) is the next step and than it is very great that the process model can be brought “alive” by the modeller himself in tools like Bizagi. Lombardi, BPMone, Pega etc.
Then a model is not just a model anymore, but your guide for improvement.
Should I change the name into UAOPMF (Usefull application of process model front)
I’m in!
Добрый день!
Я пытаюсь разобраться с данной нотацией. Спасибо за Ваши материалы.
У меня мелкий вопрос по модели (рис.3): возможно, задачу “выдать карту” логичнее поместить в пул “Обращение за выдачей карты” (с переименованием названий пулов). Т.к. фактически это единая цепочка, где успешное завершение одной задачи инициирует выполнение другой
Aliya
Спасибо, хороший вопрос.
С точки зрения техники можно и так.
Но с точки зрения методологии тут есть минус: потеряется сквозной процесс “от заявления до выдачи карты”. Вы не сможете ответить на вопрос “сколько времени занимает исполнение процесса?”. А это один из главных показателей.
Это стандартная проблема “цепной” схемы, которую вы предлагаете, даже безотносительно к предметной области.
Тогда зачем выносить в отдельный пул задачу “Найти карту”? Не проще ли поместить ее перед задачей “Выдать карту” на модели, изображенной на рис. 2?
Спасибо
Боюсь, Вы не уловили самую суть: задача “Найти карту” ни при каких обстоятельствах не может быть частью процесса “Выдача банковской карты”.
С каким конкретно экземпляром процесса (их могут быть тысячи одновременно находящихся в работе) вы свяжете эту задачу, когда к кассиру пришел клиент?
Человек может прийти за картой до назначенной даты, человек может прийти за картой, не поняв, что ему отказали. Пусть это примеры экзотические, но они показывают, что человек может прийти, когда вообще нет “его” экземпляра процесса. То есть задача “Найти карту” - это другой процесс.
Первый рисунок со структурой процессов выдачи карты изначально некорректный - в реальности надо учитывать ВСЕ процессы, связанные с решением этой задачи. Например, перечень операций мог бы выглядеть так:
1. принять и проверить заявление на выдачу карты;
2. ввести данные в информационную систему банка;
3. проверить заявителя (скоринг, СБ и т.п.);
4. сформировать пакет заявлений;
5. рассмотреть пакет заявлений (выходами могут быть как положительные, так и отрицательные решения);
6. сформировать заказ (задание) на изготовление пакета карт (по одной никто делать не будет. Тем более, что не у каждого банка есть свое производство карт);
7. получить (физически) карты и проверить на соответствие заказу (+ возможно промежуточное хранение на складе банка);
8. переместить карты в территориальные отделения (ежедневная доставка одновременно с инкассацией);
9. хранить карты в территориальном отделении (не говоря уже о их инвентаризации);
10. при обращении клиента проверить у него документы и найти карту в пачке карт (либо найти ее в списке аннулированных по срокам карт);
11. оформить документы на выдачу карты (и учесть в базе данных банка);
12. выдать карту клиенту;
13. ежемесячно (еженедельно) отобрать карты с просроченным сроком действия;
14. оформить документы на утилизацию просроченных карт;
15. утилизировать карты (вернуть в центральный офис)…
Это отдельные операции, которые можно сгруппировать в процессы.
Так вот, процесс “выдачи карты” должен включать:
10. при обращении клиента проверить документы и найти карту в пачке карт (либо найти ее в списке аннулированных по срокам карт);
11. оформить документы на выдачу карты;
12. выдать карту клиенту.
На мой взгляд, некорректно показывать процесс “обращения” отдельно от процесса “выдачи” (они НЕРАЗРЫВНО связаны). Тем более сначала просто “забывать” про него. Потом вспоминать и создавать “часто встречающиеся” процессные паттерны.
Тезис Анатолия “…задача “Найти карту” ни при каких обстоятельствах не может быть частью процесса “Выдача банковской карты”, как видно из изложенного выше, - мягко говоря некорректный.
Проблема в том, что надо сначала понять структуру процессов системным образом, а потом уже заниматься моделированием на уровне Work Flow.
Далее. Тезис Анатолия: “…потеряется сквозной процесс “от заявления до выдачи карты”. Вы не сможете ответить на вопрос “сколько времени занимает исполнение процесса?”. Пардон, это надуманный “сквозной” процесс. Реально его нет, как видно из вышеизложеного. А время замерить проще простого: “Дата оформления заявления” - “Дата выдачи”!
Владимир
Во-первых, в отличие от любимых Вами процессных блок-схем, в BPMN есть такая крайне полезная вещь, как подпроцессы. Это позволяет структурировать сложные процессы, выделять уровни абстракции, не вдаваться в детали на диаграммах верхнего уровня.
Если бы я рисовал блок-схему, мне бы пришлось изобразить на ней 15 перечисленных Вами задач (а реально даже больше) и это сделало бы ее нечитаемой. А в BPMN я могу (и должен) на верхнем уровне изобразить подпроцесс “Рассмотреть заявление”, который включает в себя Ваши действия с 1 по 5.
Во-вторых, Вы очевидно не заметили, но заметка называется не “Схема бизнес-процесса выдачи банковской карты”, а “Процессный паттерн Обработка входящих”. Как я уже написал в одном из комментариев выше, “Конечно же, я не стал тащить сюда весь их процесс со всеми его извивами, так как цель была в другом - проиллюстрировать паттерн в кристально чистом виде.”
В третьих и главных, BPMN-диаграмма отличается от блок-схемы тем, что это “закон прямого действия”. Не примерная схема того, из чего состоит процесс, а строгая, непосредственно исполняемая вещь: что нарисовано, то и делаю, “What You Model Is What You Run”. Задача “Выдать карту” нормально бы смотрелась в рамках основного процесса, если бы это была блок-схема. А в BPMN мы получим задачу, которую исполнитель не имеет возможности исполнить! Не может кассир (предположим, что карту выдает он) исполнить задачу “Выдать карту”, так как для этого нужно чтобы перед ним стоял клиент, а кассир не имеет возможности привести клиента в офис банка. Это неправильно - людям надо ставить только такие задачи, которые они могут исполнить.
Второй аргумент, почему обращение должно быть реализовано отдельным пулом: вообще говоря, клиент может прийти до назначенного срока и попросить карту (люди, знаете ли, бывают разные). Что мы должны сделать в этом случае? А все то же самое: взять его паспорт и провести поиск среди готовых к выдаче карт. Если карта не готова - попросить его прийти попозже. Мы получим два экземпляра процесса обращения за выдачей карты на один основной процесс, и это правильно. Клиент может прийти и попросить карту даже в том случае, если мы ему отказали - ну не дошло до него наше извещение. Основной процесс уже завершился (отказом), а разобраться с клиентом, который стоит перед окошком и требует карту, надо. Предложенная схема нормально справляется и с этой ситуацией.
Мораль: идет ли речь о банковском процессе или о любом другом - действие, инициируемое внешней сущностью (в данном случае внешняя сущность - это клиент, а действие - его приход в банк и запрос изготовленной карты), должно моделироваться отдельным пулом. Этот вспомогательный процесс связан с основным через данные и через отправку сообщения, но технически это все же отдельный процесс.
Поскольку приходится все это разъяснять, очевидно с задачей “проиллюстрировать паттерн в кристально чистом виде” я не справился. Ну что ж, для того и блог, чтобы поделиться на нем своими мыслями, получить от читателей отклики и с их помощью отточить аргументацию. Например, сейчас я вижу, что крайне неудачно назвал пулы: название “Обращение за выдачей карты” больше подходит основному процессу.
Анатолий
мне кажется ,что с точки зрения бизнеса следующие действия представляют собой единый процесс, выполняемый локально 1-2 сотрудниками банка (нюансы лучше спросить у банкиров):
10. при обращении клиента проверить у него документы и найти карту в пачке карт (либо найти ее в списке аннулированных по срокам карт);
11. оформить документы на выдачу карты (и учесть в базе данных банка);
12. выдать карту клиенту.
Если идет обращение по еще не выпущенной карте, это частный случай п. 10 - скорее всего, операционист сначала смотрит в базе, выпущена ли карта, а только потом идет ее искать в пачке.
Пул, который у Вас назван “Выдача банковской карты” изначально некорректно упрощен, поэтому и пришлось показывать “Обращение за выдачей карты” отдельным пулом.
Что мешает сразу создать пул под названием: “Обслуживание клиента при обращении за выдачей банковской карты” и показать в нем все операции 10-12.
Заметьте, что я не призывал показывать все 15 операций на одной диаграмме. Наоборот, предлагаю сделать группу операционных процессов, взаимодействующих между собой. Предлагаемый мной операционный процесс “Обслуживание клиента при обращении за выдачей банковской карты” является только одним из процессов, входящих в систему.
Не понял, чем собственно BPMN диаграмма отличается принципиально от грамотно описанной схемы Work Flow в eEPC или любой другой нотации, содержащей события. Только тем, что ее “понимают” некоторые движки некоторых программ? Событиями EPC можно показать и приход сообщения, и таймер “45 дней” и т.п. Схема будет на 100% корректной с точки зрения описания “реально выполняемого процесса”. Просто она не сможет автоматически транслироваться в исполняемый код.
Что касается “блок-схемы” с ромбиками, то я их не использую
Если есть заинтересованные господа “банкиры”, предлагаю описать группу процессов, а потом декомпозировать их на операционный уровень.
Владимир, я сдаюсь. Очевидно, взгляд на бизнес-процесс как на многопоточную систему не для Вас.
За “господ банкиров” будьте спокойны - этот пример я взял из корпоративного тренинга в банке, и там никаких возражений эта модель не вызвала.
Привет, Анатолий!
Прекрасно понимаю, что происходит, когда несколько операционных процессов выполняются одновременно, при этом взаимодействуют друг с другом.
Примеры на тренингах, с которыми “соглашаются” представители компаний и “боевые” описания процессов - далеко не одно и то же!
“Что есть выдача карты”? - вот вопрос. Выдача карты без обработки обращения как процесс лишена всякого смысла….
Вот когда герой Ильфа и Петрова в порыве душевной доброты разбрасывал сушки из корзины - это процесс можно описать без “обращения за выдачей”
>>Поэтому прежде чем слать сообщение в процесс выдачи карты, которая активизирует задачу «Выдать карту», мы должны спросить у клиента его фамилию и имя, если понадобится – дату рождение и/или номер паспорта, и по ним найти относящийся к данному клиенту экземпляр процесса.
Это делает отдельный процесс «Обращение за выдачей карты»:
Хитрый ход! Чтобы сделать форму запрашивающую реквизиты клиента и отыскивающую нужный экземпляр первого процесса, нам пришлось создать вспомогательный процесс.
А как-нибудь еще можно реализовать такой функционал?
Дмитрий,
А чем не нравится мой вариант представления процесса “Обслуживание клиента при обращении за банковской картой”?
Если его рассматривать в целом, то никакой вспомогательный процесс будет не нужен.
Вообще, этот процесс у Анатолия нужен для бизнеса или чтобы “рассчитать” время сквозного процесса? Но рассчитать время сквозного процесса можно без таких сложностей…
Дмитрий
Спасибо что заглянули.
Дело не в том чтобы прицепить форму, дело в асинхронности этих действий относительно основного процесса и в том, что такие обращения соотносятся с основным процессом не как 1:1, а как М:1. А раз так, это отдельный пул, и не надо искать какие-то другие варианты.
Владимир
Время сквозного процесса упомянуто только в ответном комментарии к схеме, предложенной Aliya. К выбору схемы оно конечно же никакого отношения не имеет.
Aliya
Посмотрев еще раз на схему и подумав над Вашим предложением, я пожалуй склонен согласиться, что выдавать карту логичнее во вспомогательном процессе. Только один принципиальный момент: даже если мы переносим эту задачу во вспомогательный процесс, во основном процессе остается ожидание сообщения из вспомогательного о том, что карта выдана. Нужно это все с той же целью - чтобы не потерять сквозной процесс. Таймер и аннулирование карты в случае просрочки остаются в основном процессе.
Владимир,
мне твой вариант - всем нравится. Процесс Анатолия нужен для третьего - для обеспечения технической возможности поиска нужного экземпляра в BPMS (который нужно продолжить) когда клиент приходит за картой.
С т.з зрения рассчитать время процесса, оно (время) будет даже более некорректным в во втором варианте Анатолия, т.к., смею предположить, что в процессе “Выдача…” не учтется время на операцию Find car
Я бы все-таки сформулировал по-другому: это сделано для того, чтобы не назначать пользователю задачу, которую он физически не может выполнить.
Без паники, все учтется как надо во всех вариантах. Кроме варианта Aliya - один процесс заканчивает работу, другой продолжает. Вот с ним действительно возникает эта проблема.
Анатолий, приветствую!
да, я понял в чем дело.
Просто разбивать процесс в угоду технике, имхо, не слишком красиво (этим и вызваны вопросы Алии и Владимира). Поэтому и спросил, а есть ли другие варианты технически?
Я не согласен с тем, что это делается в угоду технике. Так правильнее, если докапываться до глубин. Причем это только один пример, а так это очень распространенный паттерн. Еще один пример навскидку: основной процесс - продажа, вспомогательный - обработка выписки банка. Там в точности такая же картина.
>>Без паники, все учтется как надо во всех вариантах.
не понимаю: экземпляр процесса “Выдача…” будет висеть незавершенным все время, пока не придет сообщение Request, потом мы пойдем дальше. В итоге да, получим полное время процесса “Выдача…” включая время простоя (пока клиент не шел за картой), но чистое операционное то время - нет. Как система поймет, что к операционному времени процесса “Выдача…” нужно будет добавить M операций “Find card”?
>>Так правильнее, если докапываться до глубин.
Не спорю, мне понравилось, красивое решение. Визуально запрограммировать параллельные процессы - это, без шуток, круто.
Я просто еще с своей колокольни смотрю (как обычно ;)): не технарям такое показывать на мой вгляд нереально -даже Алия разобралась после подсказки, а с ее слов она этим занимается.
Я имел в виду полное время. Операционное время вообще проблематично вычислить. Сколько задача оставалась активной - пожалуйста, а сколько реально пользователь на нее потратил - да кто ж его знает, система это определить не в силах. Так что в этом смысле разницы нет никакой между однопоточной и многопоточной схемами.
>> не технарям такое показывать на мой вгляд нереально
Завершающая часть моего тренинга по нотации называется “Межпроцессное взаимодействие”. Мы сначала пытаемся решить довольно банальную задачу приема на работу по конкурсу с несколькими резюме от нескольких соискателей в рамках одного процесса. И так пытаемся, и эдак… и все как-то не так получается. И тогда я демонстрирую решение с двумя взаимодействующими пулами. Реакция аудитории всякий раз одна и та же - нечто вроде катарсиса. Я у них спрашиваю: проще стало или сложнее? Стандартный ответ: дело не в этом, так ПРАВИЛЬНЕЕ.
Так что все в порядке, люди врубаются. Не сразу, некоторое время надо потратить чтобы начать мыслить многопоточно, но получается. Причем по моим наблюдениям это не зависит от того, технарь это или нет. Сложно перестроиться и тем, и другим, но суть ухватывает практически каждый.
Да, а что касается программирования в BPMN многопоточных задач, рекомендую http://mainthing.ru/ru/item/396/
>>Сколько задача оставалась активной - пожалуйста, а сколько реально пользователь на нее потратил - да кто ж его знает, система это определить не в силах.
В данном примере хотелось бы знать именно операционное для оптимизации процесса, ведь т.к. клиент может идти за картой произвольное время, глядя на полное время, нельзя сказать хорошее оно или плохое…
>> глядя на полное время, нельзя сказать хорошее оно или плохое…
Согласен. Но тут простой принцип: все, что есть на схеме процесса, можно легко замерить. Хочешь - от начала до конца (карта выдана), хочешь - от начала до промежуточного события (карта изготовлена). Т.е. укоротить отрезок, на котором замеряется время, всегда можно. А вот расширить отрезок, если на схеме процесс завершается не дойдя до своего логического конца, значительно труднее. Поэтому надо тянуть его по-максимуму - там разберемся какая метрика в итоге будет востребована. Вполне возможно что обе.
Ясно.
а такой вопрос: когда приходит клиент за картой, почему нельзя открыть список из 1000 повисших экземпляров процесса “Выдача…” и по одному из атрибутов (номер паспорта) не найти в таблице (глазами или через поиск) нужный экземпляр?
Можно, можно. Но не нужно.
Смысл списка назначенных задач в том, чтобы стимулировать работу исполнителя в стиле: появилась задача - выполни, и пусть процесс от тебя уйдет и перейдет к кому-то другому.
А тут получится - 1000 задач на 40 страницах веб-интерфейса, с которыми ничего сделать нельзя, и среди них разбросаны несколько (или несколько десятков) задач, пришедших из других процессов, которые таки надо брать и делать.
Не завидую я и тому кассиру, и тому, кто предложит ему работать в таком режиме.
И еще, повторяю: человек может прийти до того, как карточка готова. У кассира задачи нет, он возьмет паспорт, не найдет задачи, пожмет плечами и скажет “ничего не знаю”. В моей же схеме система ему даст четкий ответ: то ли от человека вообще не было заявления, то ли ему отказали, то ли он пришел слишком рано, то ли он пришел во-время, но мы не успели.
>>И еще, повторяю: человек может прийти до того, как карточка готова. У кассира задачи нет, он возьмет паспорт, не найдет задачи, пожмет плечами и скажет “ничего не знаю”. В моей же схеме система ему даст четкий ответ: то ли от человека вообще не было заявления, то ли ему отказали, то ли он пришел слишком рано, то ли он пришел во-время, но мы не успели.
да, верно.
а еще технический вопрос:
>>Поэтому прежде чем слать сообщение в процесс выдачи карты, которая активизирует задачу «Выдать карту», мы должны спросить у клиента его фамилию и имя, если понадобится – дату рождение и/или номер паспорта, и по ним найти относящийся к данному клиенту экземпляр процесса.
а что происходит дальше? как технически посылается сообщение Request в нужный экземпляр? это широковещательная рассылка сигнала, рассылка именно нужно экземпляру (который принимает его и в соответствии со схемой процесса активирует событие), или прямое указание событию экземпляра выполнится?
Дмитрий
Учите матчасть
Сообщение - это точка-точка, сигнал - это широковещательная коммуникация.
Соответственно, если сообщение направляется в середину процесса (в промежуточный обработчик события “сообщение”), как в данном случае, то необходимо указать Id конкретного экземпляра процесса, в который сообщение должно быть послано. Этот Id берется из базы данных карточек к выдаче - основной процесс записывает туда свой Id вместе с информацией об очередной карточке и о ее получателе.
Анатолий, ну собственно и учу с Вашей помощью
Привет, коллеги!
Цитирую Анатолия: “… В моей же схеме система ему даст четкий ответ: то ли от человека вообще не было заявления, то ли ему отказали, то ли он пришел слишком рано, то ли он пришел во-время, но мы не успели…”
Операционист возьмет паспорт клиента, введет ФИО в базу и получит полную информацию о статусе (готова, не готова, просрочена и т.п.). “Висящий” экземпляр “супер-мега сквозного” процесса ему, вообще говоря, не нужен. Нужно ли это начальнику отделения? Например, сколько карт было выдано каким сотрудником. Думаю, что тоже не нужно.
Далее, “тянуть” экземпляр “супер-мега сквозного” процесса от приемки заявления через все производственные и логистические этапы с практической точки зрения абсурдно. Именно абсурдность примера меня и смутила. Долго не мог понять практической целесообразности такой “многопоточности”. Сейчас пример Анатолия понял, но практического смысла в нем все равно не вижу.
Осмелюсь предположить, что такая “автоматизация” никому в банке не нужна. Часто Вы интересовались у банка, на каком этапе находится Ваша карта - на бумаге или уже в производстве?! Отслеживали этапы “прохождения” вашей карты через интернет-сайт банка? Нет?! Тогда зачем эти “супер-мега сквозные экземпляры процессов”?
Желательно приводить реальные примеры, решившие конкретные практически задачи клиента…. Космические крейсера в эту категорию тоже не попадают
>> Операционист возьмет паспорт клиента, введет ФИО в базу и получит полную информацию о статусе (готова, не готова, просрочена и т.п.).
Владимир, Вы сейчас агитируете за использование функционального приложения вместо процессного. Ну да, если у нас есть “супер-мега интегрированная банковская система”, то в ней по определению все можно сделать. Только монитор у пользователя такой супер-системы весь обклеен желтыми стикерами - куда идти и в каком меню и суб-суб-меню что делать.
Процессное же приложение работает в другой парадигме. В нем есть задания, которые приходят ко мне неизвестно откуда и уходят неизвестно куда, как только я их выполняю. И список процессов, которые я могу инициировать. И все. Стучится в окно человек, просит карточку - инициирую процесс “Клиент пришел за карточкой”.
>> Нужно ли это начальнику отделения? Например, сколько карт было выдано каким сотрудником. Думаю, что тоже не нужно.
И ошибаетесь. Например, в Сбере от этого зависит размер зарплаты операционистов - знаю от человека, эту самую зарплату получающего.
>> Далее, “тянуть” экземпляр “супер-мега сквозного” процесса от приемки заявления через все производственные и логистические этапы с практической точки зрения абсурдно.
Вообще-то продолжительность от обращения клиента до полного его удовлетворения - это ключевой показатель качества процесса. И вдруг “абсурдно с практической точки зрения”?! Я в шоке.
>> Часто Вы интересовались у банка, на каком этапе находится Ваша карта - на бумаге или уже в производстве?! Отслеживали этапы “прохождения” вашей карты через интернет-сайт банка?
Конкретно этим не интересовался. Но вот совсем недавно восстанавливал утраченную карточку, и возникли проблемы с определением того, в какой филиал мне за ней приходить. В итоге выяснил. Был бы чуть менее настырен - пришел бы не в тот филиал и получил бы проблемы весьма близкие к тем, которые мы обсуждаем. Так что есть над чем работать банкам, есть.
>> Желательно приводить реальные примеры, решившие конкретные практически задачи клиента
Для иллюстрации паттернов реальные примеры плохо подходят. Реальные кейсы всегда корявы, в них много всяких деталей, за которыми сложно увидеть чистые схемы.
Но этот конкретный пример взят не из головы, его моделировали банковские аналитики на моем тренинге. Ну да, не без моей подсказки. Но если Вы считаете, что к этим людям можно вот так запросто прийти с улицы и сказать “вы работаете не так - надо вот так” и они это проглотят, то что я могу сказать… хотелось бы мне быть настолько крутым
Реализовали ли они эту схему в системе BPMS? Нет, этот банк пока не имеет видов на исполняемые схемы процессов, их интересует сугубо моделирование процессов в BPMN для целей описания и регламентирования. Не проверял, но у меня нет сомнений, что они его зарегламентировали примерно в том виде, как тут показано.
Каюсь: по поводу зарплаты человека в Сбере, привязанной к числу выданных карточек, я приврал. У него зарплата зависит от числа рассмотренных обращений. Но в принципе это ведь почти одно и то же.
“…Вообще-то продолжительность от обращения клиента до полного его удовлетворения - это ключевой показатель качества процесса. И вдруг “абсурдно с практической точки зрения”?! Я в шоке…”
Показателей может быть много. Для их расчета и мониторинга внедрение BPMS - один из возможных вариантов, причем весьма недешевый.
Что касается функциональной автоматизации. В Вашем примере, Анатолий, для обеспечения работы сквозного процесса придется интегрировать множество различных систем. Так что решение технически может оказаться гораздо сложнее и дороже функционального. Бизнесу нужны эффективность, а не мода.
Далее. На рабочем месте операционисту совершенно не обязательно “пролистывать 10 скринов, чтобы получить информацию по карте”. Это приложение может быть оптимизирован под типовые, часто повторяющиеся задачи. Один клик - меню проверки статуса и выдачи карты.
>> BPMS - один из возможных вариантов, причем весьма недешевый
Вроде мы обсуждали логику процесса, а не цену софта?
>> Бизнесу нужны эффективность, а не мода.
Оставьте пожалуйста менторский тон.
>> приложение может быть оптимизирован под типовые, часто повторяющиеся задачи. Один клик - меню проверки статуса и выдачи карты.
Я большие корпоративные системы и разрабатывал, и внедрял. А Вы?
Привет, Анатолий!
ОК. Не буду учить Вас на “лыжах кататься” (это про “менторский” тон).
Не скрою, что большие корпоративные информационные системы не разрабатывал и не внедрял.
Но раз Вы разрабатывали, то, вероятно, можете дать какую-то прикидку по цене вопроса для сравнительного анализа. Но это, конечно, уже для отдельной статьи и обсуждения.
По данному примеру у меня вопросов больше нет.
С уважением,
Владимир Репин
Привет всем участникам!
Владимир,
твое предложение
> 10. при обращении клиента проверить у него документы и найти карту в пачке карт (либо найти ее в списке аннулированных по срокам карт);
> 11. оформить документы на выдачу карты (и учесть в базе данных банка);
> 12. выдать карту клиенту.
если я правильно тебя поняла, касается не принципа взаимодействия процессов, а детализации процесса выдачи карты (его части). Не вижу проблемы - шаг, названный Анатолием “Найти карту” может быть не одним шагом, а несколькими, в том числе и п.10 может быть выполнен там же.
Пункты 11 и 12 могут быть выполнены только в случае успешного поиска, поэтому их выполнение относится к части “Выдать карту”, которая тоже может быть детализирована, и содержать даже большее количество действий.
Предлагаю абстрагироваться от деталей и оставить два действия “Найти” и “Выдать”.
Если ты считаешь принципиальным, чтобы эти действия были в одном процессе, то это вариант, который предлагает Aliya - вынести шаг “Выдать карту” в процесс “Обращение за выдачей”. Тогда, как предлагает Анатолий, ожидание ответа, что карта выдана, оставить в процессе “Выдача банковской карты”.
А вот разделить эти процессы - это уже принципиальный вопрос. Тут действительно другой процесс. Анатолий назвал его “Выдача банковской карты”, но на самом деле этот процесс имеет более глубокий смысл. Это, по сути, процесс, отслеживающий состояние карты. Карта заказана, изготавливается, выдана, а дальше будет следовать еще один автомат: закончилась, утеряна и т.д. Я бы и рассмотрение заявления вынесла в другой процесс, т.к. на жизненном пути карты может быть заявление о ее утере, обмене и т.д.
Привет, Юля!
Спасибо за разъяснения. Стала более понятна мысль Анатолия.
Анатолий,
Как учил философ Кант, предмет, произведенный априорным синтезом воображения, есть предмет идеальный, несуществующий. Процесс, описывающий изменение идеального объекта сам является идеальным, существует только в голове аналитика. Пытаться моделировать идеальный процесс, да еще в нотации BPMN несколько опрометчиво.
Хотите пример, пожалуйста. Клиент обратился в компанию с просьбой выдать кредитную карту (Рис 2). Вполне естественно описать основной процесс в виде BPMN диаграммы (пул «Выдача банковской карты»). Но что есть пул, который называется Клиент? Я предположу, что клиент есть частное лицо. Пул изображает процесс, который происходит в голове клиента. Не кажется ли Вам, что мы начинаем вторгаться в область высшей нервной деятельности. Клиент инициирует основной процесс посылкой сообщения, затем принимает сообщение, что карта готова. Но сообщение это не электронная почта. Видимо, клиенту доступны чтение мыслей на расстоянии и перемещение предметов в пространстве силою мысли.
Вот если бы Вы сказали, что моделируется процесс B2B, я бы согласился, тогда такая конструкция имеет право на существование. Но и тут я бы был осторожен. Ответьте пожалуйста, как один процесс посылает сообщение в нужный экземпляр другого процесса, когда они не связанны родственными отношениями?
В BPM всё как в Unix, родительский процесс знает номер процесса потомка и наоборот. Но что бы послать сигнал другому процессу, нужно знать его реальный ID. На рисунке 2 изображен процесс, посылающий сигнал потомку, тут все нормально (с учетом предыдущего замечания о B2B взаимодействии). Но на рисунке 3 есть пул «Обращение за выдачей карты», который не связан «родственными» отношениями с другими процессами. Здесь начнутся сложности. Вообще говоря, BPMN предлагает решение этой задачи, но увлекшись аналитическим моделированием идеальных процессов, мы забываем о реальных сложностях и проблемах.
Игорь
Спасибо за цитату из Канта. Впечатлен.
По поводу пула “Клиент” - это ни в коем случае не процесс. Пул в BPMN изображает либо процесс, либо внешнюю сущность. В данном случае мы имеем дело со вторым вариантом.
По поводу Id процесса замечание совершенно верное: чтобы послать сообщение другому процессу, нужно знать его Id. Но для этого вовсе не обязательно эти два процесса должны быть связаны родственными отношениями.
Так, процессы, изображенные на рис.3, взаимодействуют через данные: основной процесс “Выдача банковской карты” записывает в БД карт к выдаче не только реквизиты карты (включая ФИО клиента), но и собственный Id! Это дает возможность вспомогательному процессу, в случае успешной идентификации записи в БД, относящейся к данному клиенту, извлечь Id из базы и успешно послать сообщение туда, куда следует.
Так что возвращаю мяч обратно - автор вовсе не увлечен аналитическим моделированием и в курсе реальных сложностей, а вот отдельные комментаторы похоже чересчур увлеклись философией
Уважаемый Анатолий,
Стартовое событие в основном процессе - поступление сообщения (message) от клиента.Поясните пожалуйста, как Клиент посылает это сообщение из “внешней сущности”? Если процесса Клиент нет, то послать сообщение некому. Значит ваша модель работать не будет - не чем стартовать основной процесс.
Даный паттерн применяется для B2B, где есть процесс Клиент, который работает в BPM и может посредством сообщения стартоывать экземпляр процесса у заказчика.
Игорь
Сообщения в BPMN могут использоваться двояко:
1) Как средство межпроцессного взаимодействия. В этом случае за пунктирной стрелочкой в исполняемой среде стоит вполне конкретный механизм типа message queue, обеспечивающий доставку сообщения из одной указанной точки в другую.
2) Как средство документирования взаимодействий с внешним миром, который моделируется пулами-внешними сущностями, иначе называемыми black box. В этом случае за пунктирной стрелочкой никакой исполняемой семантики не стоит, фактически она играет роль комментария к схеме.
Кто-то рисует исполняемые диаграммы BPMN, кто-то аналитические… это нормально. Внешняя сущность есть элемент аналитической диаграммы, но диаграмму на рис.3 легко превратить в исполняемую - достаточно выкинуть пул “Клиент” и сообщения, идущие в/из него, и заменить message start на none start. А вот диаграмму на рис.2 так легко в исполняемую не превратить.
У Анатолия ангельское терпение. То отбивает нападки о правильности выдачи карты, а не по теме статьи, для которой предметная область была выбрана как пример. То замечания программистов, которые думают что схемы нужны программистам, и отправку сообщения клиентом никак не воспринимают обращение клиента через окошка операциониста или иным способом, ведь в реальной жизни не все можно автоматизировать, а прелесть нотации в том что она описывать может все задачи в том числе ручные, заменив массивы текстовых инструкций, в которых работник может утонуть при ознакомлении. Чувствуется преподавательский опыт! Сам когда то вел семинары и лекции, в аспирантуре) Еще один спорщик пытался доказать что нужно описывать процессы в общей куче, а не современной нотацией, к которой потому и пришли, что удобно распараллеливать процессы,…