Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Command vs. Respond

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.


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”).


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.

02/05/13 | Articles | ,    

Comments (7)

  1. Алексей Громыко 02/06/13 05:33 PM

    Прежде всего, спасибо за пост!
    Из моей практики, определение границы между оркестровкой и межпроцессным взаимодействием - один из самых сложных вопросов. Сложность его в том, что нужно сделать выбор между качеством процесса и эффективностью загрузки ресурса. Для ключевых процессов такой выбор носит стратегический характер.

  2. Xipe 02/06/13 08:21 PM

    Thank you, Anatoly.

  3. Наталья 02/17/13 12:22 PM

    Анатолий, добрый день!
    Я со студентами попробовала применить BPM к деятельности одной из фирм в нашем городе. Как, на Ваш взгляд, у нас это получилось?
    Ссылка: Волчихина Л.С., Тихомирова А.В. ПОВЫШЕНИЕ ЭФФЕКТИВНОСТИ УПРАВЛЕНИЯ ИСПОЛНЯЕМЫМИ БИЗНЕС-ПРОЦЕССАМИ КОМПАНИИ “ДЕЛЬТА” НА ОСНОВЕ BIZAGI BPM SUITE // Материалы V Международной студенческой электронной научной конференции «Студенческий научный форум» URL: (дата обращения: 17.02.2013).

  4. Anatoly Belychook 02/18/13 08:12 AM


    То, что студенты (с Вашей помощью) пытаются решать такие задачи и смотреть на бизнес через призму процессов, безусловно, радует.

    Что касается содержания работы, то я бы заметил следующее:

    1) Bizagi BPM Suite, в отличие от бесплатного Bizagi Modeler, не является ни бесплатным, ни свободно распространяемым. Это относится и к версии Xpress, и к Enterprise. Хотя, действительно, любой желающий может скачать и установить софт, который не ограничен ни по функциональности, ни по времени использования - только по числу пользователей (10 для Xpress).

    2) В приведенной BPMN-диаграмме не стоит бы моделировать клиента дорожкой (это внешняя сущность) и изображать задачи типа Составить заявку - Принять заявку, см.

    3) В потоке управления за развилкой по событиям (схема to-be) может стоять только обработчик события.

    4) Непонятно как компания ведет свой бизнес, не получая от клиентов деньги ;)

  5. David Mann 07/25/13 06:01 PM

    Fantastic explanation. This post is the single most illuminating thing I’ve read about BPM design. It explains the two different patterns, and the circumstances in which to use them. I just learned that the Activiti open source BPM engine does not directly support messages between pools. This was important to know as it is part of the pattern you say is the single most important one- “Collect and periodically process”

  6. Anatoly Belychook 07/25/13 07:40 PM

    Thanks David.

    I agree - the BPMS ability to support interprocess communications matters a lot. Some tools miss messages, others are not friendly in sharing data which is equally important as you can see from the patterns above.

    It’s a trap as I tried to explain here because typical PoC doesn’t go that far. I’m glad you missed it.

  7. Xipe 07/26/13 05:59 AM

    Sorry, Anatoly for asking this here. It’s actually for David Mann. I have also started to use Activiti some weeks ago. You comment on its lack of inter-process communication in Activiti interests me a lot. Do you have an email, pls?

Comments are closed

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