Process for the Enterprise » six sigma

Understanding Failure of the Process Kind

Scott Francis — Fri, 04 Nov 2011 03:15:40 +0000

Jacob Ukelson posted about preventing failure vs. fixing failure. He make a few good points and along the way once again compares ACM / BPM by implication. In a sense, many will argue, ACM is about learning from failure, and BPM about preventing failure:

One of the key reasons companies deploy a BPM suite is to prevent failure. This is a major selling point for many BPM solutions. A key goal of a BPM suite is to enable the deployment of process driven solutions that prevent a deployed process from failing.

But of course, as he points out later, it isn’t always cheaper to prevent failure rather than fix it. ( Not to mention, in some businesses, fixing it is an opportunity to delight the customer. ) This is the crux of it: the arguments about failure are talking past each other. Process Improvement (BPM) should aim to reduce preventable failures of a fairly routine nature. Data entry errors, for example. Logical inconsistencies. This isn’t the primary or only goal, but it certainly is one important form of process improvement for many processes out there. But the idea that we should learn from failure isn’t exactly a new one either… Max Pucher’s blog is an excellent example of this concept in the 70′s and 80′s. The Lean Startup is an excellent example from the startup world.

If you’re familiar with six sigma technique (a fairly mature method that predates my professional career), then you’re likely familiar with the Failure Mode and Effects Analysis (FMEA). In it, you rate possible or anticipated failures by:

Severity – how bad will it be if it happens?
Frequency – how likely or how often is it to happen?
Detectability – how easy and reliable is the detection of the failure (or pre-detection).

Different remedies apply to the failures depending on their characteristics. Often this is applied at a pretty tactical level. But conceptually you can apply it at a macro or management level. Such aphorisms as “worry about what you can control, not what you can’t” and “prepare for the worst hope for the best” are perhaps simplified examples of this kind of thinking. Much business advice could be reduced to focusing on what matters and letting go of what doesn’t. Some failures don’t warrant preventative treatment, and some do. This isn’t exactly a new idea.

The kind of “preventing failure” behaviors that ACM folks are pushing against are mostly organizational or cultural in nature rather than procedural. It isn’t like BPM proponents are advocating that businesses circle the wagons and just focus on preventing failures.

So in summary - where you want to play it safe deploy a process solution focused on managing structured processes, if you need agility (and are willing to accept its associated risk) then you should focus on “first fault problem resolution” for your unstructured processes – rather than try to structure them to prevent failure.

This isn’t as easy as it sounds for some businesses. Let’s talk the First Horizon oil spill disaster in the Gulf of Mexico. Did they need agility or preventing failure out there on the platform? And which situation did their decision-making process most resemble? (Given that individual operators could and would override long-established safety protocol, I think we can infer that they were on the side of more agility vs. more preventative). Other businesses, and other situations, would have a different profile and tolerance for various kinds of failure.

If you’re going to have agility and learn from failure, don’t forget one other thing. You need really good leadership. If you don’t have that, the results of failure might surprise you.

HBR and Process Improvement Culture

Scott Francis — Fri, 12 Nov 2010 19:57:21 +0000

The Harvard Business Review recently covered Process Improvement, and considers the question of why it is so hard for companies to maintain their process improvement culture after a prominent leader departs. The primary example is Allied Signal and Larry Bossidy:

Consider the story of Allied Signal. Under Larry Bossidy, Allied Signal was a “poster child” of process improvement success following the “Six Sigma” approach — enjoying consistent growth in earnings and cash flow from 1991 to 1999, highlighted by 31 consecutive quarters of earnings-per-share growth of 13% or more, and tripled operating margins to almost 15 percent. Bossidy wrote a best-selling book, called Execution, about his approach. Yet when Allied Signal merged with Honeywell in 1999 and Bossidy departed in 2000 and was replaced by Mike Bonsignore, they dropped their Six Sigma attention while focusing on a GE-Honeywell deal. According to market analyst Cliff Ransom, “It took about 18 months for a Six Sigma culture to essentially disappear when the wrong successor to Larry Bossidy took the reins.”

This is a cautionary tale to me about the problem with doing process improvement only as a human endeavor. We need technology to support our process improvement efforts, to sustain the improvements we’ve made when people retire or turnover or move on to other opportunities. As the author states:

As the Allied Signal and Wiremold stories demonstrate, there are significant potential business benefits from adopting a process improvement program, yet despite these apparent benefits, they weren’t enough to build process improvement into Allied Signal’s or Wiremold’s DNA. What are the factors that get in the way of continuous improvement?

I remember reading about Allied Signal and GE in the 90′s, and reading about how much they focused on Six Sigma and process improvement generally. There are clearly benefits – but there are challenges in making these things part of a company’s DNA rather than just a yearly objective or review element. To me, this is a bit like the difference between making customer satisfaction a yearly goal (you know who you are), versus making it a core tenet of the company itself (Zappos). In a bigger organization, obviously a key element of this is to make sure your lieutenants are not just paying lip service to process improvement and customer satisfaction, but actually believe in it. It also means making sure that you have local leadership that believes in process improvement – and will do it even without the support of upper management. Finally, you have to put systems in place to support process improvement efforts – these systems act as a bit of grease on the wheels of process improvement budgeting and planning cycles.

EMC: Role of Process Improvement Methodology in BPM

Scott Francis — Thu, 04 Nov 2010 04:38:57 +0000

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).

Looking Behind The Curtain

Scott Francis — Sat, 17 Apr 2010 20:02:45 +0000

Neil Ward-Dutton has a great post about BPM vendor results that moves into a discussion of process improvement approaches:

The distinction between “old school” and “new wave” process improvement approaches (I’ve called these “high church” and “low church” before) is just continuing to get stronger. 10 years ago, the vast bulk of process improvement activity used to be driven by the “high church” crowd: lots of ceremony, burning of incense, and so on. Scientific improvement efforts driven by highly-qualified specialists are essential in situations where there’s a lot at stake (for example when you’re reengineering an auto manufacturing line: get it wrong and it’s going to cost you a lot to put it right). And don’t get me wrong: there’s definitely a place for this.

This description and the ensuing thoughts reminded me of our early experiences with BPM at Lombardi. Lance and I (and others at Lombardi) were often running into process improvement experts with a grounding in Six Sigma or Lean (or less often, IDS Scheer, or Enterprise Architecture modeling). We were sometimes supported by these folks, and sometimes they resisted our approach (and “BPM” in general). On the whole, there was a lot of resistance, as our approach to process improvement was somewhat heretical.

So Lance (now CEO of BP3), embarked on a journey to get behind the curtain, to understand the vestments of the Six Sigma and process improvement community so that we could better work with these folks. After going through the first rounds of training at the Green Belt level, he started to get others of us to go through the training as well. And what we found was that you didn’t have to adopt the religion of Six Sigma to get the value. The statistical tools are just that : great tools you can use. The “high church” trappings are wholly unnecessary but they do create an aura of authority for those who exercise them. Lance went on to become a certified Master Black Belt, but we continued to apply what we learned from Six Sigma in an eminently practical way. The point isn’t to be “pure” – the point is to get to value faster. If statistics can do that for your business, then you use them. In our mind, if a BPMS can do that for your business, then you use it. Make the best of the tools at your disposal to get the maximum benefit.

Still, there are those whose self-interest is aligned with keeping the “high church” ceremonies and orthodoxy firmly in place. The challenge is to keep it in perspective – scientific approaches can inform the “new wave” way of thinking without slowing things down.

One of the ironies now is that some of the newer entrants to the Business Process space now see BPM as the high church (old school) and their own approach as the new wave.

Sloan Review on Process Improvement

Scott Francis — Thu, 11 Feb 2010 14:55:59 +0000

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:

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.
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.
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:

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.
Performance appraisals tied to improvement.
Keep teams small (less than 10).
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.

Statistical Significance of Observable Data

Scott Francis — Mon, 27 Apr 2009 15:31:29 +0000

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).