1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice
You must be a registered member in order to post messages and view/download attached files in this forum.
Click here to register.

What Does the Design of an Effective QMS include?

Discussion in 'ISO 9001:2015 - Quality Management Systems' started by Andy Nichols, Dec 16, 2020.

  1. Andy Nichols

    Andy Nichols Moderator Staff Member

    Joined:
    Jul 30, 2015
    Messages:
    4,423
    Likes Received:
    2,226
    Trophy Points:
    112
    Location:
    In the "Rust Belt"
    We all know of the typical pyramid of documentation that some use to describe their QMS, but it that really a 1) good design and 2) does it work effectively?
     
  2. Hitokiri Aoshi

    Hitokiri Aoshi Member

    Joined:
    Nov 18, 2020
    Messages:
    6
    Likes Received:
    0
    Trophy Points:
    1
    I think it's great. but probably misused often. It really should be reversed to signify the importance and how one is the base of another.

    LEVEL 4 Project Specific Modifiers (shouldn't be part of QMS) Order specific documentation, custom made.
    LEVEL 3 Work Instruction/Detail Instructions Detail instruction, use by all level, may require constant maintenance and updates as business evolves.
    LEVEL 2 Process Procedure/Guideline Plans out process, use by directors and top management, bi annual review maybe?
    LEVEL 1 Quality Manual Generates target, use to meet QMS program, use by top management, should rarely need modification (beside changing quality objective, which should be managed by level 2 anyway)
     
  3. tony s

    tony s Well-Known Member

    Joined:
    Sep 10, 2015
    Messages:
    1,261
    Likes Received:
    958
    Trophy Points:
    112
    Location:
    Laguna Philippines
    The once ubiquitous pyramid was the basis for many organizations on documenting their QMS. Many organizations here in my country were taught by ISO consultants to start by creating a quality manual, then support it by the subsequent levels of documentation. I don't agree with that approach. I have this slide in my training materials where it shows that the quality manual should be the last document that is to be completed.
    upload_2020-12-17_15-24-50.png
     
  4. pkfraser

    pkfraser Active Member

    Joined:
    Aug 1, 2015
    Messages:
    85
    Likes Received:
    53
    Trophy Points:
    17
    Location:
    Aberdeen Scotland
    Andy I think that you are actually asking two questions: i) "how do you design an effective QMS?" AND ii) "what is the best method to describe and communicate it?" This will depend on what someone thinks that a QMS is (which may be a separate discussion!) I sometimes find it difficult to separate the QMS from "the management system", and I believe that it is more useful to define and communicate "how you run the business" - the processes and the resources needed and the overall business structure (departments, responsibilities etc). Resources would include physical resources, information, policies, records etc.
    Then how do you communicate the system?... publish your process descriptions in a logical structure, with links to supporting documents etc (you can call this the "Manual" if you feel that you must(!) Some of the actual QMS you can't easily "publish" - and I don't think that you need to.
     
    Andy Nichols likes this.
  5. Andy Nichols

    Andy Nichols Moderator Staff Member

    Joined:
    Jul 30, 2015
    Messages:
    4,423
    Likes Received:
    2,226
    Trophy Points:
    112
    Location:
    In the "Rust Belt"
    As ever, Peter, great post. Indeed, it may well be two questions. In my mind, at least, part of effective design is the impact on deployment/implementation the term is, I believe, "Elegant Design" https://elegantdesignthinking.com/
     
  6. Miner

    Miner Moderator Staff Member

    Joined:
    Jul 30, 2015
    Messages:
    466
    Likes Received:
    372
    Trophy Points:
    62
    Location:
    Greater Milwaukee USA
    One approach that I recommend that you NOT do, is to have separate functional manuals. I joined a company that had a separate procedure/instruction manual for each function. This made it very confusing as to where to find certain documents. In addition, they combined procedures (Who, What, When) and instructions (How) into the same document. These documents ended up being extremely long and confusing to interpret. I ended up consolidating the manuals and breaking out instructions. The end result was about 20% as big and the users were much happier.
     
  7. Mehrdad Soltanifar

    Mehrdad Soltanifar Member

    Joined:
    Apr 2, 2020
    Messages:
    21
    Likes Received:
    4
    Trophy Points:
    2
    Location:
    Auckland, New Zealand
    Tony, could you please explain it further?
    I agree that we don't need to have the quality manual at first, but shouldn't we have some procedures in place before we can record our performance against them?

    From experience, I would say these steps are inter-related and there is no one way to achieve this. I mean depending on the organisation's characteristics we might start with defining some instructions and procedures, then document some records, then define a preliminary quality manual, then add more procedures, revise the manual, etc.
     
  8. tony s

    tony s Well-Known Member

    Joined:
    Sep 10, 2015
    Messages:
    1,261
    Likes Received:
    958
    Trophy Points:
    112
    Location:
    Laguna Philippines
    I just wanted to highlight that the quality manual should never be the first to be documented. Hence, the inverted delta. Using the statement in the 2008 version where clause 4.2.2 stated that "organization shall establish and maintain a quality manual that includes: (b) the documented procedures established for the quality management system, or reference to them..." Establishing first the procedures will ensure that the quality manual reflects what are actually being practiced.

    About procedures and records, whichever the organization deems should be documented first is up to them. Keeping in mind that procedure as per definition "can be documented or not".
     
    Mehrdad Soltanifar likes this.
  9. RoxaneB

    RoxaneB Moderator Staff Member

    Joined:
    Jul 31, 2015
    Messages:
    917
    Likes Received:
    1,065
    Trophy Points:
    92
    Location:
    Ontario, Canada
    Similar to @Mehrdad Soltanifar , I agree that there is not necessarily one best way to effectively document a QMS.

    Each organization has, to some degree, existing documentation and "tribal knowledge." So, capturing this and then comparing it to the requirements (be it ISO 9001, ISO 14001, or the requirements of the parent company) and identifying what is already established is that first step. Once the gap is known, then comes the decision of what to capture next. My personal preference is to go by process as opposed to documentation layer - I'd rather, for example, document what is needed for the Procurement process, rather than develop all the needed records for the organization. This approach allows for the development of micro-QMSs within the company and the final check, when the whole process is complete, is making sure that no process is left unconnected...dare we call this the Quality Manual? ;)
     
  10. pkfraser

    pkfraser Active Member

    Joined:
    Aug 1, 2015
    Messages:
    85
    Likes Received:
    53
    Trophy Points:
    17
    Location:
    Aberdeen Scotland
    Taking this a step further, each organisation also has established "ways of doing things" (ie processes!), whether they are documented or not. And this is the first step alongside looking at what is documented to establish what needs to be done to show compliance.
     
  11. John C. Abnet

    John C. Abnet Well-Known Member

    Joined:
    May 23, 2017
    Messages:
    615
    Likes Received:
    428
    Trophy Points:
    62
    Location:
    Upper Midwest- USA
    I see you're once again kicking the proverbial "sleeping dog" @Andy Nichols (thank you!).

    From my professional experiences, the "style" of how documents are structured is somewhat irrelevant and should be left to organizations to determine what best works for them.
    I (personally) am still a fan of the oft derided "archaic" pyramid style. "Procedures" (a macro document [often a flow diagram proves best] thin on text, which captures anything the organization wants to document regarding WHO does WHAT and WHEN), can be an extremely effective approach for the purpose of SUSTAINABILITY.
    During my time in this industry, lack of sustainability is, in my experience, poses the greatest threat to an organization's management system.

    Processes change- customers change- associates change. Organizations need to create their management systems (including whatever "documentation" they deem necessary) assuming that none of their existing customers or associates will still be the same, one, three, five years from now.

    I was recently performing internal audits for one of my clients and my host became defensive as I pointed out some of nonconformances that existed. That individual indicated "you do not appreciate of all the time and effort I put into this". What my host was really stating, was that as long as they are employed at the organization, then that individual would make sure all was well. The problem with that is that, someday, HE/SHE will NOT be at the organization.

    Supporting documents (i.e. "level 3, 4, etc..etc..), can then be task specific work instructions, forms, etc..., which provide detail (when needed) on HOW to perform a task and (when needed) a template for consistent reporting.

    Sustainability-
    If organizations put as much thought into sustainability as they do format, hierarchy, and "document control" when establishing their management systems, they would find their management systems to be a much better tool.

    Hope this helps.


    Be well.
     
  12. Andy Nichols

    Andy Nichols Moderator Staff Member

    Joined:
    Jul 30, 2015
    Messages:
    4,423
    Likes Received:
    2,226
    Trophy Points:
    112
    Location:
    In the "Rust Belt"
    Interesting thoughts, @John C. Abnet. I hope kicking a sleeping dog doesn't cause it to bite me! My endeavor here is to challenge the conventional wisdoms of what a QMS is all about, with the benefit of 30 years of experience and also the challenges faced by clients coming new to QMS implementation. It doesn't take much time and effort to reconcile that 1) the pyramid isn't what the ISO folks imagined when they wrote the standard, 2) the pyramid is impractical and 3) it implies things which are untrue. Let me explain:

    ISO 9001, and 9002, in 1987, required a manual and procedures (although the need for a documented procedure wasn't) and work instructions were ONLY an option to meet the Process Control requirements for manufacturing the product (under controlled conditions, including work instructions "where the absence of such would adversely affect quality"). Since the QM could embody the procedures and work instructions, too, you have a simple, two level QMS, if we take forms to become records of process/instruction implementation.

    If an organization employs a number of Quality Tools, such as PFMEA, SPC etc, are those processes? Do they need a procedure to implement? Work Instructions? The results are recorded on forms, but they are supposed to become "living documents" and updated, which means they can't become records (records shouldn't be changed) unless the organization plans on burying itself in revisions...

    If the shape of the pyramid is taken to indicate the quantity of documents, then that is woefully misleading for many organizations. Smaller organizations, run by skilled, highly competent personnel don't need work instructions. They may not even need a procedure. Practice shows that well designed forms - take the IRS 1040 tax return for, for example - is both work instruction, form and hence record.

    IMHO, the pyramid was someone's "brain fart" back in the early 90's and it goes along with that other myth "Say What You Do, Do What You Say", which was also a lie...
     
    John C. Abnet likes this.

Share This Page