Deducing Causes of Variation from Patterns Within the Data

Much can be deduced from patterns that can seen within a stream of data.  Of particular interest to the problem solver are hints regarding WHERE variation originates and hints suggesting root-causes.

I will include a few data plots (simulated data) and throw a few words around them to illustrate my point.

Fairly random "Normal" distribution.

This pattern is sometimes nicknamed "racking pattern" due to the likely source.

This pattern shows mean shifts between populations that always number some multiple of X.  "X" is likely to be the number of parts in a rack.  In this case "X" equals 10, so the savvy engineer would investigate the parts that are delivered to the line in racks of 10.  If the populations were always in multiples of 14, then the engineer would investigate parts that arrived at the plant in racks of 14.

This pattern can be caught mathematically by using a sliding window, square-wave Fourier type transform.  By mathematically I mean through the use of an algorithm that can be applied without the benefit of human inspection.

This pattern was caused by a worker who would unload the last three parts of every rack onto the floor so the material guy could swap in a full rack of parts.  The parts on the floor splayed open.  The problem was solved by giving the operator three hooks to hold the parts as a temporary buffer during rack change-outs.

This pattern would also trigger the square-wave, Fourier type transform.

This pattern is nicknamed "turn table"

It is very common to have a turn-table that feeds into a robotic cell.  The operator loads parts onto the position that is exposed while the robot processes the parts held in the second set of tools.  Problems arise when the two sets of, supposedly, identical tools drift apart.

Another source of this pattern is when the stream of sub-assemblies is split apart and run down parallel paths and then reblended back into their original order.

This pattern can be caught mathematically by counting reversals.

This pattern repeated every shift.  It was due to flanges on two separate parts colliding.  The second piece would fall to one side of the first piece early in the shift.  Then as the shift progressed and the robot warmed up the thermal expansion of the robot arm caused the second piece to be dropped further away from the robot base.  The second piece started shingling on the other side of the first piece.  There was enough time between shifts for the robot to cool down causing the pattern to repeat.

The engineer solved the problem by repositioning the second piece so the two flanges did not try to occupy the same points in space, thus eliminating the positioning influence of the shingling.

Another variant on this mean shift pattern occurs when the dimensional engineer makes a shim move to a pin and the step does NOT occur...perhaps until much later.  The likely cause of this anomaly is wear of the blocks that grip or clamp the parts down prior to welding.  "Steps" wear in into the blocks that resist the part being positioned by the pin.   This is a problem because the trimmed edges of parts are often less closely controlled than the position of gauge holes.  Positioning, even if incidentally, using trim edges induces more common-cause variation into assemblies.

A business opportunity

It seems to me that automated test score analysis would be a high value-added enterprise for publishers of educational materials.

The publisher has a vested interest in making the purchasers of their products successful.  If that means winnowing through the data and suggesting that a small percentage of individual educators be evaluated for Time-on-Task or Push-teaching (based on patterns within the data) then that is a small price if it improves the delivery of education.