Matrix for: Established, implemented, maintained (5.5.2 Management Representative)

[x-files]

Hi,

I have some questions about understanding meanings of “Established, implemented, maintained”:

5.5.2 Management representative
Top management shall appoint a member of the organization's management who, irrespective of other responsibilities, shall have responsibility and authority that includes
a) ensuring that processes needed for the quality management system are established, implemented and maintained,
[…]

I want to make a matrix with these columns on top, for which I hope, I've classified and expanded correctly, to fit our needs:
* ESTABLISHING (1) – Who has the authority to Add new or Delete existing document
* IMPLEMENTING
Preparing (2) – Who signs “Prepared by” field on the front page
Approving (3) – Who signs “Approved by” field on the front page
* MAINTAINING
Using (4) – Who is responsible to use the document
Requesting changes (5) – Who has the authority to request the document change
Technical maintaining (6) – Who generates .pdf, uploads, archives originals…
… as an extra field I could also add the “Way to control”:
Controlling (7) – Do we, or how we control the document

On the left side can be “Document type“, or better “Document name” because of fine tuning attributes per document.


So I’d have, for example:
“Document control”, (1) MR, (2) IMS Director, (3) MR, (4) Every employee, (5) Every employee, (6) IMS Administrator, (7) DCF.


My questions are:
* Have I understood the proper meanings of “Established, implemented, maintained”, which I further expanded to fit our needs?
* Is there some other valuable attribute to be added to matrix header?
* Does this matrix has sense at all? I think it could be useful for some purposes, mainly to get clear about approval path for example, or just quick changing rules by editing entered parameters.



Best Regards,
Vladimir Stefanovic

 

[insect warfare]

Re: Matrix for: Established, implemented, maintained (5.5.2 Management Representative

You seem to be equating "documents" with "processes" in your post. Remember, not all processes have to be documented (in most cases), and the writers of paragraph 5.5.2 probably did not envision the interpretation of it to mean "create a matrix" (because now you've just added one more document for your organization to maintain). Not really necessary in my opinion, as your documentation system should be as lean as possible without creating unwanted burden....

A good way to interpret 5.5.2 is to have the MR ensure that processes needed for the QMS are established (are they set up?), implemented (have they been put into effect?) and maintained (are they enabled to continue as planned?). It is more of an oversight requirement for the MR than anything, and one that any good auditor would be able to assess just fine, with or without a matrix document, through simple investigation techniques.

Brian

 

[harry]

Re: Matrix for: Established, implemented, maintained (5.5.2 Management Representative

. .................... * Have I understood the proper meanings of ?Established, implemented, maintained?, ...............

Would you agree that an internal audit should reveal whether your system is established, implemented and maintained?

This is one of those area where you demonstrate compliance rather than have a procedure or matrix. The procedure or matrix can only indicate that you have the items but cannot show that it is 'working' for you.

 

[Jim G]

Re: Matrix for: Established, implemented, maintained (5.5.2 Management Representative

I don't believe this matrix would add any value to your organisation, in fact it would be another auditable document for you to keep up to date.
Assuming you have the processes required by the QMS in place, they are being implemented across your organisation and they continue to be an up to date reflection of your business, then any auditor would be able to establish compliance without a matrix.

 

[x-files]

Re: Matrix for: Established, implemented, maintained (5.5.2 Management Representative

I think I understood all your observations. Better to think about compliance, rather than have yet another document to control and think of.


When looking into other “Document control procedures" (DCP), they always easily define approval authorities in a brief list. In „Document control form“ (DCF), near the approval signature line, it’s simpy said something like this:

Approval for Revision (either per the document's stated approval authority of the Document Control Procedure, XYZ)
Approval for Addition (either per the document's stated approval authority of the Document Control Procedure, XYZ)
Approval for Deletion (either per the document's stated approval authority of the Document Control Procedure, XYZ)

The idea for creating a matrix for our particular case is because we already have 120 procedures, and huge and brached organizatational structure (3500 employees) on displaced locations. In practice, we cannot easily define the approval authorities for the procedure, although is sounds easy. Process owners and working positions cannot be connected/linked by simple words: director, manager, leader, etc. Sometimes, two or three process owners, on different locations, are sharing the same procedure, and they all have differently named working positions. We think, every of them has the approval authority to the document. How and where to say that? Furthermore, there are three or even more “Prepared by” persons. Who are they, how to define them?

When creating/editing a procedure, we in advance know:
- How the procedure is to be titled (it’s said in Manual, for example, or in DCF request for new document)
- How we index/number documents [procedures, wi, forms, templates, …] (it’s said in DCP, for example)
- How we format revisions (it’s said in DCP, for example)
- What’s the next revision (it’s in previous DCF record, for example)
- What sections (TOC) the procedure must have (it’s said in DCP, for example)
- What names to add above job titles and signautre line (it’s said organizational structure)
- Possibly, how we format even dates: m/d/yyyy or d/m/yyyy
- etc, …

Observing so, I can see that a procedure, as an integral document prepared to be self-contained as much as possible - pretty much is assembled from other “older” documents. The exception is of course the pure essence of a procedure - “Defined activities”.

So, can/how we in advance know who are the approval authorities for the procedure, or the procedure text is the first time when that’s mentioned? Sometimes, I saw that’s said in the Manual, but not in our case so far.

Other columns I stated in initial post are just extension.



Best regards,
Vladimir Stefanovic

 

[insect warfare]

Re: Matrix for: Established, implemented, maintained (5.5.2 Management Representative

So, can/how we in advance know who are the approval authorities for the procedure, or the procedure text is the first time when that?s mentioned? Sometimes, I saw that?s said in the Manual, but not in our case so far.

Just as an example, we define the approval authorities for each document on our master list, so the document controller can quickly prepare the necessary approval records for completion. How do we know who those approval authorities should be?....we just read the documents. It should be evident in the procedural documents who those entities are - if not, we consider such documents inadequate and we instruct the authors to consider additional markups.

For us, approval authorities mainly consist of the process owners, because we understand they should have ultimate responsibility for the processes defined within (including any associated documentation). Our documentation structure is broken down by process and not by department, so most of the time the approval authorities will consist of one, maybe two process owners. We know it is in our best interests to keep it simple that way.

Obviously there are many other ways to achieve the same thing, but your organization should not have to end up complicating this aspect of the documentation.

Brian

 

[x-files]

Re: Matrix for: Established, implemented, maintained (5.5.2 Management Representative

Just as an example, we define the approval authorities for each document on our master list [...]

If you are referring to "Master document list", that could be the answer on my question. Our MDL does not have Approval column, just titles, revisions, dates... If I add Approval column, I got the functionality I want.



Best Regards,
Vladimir Stefanovic

 

[somashekar]

Re: Matrix for: Established, implemented, maintained (5.5.2 Management Representative

Just let the MR Establish, Implement and Maintain the QMS, directly or through his associates under his direct authority.
There is no need to write about it, which makes it all the more confusing and non value added.

 

[insect warfare]

Re: Matrix for: Established, implemented, maintained (5.5.2 Management Representative

If you are referring to "Master document list", that could be the answer on my question. Our MDL does not have Approval column, just titles, revisions, dates... If I add Approval column, I got the functionality I want.



Best Regards,
Vladimir Stefanovic

Never hurts to try something out, I always say - this method may or may not be suited to your taste. Be sure to let us all know how it works out for you....we always appreciate updates from experiments undertaken.

Brian