I critisized reengineering - in its radical form - many times both in public speeches and in private talks.

There was a temporary retreat from the concept of constant performance improvement during the reenineering epoch of 90’s. The technocratical, american, “cowboy” approach has won. Yet the idea of being able to draw the ideal business-process from scratch turned out to be too idealistic. First, cross-functional (enterprise-wide) business process are too complicated to be designed in one iteration. Secondly, there is no such thing as optimal “to be” - only a run to ever-escaping horizon.

Methodology, technology and organizational principles of BPM are based on these realities.

But… there is a nuance.

We conduct BPM projects for several years now and have a clean understanding of three conditions that should be met from a prospect’s side for the project to be successfull:

1. There must be a “pain”. Business must have a problem critically affecting it’s competitiveness and company’s prospects in general. And the problem should be identified - just an attempt “to do something” is no good.
2. There must be a will to solve the problem. Companies with degraded motivation - e.g. those where owners abandoned business completely, fully trusting to hired managers without a stock share - have problems at this point.
3. There must be resources: financial and intellectual. Minimal financial requirement is two full-time specialists, minimum one of them being internal employee. Intellectual resources means top managers being business process owners which implies in particular their readiness to spend one or two hours weekly to participate in process (re)design sessions.

Now, the first condition automatically means that the first step of your BPM project must be no constant improvement game but a radical redesign of the business process.

Why? Because “isn’t broken - don’t fix” principle is still in place. With very rare exceptions, no businessman would launch BPM initiative (as well as any other serious innovation) just because the life became too easy. There must be a performance gap for the project to be financially meaningfull. In simple words, one of valuable processes must be broken.

This way, we are back in reengineering, albeit on a new turn of evolution spiral. And by the way, “as-is” and “to-be” are also back in play - now we need them to quantify and measure process performance at project begin and end to tell the project sponsor exactly what he got for his money.

The bottomline: the BPM car in motion is constant improvement yet the starter of this car is one-shot, radical enough, reengineering-style process improvement.

Too bad I catched this only now when Michael Hammer has gone…

I can’t avoid paying my deep respect on this occasion to another titan that left us last year - Geary Rummler. He said in his interview (possibly the last one):

“I think there is only one critical condition for success that must exist – and that is the existence of a critical business issue (CBI) in the client organization. If there is no CBI (hard to believe) or management is in deep denial as to the existence of one, then serious, transforming BPM is not going to happen. Period. There may be misleading “demonstrations” and “concept tests,” but nothing of substance will happen. How can it? Serious BPM costs money, takes time, and can upset a lot of apple carts, and you can’t do that without an equally serious business case. I guess you could argue that a second condition – or factor – is that the internal BPM practitioner is about 70% a smart business person and 30% a BPM expert. Because the key to their success is going to be finding the critical business issue, understanding how BPM can address it, and then convincing top management to make the investment. I guess those are the two conditions: an opportunity and somebody capable of exploiting that opportunity.”

Thank you Geary, hopefully we’ve got the right course.

Sorry, this entry is only available in Русский.

Sorry, this entry is only available in Русский.

Another frequently asked question from a forum.

Question - When a business process template is modified (activity added/removed), what happens with process instances started by this template (previous version). What happens with analytics?

Answer - Most BPMS will finish running instances by following old template and will create new instances based on new teplate. It’s acceptable only if the template modification was planned. If - like it happens in most cases - the process became stuck because the template doesn’t have a desired gateway or a flow then you have nothing to do but abort the process instance and start it again by new template making the analytics inconsitent.

Yet there are systems allowing process scheme modification “on the fly”. Recommended reading:

• ebizq.net article by Glen Smith from Appian explains why this functionality is important from methodology perspective. You can launch the process into operations faster if you don’t have to discover details of all possible exceptions.
• Keith Svenson from Fujitsu notes that implementing process modification on the fly is hard to implement in a system that uses BPEL for excution. Fujtsu Interstage BPM lets you edit the scheme of a running instance the same way you edit a template; you can save the new instance scheme as a new version of the template if you wish.

Please refer to BPTrends report for the information about specific BPMS.

It’s hard to implement on the fly modification if a business process editor (modeler) is implemented as a desktop application which is the case for most systems. If a process instance stuck one should be able to correct scheme online promptly. Hence the modeler must be implemented as a thin client. Fujitsu Interstage for example has both desctop and online (java applet) modelers.

Oracle BPMS (aka BEA AquaLogic aka Fuego) took another way. The modeler pallette of this system has a special “magic” activity which can get control from any activity and/or pass it to any other acitivity. It solves the major part of the problem - absence of a desired flow on a scheme.

But you shouldn’t rely on a tool only - the process sheme should be designed the right way.

Let’s consider a long-term contract with a customer for example. We are going to deliver goods, obtain money and also renew contract’s terms and re-negotiate its conditions many times during several years. If we tried to implement it technically by a single process then for sure its scheme will be changed many times. Better solution is to create a long-living yet very simple process on the top level - a kind of a state machine keeping the state of our relations with the customer: “contract is beeing agreed”, “contract is in effect”, “contract is being agreed” etc. Every action starting from contract negotiations should be implemented by a workflow-like process. This workflow can be started if the contract is at some specific state and it can send a message to the contract process which will bring it from one state to another. Since the state machine is strictly passive one can modify a workflow scheme freely and/or create several alternative versions of e.g. delivery workflow.

How people activities look in various BPMN implementations? Let’s assume purely for illustration purposes that we have an “Inquiry to Order” process containing three activities: “Do This” (system), “Negotiate Contract” (human), “Do That” (system) and diagram it with several popular tools:

» read the rest

Sorry, this entry is only available in Русский.

As mentioned at “End-to-End Process Orchestration anti-pattern“, business doesn’t work like “one-two-three”: shop floors don’t switch on/off by every client’s order even at produce-to-order scenario; material purchases are arranged for a production program rather than for a single finished product. Hence an end-to-end business process is modelled not by a sequence of activities within a single process (so called process orchestration) but by several processes executed independently and exchanging data and/or messages.

In BPMN each process is modelled by a separate pool. A process chain “Order to Cash” - “Manufacturing” - “Material Supply” for example may look as follows:

“Order to Cash” process is initiated by an incoming message - an order submitted by a client. “Manufacturing” is triggered by a timer, e.g. at the end of each working day, and handle queued orders within a cycle. If necessary materials are not available then “Manufacturing” waits for a signal from “Material Supply” that they are delivered. “Material Supply” is scheduled by a timer too and arranges purchasing for materials having the projected stock balance below the limit. (The internal orders chaing may have more links than in this example, e.g. a metallurgical plant may have inter-shop orders.)

Such asyncronous inter-process communication implies buffers between them. The buffers accumulate orders passed from process-requestor to process-provider. In the example above these are “Manufacturing Orders” and “Planned Stock Balance”. Technically such buffers may be implemented by a number of ways: message queue, database records, ERP objects at some specific state. Of course the buffer internals better to hide by wrapping them with services like “insert”, “traverse”, “extract”.

Modern BPM Suites are able to model and execute diagrams like above and this is the major BPMS advantage over traditional workflow systems. However such diagrams turned out to be difficult for analysts as Bruce Silver noted at “BPMN to Requester: Get Outta My Pool“. The major issue isn’t the notation but “asynchronous thinking”. One should develop an ability to extract separate asynchronous process from what business present to you as a single process. The answers to following questions should help: 1) what business object corresponds to a business process instance; 2) which events correspond to process instance start and stop.

For example, even in the relatively simple process of hiring an employee we can find a set of business objects: 1) a headcount item; 2) manager to HR request to fill the item; 3) a vacancy passed to a specific recruiting channel; 4) a candidate; 5) hired employee. They do not correspond to each other as 1:1 and their lifecycles aren’t synchronous. E.g. a candidate may submit his resume not caring about whether we have a vacancy for him - it’s HR task to assess which vacancy (or vacancies) it’s worth to consider for him. So a single process will hardly suffice; it depends on your business how much process there will be at the end of the day.

Worth to note that employee hiring is a classic business process example that BPM vendors love to use for their products demonstration. Yet they try to do it with a single process! Obviously such demos are made by developers, not consultants.

Final warning: please don’t consider the above as a call-up to breed too many asynchronous processes. In fact, the choice between synchronousness and asynchronousness is a non-trivial managerial decision but we’ll talk about it next time.

Sorry, this entry is only available in Русский.

To be more precise, it was a big fun back in 90-s; modern process disciplines are not as funny as reengineering and ISO 9000. Look at the selection of Dilbert strips on the matter. » read the rest

Sorry, this entry is only available in Русский.