Although a single agreed definition of BPM has not yet been developed, most experts agree that BPM is a combination of management methodology and software tools. But what is BPM methodology and does BPM have a methodology of its own?

To get started, what process methodologies constitute today’s mainstream?

• The most popular today is Lean Six Sigma - a combination of Lean and Six Sigma approaches.
• Lean is a business transformation methodology derived from Toyota Production System (TPS) that focuses on increasing customer value by reducing the cycle time and elimination of waste.
• Six Sigma is a business transformation methodology originally developed at Motorola, it focuses on customer’s value by reducing process variations and elimination of defects on the basis of strict statistical techniques.
• Theory of Constraints (TOC) is a systematic approach to process improvement that views the business as a system of interconnected processes. The key point is that the performance of the whole is constrained by the weakest step like the strength of a chain equals to the weakest link’s strength. Although this methodology’s scope is narrower it brings genuine and practically valuable ideas. As a result they become widely accepted and partially incorporated into Lean Six Sigma.
• Total Quality Management (TQM) is also widely known yet now it’s part of the history rather than evolving methodology. Its basic ideas became part of Lean and Six Sigma as well as the ISO 9000 series of quality standards.

In addition some companies and analysts promote their own, sometimes very interesting methodologies. But perhaps only TQM, Lean, Six Sigma and TOC have reached the mainstream, meaning that there are communities around them, many books are written and training courses are available. Given that these mainstream methodologies overlap with each other to a large extent we can hardly expect that any new methodology would gain wide acceptance in a sudden.

Viewing from this perspective one comes to the conclusion that BPM doesn’t need a process methodology of its own: first, such a methodology would be competing to the mainstream without a chance to win, and secondly, BPM can be successfully applied in any of the mainstream methodologies.

Within BPM we should only talk about «tactical» methodology which is closely related to the tools. For example, BPMS promotes efficient business process discovery. Another example is rapid prototyping of executable processes within BPMS which helps bridging the gap between business and IT and improves agility.

But the strategic issues of process management - like the company’s value chain definition - are rather part of the outer context than the BPM itself. That doesn’t mean underestimating: the context is very important because it sets the business goals; without them the BPM program would be no more than IT department exercise.

What practical conclusions from this are for companies thinking about implementing the BPM program?

1. Take care both about technology and methodology. Within technology you should choose a BPMS, agree business process modeling style, adopt a standard business process lifecycle etc. On the methodology side you need to know e.g. how a particular process for the next project within BPM program is choosen: what’s the procedure and who is in charge. How the key metrics are choosen at the project start and how the goals are measured at the end? How the visibility of processes and their reuse are promoted within the organizations? Who is responsible for business processes to join into a value chain and not becoming scattered islands of suboptimization?
2. Leverage on ready-to-use BPMS and methodology. Developing a methodology of your own as well as developing a BPMS will bring you too far from the ultimate project goal which is improving your business efficiency. Keep in mind that developing a unique methodology could only afford such giants as Toyota (Lean), Motorola (Six Sigma) or Xerox (TQM). Stand on the giants’ shoulders - spend time on the books and trainings, hire consultants that have experience in implementing process management with BPM. This in no way means the call to blindly copy other’s experience. In fact, all methodologies establish only general principles and leaves more than enough room for the adaptation to the conditions of your particular business. And they all emphasize the importance of developing your own competence rather than buying it from someone else. So you’ll need talented and motivated individuals starting from the company’s top and you will have enough tasks adequate to their ambitions.

Alternative title: “Micromanagement”.

The typical first BPM project issue: how deep to dig into a business process details?

We were engaged into a process called “Purchase order by the three-tier agreement” in one of our first projects. Here is the brief:

• A three-tier agreement is concluded by and between the buyer, the manufacturer and the supplier - manufacturer’s authorized partner.
• The agreement is designed as a framework: it specifies prices, terms and conditions, but not the items to be purchased nor the volume. Each purchase shall be specified by a separate specification containing items and quantities. When signed such a specification enforces contractual obligations to all parties.
• The process is managed by the supplier and there were no intention to directly attach the buyer or manufacturer to BPMS. The whole process runs inside supplier’s organization yet there were such activities as “send the specification to manufacturer for signature” or “ship the goods to buyer”.

The process consists of four majour phases:

1. Agreeing the order.
2. Signing the specification.
3. Delivery.
4. Payments and deal closure.

Let’s consider the first phase “Agreeing the order”. Despite terms and conditions are set by the agreement, the bargaining may happen here, e.g. the buyer may request an additional discount for a large order or tougher delivery terms tied to the internal project schedule. In such cases the account manager should agree on the conditions within the organization and with the manufacturer; if the buyer requested too much then a compromise acceptable for all parties should be found. Several iterations may be necessary lasting for months. It’s a delicate work highly depending on account manager’s skills. And this is the key point of the process - the remaining activities are pure routine.

The first version of the process diagram looked like this:

Then it became more compliacated. First, if the manufacturer made a counter-offer that we found acceptable then we should only agree it with the buyer on the next round; the same is true with respect to buyer’s counter-offers. Then it was rightly pointed out that the process may be speed up if negotiations with the manufacturer and the buyer was made in parallel. And so on.

Let me skip the evolution of the process and proceed directly to the resulting diagram:

The key point of this process is that there is a single performer: account manager. No one else cares about where we are inside. Agreeing started / agreeing ended successfully / agreeing failed - that’s all the business (the process owner) is interested in.

I’ve seen process diagrams similar to the first one several times. For example, there was customer’s process of accepting goods to the warehouse with about twenty activities, all performed by a  storekeeper. It doesn’t make sence. You get cumbersome scheme prone to frequent changes yet the details do not add value to the process.

Target BPM on the overall process performance and cross-functional problems which are responsible for poor performance in most cases.

It is not easy - you must be ready to find yourself under crossfire if your studies affect existing borders between organization departments. But don’t go the path of least resistance and don’t use BPMS to document a sequence of activities performed by a single person.

The current financial crisis isn’t a threat for BPM because there must be a boom before to talk about a crisis and there were no boom in BPM.

Some people anticipated the boom by calling BPM “The Next Big Thing”. Pure-play BPMS vendors have made big bids on the boom. The stack vendors aquired BPM assets.

In Russia, every BPMS vendor now has about one and a half BPM project - one successful and one decent - and shows them at every event. The first BPM conference in Moscow held in 2006 so companies invest into BPM marketing minimum for three years now. The results aren’t very impressive; not a boom anyway.

» read the rest

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

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.

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:

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