You can't always get what you want
But if you try sometime, you get what you need
- Some old dudes
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.
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.
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:
- The Throughput of loan applications in the system
- 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 : 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.
- Identify the two or three KPIs that you really care about
- Compare what expected the KPIs to be with that they actually are. Then decompose the KPIs into specific drivers that lead to corrective actions.
- Score your findings
- 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 : 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.