After speaking at a Six Sigma conference I was asked what my definition of BPM is and what differentiates it from Six Sigma. The topic of my presentation was how to identify important change programs. I am not sure what exact wording I used but I must have first stated that I am not a Six Sigma expert, only a Six Sigma customer, but Six Sigma did not seem to use standards. The BPM definition must have included process measurement, modeling and change planning. Later in my hotel room I realized I never put to paper what my definition is of BPM.
For me BPM started 5 years ago with a request to join a group of individuals traveling to Minneapolis that was going to be trained in SCOR. The training experience was both positive and negative. The positive aspect was and remains the standard definitions for processes and metrics. As a former reporting manager I have spend many meetings explaining why we adopted a certain set of metrics and then sat through the arguments of what the definition should be according to such-and-such. Today whenever somebody asks the question how to measure an aspect of the supply-chain the response is simple: Here’s the list of SCOR metrics; let’s review which aspects you want to measure. The ‘excuse’ that they are the industry standard quickly kills those two birds with one stone; What metric and How is it defined.
Once I started using SCOR on my projects I realized the true value of the standard definitions for process. In many projects, where two teams need to come to an integrated solution or extract a single process out of two ‘this-is-how-we-always-did-it’ processes, a lot of resistance seems to exist about the what and how. Experience learns this is partially caused by the lack of understanding of what it is people do, we have all been trained to think in organization rather then process. The label of an organization may or may not be representative for what it is the organization does. (I started my carrier in a group called short-term-planning, a group of supply-shortage fire-fighters, we did everything possible and impossible to support customer orders, but none of it would classify as planning). Just imagine the potential differences between two organizations with the same name in different companies (like in a merger or acquisition situation).
At the time the Supply-Chain Council’s training materials stated that a SCOR project would take between 12 and 18 months. This was a big turn-of for us. We already knew how to do a multi-year projects (just continue business as usual). It would also be a hard sell to our management: “If we train everybody now, we will see the results in 12-18 months”. This, plus the knowledge that the attention span of management for ’strategic’ projects was about 3-6 months, did not really seem like something we would invest in.
To fast forward through 5 years following the training; I started using SCOR on projects I worked on, then got to train a couple of people in using SCOR, later formed a group of SCOR project managers and soon realized we were fine-tuning the way we did projects. Methods and templates were modified and frameworks for other business domains – such as product design and sales operations – were created. Somewhere along the way the name BPM was attached to what we did. That’s when I first started looking at the definition of BPM. Gartner separated BPA and BPM; BPA, Business Process Analysis, representing more of what we did. BPM (Business Process Management) stood for the automation of workflow. Many IT professionals seemed to agree with Gartner on the meaning of BPM.
Enough about history, back to the original question.
What is BPM? BPM is the ability to identify the core processes and validate their effectiveness, completeness, similarity, redundancy and re-usability. The M for management implies continuity, the ability to constantly re-align process to every changing market needs and company goals.
In BPM standards there are two aspects that need to be considered: Taxonomy and Implementation. Taxonomy is the aspect of using a common language, classification or using the same words to describe the same things. Most people I talk to about SCOR are drawn by the taxonomy aspect of standard process frameworks as illustrated in Figure 1.. The Implementation aspect, however, is more valuable. Implementation is the way a process is executed at the detail level. This includes the sequence of activities and can be significantly different. Aspects that determine the implementation are Organization (who is responsible), People (who performs the work), Technology (what tools support the process), Location (where is it done), Business rules (do’s, don’ts, and how is the process measured).
Consider the process of ‘Departing’ of a business trip. My proposed taxonomy would include the following process steps: Book the trip, Travel to Airport, Check-In and Board the Plane. As a frequent traveler I have different implementations of this process with different airlines and/or destinations. Let’s compare domestic flights with Continental and Southwest. Continental is based in Houston and our preferred carrier; they provide direct flights to most locations, which saves on travel time. When I book a flight I am assigned a seat in advance. Southwest is a carrier that I travel if cost is the primary consideration. Southwest does not pre-assign seats; they operate a FIFS (First-In/First-Seated) model. Their seat-assignment business rule changes my behavior, and thus how I implemented the process. Figure 2, shows the implementations of Departing with Continental and Southwest.
The input to the ‘Departing’ determines the outcome of the ‘Book the Trip’ step. If cost is primary and travel time secondary, then it will most likely be a Southwest ticket. If the input is to reduce travel time then a slightly more expensive Continental ticket will most likely be the output of this step.
The next step depends on the airline. As Southwest assigns no seats I would like to check-in as early as possible (my unconfirmed belief: the earlier you check-in the better your boarding group). For Continental I travel to the airport before I check-in. The example highlights the difference in sequence. There is also a difference in Check-In. Figure 2 does not really highlight this. I can either highlight this in the narrative for process-element ‘Check-In’, or, if it adds value to my project, I can model the next level down for ‘Check-In’.
The figures above highlight the difference between using a process framework as a taxonomy-only or extending it to implementation. The implementations (specifically the sequence and connections of process steps) also highlight another aspect: Performance. Trying to shorten the Check-In-to-Boarding-Complete-Time makes sense for Continental. Continental customers experience that time mainly as waiting time. For Southwest a project to shorten that time would most likely fail, unless the project team would be allowed to change the business rules on seat assignment. The relevant waiting time metric for Southwest would be the Travel-to-Airport-Complete and Boarding-Complete-Time. Please note that post-9/11 security may require it’s own process element; in my original example it is a simple step as part of the boarding process.
My advice for BPM-starters is to select an existing reference framework that contains process and metrics pre-populated. Start with measuring the high-level metrics and describe your company’s, function’s or organization’s level 1/2 processes. But, don’t take my work for it, prove it to yourself in practice. Talk to other practitioners or a trainer on how to make process management a competency for your company.
