A friend and colleague at Lombardi, Kalvin Stollznow wrote a post at Lombardi’s blog on Monday articulating the need to view the business and associated wastes and defects through the lens of a “process prism”. I certainly agree with Kalvin on this point. Especially where it concerns the insurance business, for at BP3 we have had a lot of experience in this area.

Kalvin discussed the power of Lean Six Sigma as a method to deal with the very thing that causes great angst in companies and that is the waste (aka Muda) and defects mentioned above. He moves on to bring light to the fact that these particular approaches may have been born from the world of manufacturing but absolutely are applicable and more importantly effective in transactional or service based businesses. This is a fact, and expanded or integrated into a company who views business process management as a true discipline then you have a truly remarkable organization who can retain and grow customers as if they were born to do it.  However, it does require “translating” some of the standard Lean Six examples out of the manufacturing world and understanding their analogs in the transactional and services world.

I will take what Kalvin was alluding to in his post and give an example from a financial services perspective of the things we do everyday that create waste and defects in our processes - and the key here is to be able to identify these things so that they can be managed. Let’s do this from ”The 7 Deadly Wastes” from Lean Six Sigma to examine this closer, in no particular order (although ‘Overproduction’ is considered the worst waste in Lean). I will go ahead and make it 8 and add rework as I believe it is very insidious but not officially declared in the initial 7 wastes-

1. Rework: Anytime you see a loop in a process, that is probably rework. Think of touching the same thing over and over again. For example, an invoice is sent to a member or group customer and the bill is wrong. Requests are made to change coverages, drop dependents, etc. The clock starts ticking for that request to be fulfilled. If the request cannot be fulfilled in time, the next bill will generate and it will be wrong again. rinse. repeat.  Customer satisfaction declines, and administrative costs go up.

2. Defects: An enrollment form with missing information or incorrect information; a bad requirement for that new claims handling system; a bad or “dirty” invoice from the rework example above, forms or applications with unclear instructions or usability. Defects are pretty easy to understand although I have heard businesses tell me “we don’t have defects, we have exceptions”. Whatever you want to call it is ok by me, but exceptions and defects both cost the business money.

3. Inventory: A backlog of policy change requests, a queue of contracts, or claims unprocessed, callers on hold, piles of forms and the like. Financial Services companies have a ton of “inventory”, just not in the way people normally think of it.  But it can have the same negative effects: clogging a process and creating or exposing bottlenecks in a hurry.

4. Waiting: Waiting for an approval on a claim, an expense reimbursement, an underwriting decision, 1/24 hour batching of data. Waiting promotes the clogging of processes, can create defects and cause rework.  When expensive specialists are waiting for a response or for work to hit their queue, the company is letting money walk out the door.

5. Processing: Or Overprocessing more specifically, such as an inordinate amount of approval steps to pay a claim or making sure a document is imaged and re-imaged over and over again. Basically doing more work than is absolutely necessary to delight the customer.

6. Motion: Constantly switching between screens and applications to get the policy change made, having to go out and find an archived image/document in the DMS or on a network share, keystrokes and clumsy navigation of systems. Running over to the printer constantly to get those TPS reports (couldn’t resist the last example, Office Space fans).

7. Transportation: Similar to rework and examples could be having to get physical signatures from across the campus, delivering and picking up paperwork from all over the place, delivering reports, etc.

8. Overproduction: Lean considers this the worst waste because it can often be the root cause of many other wastes listed and if you think about it we see this all the time. 100 reports when really 3-5 would do the trick, constant emailing, a requirements specification 300+ pages deep for a small to medium software project, print-outs of everything going to everyone, flooding queues with tasks just spit out from that batch processing which in turn causes the backlog to grow or at a minimum not shrink.

It all comes down to delivering goods and services to customers how they want it, when they want it, and at a price they want to pay. If any company, not just financial services, are not managing their business via a process view then it will be those companies who will not keep customers. Applying Lean Six can identify the causes of waste and defects, and then can help remedy the waste/defects with prescriptive solutions (perhaps more on the prescriptive side in a future post!). This comes down to pure physics and physics cannot be wished away. Manage the processes or they will manage you as the saying goes.

If your company has already ventured down this road you probably realize that standardizing processes, especially core business processes is in fact NOT easy. There are many reasons why this is a heck of a lot harder than one may think. Let’s start with the big question first – What do we mean by standardization and what is the real business objective in doing it (i.e. who is asking for it)? I have seen quite a few flavors of this over my career; most recently I spent the better part of a year working with a very large insurance company who wants to standardize their claims process across all of their products and regional markets.

When I asked “why standardize?” I received different answers from lots of different people. “We want to make the claims process cheaper and more efficient,” while another person said “We want to be able to centralize the processing of claims,” and yet another “We want the customer to have the same experience in their claims handling regardless of where they are or who they talk to.”  Are they all saying the same thing in different ways? Are these really the same objective? Perhaps, but I and a few others were not convinced. The implication of this question is huge as this will without a doubt dictate what approach will be needed to achieve the goal. Yes, it’s those details again that quite often nobody really wants to face but without them then the whole exercise is just academic and everyone can just standby for a journey that could take a decade to realize, all the while managing ongoing change as the business climate shifts (i.e. competition, regulations, new markets, etc.).
So what does “standardizing” really mean? If we look at the definition of standard and exclude “a grade of beef below good” as one of them, then we see “a basis for comparison; a reference point against which other things can be evaluated”. So said in more of the context of a business process, it is to achieve a baseline measurement and reference model for process performance. So this has less to do with centralizing a process and much more to do with achieving a consistent performance profile to meet customer and/or business requirements.

So then another big question hits home. Do we really need everyone to perform the tasks in the exact same way? Or can it be that we don’t really care how they do things at a procedural level as long as they consistently meet the needed SLA’s, thus making the measurement the real standard? Maybe think of the latter like a technical standard such as J2EE, as long as a software vendor can deliver the functions required that make it J2EE compliant, it doesn’t matter how they actually implemented it. And as we all know there are very big differences between J2EE products. That becomes yet another big question. At what level of a process, if you think in terms of value-streams, should be considered the standard and what can be tailored in any fashion just as long as it can deliver to the specified requirements?As you can see, this whole notion of process standardization creates some very big questions that any company pursuing this strategy will have to answer, and it is not easy. From experience I can tell you that achieving the benefit of standardization does NOT unequivocally equal everyone at all levels of a process doing things the same way.

In fact, that is usually why this work can get very, very hard. Rationalizing activities from an end-to-end standpoint without knowing quantifiably what the performance standard needs to be is a recipe for some major headaches. So maybe another way of approaching standardization is by backing in to it, such as we need to process x-type claims in 72 hours in all markets we serve. Focusing on it from a measurement standpoint is the best way to understand at what levels of a process and more importantly what are the few key activities at those levels which really need to be rationalized. Versus what I have seen so many times, a blanket objective of everyone who is involved in the process must do things the same way. If you are reading this post, then you have probably been in those meetings where you need everyone to agree on “how the process should work”, now multiply that effect by 100 when you begin talking standardizing across products and geographies.
Ironically, everyone agreeing and doing the same work doesn’t guarantee that the measured result will meet the standard, but that is often the implicit assumption in such endeavors…

Happy 4th of July everyone, and think about our armed forces today. Our deepest thanks go out to all of you.