I am responsible for developing a quality system for Novell's GroupWare
Technical Services. The first thing I did was start what I have coined an
"assumption luncheon" where I invite 18 people from the department, to a
lunch every day where we identify the assumptions we operate on every day.
This has proved beneficial. In fact, it has probably been more
enlightening to me than those who've attended, because I get to follow the
"whole" thread of dialogue instead of just one session. Through this
process, I believe I've identified a major assumption that is impeding
Novell's ability (along with many other software e vendors) from providing
the type of service their customers expect.
Here's the problem:
We're using a manufacturing model of business, and performance/quality
metrics to run a continually changing, knowledge-based business. It
doesn't work well.
What do I mean by that?
Here's how I see manufacturing (correct me if I'm wrong):
* When a product is being manufactured on an assembly line there is very
few sources of input -- all of which are identified and have their known
place.
* Those on the assembly line have very clearly defined, and often
repetitious, work processes. The input is constant, and the output is
constant.
* The product being manufactured is tangible, and therefore the quality is
easily measured. X number of widgets don't function properly -- or X
widgets have a problem with their locking mechanism, etc.
* Since the assembly of a product follows such repetitious processes, it
is easy to predict the capacity of an assembly line: X widgets per hour.
* Workers have very clear job descriptions. There is very little deviation
or variance in their work day.
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") | 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/>