Informational Is Identification of Risks and Opportunities required for QMS Processes?

[AndyN]

Equating running a small business to playing board game at the weekend when the owner has staked his or her family home and more on the success of their business.

...is respectful?

You read too much into that

 

[Jen Kirley]

Jen,

All process and projects are planned to some extent. I contend that planning includes assessing the risks of failure

Planning engages the process or project team in understanding and agreeing the objectives (and the risks of not meeting the objectives) before determining the resources necessary to fulfill the objectives.

How can planning that omits risk be considered complete or likely to be effective?

John

Did I say that process planning should omit risks? I certainly did not intend to send that message.

 

[Jen Kirley]

From your posts, John, it seems to me that we work in very different worlds. For the most part, my recent experiences are with small/medium sized businesses which are relatively unsophisticated and certainly don't do what you've described. "Risk" is often a board game played with family at the weekend...

One of the most frequent challenges I have faced is in convincing people that risk is not necessarily complex. People tend to look at risk like it is akin to sky diving or bungee jumping. It is not, and was never intended to be something only the large organizations do. It is the replacement for preventive action. Organizations of all sizes tend to do that in some way, but very often don't give themselves credit for what they do because they think they are supposed to be doing something elaborate.

 

[Jen Kirley]

Because someone wrote that, doesn't make it so! The fact remains that ISO 9001 in its earliest forms wasn't about risk. When people rely on "implicit" requirements then you know they are grasping at straws. The fundamental reason for ISO 9001 (forget certification because that only came along later, to reduce costs) is as a basis of agreement (contractually) between customers and suppliers, as I said, to reduce the need for supplier development activities. In fact, the ONLY time customers were mentioned was in respect to customer complaints, if I recall correctly. Hardly a "risk based thinking" approach. Same with "Contract Review". To wait until a contract is awarded, to review it is hardly a "risk based thinking" approach is it? If the standard was about risk, how come so many ISO certified companies still deliver rubbish (and the same for other certifications based on 9001)? Why is it auditors have rarely, if ever, addressed "risk" when auditing? Or signed off on management reviews and audits being done once a year?

And how did organizations use the ISO structure to reduce the need for supplier development activities? Put in an effective receipt raw material inspection system and the risk of producing defective material tends to be reduced. Calibrate instruments in both design and final inspection processes and the risk of mismatch between these two processes tends to be reduced. I have never liked the term "risk" because it invites people to think it is a new thing. It isn't.

 

[AndyN]

And how did organizations use the ISO structure to reduce the need for supplier development activities?

They used various requirements of the standard, specified contractually, that the supplier should employ to assure product. In fact, there's a note in the foreword/introduction texts of the document which describes this "tailoring" to suit the needs of the relationship.

 

[Jen Kirley]

They used various requirements of the standard, specified contractually, that the supplier should employ to assure product. In fact, there's a note in the foreword/introduction texts of the document which describes this "tailoring" to suit the needs of the relationship.

And, do the resulting process controls reduce risk?

 

[AndyN]

And, do the resulting process controls reduce risk?

In earlier versions, "process" wasn't a requirement.

 

[Jen Kirley]

In earlier versions, "process" wasn't a requirement.

Did people have processes whether or not they were required? That is, inputs transformed into outputs? Or did they call them something else? (20 years ago we called them processes)

 

[John Broomfield]

In earlier versions, "process" wasn't a requirement.

Work has been a requirement since Adam left the Garden of Eden.

 

[AndyN]

Did people have processes whether or not they were required? That is, inputs transformed into outputs? Or did they call them something else? (20 years ago we called them processes)

As part of their QMS? As in part of their documented ISO 9001:1987/94/2000 certified system? The answer is in many cases, no! They had procedures. Those procedures didn't define input or outputs. No measurement (except of product, only).