The Elsmar Cove Wiki More Free Files The Elsmar Cove Forums Discussion Thread Index Post Attachments Listing Failure Modes Services and Solutions to Problems Elsmar cove Forums Main Page Elsmar Cove Home Page
Google
  Web Elsmar.com
*Please be aware that SOME RECENT forum threads may not yet be indexed by Google.

View Full Version : Manager's version of the process contradicts personnel running the process


qualityboi
6th November 2008, 07:10 PM
While auditing a process (sorry I can't be more specific as people from my company may see this), the manager's version of the process flow was different than what was significantly different than two technicians that I interviewed on the floor especially for the mechanism for out of control data points, spc rules. The process is not documented, and since there was conflicting information I am going to write this up. I am just wondering how to word it so as not to make the manager look dumb or not to get the technicians in trouble...:(

MIREGMGR
6th November 2008, 07:22 PM
Just write it up for being undocumented. Then the next time it's audited, either the way it's actually done or the manager's version won't agree with the documentation...unless the process of documenting what they're doing now prompts the manager and the techs to get coordinated.

RCBeyette
6th November 2008, 07:35 PM
Unless there is a requirement for the process to be documented, issuing a nonconformance on the lack of a document wouldn't add much value...in my opinion.

I would suggest writing the nonconformance in such a way to demonstrate that the lack of standardization within the process runs the risk to negatively impact the ability to state that product meets requirements or that the process is under control.

AndyN
6th November 2008, 07:40 PM
Indeed, the lack of documentation is not the issue. The real kicker would be to discover whose version was more effective! One of the things people do is 'make up' for parts of the managers version, where they find it's not effective.

You did a good job of detecting the difference. To be a great auditor, you have to find out which version gives the best results!

Nice work!

julsbear
7th November 2008, 02:15 PM
The writeup should be for the discrepancy in understandingof how the process work or is practiced. This would highlight the need for this processto be documented. As part of the documentation process it can be decided what is needed to accomplish what is intended. Part of "best results" could be:
1) What meets the requirements
2) What is more stable.
3) If the requirement is one sided, what gives the more desirable result. (Yield, purity etc.)

From experience, the manager may have seen a very short term result meeting criteria 1. The techs may be doing things that deal with all three.

Only when you know under which conditions you are/have run and track the results, can you answer which is better.

AndyN
7th November 2008, 02:21 PM
Only when you know under which conditions you are/have run and track the results, can you answer which is better.

This statement, in a nutshell, is what all auditors should be looking for to determine what's effective. This is the value in an audit finding that assists management to identify what actions are necessary in response to the audit finding, much, much more than just telling that 'we didn't follow the process'.

What a great point, Julsbear - thanks for making it!

Wes Bucey
7th November 2008, 04:19 PM
FWIW:
My take on the situation is slightly different:


There is an undocumented process - it gets an NC
There are two versions of the process - it is NOT the auditor's place to determine WHICH is better, merely to point out the obvious: the variance "could" lead to producing nonconforming product. Also obvious, manager did not have a process for affirming the operators agreed with his version of a process and did, in fact, implement the process according to his version.
An Opportunity for Improvement (OFI) could ALSO be generated, describing the opportunity to conduct Design of Experiment exercises to determine the optimal process [not limited to the two known processes]

An interesting set of side issues:
(grist for a management review, NOT an auditor report):


Did operators EVER follow the manager's method?
Did the manager change, NOT the operators?
If yes to either (1) or (2), when and why did they change?
If no, was the training adequate and accurate??
Should the training method be changed?
Is either method the viable one?
If not, what is necessary to determine the most viable and optimal method?

This situation would make for an excellent case study on determining root cause!

RCBeyette
7th November 2008, 07:42 PM
There is an undocumented process - it gets an NC

Where is the need for a document? I will grant you that the inconsistent approach towards the process leads one to believe that a document would be great, but it could be something as simple as determine the correct method, generating a one-point lesson and getting back to business.

In today's businesses - which are demanding efficiency and effectivess - a documented procedure may not always be the best solution.

There are two versions of the process - it is NOT the auditor's place to determine WHICH is better, merely to point out the obvious: the variance "could" lead to producing nonconforming product. Also obvious, manager did not have a process for affirming the operators agreed with his version of a process and did, in fact, implement the process according to his version.

Who's to say the manager's version is the correct version? :cool:

That being said, I agree that the lack of consistency in the process should be the focus of the nonconformance as it may increase the risk of final product and/or overall process not meeting requirements.

An Opportunity for Improvement (OFI) could ALSO be generated, describing the opportunity to conduct Design of Experiment exercises to determine the optimal process

A nice idea and it may get the team thinking about their overall process, however, smaller shops may not have the resources available at this time to implement such exercises.

This situation would make for an excellent case study on determining root cause!

I don't think any one here will disagree with that, but I would really hate to see the root cause attributed to the lack of a document. That simply skims the surface of the situation.

Wes Bucey
7th November 2008, 08:33 PM
Where is the need for a document? I will grant you that the inconsistent approach towards the process leads one to believe that a document would be great, but it could be something as simple as determine the correct method, generating a one-point lesson and getting back to business.

In today's businesses - which are demanding efficiency and effectivess - a documented procedure may not always be the best solution.



Who's to say the manager's version is the correct version? :cool:

That being said, I agree that the lack of consistency in the process should be the focus of the nonconformance as it may increase the risk of final product and/or overall process not meeting requirements.



A nice idea and it may get the team thinking about their overall process, however, smaller shops may not have the resources available at this time to implement such exercises.



I don't think any one here will disagree with that, but I would really hate to see the root cause attributed to the lack of a document. That simply skims the surface of the situation.If the root cause investigation STOPPED at "lack of a document," that would be a tragedy. That would be almost as bad as "operator error." The five Whys comes in handy in cases like this.

There may be lots of reasons to issue (if one were so inclined) an NC:
if I were looking to nitpick, I'd probably start with
7.5.1 Control of production and service provision
The organization shall plan and carry out production and service provision under controlled conditions.
Controlled conditions shall include, as applicable,
a) the availability of information that describes the characteristics of the product,
b) the availability of work instructions, as necessary,
c) the use of suitable equipment,
d) the availability and use of monitoring and measuring equipment,
e) the implementation of monitoring and measurement, and
f) the implementation of product release, delivery and post-delivery activities.It seems to me an auditor could make a de facto argument that his observation of a discrepancy in understanding the details of a work process indicates a lack of controlled conditions in product realization. Written work instructions may not be necessary, but it is obvious there is a disconnect in communication of some sort when operators perform processes differently from what management has planned. It may or may not matter to the end product whether one process or the other is used or even if one is more efficient than the other, but the lack of a consistent process bears further investigation.

If the auditor is kind and not looking to play "gotcha," he writes an OFI. My question is "Does the OFI hit management review with the same impact as an NC?"

Alternately, one might refer to
7.5.2 Validation of processes for production and service provision
The organization shall validate any processes for production and service provision where the resulting output cannot be verified by subsequent monitoring or measurement and, as a consequence, deficiencies become
apparent only after the product is in use or the service has been delivered.
Validation shall demonstrate the ability of these processes to achieve planned results.
The organization shall establish arrangements for these processes including, as applicable,
a) defined criteria for review and approval of the processes,
b) approval of equipment and qualification of personnel,
c) use of specific methods and procedures,
d) requirements for records (see 4.2.4), and
e) revalidation.In my opinion, these requirements are not limited to products which may have "hidden" nonconformances.

As I inferred, "rogue operators" are only a symptom, not a root cause. The management of the organization does not have an apparent, auditable process to assure its processes are performed consistently.

Just because I did not act as a "well-trained, well-mannered auditor" by citing the "shalls" in my first post doesn't mean I'm at fault - Deming suggests you blame my manager!:lmao:

RCBeyette
8th November 2008, 10:19 AM
Wes:

With all due respect, I did not expect you to cite the shall's. I am certain, however, that they will be appreciated by the original poster who is questioning the lines along which a nonconformance may be written.

That being said, the availability of work instructions is "as necessary." As auditors, do we have the right to say what is necessary? The answer to this is, in my opinion, we have that right only when the risk posed by the lack of documentation is high. As auditors, our role is not only to assess the organization's level of conformance to requirements and the effectiveness of the system, but we are now to assess the level of risk of the gaps. This allows the organization to prioritize their actions and resources.

Without knowing the details of the original poster's organization and the impact that the provided example has on both the ability to meet requirements and control the overall process, it is impossible for Cove Members to provide a black-and-white answer.

Phrasing a nonconformance such that the potential risks are highlighted (i.e., a solution will add value to the organization's bottom line) will probably generate the most attention from the organization. The nonconformance can not simply be worded as "The process for xxx is not documented." Tying the appropriately worded finding to Clause 7.5.1 would ensure that everything is written up in a suitable manner and initiate - hopefully - a root cause analysis that goes to the right depth.

BradM
8th November 2008, 11:01 AM
Hello qualityboi!

One of Roxane's points got me thinking... I would think a higher tier procedure would at least specify which processes should be documented and which aren't. Also (as I learned of a need yesterday in a situation) there may be times to deviate from a documented process, but there should be steps for that.


So if there is no procedure for determining processes that do/don't require documenting, I would think that would be a worthwhile mention. Otherwise, managers may think nothing needs to be documented (when it probably should), while another manager feels everything has to be documented (that does not need to be).

Sidney Vianna
8th November 2008, 12:08 PM
As auditors, do we have the right to say what is necessary? The answer to this is, in my opinion, we have that right only when the risk posed by the lack of documentation is high. As auditors, our role is not only to assess the organization's level of conformance to requirements and the effectiveness of the system, but we are now to assess the level of risk of the gaps. This allows the organization to prioritize their actions and resources.:agree1:Very, very insightful. You should expand your "auditing in the XXI century program" to outside entities. More "professional" auditors need to hear that message. Keep it up. :yes:

The concept of "managing risk" is the only sustainable answer to management system implementation and assessment. Somebody should use that as a slogan....:tg:

John Broomfield
8th November 2008, 02:22 PM
While auditing a process (sorry I can't be more specific as people from my company may see this), the manager's version of the process flow was different than what was significantly different than two technicians that I interviewed on the floor especially for the mechanism for out of control data points, spc rules. The process is not documented, and since there was conflicting information I am going to write this up. I am just wondering how to word it so as not to make the manager look dumb or not to get the technicians in trouble...:(

If as a result of this confusion the process is ineffective then you have a 4.1c nonconformity: system failed to determine the criteria and methods necessary for effective operation of the process. Blame the system not the people, unless of course the leader is willing to step up to the plate.

Big Jim
9th November 2008, 01:23 AM
Quote from Wes:

"There is an undocumented process - it gets an NC"

Try as you may, you cannot find a "shall" for this. Unless it is one of the six required procedures, they do not need to be documented.

With further investigation, one of the "shalls" you quoted may be appropriate, as well as others, but not just because you stumbled across something that isn't documented.

With what has been disclosed at this point, to me, it is just an audit trail. It may or may not end up being an NC. I think it likely would end up being one, but not from the evidence at hand.

PS: I kind of like the possibility of John Broomfields idea of this being against 4.1c, but again not without more information.

Jupitor
9th November 2008, 09:09 AM
I find this very interesting, informative and thought provoking discussion. Let me put across my views.
Firstly we could note down what the operators are actually following on the floor. Then get the manager's version. This would be necessary to ensure we have understood the position correctly. In case there is indeed a discrepancy, the discussion with the manager should highlight the need for documenting an effective process/process control procedure lack of which is an NC.

Now, NC under which clause?
4.2.1 c) ...documents needed ...to ensure effective ...operation & control of its processes.

7.5.1 b) ...controlled conditions shall include as applicable...the availability of work instructions as necessary

8.2.4 ......monitor ...to verify the product requirements have been met....carried out at appropriate stages...in accordance with planned arrangements (7.1). This would link with 7.1 b) ...establish documents....etc.

Helmut Jilling
9th November 2008, 10:09 AM
Quote from Wes:

"There is an undocumented process - it gets an NC"

Try as you may, you cannot find a "shall" for this. Unless it is one of the six required procedures, they do not need to be documented.

With further investigation, one of the "shalls" you quoted may be appropriate, as well as others, but not just because you stumbled across something that isn't documented.

With what has been disclosed at this point, to me, it is just an audit trail. It may or may not end up being an NC. I think it likely would end up being one, but not from the evidence at hand.

PS: I kind of like the possibility of John Broomfields idea of this being against 4.1c, but again not without more information.

Cl 4.1.b requires that the sequence and interactions of processes be defined. If there are two verbal versions, I don't think that will likely end up complying. I would go with your comment "it's an audit trail for now..." but it would likely end up as an NC.

Stijloor
9th November 2008, 10:35 AM
While auditing a process (sorry I can't be more specific as people from my company may see this), the manager's version of the process flow was different than what was significantly different than two technicians that I interviewed on the floor especially for the mechanism for out of control data points, spc rules. The process is not documented, and since there was conflicting information I am going to write this up. I am just wondering how to word it so as not to make the manager look dumb or not to get the technicians in trouble...:(

The standard uses the word "defined" quite a bit. "Defined" can be in practice and/or a document. That's your organization's choice. What I concluded from your post is that the process definition based on statements of fact (a verbal response from an auditee that is considered audit evidence) is inconsistent. So it is a nonconformity in my book. The corrective action will consist of defining what actually has to happen and having the stakeholders agree to it (preferebly by consensus). Next, you will verify that the agreed upon and defined process is effective. No need to make it unnecessarily complex. See? Not even a "document" involved.;)

End of the story.

Stijloor.

AndyN
9th November 2008, 11:26 AM
This is an interesting thread. Sitting here at breakfast on Sunday am, something occurs to me.......

Was this issue simply stumbled on by the auditor? Was the audit scheduled to some calendar of processes or requirements and the auditor was perceptive enough to find that the story between management and staff? Why were we (I mean you, Qualityboi) auditing?

My beliefs are that we have to have a better reason for doing an audit than because some (sometime, arbitrary) calendar sends us to audit. It isn't good audit management that this issue was (luckily) stumbled upon. However, if we were auditing based on 'status and importance', then there's a much better reason why this finding should be identified and corrected:-

There's been a problem (to customers or internally, causing scrap, etc.)
It's a new or changed process
It's working better than expected (planned)

An effective and organized auditor will have researched the background to the process issue and will have a good idea what results are being seen. From that it's easier to determine the effectiveness of the process and therefore, which 'version' of the story is working.

When reported as such, it's clearer for management which course of action(s) are necessary and the audit is seen as value added!

Back to my porridge........

John Broomfield
9th November 2008, 11:43 AM
Agreed, yet another reason for every audit having an objective. The differences may be unimportant.

Wes Bucey
9th November 2008, 11:46 AM
The standard uses the word "defined" quite a bit. "Defined" can be in practice and/or a document. That's your organization's choice. What I concluded from your post is that the process definition based on statements of fact (a verbal response from an auditee that is considered audit evidence) is inconsistent. So it is a nonconformity in my book. The corrective action will consist of defining what actually has to happen and having the stakeholders agree to it (preferebly by consensus). Next, you will verify that the agreed upon and defined process is effective. No need to make it unnecessarily complex. See? Not even a "document" involved.;)

End of the story.

Stijloor.
No documents are involved in the rosy picture you paint, but reality in practice has a few snags - primary being "mission creep" where the "players" add or subtract parameters to a process as time goes on. Without the document for a reference, mission creep invariably leads to changes from the original plan. (sort of like a game of "telephone")

The process you describe depends on accurate "word of mouth" training from shift to shift and generation of worker to generation of worker. Rarely does such dependence on undocumented processes result in consistent application of the original process.

The process you describe is akin to showing one manager the blueprint of a product, removing the blueprint, and requiring him to maintain consistent production of the product from one or more operators when no operator has access to the original blueprint. Possible, but not probable!

Which is why this clause
7.5.1 Control of production and service provision
The organization shall plan and carry out production and service provision under controlled conditions.
Controlled conditions shall include, as applicable,
a) the availability of information that describes the characteristics of the product,allows some organizations with relatively simple processes to do without documentation, while in others, the "as applicable" spectre looms large.

We are not privy to the exact process under consideration, but it seems reasonable to infer it is complicated enough to have at least two different versions. Simple mistake-proofing by having a written work instruction is worth an OFI at least, wouldn't you agree?

Stijloor
9th November 2008, 12:03 PM
No documents are involved in the rosy picture you paint, but reality in practice has a few snags - primary being "mission creep" where the "players" add or subtract parameters to a process as time goes on. Without the document for a reference, mission creep invariably leads to changes from the original plan. (sort of like a game of "telephone")

The process you describe depends on accurate "word of mouth" training from shift to shift and generation of worker to generation of worker. Rarely does such dependence on undocumented processes result in consistent application of the original process.

The process you describe is akin to showing one manager the blueprint of a product, removing the blueprint, and requiring him to maintain consistent production of the product from one or more operators when no operator has access to the original blueprint. Possible, but not probable!

Which is why this clause
allows some organizations with relatively simple processes to do without documentation, while in others, the "as applicable" spectre looms large.

We are not privy to the exact process under consideration, but it seems reasonable to infer it is complicated enough to have at least two different versions. Simple mistake-proofing by having a written work instruction is worth an OFI at least, wouldn't you agree?

Wes,

You make excellent points. :agree1:

I am not opposed to documents supporting a process. But the OP pictured a situation where the process was not documented and where he apparently heard two different interpretations for this process. The point I was trying to make that even though the process was not documented, he could still note this as a nonconformity because the definitions were different.

Not knowing the complexity of the process and the required competencies, it may be necessary to document this process. But as we all know, having a documented process does not always assure compliance or consistency in practice.

Stijloor.