Focus on Removing Waste not Cost

This is a repost of an article I did last year, it is being reposted a) because it is highly topical right now and b) because some nice person hacked it on the blog!

====

So at last, governments around the world have woken up to what businesses have known for a long time—we are in a downturn, which seems set to turn into a recession. So with everyone scurrying around looking for ways to minimize the effects and hoping that it won't turn out to be as bad as that of the late 80's / early 90's, what can we do to help?

Well, it is pretty certain that many organizations will look to Business Process Management (BPM) as a way of reducing costs and trying to manage their way out of the situation, and for some this may well be the correct approach. The challenge will be how well they manage the use of BPM; will they go with a sledgehammer to crack a nut, or will they look at the wider possibilities and allow themselves to position for success.

It will be fascinating to see whether we go for the history repeating approach or learn the lessons from the past. Those with long memories will remember that Business Process Reengineering (BPR) was seen as a way and used as a tool to help businesses out of the earlier recession, then as business picked up people said that BPR did not work and was too blue sky. The lesson, of course, is that everyone was focused on removing cost as opposed to removing waste; it is the removal of waste that will serve us when the upturn in the market starts.

Pretty well for the last 15 years or so we have seen steady growth in the economy overall and revenues and profits have grown with it, primarily as a function of scale and market sector growth, especially in newer sectors. Inevitably this means that businesses have not needed to be as efficient as they might otherwise be. Of course many would argue that they have been on top of efficiency or that they have always managed costs—well, I am sorry but this has not been my experience.

Now though, there is a need to chase efficiency and, whilst true to form, many will simply ask their purchasing people to squeeze their suppliers. I contend that this is a lazy approach and is management acting without managing. Simply taking costs out of a business across the board has never been seen as a successful long term survival strategy in the past and there is no reason to believe it will be the right strategy for the future.

Instead, managers should focus on getting a better handle on their cross functional or business processes and allowing their own staff to identify waste or non-value adding activities that can and should be eliminated. By removing waste as opposed to cost will mean that the company is not being damaged in any way and will, in fact, be in a better position to serve its customers in the market upturn. Some smart organizations may well realize that if they do this well, they may actually be able to go to their clients and offer cost reductions without being asked, thus forging stronger relationships and, potentially, even increasing the share of their customers business that they get. Now, wouldn't that be neat; remove waste, leading to lower costs which leads to higher revenues, seems like a win-win to me.

To benefit from waste or non-value add removal it is a simple matter of process analysis and redesign. I say a simple matter, because it does not require teams of analysts to be set running around taking months to report back before coming up with a redesign that is based purely on reduction or deduction. Instead it requires a few good coaches or facilitators to help people identify what they are doing now and get them thinking inductively about how they can make improvements. The caveat, as ever, is that managers need to focus on empowering and leading rather than controlling and managing.

The outputs from such exercises can literally save some companies millions for only a few days efforts. They also serve to provide IT people with a much better brief on what might be expected from, or required of, some kind of process automation. This in turn means cheaper system implementation costs, lower resistance to change and greater value from the IT part of the project.

Now, if we move forward and deliver on this vision people are certain to look make this time and say that BPM helped them deal with the issues and was indeed practical and results focused. In summary, we learned from the lessons of the past, focused on waste and helped to ensure the survivability of our organizations and ultimately our jobs!

Procedure vs. Process

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 <legal procedure> <a surgical procedure>

(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 seeing 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 very 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 fills 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.