ISO9000 certification requires companies to explicitly document their operating procedures and then follow them. What could be wrong with that? Here’s what.

The purpose of business is the creation of wealth. Wealth creation is, at root, a process of creative thought. To be highly successful over the long term, a company has to constantly improve its products and methods of production — it has to innovate. But innovation, by definition, cannot be captured in a formal procedure. Following a set of rules someone else wrote down is the antithesis of the kind of ongoing creative thinking that business success requires. And that kind of rule-following is exactly what ISO9000 requires.

Conclusion: ISO9000 is worse than pointless. Which probably explains why I work at an ISO9000-certified company and nevertheless have no idea what documented procedures I’m supposedly following.

2 Responses to “Why ISO9000 is bad”
  1. Hugo Schmidt says:

    I’m going to be forced to disagree here. I do not know much about ISO9000, but the general idea of writing down everything that you do seems a very good one.

    I’ve worked in a lab, and the first rule of research, the absolutely first rule is “Write down everything, I mean absolutely _everyting_ that you do”.

    Similarly, written protocols can form the basis of future innovation. If you don’t know exactly what the original procedure was, how can you be sure that it was your change and not some random one that has had a positive effect?

    Of course, written rules should not become constrictive.

  2. Kyle Haight says:

    Not surprisingly, I’m going to stick with my original viewpoint. The key element in my objection is not the documentation of procedure per se; it’s the emphasis on always following documented procedure that causes the problem. I’ve had an ISO auditor tell me to my face that it doesn’t matter whether the procedure documented is efficient, sensible or even plausible — just so long as you follow it to the letter. The essence of ISO9000, in my experience, is the attempt to reduce work to nothing but the execution of mechanical rules.

    Take a concrete example. I’m a software engineer. A major part of my job is finding and fixing bugs in our software product. I don’t think it’s even possible to document exactly how to do that. Any set of steps that covered all the cases would be so general that it would be useless as a guide to anybody else. Sure, you can put together a set of ‘tips and tricks’, and document so-called ‘best practices’, but at the end of the day you have to sit down and actually do the engineering, and that just isn’t capturable in a “ok, I finished step 6, now let’s go on to step 7” model.

Leave a Reply