Adding processes to a QMS

10 minute read, or just take in the article’s mind map.

If you’re responsible for a QMS, it pays to create an environment where people are happy for their processes to fall under its remit. Do this through adding value. Here’s how I try and ensure a win win for everyone. Remember, a process driven approach is fundamental to ISO 9001:2015.

Throughout, PO means Process Owner.

The structure of this article is:

I use Atlassian Confluence Cloud for my cloudmansys QMS, and at work. I use examples based on this. However, the ideas in this article apply regardless of your tooling choice.

The risk of Shadow QMS

Why should you bother? Alongside poor document control, I think shadow QMS is the biggest risk to QMS.

Shadow QMS is where processes exist outside your QMS, or worse, outside and parallel. The former happens, but the QMS will usually catch up. The latter is dangerous, as it’s often deliberate. Parallel processes mean people know what’s in the QMS, but choose to follow another process.

As well as risky to certification, any reluctance to stay honest reflects badly on the process itself, and on how the QMS is both perceived and functioning. Help avoid this by adding value to process capture. Make it a worthwhile and positive experience. This means being helpful, empathic, and pragmatic whilst demonstrating some knowledge of business process analysis and improvement.

Can you put this in the QMS?

This is how I’m usually approached. Sometimes I know it’s coming because they’ve mentioned it. Occasionally it’s a surprise. Sometimes it’s a surprise to them that I knew it was coming. What’s common is their belief that the process is “finished” and just needs “putting in the QMS”.

Here’s an example. I got a new process from one of our teams. The two page Word document had all the process steps as bullet points. It did outline the process end-to-end. So they’d obviously thought about the process itself, and I applaud this. However, as a narrative, the document was hard work. Furthermore, as a means of understanding and communicating the process, it had no future in the QMS.

Not that I’m complaining. I tell POs that I’m happy to get content in any form. As Quality Manager responsible for an ISO 9001:2015 certified QMS, what’s important to me is that they engage with me, and with the QMS. But I hope they don’t bother beyond the accuracy of the content. I certainly don’t want them spending time on presentation. It’s only the content that will make it into the QMS.

Where to stick it?

This section is a sideways digression. Take a moment to consider what you are slotting new processes into.

I know that a QMS can comprise content in many formats, and, provided it’s controlled, it’ll pass certification. However, as a QMS needs to be communicated, and because it can be used to represent a business, some consistency of approach and presentation is, in my mind, desirable. I’m a believer in QMS as intranet. Hence, I’m a proponent of Confluence.

A lot depends on your starting point:

  • If you have inherited a QMS platform that you need to slot your process into, consider whether you’re happy with how processes are presented? Change has to start somewhere, and it can be gradual. Call it continual improvement. A new process is a good way to trial a new beginning.
  • Are you starting out on your QMS journey? If you’re lucky, you might have an opportunity to choose tooling and do it from scratch. This is where I found myself, and it’s how cloudmansys began.
  • Somewhere in between? In such cases, consider a wrapper for your QMS. A high level mind map is one possibility, as is a simple wiki created in Nuclino – its Graph view would be great for presenting a QMS. I suppose I’m advocating a return to the Quality Manual of ISO 9001:2008, just not so linear, and not in Microsoft Word!

Regardless of what platform you use, you should be proud of your QMS. You should be happy to show it off. The advances in low cost Cloud platforms means you’re spoilt for choice in this respect. Anyway, back to the process in hand…

Process for adding process

As a Quality Manager, part of my role is to take the raw process data and improve it. I usually enjoy doing it. So, to get a new process into the QMS, I:

  • Document it using a standard approach
  • Review and refine it with the PO and key, affected individuals
  • Look at the wider QMS impact
  • Get everything under document control
  • Communicate it
  • Embed it

I’ll now look at each of these in turn.

Pictures and simplicity

Establish a standard way of presenting process. In my QMS, every process goes on a single page that follows this design:

consistency helps communication

Meta data

Process overview detail. This covers things like purpose, owner, roles and responsibilities, inputs, outputs, any parallel or dependent processes, change control and KPIs. All linked where necessary.

Resources

Details and links to the different resources used in the process.

Records

What records are produced by the process. This is valuable at audit time (along with all the other detail).

Flowchart

Pictures just make it easy to understand and explain. I use swim-lanes where roles and responsibilities change through the flow. In Confluence, I use the draw.io plugin.

Notes

I include a table with a row for every point in the process flow diagram. This holds any explanation or elaboration necessary. Some can be empty. Over time the level of detail can grow. But only to the extent necessary. Over documenting must be avoided. Stating the obvious just wastes time, and hides the valuable stuff.

This approach is easy to digest, communicate and maintain. Nobody really appreciates a wall of text. In addition, it makes the QMS very consistent, and dare I say it, pretty. To elaborate, as a QMS can be used to demonstrate aspects of your organisation and its professionalism, it’s pretty with purpose.

Refinement

When I transpose a process from paper or interview, questions arise. Some have been thought about, some haven’t.

Auditor hat

I look at processes from an auditor’s perspective. What would raise doubts in my mind? What threads would I follow? In a recent one, there was a point in the process narrative where the job title changed and became a bit vague. It had a slash in it, like Service/Support Manager, where none had been before. This made me wonder if roles and responsibilities had been fully established. Together with the PO, this was clarified. As a result, I’m now confident that those engaged in the process won’t be confused. Similarly, the external auditor won’t have that line of attack.

User hat

I also look at it from a user’s perspective. Could I follow this? Again, with a recent process, I had a concern. At one point I envisaged uncertainty about Salesforce status. So we clarified this, and the documented process improved. Also, speak with affected individuals. Were they consulted? This can be telling.

Business analyst hat

This might be the trickiest hat to wear, as you’ve got to remember that you don’t own the process. Apply process analysis and help your POs think. Suggest and guide but don’t impose or preach. For example, you could introduce some Theory of Constraints thinking by asking where bottlenecks occur, and how the throughput of the process fits in with everything else.

There are lots of techniques. Use whichever you are comfortable with. Just keep it real and grounded in the PO’s reality. Nothing might come of it. However, you’ll have demonstrated that you want to help, and that you have skills that go beyond just documenting process. I think you need to cultivate both aspects. Eventually it should pay off.

Hats off

All this refinement is part of the job. If I was an auditor for ISO 9001:2015, I wouldn’t be allowed to do it. But I’m not an auditor, so I’m allowed to help and suggest possible improvements.

Putting processes into Confluence also gives the PO fresh perspective. Together, we invariably improve both the process and its communication.

Document control

Outwardly this is simple. I give the process an ID and log it in document control. Confluence takes care of version control, and I set the permissions so that only the PO and I can edit it. I also make sure the process resources and records are under control.

The difficulty can come in making sure the PO and team understand what document control means. For example, I need to communicate that:

  • The original Word document is not the process, no matter how long you have been using it before telling me. Do not distribute it, and if your team members have it, tell them to delete it. From now on, point everyone to Confluence.
  • The process is now under document control, so you can’t just tweak it within the team. If it does need to change, then we’ll control and communicate that change. However, hopefully the act of getting the process into the QMS has smoothed its edges. But, in operation, I do expect processes to evolve. So keep engaging with me.

Shadow policy or shadow IT is a major risk to any QMS. I think it is the key education piece for any certified QMS.

Wider QMS impact

As Quality Manager for the QMS, I assess whether the process impacts other team processes. Within teams it is usually fine. However, impacting other teams can require some checking and, potentially, mediation. For example, in the one I’ve been using as an example, it said another team would do something. So, I asked the question, did they know this?

You may also have to consider wider resource and training requirements, associated risks, performance measures, and auditing impact. New processes can cause many ripples across a QMS. All have to be controlled.

Pointless if not communicated

So you do all this work. It’s pointless if you don’t communicate it to everyone impacted. Also take the opportunity to remind them that it is controlled, it will be audited, and, importantly, that it can probably be improved. You need everyone to help in this.

Ensure a return on investment

New processes all suffer from the same susceptibility. Newness. Processes don’t truly reveal themselves until they are operational. You need to monitor how they are functioning, and how they are perceived. Don’t be surprised by people’s unwillingness to question things on the basis that it’s new and ‘they’, the POs, won’t want to change it so soon. Such institutional tolerance may be a British trait? I’m not sure.

For all processes, build in some sort of review. Even just asking a few of the doers how they find it is good. It might reveal something. More importantly, it shows that you’re being proactive, and that the QMS is not a monolithic construct. When you do get feedback, respond or react in a way that shows it has considered, and not just summarily dismissed. Try and keep people on your side. It’ll help enormously when you do have to be tough.

Also, if you have ISO 9001:2015, update your audit criteria to reflect the process changes. This way, if your Certification Body decides to look at 9.2 Internal Audit, you can show how your criteria are evolving. It will also remind you to ask about the new process next time you audit the affected area. Even you can forget what’s changed!

The answer is usually yes

The seemingly simple ask of “Can you put this in the QMS?” kicks in a lot of process. But, if you have a robust QMS, it should be pretty straightforward. I know it is for me. So my answer is usually yes, but what eventually goes into the QMS tends to get some refinement along the way.

A new, process driven, way forward?

What I’ve described involves me, as Quality Manger, throughout. I’m paid to do this. However, for my own cloudmansys QMS, I’m removing myself from the loop. You too might want to. So I’ll leave you with a taster image. The idea is to let people self service “Can you put this in the QMS?” requests. So it’s a process for a process driven approach.

DIY in cloudmansys QMS

Leave a comment

Your email address will not be published.