Went to American Society for Quality World conference in Milwaukee. Stayed at the Hyatt. Imagine my surprise when I went to take a shower and discovered that I had two conditioners, but no shampoo. Called and after a while someone delivered a handful of shampoo bottles. Next day I left a note for housekeeping to leave two coffee bags, but they only left one. Called for more, got a half dozen. Phone calls, Rework and interruptions.

Ate at the diner across the street from the Hyatt. Sat and waited and waited and waited. Finally the *cook* came out and took my order. No stars for that Yelp listing.

Whenever Cp is more than a third higher than Pp, it means the process isn’t stable. And a process has to be stable *before* you can do capability analysis. How do you check stability? With a Control Chart. Here’s the data in an XmR chart:

As you can see, the process runs at three different levels. I have found that any process shift, not matter how small will create out of control conditions that prohibit capability analysis. Pp and Ppk use standard deviation (distance from the mean). Cp and Cpk use the difference between parts to *estimate* standard deviation. When part-to-part variation is small, Cp/Cpk will get large.

Pp = (USL-LSL)/STDEV

Cp = (USL-LSL)/Sigma Estimator

The QI Macros will alert you to these issues, so you will need to go back and run a control chart to determine what’s going on. Then do some root cause analysis and correction to make the process stable.

In this case, the measurements need to go out to the 0.0001 decimal place to capture enough part to part variation to allow capability analysis.

Get the idea: First Stability then Capability

]]>

I find this is true in most companies. They collect tons of data, but can’t “winnow” the data down into the vital few bits of information that would transform their business. What I invariably do is use PivotTables, control charts and Pareto charts to find the “vital few” bits that tell us exactly where to find and fix the problems that cause over half of the waste, rework and lost profits.

It’s not hard, but few people seem to know how to do it. Learn more at www.lssyb.com.

]]>There was a 25% off coupon in my mailbox for my local Ace Hardware. But when I went to check out, the system wouldn’t accept my coupon. I had retrieve the flyer to prove the coupon was valid. Problem: rework, time 30 minutes plus driving. Root cause: Marketing not in sync with sales systems.

]]>As an IT guy, *Agile* is Lean applied to software development. I wrote a book about a similar methodology called Rapid Evolutionary Development back in 1989. Both are about rapid iteration to converge on a deliverable solution when “the problem is complex, solutions are initially unknown and product requirements will most likely change.”

In many ways, *Agile* is similar to the Lean Startup methodology: Build, Measure, Learn. We also find it in the OODA Loop (observe, orient, decide, act) developed by fighter pilot John Boyd. “Thinking about operating at a quicker tempo…engaging in activity that is so quick it is disorienting [that] inhibits the adversary’s ability to adapt. Whoever can handle the quickest rate of change is the one who survives.” Even *Systems Thinking* which argues that the company that learns faster than it’s competition wins. From these and other and other sources I think we can begin to consider that rapid learning, faster iteration and rapid prototyping are the key to *blitzscaling* a company.

Agile approaches to management have begun to spill over from IT into adjacent customer and management arenas.

*Agile* sounds more desirable than Lean, doesn’t it? Would you rather be agile or lean? Maybe this is a new way to approach implementing Lean or the Toyota Production System in a company. Rather than wall-to-wall, floor-to-ceiling implementations of Lean, start in IT and let the methods spill over into neighboring work units until it reaches a critical mass.

This is how cultures adopt, adapt or reject change. Might be worth a try.

*Boyd, The fighter pilot who changed the art of war*, by Robert Coram, Little Brown, 2002.

*Lean Startup*, Eric Ries, Crown Business, NY, 2011.

*Fifth Discipline Fieldbook*, Peter Senge, et. al., DoubleDay, 1994.

*Rapid Evolutionary Development,* Jay Arthur, Wiley, NY, 1989.

]]>

A car can still fit between the posts, but it’s much less likely to happen.

Then I noticed other applications of the same principle to gas and electric systems * behind storefronts*.

Not a bad idea, huh?

Many years ago I found that Excel users had a hard time selecting data that was separated by one or more columns. If you don’t select exactly the same number of rows, Excel balks. So I developed code to mistake-proof the selection of data, *even if you don’t select the same number of rows.*

I also found that people couldn’t remember what control chart to choose, so I created the Control Chart Wizard to mistake-proof selection of control charts.

What area of your business, products or services need some mistake-proofing?

]]>Write-offs are money, plain and simple. Money is variable (a.k.a. continuous or measured) data.

I explained that to her and suggested she stop worrying about what kind of distribution she has and just look at her data.

- Decimal data has to be variable/continuous/measured (e.g., 7.45, $27.95, 9.5%)

If you have a single column or row of decimal data use the XmR Chart. - Integer data can be attribute (defects) or variable (days). Examples: 12 defects or 12 days.

If it’s*time*, use the XmR Chart. - Integers with a Numerator/Denominator means that you will need either a
*p*or a*u*chart. Example: 2/100 widgets.

If the data is good/bad (binomial) use a*p*chart.

If you can have more than one defect per unit use a*u*chart.

If the denominator is a constant size, use an*np*chart.

You can also covert the numerator/denominator to a ratio (e.g., 2/100 = 0.02 = 2%) and plot it as an XmR Chart. I personally find it easier to explain an XmR chart to a management team than a*p*or*u*chart with varying control limits. They get lost in why the limits vary and stop looking at the data. - Integer data of unlikely events (e.g., injuries) would be a
*c chart*.

You don’t need to know anything about distributions to start drawing your first control charts. You just need to know if it is decimals or integers.

Let the QI Macros Control Chart Wizard to do this for you auomatically.

]]>My question is, why are you taking the class if you don’t intend to use what you’ve learned?

From a purely Lean perspective, unused training is waste:

- Waste of the company’s money
- Waste of the student’s time
- Waste of the instructor’s time

]]>

Failure Mode and Effects Analysis (FMEA) is designed to ferret out these kinds of problems in advance.

Failure Mode: Someone (adult or child) mistakes them for candy and eats one.

Effects: Vomiting and even death

Could this simple analysis have prevented this problem *before* it got to market? Maybe.

Learn more at www.qimacros.com/lean-six-sigma-articles/fmea/

]]>