Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Anti-pattern: “End-to-End Process Orchestration”

Definition:

  • “Enterprise Process” (equivalent term “End-to-End Process”) is a business process connected to external customer at both ends and going through more than one top-level company’s departments.

Axiom:

  • A BPM initiative would pay for itself only if you target end-to-end processes.

Otherwise you’ll be guilty of suboptimization sin according to Lean methodology or will “shoot sparrows with a cannon” according to Russian proverb. Yet it doesn’t mean you must begin with such a process - you may use something else for training but you won’t win a medal for training only.

Typical errors:

  1. BPM vendors love to illustrate their products by supporting processes like “Employee Onboarding” or “Expenses Report” thus provoking prospects to do the same. It’s OK for training but there is simply not enough money beghind these processes to justify enterprise-wide project which what BPM project is by definition.
  2. Many prospect wish to go for “Negotiating a Contract” process. There are money behind it but is this a process really? For me it’s rather a fragment of end-to-end process “Sales of Goods or Services”. Customer’s concern being the end result - i.e. performance of the process as a whole - it may happen that the bottleneck wouldn’t be this particular fragment. Narrowing a scope leads to suboptimization.
  3. And here is the worst case: “We have a process here, well-studied and alredy automated, now let’s implement it in BPM for comparison”. In other words, let’s make a race between good and better. For your project to be acknowledged by the management you must not only implement some process in BPM but also significantly improve it. You’d hardly make it with a process that was well worked on already.

OK, let’s assume that we do everything right and consider “Order to Cash”, a classic example of end-to-end process. (Good questions would be: “Why exactly this process?” or “How to pick up the best one from many company’s processes?” These deserve detailed answers however so let’s leave them for the next time.)

“Order to Cash” process in “produce-to-order” business scenario may consist of prepayment, manufacturing, delivery and closure subprocesses:

End-to-end process example diagram in BPMN

What’s wrong with the above diagram? It assumes (since we have only one pool) that manufacturing works synchronously with sales: no order - manufacturing is idle, order arrives - manufacturing starts working on it. If we got deeper into manufacturing subprocess, we would probably found materials and/or parts purchasing subprocess, sychronized with manufacturing in turn.

But businesses just don’t work like “one-two-three”!

Manufacturing does not switch on/off by every client’s order even if we produce to order. Clients’ orders are accumulated and picked up on regular basis, say daily by production scheduling process. Similarly, purchasing is not triggered by a single order usually but rather runs regularily or is triggered by stock level going below a limit.

Technically such work is implemented in BPM not by a singe sychronous process like shown on the diagram above but by several asynchronously executed processes that communcate with each other by data and/or messages. Such scheme can be drawn with BPMN and executed by BPMS - which, from my point of view, is a big advantage of BPMS over workflow. But let’s consider the correct diagram next time - what I’m going to say here is that asychronous execution is a core feature not only of this particular but of every end-to-end process.

Definitions:

  • “Process Orchestration” means tasks execution sequence and logic within a single process frame.
  • “Process Choreography” means the logic of several processes asynchronous execution coordinated by data/message flows.

Theorem:

  • End-to-end process should be modeled by the choreography, not by the orchestration.

It was confirmed by practice and could be proved by the following consideration: since end-to-end process by definition goes through several top-level departments, you’ll have to take into account the working rhytm of each one of them, which means - modeling asynchronous execution.

An attempt to model it by pure orchestration is nothing else but following an anti-pattern which I will call “End-to-End Process Archistration”.

12/22/08 | Articles | , ,    

Comments (13)

  1. AS 12/23/08 09:39 PM
  2. Anatoly Belychook 12/23/08 10:36 PM

    Alexander

    Please be less pedantic :) Or better ask BPMN standard body to be more precise :)

    Of course production goes after ordering - did I said the contrary here? The question is: whether an order fires production (in that case it may be implemented as a subprocess within the same pool) or production is triggered by some other event e.g. by a timer (then it’s another pool). My point is that novice BPM desingers tend to use former model but the latter is more realistic.

    Branches from a parallel gateway may go over other pools? I seriously doubt this. Not in BPMN. But you are right: parallel gateways do produce asynchronous threads.

    My favourite analogy to process choreography is threads programming in java.

  3. AS 12/24/08 01:40 PM
  4. Anatoly Belychook 12/24/08 01:54 PM

    Alexander

    Of course you diagrammed both choreography and orchestration. The words “branches may go” from your first post are misleading I’m afraid: most people would suppose you mean sequence flow. So it’s my turn to ask you be more accurate :)

  5. AS 12/26/08 12:50 PM
  6. Anatoly Belychook 12/26/08 01:13 PM

    Sorry Alexander, don’t understand you. I believe you get choreography as soon as you draw more than one pool and messages accross them. Please share your interpretation.

  7. AS 12/30/08 02:27 AM
  8. Anatoly Belychook 12/30/08 01:51 PM

    Alexander

    I follow Bruce Silver’s interpretation:
    * orchestration = single pool, sequence flow
    * choreography = communication between multiple pools, message flow

    BPMN 1.1 spec define choreography as “an ordered sequence of B2B message exchanges”. It’s close to your interpretation because B2B situation implies lesser predictability.

    Two interpretations diverge on multi-pool processes with pools representing different process instances, not different business entities. And this is exactly the subject of the original post. Under your interpretation, I should have call it “Single pool end-to-end process”. Not a bad idea may be, thank you for the input.

  9. Сергей 09/10/09 12:43 PM

    Продажи - это не сквозной процесс, как мне кажется, а набор фрагментов различных процессов

  10. Anatoly Belychook 09/14/09 10:47 AM

    Сергей, загляните вот сюда: http://mainthing.ru/ru/item/150/

  11. ISA 05/19/11 04:08 PM

    Правильно ли я понимаю, что с выходом BPMN 2.0 в данной статье оркестровку надо заменить на межпроцессное взаимодействие (collaboration)?

  12. ISA 05/19/11 04:14 PM

    Сделал опечатку, имел в виду:
    “… хореографию надо заменить на межпроцессное взаимодействие (collaboration)?”

  13. Anatoly Belychook 05/19/11 05:58 PM

    Да, правильно.

What do you think?

Captcha

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