DEN Discussion List Archive

[Date Prev][Date Next][Date Index] [Thread Index] [Author Index]

Re: Web-based, enterprise-wide, SPC-based performance improvement



Others may have differing opinions, but I do not favor automated charting
except in certain circumstances.

Anyone who has spent a lot of time charting or otherwise handling data by
hand realizes that one gets a 'sense' of the data.  Strange values, subtle
trends and patterns, unusual values from rounding, etc., can all be detected
by a person plotting that are not usually detected by a person simply
entering data in to a computer.  This problem is exacerbated if the entry is
also automated.

There is not widespread agreement even in published works about a standard
approach to setting limits, charting and interpretation of charts.  That
diversity will be reflected in the software used to do the analysis and,
once, written, such software is difficult to change.  Measurement studies
often required differing arrangements of the same data to reveal fully what
the measurement process is doing.  Will this be possible?  Of course it is
simple to do by hand.

Generally data is entered on a chart one value at a time.  This does not
seem burdensome.  Moreover, it reinforces the notion that monitoring and
assessing the quality of a process is part of the job.  Automating it would
give it a status less worthy than is needed.  In effect it relegates
charting to drudgery and treats as ancillary to the 'real' job.

Finally as process is brought under control and become more and more
capable, the need for hi levels of charting activities begins to decrease.
As Jeff Liker points out in The Toyota Way, Toyota does not use a lot of
charting.  I'm convinced that is due to the pervasive use of charts earlier
in Toyota's history.

 As Toyota's operating philosophy of continuing improvement played out,
processes became so capable that routine monitoring was not needed and the
charting activity gave way to more emphasis on lean thinking.  Like
automation, lean thinking operates a lot more effectively with capable
processes.  

So why invest a lot of time and capital in a system that won't be needed in
five years (if the job is continuous improvement)?





DEN Home | Main Index | Thread Index | Author Index