Document Hierarchy Structure for Documents Compliant in ISO 9001 and CMMI
Thank you Ajit for your reply. What I meant is that our current document structure is:
Level 1: Manual
Level 2: System Procedures
Level 3: Operational Procedures
Level 4: Forms
Our Level 3 procedures are generally for our core services and departmental procedures. I am quite clear on the departmental procedures/support services (HR, Purchasing, etc.) but for our services for example facility management. We have a "generic" set of procedures for FM that sites are ought to follow. But we have over 50 site projects reporting to different clients and that they may have their own requirements so our site managers may need to modify our Level 3 procedures to conform with the client's requests. In this case, should the site-specific procedures be maintained by the company's document controller or the respective site should keep their own procedures? Will these be considered a Level 5 in the doc structure?
Thank you.
Level 1: Manual
Level 2: System Procedures
Level 3: Operational Procedures
Level 4: Forms
Our Level 3 procedures are generally for our core services and departmental procedures. I am quite clear on the departmental procedures/support services (HR, Purchasing, etc.) but for our services for example facility management. We have a "generic" set of procedures for FM that sites are ought to follow. But we have over 50 site projects reporting to different clients and that they may have their own requirements so our site managers may need to modify our Level 3 procedures to conform with the client's requests. In this case, should the site-specific procedures be maintained by the company's document controller or the respective site should keep their own procedures? Will these be considered a Level 5 in the doc structure?
Thank you.
To begin, we have this very basic "document pyramid":
A thought - A call center which handles multiple clients. Operators are divided up into different customer groups, the size of which (number of "operators") depends upon the specific customer needs (E.g: calls per hour or calls per week, as an example). Each customer has a specific set of instructions which operators which handle their calls must follow. The instructions for each customer are going to be unique (e.g.: Sears vs. Walmart, or technical support vs. sales). My point is, the "document pyramid" is a general guideline for classifying documents. If you REALLY want to, you could have a 20 Tier document pyramid, but what good would it serve?
Keep it simple.
Re:
I have worked with companies which had multiple national and international divisions, locations, etc. Typically all requirements flow down starting with corporate at the top. If any location or division lower down on the chain needed/wanted a corporate (or other level" / location) level procedure/policy/<other document revised which had been flowed down to them>, they had to determine the owner of the document they wanted revised and submit a document change request in conformance with the applicable corporate (or lower level) procedure for document revisions.
I do understand that things can become quite complicated these days. There are so very many corporate mergers, buyouts and various other "stuff" corporations / companies do these days; even building (not to mention maintaining) an organizational chart can be problematic (and it can change so often and so fast!). This is because the people doing the merging or whatever rarely look at anything other than their top structure. They are into financials and their predictions (how to make more money, and how to...) for the future. If, for example, they buy a small company which already has it's own procedures and corporate/company hierarchy, how will top level requirements affect them and their current procedures becomes an issue. Ultimately, most upper management are focused upon the financials - Not the repercussions and aded time, costs, etc. when things have to be merged.
As to:
As a last "editorial" thought: It's 2018. Remember that the old "4 level document pyramid" in very old. It is from before the days of things like:
Think about how they merge / consolidate, if they actually ever really do, their documents, various requirements, do requirements flow downs. Document control and classification is complicated these days, but not impossible to deal with.
A thought - A call center which handles multiple clients. Operators are divided up into different customer groups, the size of which (number of "operators") depends upon the specific customer needs (E.g: calls per hour or calls per week, as an example). Each customer has a specific set of instructions which operators which handle their calls must follow. The instructions for each customer are going to be unique (e.g.: Sears vs. Walmart, or technical support vs. sales). My point is, the "document pyramid" is a general guideline for classifying documents. If you REALLY want to, you could have a 20 Tier document pyramid, but what good would it serve?
Keep it simple.
Re:
You would have to explain how a customer's requirements would trigger a revision of your internal procedures (I assume that is what you are saying). I DO see this happening, especially with record retention requirements. I read recently where a customer requirement came in for records retention of 20 years while their internal requirements were set at 5 years retention. This could be handled in 1) a revision to the company's record retention requirements / policy, or 2) the company (location or whatever) could make it a "Customer Specific Requirement". Every scenario is so specific that it is hard to generalize and say "This makes the most sense".
I have worked with companies which had multiple national and international divisions, locations, etc. Typically all requirements flow down starting with corporate at the top. If any location or division lower down on the chain needed/wanted a corporate (or other level" / location) level procedure/policy/<other document revised which had been flowed down to them>, they had to determine the owner of the document they wanted revised and submit a document change request in conformance with the applicable corporate (or lower level) procedure for document revisions.
I do understand that things can become quite complicated these days. There are so very many corporate mergers, buyouts and various other "stuff" corporations / companies do these days; even building (not to mention maintaining) an organizational chart can be problematic (and it can change so often and so fast!). This is because the people doing the merging or whatever rarely look at anything other than their top structure. They are into financials and their predictions (how to make more money, and how to...) for the future. If, for example, they buy a small company which already has it's own procedures and corporate/company hierarchy, how will top level requirements affect them and their current procedures becomes an issue. Ultimately, most upper management are focused upon the financials - Not the repercussions and aded time, costs, etc. when things have to be merged.
As to:
As of what we know about your specific situation, at this point I would say no.
As a last "editorial" thought: It's 2018. Remember that the old "4 level document pyramid" in very old. It is from before the days of things like:
- Company A owns Companies B, C, D, E (etc).
- Company B owns Companies G, H, and J.
- Company J owns Companies M, N and P.
- Company P owns Companies Q, R and S.
- Etc. etc.
Think about how they merge / consolidate, if they actually ever really do, their documents, various requirements, do requirements flow downs. Document control and classification is complicated these days, but not impossible to deal with.
Last edited:
