The ISO standard states that the changes to the Quality Manual should be available for review by the use of attachments or visible on the page itself "where Practicable". My quality manual INCLUDES all of the quality system SOP's as part of the manual and each time one of these is revised it must be reflected on the change record page of the manual. My question is this "can I eliminate the revision record from the manual itself and keep all changes available for review in my Change Notice files (ECO's)?" Any change as in the past needs to be approved through the document change system anyway and the revision record in the manual is redundent!

Hmmmm, interesting question. I would say that you should talk with your registrar. I would think that the revision record is not optional. Even if it were, I would keep it anyway. It never hurts to CYA.
Then again, I'm a packrat :tg:

Mark,

I believe that this is a personal preferrence your documentation person must make (perhaps you). I keep a database online with changes made to documents under control. As my personal preferrence, I keep the change details separate from the details I want the reader to read and act on. Reduced clutter and increased understanding I think.

Regards,

Kevin

I don't put revisions in the manual. I only reference the SOP number. This number never changes regardless of how many revisions we go through. The SOP table of Contents states the revision. Hope this helps.

In our manual we footnote the latest revision only, and refer to the files for a full revision history. In our opinion it is both impractical and redundant to retain a complete revision history in the manual itself, and our registrar has not had a problem with this.

Why do we keep the record? It's to facilitate the requirement of 4.5.3, paragraph 1, ie; those doing the review and approval (and, not stated but more important, the guy making the change) should ensure that the change does what it is intended to do without diminishing other aspects of the procedure.
So you need to keep it. "Where practicable", put it in the document or attachments. Where this is not practicable, or you have some other method which is more practicable, then do what you like. But be able to explain why. And don't lose sight of the basic intention of the requirement of the clause. (as above)
If procedures are to be good, they should state the important thing, not the obvious or mundane thing - we'll manage that anyway. The most important thing, when changing a procedure, is to understand how and why the procedure got to be the way it is. Otherwise you may be re-introducing problems already eliminated or undermining basic principles behind the design of the original procedure.
To make the information easily accessible helps ensure it is used. To document the need and (if necessary) say where the information is available, is a simple, but critical piece of documentation. Show this and explain it and no registrar can have anything but respect for the way you deal with the issue.
rgds, John C

I never, ever, ever, ever, ever, ever show the "nature of the revision" within the documents of our Quality System.

Our docs simply detail the revision level of the document. If anyone, including a registrar wants to see the revision history, they can page through my book of DCO's (Document Change Orders) which contain the change request and details, and a marked up copy of the previous version (appropriately labeled as OBSOLETE).

I have never had a problem with our registrar(s).

ALM

Our docs simply detail the revision level of the document. If anyone, including a registrar wants to see the revision history, they can page through my book of DCO's (Document Change Orders) which contain the change request and details, and a marked up copy of the previous version (appropriately labeled as OBSOLETE).If a rgistrar asks for more than that they should be challanged.

Marc wrote: If a rgistrar asks for more than that they should be challanged.

My reply: They have been! (LOL).

We should start a new thread that asks for the "oddest" "requirement" that an auditor ever looked for. My experience has been that more of the funnies come from customer-auditors and not third-party registrars.

Maybe I'll start that topic.

ALM

You're all hung up on auditors and certification. The documented system is there to be used by the people implementing and developing the process and should be designed as such. For the sake of efficiency and clarity, the best place for the change history is in the document to which it refers, not in the Quality Manual and not in a separate document. Regards the ECN record; Well my preference is not to use an ECN to make a document change but we are still using a hard copy through the development/change stage. Maybe if we were fully paperless, then the ECN would be the best way, though I think I would still go for a brief change description on a history page. It's the easiest to use, which encourages it's use.
An unnecessary document is waste, and so is the time spent maintaining, retrieving and handling it. All waste should be eradicated from the system.
Also; Auditors come in all shapes and sizes, just like other people, and about one in 400 is going to be totally insufferable. The rest are struggling human beings like the rest of us and will respond in kind to kindliness and consideration, with resultant benefits all round. Why butt up against them over something which is, at worst, a debatable issue? Why risk a critical observation and bad feeling? By all means, be prepared to draw a line in the sand, but why draw it here?
rgds,
John C

Typically i turn on 'track changes' and note in the margins where the changes are in the proint out. It also tracks who originated/reviewed, and their comments/annotations (can even be manually entered by the doc guy if not on line) From there the sophistication of the company rules. Even companies that are not networked, can do it by passing a disk....and the 'keeper' of the records gives it a transaction number that appears on the document if more detail is needed for the reason for the change, etc. Or if a paper system is what they really want, print it....Set it up with a header for pertinent info that the system requires( an ECO form if you will)

There are several levels of "paper"/'paperless" that can be used in any company.

RE: serving the auditor
Absolutely, there is a lot to be said for being 'auditor friendly'. And one needs to choose his battles carefully...I agree. But don't let an auditor lead you to doing something that adds no value, just to please him/her. Take what they say under advisement, and look to see if it will add value, after they leave. If not...then say so in your response..clear and consise..If you can justify it, and still meet the intent of the standard, you will be fine, and without an argument.

OH YA...I have one small (3 man)company that has 1 control book/manual, also serves as the master hard copy. (I have the soft copies) They choose to mark up changes to documents in the book, sign and date...as they go along. Then if (and it has not happenned yet) there are serious changes, or several, they call me in to make them and reprint. Otherwise I am in every 3-6 months for audits, updates, reviews, reports, etc. and I make the changes then using the method above.

If it's a print I typically want change info 'readily' available.

If it's a procedure, change info is typically not immediately important.

All depends upon the document, in my eyes.

JOHN C - We'll have to agree to disagree on the location of the "nature of the change" issue.

IMO, it serves no useful purpose in my business to have the nature of the change "right on the document" or even another location in said manual. In fact, my having revision history in another manual is not all that different from having it in the back of a page in the same manual.

Our experience has been that if a particular current procedure has not been working properly, having the nature of the change readily available MIGHT encourage someone to try to do it the "old way." (Just one example, anyway.) So, "for the sake of efficiency and clarity," our experience is that it is better NOT to leave something distracting to the way a process is to be CURRENTLY performed.

As for debating with the auditor, remember, YOU are in the driver's seat. Regardless of what the circumstance is, the auditor is NOT to dictate to you to do something that is not required by the Standard. If an auditor was to debate the above issue with me to the point where it was "unfriendly," I would "chuck him/her" and request a new auditor. A "critical observation" about something that is not a requirement of the standard and "bad feelings" are certainly NOT what the auditor is here to be generating.

Whether or not your interpretation of an item is "critical" or "non-critical" is not the issue. No matter what the circumstances, do you meet the standard or do you not? If you do, then the auditor is to move on, not debate the issue with you. To me, this one is cut and dry and any further discussion on the topic by the auditor is (IMO) "combative" and not "cooperative," the latter being how it should be.

Conclusion: Having a separate record of revision history is no different than having it in the back of your manual, or even on the last page of the procedure in question. My removing it from point-of-use eliminates the possibility of someone wanting to try something the "old way."

ALM

ALM,
No, I can't agree to disagree. The original question was; "Can I eliminate the change history and refer to the ECO that controlled the change?" (or words to that effect)
If your answer is that you would challenge a registrar that wrote that up ("asked for more"), then you are misleading the person that asked the question. Clause 4.5.3 states that "Where practicable, the nature of the change shall be identified in the document or the appropriate attachments." So, your only challenge can be on the grounds that you have evidence to show that it is impractical to do so. In your case, the only evidence you offer is that people might revert to the old method. Tell that to the registrar auditor and you are likely to open a can of worms and a string of questions relating to 4.1 and 4.2. I would't recommend it.
I agree with the requirement (in the document or attachment) and would find it impracticable to do it any other way. My practical reason being that it eliminates a step in the process, so reducing cost and a potential source of error. This is an engineering principle and may be the reason for the requirement although there is no indication of this in the standard.
Regards the response to the registrar; As I said, I would not draw the line in the sand over this issue. After reconsidering to the standard, it seems that those who would seem to be quite out of order. Note though, that it does not ask that you hold the complete change history. It states 'the nature of "the" change, which can only be interpreted to refer to the most recent rev.
Just for completeness; I would put the change history on an attached sheet, such as a cover sheet or a sheet at the back. You could imply from the wording of 4.5.3, last paragraph, that it could be in the margin, or as a footnote or shown by some means within the text. As someone said, that would lead to clutter, could be distracting or misleading, and I think it would be most unsuitable. However, while I have the freedom not to do it that way, I must concede that if someone prefers it, then it is within the requirement.
rgds, John C

[This message has been edited by John C (edited 27 June 1999).]

Marc,
Which brings us back to the old 'interpretation' issue; I don't believe in interpretation because 100 people can hold 101 different views on any given day, and 1001 different views over a period of three months. What could be clearer that the last paragraph of the clause; "Where practicable, the nature of the change shall be identified in the document or the appropriate attachments."
One sentence, 17 words. Which words do we disagree about? It doesn't mention 'preference', 'importance', 'type of document', but does give an option, conditional upon filing, on or attached to the document, being impracticable.

I stand by the words and my little pocket dictionary.
rgds, John C

Marc,
Which brings us back to the old issue of 'interpretation'; On a given day, 100 people will have 101 different interpretations and 1001 over a 3 month period, which is why I stick to the text. The last paragraph of the clause is quite clear showing that the change information is to be held on, or attached to, the document where practicable. It doesn't say anything about opinion, importance, etc. How can we disagree over 17 simple words? Which word means something to you that is different from the meaning in my little pocket dictionary? I stand by the text.
rgds, John C

Sorry, I didn't notice the change to a new page and thought my first response had'nt filed. Now I seem to have lost the edit function.
John C

JOHN - MY answer to the question about eliminating the change history and referring to the ECO on file would be a resounding YES. I would not mislead the person who asked the question and I thought that my original response answered the question.

Moving on...

Well, I suppose what it then comes down to is what is defined as "practicable?"

I understand your concerns over the one example I cited for why it is not practicable for me. One cannot legislate or even train-out the curiosity of people.

Now, are the auditor and I going to get into a pissing contest over what is the definition of "practicable?" I think not.

My definitions of "not practicable" include:

1) My favorite and, in my experience, unchallengeable: "It is non-value added. Our current document control system provides for Document Change Orders. The nature of the change is on file with "ALM." Therefore, it is an unnecessary repetition of effort to also take the time to create (a new revision history document within the manuals) or (type the nature of change within the procedure itself), even if it is only a summary of the actual change."

2) "It has been our experience that it creates more questions in the minds of users than it does provide answers or insight. Due to this fact, we removed the "nature of change" from points. Additionally, we review historical data when there arises a time for a potential new revision with all appropriate personnel."

3) "Our quality system wasn't designed to accommodate the nature of changes within the documents and we have provided a more than adequate alternative to cluttering up our manuals with information that will not be used during day-to-day operations WHICH MEETS THE STANDARD."

There are a few. You don't have to like them, but as previously stated, it has never been an issue with our registrars. In each case, it is not practicable in our eyes and does nothing to add value to the documented Quality System.

Additionally, I have always thought that leaving historical information (old, non-current documentation, IMO) flies directly in the face of 4.5.2 (b) >>> "invalid and/or obsolete documents are promptly removed from all points of issue or use, or otherwise assured against unintended use..."

Granted, the documents are removed, then why "where practicable," are we going to put back into the "document or appropriate attachment" information (even summarized) that has been deemed obsolete?

No auditor worth his salt will hold-up my certification over such a non-issue. The PURPOSE behind the specific parts of the Standard that we discuss are most definitely covered. I would defend how we have set this issue up against any auditor who would have a problem with it.

Just another viewpoint...

As for your not agreeing to disagree... that is your prerogative. However, we have been certified for 4 years running with a documented Quality System to ISO 9002 Standards. The way we have set it up must be correct and I understand that there is more than one correct way to do it.

ALM

[This message has been edited by ALM (edited 28 June 1999).]

the document and the point of use as well....if lots of sites use the document and need to train to the new change, then the nature of the change being available is more important than if the document is used primarily by the function that changes it, or it is transparent to the factory.

AND to answer the original question....which I guess I missed as well....YES

JohnC wrote the items with the "[[[ ]]]" brackets.

[[[Sure, but I'm not engaging in this discussion to find out what you think makes you right, or to prove to you that I am right. I'm testing my own ideas and methods and trying to find out where I am wrong. As soon as you show some evidence then I'll be the first to thank you.]]]

No one needs to thank me. The original poster asked a question and I gave him an answer based upon my experiences.

I didn't realize that this was the direction that the discussion had turned. You are certainly more than welcome to have an opinion about the subject. My reply to the original poster was that my experience with different registrars was that having the nature of the change in the document or as an attachment has not been an issue. Unless I misread his original post, that was the crux of the matter. Could he eliminate the "nature of the change" on the document and simply refer to his ECN records? I say yes.

As for your methods and experiences go, continue as you wish. Short of sending you years of audit results from our registrars, the "proof" that I have offered that I am "right" is continued certification with no majors, minors, or even "opportunities for improvement" where the nature of the change issue is concerned. I think that this is evidence enough.

[[[Look; If I were in your position I would just say that for various reasons it is not practicable in your case. I don't care what your auditor thinks of it. But, that's a specific case and you can't answer the initial question, which was general, by showing specific examples. You need to give an answer that covers all cases.]]]

The answer is YES. He does not NEED to do it. That covers all cases. All someone has to do is show even the slightest evidence that it is not practicable for them and that is the end of the story.

I believe that the original poster wouldn't be asking the question if he thought that the task was "practicable" ---> he cited the redundancy of the task in his original post.

Even using Barb's excellent example of a situation where it might be necessary, in today's technological world (phones, faxes, scanners, networks, etc.) one could still make a case that doing so would not be practicable and that the communication of the historical changes to documentation was handled any number of appropriate ways to meet the requirements of the standard.

It isn't a matter of me "thinking" that I am right, the results speak for themselves. You are the one who made the blanket statement that YOUR opinion was "the best way" and intimated that for the sake of keeping peace with an auditor who will potentially call you on something that is not REQUIRED, one should design their system to accommodate them. You said that he "needs to keep it." That is wrong. If he deems it not practicable, he absolutely does NOT have to keep it. The day the Standards uses the words REQUIRED in the above topic, you simply do not "have to keep it."

Conclusion... all of our interpretations and practices aside, the original question was and still is... "can I eliminate the revision record from the manual itself and keep all changes available for review in my Change Notice files (ECO's)?" The answer to his question is YES, no evidence, interpretations, opinions, experiences necessary. He absolutely can.

ALM


[This message has been edited by ALM (edited 28 June 1999).]

John:

Please don't take this as a personal thing. I enjoy your input here and I don't want anyone offended. I offer this in respect to interpretations:

You said Which brings us back to the old 'interpretation' issue; I don't believe in interpretation because 100 people can hold 101 different views on any given day, and 1001 different views over a period of three months. What could be clearer that the last paragraph of the clause; "Where practicable, the nature of the change shall be identified in the document or the appropriate attachments.The words where practicable (we might say appropriate instead) are the gateway to interpretations in this specific scenario.

For the most part I make my living interpreting ISO9000 and QS9000. I tell clients to be prepared for auditors with 'idiot' interpretations. I also tell them they have to understand the intent of each sentence or paragraph to be able to interpret the requirement with respect to their company and their industry.

This whole site is based upon the fact that interpretations are part of the game. If there was no importance in interpretations. I started the site and, as is on the first page of the site The Beacon for Direction Thru The ISO9000 - QS9000 Fog and 'Intent' Blurrr-r-r...This was (and is) based upon the fact that both ISO and QS are vague even when they appear to be precise

In the QS9000 arena, there were, and though they said there would be no more, there are now a few (more to come) interpretations on the latest revision.

John, no offense, but interpretations are what it's all about. It's why people participate in the forums.

-------

Alm, if you want to quote someone, there is a neat, easy way to do this. 'COPY' the text and PASTE it into your response. If you review the 'vB Code' functions you will see it is easy to do this Alm, if you want to quote someone, there is a neat, easy way to do this. 'COPY' the text from the message and PASTE it into your response. Obviously you don't have to do this, but it does make the quoted text easy to see. And it's real easy! You can even do lists and stuff. Basically it's 'Easy HTML'.

----------

Anyway, to go back to Mark Smith's original question can I eliminate the revision record from the manual itself and keep all changes available for review in my Change Notice files (ECO's)?"The answer is Yuppers! (Yes). You can keep them any **** place you want. Do consider 'readily available' as an auditor interest.

[This message has been edited by Marc Smith (edited 28 June 1999).]

Alm,
Sure, but I'm not engaging in this discussion to find out what you think makes you right, or to prove to you that I am right. I'm testing my own ideas and methods and trying to find out where I am wrong. As soon as you show some evidence then I'll be the first to thank you.
But I'm shutting down now and leaving my present place of employment, so I can't continue the discussion for a few weeks.
Look; If I were in your position I would just say that for various reasons it is not practicable in your case. I don't care what your auditor thinks of it.
But, that's a specific case and you can't answer the initial question, which was general, by showing specific examples. You need to give an answer that covers all cases.
Thanks again
and rgds,
John C

IMHO, removing the revision history record on the quality manual. Would also reflect on the Document Control Procedure. (That was in our case).
Having a long list of Revision Record would be a problem?
Raffy

After reading this whole thread, I realize I had no idea this was such a sticky subject. I do, however, see the value of keeping the revision history out of the hands of assemblers and machinists who are more focused on doing their job rather than trying to determine which set of instructions they should follow. It's just too easy for them to start reading the wrong page and yes, there are cases where they might be tempted to try it the "old way" if they experience problems. What we are currently considering here is to have a record of changes at the end of the document which refers to a separate ECO log where the details are recorded. This links the two together without creating confusion on the production floor because the document shows only the current procedure and refers to the "old way" by number only. Anyone else doing something similar?

At end of each procedure, we have a small table that lists the rev levels and there is a space for a summary of change made. Each doc revision does have a document change notice which carries info such as why it changed and how it changed. But not a line by line rendition. I am not numbering the DCN's, but simply refer to them by the doc number and rev level and name the electronic file that way.

Where do you keep the detailed description of what changed?

I keep an electronic history folder of the old revisions of the docs and in addition,for forms, I keep a hardcopy in the plastic sleeve behind the current revision in my master log of forms.

If anyone needs to see details of the changes they can make the comparison themselves. :p

Nice. I guess it helps to have a little OCD in this job, huh?

Yeah, maybe that explains why I wash my hands so often and have to circle my chair exactly 3 times before I sit down!

Actually, keeping files and matrices etc. is not really my cup of tea. But having the old forms has come in handy as we have discussed further revisions. I'm able to pull them out and say "well we used to have the form with that column but it was taken out.. so why are we talking about putting it back?"

Wow - deja vu! I think I've had that exact converstation before...

Skinning the "Revision History" Cat,

So we all do it a little bit differently eh?

In my recent experience (that was just this week insulted by a hail of verbal garbage...) we do things differently for different documents.

For QA Policies & Procedures the revision hx is in them on the last page. This we find valuable for doing audits where "You did it that way? Why?..." well sherlock, the P/P changed midway through the year!

For Eng docs, the hx is on a separate cover page on the server, same file, since they can become cumbersome.

For drawings, it is on the page itself. (Marc said he likes this for drawings, and I agree...)

For procedures (work instructions) we always state "Latest revision", which eliminates the need to amend the procedure every time a referenced document get changed.

Another interesting thing happened here. Our Doc Manager would circulate a document for approval, and then would selectively accept or reject comments based on personal preference.

We fixed his highly intelligent methods (so high I think he was in the clouds!), and told him he MUST keep all editing comments made to documents, and seek approval of the team to accept or reject them. The amended document must have the marked-up (commented) document attached to show what comments have been accepted/rejected in order to obtain approval. We will see how it goes from now on. (this is really a gaping hole in the procedure that is now getting a welded plate!)

Before you etch into stone the "proper" methods for revision hx, consider: What is practical for the revision hx? Where would you need it?
But do keep it somewhere!

A Blast from the Past!

I wonder what ever happened to John C and ALM...