Does all level (all types) of documents should have history of changes as required? and why? and where this should be? in revision history page?

:) Hello gheghe,

You should have a documented procedure defining the controls needed to ensure that changes to the current revision status of documents is identified.

How you choose to IDENTIFY the changes is up to your company. Such as a Number or Letter, or "Changes to this document are indicated by:_______."

The Quality Management System documentation shall include:
1) Documented Statements of a quality policy and quality objectives.

2) A Quality Manual.

3) Documented Procedures required by the standard.

4) Documents needed by the organization to ensure the effective planning, operation and control of its processes.

5) Records required by the standard.

Yes you can have a revision history page if that works for your company.

Hope that helps!
Paula :bigwave:

I have always put a revision history (something as small as Rev Level, ECO #, and date) for Level I (Quality Manual), Level II (Quality Procedures), and Level III (drawings and work instructions). For Level IV (forms, checklists, etc.) just the most current rev and date). We use a revision page on I, II and work instructions because they tend to be multipage, and a rev block on 1 page drawings.

I've seen cases where a change was requested and the history showed that the document was already that which was requested. Like, "It was that before and we changed it because.......". Also, the question, "When was that changed?" Without a history, do we run the risk of going round and round? :vfunny:

I've seen cases where a change was requested and the history showed that the document was already that which was requested. Like, "It was that before and we changed it because.......". Also, the question, "When was that changed?" Without a history, do we run the risk of going round and round?

The answer to the question is "yes", IMHO. People come and go, but some documentation is here to stay. And Newbie may think "Heeeey....this document needs to be revised coz I just changed the process and now it needs to reflect what it is I truly do." Without a properly documented history, not only will Newbie never know that Oldie used to do it that way, Newbie will not understand why Oldie modified the process. Maybe the old way was ineffective. Maybe the old way caused massive quality issues. Maybe the old way resulted in requiring too many resources in this day-and-age of lean manufacturing.

In other words, documentation can be an awful lot like the real world. If we fail to learn from history, we will repeat our mistakes.

I take a lot of heat from some departments for making them clearly document their revision changes, but when I explain why they should, the proverbial lightbulb usually brightens up a bit.

May I suggest that the "history" is important only when related to reference to documents which fully explain the change. Most engineering drawings are only modified [revised] after a process often termed "engineering change order process" in which the person initiating the change spells out the reasons for the change to convince checkers and approvers down the line to accept the change.

Some companies are VERY anal about this and demand explanations of the ramifications of the change (i.e. should old stock be recalled? do we need new production machinery? etc.)

Other companies are very loosey goosey and do not do a good job of documenting a reason for the change.

This loosey goosey attitude is very prevalent when non-engineering documents are changed (report forms, purchase order blanks, etc.), resulting in a vast array of companies which have "history" pages attached to all documents which carry no more information than the number and date of the revision and no reference to the equivalent of an "engineering change order" (ECO) which reflects the reasoning behind the change. The data in the ECO can be very detailed or not, depending on the nature of the change (consider the difference between a change in dimensions versus a correction for typographical errors.)

In my opinion, lackadaisical attention to Document Management and Control can result in some gross inefficiencies in the operation of an organization. I further believe it is important to document the reasons for change with an easy method for retrieval of that reasoning when considering a new change.

History of document change that clearly states the major changes is useful for current users to identify exactly what is different about the new version, without having to nitpick through the document themselves to try to discover the difference.

For instance, in negotiating a contract it simplifies matters to maintain a table of changes for easy reference.

All of our procedures simply list the revision levels, the word "revision" for nature of change, and the date! How useful is that?? :bonk:

I guess I'm like the guy in the commercial "Inquiring Minds Want to Know!"

How much more simple to add a few words to "Revision" such as "tolerances changed for more efficient manufacture" or "finish change from Cadmium plating to Electroless Nickel plating"?

Frankly the word "Revision" alone as a reason is redundant, you can put the word at the top of a column and just add the number of the revision if all you want to indicate is the fact there is a newer version of the part or document.

If we are in the Quality business, we are supposed to be the "bright lights" NOT blinders.

What are some of the ways the changes are identified?

examples: Revision history in an appendix, Bold or italicized text, Asterix next to the modified paragraph....

The only one that works for deleted text is a revision history.

It would seem after years of creating document control systems there is still discrepancies as to whether the actual modified text needs to be identified. The standard would seem to indicate that the changed needs to be noted where it says "to ensure that changes and the current revision status are identified."

So what are ways that the actual changes are identified?

Laura

What are some of the ways the changes are identified?

examples: Revision history in an appendix, Bold or italicized text, Asterix next to the modified paragraph....

The only one that works for deleted text is a revision history.

It would seem after years of creating document control systems there is still discrepancies as to whether the actual modified text needs to be identified. The standard would seem to indicate that the changed needs to be noted where it says "to ensure that changes and the current revision status are identified."

So what are ways that the actual changes are identified?

Laura

I have used most of the ones mentioned above. The 2 which have given me the best results in communicating the nature of the change in a document are; use of a revision history in the document itself (like a revision block used to do on a drawing in the pre-cad days :eek: ), and the use of a different color of text for the font in a document or PFD. IMHO this issue is one of the quickest means of checking the pulse of the organizations committment. Those that are committed and interested in maximum return from their QMS will be doing something that ensures the changes in their documentation / instructions are identified in a manner that aids the user in finding it and reviewing the change. :p

I have used most of the ones mentioned above. The 2 which have given me the best results in communicating the nature of the change in a document are; use of a revision history in the document itself (like a revision block used to do on a drawing in the pre-cad days :eek: ), and the use of a different color of text for the font in a document or PFD. IMHO this issue is one of the quickest means of checking the pulse of the organizations committment. Those that are committed and interested in maximum return from their QMS will be doing something that ensures the changes in their documentation / instructions are identified in a manner that aids the user in finding it and reviewing the change. :pDifferent color font is only acceptable during the "approval" process for a document change. Once the revision is approved by all applicable parties for release, the different color text (or lines on an engineering drawing) are no longer acceptable. Hence the notation in the "comment" column of a revision history block or page with a brief description of the change.

(I've even seen notations as to the reason for the change, such as "new regulation" or "alternate supplier.")

Different color font is only acceptable during the "approval" process for a document change. Once the revision is approved by all applicable parties for release, the different color text (or lines on an engineering drawing) are no longer acceptable.
Why?

Why?Myriad reasons. Several come to mind:

Mechanical reproduction, for one. (Everyone does not want to expend the price for reproducing copies in color, although this is certainly physically possible. I am mindful of many organizations which use black/white scanners to input latest version of documents for future dissemination enterprise wide or world wide.)
Differences in conventional Standards of Engineering Drawings
(ASME 14.100M, for example) which dictate line weight, reserve color for specific wiring, etc.
Distraction from the main thrust of the then current version of a document. (It isn't necessary for the production worker to be aware of the history of the changes, only to adhere to the current version. It is management's responsibility to see production has latest version to use.)
Having a color version and a black and white version contravenes the concept of having a uniform version. (Which version is the "official" version?)
Note that I am making a distinction between a "final approved version" and "redline version" which is often used as a temporary working version of a modification, especially in industries like aerospace and commercial aviation where "aircraft on ground" awaiting drawing or document changes for a product installation creates a costly proposition. In all cases, though, in aerospace, the final authorized version which may be duplicated for dissemination to regulatory agencies and repair stations around the world is in conventional colors and no longer has color or highlighting distinctions pointing to the modifications. This applies to engineering drawings and text documents, which may include operating instructions, etc. "Redline" is itself often a misnomer, since the modifications may be transmitted across the world via black and white fax for installation at a repair station located far from the engineering department making the changes.

My favorite method of highlighting changes....Let's say we had a revision "3" and a specific paragraph was amended. Using "Word", enter the symbol "circled 3" in superscript at the beginning of the paragraph. At the back of each document was the Revision list with the changes for "3", and all pertinent information as to why. Kind of like "footnotes" in other types of documents. Not a distraction for the reader and for those curious types, a prompt to look at the Revision sheet if they were feeling nosy. Real easy. :bonk:

Different color font is only acceptable during the "approval" process for a document change. Once the revision is approved by all applicable parties for release, the different color text (or lines on an engineering drawing) are no longer acceptable...
I'm having trouble understanding the "hard line" answer. While I can understand a large company wishing for the uniformity aspect, a small/medium sized company may find it beneficial to highlight a change to a Setup or Operator instruction sheet. On our floor, the operators are pretty well trained in the generalities of how to perform their job. A "highlighted" (in our case - blue) change to these documents draws their attention to it. The supervisor is also charged with making sure each operator is aware that there has been a change to an instruction. Is training required? Not necessarily - a parameter setting may have changed or the frequency of an inspection check may have increased/desreased, etc. In these types of instances, the highlight helps to insure the operator is aware of a change to his/her "routine". The "myriad changes" response hasn't cleared it up for me either. I can't find anything in TS/ISO/QS that says our "different colored text" is unacceptable. :confused:

Bill

Hello - this is an interesting thread. Everyone has their unique method of highlighting their changes and maintaining their revision levels. Here is mine.

When I make a draft to send out for review, the new things are in green, bold, italic, and underlined. The removed text is in red with a strike through. After approval, the red text with the strike through is deleted, and the green becomes black. The bold, italic, and underlined features stay until the next revision. There is also a revision line in the margin locating where the changes are. This is a simple feature in Word. It has worked well for me. Then I use dates and a revision letter to maintain the actual revision level. Thus all of my revision history is electronic; to include the drafts and the release documents.

Then when I issue the changes, I determine what level of training is needed based on the changes.

Level 1 would be no training needed, changes are for simple, non-impacting changes. (This would be for grammar, spelling, format issues that do not impact the intent of the document).

Level 2 is training in the changes only.

Level 3 is training in the entire document required.

Sometimes as document control facilitators, we can loose site of the training of the people that need the document and that use the document. Maintaining a record of revision is supported by the record of training in the revisions as needed.


JMHO. :bonk:

Myriad reasons. Several come to mind:

Mechanical reproduction, for one. (Everyone does not want to expend the price for reproducing copies in color, although this is certainly physically possible. I am mindful of many organizations which use black/white scanners to input latest version of documents for future dissemination enterprise wide or world wide.)
Differences in conventional Standards of Engineering Drawings
(ASME 14.100M, for example) which dictate line weight, reserve color for specific wiring, etc.
Distraction from the main thrust of the then current version of a document. (It isn't necessary for the production worker to be aware of the history of the changes, only to adhere to the current version. It is management's responsibility to see production has latest version to use.)
Having a color version and a black and white version contravenes the concept of having a uniform version. (Which version is the "official" version?)
Note that I am making a distinction between a "final approved version" and "redline version" which is often used as a temporary working version of a modification, especially in industries like aerospace and commercial aviation where "aircraft on ground" awaiting drawing or document changes for a product installation creates a costly proposition. In all cases, though, in aerospace, the final authorized version which may be duplicated for dissemination to regulatory agencies and repair stations around the world is in conventional colors and no longer has color or highlighting distinctions pointing to the modifications. This applies to engineering drawings and text documents, which may include operating instructions, etc. "Redline" is itself often a misnomer, since the modifications may be transmitted across the world via black and white fax for installation at a repair station located far from the engineering department making the changes.

Wes,

In a strictly regulated environment (Gov, Military, FDA, etc.) your auguments may hold true, but in a small business and/or any less regulated environment the use of color highlighting may not only be acceptable but may be desirable.

In a small business (or in an organization that is "paperless", with online documentation) there would be no mechanical reproduction or conflicting color -Vs- monochrome issue.

Again, if you are in a non-regulated environment the standards of ASME 14.100M, etc. may not apply (and actually, in a regulated environment these "standards" would apply towards your process/production documentation only if your company chose to adopt them for that environment - they are typically contractual "requirements" for engineering drawings and documentation only).

As to multiple colors being a distraction to the main thrust of the document, I believe that is just a matter of personnel training. As long as you have properly and clearly explained the purpose of the multiple colors, there should be no confusion/distraction.

Finally, your statement on "final approved version" and "redline version" once again only applies in regulated businesses, or businesses that have "chosen" to adopt this practice.

My point in all this is not to be argumentative, or to belittle, but to point out that what may appear as "hard arguments/requirements" to us in regulated industries may not apply to those in small or less regulated businesses. In-fact we in regulated industries would probably do well to "benchmark" some of the examples provided by the small less regulated businesses - afterall wasn't that the whole purpose of the Defense Logistics Agency's Single Process Intiative in 1998? :bigwave:

So if the text is highlighted in 'draft' or 'approval' copies, then printed in normal font for release, does that meet the requirement that the change is "identified."

I've had systems pass with just a date and rev level change - no notations in the text as to what the change was, just a filed "document change request" with appropriate approvals. The rev is identified, but the actually change in text in not indicated anywhere in the released copies. I've used the method indicated by energy - with a symbol similar to prints - indicating the paragraph or block of text changed.

Why I'm asking..... I've just completed a beautiful (IMHO) trifold quality manual. The process interaction is in the middle, with the quality policy on the cover, scope and objectives on the inside fold. I'll remove the company detail and post later today. While I think it will be easy to include a small font date and rev level, I don't want to clutter it up with notes or a revision history. Comments?

Here is the manual - to be printed on 8 1/2 X 14 paper - 2 sided. Process interaction needs some work - but that's not the purpose of this post - just to show the concept.

I don't get something...let's say a document is at Rev 4. I can clearly see through a multitude of methods here which aspects of the document was changed for this current release (i.e., through colours, italicized font, underlining, a circled number 4).

So...if these are the methods you are using, how do you find out what Rev. 2 looked like? How do you find out what the changes were between Rev. 2 and Rev. 3?

The problem I see with these methods is that they are only as good as the current release.

gheghe asked a question in the first post that I don't really see being discussed in here. Why? Why have a revision of changes? What is its purpose?

We've discussed hows and whats and even some whens...but no whys. And does you "how" suit your "why"?

We maintain a copy of each revision as it was released (online, but could be maintained as hard copy if preferred), so that we can go back at any time and review the revision history. Additionally, we incorporate a brief summary of each change as a part of the Revision History section we maintain at the back of each document (e.g. Rev. A - Para. 3 line 3, changed .2" to .02"; Rev. B - Section 6.2 added requirements for Calibration Subcontractor Control). :bigwave:

Electronically. Here is an example of the file structure that clearly shows each revision (the draft and the issued reveision). It works well for me.

I don't get something...let's say a document is at Rev 4. I can clearly see through a multitude of methods here which aspects of the document was changed for this current release (i.e., through colours, italicized font, underlining, a circled number 4).

So...if these are the methods you are using, how do you find out what Rev. 2 looked like? How do you find out what the changes were between Rev. 2 and Rev. 3?

The problem I see with these methods is that they are only as good as the current release.

gheghe asked a question in the first post that I don't really see being discussed in here. Why? Why have a revision of changes? What is its purpose?

We've discussed hows and whats and even some whens...but no whys. And does you "how" suit your "why"?Thanks, Roxanne, for calling my attention to a point I thought I made, but upon review was so poorly stated as to be ineffective:
Who (and at what point in the production cycle) is that person going to be looking at these changed documents and for what purpose? Will it be a production worker? an engineer reviewing the document for future changes? a customer who will never see or know the previous version? a regulator? a rival company?

For the sake of example, consider an engineering drawing which changes one small detail (use star drive screws for fastening instead of Phillips head for more efficient automatic screwdriver operation in production) The change does not affect product in use or in inventory, but does change work in process and any future production. Repairs by customers or field reps can freely substitute Phillips head with the same thread profile.

The change process from concept through final approval and implementation might either highlight the change or print it in different color for efficiency in review and approval of this one single change. Once approved, the production folks are alerted to the change and instructed to replace stocks of Phillips head with star drive screws and tool heads are changed to star drive. The assembly drawing may have a note that alerts repair people that the thread profile is the critical feature of the fastener and the use of either type of head is acceptable. (probably not a cosmetic issue)

So the point is: next year, when the design is reviewed, it might be a good idea to have a history page which refers to the Engineering change order so that "Joe, the new guy in engineering" has something to review before he says, "Hey, let's change to Phillips head screws because more people have those kind of drivers to make repairs or adjustments."

Consider also, the consequences of two previous revisions,

the initial one changing from blind rivets to flat blade screws (so field repairs could be made),
the second one changing to the Phillips head (to use automatic drivers in assembly), and now
our third, changing to star drive.
Should each of those changes be separate colors?

IMO, document creators and modifiers are the people who need primary access to the history of changes and the accompanying REASONS for those changes. The history page used in many document systems is really insufficient for that purpose UNLESS they identify the allied documents explaining the changes and reasons for them.

Some have mentioned there is a decided difference between organizations in the manner of identifying changes. I absolutely agree that the system which works for a giant like GE is utter nonsense in a ten person job shop. The type and scope of the change is also pertinent. The internal procedures and numbers of people who may EVER view the document are equally pertinent.

The wonderful thing about ISO Standards is that each organization may adapt the system to fit its own circumstances.

IMO, document creators and modifiers are the people who need primary access to the history of changes and the accompanying REASONS for those changes. The history page used in many document systems is really insufficient for that purpose UNLESS they identify the allied documents explaining the changes and reasons for them.

And the document users.

I agree that the document authors (as we call them) and approvers need to know what the changes were and why in order to continually move forward with the processes and not backwards.

"Why don't we modify the process so that we can...oh...wait...we used to do that, but discovered it wasn't as efficient in reality as it seemed on paper due to blah, blah, blah."

From a training standpoint, an explanation of the what's and why's also help in longer and/or detailed documentation. It allows the user to home in on those specific aspects that were modified, which reduces training time.

Some have mentioned there is a decided difference between organizations in the manner of identifying changes. I absolutely agree that the system which works for a giant like GE is utter nonsense in a ten person job shop. The type and scope of the change is also pertinent. The internal procedures and numbers of people who may EVER view the document are equally pertinent.

The wonderful thing about ISO Standards is that each organization may adapt the system to fit its own circumstances.

I agree...which is why I asked for people to consider why they feel recording document history is important and if their organization's methods are suitable to address their answer.

Does maintaining a history count as "identifying the change?"

Does maintaining a history count as "identifying the change?"

It can. As I mentioned earlier we have a change history file at the end of each document (other companies put it at the beginning), where we provide a brief description of the change including reference to the applicable section, paragraph, sentence, et cetera. With this in place, coupled with providing some training to the users to familiarize them with how to determine what the changes were (reviewing the change history section), we feel that we have adequately "identified the change". :bigwave:

I don't want to beat a dead horse, but if you go back to my posted example of a one page quality manual - I really do not want to clutter it up with a history listing. I would like to simply have the revision date/rev level in a footer. To underline, asterik, bold, change color, etc or to keep a listing of revisions will make it messy. There is empty space on the back, but since this could be a marketing tool as well as a quality manual, I think a table indicating, for example, "Rev B Quality objective # 2 modified - 1-13-04" doesn't help in this case.

I don't want to beat a dead horse, but if you go back to my posted example of a one page quality manual - I really do not want to clutter it up with a history listing. I would like to simply have the revision date/rev level in a footer. To underline, asterik, bold, change color, etc or to keep a listing of revisions will make it messy. There is empty space on the back, but since this could be a marketing tool as well as a quality manual, I think a table indicating, for example, "Rev B Quality objective # 2 modified - 1-13-04" doesn't help in this case.

Well Laura just to take one more swipe at that dead horse - I have to ask the question: How do you propose to define to the recipients of your quality manual any revisions to the quality policy, objectives, or process interactions? Or another way to view the question could be: How am I as a recipient to know if there have been changes to the quality policy, objectives, or process interactions? :confused:

OK, I am definitely not saying that what I do is right, or the only way to do it. :ca:

In the documents themselves, I use a Pipe symbol at the point of revision (| because it is not a tech symbol we use anywhere else) and the rev. no. (1, 2, 3, etc.) and that is it. We keep a database with rev info, so we can explain in as much detail what the rev was. I hate documents with 150 paragraphs at the bottom explaining every revision ever made. Because we do have the database, and once the documents are entered into it, we do go ahead and record all levels of documentation, from forms, to quality manual.

Some revisions are detailed very explicitly, some are as simple as "changed format of form to facilitate easier data entry."

This is one of those, whatever works for your company/industry areas. You might find a database overkill in your business.

I should probably mention that in the document itself, only the current revision is marked....keeping the document relatively clean, forms typically don't have the rev symbol at all. Revision numbers are always in a "header" for that particular type of document.

I've just completed a beautiful (IMHO) trifold quality manual. The process interaction is in the middle, with the quality policy on the cover, scope and objectives on the inside fold. I'll remove the company detail and post later today. While I think it will be easy to include a small font date and rev level, I don't want to clutter it up with notes or a revision history. Comments?

Here is the manual - to be printed on 8 1/2 X 14 paper - 2 sided. Process interaction needs some work - but that's not the purpose of this post - just to show the concept.

I must admit that is the first 1 page QM I have ever seen. Do you currently use this, or intend to use this, as the official QM for your company? Have any auditors commented on it? Why did you decide to go this route? Just curious...

:bigwave: Hi Everyone!

I work for an organisation that provides careers education and other advice and guidance county-wide (that's an English county).

We don't use a history table or page on our procedures, but do have a revision letter after the document's reference number - this ties in with an issue date on a separate Procedures Index.

At the beginning of the document we have a "details of change" area in italics that only amounts to about a paragraph in size. In this we briefly indicate the sections/sub-clauses, etc. within which the changes have occurred and the subject of the changes.

Within the sections of the document where the revisions have been made, the relevant paragraphs are highlighted using a "double-bar" at the right hand side of those paragraphs, while, if it doesn't look too messy, deletions may be indicated by using 'strikeout' on the appropriate text.

Where there are a larger number of changes to be made, we may just state in the details of change area that such sections in which these occur are indicated by double-bar highlighting. If really numerous and radical changes have been made to the document, then we just state that fact and that the whole procedure should be taken as having been revised.

We issue our documents on our Intranet, which is available to all our staff throughout the county (largely rural - though not by North American standards!). We inform line managers by e-mail of the documents that have been updated and provide them with a link that takes them directly to the document(s). They are requested (Brit's like you to be polite!) to print out a copy for their paper files - computers do crash - and to inform their staff of the changes and if there are any effects on their practice. We use voting buttons on the e-mail so that the managers can either inform us of successful completion of the required actions or to tell us about any problems.

Staff can take copies of the procedures if they use them regularly or the process described is complicated. Procedures are password protected for modification and are marked as "Uncontrolled when printed" - the definitive version is the one on the Intranet.

We don't use colour on our electronic documents, as it's a waste of time - the number of colour printers in our organisation is very low and all of our photocopiers are monochrome.

So far, this system appears to work for us.

Cheers.

Lyn

Some revisions are detailed very explicitly, some are as simple as "changed format of form to facilitate easier data entry."

This is one of those, whatever works for your company/industry areas. You might find a database overkill in your business.


This attachment is a step back in time...94 version-Element 14 and the last page of every procedure. It was one I could locate quickly and I just know some of you need it right away. :D We wouldn't want those working to these procedures to forget how to do their job. ;) Worked real well. Let's not forget that people using these procedures do not have it memorized down the exact paragraph. Like, "Hey, that says "and" and it used to say "plus". :vfunny: Referencing a paragraph and what was changed will suffice for many companies. :smokin:

We maintain a copy of each revision as it was released (online, but could be maintained as hard copy if preferred), so that we can go back at any time and review the revision history. Additionally, we incorporate a brief summary of each change as a part of the Revision History section we maintain at the back of each document (e.g. Rev. A - Para. 3 line 3, changed .2" to .02"; Rev. B - Section 6.2 added requirements for Calibration Subcontractor Control). :bigwave:

This seems to me like the easiest thing to do and would probably work in most companies. IMO keeping a (properly identified as obsolete) copy of all earlier revisions of a document is both easy (e-copies) and a good idea. In fact, IMO, on the latest revision you only need to show a brief summary of what the revisions are relative to the previous revision, not every revision ever done. Remember, don't make it harder than it needs to be!

I must admit that is the first 1 page QM I have ever seen. Do you currently use this, or intend to use this, as the official QM for your company? Have any auditors commented on it? Why did you decide to go this route? Just curious...

Perhaps this should move to another thread because we're crossing topics...

I did have one client get registered with a one-page quality manual. It was their idea and they actually got an example from their registrar before I was ever in the picture. Funny thing was the auditor asked after viewing the one page - "Can I see your manual?" After some uncomfortable conversation - he agreed the minimum requirements were covered and moved on.

So it has been done. In this particular case, all of the procedures in the process interaction have been written. We looked at the minimum requirements of a QM per the standard, and felt we could handle it this way. There was a previous QM - 25 pages - but the more we looked at it, it repeated alot of information already in the procedures. If something changed - then 2 documents needed updating.

As far as the question regarding distribution and latest copies, that deserves some thought. My 'gut' reaction is that the Quality Manager keeps track of who he provides one to if they are outside the company - and whether they need updates. For the most part, I believe those people would not be actually 'using' the manual, so there is probably no real need to send them updates. Internally they would have it posted on the intranet. We could potentially add a "print copies are uncontrolled" statement.

Most of my previous procedure, manuals, etc have a revision history as posted by energy.

Laura

PS. Mr. Moderator can let me know if you want to move the one-page manual discussion to a different forum

How am I as a recipient to know if there have been changes to the quality policy, objectives, or process interactions?

I think this is the key question. If you hand me a revised document, and say it was revised, I would immediately ask; "What changed?" If it is not apparent in the document, then it would have to be identified some other way. I think this can be accomplished through training, such as answering my question. I have the new revision, you told me what has changed, and by doing so, you identified met the requirements of the standard.

I think this is the key question. If you hand me a revised document, and say it was revised, I would immediately ask; "What changed?" If it is not apparent in the document, then it would have to be identified some other way. I think this can be accomplished through training, such as answering my question. I have the new revision, you told me what has changed, and by doing so, you identified met the requirements of the standard.

And what about electronic systems that allow for self-training? Our document control system electronically enters the document into a staging area and sends out emails to all people who need to be aware that the document has been modified. The email recipients are to follow the link in the email to the document, read it over, understand the changes and select the self-training button (to indicate that they have done the training). Simply stating what changed and when isn't sufficient for us.

I think we all agree that an organization needs to find a system that works for them. What work for Company A, may be overkill for Company B, and insufficient to meet the needs for Company C.

Yet, no one appears to have any problems with their Registrars when it comes to document control. We all have systems that work for us, proving that you don't conform to ISO 9001...you make ISO 9001 conform to you. :)

:truce: