Question #1 of BPMN-based process analysis: what are we going to do - Command or Respond?

• Command means using orchestration only, i.e. model within a single BPMN pool.
• Respond means providing handlers for events raised by external entities (clients, partners, government agencies), internal services and/or enterprise software systems.

Examples

1. Wait for customer’s payment

Scenario 1: Low intensity process - the average number of unpaid invoices is about 10. Let’s Command:

Fig. 1.1. Low intensity - Command

Scenario 2: High intensity process. The problem of the model in Fig. 1.1 is the “Get payment” task. The only thing a performer can do is to call the customer and remind to pay the bill, but it won’t make the job done. This issue could be ignored when there were few unpaid invoices but if one expects hundreds or thousands then the model in Fig. 1.1 would produce hundreds or thousands of “non-tasks” flooding the to-do list of the process performer. Not very convenient, to say the least.

To be honest, “Get payment” is an event, not a task. We become aware that the bill is paid by receiving a bank statement. Let’s switch from Command to Respond:

Fig. 1.2. High intensity - Respond

The same patterns and Command vs. Respond choice occurs when we are waiting for documents from a business partner or a truck delivering goods ordered.

2. Select a supplier

Scenario 1: low intensity process. Only one tender occurs at any given time, the average number of  candidate suppliers is three, the term of the offer is one week. Let’s Command:

Fig. 2.1. Low intensity - Command

Three instances of the “Get offer” task would hang in the performer’s to-do list for a week - not a big deal.

Scenario 2: A large organization, up to 10 tenders running in parallel, up to 10 candidates in each, tender timeframe up to 30 days. With the model in Fig. 2.1, up to 100 instances of “Get offer” task will hang in the performer’s queue for about 30 days. Again, it’s a “non-task” because it’s beyond performer’s control.

Let’s switch from Command to Respond by treating receiving an offer as event, not task:

Fig. 2.2. High intensity - Respond

The same patterns and Command vs. Respond choice occur in the Hiring process - it’s a competition of employee candidates instead of potential suppliers.

3. Conclude a contract

Now let’s look at the purchasing process from supplier’s perspective.

Scenario 1: We received a request for proposal, the buyer follows a well-defined procedure and the decision timeframe is known. Let’s Command:

Fig. 3.1. Fixed term tender - Command

Scenario 2 - “Proposals factory” - only 10% of submitted proposals win, the time from submitting a proposal to the order can last for months. If the process in Fig. 3.1 is followed, it won’t complete forever because there is always some likelihood that the customer will get back. (As soon as we ended the process, the customer would bring us the order according to the law of meanness.)

It can be argued that the proposal has an expiration date so we may end the process after that. But in practice the deadline is often imposed by the supplier only to push the buyer hence suppliers agree to accept terms formally expired.

Let’s switch from Command to Respond by treating request for proposal and order as two independent events initiated by the client and triggering two separate processes. The positive result of the proposal work now is not a contract but its acceptance by the client:

Fig. 3.2. “Proposals factory” - Respond

Another process may be added that would scan submitted proposals periodically and push sales manager to contact the customer.

4. Fulfill an order

Scenario 1: The repair shop fulfills a client’s order. Let’s Command:

Fig. 4.1. Quality is priority - Command

Scenario 2: The plant produces goods by clients’ orders. Manufacturing doesn’t obey the rhythm of clients’ orders because it must plan capacity and supplies in advance. Therefore the client’s order process doesn’t command manufacturing - it responds to a message from the latter:

Fig. 4.2. Effectiveness is priority - Respond

Because internal orders are accumulated in the buffer before getting into manufacturing, the order fulfillment time seems to increase. But if we don’t plan manufacturing its effectiveness will drop down so dramatically that the client will suffer even worse.

Having an input buffer is more comfortable than working at a pace imposed from outside so not only manufacturing but any other function may request it. Yet it should be provided to the critical resource only or the overall process quality would be compromised.

The same patterns and the same choice Command vs. Respond occur in the “Payment Approval and Scheduling” process. Sometimes the working capital may be the critical resource. If this is the case, the payment requests should be stored in a buffer and ranked by priority. Another case is CFO as a critical resource - it’s more comfortable to approve a list of payment requests once per day or once per week than one by one in a real time.

The choice Command vs. Respond would occur more than once in a decently complex process. As an example, “Get payment” in the diagrams above may be implemented one way or another according to Fig. 1.1 and 1.2.

5. Integrate business process with corporate systems

Scenario 1: Employee enters expense into BPMS then it is approved by finance and entered into ERP automatically. Let’s Command:

Fig. 5.1. Data collected by BPMS and stored in ERP - Command

Scenario 2: The end-to-end process “Order to cash” is served by several computer systems - the order comes from external web portal, shipment is prepared by warehouse employees using their own application, delivery is managed by logistics application and payment by accounting system or ERP. Each system successfully implements fairly complex functionality and their replacement or rewriting is out of question. Time to switch from Command to Respond:

Fig. 5.2. Functions are controlled by corporate systems and overall process by BPMS - Respond

Although each system implements its function well, the control may be lost in transition between systems. End-to-end process visualization, execution and monitoring within BPMS are much more efficient than point-to-point systems integration.

Technically BPMS interact with enterprise systems by calling their functions via web services. (If the legacy system does not support web services then ESB may help to translate a web service call to a specific interface and back.) The enterprise systems code should be modified by introducing callbacks to BPMS after the next function is completed - these calls initiate BPMN events.

All essential functions are performed by enterprise systems, BPMS responds to events happened (the order is paid) and also (an important point) to events that didn’t happen (payment timed-out.) BPMS responds to an event that happened by calling another system and to an unhappened event by triggering an escalation (”Investigate delay,” “Client in debt”).

Conclusions

1. Command technique is sufficient if:

• We are dealing with supporting process not interfering with the external customer.
• Quality of the process is more important than resource usage efficiency.
• The intensity of the process is low - few process instances run simultaneously rather than tens, hundreds or thousands.

2. If you only know how to Command or a vendor/consultant demonstrated only the ability to Command on supporting processes like “Vacation request” or “Expenses report” then you know less than half of what is needed to know about the process analysis with BPMN. And you are at risk to face unpleasant surprises when switching from PoC (Proof of Concept) to core business processes.