How do you decide what is a Process, a Procedure or Work Instruction?

[Jim Wynne]

Re: How do you decide what is a process, procedure or work instruction?

I guess I missed this when it was first posted, sorry for the tardiness of the response.

Slow down Jim, take it easy. I split that level up for many reasons. One of them is repeatedly expressed throughout this series of forums; that of having way too many documents. My level three consists of those work instructions (documents that provide specific HOW TO) that directly address an ISO requirement. My level four are those documents that you would like to have in your organization but are ones that ISO gives no direction for and has no guidance for. The registrar has no jurisdiction over the content of how you set up your coiling machine or how you distribute bonuses or how your safety committee meets and reports. These are not directly ISO subjects, thus they belong in a separate classification.

ISO requires documentation (beyond what's directly specified in the standard) necessary for the functioning of the system. The ones you're referring to as your level four are not significantly different from your level 3 with regard to classification, thus it seems that creating a separate classification serves no useful purpose. Whether or not they are "directly ISO subjects" is irrelevant. They are quality management system subjects, and thus carry the same weight and import, and are just as auditable.

I suppose I should have been more clear. The level fours I refer to do not have to be audited by your registrar and generally will not even be reviewed. They do have to be audited according to your internal requirements. Since they do not address an ISO requirement they really can't be audited by the registrar. The registrar has no criteria with which to evaluate them with anyway. All the registrar can really do is audit the presence of a required instruction. Then the auditor can follow the operator as they conduct the activity but for the most part the auditor will be busy trying to audit the processes and related level three documents.

If your level four documents are integrated in the QMS, they are auditable. Whether or not a registrar's auditor chooses to audit them is a separate question. The idea that they "...do not address an ISO requirement..." is simply wrong; as I said above, ISO requires documentation necessary to the functioning of the system. The fact that the standard isn't specific as to what that might include is simply the result of there being too many different cases to consider. Simply put: if documented procedures (which includes such things as work instructions) are included in the scope of the QMS, they become auditable, regardless of whether or not the standard specifically and explicitly requires them.

Come on Jim, tell me you didn't use that word. Your messin' with me right? I covered the rationale for the 'bifurcation' in the previous discussion.

Actually, the presence, the legibility, identifiability and distribution are every bit as important in the world of document control as is the content Jim. Immutable (if you must use those 'big kid' words) fact is fine but how it gets presented to the organization is very important and must be controlled.

It seems to me that the meaning of what you refer to as "big kid words" is apparent from context. Forgive me if I have higher regard for the reading comprehension of most Covers than you apparently to. I thought that I was addressing a "big kid," and thus didn't think it necessary to limit myself to words of two syllables or less. My bad.

I hesitate to even admit it but I have worked with over 100 different organizations and have yet to see one of them put the QM to any use of any kind. Yes, in most cases, the QM is issued to fill a requirement. Like it or not that's what is happening in the real world.

I'm well aware of the condition of the real world; I don't like it, and rather than facilitating it, I do my best to help people understand how to make things better, and how to make documentation actually functional. One way to do this is to avoid creating unnecessary dichotomies.

Jim, I hope you don't take offense but I truly hope you don't write your internal documents the way you write your Elsmar posts. I did experience a registrar noncompliance for an organization using the phrase "...all employees practice good stewardship of the customer's product..." or something like that. Nobody knew what 'stewardship' meant; nope, not a single employee. The pretty word did nothing but guarantee a noncompliance for this company. Maybe 'effective' would have been every bit as effective...you think?

No offense taken. I do my best to use words that best fit the meaning I intend to convey, and I do take my target audience into consideration. Note that there is a subtle difference in meaning between "effective" and "efficacious" in the context at hand; it's possible to be effective without being efficacious.

We all know that it's eminently possible to cookie-cutter your way to registration, but if you set out with banality and needless rigor aforethought, you'll wind up with a system that's banal and needlessly rigorous.

OK, I give up. Any takers on what Jim is talking about here?

Reference to the definition of banal provides a clue; consider its possible antonyms and you'll have an idea of what I was referring to.

 

[meo786]

very nice discussion for new guys like me

 

[Jody1]

Excellent knowledge on display here. I have a question.

I am new to an organisation and come form a different industry (which had procedures and work instructions)

The new place has
QM
QA procedures
SOP's Standard operating procedures and WI's

I wanted rid of the SOP's but found that the industry term for this doc is SOP and calling them WI's would only cause communication problems with customers etc.

So my thoughts are to ditch the Wi's as they are performing the same function as the SOP's and use the SOP's as the HOW TO documents and keep the QAP's as the who does what when type docs.

I need to start work on the education of the business in document structure (pyramid etc) as we currently have policies that include the how to ?

Anyhow your thoughts and suggestions welcome......

New here and really enjoyng what i have found at the cove!

 

[Patricia Ravanello]

Excellent knowledge on display here. I have a question.

I am new to an organisation and come form a different industry (which had procedures and work instructions)

The new place has
QM
QA procedures
SOP's Standard operating procedures and WI's

I wanted rid of the SOP's but found that the industry term for this doc is SOP and calling them WI's would only cause communication problems with customers etc.

So my thoughts are to ditch the Wi's as they are performing the same function as the SOP's and use the SOP's as the HOW TO documents and keep the QAP's as the who does what when type docs.

I need to start work on the education of the business in document structure (pyramid etc) as we currently have policies that include the how to ?

Anyhow your thoughts and suggestions welcome......

New here and really enjoyng what i have found at the cove!

Hi Jody,

I think the attachment below is fairly self explanatory, but just to set you off in the right direction...

1) Identify your KEY BUSINESS OPERATING SYSTEM PROCESSES...those will become your Procedures or SOPs...you shouldn't have more than about 12-15 of them.

2) All the other Work Instructions or sub-processes left in your existing system have to be subordinate to one of your procedures...so marry them up with the right procedure, remembering, Work Instructions are only required where more detail or information is required...there should be NO orphan Work Instructions. Each one belongs to one of your Key Processes/SOPs​

.
The attached Matrix lists a sample of KEY Processes or Procedures(SOPs), and as an example, under SOP-0008 Purchasing and Materials Management, you see all the supporting Work Instructions which provide the details.

If you look at SOP-0010 Product Realization, you see that it is very complex, in that it is comprised of 10 Phases....I've chosen to use 'Phase 9 - Product Launch, Production and Delivery" to show you how the Work Instructions are matched up with their "parent" procedure.

This Documentation Matrix will help employees to understand your documentation hierarchy, so it's important that you take the time to build it correctly, and provide them with a visual that they can understand and follow. It will also help you to identify where there are gaps in documentation, or the need for additional Work Instructions, as appropriate.

Hope this helps.

Patricia

Afterthought...For your reference...the second attachment is a fairly widely accepted interpretation and definition of the documents typically found in an ISO-compliant Management Operating System. You can structure your pyramid/model/whatever as you choose, with as many or few layers as you deem appropriate.

Also...I'm a bit confused by your company's "Quality Procedures"...why are they segregated from the SOPs??I]

 

[Jody1]

Thanks for the reply, however I think you missed my objective here let me try again

The mining industry does not recognise WI's they only recognise SOP's when really the SOP's by there very nature (descriptive) are more like a WI. As our customers constantly ask "what SOP are you working to" etc. by renaming them as WI's we would only confuse and make our life harder.

The organisation has some internal WI's (this only confuses the situation)

the QAP's are what i class as the true procedures. therefore thoughts are to irradicate the WI's (so not to confuse) keep QAP as the Higher level procedure (below the QM) and then use the SOP terminology for the instructional stuff.

This would then mean that the QAP calls out the specific SOP's required to carry out activities

Therefore when external agencies ask "what SOP are you working to" we will give them our process instruction data without confusing them with "here are our Work Instructions" and them saying "we do not undersatnd please show us your SOP's"

Hope this clarifies my question. As i am already clear on the standard document pyramid etc.

 

[Helmut Jilling]

Excellent knowledge on display here. I have a question.

I am new to an organisation and come form a different industry (which had procedures and work instructions)

The new place has
QM
QA procedures
SOP's Standard operating procedures and WI's

I wanted rid of the SOP's but found that the industry term for this doc is SOP and calling them WI's would only cause communication problems with customers etc.

So my thoughts are to ditch the Wi's as they are performing the same function as the SOP's and use the SOP's as the HOW TO documents and keep the QAP's as the who does what when type docs.

I need to start work on the education of the business in document structure (pyramid etc) as we currently have policies that include the how to ?

Anyhow your thoughts and suggestions welcome......

New here and really enjoyng what i have found at the cove!

Whatever you want to call them is OK, it depends on wha is good for your organization.As to what to keep, keep those you feel provide value, and obsolete the rest. File the obsolete ones and see if anyone misses them.

The standard explains what is required in cl 4.2.1. However, you have to decide what is useful to your company. Good Luck to You...

 

[meo786]

Dear Sir,

In my point of view, WI are create lot of problem so you can change all the WI into SOP,

Excellent knowledge on display here. I have a question.

I am new to an organisation and come form a different industry (which had procedures and work instructions)

The new place has
QM
QA procedures
SOP's Standard operating procedures and WI's

I wanted rid of the SOP's but found that the industry term for this doc is SOP and calling them WI's would only cause communication problems with customers etc.

So my thoughts are to ditch the Wi's as they are performing the same function as the SOP's and use the SOP's as the HOW TO documents and keep the QAP's as the who does what when type docs.

I need to start work on the education of the business in document structure (pyramid etc) as we currently have policies that include the how to ?

Anyhow your thoughts and suggestions welcome......

New here and really enjoyng what i have found at the cove!

 

[Patricia Ravanello]

Thanks for the reply, however I think you missed my objective here let me try again

The mining industry does not recognise WI's they only recognise SOP's when really the SOP's by there very nature (descriptive) are more like a WI. As our customers constantly ask "what SOP are you working to" etc. by renaming them as WI's we would only confuse and make our life harder.

Hope this clarifies my question. As i am already clear on the standard document pyramid etc.

Hi Jody,

As Helmut said...call them whatever you want. You still need to organize them so they make sense, both to you and your customers, where applicable. I understand your nomenclature problem...you still have to be able to distinguish between the different types of documents (especially for system and audit planning purposes) - that was the point of my first attachment (above).

Perhaps, where it's useful or important to have a distinction in document types, you could use numbering to identify the different kinds of documents, without adding new terminology, while respecting the old.

Example:
...If one of your Key Process is:

SOP-08 Purchasing & Materials Management​

...you could Name the associated/supporting Instructions:

SOP-08.1 Material Requisition
SOP-08.2 Supplier Selection
SOP-08.3 Supplier Performance Evaluation​

You could even carry it further by labelling associated forms by adding another decimal place...

SOP-08.01.1 Purchase Requisition Form
SOP-08.01.2 Purchase Order Form​

In this way, you don't confuse the customer, and you've distiguished the levels of documentation within your system and created families of documents. The Purchasing Department would most likely "own" all the documents starting with SOP-08...

That way you can stick with "SOPs", and you can still structure your system in a logical manner....I don't know how you'd ever make the distinction for the purposes of addressing 4.1.a and b...defining the key Management System Processes...their sequence and interaction, if everything is called an SOP.

Good Luck,
Patricia

 

[gfreely]

Just a little unsolicited input...

In one of my previous lives (career fields), we were one branch of a national company. We had the QAM, corporate-controlled SOPs, and our branch's LOPs (our attempt at WIs).

Just thought I'd share...

and by-the-by, you want to talk CONFUSING ...

at my present position, I am taking a newer department of my company (who had their OWN doc system set up) and bridging/integrating it into the company's QMS. Try and tell a 20 yr Manufacturing manager that you are changing his documentation system...it's like trying to yank a steak away from a pit bull...

 

[Bill Goss]

I would not get too hung up on what a document is called. For example, in the old days we were all using the pyramid showing the 5 levels of documentation. Remember this? The level 1 was a policy (Quality Manual) that defined the high level commitment from management, sort of a "I swear to Quality" type of document. Then the level 2's were the procedures that defined who does what, when, where, and sometimes why. The level 3's were the work instructions or Standard Operating procedures (SOP's) that defined the "how" and these supported the level 2 procedures.

Well, in real life often we find the "how" in the level 2 procedure. So people were unsure what to call the document. My advice was always to call it at the highest level it could possibly cover. So if a procedure included "how" information, just call it a procedure and don't get hung up on what it is called.

These days, with electronic documentation system, like the e-Doc Plus 3.2 system that I sell, has so many ways to index and search for documents that finding any document you are looking for takes 2 seconds. So the level really does not matter any longer. Paper-based systems, that are rarely used these days, I can see where the category that the documents are in could matter. But who has the time and money to be using a paper-based document control system these days?

Bill Goss