Interesting Discussion Procedure vs. Work Instruction (WI) - What is the difference?

[John Broomfield]

Even DISCOVERING all the processes a company has demands a lot of time and effort. Even at medium granularity, a medium company can have over one hundred different processes. Discovering all of them, setting boundaries where one process ends and another starts, is a job for a Process Department (which may later map the processes that NEED to be mapped, based on ROI and Organizational Strategies) and analyze the processes and suggest improvements.

To want to map all processes in a company just for the sake of ISO is madness. For ISO, use very coarse granularity, resulting in macroprocesses and just call those "processes" and give them a documented procedure.

Roger,

Indeed, mapping all the processes in the system would be madness. Risk-based thinking prevails instead.

Top management, with due regard for their organization’s mission, determines the key processes (at 10,000ft) in the core process that converts the needs of customers into cash in the bank.

As a result of this they usually have:

1. An end to end core process flowchart showing the interactions between its customers and suppliers.
2. A list of key processes extracted from the core process.
3. The unique identity of each key process and the name of the best person to be its owner.

Each organization has at least one core process (or value stream) and the core process is sustained and improved by other key processes in the system. These may be called support processes and each of them is uniquely identified and assigned to a process owner.

The key processes (core and support) are captured/designed in deployment flowcharts (showing interactions at the job title level). These become the documented procedures and may link to existing method statements or instructions. Process Owners avoid getting into the weeds by recognizing that most if not all processes include more than one department or function and comprise many tasks; non-value adding tasks struggle to be included.

All they are doing is capturing a model of the way the system actually works (as it is). When compared with a standard a few controls or tasks may be missing from existing processes and even fewer processes may be missing from the system. By carefully designing, training and nurturing these new controls, tasks and processes the system can then improve itself; remembering, of course, that a process means work usually by a team of humans.

Again, with risk-based thinking we use the system to prioritize and bring about the necessary improvements.

In my experience it is better to listen and to help the system to improve itself than to re-engineer it.

John

PS: Project-driven organizations to some extent reinvent parts of their core process for each new project so construction companies, for example, may maintain a library of method statements which are used and further developed by the estimating team when costing for new bids and proposals.

Their corporate management system would show what is done and by whom. The management system describing how may be unnecessary for a competent team; again RBT prevails.

 

[AndyN]

This old myth of procedures being "What, When & Who" and work instructions is "How" is so bogus it's not true. People have been living that lie since the standard came out. Even the earliest version of ISO 9001 didn't specify WIs for all procedures. And there are supposed to be procedures which don't tell you "How" in another document, instead of IN the content? That's totally bogus. Whomever dreamed that one up has probably got a lot of bridges for sale!

 

[Sidney Vianna]

This old myth of procedures being "What, When & Who" and work instructions is "How" is so bogus it's not true. People have been living that lie since the standard came out. Even the earliest version of ISO 9001 didn't specify WIs for all procedures. And there are supposed to be procedures which don't tell you "How" in another document, instead of IN the content? That's totally bogus. Whomever dreamed that one up has probably got a lot of bridges for sale!

Amen. As long as people keep over emphasizing documentation, as long as people fail to let go of archaic paradigms as documentation pyramids, as long as people protect their obsolete document control departments, as long as people don’t understand the difference between documented systems and system of documents, this type of doubt (work instruction vs. procedure) will live on. And we’ll be distracted from the real issue which is process control and efficiency.

 

[MeThatGuyHimWhoisMe]

Work Instructions are simply Sub Procedures. You would include them for TASK SPECIFIC, step by step instructions. For example, you may have a general Procedure for shipping, which would include a step like "Prepare the order for shipment based on the method of shipping." You would then have specific work instructions for each method of shipping. For Example: Shipping by UPS, Shipping by FedEx, Shipping by Air, International Shipments, etc...Each method of shipping may have so many different steps from the others that a separate, task specific instruction is advisable.

 

[rogerpenna]

I don't personally care what they're called - but because some do - I always say:

Procedures - tell you who does what when.

Work Instructions - tell you how to do something.

Consider a Risk Management Process.

The procedure would say
Risk Registering - Process Owner - When discovered
Risk Acceptance - Quality Manager - after Risk is registered
Risk Analysis - Process Owner - after Risk is accepted
- Risk Analyss (Cause Analysis)
- Risk Analyss (Source Analysis)
- Risk Analyss (Probability)
-Risk Analysis (Impact)

etc, etc.
Notice I didn´t say HOW to analyze impact, probability, how to analyze cause, etc. Those are instructions that would need an explaining of the kind of risks, diffrent impacts depending of the type of risk, what probability means in different scenarios.

Is the HOW in that case part of a Work Instruction????
In my company we always saw these "HOW", at least in these types of processes, as quite high end, concepts that need to be explained, and thus not part of Work Instructions, while the Work Site instructions to Foremen and Asphalt workers, steps and how to build a road base layer, etc, as Work Instructions.

 

[rogerpenna]

Work Instructions are simply Sub Procedures. You would include them for TASK SPECIFIC, step by step instructions. For example, you may have a general Procedure for shipping, which would include a step like "Prepare the order for shipment based on the method of shipping." You would then have specific work instructions for each method of shipping. For Example: Shipping by UPS, Shipping by FedEx, Shipping by Air, International Shipments, etc...Each method of shipping may have so many different steps from the others that a separate, task specific instruction is advisable.

We have decided that our Processes will be documents that are more detailed in text, detailing more complex tasks
Our Work Instructions will be documents with much more images and maybe even videos. Maybe even Powerpoints with a printable version,. The objective will be to use them for training, including employees with low cognitive skills or low education level (here in Brazil, while it's hard to find real analphabets in my state, PRACTICAL analphabets are much more common... they may read a word, but make sense of a paragraph is something else entirely)

 

[Cari Spears]

I'm not sure what your point is.

Consider a Risk Management Process.

The procedure would say
Risk Registering - Process Owner - When discovered
Risk Acceptance - Quality Manager - after Risk is registered
Risk Analysis - Process Owner - after Risk is accepted
- Risk Analyss (Cause Analysis)
- Risk Analyss (Source Analysis)
- Risk Analyss (Probability)
-Risk Analysis (Impact)

etc, etc.
Notice I didn´t say HOW to analyze impact, probability, how to analyze cause, etc. Those are instructions that would need an explaining of the kind of risks, diffrent impacts depending of the type of risk, what probability means in different scenarios.

Is the HOW in that case part of a Work Instruction????
In my company we always saw these "HOW", at least in these types of processes, as quite high end, concepts that need to be explained, and thus not part of Work Instructions, while the Work Site instructions to Foremen and Asphalt workers, steps and how to build a road base layer, etc, as Work Instructions.

We don't have a risk management process. Risk management is part of every process.

 

[rogerpenna]

I'm not sure what your point is.


We don't have a risk management process. Risk management is part of every process.

If Risk Management is part of every process, it is ANOTHER PROCESS that is being used an a subprocess. You can model it. It would be an activity with a PLUS sign below it indicating it's a subprocess.
In theory, it would be a subprocess of a PDCA.
And PDCAs are NOT part of every process. They INCLUDE every process. The way you map or model processes is not correct, imho. You are probably using ISO's definition of processes, which are quite wrong imho and according to BPM standards.

Even if risk management is part of every process, HOW do you consider probability, impact of risks, etc. Is it a free for all?
And why nitpick at an EXAMPLE?

I am not sure what your point is either because I am not sure if you are being literal and think I am talking ONLY about Risk Management or if you understood the Risk Management example was just an example.
Anyway, reading the topic, soon after you posted that SOPs are about what and when, and WI were about HOW, I noticed that some other people, including other moderators, etc, disagreed with that and had a vision that was more similar to mine that prompted me to post that reply.

 

[Bev D]

OK. No need to be adversarial in this OLD thread. If anything this thread shows that there are many different valid interpretations of these two words. As long as it works for your organization it’s correct.

If there is a new take that anyone would like to share then start a new thread. Newer members don’t need to scroll through 9 pages

 

[Randy]

Process, procedure, work instruction, fiddley dee and horse fritters, getting wrapped around the axle while one's "T" is in the wringer over semantics that amount to nothing, won't effect climate change and doesn't put any more taters on your dinner plate. In the real world it all amounts to less value addedness than what my dog leaves in the yard.

This is the whole "schmear" of all those dribble words & phrases in one package (pun intended)