Document hierarchy for Process mapping for ISO13485

[Jonathanlai928]

So I'm new to this company and want to map out their processes. Traditionally the SOPs are text based and they are split between SOPs and Quality SOPs (QOPs).

Would it be reasonable to add process maps then generally redistribute the SOPs into work instructions or remove them if they are covered by process maps?

The heirarchy will then be MANUALS/POLICIES - PROCESS MAPS - WORK INSTRUCTIONS - FORMS/RECORDS

Or ... Would it be beneficial to keep it like this MANUALS/POLICIES - PROCESS MAPS - SOPs - WORK INSTRUCTIONS - FORMS/RECORDS. If I do that though I'm not sure it won't become confusing as to the purpose of the SOPs in that context.

There's no right or wrong I know, just wondering what people think or do in their organisations that implement process maps?

 

[Jean_B]

Hierarchy establishes which information overrules which other information. The higher level should take precedence and prevent local deviation, but if local deviations do occur there is not an automatic slap-back. Instead the assessment should be made whether it is an improvement worthwhile to echo back up the hierarchy and thus down again to other places; or whether to bring it back in line. The main thing there is to get lower levels in the habit of updating the documentation to what they are doing, and not lock it down so practice deviates from description without being noticed.

Then, hierarchies should not work in 'levels'. Many a time an additional level of the same type but with adjacent scopes for more detail would have been handy. So do not let the 'depth' into the hierarchy define what something is. Hierarchy to me is more about scopes; the authority is a consequence of that.
A bit like the federal government generally being above states, who are above municipalities etc., but there are state national guards, but also a national army; or state government being above provinces, who are above municipalities, while also allowing for trans-provicinial/municipal organizations such as water/roadway maintenance not being national but differing by type of transportation.

When it comes to numbering do so without including type into it, going into the depths by putting a separator for each step down.
The exception is forms. Decouple forms from the depth numbering, because often you will see a form flowing across multiple processes, or the same form being initiated by multiple processes.
Pure policies are above anything else, but commitments and policies are often in the manual as well to cut down on separate documents. If anything it is important to distinguish within the manual what is descriptive and what is policy, and be careful in the wording for which policies are hard (nobody is allowed to deviate from it) and which are soft (the preferred option is stated, but rationalized deviations may occur). This often gets lost in the textbook like style of manuals.

Though that's what I'd do if starting fresh, alas my reality is not so. Currently we have process flows as the first section within our procedures, with section references for the details of the steps, and a policy that read and understood training is only assigned if mentioned within the procedure. This works well enough. Sometimes we either sidestep a procedure which should be under another one, or we have documents below procedures which are written as if work instructions, but with the authority of a procedure. The decoupling of forms is something that would make our lives easier, but isn't a disaster in comprehension. A hugely important but oft forgotten document for us is the overview of where to store the records generated from a form once it is completed, and what the retention policy is (duration, digital scan allowed, off-site storage allowed etc). This is an odd one out when it comes to the usual types (we call it overview) but of significant value in keeping things tidy and being able to find stuff by personnel not involved daily in the use of such records (e.g. during audits).

 

[Jonathanlai928]

Thank you for that in-depth guidance. Really appreciate it.

 

[yodon]

Another consideration is when you're audited. I allow auditors to see only the Quality Manual and SOPs. These fully demonstrate that we have addressed the requirements. I don't (generally) let them see WIs since they shouldn't need to know how we do things. (And then, of course, show the records and such to demonstrate that we actually comply.)

I don't like to "do things" for auditors, but I do always keep them in the back of my mind.

 

[Sidney Vianna]

I don't (generally) let them see WIs since they shouldn't need to know how we do things.

As a CB auditor i would stop the audit right there, remind everyone that confidentiality clauses are in place and ask again. Refusal to allow auditors to access relevant information, data and documentation is a rule breaker. I clearly remember in my auditing early days, many findings being reported had to do with lack of hardware conformity with engineering notes in drawings available in the work order package. Obviously, as an auditor, I should be able to assess if production, assembly, product realization is being performed against ALL relevant requirements.

 

[yodon]

As a CB auditor i would stop the audit right there

I've never withheld information. The records all demonstrate compliance. I've never seen a need to show an auditor the WIs describing HOW we do things. To me, it's irrelevant. The SOPs say what we do and the records provide the evidence.

As a CB auditor (and I'm sincere in asking, not trying to be provocative), why would you need to see anything else?

There are a few exceptions, my training program for one. I can't really demonstrate full compliance without going down to that level, so I'm happy to share that.

 

[Sidney Vianna]

why would you need to see anything else?

I have already mentioned the numerous cases where I was able to identify lack of conformity with engineering notes is drawings. If I cannot verify FOR MYSELF that work instructions are being followed, I am not doing my job as a professional 3rd party auditor.

 

[Tidge]

So I'm new to this company and want to map out their processes. Traditionally the SOPs are text based and they are split between SOPs and Quality SOPs (QOPs).

Would it be reasonable to add process maps then generally redistribute the SOPs into work instructions or remove them if they are covered by process maps?

The heirarchy will then be MANUALS/POLICIES - PROCESS MAPS - WORK INSTRUCTIONS - FORMS/RECORDS

We do something like this for the Quality System, but don't map the process, rather we will generally spell out inputs and outputs at the policy level:

1. Quality Manual (this is where we keep the hype)
2. Policies (this is where we keep the promises to generate specific outputs from specified inputs)
3. WI (this is where we keep the loopholes)
4. Records (this is where we keep the bodies)

On the product side, after BoM we only have (M)WI and Records. The MWI usually include a diagrammed process flow, but internally opinions vary about this (I don't want to explain why, just that they do). When we have auditors who want to witness product being manufactured/handled, the auditor almost always has a copy of the relevant MWI.

Technical auditors (e.g. from a NRTL) never ask for MWI. Having escorted a couple of these, I assume it is because those auditors know what they expect to see and if it was "done wrong" they would recognize the defect and so no WI is going to excuse it. I'm refering to things like labeling and electrical safety testing. In another life, auditors for laboratory certification would review WI/SOP for particular documentation reasons, but they were familiar enough with what the labs were doing (for standardized tests) that they also didn't need a WI of SOP to assess if it was being done correctly.