Every single thing in a company is a process.

It has been my job, at every company I have been at, to implement the quality system internally. And the first thing you need as the QA officer is to know what is happening in all the systems... which you usually don't, right?

Because a different branch of the company will just start using something, and they'll configure it, and they'll use it for things that absolutely have an effect on the quality of the product. In a regulated industry all of that software needs validating. So you go and find it, and then you try to get these things to talk to each other, which gets really expensive, and then it becomes someone's full-time job to coordinate and validate them.

Most companies know by now that you shouldn't work in silos. Then you look at the tools we have available, a CRM, an HRIS, an ERP, a QMS, a PLM, an MES, and the silo is set up by design, because of the way the tools have been split up.

Look at your CRM (Customer Relationship Management). You find a lead, you qualify them, you go through your sales process, you sell, and then you monitor and nurture. That's a process. Your PLM (product development) is a process too, user needs, verification, validation, the classic V model. So is hiring. Every single thing in a company is a process.

The only thing that is different between all of those systems is the way it's displayed to you. Product development gets a project board with a Gantt chart, sales gets a kanban board, and in your QMS you have procedures that you type in. But they've all got the same anatomy, a trigger, an input, steps in the middle for what you do with that input, an output, an owner, and a regulation or standard they need to abide by.

And a standard, if you look at it, is a line asking you to carry out an action that produces a record. Requirement after requirement, the same thing... so it makes no sense that we're implementing all of this from scratch for every single company.

The tools are separate from each other, and they're also separate from the procedure. Your SOPs sit in a SharePoint folder that nobody looks at.

Say you copy your design and development process into Jira. That's fine, you follow it the first time. Then Jira gets updated, people move on (naturally), and the next project just copies the template from the last one and never looks at the procedure again. That's how you get drift. And it's that way with a lot of things.

I've worked with a lot of QMS tools, and even they work like this. They're configurable, but separately, in the backend. You go to the backend, you look at your procedure, and then you build the form anyway. That's a very long way round.

If everything has the same anatomy, it can all live in one place, with the display changing to suit the person instead of the system changing. The engineer still gets a project board and the salesperson still gets a pipeline, and they're looking at the same records.

Then the procedure is the form you fill in, so what you wrote down and what you did stop being two different things. Your quality manual, which is supposed to list all your procedures and how they interact, gets derived from the procedures that exist, so you never have to remember to update it (everyone forgets). Same with the org chart, which is one of the things people get findings for all the time.

By the time you convince a company it has a problem, it's usually kind of too late. It's just before certification, the company is already up and running, and the six systems are bought.

If you're at the start, you haven't bought them yet. You get to build it in the right shape from day one. ⋆˙⟡