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.