Sure, the work involved in managing a process (or your fantasy football team) is facilitated by the use of a tool, but the tool is not, in itself, the answer to the problem.
The Process isn't the System
Tools help to focus your efforts in the places they need to go. With the appropriate tool you will be lead down a particular path to an end result. If the tool is a good one, well thought out and tested, it will take you down a good path. If it isn't it will take you down a bad path.
Tools help to increase efficiency of management of the process. Sure you can manage your fantasy team with a paper and pencil. Your end result will probably not be radically different. You can also manage your processes with paper and pencil (or Post-It Notes (C) and brown paper) and the end result will work probably just as well as if you had used a top of the range BPA or BPM system. But using the right tool will always pay dividends.
And here's where we start to hit the problem. I have said many time before on this site that "If all you have is a hammer, every problem is a nail". What that means is that the method you will use to find a solution will be dictated by the tools you have at your disposal. If you just have a simple piece of paper and pencil to document your processes you are going to be defined and managed in a different way than if you were running, for example, Metastorm's ProVision or Casewise's Corporate Modeler Suite.
The System isn't the Process
The other side of tools and processes is the trap that people fall into when they equate the tool that supports the solution with being the process itself. I've been in any number of process facilitation sessions where I have asked the question "How does your process work" and the participants have spent time telling me all the things that they do on a daily basis, most of which consist of "We add this to the system", or "The system flags that". The problem with this method is that they are defining their process according to the process mandated by the solution they have chosen to support it. This is akin to planning your vacation according to where the airlines fly rather than where you actually want to go.
The other problem with this approach is that if you then have to change your supporting system and replace it with a new one there is always the possibility that you will have to redefine your process according to the way the new system works. obviously this is not ideal.
When defining processes I always ask ‘If you didn’t have a system, what would your process be?’ I find that this question by itself will open up a large amount of discussion and really get to the meat of a particular process problem. Whenever I hear the words 'We put this into the system' I then stop and repeat my question: ‘If you didn’t have a system, what would your process be?’. This is a very useful question for focusing the mind in what the process step should be rather than what the 'solution' to support that step is.
Tools are incredibly useful things for process management but there are two pitfalls to be wary of:
1) Requiring tools to be present to do any work. It is always easier to have the right tool in any job, but beware of only doing the job with any given tool or toolset
2) The tool itself is not the process. If you are supporting your business with an ERP or CRM system ensure you know and understand your process and how it works without the tool. This is crucial for ensuring you own and run the process rather than letting the tool mandate it.
Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you.
Click this link and follow the instructions to get this book.
All information is Copyright (C) G Comerford
See related info below