You can't always get what you want
  But if you try sometime, you get what you need
- Some old dudes

This is the Third in a three-part article, regarding the processing of choosing, quantifying, and starting your first process transformation. Part 1 can be found here, and part 2 can be found here.

In the second part of this series, we talked about soul-crushing humility. This is where that comes in. Get a pillow: this is going to hurt.

The Setup.

First, let’s focus the use case. For the sake of the discussion, let’s assume we’re talking about a loan application process.

The process Diagram for the Loan Application is diagramed below.

Loan Simulation
Figure : Loan Application Simulation

The Use Case

The Loan Requestor applies for a loan. The Reviewer reviews it. If the loan application is unacceptable, we’re done.

If the loan is acceptable, the Reviewer suggests terms. The Requestor then reviews or counters those terms. If there is agreement, then the loan is released. If not, the Reviewer makes a counter. And so on until we’re done.

After extensive research, we’ve decided that we really care about two KPIs here:

  1. The Throughput of loan applications in the system
  2. The cost of processing each loan application

So far, so good.

You get what you need.

In the process world, we spend a lot of time talk about AS-IS vs. TO-BE. The AS-IS is the state of the world before we begin our work, and the TO-BE is what we’d like to achieve. It’s important stuff, and a key feature on how to start process improvement. But it’s not the end of the line.

Once the project is delivered, we spend some time talking about the Achieved and the Projected. This is how to measure what we got with what we wanted. This is the actual stuff, not necessarily the stuff we were wishing for.

First, a little vocabulary

Let’s define our terms.

The Achieved is the actual observed state of the system we build: it’s the measure of the KPIs we defined in step 2. For example, we were able to process 15 applications per hour at a cost of $10 per application.

The Projected is the goal we were shooting for: it’s what we guessed/hoped our system would be able to achieve with the KPIs we projected. For example, we projected that we would be able to process 23 applications per hour at a cost of $8 per application.

The Goal here is to clearly align what we expected with what we got. It’s honest and it’s brutal. A chart like the following can help. This, incidentally, is where that humility comes in handy: because chances are, you’ll under deliver on the first iteration. But this isn’t about a tactical win: this is engaged strategy. Tactical wins are checkers. We’re play Chess here.

Figure 1 - Achieved v Projected
Figure : Achieved vs Projected

If you can’t explain it simply, you don’t understand it.

It’s been my experience that the big problems almost always come down to an 80/20 rule in enterprise systems. There are 2 or 3 key changes that will make a big difference. And those usually have two or three big factors.

I like focusing on the big changes, because it forces a discipline of identifying big systematic flaws, digging deep into those, and keeps one from going off on wild goose chases that can lead to paralysis by analysis.

Yeah Yeah: What does it actually look like in the real work, Max?

It looks like you, forcing yourself to focus on no more than two or three Key Process Indicators(KPIs), and measuring what you go vs what you expected. It looks like you forcing yourself to focus on just two or three causes for each one of those KPIs in order to make sure you don’t start chasing snipes when looking for concrete fixes.

Then, you value to assign a value to the delta. Is the difference worth your effort? If you saved $17,000,000.00 dollars, but you had projected $17,000,100.00, do you really need to dig into further improvements?

Assuming the answer is yes, or that you have identified some other KPI that is worthy of your efforts, you head into root cause analysis, as below.

This is how we do it

Here’s the methodology I use when I’m reviewed Achieved vs. Projected. There are many more elaborate ways to do this, but I find the simplicity of this system suits me fine.

  1. Identify the two or three KPIs that you really care about
  2. Compare what expected the KPIs to be with that they actually are. Then decompose the KPIs into specific drivers that lead to corrective actions.
  3. Score your findings
  4. Believe your data

When you’re done, you’ll get the data you need. If you want to be shamncy about it, you can use a Ishikawa chart like the below.

Figure 2 - Achieved v Projected
Figure : Achieved vs projected

In my Loan Application, I determined that throughput was affected by two factors: Correction Time and Manual Entry. My first pass at a solution addressed those factors, but didn’t have as much impact as I had projected. I’m now going back to the well with new data and a new hypothesis. In this case, my research led me to believe that QA should be done before I start processing, and that manual entry could be further reduced. In fact, any manual entry is disruptive.

I gather my data, I shop it around with leadership, I make my case, I get my budget, and we go on to phase number two.

This Is The End, my friend.

So what did I do here? I let the business define the problem. I examine the problem in light of the data, and the I let the data lead to the solution. Finally, and most importantly, I let the solution lead the technology. And I kept everyone, including myself, honest throughout the project by providing plenty of sunlight.

Incidentally, in the real world case that this is based on, we saved the customer a measureable $13,000,000.00 for a $1.2 M engagement. Per year. This stuff works.

If you think about, this is exactly what BPM is all about. It’s about making informed decisions, guided by the business, and executed by technology. The technology, the vendor, the database and all of that are of secondary importance. The heart of the of the understanding the problem, and applying discipline to the process of fixing it.

Max Habibi
Author: Max HabibiWebsite:
Max Habibi is a Principal with Capital BPM. He previously ran large BPM/ODM practices for Avnet, Ascendant,and He is an alumni of Lombardi & Pega Systems, and specializes in helping organizations build better BPM& ODM practices. Max is a hands-on, working architect in the BPM/BRMS space, holds dual Master’s degrees from the Ohio State University in Abstract Mathematics and Computer Science, and is a Certified Six Sigma Black belt. He is the author our four books, including the best selling "Java Regular Expressions: Taming the java.util.regex Engine”.

blog comments powered by Disqus

More articles from this author