Re: What criterial do you use to identify a company using the "process approach"?
Companies define their documentation and organizations in 3 different variations.
Please explain your definition of "define their documentation and organizations". Are you referring to organizational charts? Are you referring to documentation structure?
1. Some truly define and manage it as a series of processes, as the standards promote and require. A true process approach.
Please show or tell about an example of this and an example of one that does not follow this approach. Give me an example of what constitutes "...truly define and manage it as a series of processes...". You say it is a requirement. State the requirement and give an example of objective evidence that a company does, and of one that does not, "...truly define and manage it as a series of processes...". That is to say, objective evidence that a company does, or does not, comply with the requirement you are going to cite. (Key words: objective evidence)
I have never been in a company that did not define and manage themselves as a series of processes. They really don't have a choice because a company *is* a series of processes/systems. If there is any question in this it is who, if anyone, understands how all the systems/processes/sub-processes fit together and how they interact (and especially in larger companies it is rare that you can find one person who knows and can explain how
all the parts fit together along with
every input and output of every system/process the company has). Most employees only need to know what processes they are responsible for following. As one climbs the ladder of responsibilities in a company (going up the organizational chart, so to speak), the more processes/systems the person is expected to follow and understand, typically including some or all of the processes employees s/he is responsible for must follow. Let's now go to plant manager (usually high on the chart). What systems/processes is s/he responsible for is determined by the company structure, but again it will be a sub-set of all the company's systems/processes.
2. Many only get to a Dept. approach, which does not quite comply. An example would be that Sales and Purchasing is identified as a single "process" because the same person is in charge of both. Of course, the documentation and metrics quickly becomes a mess, because they really didn't understand the intent of a process approach. This is very common because this is how companies have been managed for decades, and is sometimes difficult to get past.
Give me an example of where Sales and Purchasing are identified as a single "process" (no sub-processes/systems).
Sales and Purchasing are functions/systems made up of sub-systems/processes relevant to how a specific company does things related to the sub-systems/processes. I have been in many companies where one person had multiple responsibilities. Sales and purchasing are broken up into sub-systems/processes necessarily simply because they are not the same thing. Whether or not one person has one or many responsibilities is not relevant.
What is a department approach? Are you referring to how the company structures its document naming conventions? So what if the same person has multiple responsibilities? Processes/systems (documented or undocumented) have to be followed, have to have inputs and outputs regardless of whether one person has to follow the processes/systems (documented or undocumented) or whether many do.
Let's take organizational charts: While nice and appropriate to have, in many companies they change frequently, sometimes monthly. Just because the organizational chart changes frequently it does not mean that the process/systems the company have in place necessarily change. This month the Engineering Department Manager may have a set of responsibilities for specific systems/procedures, but next month (after another round of downsizing) the Engineering Department Manager may take on additional responsibilities for systems/procedures someone who is let go used to be responsible for. Org charts assign responsibilities/authorities for processes/systems but that's about it.
I have been in companies that changed so often that keeping organizational charts up to date was a serious problem (not to mention the flow down effects on many things {and people} including {typically} some documents). My position as a consultant implementing a standard, and as an auditor, was/is organizational charts must be up to date and must be controlled documents, and that changes are appropriately communicated throughout the organization. Then again, I have been in small companies that didn't need an organization chart. You could ask any employee who was responsible for what systems/processes and they could tell you. As an implementation consultant I always made a company make an org chart if they didn't have one, even if they really didn't need one, if only to keep auditors happy.
3. Strictly, element based QMS. Documents are all oriented to the 20 elements we used to use. No alignment showing linkages between processes.
So - You are saying a company has to have something like diagrams of some sort to show linkages between processes when linkages (inputs and outputs) are already within the documents? Can you cite the specific requirement that there must be a specific document that shows "...alignment showing linkages between processes..."?
All that I can see is you are trying to say companies must adopt a specific documentation structure which has nothing to do with document content. I could label every procedure/document in a company with, for example, a prefix of the section of the standard it most closely applies to with respect to compliance. So what? The *content* (importantly inputs and outputs) of a document/procedure is what is important.
Limited process documentation or metrics. I still see this a lot.
Now we're getting into subjective territory. Who is to decide how much process documentation is necessary? An auditor? Who is to decide what metrics are enough as long as data/inputs/outputs required by the standard are there? An auditor?
(PS: ISO 9004 contains good information about the process approach.)
Ummm, after 20 years of involvement in ISO (and other) standards I do understand that. But to me, ISO 9004 is 'basic business 101' (as is ISO 9001). For example:
ISO 9004 said:
4.2 Documentation
Management should define the documentation, including the relevant records, needed to establish, implement and maintain the quality management system and to support an effective and efficient operation of the organization's processes.
The nature and extent of the documentation should satisfy the contractual, statutory and regulatory requirements, and the needs and expectations of customers and other interested parties and should be appropriate to the organization. Documentation may be in any form or medium suitable for the needs of the organization.
In order to provide documentation to satisfy the needs and expectations of interested parties management should Consider
-- contractual requirements from the customer and other interested parties,
-- acceptance of international, national, regional and industry sector standards,
-- relevant statutory and regulatory requirements,
-- decisions by the organization,
-- sources of external information relevant for the development of the organization's competencies, and
-- information about the needs and expectations of interested parties.
Well, Duh!
ISO 9004 said:
5.1.2 Issues to be considered
When developing, implementing and managing the organization's quality management system, management should consider the quality management principles outlined in 4.3.
On the basis of these principles, top management should demonstrate leadership in, and commitment to, the following activities:
-- understanding current and future customer needs and expectations, in addition to requirements;
-- promoting policies and objectives to increase awareness, motivation and involvement of people in the organization;
-- establishing continual improvement as an objective for processes of the organization; -- planning for the future of the organization and managing change; -- setting and communicating a framework for achieving the satisfaction of interested parties.
In addition to small-step or ongoing continual improvement, top management should also consider breakthrough changes to processes as a way to improve the organization's performance. During such changes, management should take steps to ensure that the resources and communication needed to maintain the functions of the quality management system are provided.
Top management should identify the organization's product realization processes, as these are directly related to the success of the organization. Top management should also identify those support processes that affect either the effectiveness and efficiency of the realization processes or the needs and expectations of interested parties.
Management should ensure that processes operate as an effective and efficient network. Management should analyze and optimize the interaction of processes, including both realization processes and support processes.
Consideration should be given to
-- ensuring that the sequence and interaction of processes are designed to achieve the desired results effectively and efficiently,
-- ensuring process inputs, activities and outputs are clearly defined and controlled, -- monitoring inputs and outputs to verify that individual processes are linked and operate effectively and efficiently -- identifying and managing risks, and exploiting performance improvement opportunities, -- conducting data analysis to facilitate continual improvement of processes, -- identifying process owners and giving them full responsibility and authority, <snip>
Again, Duh! Business 101. What is taught in MBA courses? What does a business major learn? How does a company stay in business these days if they don't do these things?
ISO 9004 is a good document. I'd call it a basic business primer for, at least to some degree, but let's be real. This is just basic business 101. I'm so sick of seeing this simplistic diagram over the years, and each time it's fawned over as if it's something great and wonderful and new when it's how businesses that stay in business work.
PS: I usually write the Quality Manual based on the clauses, to capture the ISO requirements. But, the QM defines the processes and from that point everything else is process, process, process.
On this we agree. I usually advise companies to write their Quality Manual based on the clauses because it helps them learn the structure of the standard, how it all fits together and promotes a better understanding of it. One might even call it a reference, especially in small companies that already do 'every thing right'. It helps wean a company off their dependence upon me for understanding of the standard because its in their face all the time (at least in the face of people who have to understand the requirements, which is always a small sub-set of employees in any given company).
ISO 9001 and related standards only require that a company have certain systems/processes (e.g.: document control) and that certain systems/processes have certain inputs and outputs. Well, yes, the systems must be *effective*, but again we digress into a degree of subjectivism when we discuss what is 'effective' from the view of the auditor vs. the view of the company. In some cases it *is* quite apparent that a system/process is or isn't effective, but many times we end up in the old 'gray area' of opinion.
I also think it is important to say the presence or absence of a required system (such as internal audits and document control) does not mean a company is not process based with inputs and outputs in their systems/processes and related documentation. The examples I cited (internal audits and document control) are just additional systems they will have to design and implement to be compliant with the standard.
In all the years that I've been involved in this, almost all companies I have worked with had *most*, if not all, of the systems/processes the standard they wanted to get registered to requires. A lot of what I did was look at how they operated and then sat down with them to explain the standard and its requirements. Most of the problems were understanding the 'language'. I don't now how many times I heard stuff like "OK, so we do this and we have that process documented here but we call it document control. We don't even really have a name for it. It's just how we handle documents." To which I have to reply something like "Well, in IO 9001 they call it document control. Now, let's step through your procedure here and see if it contains all the requirements of the standard, and let's look through your documents and forms and ensure we know how they work together." I've been called 'the teacher' in a couple of companies. Obviously it was because I was teaching them how to interpret the standard and how they complied (or didn't comply) with the requirements of the standard.
This is something I wrote quite a few years ago as 'bullet points'. You'll notice some of the failure modes (such as 4.20 Statistical Techniques - System not used where SPC could definitely improve quality) are subjective. I'll bet they're the same typical failure modes today.
Registration Audit Failure Modes
