Processes, Procedures, Work Instructions – what’s the difference anyway?

This post was originally published on the Idatix Insider’s Blog.

 

It’s often all too easy to bundle “processes and procedures” into one statement as if they are a single entity. Of course, they aren’t, but ask a dozen people what the difference is and you are likely to get a dozen different answers. Throw in the oft misunderstood “work instructions” and chaos can ensue!

When working to improve business processes and procedures it’s critically important to define what each is prior to embarking on the improvement initiative. This sets a clear understanding for the business in terms of what work will be performed.

The easiest way to think about processes and procedures is in the level of detail of the information. Processes can be described as being at a “high level” and operate across the organization’s varying functions, whereas procedures sit at a “low level” i.e. they contain detailed information. Both are, of course, intrinsically linked. The procedural level can be thought of as a detailed breakdown of a step in the process.

Processes vs Procedures

…and Work Instructions

So what are the key difference between processes, procedures and work instructions?

Processes are cross-functional and define what is done and by whom. They are often depicted in diagrammatical form such as a decision tree or flowchart where the work performed is split into logical interrelated steps or “activities”. Processes should always have a “trigger” or start event and a “terminator” or end event that achieves a specific result. All processes should seek to fulfill a successful customer outcome.

Procedures define how the work is performed. They are typically documented in a step by step order with detailed descriptions of how the work is to be performed and who is responsible for performing the work.

Work instructions add a level of confusion to the puzzle, but are generally recognized as a sub set of procedures. The way they differ is that the work instruction is typically written to describe how to do something specifically for a single role, rather than procedures that may contain instructions for several different roles within an organization.

How to Use

The next question then relates to how each of these should be used.

The answer is simple: together.

Processes are an excellent means of quickly displaying the entire process in an easy to understand format, but on they are too high level for staff to use to perform their day-to-day work. This is where procedural detail is required.

The solution to this problem is to always pair process diagrams and procedural detail together, clearly showing the step (or steps) in the process that the procedure refers to.

This way staff can see the greater context and implications of the cross functional process whilst having the level of detail required to be able to successfully complete their own tasks. Work instructions can also be used in this manner but caution should be exercised as single role based work instructions can lead an insular view of the work being performed. Well-written procedural detail can often eliminate the need for documenting work instructions.

Processes, procedures and work instructions are all part of the business eco-system, and just like life on earth, they work best when we work to manage all of them together in perfect harmony.

Cheers,

TPN

 

Courtesy to Craig Reid. This blog is also available on The Process Ninja.

 

pixelstats trackingpixel

By Craig Reid @ The Process Ninja | June 7, 2012

2 Responses to Processes, Procedures, Work Instructions – what’s the difference anyway?

  1. We have made a detailed analysis of these termes and developed a crisp glossary, see

    http://wiki.ubpml.org/index.php?title=UBPML_Prozessbegriffe&setlang=en

    on the UBPML site you also find a process map, which relates all those terms graphically
    (using UBPML notation itself, which, mostly, in this case, consists of UML classes)

    http://wiki.ubpml.org/images/5/5d/ubpmlprocess.pdf

    To a large degree, the observed “detail hierarchy” of process/procedure/work instruction in your article is true and a natural consequence of the fact that processes are made of activity instances which in turn are detailed by procedures.

    Nevertheless, in some cases the execution of a step in a procedure might in turn “start a new subprocess”, so the hierarchy is not absolute. Sometimes, this leads to confusion since people cannot decide on which detail level a certain issue belongs. In such cases, the finer distinction between the terms as given in the glossary may help.

  2. Pingback: Back to Basics Definitions « Back Office Mechanics

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>