TQM encompassed by LO LO11054

Benjamin B. Compton (bcompton@geocities.com)
Mon, 18 Nov 1996 20:37:56 -0700

Replying to LO11030 --

> Katheryn writes:
>
> >I feel that TQM as a named strategy will (thankfully) ride off into
> >the setting sun as its best tenets become encompassed by the LO
> >philosophy.

To which John Farago writes:

> Dedication to continuous quality improvement linked with customer focus,
> which characterises 'TQM', needs to be underpinned by learning, but LO
> does not make TQM obsolete. Similarly BPR, much misused and derided, is
> not wrong when underpinned by learning culture, structures and systems.
> The main obstacles to continuous or radical improvement and change through
> learning are the mindsets and measures which prevent individuals and teams
> from diverting time and/or money from yesterday and today's objectives,
> targets and measures of success to thoughts and actions focused on
> creating a successful future.
>
> I realise that we have been around this loop before here on the list
> (Deming, etc.), but I would mourn TQM being consigned to history without a
> whimper.

A while back I sent a message about how many software/hardware companies
are using what I consider an outdated technical services model.
Nonetheless I applied for, and was hired, as a Quality Manager for Novell
in Novell Technical Services. Specifically, we were working toward ISO
9000 certification (I admit, ISO 9000 is not "TQM" but it is, at best, a
distant relative).

When I began the job here's what I was thinking:

We're in the business of providing customer service for Novell products
and customers. Our objective is simple: Provide a responsive, high-quality
experience for the customer without wasting company resources.

As I began this job, I sent a memo to the person I report to, explaining
what I thought continuous improvement meant for us:

"It is important to understand how we achieve this objective. In our
industry, customer service is a knowledge-based business. This means that
our competitiveness comes from our ability to create and replicate new
technical knowledge within our department and throughout Novell's reseller
channel.

"Thus the work we do comes in the form of thinking, reasoning, solving
problems, and making decisions that influence how our customers implement
our technology. While we have a number of tools to help us do this,
ultimately it is human intelligence and knowledge that allow us to achieve
our objective.

"And so for us continuous improvement (i.e. constantly improving our
ability to achieve our basic objective) primarily focuses on learning:
Learning to think about our business and our technology in new and better
ways, learning to reason more clearly, learning to solve complex problems
faster, and accepting the responsibility for making real-time decisions
about how a customer should use our technology as a solution to their
business problems."

I realized, before I even began, that ISO 9000 would do very little to
increase our performance. At best, it would minimize rework as customer
calls were escalated to our back-line support structure. Learning is not a
something that can be defined in a procedure (although learning can be
built into procedures); learning is something that occurs in a rather
unstructured and ad-hoc way. As we make new connections between known
concepts, add new concepts, link those new concepts to old concepts, we
then begin to learn and our body of knowledge grows. Thus, knowledge is
nothing more than a web of concepts with a whole lot of connections
between them. How we can identify those concepts, and connect them is not
something we can define in a procedure.

Our procedures are documented. People are religiously following them. And
our performance has not increased in any significant way. In fact, what I
discovered was a real irony. I described this irony is a memo I sent to my
department last week:

"Developing and following procedures makes us more consistent in our work.
But continuous improvement goes far beyond following formal procedures.

"Currently we measure number of incidents resolved, time between creation
and resolution, and number of incidents resolved that are tied to a TID,
etc.

"Two engineers may be very close to each other on these measurements. But
everyone knows that one of these engineers may be one of the best on the
floor, and the other may be one of the worst.

"Clearly, such measurements only tell part of the story. Two people may
follow the same procedure, and do it equally well, as far as the
measurements show, and still have radical differences in their technical
competence, and in the quality of their actual work."

In my world, continuous improvement is really more about learning than it
is about procedures, processes, and measurement systems.

Now for a terse ending to a rather long post:

The key to creating a learning environment (at Novell), in my mind, is to
help people understand that a concept is not the definition of an object.
Focus on concepts first, identify objects later. It works well.

-- 
Ben Compton
The Accidental Learning Group                  Work: (801) 222-6178
Improving Business through Science and Art     bcompton@geocities.com
http://www.e-ad.com/ben/BEN.HTM
 

Learning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>