Once again, there are no real differences in the real world but in quality management systems there are a number of intents surrounding these two. Procedures are a set of instructions in a prescribed format and order giving the reader an understanding of how a number of different processes interact.
Whilst a process is an implied rule or understanding of a particular activity or set of activities.
In the certification world, it is normally accepted that procedures are documented in some manner. ISO 9001 only requires 6 documented procedures.
However, the standard also asks that 15 types of quality management systems records are generated to verify the effectiveness of a quality management system. But you cannot generate a records of an activity unless there was a process generating that record. So instead of documenting a procedure describing how that record is generated, all a quality management system needs to do is demonstrate the process is understood and applied uniformly in order to generate the desired records demonstrating effectiveness. What a mouthful!
In other words, if the process is simple, the staff competent and the records readily retrievable and demonstrable of desired outcomes, you don't need to write a procedure. But there are other reasons, like to help in knowledge preservation, succession planning and training resources. But as always, that is up to you, your business and your risk profiles.
Monday, 30 July 2012
Tuesday, 24 July 2012
Procedures -v- Work Instructions
To the lay person there is no difference. To the partially informed it is a convenient differentiation in an attempt de-value a document when found by an auditor. To the truly expert, any document that has been generated to describe a process, no matter the detail, the prescription, the intent, should be judged by the end-user and subsequently reviewed for accessibility, relevancy and most importantly impact on the total system. But enough pontificating.
What is the difference and when should you have one, the other or both? Once again, the situation is totally up to you, the client organisation and the end users. By definition, documentation within a quality management system is broadly broken into a number of categories. These being; vision, policy, procedure, instruction. The structure and format can be determined by the company and or end users with the intent being; vision - overall strategy, policy - a business rule or ideology as a subset of vision, procedure - what has to be done to achieve policy, instructions - the minutia to comply with procedure.
The standard only requires six documented procedures and requires records to be generated to verify fifteen processes and does not stipulate anywhere any requirements for additional documentation. That is left completely up to the need of the organisation and normally as a consequence of risk management. That means if you want a work instruction to explain in detail or to prescribe strict process, use them. The format is up to you. Screen shots, pictograms, photos, it is totally up to you. Just make sure that if they are to be valued that you apply the same document control measures for them as you do for all your quality management system documents and then use them in training sessions and include them in internal quality audits.
What is the difference and when should you have one, the other or both? Once again, the situation is totally up to you, the client organisation and the end users. By definition, documentation within a quality management system is broadly broken into a number of categories. These being; vision, policy, procedure, instruction. The structure and format can be determined by the company and or end users with the intent being; vision - overall strategy, policy - a business rule or ideology as a subset of vision, procedure - what has to be done to achieve policy, instructions - the minutia to comply with procedure.
The standard only requires six documented procedures and requires records to be generated to verify fifteen processes and does not stipulate anywhere any requirements for additional documentation. That is left completely up to the need of the organisation and normally as a consequence of risk management. That means if you want a work instruction to explain in detail or to prescribe strict process, use them. The format is up to you. Screen shots, pictograms, photos, it is totally up to you. Just make sure that if they are to be valued that you apply the same document control measures for them as you do for all your quality management system documents and then use them in training sessions and include them in internal quality audits.
Monday, 23 July 2012
Audit / auditor planning
I am constantly amazed at the lack of customer service exhibited by certification service providers. In particular, the forward planning of audits and auditors.
Most certification audits, once you have certification, are either 6, 9, 12 months in frequency. These might appear ‘long between drinks’ but it shouldn’t stop proactive planning of the next audit, before the conclusion of the current audit. It surely must help with forward planning. Doesn’t it? It most certainly gives you focus on when certain actions need to be done by. And if you are diligent with your project / program planning, it will at least give you the ability to change, long before they fall due, especially if your current provider has penalty clauses for late changes.
Most providers won’t let their auditors plan their next audit with their client. Probably because it locks people in to a commitment. Heaven forbid! It also means, that if there is a change in date closer to the audit, by lack of forward thinking clients, they might not be able to bill anyone for that day. Ouch. Perhaps the time could be used for training, or reporting or even leave? And when the change is driven by the provider because a more important client, more billable client starts squeaking the wheel, well the original client gets the short straw with a date and or auditor change. Not good.
The inflexibility creates distrust and dissatisfaction with any penalties just plain aggravating the situation. I understand the need for providers to manage their personnel and their loadings, but at the expense of customer focus, just makes clients unhappy and far more ready to change dates and stuff things up rather than keeping to commitments or to a true client / supplier relationship.
Most certification audits, once you have certification, are either 6, 9, 12 months in frequency. These might appear ‘long between drinks’ but it shouldn’t stop proactive planning of the next audit, before the conclusion of the current audit. It surely must help with forward planning. Doesn’t it? It most certainly gives you focus on when certain actions need to be done by. And if you are diligent with your project / program planning, it will at least give you the ability to change, long before they fall due, especially if your current provider has penalty clauses for late changes.
Most providers won’t let their auditors plan their next audit with their client. Probably because it locks people in to a commitment. Heaven forbid! It also means, that if there is a change in date closer to the audit, by lack of forward thinking clients, they might not be able to bill anyone for that day. Ouch. Perhaps the time could be used for training, or reporting or even leave? And when the change is driven by the provider because a more important client, more billable client starts squeaking the wheel, well the original client gets the short straw with a date and or auditor change. Not good.
The inflexibility creates distrust and dissatisfaction with any penalties just plain aggravating the situation. I understand the need for providers to manage their personnel and their loadings, but at the expense of customer focus, just makes clients unhappy and far more ready to change dates and stuff things up rather than keeping to commitments or to a true client / supplier relationship.
Tuesday, 17 July 2012
Purchasing
This is a mixed bag of good business practice with a throwback to the prescriptive past. It is a three part element; purchasing process (the good bit), purchasing information and verification of purchased product (the throwbacks).
The process is very open ended and enables the organisation to deal with purchasing decisions as they see fit. The standard reads; an organisation will ensure that purchased product conforms to specified purchase requirements. The type and extent of control applied to the supplier and the purchased product is dependent upon the effect of the purchased product on subsequent product realisation or the final product.
Rather simple really. Whilst a documented procedure is not required, I would always have one to ensure authorities levels are defined or referenced and to give an overview of the process involved.
Then more importantly is the review of suppliers. In a previous version of the standard, this had its own sub element and was the fixation of many auditors trying to get companies to rate suppliers on some sort of convoluted machination. Thankfully no more. Just good business practices. I wouldn’t have a standalone procedure (unless warranted by the complexity) but if you have a purchasing procedure (or at least a process), the review and acceptance of supplier should be an integral component.
The standard talks about; a company evaluates and selects suppliers based on their ability to supply product in accordance with company requirements. Criteria for selection, evaluation and re-evaluation are established. Records of the results of evaluations and any necessary actions arising from the evaluation are maintained. The sting being, records must be generated. Don’t get hung up on questionnaires, audits reports, etc (of course, unless warranted) but at least identify the records that are generated that verify the review activities. These can include minutes of meetings, emails, etc. I also like a supplier list and reviewing it in management review meetings.
The rest of this element is trite. Make sure you address the requirements in your process or procedure, but if you have robust purchasing processes, you will cover them as a matter of course.
The standard says; Purchasing information describes the product to be purchased, including where appropriate a) requirements for approval of product, procedures, processes and equipment, b) requirements for qualification of personnel, and c) quality management system requirements. A company ensures the adequacy of specified purchase requirements prior to their communication to the supplier. And it then goes on to describe; verification of purchased product. A company has established and will implement the inspection or other activities necessary for ensuring that purchased product meets specified purchase requirements. Where a company or its customer intends to perform verification at the supplier's premises, company will state the intended verification arrangements and method of product release in the purchasing information.
My head hurts. Perhaps I should have made this blog a two parter.
The process is very open ended and enables the organisation to deal with purchasing decisions as they see fit. The standard reads; an organisation will ensure that purchased product conforms to specified purchase requirements. The type and extent of control applied to the supplier and the purchased product is dependent upon the effect of the purchased product on subsequent product realisation or the final product.
Rather simple really. Whilst a documented procedure is not required, I would always have one to ensure authorities levels are defined or referenced and to give an overview of the process involved.
Then more importantly is the review of suppliers. In a previous version of the standard, this had its own sub element and was the fixation of many auditors trying to get companies to rate suppliers on some sort of convoluted machination. Thankfully no more. Just good business practices. I wouldn’t have a standalone procedure (unless warranted by the complexity) but if you have a purchasing procedure (or at least a process), the review and acceptance of supplier should be an integral component.
The standard talks about; a company evaluates and selects suppliers based on their ability to supply product in accordance with company requirements. Criteria for selection, evaluation and re-evaluation are established. Records of the results of evaluations and any necessary actions arising from the evaluation are maintained. The sting being, records must be generated. Don’t get hung up on questionnaires, audits reports, etc (of course, unless warranted) but at least identify the records that are generated that verify the review activities. These can include minutes of meetings, emails, etc. I also like a supplier list and reviewing it in management review meetings.
The rest of this element is trite. Make sure you address the requirements in your process or procedure, but if you have robust purchasing processes, you will cover them as a matter of course.
The standard says; Purchasing information describes the product to be purchased, including where appropriate a) requirements for approval of product, procedures, processes and equipment, b) requirements for qualification of personnel, and c) quality management system requirements. A company ensures the adequacy of specified purchase requirements prior to their communication to the supplier. And it then goes on to describe; verification of purchased product. A company has established and will implement the inspection or other activities necessary for ensuring that purchased product meets specified purchase requirements. Where a company or its customer intends to perform verification at the supplier's premises, company will state the intended verification arrangements and method of product release in the purchasing information.
My head hurts. Perhaps I should have made this blog a two parter.
Monday, 9 July 2012
Design and Development - The last word
Had enough yet? One more instalment. Here is the standard. 7.3.6 Design and development validation; Design and development validation is performed in accordance with planned arrangements to ensure that the resulting product is capable of meeting the requirements for the specified application or intended use, where known. Wherever practicable, validation is completed prior to the delivery or implementation of the product. Records of the results of validation and any necessary actions are maintained. 7.3.7 Control of design and development changes; Design and development changes are identified and records maintained. The changes are reviewed, verified and validated, as appropriate, and approved before implementation. The review of design and development changes include evaluation of the effect of the changes on constituent parts and product already delivered. Records of the results of the review of changes and any necessary actions are maintained.
Yep, my head still hurts. These two parts are very prescriptive. Do you really need me to spell it out any further? Validity is by definition is proof design works. Get it tested, seek peer evaluation, trial, etc. Get the results, check the results, compare results to the previous five elements. Is it OK? If not, record what isn’t and fix it. Redo all previous steps. All good? Proceed.
The last is just making sure that if you change anything, record it. Record it on the design documentation, in test results, in meeting minutes, etc. And when you change it, do the previous six steps again, review it again, change it again and record it again. Happy designing.
Yep, my head still hurts. These two parts are very prescriptive. Do you really need me to spell it out any further? Validity is by definition is proof design works. Get it tested, seek peer evaluation, trial, etc. Get the results, check the results, compare results to the previous five elements. Is it OK? If not, record what isn’t and fix it. Redo all previous steps. All good? Proceed.
The last is just making sure that if you change anything, record it. Record it on the design documentation, in test results, in meeting minutes, etc. And when you change it, do the previous six steps again, review it again, change it again and record it again. Happy designing.
Forms and Records - What is the difference?
In the real world there doesn't have to be a difference, so long as both
people discussing them have the same intent. In fact, the standard doesn't talk
about forms, it talks about documents in general. Well, that is whole blog on
its own. But in the quality world, both forms and records are very different
and need to be managed very differently.
So here are some simple definitions.
A 'form' is a structured document, either online or offline, specifically designed to collect data in a prescribed format. Did I say simple definition? Normally, a form is used to collect data for a database so that further products or services can be processed. The form itself is known by its own identifier, it's name, it's number, it's intent. My favourite example of a form is the annual leave form for my company. Without it, no annual leave. As we don't use form numbers, it is simply called the 'leave form' because it is also used for sick leave, special leave, etc.
Now a record, by my definition, is a collection of data. Sometimes such data is online, sometimes it is collected on a form, sometimes it is just a discreet unit of measurement. It is simply a piece of information representing a whole or a part of the required data. The record itself is known for its content and not what is was recorded on or in. Therefore my favourite form, the leave form, once I fill it in, is no longer know as a leave form, but John's annual leave record for July 2012.
The most important part of this whole definition, transition story is that you need controls for each. Such controls are varied and very different in design and implementation. So before you race off and put policy and procedure behind each, get your definitions clear and your journey will be far simpler.
So here are some simple definitions.
A 'form' is a structured document, either online or offline, specifically designed to collect data in a prescribed format. Did I say simple definition? Normally, a form is used to collect data for a database so that further products or services can be processed. The form itself is known by its own identifier, it's name, it's number, it's intent. My favourite example of a form is the annual leave form for my company. Without it, no annual leave. As we don't use form numbers, it is simply called the 'leave form' because it is also used for sick leave, special leave, etc.
Now a record, by my definition, is a collection of data. Sometimes such data is online, sometimes it is collected on a form, sometimes it is just a discreet unit of measurement. It is simply a piece of information representing a whole or a part of the required data. The record itself is known for its content and not what is was recorded on or in. Therefore my favourite form, the leave form, once I fill it in, is no longer know as a leave form, but John's annual leave record for July 2012.
The most important part of this whole definition, transition story is that you need controls for each. Such controls are varied and very different in design and implementation. So before you race off and put policy and procedure behind each, get your definitions clear and your journey will be far simpler.
Tuesday, 3 July 2012
Design and development - part 3 of 4
The next instalment covers; design and development review and design and development verification.
Design and development review. At suitable stages, systematic reviews of design and development are performed in accordance with planned arrangements; a) to evaluate the ability of the results of design and development to meet requirements, and b)to identify any problems and propose necessary actions. Participants in such reviews include representatives of functions concerned with the design and development stage(s) being reviewed. Records of the results of the reviews and any necessary actions are maintained.
Ooww my head hurts. So, with the qualspeak dropped it should read…Update your deign plan. Conduct a review meeting and ensure the right people are there. Generate minutes or an action plan and follow them up next review. Simple. Just remember that some clients have quite specific requirements concerning such reviews and reporting, so make sure you know them and if you want to change those requirements, get their approval.
Design and development verification. Verification is performed in accordance with planned arrangements to ensure that the design and development outputs have met the design and development input requirements. Records of the results of the verification and any necessary actions are maintained.
Hmmm. Smells a bit like the above requirement, only it specifically requires a roadmap type record to demonstrate outputs equals inputs and when they don’t, there is an action plan to fix them. You can merge these two if you want, just make sure your procedure points in the right direction so that a third party can assess the process.
Design and development review. At suitable stages, systematic reviews of design and development are performed in accordance with planned arrangements; a) to evaluate the ability of the results of design and development to meet requirements, and b)to identify any problems and propose necessary actions. Participants in such reviews include representatives of functions concerned with the design and development stage(s) being reviewed. Records of the results of the reviews and any necessary actions are maintained.
Ooww my head hurts. So, with the qualspeak dropped it should read…Update your deign plan. Conduct a review meeting and ensure the right people are there. Generate minutes or an action plan and follow them up next review. Simple. Just remember that some clients have quite specific requirements concerning such reviews and reporting, so make sure you know them and if you want to change those requirements, get their approval.
Design and development verification. Verification is performed in accordance with planned arrangements to ensure that the design and development outputs have met the design and development input requirements. Records of the results of the verification and any necessary actions are maintained.
Hmmm. Smells a bit like the above requirement, only it specifically requires a roadmap type record to demonstrate outputs equals inputs and when they don’t, there is an action plan to fix them. You can merge these two if you want, just make sure your procedure points in the right direction so that a third party can assess the process.
Monday, 2 July 2012
Certification and executive sponsorship
Certification and executive sponsorship
Are you the executive sponsor of the design, implementation and certification of your quality management system? If yes, congratulations! I truly believe that if you are this person, it is time to make a difference for your company. And in the certification space, this means thoughtful, decisive and committed project management of the certification process.
The key elements of which are; certification project plan, certification service provider (CSP) selection, CSP management, CSP review, internal / external communication plan and ongoing support past initial certification.
Treat this project as you would any other. Develop a strategic plan, a business plan, marketing plan, budgets, ROIs, payback, etc. Be honest. Gather the relevant data. Make decisions on fact. Take the emotion out of the equation. Hell, you may even decide during the discovery phase that certification isn’t what your company needs. It is not for everyone.
In some cases, it might all boil down to another cost of goods sold line item, that, should you spread it across all products and services, might just get it across the line. So long as there is a record of such decisions, be comfortable with it.
Are you the executive sponsor of the design, implementation and certification of your quality management system? If yes, congratulations! I truly believe that if you are this person, it is time to make a difference for your company. And in the certification space, this means thoughtful, decisive and committed project management of the certification process.
The key elements of which are; certification project plan, certification service provider (CSP) selection, CSP management, CSP review, internal / external communication plan and ongoing support past initial certification.
Treat this project as you would any other. Develop a strategic plan, a business plan, marketing plan, budgets, ROIs, payback, etc. Be honest. Gather the relevant data. Make decisions on fact. Take the emotion out of the equation. Hell, you may even decide during the discovery phase that certification isn’t what your company needs. It is not for everyone.
In some cases, it might all boil down to another cost of goods sold line item, that, should you spread it across all products and services, might just get it across the line. So long as there is a record of such decisions, be comfortable with it.
Subscribe to:
Posts (Atom)