C
Hi,
I'm about to embark on something of an epic journey into Quality Management Systems.
I have a QMS of six hundred Procedures, Work Instruction, Forms and which needs to be completely rewritten, to take in new requirements based on a major organisational change, correct a decade of neglect, and generally make the QMS much more "process based".
What I am particularly interested in is finding a good method of seperating the things we absolutely must do, from the guidance level detail of how to go about doing it.
I've observed that documents which are very wordy, and give a great deal of guidance detail can tend to be treated by auditors as Gospel, with them picking on very minor deviations from process with the same sort of enthusiasm as if they had found something which would actually affect product quality, safety or customer perceptions.
As a result of this, I've found that people use the defined process as an excuse NOT to do work that is needed, simply because it's not written into the procedural documentation
So... what I am wanting to do is to seperate this guidance level detail from the actual core process - but I would appreciate some guidance on how other people have seperated the critical aspects from the lower level detail, to provide employees with a degree of operation freedom.
Many thanks in advance,
Steve
I'm about to embark on something of an epic journey into Quality Management Systems.
I have a QMS of six hundred Procedures, Work Instruction, Forms and which needs to be completely rewritten, to take in new requirements based on a major organisational change, correct a decade of neglect, and generally make the QMS much more "process based".
What I am particularly interested in is finding a good method of seperating the things we absolutely must do, from the guidance level detail of how to go about doing it.
I've observed that documents which are very wordy, and give a great deal of guidance detail can tend to be treated by auditors as Gospel, with them picking on very minor deviations from process with the same sort of enthusiasm as if they had found something which would actually affect product quality, safety or customer perceptions.
As a result of this, I've found that people use the defined process as an excuse NOT to do work that is needed, simply because it's not written into the procedural documentation
So... what I am wanting to do is to seperate this guidance level detail from the actual core process - but I would appreciate some guidance on how other people have seperated the critical aspects from the lower level detail, to provide employees with a degree of operation freedom.
Many thanks in advance,
Steve
I saw it as an opportunity to not only reduce and streamline procedures, but to improve efficiency throughout the organization.
Our process mapping demonstrated multiple areas around the company where processes were duplicated and sometimes done three or more times by various departments. Departments that used the same information, didn't share it - they maintained separate databases. And, needless to say, the majority of people in the company were unaware of all of the procedures that applied to them, and didn't follow the procedures they were aware of.
It was mass confusion, to say the least, and bringing it all to the surface more than opened a can of worms. We formed cross-functional teams, and analyzed the process maps and audit findings. Each team established lists of requirements based on the standards and regulations and the audit report, then began remapping processes. Our maps indicated the significant problem areas, deficiencies and redundant processes, so it basically stood out.
I created a master matrix that identified the requirements and the procedures that satisfied them.
As new procedures were developed, we referred to the matrix to supersede the existing procedures. In some cases, one short, four-page procedure could replace three 15-page documents.
After about five months, we reduced the total number of procedures to about 200. Many procedures were replaced with simpler flow charts, while a few others still needed to maintain the detailed text.
We saw an immediate improvement in every area. First, everyone was more than familiar with their procedures and processes - they owned it. The Quality System had become a part of the day-to-day business, not a side entity that was considered at audit time. Dashboard metrics were established and key processes could be monitored, whereas in the past no one really understood. Processes were streamlined across the organization, allowing the company to utilize the staff more effectively. Where, in general, employees felt that they were really stretched and needed additional resources, they found they had time to participate in continuous improvement teams. Backlogs were eliminated - a 200 part backlog in the incoming inspection department vanished in about three weeks. Complaints were investigated and resolved, nonconforming material was reduced, COGS was dramatically reduced, and the company found it didn't need to hire the additional 30 positions it had created.
Ultimately, it was a massive success with a major impact. It freed funds to allow for expansion and automation. We streamlined further, moving to a paperless system, a new ERP system, and a customer service system that all shared information. This dramatically reduced processing time, improved efficiency, and reduced errors.
So, the moral of the story is, take the opportunity to not only replace / reduce documentation, but to improve the business processes. You could easily have every department re-write procedures, simplifying them and tossing out the redundant or pointless procedures. In the end though, they're just re-documenting what they already do, and you won't see much of a ROI for the time you spend correcting the documentation. So, it'll appear to be a "cost of compliance", and no one will see a benefit - other than a big gold star on your next audit report.
