Process Documentation (WAS: Disabling Print)

Subject: Process Documentation (WAS: Disabling Print)
From: "Murrell, Thomas" <TMurrell -at- alldata -dot- net>
To: TECHWR-L <TECHWR-L -at- LISTS -dot- RAYCOMM -dot- COM>
Date: Thu, 20 Jan 2000 13:13:18 -0500

Tim Altom write:

> Doc management is a case in point. For ISO 9000 to work, there has to be
> control, or at least tracking. Whenever formal controls are instituted,
> somebody's work slows down. Can't be helped. The alternative is to trust
> in
> chaos, and not every company can do that. Certainly an ISO 9000 company
> can't.
>
My experience is that the position being stated above misses the intent of
ISO 9000. It is not intended to be a control mechanism. It is purely a
documentation mechanism. ISO 9000 asks two questions: "What is your
process?" (that is, how do you do what you do?), and "How can you prove that
you follow this process?" It is the answer to this second question that
causes inefficiencies in processes.

Correctly developed processes follow a natural work flow. When you document
what you do--especially as opposed to what you should do or what you think
ought to be done--the process you've documented reflects reality: how things
get done, how product gets produced, how documentation gets produced to get
very specific.

Equally importantly, correctly developed processes are virtually
self-documenting. When processes are correctly developed nobody's work has
to slow down to demonstrate that the process is being followed. The
statistics are developed naturally from the process.

When you've identified an area where either work slows down to serve the
documentation of the process or people (the ones who follow the processes)
circumvent the process in order to get the work done, you have identified an
area ripe for process improvement.

If, in the original example that initiated this thread, the purpose of the
Documentation Department is to deliver documentation to users, and if that
is what the process is doing, extracting the proof required by ISO does not
necessarily mean you make people fill out a physical piece of paper and
deliver it to the department before they can have the documentation. (It
can mean that and apparently it does for the initiator of the thread, but it
doesn't have to.) You could have people fill out a form on the web site as
part of getting access to the site. The form is mailed to the record
keepers who can file it, print it, do whatever they need to pass the audit.
The users can then print whatever they want.

Even that can be a slowing down, though, which is why I suggested using
cookies to track site visitors. Whether they print or not, they have
received documentation from the site, and you have a record of it. And
nobody's work has been slowed down.

I'm sure there are even more creative ways to accomplish both your ISO and
your production needs, because I know there are people out there who are a
lot more creative than I am. What you need to do is seek out the solutions
you need.

I'm a big advocate of changing the process when it doesn't meet your needs.
And people will tell you by their actions whether or not your process meets
their needs.

Tom Murrell




Previous by Author: RE: Disabling Print
Next by Author: RE: HELP - css problems!
Previous by Thread: Re: soft keys vs. hard keys vs. programmable
Next by Thread: Re: Process Documentation (WAS: Disabling Print)


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads