At 7:06 PM 8/1/96, Ben Compton wrote:
>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.
I agree the manufacturing model does not work well for software product or
service businesses. In either software or service, the final real product
is the first real product. (There's no notion of getting the first one
done right, and then following it up with making it for
manufacturability.) I disagree with your characterizations of
manufacturing, but that's a different discussion.
>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.
This is true, but how different is it from software development? (Maybe
I'm cynical here, but I think the requirements come from all over, and the
design effort must include lots of people. Even with a supposedly defined
process, not all the right people talk to each other at the right time.
Maybe I'm throwing you a red herring.)
>* 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.
The actual process is not precisely the same each time, but the overall
processes are quite similar. If you have a good help desk system,
integrated into your bug-tracking system, you can actually define the
first 3-4 steps of your process quite easily, and that should take care of
at least 80% of the problems. It's the other 20% that you need creativity
for.
>* 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.
I was going to suggest the number of creations and hits per day on your
database of knowledge. Maybe that's too simplistic.
>* 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.
You should graph this in relation to release shipment. I guarantee you
that the call rate goes up as the release is mass-shipped to the folks on
support, and then it levels off. Of course, you still need daily, weekly,
monthly call numbers, and time to resolve. But the more interesting
problems will show up closer to release shipment.
I always use to measure the ratio of doc problems to sw problems. That
gave me an idea of where the problems were in the software development
process, to cause doc problems.
>* 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. [...]
>Thus, in my opinion, the model is all wrong. We need to think completely
>different about knowledge work, [...]
You need to categorize the calls. Not every call is equal to every other.
It's not clear to me you have the technology you need to do the process
work you want to do. Are you working to develop the process before getting
the technology and upgrading staff skills?
Johanna
-- Rothman Consulting Group, Inc. URL:http://world.std.com/~jr/ voice:617-641-4046 fax:617-641-2764 jr@world.std.com Management Consulting for High Technology Product Development
Learning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>