8 replies to this topic

[JPO]

Let's pretend that I have a series of specifications for products.

 

I build a snazzy form, lay it all out, get it approved, and I'm happy.  That's Revision 1.

 

Then, we make a change to the form.  We revise the layout, add a section, get it approved, and now we're at revision 2.

 

Then the vendor calls and changes the limits on the specifications.  Rather than 300 doohickeys in the box, there are now 275 doohickeys in the box. 

 

I want to track the changes to the DATA in the form too.  It makes sense to be sure we have the latest information going out when we send out specifications to customers and it's important to track changes too. 

 

BUT, that's not "revision 3".  It's the first revision to the DATA on the form, but it's the section VERSION of the form.

 

Does this make any sense to you?? 

 

If so, how are you managing things like this in your processes?

 

JPO

[Anika]

Hi JPO,

 

I would still add the section change on the revision log.

Does the change effect quality/food safety program? ccp? sop? sampling testing plan? labels? formulation/specification? process/operating parameters? shelf life ? process?

 

If it's yes to any one of them, I would do a revision log and version change

[mgourley]

I guess it all depends on how much work you want to do.

 

A couple of assumptions:

 

1) you have one document format with a document number

 

You have 300 specifications that are all "Document #: 3.6.1.1 Product Specification" (because they are all the same format), because you don't want to do "Document #: 3.6.1.1 - 3.6.1.300. 

 

2) But the actual document title is "3.6.1.1 Product Specification Widget"

 

I would make that particular document Revision # 2.1. Because the format of the document has not changed, some minor data has. 

 

3) I would put the following in the document revision log: Your document revision log format, of course applies:

 

Doc #: 3.6.1.1 "Product Specification"  Revision: 2.1  Date of Change: xx/xx/xxxx Reason For Change: "Changed Product Specification for Widget per Customer to include 275 doohickeys in box vice 300".

 

If that makes sense.

 

Of course you have to make sure that the most recent document is in use and that any training about the changes has taken place and is documented.

 

There are of course all sorts of "rules" about document revision out there. But if the standard you are audited against does not specify one of those rules, make it easy, ensure the document in use is the correct one and have that documented.

 

I have roughly 400 SSOP's that all have the exact same document format. I'm not going to change revision numbers on all of them if I decide to change a cleaning practice on one piece of equipment.

 

Marshall

[Charles.C]

Hi JPO,

 

I assume the form is regarded as a document.  IMO the document then includes the data.

There are innumerable revisioning systems in use. Here's a fairly logical scheme, not that I've used it myself -

 

http://www.qualitysy...on-date-or-both

[JPO]

We are currently thinking about REVISION X and VERSION y.

 

We may have a specification that changes data a dozen times based on crop min-max, but the document layout, content design, etc. all remain the same.  That's a lot of version changes with no revision changes.

 

the goal is to have every spec have the same REVISION, so they all have the same look, layout, etc., but have the correct DATA per VERSION. 

 

these file paths need to get longer...

 

Thanks folks, (again)

[Miss Tammy]

We attach a copy of the current version with the prior one, highlight the changes and file.  Not very high-tech, but a fast and easy way to see what changes have been made.  If it is an electronic document only, we add page 2 and create a revision log with date and reason for change.

[GMO]

We have a similar system; if I understand this correctly then you have a format for the specification which is document controlled but then that is used for several different products which each need version control.  We do something similar for ingredients.

 

What I would do is have a code for the document, e.g. FS01 and an issue number for that which would be at the top and bottom of the document.  On this document I would have fields at the start or end for the issue number and date for that specification (i.e. not in the header and footer).  Then I would save the file with the ingredient name, e.g. FS01 White Granulated Sugar and within that it would show you it was issue number, say 10 of the template and version number, say 2 of that particular specification issued on 13/4/16.  Is that the kind of thing you mean?

[JPO]

We have a similar system; if I understand this correctly then you have a format for the specification which is document controlled but then that is used for several different products which each need version control.  We do something similar for ingredients.

 

What I would do is have a code for the document, e.g. FS01 and an issue number for that which would be at the top and bottom of the document.  On this document I would have fields at the start or end for the issue number and date for that specification (i.e. not in the header and footer).  Then I would save the file with the ingredient name, e.g. FS01 White Granulated Sugar and within that it would show you it was issue number, say 10 of the template and version number, say 2 of that particular specification issued on 13/4/16.  Is that the kind of thing you mean?

Yes, essentially what you said.  The format is document controlled but the data in the form changes. 

 

Revision for the different format, version for the data change.

[Charles.C]

Hi All,

 

IMO the method of referencing the document is arbitrary as long as user objectives as exampled in the OP are reliably achievable, ie -

 

It makes sense to be sure we have the latest information going out when we send out specifications to customers

 

Seems to me the various updates in terminologies are all "revisions" of one kind or another.

 

If you have a document containing  one "label" for text format, say "T0001" and another for data, say "D0001", any material change in either Text or Data  will necessitate some change in a "1"  IMO.

 

Personally i prefer to include the full reference classification of a document in the PC filename so I prefer more basic numbering methods. Admittedly  i do end up with a lot of 0.01 - 0.10s though.

 

Large numbers of similar "things" are, like hazard analyses, maybe better addressed via grouping / documented  lists. I suspect always likely to be a headache one way or another in the current context.