New Technical Service Model LO8925

Ben Compton (BCOMPTON@novell.com)
Tue, 06 Aug 1996 20:30:25 -0600

Replying to LO8904 --

I appreciate the many responses, both public and private, to my post.
Several of you have pointed out that my model of manufacturing is
inaccurate. I have no reason to dispute that, as I've never studied nor
worked at a manufacturing plant. At the same time, the specifics of the
manufacturing model I painted are far less relevant to the problem as the
specifics of the technical service model.

Let me add a little context to the problem:

We've statistically analyzed the work we do so much that I could name off
almost any conceivable number you would ever want to know . . . what is
the average number of calls taken by each engineer per day? What is the
average call time? How many problem reports are solved within 5 minutes?
How many within 1 hour? How many within 8 hours? How many within 24 hours?
What percentage of problem reports are answered with a written technical
document that is disseminated to the public? How many actual software
defects per X number of problem reports?

We even track network failures, database failures, power outages, etc. and
how that impacted performance for a given day or week.

All these numbers are great. But they all have a few basic problems:

1) They're linear in nature, and do not accurately reveal/reflect the
hidden cause and effect structures at play (an issue of systems dynamics).

2) They cause systemic problems to emerge.

3) They don't measure the accuracy of the knowledge we replicate within
the department and to our customers.

A short explanation of each of these points:

The numbers (statistics) are linear in nature. They record events in
sequence. They do not show parallel events, nor do they reveal systemic
problems, such as the solution to one call being the source of another (A
cause B, B causing A, as Gene Bellinger would put it).

The measurements we have actually causes systemic problems, such as the
one just described where A causes B, and B causes A. The interesting thing
is that the solution to a problem may not cause another problem for
several months. Neither the customer nor the engineer is aware that
they're solving a self-created problem. I've battled this problem on many
fronts, and assiduously worked to help others see the "dynamic complexity"
behind the technology, so our solutions are permanent and do not come back
in the form of another problem.

(To this end, as an engineer, I developed a comprehensive simulation of
designing a Network and E-Mail system, which would demonstrate these
problems. It is the technical equivalent of Senge's Beer Game. It has been
a popular item for our customers, and I have facilitated the simulation
many, many times. I get several requests per week for the simulation from
our customers. It has definitely helped curb the number of incoming calls,
and reduced the stress of many network integrators.)

It is difficult to measure the accuracy of the knowledge being replicated
(I choose this word, because of how cells replicate -- mitosis -- and I
view knowledge replication to be the same thing: The replication of
accurate knowledge is critical to the long-term health of Novell. . .the
replication of inaccurate knowledge can cause a form of cancer that will
hurt our business). Cause and effect structures that emerge from the
replication of inaccurate knowledge are very difficult to track, and often
have a hidden and detrimental effect on our business.

And so while we have a thousand and one measurements, I still don't think
we're measuring the right things. And I think the measurements are causing
their own problems, as they reflect, more or less, an outdated model that
has no application to the information/knowledge era.

Hope that helps clarify what I was trying to say.

-- 

Benjamin B. Compton ("Ben") | email: bcompton@novell.com Novell, GroupWare Support Quality Manager | fax: (801) 222-6991

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