1 reply to this topic

[Agrumeambu]

Hello !

 

Since we are building our programs from scratch, I'd like to change the way we have been naming and codifying our SOPs.

 

What have you seen in your industries ?

 

Here is what we have done in the past :

 

 

QA-PRO-100 Building inspection

QA-REG-100 Building inspection form

QA-INST-100 Building inspection work instruction

 

Then we would have the same principle for operations (OPS-XXX-XXX), maintenance (MTN-XXX-XXX), etc. 

 

The line between departments is hard to see sometimes, which would lead to confusion in the team. We also had different ''series''. For example, 100 was building, 200 was suppliers, 300 was equipment, etc. 

 

IA gave me some examples that were more like this : 

✅ Warehouse & Logistics (WH)

7. SOP Code: WH-RCV-009 Ingredient Storage and FIFO Rotation (Rev. 2)
   Title: Ingredient Storage and FIFO Rotation
   Purpose: To manage inventory using First-In, First-Out to reduce waste and ensure freshness.

8. SOP Code: WH-DSP-012 Product Dispatch and Load-Out Protocol (Rev. 1)
   Title: Product Dispatch and Load-Out Protocol
   Purpose: To control the dispatch process, ensuring correct orders, hygiene, and transport compliance.

 

 

I find that having multiple Process Type would get confusing, but maybe it is better ?

 

Thank you !

[jfrey123]

When I'm given the choice, I default to a 4 digit system like many of the GFSI codes use (1.2.3.4) just because it's infinitely expandable and lets you easily insert sub-policies in-between two existing documents just about anywhere.  First digit always is the program itself, second digit starts to number each SOP to support and accomplish the program, third digit can be work instructions related, fourth digit can be research or data or whatever else you need.  I usually split my FS-QMS into around 26 "buckets" or chapters, so we'll end up from 1.0.0.0 to 26.0.0.0 with all the forms kept within those chapters. 

 

For forms, I like alpha numerics like you listed (ABC-123-1.0) where the alpha can be the department (QAC, PRO, SAN, WSR, MAN for maintenance, etc.); I always started the numerical at 100, but in in theory you could start at 001.  Then the 1.1 was a Version.Revision code, where minor changes could be handled with upping the revision number but major changes bumped the version number (original docs were 1.0, small revisions brought 1.1, 1.2, 1.3, but then a major change would bring us to version 2.0).  It's really handy to have version numbers right in a form's control number, because I document the changes/revisions on a separate log in order to keep my forms short and sweet.  The Document Control Register shows last date revised with the current version number that should be in use.