ebizQ has a two part series on BPM and Lean – something we’ve written about in the past and our own Lance Gibbs is a proponent of:

Lean is actually a process of experimentation, rapid iterative cycles of learning and testing, where the next step, the next future state, is a hypothesis waiting to be tested before it is adopted. This is significantly different from implementation, where you select a “known” target state and budget time and resources to achieve it. Many traditional IT budgeting and governance processes resist this incremental, experimental approach – it feels risky and uncertain. But the reason so many projects disappoint is that it is impossible to truly know what the final end state will be.

Exactly – it isn’t about the end-state, it is about the journey.  Very appropriate for the BPM mindset.  The first part hits on a few other key points as well, including the idea that Lean is not just about cost-cutting (which sounds familiar to the BPM advocates out there).

I was surprised to run across this article from EMC/Documentum. It is a pretty thoughtful post about Process Improvement methodology and BPM.  It starts with a pretty good background proposition to set the tone:

BPM and PI share a common definition of the concept of process—“activities or tasks that produce a specific service or product for customers”—but from this common ground, their interests can go off in separate directions. In the ideal situation, they are synergistic, with an analytic, data-driven PI methodology identifying and building a sound business case for a BPM application while enabling a continuous improvement cycle driven by BPM transaction data. But it’s also possible for the methodologies to ignore each other’s roles or, worse, disparage each other’s value. This article examines the interaction for both synergies and contradictions.

Followed by a quick summary of origins, pinning process improvement’s history as far back as Henry Ford, with modern manifestations in TQM, Six Sigma, Lean, and Operational Excellence.  Whereas BPM’s origins are in IT, with a background in workflow, SOA, enterprise resource planning, and BI.

Its a pretty good read, overall, especially if you aren’t already familiar with BPM.  The conclusion I find especially interesting:

So, why are we not more aware of the successes of a combined PI–BPM approach? Reviewing articles and blogs on the BPM side, there seems to be a developing interest (or at least an awareness) of sharing the process space with PI and an interest in learning how the methodology can add to BPM’s value. This is especially true among BAs who are responsible for understanding process and process design. Discussion of the value of PI training and certification is common. This interest may be a leading indicator of change, but for the present, much of this thinking is lost in the push for software delivery—“It’s out of scope,” or “We have to get this done now; we’ll fix it later.”

In contrast, PI practitioners are more or less ignorant of BPM’s capabilities; at best, BPM is thought of as workflow. PI’s origins on the factory floor and its tradition of small, simple, incremental improvements sometimes do not translate easily to a complex back-office or case-management environment. Although basic principles of flow, pull, and stability remain the same, a literal U-shaped work cell may not be the answer; an understanding of its BPM equivalent may be. Disdain for or ignorance of software solutions—even a handoff of requirements—will not produce optimum future-state designs. Knowledge of BPM capabilities should be in the PI practitioner’s toolkit right along side Minitab and kanban cards.

At BP3, we’ve noticed the same opportunity, and the same disconnect – PI practitioners are often ignorant of BPM, or dismissive of any technology-enabled process improvement (despite the fact that they do use their own software tools to help do PI work…). At BP3 we look for opportunities to apply PI to our BPM projects, its almost a free boost to ROI (it requires minimal extra investment and yields better returns).

“Successful Failure” has been used to coin the events which unfolded for the Apollo 13 mission. The failure was that the mission did not meet its original objective to land on the moon and return but rather met a more urgent objective which was to successfully deliver home the astronauts who were caught up in a series of unexpected and violently changing situations.

During the course of BPM delivery, and if a company is open-minded enough they can actually benefit from a failure. Now to be clear, I am not suggesting that every endeavor should automatically be assumed to fail or for that matter even the planning for failure is not something anyone would really want to do. Risk mitigation, yes of course but what I am referring too is a willingness to change a plan if the business value interests aren’t completely aligned with that initial plan. Things happen on a project and sometimes even a perceived negative situation can be capitalized on and may actually yield a better overall outcome than that original improvement roadmap. For example, when you are finding yourself looking at a process and subsequent solution requirements and they have stagnated. Stagnation of solution requirements is extremely common. Perhaps those requirements were developed months and months ago (or even longer), or similarly developed in isolation of the true voice of customer/voice of business. If you approach this purely from a plan-driven approach your failure scenario is high pure and simple. And achieving that failure may be the best thing to happen on that project because it opens the door to re-adjust and go after the more immediate business-value aspects of the solution; the here and now, not the how it was. As a result, you likely just saved a ton of capital by avoiding the ongoing support for a solution that was at best dead on arrival, and at worst just added to the overall process problems.

In a Lean-Agile delivery approach the notion of “failing fast” and being business-value driven over plan-driven are extremely important in these scenarios. Business-value driven simply means that during delivery you are willing to put the true needs of the business first, those solution requirements that will actually move the performance needle and not generating assets just because they may have been written down in a plan once upon a time. In essence, separating the wheat from the chaff.

For Apollo 13, as much as solutions were needed to the various problems, solutions had to be identified quickly in the face of the many unknowns that the mission was faced with. To do so the team needed to “fail-fast”, meaning that the capability to perform quick failure assessments and prevent re-occurrence is equal to the value of identifying a solution. Simply stated, do everything you can to get the real problems you are going to face identified up front. For companies new to BPM and its Agile software delivery tenets no matter how rock solid you believe your plan to be the teams will be undoubtedly faced with unexpected challenges. Getting too far ahead of the risk aversion curve by trying to engineer for every possible corner case everyday is fruitless, expensive, and ultimately useless. Reason being is that in doing so you will create more mass in the project than what can literally be propelled off the ground; more mass requires more energy and will ultimately result in inertia. The last thing anyone would want to have on their delivery project is a vast, never ending source of mitigations and controls based on theory or even meta-theory. An organization needs to have courage to move into and stay in a delivery mode versus discussing what delivery may or may not mean for a project academically.

What is required in delivery is proportionality and pragmatism in order to achieve the mission objective. In Lean-Agile, which happens to be the method of choice for us at BP3 in delivering BPM solutions, there are just a few simple staple items all of which are based on delivering business value as soon as possible. When we talk about what is value we talk in terms of a working solution over the documentation of a solution, collaboration over negotiation, flexibility being valued over rigidity as examples. The reason we value this is because it brings everyone closer to seeing a successful outcome by bringing risk and unknowns forward to deal with immediately.

In Lean, something which is considered Value-Added must pass three discrete tests:

1. The customer would be willing to pay for it
2. Done right the first time
3. Physically transforms the output; increasing its value

If you took the same philosophy to dealing with failures which occur on projects today then its pretty evident that there is a tremendous value in being able to identify and resolve issues quickly.

Value-Added Failure

1. The mission/project/program would be willing to pay to prevent or remediate issue
2. Identified and resolved early
3. The outcome increases efficiency, effectiveness, and business value of the ultimate solution

Again, in order to truly realize the value of putting your undiscovered troubles behind you quickly you have to begin by acting, doing something that provides the opportunity of discovery versus avoiding the journey all together. So if your going to have a failure, set yourselves up to do it quick and unequivocally.

Interesting article in the MIT Sloan Review on “Where Process-Improvement Projects Go Wrong“.  It compares process improvement projects to the behavior of a metal spring, by dividing into three phases:

1. Stretching – at the beginning, a small team is motivated to succeed, and has support of executives.  A six sigma or process improvement coach helps them navigate some of the harder issues to make sure they stay on target and achieve early success, which causes additional initiatives to be kicked off.
2. Yielding – As the process improvement coach is removed, teams begin to revert back to prior behavior, or lose the ability to get the team objectively past some of the harder sticking points.  Executive attention, and perhaps some of the best team members, has moved to other projects.  Performance starts to retreat, though not necessarily to pre-improvement levels.
3. Failing – the vicious cycle begins “With the improvement expert long gone and no additional training in Six Sigma or other improvement strategies provided by the aerospace company, team members became increasingly discouraged by their failure to build on earlier success. They eventually stopped caring about the improvement project, partly because it wasn’t tied to their performance reviews.”

Well, I feel motivated, how about you? Luckily we are not springs, we’re people, and we can be a bit more creative about avoiding this inglorious “failing” phase than the author imagines.

The article author proposes 4 lessons learned from the many companies they studied for this report:

1. Keep the improvement expert around longer – or share this expert among more than one team to spread the cost – but the recommended term was 2 years, augmented by training managers to pick up these responsibilities.
2. Performance appraisals tied to improvement.
3. Keep teams small (less than 10).
4. Executives need to directly participate in the projects, not just receive reports from someone who has incentive to focus on only the good news.

This isn’t bad advice, it is good advice to start.  But it is insufficient and unlikely to cause organizations to suddenly get higher success rates with process improvement.

What did they miss?  Well, they missed BPM, is what they missed.  One of the reasons BPM is a “killer app” for process improvement is that when you discover the most effective changes to make for your process, you can put them into software, not just into a book of Standard Operating Procedures that your team will quickly forget about.  And your improvements aren’t just things that people on the team learn and practice, nor just things that they pass on to others on adjacent teams – they are things that get encoded into your process.  The software gives you:

• Some resistance to the “yielding” phenomenon described in the study results.
• Accurate measurement over time – no dependence on manual measurement techniques that may degrade as team members lose interest in the stop watch and other manual measurement techniques.
• The ability to “bake in” an improvement and move on to the next thing, rather than get stuck in a high-cost maintenance of the first improvement.
• A “control” baked into the software.  (Six Sigma has standard approach called DMAIC – define, measure, analyze, improve, control… and BPM software directly addresses D, M, and C, and supports the A and I activities…)  So often the “failing” phase is because the organization loses focus.  Software doesn’t lose focus – it just keeps running.

Too often, the proponents of Lean and Six Sigma ignore technology because they view it as an impediment, failing to understand that there is more to technology than MiniTab or SAS/SPSS or Excel.  And if technology allows you to do something at lower cost, such as a process improvement project, or maintaining an improvement over time, then it shouldn’t be dismissed out of hand.  But it is easy to understand why they sometimes see tech as an impediment – deploying software takes time – and during the initial phases of improvement the improvement guys just want to move fast.  My take is – don’t let the tech get in the way, but don’t pretend it can’t dramatically improve the efficiency of your business – in fact, technology, and specifically BPM software, is likely the key to locking in the gains you seek to establish a “new normal” that is a more efficient and effective process.

The BTF09 Event can be summarized in one word, literally:  LEAN.

I have to hand it to Forrester, someone decided Lean was the message of the day, and they have delivered that message consistently.  You can find the feed on Twitter here.  To  make it easier, use this link instead to see the lean references along with #BTF09.

A quick review of Sandy Kemsley’s write-ups of sessions yields the following topics that refer to Lean:

• Why Lean is the new business technology imperative
• Lean and the CIO
• The Power of Lean IT
• Embrace Lean thinking to enable innovation
• How can Lean Software Enable you to Better Serve the Business?
• Can packaged Applications ever be Lean?
• Forge your Lean process improvement gameplan
• Lean application development strategies.

There was even a UX design session where the presenter made the argument that UX design is “Lean”.

Someone should have tweeted that all this tweeting isn’t very “Lean”…   And I guess no one had the discussion about whether attending a conference is “Lean”… Which is precisely why we shouldn’t try to apply the word “Lean” as Good and “not-Lean” as Bad.  Not everything we do that has value is “Lean” – something I am acutely aware of having had to read “Pigeon Wants a Puppy” to my daughter twice the other night.  It wasn’t Lean, but it had a lot of value!

There is a sense from reading all the traffic on twitter and blog posts that Lean is good and Not-Lean is bad.  Honestly, I don’t care if “SalesForce” (insert favorite SaaS product) is Lean, but I do care if my “Sales Process” is Lean.  And even more than that, I care if it produces reliable revenue streams at reliable cost outlays.

I don’t care if a COTS (Commercial Off-The-Shelf) Software package is lean vs. custom-coding being lean – I want the solution that solves my business problem with minimal cost and maximum fit for purpose, and I care that the processes that require this software solution continue to operate “efficiently”.  More simply – whether my car was constructed in a Lean fashion or not, how I use a vehicle in my business may prove to be Lean (or not).  The car at the point that I care about it, is already a finished product and I take it or leave it largely as-is.

To the extent that the point of Lean is to eliminate waste, you can almost characterize anything that eliminates waste as Lean – but that misses the point of using Lean as a process improvement method.  And Let’s not forget that you’ll still need other tools in your utility belt – six sigma for identifying and eliminating defects and variance, software for maintaining a good solution over time, and leadership to get your project over the finish line in challenging times.

Taking a step back, we have to remember that Lean is a means to an end, not the End itself.

All too often I see conclusions based on observable data, where the conclusion does not necessarily follow the data presented.  This doesn’t mean that the conclusion is wrong on the face of it, but that it can’t be made based on the facts presented thus far.  Sometimes the conclusion is presented as causal when it is only correlated, sometimes it is extrapolating from a really small sample to describe the whole population (over generalizing).

I recently read Theo Priestley’s post on why Six Sigma doesn’t work in the real world.  In it, he relates a LinkedIn posting from someone attempting to do six sigma analysis on a call center process.  From reading the LinkedIn posting, it is clear that the person posting is not experienced in Six Sigma or other  related process improvement technologies that would be helpful to the cause.  This person is trying to figure out how to get a bell curve from a formula related to rate of defects in the call center process, where a defect is defined as a call response being over 60 seconds.  Theo extrapolates from this that it is an example of why Six Sigma doesn’t work in the real world, and why black belts are not needed (all that is really needed, he says, is a pragmatic approach).  And he quotes a response he advocates:

“…at the end of the day if you produce a bell curve telling me the USL and LSL for my call centre, along with the number of defects per million and a sigma value of 1.727, is this really a useful measure? More to the point, what can I – as a business person – do with it?”

Well, look. The response (quoted) asks the right question – is this a really useful measure, and what can I, as a business person, do with it?  In other words, are you wasting our time trying to figure this out in the first place?

But here’s the rub.  A good Six Sigma practitioner would not need to post to linkedIn (hardly the font of six sigma knowledge in the first place) to ask how to plot a bell curve to show USL and LSL.  So the poster hardly represents the “failure of Six Sigma in the real world”.  And a good six sigma practitioner could tell the respondent quite nicely:

If we can plot the response times of your call center, we can understand whether the process is “in control” or not – by which we mean, is it predictable and does it vary in a “normal” way from the median behavior.  If it *is* in control, then we can endeavor to improve the process by decreasing overall response time if too great a percentage of responses are exceeding your 60s window.  However, if your process is *not* under control, then this means that there are one or more special cause conditions causing the process to be more volatile. Therefore your first effort has to be on stabilization before you effectively focus on ratcheting down the long-term variation (i.e. drop the average of the process down as a whole).

Not that Six Sigma is the only tool available.  Lean has several tools that are well suited for call-center style efficiencies, and so does 5s (the Japanese concepts of organizing the workplace to keep things consistent and orderly in order to keep the process consistent as well) and keep in mind just like BPM, Six Sigma is continuously evolving with new tools and techniques and while the statistics is certainly an important part it’s not the alpha-omega that many who haven’t learned Six Sigma believe it to be; certainly not the Six Sigma of the 1980′s.

My problem with the post:  using one example of someone struggling with the concept of Six Sigma, to challenge the whole notion of using Six Sigma – a bit like challenging the concept of a 100-meter dash after watching me run it, instead of Carl Lewis – at least look at how experts apply the techniques!  Six Sigma is not a religion (or at least it doesn’t have to be!)- it is simply a set of tools that can be used to pragmatically improve your process by focusing on unemotional data rather than exposition based on anecdotes.  Not all the tools are even statistical, which was a surprise to me when I first studied material at the green belt level -but even those tools are very practical process improvement tools.  The biggest problem with Six Sigma in the past has been the C in the DMAIC moniker (Define, Measure, Analyze, Improve, Control).  BPM really helps address C by putting the controls in software (call center software can help with this as well), and it helps with the M by helping measure the process even when no Six Sigma blackbelts are paying attention.  This makes it a lot easier for them to drop in, interpret the data, and devise new improvements based on the data, rather than spending so much time collecting hand measurements.

Here’s a great post by Jason Cohen (of Smart Bear software) that illustrates that humans are terrible at making gut decisions that can be disproved with statistics, and how to help yourself avoid sample size errors at least when dealing with A/B tests (as in, which is better, A or B?).  Better yet, it has a cute video of Hammy the Hamster to assist.  It cuts to the point about how much data you need to get a reasonable sample size to draw conclusions, and I think it makes clear why data sets of less than 10 are just generally problematic.  Um, also, there are formulas involved, so if you don’t put much faith in mathematics, Mr. Cohen’s article may not be much comfort to you, but I promise the math required to evaluate your sample size will be easy to do!

In my view, the real problem with applying Six Sigma is usually people.  Turns out it takes skill and  judgment to apply Six Sigma tools in a way that helps the business answer questions the business cares about.  This isn’t that much different than the kind of challenge one confronts getting a business to adopt BPM, or a software package.  Let’s not condemn a whole professional practice with proven successes just because we have one example of someone who doesn’t understand how to apply it (or even 10 examples of such people).

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.