G
gheghe
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?
R
Raptorwild
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
Icy Mountain
Sachem
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.
E
energy
Sometimes, it proves interesting
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?
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?
energy said:
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.
Wes Bucey
Prophet of Profit
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.
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.
J
JodiB
Time saver ; User Friendly
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??
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??
Wes Bucey
Prophet of Profit
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.
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.
L
Laura M
Re: History of changes
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
B
Bigfoot
Re: History of changes
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 ), 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.
Laura M said:
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
), 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. Similar threads
