Yes.
ISO 9001's description of a process is dreadful, complete with a worse-than-useless diagram which, in training classes, I always found an embarrassment. It's so abstract as to be meaningless. ISO 9001 should demonstrate the principles upon which it's based, not abuse them and mislead, e.g. with a proper process map (except it can't be done for the entire standard, so without one then!)
ISO 9004 doesn't help much either, with abstract guidance on what to consider when defining processes in clause 7 on process management, but nothing on how to define, communicate and implement processes.
Neither ISO 19011 nor ISO 17021, both recently reissued, take the opportunity to define process-based auditing. In particular, guidance is needed on identifying and evaluating evidence of effective process management.
ISO 9000 obfuscates with a correct but useless definition of a process as “a set of interrelated or interacting activities which transforms inputs into outputs.”
It then confuses the issue by declaring that a procedure is “a specified way to carry out an activity or a process.” Suppose I write that “Design is performed by taking the requirements specification (input) and using the Booch UML methodology (see Mr Booch's book) to prepare design specs (outputs) by a competent software engineer. Both inputs and outputs are peer-reviewed prior to use.” What have I written? A process or a procedure? Why does it matter? The answers, respectively, are “Who cares?” and “It doesn't”.
The motor industry tried to improve things with Turtle diagrams. Do they help? As an outsider, my perspective is that they only help those who understand process management, and then only in preparing for audits. When used as a process mapping template, I think they more often than not obscure the processes and their interactions in a welter of detail that should be somewhere else.
I was involved some while ago at QuEST Forum in trying to move TL 9000 more towards the process-based approach of the underlying ISO 9001 standard; then, and now, too many of the additional requirements mandated documented procedures that were onerous, instead of expecting organizations to learn and use process techniques. We failed, shouted down by the ISO 9001:1994 brigade who continue to believe that if it ain't documented, it ain't so.
The problem with process management, as opposed to the elemental approach (why do we even grace that with a name?) is that it requires skill, in management systems implementers and auditors, and while that's mandated in the relevant standards, too often those evaluating process management skill do not themselves have it.
Here's how I would start:
Define a process as an activity that transforms inputs to outputs, for which the following are defined:
- the inputs, and any requirements they must satisfy prior to use in the process (needs word-smithing to allow for processes to start with fuzzy inputs that firm up later in an incremental management style)
- the outputs, and any requirements for V&V that must be satisfied prior to their release from the process
- how to perform the process
- relevant process measurements (KPIs)
- to whom to report opportunities to improve the process (process owner)
- competencies required for performing the process
- tooling and equipment mandated for the process
- how to budget time and money required for the process
These last three are usually lumped together as “resources”. I like to separate them out because I don't think people are resources, we're people; and time and budget planning is often poor and a root cause of process failure – indeed, time and money is often not even seen as a resource, yet they are the most important, and the most squandered.
I'd add guidance for auditors on process auditing:
Assure that the process is repeatable and sustainable by checking that:
- it is systematically communicated (not necessarily documented, but if it's not, check that everyone knows what it is and can tell each other even if a few leave the organization)
- it is systematically executed
- it is systematically effective (look for records of KPIs and of checking process outputs against defined criteria)
- it is systematically understood by those involved (a common cause of process failure because people take short cuts without understanding the implications)
- it connects properly to related processes with inputs and outputs whose acceptance criteria are well-defined and utilized (throwing inadequate work over the wall is in my experience a very common cause of departmental success at the expense of organizational failure)
This way of auditing processes reveals why the disproportionate emphasis in the management systems community on documenting procedures doesn't work: documentation only helps with communicating the process. While that's important, there's no guarantee that it works. Few people read documentation and auditors have to (or should) check all the other things anyway, so it only helps so much and effort spent upon it should be proportionate to its value.
ISO 9004 should include several examples of process management for manufacturing, for services, and for software.
Just my 2c,
Pat
but I believe the standard demands a process approach but many ignore the requirement.
