New Technical Service Model LO8853

GaltJohn22@aol.com
Sat, 3 Aug 1996 16:22:05 -0400

Replying to LO8812 --

Benjamin B. Compton wrote with regard to technical services quality and
the major differences between what he is looking at and the way
manufacturing measures quality (I snipped the last half of his message,
below.)

Ben's thoughts, especially on the high number of variables, the high
variation in the process, etc. very much coincide with my own (as I'm sure
many of you were sick of hearing many moons ago). Ben's problem could
serve as a model for what we will face in the increasingly
customization-driven world of customized/high variability manufacturing.

Ben, in the discussion I refer to above, I proposed what we came to call
DECISION QUALITY as the appropriate measure(s).

It goes something like this:

Knowledge + Information + Number of disciplines applied
DQ =
-------------------------------------------------------
Time Taken To Decide - Act

We never fully consensed on how to measure each of the variables though I
would do it as a "delta" - "What we did -vs- what the problem required,
managing for a zero sum or slightly positive outcome.

I would welcome any dialog on or off list on this subject.

- Hal Popplewell

============ BEGIN SNIP ===========

Here's how I see technical services:

* In Technical Services there are many sources of input, and it is
difficult to identify each of those inputs. Work can literally come from
many directions, simultaneously.

* Processes are not repetitious. Many problem reports (customer's
reporting problems with the software) create entirely new processes. Often
a problem report will result in new knowledge -- both for the technical
engineer and the customer. Knowledge discovery is never the same twice,
especially when you're dealing with thousands of possible variables.

* It is difficult to measure the "knowledge" created and replicated
throughout the department, and to our customers. I can't touch knowledge,
and therefore have a hard time quantifying it, and an even harder time
quantifying it's quality. It is intangible, but it must be measured if
we're to have a meaningful quality system.

* Because of the variableness of the work done in technical services it is
difficult to predict call capacity -- how many customers can be helped per
day? Right now I think we help around 300 customers per day. . .but the
number fluctuates drastically from week to week.

* Technical Support Engineers have clearly defined expectations: Take
calls from customers, solve them as quickly as you can, and get on to the
next customer. The problem is that this attitude does not take into
account the time it takes to discover and replicate new knowledge, nor
does it take into account the variableness of the work we do. Thus it is
difficult to accurately predict call capacity, or even an optimum call
capacity.

Thus, in my opinion, the model is all wrong. We need to think completely
different about knowledge work, and stop trying to applying the model that
emerged from the industrial revolution to the knowledge/information
revolution.

Any comments, suggestions, ideas, or references? Those interested in the
work I do in solving this problem, let me know. . .I'd be glad to keep you
posted.
--
Benjamin B. Compton ("Ben") >>

============ END SNIP ===================

Good luck!

-- 

Hal Popplewell hep@itsy.com or GaltJohn22@aol.com

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