Document control – make it less of a chore and more of an asset
When I first arrived at my current role, I had come from a 19-person QA department with at least one or two people dedicated each to a portion of our program.
Now I was a one-man crew, but the SQF code hadn’t changed. I had to reexamine my interpretation of the code to focus on the basic requirements and how I would be able to meet them with whatever capacity I had. This meant that a lot of “fluff” had to be removed from my previous experience with compliance. Three audits later and no one has missed any of the fluff that was once there.
And now I see it everywhere! Documentation is one of the worst offenders.
We’re all working way too hard on the minutia of document control. Here are some tips and tricks that I picked up along the way to making my system leaner. Note that this system was in a relatively small company (50-100 employees, single site, 7 process flows), so not everything would translate as well to a bigger or multi-site food company.
As usual, let’s start with the applicable sections of the code so that we know what we’re being audited against:
2.2.2 Document Control (Mandatory)
184.108.40.206 The methods and responsibility for maintaining document control and ensuring staff have access to current documents shall be documented and implemented.
220.127.116.11 A register of current SQF System documents and amendments to documents shall be maintained.
18.104.22.168 Documents shall be safely stored and readily accessible.
22.214.171.124 All changes made to food safety plans, Good Manufacturing Practices and other aspects of the SQF System shall be validated or justified.
So, to distill these requirements down, you need to have a written program for maintaining controlled documents, staff need to have access to them, and a register (list) of changes needs to be maintained.
This ends up being a relatively simple requirement, and one that naturally occurs with a well-maintained document control system, but that’s where it can become burdensome. Rather than holding to the basic principals above, many practitioners go overboard with historical recordkeeping, revision tracking, restricting control, and proliferation.
Before we go any further into the details, I’m going to save you a lot of trouble and start with my golden rule:
Quality Management System Golden Rule: Never make systems to “pass audits”. Make systems that work for your company that help it make safer/higher quality products more efficiently.
An audit is once per year, your systems need to work the other 365. It’s your job as practitioner to explain to the auditor how your system meets the code, not to make everyone else at your company figure out how to make your annual chore easier.
Let’s get started!
I love to look at the headers of documents when I visit other companies, and usually have the opportunity to do so when I sign into their visitor log before entering the plant. Here’s an example of what I normally see:
I mean, it’s very thorough, there’s a lot of information there! It looks professional and there’s nothing wrong with it necessarily.
But holy cow, let’s look at everything on here that needs to be reviewed or updated any time you update the SOP.
Let’s take each of the components listed in this example and look for some ways to make our lives easier, while still meeting the requirements of the code.
SOP names and numbers
The numbering system of your documents can carry a lot of useful information, or it can be completely arbitrary. I opt for the former; however, the type of information it carries needs to remain consistent for years to come.
One pitfall I often see is naming SOP’s after sections of a GFSI scheme/code. These codes are eventually revised and then no one has any idea why their product rework sop is called i.42.3.iv.(a)7. Never mind the fact that this ultimately forces you to create many more SOP’s than you might need simply because you want to use the numbering system (I need a waste disposal AND a waste management SOP!).
If you want to reference the code, maybe do it in your register.
Another trap is to incorporate too specific information into your documents, such as the names of specific vendors or customers. Vendors and customers will change over time, but your processes, location, equipment, and documents may not, try to keep them independent.
My recommendation? Come up with a numbering system that will allow for unique codes up to 4 digits in length (I hope no one ever exceeds 9999 controlled documents…), and use a precursor to designate either a location, a division of your business, or my preference- the hierarchy of the SOP. We’ll talk about this later.
And so, help me, unless you have a very compelling reason, don’t make it alphanumeric and you’ll never have to worry about mistyping SOP O0oiI1llLQj88B8.
SOP Revision Information
Revision control is essential to good document control. But let me ask you this, who’s using that revision number on the document you’re editing every time? Presumably as part of your control process someone is in charge of purging the building of older revision copies when the new one comes out, so that person cares. But again, does that person really care that this is the 18th time you have revised this controlled document, or just that they know they have the most recent one?
My recommendation: use the date of revision or the date of approval for your revision number. The number is arbitrary anyway and having a revision number of 20180711 (YYYYMMDD) very clearly tells me that the version I’m holding is newer than version 20170620. Heck, it provides me even more information in that I know how old the document is.
And did you notice? By using the revision date as the revision number, we’ve eliminated one of those boxes from our header above.
SOP Revision logging
We noted that this is a requirement above, but again, we need to do what’s right for our business, not necessarily the audit. What I most often see is a table or log at the end of every SOP that looks something like this:
Why. Who’s looking for this information?
Yes, it’s a requirement, yes, the situation miiiiight arise in which you want to know when you changed the requirement and why. But for the amount of times this actually comes up, it doesn’t need to be readily accessible and updated inside every single SOP or controlled document.
My recommendation: keep a register every time you update an SOP in a spreadsheet or some other easily managed document. An excel table works really well and is much more searchable and indexable than text inside your documents.
In combination with this, keep the old versions of your SOP’s properly archived, and if you ever need more detail than what’s in your revision index above, you will quickly be able to look up which revision has the edits and pull it from your archive.
For similar tables and archive options, see my post on making SQF registers.
Not all documents are created equal. Your checklist for making sure the equipment is turned off at the end of the day does not need the same level of scrutiny/control/training as your HACCP plan does.
SOP hierarchies are the most powerful way to make document control simpler. By identifying which level of documents need what level of company control, you can reduce the necessary revision control etc. needed to maintain them. I prefer a 3-tiered system:
- Tier 1: Business policy level SOP’s, food safety plans (HACCP), recall plans, etc. that require top management review and approval and have a large impact on the quality management system.
- Tier 2: Operations level SOP’s and work instructions that support the tier 1 documents and have a large impact on day-to-day business (e.g. product hold and release policies, supplier approval). May require additional management review and approval.
- Tier 3: Documents, checklists, visual aids, lab instructions, specifications, logs, databases, and other documents that provide instructions or records for the other tiers. Need to be controlled but may require frequent edits and really only QA/SQF practitioner and the people who use the documents daily care about them.
While I control tier 1 and tier 2 documents by requiring no copy-to-copy duplication (must print from file only) in a locked PDF, tier 3 documents may simply be word files for a complaint log or production paperwork that people keep extra copies on hand. Revisions may need to be made frequently and don’t need a lot of people to review/approve, we just have to track them somewhere like our revision index above.
Speaking of approvals:
Approval information and signatures
Probably the biggest time sink in the revision process. You can create a new SOP in 2 days, but it will take your VP of sales 2 months to put their signature on your new labeling SOP.
We can make this easier.
Step 1: Introduce a document hierarchy like above so that you need as few signatures as possible for the importance of the document. Your HACCP plan may need signatures from the CEO, but your waste management SOP does not need to make the rounds on the top floor.
Step 2: Remove the names. Guess what, you may not have the same VP, manager, or practitioner 5 years from now. But when that name changes, your SOP is now obsolete even though it remains in place and effective. I’ve seen in happen in audits when QA managers take over, suddenly the auditor thinks the HACCP plan isn’t valid because it references another name.
Instead of “Elon Gates, VP of finance”, there’s no reason your SOP can’t say “VP of finance” and be signed with someone having that authority. SQF already requires you to have a clear organizational chart (126.96.36.199). Use it to support your signatures!
Step 3: When routing documents, highlight the changes that were made or indicate that there were no changes to the document. If the CEO doesn’t have time to review your supplier management SOP for kicks and giggles, it’s always fast and easy to sign off on the status quo. If you decided there was no need for edits this year, let them know so they can sign and move on.
A document for every requirement…or not
Your goal in having a lean document control system is always the same, follow the golden rule, and do it with as few documents as possible.
Many sections of the code aren’t right next to each other but lend themselves well to being combined into a single document. A prime example is supplier approval and contract service approval. They’re very similar processes and would generally route through the same employees at any level. There’s no need for a separate document for each. Some of my favorites are combining recall information with product identification, and combining product hold and rework procedures with corrective and preventive action procedures. Generally, we don’t rework or hold anything without CAPA, and vice versa.
As I mentioned above, just because there’s a code requirement does not mean you need an SOP. You need to demonstrate that you have defined the policy and procedures. You may do that with a controlled document, or it may be part of your contract service agreement with your micro lab!
Ditch the Fluff
Finally, as pretty as a document may be, we include a lot of fluff in our SOP’s as in the original example above. Here are a few ones that love to show up:
- Headers and footers that contain the same information. These are just asking to get inconsistently updated, useless, and makes the documents busy and intimidating.
- Names of document editors: the approval signatures are what matter. If you want to track who actually played with the word file, record it in your revision index, but it has no helpful place on your SOP.
- Creation dates and modified dates. Modified date is helpful for revision control on the floor (see above) but WHO CARES when you first wrote the SOP? It’s policy now, why does the creation date matter to anyone?
- “Definitions” sections. If your SOP needs a secondary guide to understand what’s written, your prose and nomenclature is so grandiose as to be nebulous to the median literary enthusiast. Define terms within the document so that a reader can understand them, and also understand that these were written for YOUR facility (golden rule), you don’t have to define all your industry trade terms, you can tell the auditor what they mean.
After integrating these and the tips above, this is what the front page of my SOP’s look like.
All the required information is there.
- I know what this SOP covers.
- I know what tier of document this is via my SOP hierarchy.
- I know what revision it is and how long ago it was approved by the revision date, and I could tell if this revision was newer or older than a random copy.
- I know where to find the digital copy if I need to print it.
- I know the SOP number so that I can look up the revision history in my revision index or open up an archived version.
- I use that signature box on the first page of every SOP as a template, and line out the names that aren’t necessary for the tier of the document. That header appears on every page, keeping all the information together.
Keep it lean, keep it clean, and follow the golden rule. Soon you’ll find your team spending less of their time managing documents and more time improving the processes they describe.
Austin Bouck is a quality assurance manager at a regional beverage company in Oregon, USA. When not at work solving technical quality challenges, he continues to ponder food safety issues on his blog, Fur, Farm, and Fork, which helps him stay sharp and share his knowledge with other professionals and the public.