From: "Edwin"
I've watched this thread with considerable interest.
Some responses:

SECURITY
The best way to secure documents over the Intranet is with network facilities: either using your web server's security features, or restricting write access to the directories in which the documents are filed. We try not to use Word documents: HTML and PDF formats are much smaller and create consequently less network traffic. The rule is: if it's only going to be accessed on-line, use HTML; if it's also going to be printed, use PDF.

EDITING
With HTML software so easy to use, it's easiest to convert the files into HTML, and when satisfied, delete the Word files: that way, you only have one version of the file (therefore no version conflicts), and any links you create in the HTML file aren't lost on re-exporting from Word. Don't, for heaven's sake, use Word to edit the HTML files: it's a dog of an HTML editor and produces the worst HTML imaginable. PDF is not an editable format, so any editing must be done in Word, and then the final document exported into Acrobat and bookmarks added, if required.

APPROVALS
The simplest method of ensuring appropriate approval is to discipline the posting process by restricting write access to the directories to those responsible for the document. Then, when the document is altered, if the revised document is online, it can only be because it has been posted (i.e., authorised) by the responsible person). Control is by the logic of the process, not elaborate digital signatures or similar.

Best Regards
Edwin Humphries

------------------------

From: ISO Standards Discussion
Date: Wed, 12 Jul 2000 14:39:50 -0500
Subject: Re: Web Based QMS /../Humphries/Pfrang

I like Edwin's suggestions, as well as a few others that have been posted, because they address the important issues related to Intranet use without going overboard. Some people have the mistaken idea that Intranet use demands all sorts of extreme procedures for document security, editing and approval. In fact, unless the firm has (or is likely to have) a widespread problem with employees deliberately falsifying documents, the firm should do just fine with a minimal document control system (electronic- or paper-based) that merely prevents accidental tampering.

In other words, the level of document security, editing and approval depend more on the character of the firm and whether it has (or is likely to have) forgery problems than on whether the firm chooses paper or an Intranet as its document storage medium. If the firm has no forgery problems with paper documents, then switching to electronic media should require no significant new procedures for document security, editing and approval.

-- Doug

I was reading some of the posts for electronic documentation. I did not see anything that could answer my questions.
I would like to ask 2 questions along this line. We are going to a full electronic system, meaning procedures and work instructions on line with each department responsible for assuring the current copy is posted, (pdf file) at this time. First, does ISO require us to keep a original Hard copy? And second, if a hard copy is not required, is it just a matter of how we define/document how we will do electronic approvals/signatures ? (is this allowed for ISO)
Thanks for any input you can give.

Bryan

No, you do not need hard copies (I assume this means paper copies). Electronic signatures are great if you can confirm that the person who's responsible for review/approval are responsible for the signature. For instance, you have an e-mail message stating that the document is reviewed /approved by the responsible person. I'm sure there are other approaches, but something like this works.

Bryan,

This is what I am doing.

We are going to an electronic system, but I need to maintain approval signatures on file.
I keep a hard copy of the procedure in my "records" file along with a cover sheet listing all the documents released and all the required approval signatures.

Hope that helps a little.

CarolX

Bryan:

The company I work for also has an electronic document system including electronic approvals. Our system is set up such that each document has an on-line Index which includes identification of the "Owner" of the document. Our electronic approval document requires that the "Owner" be the first signature sign-off and identifies all the other required signatories by title. When the document(s) hit our Doc Sys Group all they have to do is cross reference the Index to verify that the "Owner" has approved the document revision. The Index eliminates the need for us to keep a separate approval file. Our Level 2 document describes our system and indicates that this is the method we use to ensure compliance with ISO element 4.5.3. So far our Doc Sys Group and the system has been one of the consistent favorites of Third Party and Customer auditors.

I can convert your quality manual to e-books without the need of Acrobat or any other program.

Also see http://Elsmar.com/ubb/Forum7/HTML/000091.html and http://Elsmar.com/ubb/Forum7/HTML/000106.html and http://Elsmar.com/ubb/Forum7/HTML/000041.html

1- No, you are not required to keep a har copy, however, your registrar may request that you keep one controlled copy; just to give them that warm fuzzy ...

2- Develop a document control procedure for electronic media just as you would for hard copy , no difference.

Hi Ali,
In the long run, Laura' suggestion may not work. Please visit us at www.omnex.com. (http://www.omnex.com.) We have some unique solutions for ISO and QS documentation control.

Regards,
Arun

Hi,
It's actually Comic Relief (otherwise known as red nose day) here in the UK - raising money for under priveliged children in Africa & the UK.

From the postings today it looks like it may also be "give a plug to Omnex day"!!!!!

Don, I was waiting for someone to make the OMNEX crack. congrats.

Arun,
I have yet to post in this thread, so I'm curious as to what suggestion I had that won't work in the long run. If you mean the document control idea, then maybe you can explain why - cuz in the short run it is working just fine.

Laura

I've designed and implemented web-based ISO 9001/2 registered systems for five companies, some of which have multiple, remote locations and have been registered for five years. All of the webs use HTML and scripts as well as "server side permissions." I have yet to have ANY findings or issues related to this approach (and only well known, reputable registrars were used). Additionally, this method requires no additional (proprietary) software or "seats." I would be very interested to hear about any negative issues that may result "over the long term" from taking this cost effective, efficient approach to documentation management and distribution.

My company has purchased 'off-the-shelf' document control software. This software manages version control & archives well. The software also allows you to route a document for information or approval. For new documents, the software will not allow you to publish a document until it has been routed. However, we have recently discovered that the software will allow you to publish a document even if it came back as 'Disapproved'. :mg:

Is it sufficient to trust our people that they won't publish a document that is disapproved?

You can view whether a document has been approved or disapproved, however this information can easily be deleted. Is it stupid to trust that people won't delete this information?

We are trying to keep the system completely electronic & avoid having to keep printed, signed copies.

Your comments would be greatly appreciated.

...we have recently discovered that the software will allow you to publish a document even if it came back as 'Disapproved'. :mg:

Is it sufficient to trust our people that they won't publish a document that is disapproved?

You can view whether a document has been approved or disapproved, however this information can easily be deleted. Is it stupid to trust that people won't delete this information?
Ah.... Ok, I see your problem. No, generally speaking I don't think it's stupid to trust people. On the other hand, mistakes can and will happen. By the sound of things, the proper action would be to contact the software supplier and get them to patch their product up.

/Claes

Ah.... Ok, I see your problem. No, generally speaking I don't think it's stupid to trust people. On the other hand, mistakes can and will happen. By the sound of things, the proper action would be to contact the software supplier and get them to patch their product up.

/ClaesI agree with Claes. Your software author should be able to fix that up. Most of the Document Control systems I'm aware of do have a control to set the number of approvals before a document can be published as "approved." Sometimes a "workaround" is to set the security levels to allow only certain system users to "approve" for publication. Ultimately, you have to have faith in them.

In my opinion, this is a bug the author ought to fix for free.

Ah.... Ok, I see your problem. No, generally speaking I don't think it's stupid to trust people. On the other hand, mistakes can and will happen. By the sound of things, the proper action would be to contact the software supplier and get them to patch their product up.

/Claes

The problem is that it is an 'off-the-shelf' product and they are claiming that this is a customisation which will cost us money (& management don't like that!). :frust: We are trying to argue that it is the logical use of the routing function and should be patched. We'll have to see who wins the argument.

We are trying to argue that it is the logical use of the routing function and should be patched. I know that problem too. You can find lots and lots of applications of this kind, but the trick is to find one made by someone who is equally at home in the worlds of Computer geeks and Q geeks...

A programmer can whip something up and present a product in no time, but if he lacks insight from the Q community there is a fair risk that it may not be what the customer (the Q geek) wants...

:soap:
Besides, If the product came off the shelf, I would say that it makes it all the more urgent for the supplier to seal that leak. Other customers will have the same problem and may not know about it. Now, there is an argument in your favour.

/Claes

The software supplier is under no obligation to re-design their product based on your suggestions , unless of course you are willing to pay for it.
In the course of document release, I would think that the person reviewing the document for approval/disapproval would document their findings electronically. Although this would not fix the problem of human error it would provide a link back to the person responsible for releasing the document.

The software supplier is under no obligation to re-design their product based on your suggestions, unless of course you are willing to pay for it.Re-design? Possibly not, but how about patching it to make it live up to the the product specification? Look at Microsoft...

Anyway, If my customer tells me that my product is flawed, maybe I ought to think about fixing it? If I don't, it could have a negative effect on my sales before I know it...

/Claes

Re-design? Possibly not, but how about patching it to make it live up to the the product specification? Look at Microsoft...

Anyway, If my customer tells me that my product is flawed, maybe I ought to think about fixing it? If I don't, it could have a negative effect on my sales before I know it...

/Claes

As for not meeting product specifications; I didn't read in "gerrybeans'" post that it did not meet product specifications.
The supplier did react. They indicated that there would be a charge for re-designing the software to suit the specific customer requirement. I use the word "re-design" here because there is no indication that the product is flawed.
Also there is no indication of how long the product has been on the market or how many complaints have been received.

Hi,

I have our documents and procedures stored on the shared drive on our server. All users may access these files, but only as a read or print function. That way, if there are changes that anyone wants to make, they must come to me, as I'm the only one who has full access. I also keep a master book of hard copies, which has a signature page attached, rather like what CarolX is doing.

All the best!
Jonell

Hi,

I have our documents and procedures stored on the shared drive on our server. All users may access these files, but only as a read or print function. That way, if there are changes that anyone wants to make, they must come to me, as I'm the only one who has full access. I also keep a master book of hard copies, which has a signature page attached, rather like what CarolX is doing.

All the best!
JonellI can understand your position, Jonell, if you have a relatively small number of static (not often changed or updated) documents in your system.

However, when the documents run into thousands and changes are fast and frequent, a single person acting as the gatekeeper on allowing "approved" documents to be published (made available to others via hard copy or computer access) stands instead to be a "chokepoint" which inhibits the ready flow of documents.

Consider a system which has literally hundreds of document authors, constantly creating or modifying documents: it almost begs for an automated control and a process in which only the final approval (in a string of any number of approvals - the "collaboration circle") unlocks the key which turns it into a published document versus one in limbo while its authors and approvers collaborate on a finished document.

A good document management system (especially many off-the-shelf ones) makes allowance for the "limbo" documents and keeps them unavailable to anyone outside the "collaboration circle."

Wes,

Yes, We have a very small company here, about 60 employees total. What we have works for us for the number of documents and number of users that we have. There is no way that I could ever justify to the owner of the company, the need for anything more than what we have now, especially if there would be added expense involved, although having an automated system would sure be sweet.

Thanks for your input!
Jonell

I can understand your position, Jonell, if you have a relatively small number of static (not often changed or updated) documents in your system.

However, when the documents run into thousands and changes are fast and frequent, a single person acting as the gatekeeper on allowing "approved" documents to be published (made available to others via hard copy or computer access) stands instead to be a "chokepoint" which inhibits the ready flow of documents.

Consider a system which has literally hundreds of document authors, constantly creating or modifying documents: it almost begs for an automated control and a process in which only the final approval (in a string of any number of approvals - the "collaboration circle") unlocks the key which turns it into a published document versus one in limbo while its authors and approvers collaborate on a finished document.

A good document management system (especially many off-the-shelf ones) makes allowance for the "limbo" documents and keeps them unavailable to anyone outside the "collaboration circle."

Wes,
I would bring up the point that you are describing chaos, however, it may appear that I am bemoaning the need for continual/continuous improvement.
As we know, "there is nothing constant except change". And that is what keeps us (quality folk) employed.
Brings to mind the phrase,"Oh, what a tangled web we (braid), when at first we try to (upgrade)".

Wes,
I would bring up the point that you are describing chaos, however, it may appear that I am bemoaning the need for continual/continuous improvement.
As we know, "there is nothing constant except change". And that is what keeps us (quality folk) employed.
Brings to mind the phrase,"Oh, what a tangled web we (braid), when at first we try to (upgrade)".Yep, Sam. Often Document Management borders on Chaos. Some organizations (like Jonell's) are relatively small and located in a single geographic location. In such an instance, electronic document management is a "convenience."

In many, many instances, however, Document Managers are dealing with multiple sites and teams of collaborators (including customers and suppliers in many cases) scattered across half the globe. The concept of continuous improvement dictates that new documents and revisions to existing documents is the norm, not the exception.

If we are, as ISO9k2k suggests, "process oriented," then we create a process to handle document management (creation, collaboration, revision, approval, publication, storage, protection, retrieval, disposal) which is as efficient as possible.

In the early 60's, when I entered the workforce, document management was as important as it is today. The difference is the amazing compression of the timetable for creation, approval, and distribution of documents. What took weeks then is expected to be accomplished in hours today.

A CAD document (a technical drawing of a complicated device, for example) can be created, approved, and published to the point of being manufactured in less time than it took for the draftsman in 1960 to take a pencil or pen & ink drawing over to the blueprint machine at the end of the long drafting room and wait for the deep blue to develop while he got high from the fumes.

Given this incredible (to me) time compression, any single person who places himself in the position of sole gatekeeper is a major obstruction to continuous improvement. We need the process where the final approval of a new or modified document is the trigger to release it for publication and distribution. In addition, an audit trail is necessary for sampling for errors and for evaluation of further ways to improve and streamline the process.

:topic: The biggest impediment to an efficient process of document management is an ineffective or crippled software system. Practicioners should really examine the ROI of converting to a better process versus the losses due to inefficiencies of the current process.

Almost any good electronic document system will import and manage documents from an existing legacy system.

The primary/major cost is not the purchase or license price of the software - it is the cost of failure (if an obsolete or error-ridden document is used) and the cost of inefficiency and dissent for employees forced to work with error-prone tools. Remember the dictum of ISO9k2k Section 6 Resource Management - to provide tools and work environment "to achieve conformity to product requirements."

As for not meeting product specifications; I didn't read in "gerrybeans'" post that it did not meet product specifications.
The supplier did react. They indicated that there would be a charge for re-designing the software to suit the specific customer requirement. I use the word "re-design" here because there is no indication that the product is flawed.
Yes. All true. However, I reacted to the fact that the software will allow you to publish a document even if it came back as 'Disapproved'. It looks very much like a bug to me... Surely that cannot be the way it was intended to work?

/Claes

I can't remember if anyone posted this yet.

Yes. All true. However, I reacted to the fact that the software will allow you to publish a document even if it came back as 'Disapproved'. It looks very much like a bug to me... Surely that cannot be the way it was intended to work?

/ClaesI think I know what the problem was with the software that was the original topic of discussion - it was a "document sharing" system, NOT a "document managing" system. The difference is like the difference between having a library full of books that anyone can take off the shelf and take home and a library which has the books sorted with a card file and a checkout system to charge fines if you keep the book out too long. It may even have some documents coded as "reference only" - not to be taken outside the library.

Both libraries serve the purpose of making material available for their users - one keeps adequate track of the materials, the other doesn't.

- it was a "document sharing" system, NOT a "document managing" system.Ah-haaaaaaaa. Yes, that would make a world of a difference, wouldn't it? In that case I withdraw my remarks about making it live up to the the product specification.

Thank's Wes :agree:

/Claes