In the course of undertaking the Mapping and Modelling survey a number of interesting areas of uncertainty or confusion became apparent. So I thought that maybe I would try and address one of them; the thorny issue of the difference between process and procedure. The issue has been hotly debated for many years, but to my mind became red hot at two points in time.

The first time was when the ISO9000:2000 standard for quality was published. This saw a shift away from companies simply documenting and following procedures, to needing to document and show plans for continually improving their processes. With apologies to those companies who did undertake the work required to make such changes, most in my experience simply undertook a global search and replace exercise and replaced the word procedure with the word process. Simply replacing one word with another, to my mind at least, meant confusing themselves, their staff and the rest of us in one fell stroke.

The second time was with the emergence of Business Process Management (BPM) Systems. The people in the software industry who told us that BPR was dead and that brown paper and post it notes would not cut it. The people who told us we needed to draw our models in tools so that we could push buttons to generate software applications. For many of these people process was a nasty thing with a lack of rigor. So they used, and continue to use, the word process, when actually what they are drawing or requiring are procedures. At risk of over generalizing, while business people can talk about process, IT people have to bring it to procedure. The reason being that if you want to execute something programmatically then you have to have it precisely defined, e.g. converted into a procedure. So perhaps BPMS should really stand for Business Procedure Management Systems. Indeed, my old friend John Pyke has frequently reminded people that for the most part BPMS still the same old work-flow systems that were created in the 80's dressed up as something different (we know that there are now some exceptions, but still the language is confusing).

In order to explain more fully my perspective I would first like to take a look at some dictionary definitions of the two words, they are defined in the Merriam-Webster dictionary as follows:

Process

1. progress, advance
2. something going on : proceeding
3. a natural phenomenon marked by gradual changes that lead toward a particular result
4. a continuing natural or biological activity or function
5. a series of actions or operations conducing to an end ; especially : a continuous operation or treatment especially in manufacture

Procedure

1. a particular way of accomplishing something or of acting
2. a series of steps followed in a regular definite order
3. a set of instructions for a computer that has a name by which it can be called into action
4. a traditional or established way of doing things

As can be seen from these definitions they are clearly not the same thing. Process may be seen to refer to a series of actions, but it does not place a particular order on those actions. Procedure on the other hand is very much focused on steps, order and instruction. When we take these two definitions we can see that while a process may contain order, it does not require order to be a process. If we take away the order from procedure then we don't have a procedure, but we may still have a process.

Personally I quite like the idea that Process is very much talking about "What we do" as opposed to Procedure talking about "How we do it". There are those who suggest that the what and how are actually synonyms, but in researching this article using sites like synonym.com and others I did not come up with any suggestion to support that suggestion.

So perhaps it is time to look at some examples of how the two may coexist but talk about different things. The first example I use is that of "Paying Phone Bill" (a process), you could list the actions you might need including the following: decide where to pay from, decide payment method, decide payment date—but these actions could be undertaken in any order as long as all were complete before you decided that the process was complete. Alternatively if we had our "Paying Phone Bill" (a procedure) we would have to take the following actions in order; log on to internet bank, select account to pay from, select payee, enter amount to transfer and then complete the transaction. These last tasks have to be undertaken in a specific order, either because a system dictates it or because to do it another way makes no sense. But we can certainly see in this case the process can be seen as a higher level of abstraction. We may even have two procedures "Paying Fixed Line" and "Paying Mobile Phone".

The second is another similar example, but this time illustrating it in a non-technical way. The example might be that of "Arranging a Party". Our process might include; Make a guest list, send out invites, Arrange for catering, Arrange for music, Wait for guests to arrive. Here we can see we need to send the invites after we have a guest list and that it is a good idea to have sent the invites and arranged food and entertainment before the guests arrive :-) but does it matter whether the invites are done before the catering, of the music before the invites? Not really, but our process still has all the actions (abbreviated here). So let's consider our procedure, or indeed just one of the procedures that might apply to this process, in this case the "Send Out Invites" here we find the following steps; Buy invitations, Write the invitations, Put it in an envelope, Address the envelope and then Post the envelope. With the exception of stuffing and addressing the envelope that could be switched, everything else has to have that definite order if we are to be successful.

My final example is a much larger one, but is real and taken from a well known manufacturer of sealable plastic containers—a world brand. The story was told to me many years ago, so it may not still be exactly true today, but I hope you will agree that it illustrates quite well the distinction between the two. The company in the story is known throughout the world for its sealable plastic containers and it is Tupperware. Wherever you go in the world most of the products they make are available to you. Yet, as you might imagine, depending on your country the demand for a particular type of container will vary immensely. However in order to maintain quality and their enviable reputation they always want to make sure that the same "Process" is used across the world for making their products. Now in Holland where demand is high for a container, this means ensuring that the right molding tool is loaded into a machine, that the machine is correctly fed the right type and quantity of plastic and obviously a hundred other things so as to enable a production run to take place. In order to do this they have a "Procedure" for carrying this out. Now switch to somewhere like a small country in South America, where the requirement is for only a handful of the same product and the "Procedure" does not work. Here they have person who will collect the mould from the store (not a machine mould but a hand mould), they mix the plastic to the right recipe and then fill the moulds by hand. Thus he executes the same Process but with a different Procedure. It may even be that within these two extremes the company may have many other "Procedures". The Procedures contain the tasks or work instructions with the order and detail as to how to perform them. The Process though is at a much higher level of granularity and is focused on the inputs, the outputs and any quality or control measures that are applicable. So as we have seen the same process can and should be undertaken differently according to the requirements.

To conclude, I still very much believe that we need to be more careful how we use the two terms. There are certainly benefits in reviewing and updating procedures to ensure that they constantly reflect how the work is actually taking place in an organization. But, in documenting and improving procedures, we are certainly not going to drive out the big wins that people are looking for from Business Process Management. Conversely, by understanding and improving processes better we can ensure that our processes are lean and effective, thus delivering on the business benefits.

From a systems perspective, I suggest as ever, that we should first examine the process, drive out waste and improve effectiveness. Having done this we can examine the activities left in the process, document the procedures and then consider whether and how to automate them. At risk of touching a another thorny issue (BPMN) then this idea to me sits well, after all a procedure contains nothing more than a set of tasks and in the order and detail to carry them out, the very same thing that appears to be supported by the BPMN symbol set and notation.

Copyright Mark McGregor 2007 : www.markmcgregor.com