How to document many document control systems with one Document Control Procedure?

C

CATERAF

Hi,

I've been searching through document control procedures in an attempt to work out how to write mine but no success so far..

My dilemma is that we have many (!) different places that documents are stored and they have different systems of approval, distribution, permissions, ownership, etc.

How do I document all these in one procedure?

Two examples are:
1. Software Documentation - We use Team Foundation Server to control our software development process. This includes requirements, design, test cases, code, etc. We do not want every document 'approved' because they'd be there all day so they just want to approve some documents, such as requirements.
2. Wiki - We use our wiki to store many process-related documents, records that are generated as part of a process, templates and forms, sales documents, software design that's not in TFS, etc. With the wiki everyone who has permission can make changes and save those changes. Some of the time we want documents 'approved' before release but other times we don't care so much and consider all changes an 'improvement' and the document can be reviewed by the document owner 'later'.

These are 2 examples but we have lots -- a production database, wiki, software program, emails, etc.

How should I co-ordinate all these differences into a single procedure? There are so many variations...

Oh, adding to that, with each 'process' we document what needs approval -- so it's almost doubling up to have it in the document control procedure.. or is it?

Also, I have problems knowing if a document is a record or not .. for example, sales orders are a document until they're set and then they're a record -- so do i need to class the accounting software (which stores them) as a document, or a record?

Any help with all of this would be very handy -- I'm really quite confused as to how to come at this. I've tried a few different ways but they aren't useful for the company, just for ISO.

Thanks!
 

Wes Bucey

Prophet of Profit
Re: How to document many document control systems with one Document Control Procedure

Hi,

I've been searching through document control procedures in an attempt to work out how to write mine but no success so far..

My dilemma is that we have many (!) different places that documents are stored and they have different systems of approval, distribution, permissions, ownership, etc.

How do I document all these in one procedure?

Two examples are:
1. Software Documentation - We use Team Foundation Server to control our software development process. This includes requirements, design, test cases, code, etc. We do not want every document 'approved' because they'd be there all day so they just want to approve some documents, such as requirements.
2. Wiki - We use our wiki to store many process-related documents, records that are generated as part of a process, templates and forms, sales documents, software design that's not in TFS, etc. With the wiki everyone who has permission can make changes and save those changes. Some of the time we want documents 'approved' before release but other times we don't care so much and consider all changes an 'improvement' and the document can be reviewed by the document owner 'later'.

These are 2 examples but we have lots -- a production database, wiki, software program, emails, etc.

How should I co-ordinate all these differences into a single procedure? There are so many variations...

Oh, adding to that, with each 'process' we document what needs approval -- so it's almost doubling up to have it in the document control procedure.. or is it?

Also, I have problems knowing if a document is a record or not .. for example, sales orders are a document until they're set and then they're a record -- so do i need to class the accounting software (which stores them) as a document, or a record?

Any help with all of this would be very handy -- I'm really quite confused as to how to come at this. I've tried a few different ways but they aren't useful for the company, just for ISO.

Thanks!
please look at this post to see if it helps you.
Much depends on the quantity of legacy documents which have to be put into your new system and much depends on how many documents are generated daily/weekly/monthly and on how many authors you have making new documents or revising existing ones.

I see many examples of companies tying up all documents in the organization into one computerized system - the key is to install a method of security to keep them from being altered without authorization.

It has to be simple to learn and follow or rebels will try to "game" the system.
 
C

CATERAF

Re: How to document many document control systems with one Document Control Procedure



Thanks very much for such a speedy reply. The link that you sent seemed to be leaning toward finding a single system to help.

Unfortunately I don't think we're in a position to achieve that (time, expenses, etc) so I'm trying to work with what we've got.
That said, the post did draw on the points that you need permission controls, audit trails and version history (etc) which I have *tried* to implement in each of the systems we have.

That said though, I'm not sure how to write one procedure that wraps up all the systems into one..

I do agree with you that simple to learn is best, but as we have so many different systems, one of the hurdles for the staff is knowing which system to use. Within the systems I've tried to get the structure as simple as I can and/or similar to the way other systems are structured for consistency.. they seem to be getting their head around it, but I haven't found a way to write a 'procedure' for all the systems..?

Thanks for your help :)
 

RoxaneB

Change Agent and Data Storyteller
Super Moderator
Re: How to document many document control systems with one Document Control Procedure

One procedure and one process would be the ideal, but I can appreciate that this is not the reality for many organizations. With all of the possible document control processes within your own organization, it might be helpful to first create a table that identifies some key information (this could then aid users within your organization on which protocols to follow and when). Information in the table could contain:

  • Process/Department
  • Name/Type of document control in play (e.g., if they use software, a wiki, a common drive, etc.)
  • Methods of approval (e.g., hard copy signature, e-sig, none)
  • Accessible to all users within the organization (yes or no)

From then, you could also create a process flow diagram if information in documents from one area can impact the documents in another - as you'll want to understand how changes are communicated between documents.

At that point, I hate to say this, but you may end up creating a high level procedure/policy that outlines the bare minimum for a document control system within your organization. Include the table that you developed - see above - and make each department responsible for documenting the details of their own document control process.

The high level procedure/policy would basically be a repeat of the standard's requirements and any common core organizational traits (e.g. if you have common numbering system or title format). The table can also serve as a checklist when auditing the document control process as you'll have a quick, at-a-glance reference to see who to audit (or who should be added to the table if other departments develop their own systems).
 

Pancho

wikineer
Super Moderator
Re: How to document many document control systems with one Document Control Procedure

Hi Cateraf,

I think its hard to write one single procedure that will contain all the different cases. After all, the standard itself differentiates between records, docs of external origin and regular docs, so most QMSs will likely have at the very least three individual instructions to handle those. Then there's email, the bad boy of doc control. You'd want to control that in its own way. Records in a db, development notes, schedules, etc, sensitive documents, etc., all may require their own controls.

So the trick may be in not trying to encompass all in one procedure, except by reference. Why not write a "menu" doc control procedure: acase statement that directs users to the place they need to be. For example:


Document control is carried out in accordance with {Document control in wiki} except for the following types of documents:

  1. Software development documentation, see {Development doc control}
  2. Emails see {Control of emails}
  3. Production database, see {Control of production records}
  4. Contracts see {Contract handling}
  5. Documents of external origin {...}
  6. All other documents {Document control in wiki}

Also, You may need to complement this (or each individual case) with clear descriptions of what each of these docs is, how to add links within each document for related docs, and how to add new documents into their proper indexes, navigation, etc.

At the top of each subprocedure, describe exactly what kinds if docs this applies to, and provide links to the other subprocedures.

Good luck!
 

normzone

Trusted Information Resource
Re: How to document many document control systems with one Document Control Procedure

Here's how I am approaching this challenge.

I play for a small team that's in the ISO 9001:2008 at an entry level - systems are not very far removed from tribal, no gorgeous central software for control of all systems, more of a patchwork of systems for things that have evolved as the company transitioned from the three-men-in-a-garage stage that most small companies start out as.

The systems play nicely together remarkably well, and they continue to improve, but it's a challenge to document it in some fashion that makes it auditable.

So I made a list of all the records / documents that are in active use. Then I made this form:

CONTROL OF CHANGES, DOCUMENTS, RECORDS : TEMPLATE – XX – XXXX Rev. A

The categories underlined below must be completed.
Example answers are shown between underlined categories. Replace that text as appropriate.

Document or record description:
What is this thing? A drawing, technical specification, work ticket, corrective action, etc.?
Unique identification (document number if applicable) :
This item has a document number, has no document number but has a job number, etc.

Process owner(s):
Which department(s) or group(s) executes the process(es) resulting in the change, document, or record ? Operations, Sales and Engineering, Field Application Engineer, etc.

Storage method / location
This document/record is kept on my hard drive, on the engineering server, on the network, in a file cabinet, in email folders filed by customer, Sharenet, LTpublicdrive, etc.

Review authority / mechanism
This document is generated and approved by the Operations Manager, generated by engineering and approved by the Design Review Board, etc.

Authority to revise
This assembly instruction may be revised by Operations, this customer communication by Engineering, this work ticket by the Director of Operations, etc.

Revision / Change status identification method
Revisions are identified by alphanumeric, datestring, not identified but previous version destroyed/archived and new version distributed, etc.

Obsoletion control method
Previous revisions are archived on the server, put in the shredder, maintained as records in email, do not exist because each new document overwrites the previous one, etc.

Record retention duration
Records exist forever in MAS3000, are retained for five years, are retained as required by regulatory and contractual requirements, exist until the email server is purged, etc.


I then interview the apparent process owner of each of the two dozen record sets I've identified, and capture the answers to these questions on a copy of my form dedicated to each of these.

I'll maintain the set under a cover sheet detailing how this information was captured and maintain / update it as required.

I'm hoping it will fly - I've not tested it with an external auditor yet but it seems practical to me as a method of documenting a chaotic data set in a controlled manner.
 
Last edited:

normzone

Trusted Information Resource
Re: How to document many document control systems with one Document Control Procedure

A bump out of curiosity - I'm wondering if the approach above that I have taken meets with any form of approval (or otherwise) with my peers here. I've updated my post to show the content of the form I created.

Thanks - Norman
 
Last edited:
Top Bottom