Dear List,
I came into this discussion late. I hope I am not being
redundant.
We are an automotive manufacturing environment and rely heavily on
Corrective Action problem solving. I have been working with teams
on problem solving for at least 10 years and have come to some
conclusions based on observation.
There are two concepts that I think underline the foundation of
problem solving = (1) is a theory of Einsteins that "no problem
can be solved by the same consciousness that created it"; and
another theory (2).. (I do not know who to credit for this) that
"Everything is a process within a system. A process cannot work in
a systems that does not support it."
(1) I have found that a large majority of problems were
anticipated in the design stage...i.e. = I hear engineers say,
"Wow this will be hard to manufacture"..yet, they still release
the process to production and 'lo and behold' it is hard to
manufacture, resulting in defective product and requiring
corrective action. - This amazes me. We knowing go into a process
anticipating problems and when the problem does occur we [pretend]
to be baffled.
I have also found that in the planning stage - most teams do the
easy part of planning. In other words they plan the big 80% and
call it done! - THe last 20% they assume will take care of itself.
Unfortunately the first 80 % anyone one with some level of
reasoning ability could have planned. The last 20% is mostly the
anticipation and planning for training, coordination, timeline,
implementation steps, skill assesment, and last but not at all
least - what is the plan when the plan fails.
When most teams plan the first 80 they sigh a sigh of relief and
call it a plan - the last 80% they don't want to address...their
reasoning is that it is getting too detailed, or that it should be
obvious, or requires common sense. An oversimplified version of
the 80% I see being planned is the WHO< WHAT< WHERE<and WHEN.
The last 20 is usually HOW and WHY.
I agree that a solution to a problem is a process of asking all
the right questions - to change the consciousness. New
information should change the consciousness of those who
originally created the problem. Planners seldom realize that the
problem is not a GIVEN...the problem is something that THEY
CREATED. For most plans that fail - I require the planning team
to review the process after implementation and discover both what
worked and what failed. Once they realize that the last 20% will
be addressed and the burdon will still be on them - the hope is
that they will chose to work on the 20% up front and not down
stream where it is more difficult to repair and the cost/loss is
more significant.
A problem solving process should be a process of collecting data
and information...supporting another of Einsteins quotes:"Finding
the solution to a problem is a series of asking the right
questions." This has proven itself over and over. I encourage
teams to ask, ask, ask...and collect data. Once the process of
asking questions 'discovers' the solution, we are done. I
discourage teams from throwing out corrections and solutions not
discovered through the questioning process - because a correction
or solution found, but not through questions - was not arrived at
through a new level of 'consciousness' and therefore not
supportive of a correction.
(2) Everything is a process within a system. I have found that
all problems need to be corrected at two levels- within the
process itself and within the system that is intended to support
it. I think that the second biggest issue with problem solving is
that systems issues are not addressed.
One way to explain the difference between a process and a system:
If the car is a process - the road [and all of the rules
associated] is the system. SO, you can take the 5M's Man,
Machine, Material, Method, Measurements and apply it to the
automobile - Man is the driver, machine is the car, method is the
drivers training, material is gas/oil, and measurement is the
odometer, gas gauge,etc. - and have all of those working and in
fine form and still have a process failure if you put that process
into a system that doesn't support it...i.e. the OCEAN.
Drop a car in the ocean and I don't care how well trained the
driver is, how well tuned the car is, how high quality the gas and
oil is...it plum won't work.
No matter what process you design and no matter how well...if you
don't look at your system that the process will be encased
in...you have not done all of the planning.
Biggest mistakes I have seen in my experience regarding good
process plans and poor systems -
Putting a process in place that requires training - in an
organization where training is not valued, planned or executed
well.
Putting processes in place that require extensive communication in
a system where people dislike and mistrust each other.
Putting processes in place that are specific to the behavior of
one shift - when the system has each shift behaving with
completely different sets of rules.
And last but not least - putting processes in place that disrupt
or go against other processes that have opposing goals...i.e.
putting a quality process in place that stops the shipment of
defective material within a manufacturing system that values
'getting it on the truck' as the highest priority.
Thanks for letting me sound off.
Rick Corcoran
corcoranre@excelinc.com