Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Process Pattern: Post Office

In the previous post we considered a message from external entity that needs to be processed to determine which process instance it should be routed to. But at least there were no incertainity about which process template (process type) the message corresponds: client requests a credit card from a clerk (credit card issuance process),  CV arrives to Human Resources (enrollment process), payment notification reaches Finance (sales process).

Now let’s consider more complicated case: documents arrive to the company’s post address by traditional mail. They don’t reach process participant’s desk directly but go to the general administration office.

Let’s take a banking example once again, this time a credit request from a business entity. Let’s consider the beginning phase of the process:

  • client’s request initiates the process
  • a clerk accepts the application by checking its completeness
  • if documents are missing he/she notifies the client and the process awaits requested extra documents
  • if the documents don’t arrive in 10 days the process ends with “Incomplete application” status
  • after all documents are gathered the process passes to request processing that we leave out of further consideration

First, naive process version:

Fig.1 Client’s documents magically reach “his” process.

As we found in the previous post, there is an implication at the diagram on fig.1: it should be figured out somewhere which particular process instance the arrived documents are for - a simple yet necessary activity.

Let’s apply the “Incoming Processor” pattern:

Fig.2. “Incoming Processor” pattern: which process instance are these documents addressed to?

The easiest way to identify the request is by the reference number in the accompanying client’s letter. If there is no accompanying letter (we should be prepared for this scenario) then we should just look at the sender - probably we have just one active request from this client. If there are more than one then requests attributes should be compared with the documents received. Generally speaking, successful identification isn’t granted - e.g. the documents could arrive when the main credit process has timed out.

But who will obtain the documents sent by the client - right the performer of the credit process? Sometimes this is the case - it may go this way when adressee’s name and department are specified on the envelope. But we can’t be sure about it: the addressing may be wrong or incomplete, the case could be reassigned to other performer. In the general case documents will arrive to the bank’s administrative office.

Now let’s take into account that mail exchange between bank and client may happen not only on the credit matter. Generally speaking there are a number of processes - not process instanceses but different process templates - receiving a spectrum of messages from client:

Fig.3. Which messages relate to the process A and which ones to the process B?

The implication of  the scheme on fig.3: when the office receives a letter saying “please provide a credit for our company…” there is no writing on the envelope saying that this is a start message for credit request process. An incoming letter or documents package is all the office worker can see at first glance.

For this letter to transform into e.g. a credit application or extra documents requested under the credit request process someone should open the envelope, look at the document and identify it as relating to some process. After that the message can be routed to appropriate start event or incoming processor:

Fig.4. Incoming documents routing.

If all inbound correspondence passes through administrative office then most likely all outbound goes through it, too. They assign reference numbers to outbound correspondence and when processing inbound documents they check for this reference number. If it’s found then both process type (i.e. process template) and process instance identifications become much more easy:

Fig.5. “Post Office” pattern: centralized processing of all inbound and outbound correspondence.

One more thing: it’s better to use BPMN signals instead of messages in communications between the Post Office and applied processes, as depicted on fig.5.

Let me remind that signals are a sort of broadcast messages: unlike messages, they are sent not to a single process instance but to all processes awaiting it at the moment. But this aspect doesn’t matter in this case because we are dealing only with start events.

There is another reason to use signals: they provide late binding. When messages are used, one should specify sender and receiver processes at design time. In case of signal receivers are determined at run time - when it was fired. So if messages were used all processes would become interconnected via the inbound docflow; signals let us create independent diagrams for each fragment separated by dashed lines on fig.5.

And now the final note. After discussion of the last post I’m awaiting reader’s comments sayng something like this: “Let’s get rid of traditional mail. The electronic mail will arrive directly to the right addressee with scanned documents attached.”

First, it’s not always possible to replace original with copy.

More importantly, we are not in position to say to business “your procedure is too cumbersome, I can’t implement it with BPMN/BPMS so you have to streamline it”. Sure you may and should warn business that implementing the procedure this way would be harder and more expensive but it should be doable.

Never give lightweight advices to business - it has issues to solve and compromises to find while dealing with matters more complicated than BPMN.

The case considered above was raisied by a student at my BPMN training. Well it wasn’t a bank but a company that have a lot of mail exchange with different regulation bodies. All this mail goes in a very traditional way and changing it means re-educating all this government offices. The company don’t need this kind of optimization, thanks a lot.

07/07/11 | Articles | , ,    

Comments (12)

  1. Сергей Ладнич 07/08/11 01:02 PM

    Анатолий, а если клиент не вставит «в ответ на ваш исходящий № …», то организовывается процесс “Разбирательство……”. Я правильно понял?

  2. Anatoly Belychook 07/08/11 01:27 PM

    Сергей

    Конечно. То, что я нарисовал,- это голая схема, скелет. “Идентифицировать тип документа” можно (и нужно, если мы решаем реальную бизнес-задачу) превратить в подпроцесс и накрутить в нем бизнес-логику, эскалации и т.п. По принципу “были бы кости, а мясо нарастет”. То же самое с идентификацией экземпляра процесса в Обработчике входящих.

  3. Kalyan 07/08/11 06:58 PM

    Very nice and simple explaination of the concepts, Mr.Anatoly. Loved reading it

  4. Procesje 07/13/11 09:12 PM

    Anatoly,

    (here I am again ;-)

    If business has more important issues to solve, then why bother getting insight in their process? That means you will give no advice (is that better then lightweigt advice?)

    It sounds to me like: Anatoly, i’ve noticed that you have two ears. Have a dobry day.

    Regards,

    Procesje

  5. Julia 07/18/11 11:29 AM

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

    И еще: обработчик событий посылает сигнал о поступлении дополнительных документов в процесс А. И при этом ВСЕ процессы А срабатывают на этот сигнал.

  6. Anatoly Belychook 07/18/11 11:35 AM

    Julia

    По поводу названий: спасибо за замечание, это погрешность перевода с английского на русский.

    По поводу сигнала: он принимается *стартовым* событием, какие тут “все процессы А”?

  7. Julia 07/18/11 11:46 AM

    Сорь, с сигналом ошиблась: для старта процесса работает. Перепутала с промежуточным событием.

  8. Maxim Miroshnichenko 01/31/12 11:22 AM

    Возможно, я не до конца понимаю сути задачи, но у меня вопрос следующий: А что, если типов процессов А и В будет не два, как в этом примере, а много больше, как в реальной жизни. Мало того, эти типы процессов меняются (дополняются и изменяются) часто. Все время помнить о том, что в процессе на рис 3 под названием “Входящий документооборот” необходимо поддерживать исходящие от развилки ветки в актуальном состоянии довольно проблематично. Есть ли паттерн проектирования, который помог бы избежать подобного затруднения?

  9. Anatoly Belychook 01/31/12 11:31 AM

    Максим

    Спасибо за очень хороший вопрос. Действительно, тут есть проблема. Решение (паттерн) для нее имеется, скоро опубликую. Следите за обновлениями: http://mainthing.ru/feed/

  10. Maxim Miroshnichenko 01/31/12 12:10 PM

    спасибо большое!

  11. Игорь 03/28/12 05:18 PM

    Анатолий, добрый день!
    Смущает использование артефакта Data Object для “БД исходящих документов”. Разве это не должно быть Data Store? Как я понимаю DO существует только в период жизни экземпляра процесса (в данном случае процесса “Исходящий документооборот”), а нам нужно получить доступ к информации об уже отправленном исходящем документе, т.е. вне периода жизни экземпляра процесса. ИМХО в этом случае уместно использовать DS. Разве нет?

  12. Anatoly Belychook 04/01/12 08:19 AM

    Игорь

    Абсолютно справедливое замечание, в BPMN 2.0 дело обстоит точно так, как Вы написали.

    Просто на момент написания этой заметки Bizagi Modeler поддерживал только BPMN 1.2. В рамках этой версии все изображено корректно.

What do you think?

Captcha

Copyright © 2008-2016 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments