Millions of hours and hundred of millions of dollars are spent around the world each year by businesses of all sizes doing Business Process Modeling.
Why?
The senior executives involved in signing off the huge budgets for these projects would tell you of the wonderful benefits they will bring to their enterprises.
But Do They?
How many businesses are better off after these projects than they were before? The answer, very sadly is, very, very few!
But why not?
Sadly, most of these modeling projects make such fundamental errors that they are guaranteed to fail. Yet all of these errors are all completely avoidable. Any reasonably competent analyst following the basic rules for Business Modeling could avoid them! The crazy thing is that even the most "experienced" analysts in these projects GET THE BASICS WRONG!
The Five Cardinal Errors
The five most common errors made by business analysts are:
1. Incorrect or no basic definitions
2. Starting in the wrong place
3. Decomposing business processes
4. Modeling the wrong thing
5. Using grandiose names for flawed techniques
One of these errors would be bad enough but once you get Item 1 wrong you are going to get the rest wrong as well - a recipe for a very expensive failure!
But there is hope. There are some good analysts out there and they do an excellent job. Unfortunately, the means by which they achieve their good results is all locked away in their heads. Unless an analyst eager to learn their methods were to follow them around for three to six months, there would be no way of learning these methods. But there is one exception.
John Owens, a business modeling specialist with over twenty years international experience and learning has written down the very best techniques and given birth to the Integrated Modeling Method (IMM). Following IMM will enable all analysts to avoid the Five BPM Cardinal Errors and achieve extreme success in Business Modeling.
Lets take a closer look at the Five Cardinal Errors.
Cardinal Error 1: No Basic Definitions
Ask any three business analysts "what is a Business Process?". The immediate response that you will get is a loud guffaw and be told not to be so stupid, because "Everybody knows what a Business Process is!" But if you press them for a definition you will get at least four different answers and probably NONE of them will be right.
Hard to believe, but it is true. The reason for this is probably because analysis started off in the world of computing where jargon was, and still is, king. Nearly everybody in that world believes that they know exactly what each piece of jargon means and what they understand it to mean is exactly what everybody else understands - WRONG!
If they ever have a doubt about their understanding, they will never ask. That would be admitting that they do not know and would risk the ridicule of their peers! So they bluff it out year after year, increasing their time in the business but not their learning.
So lets turn the tide and give some basic but essential definitions that anyone doing Business Systems Analysis or Business Process Modeling needs to be able to give by heart.
Business Function: WHAT a business must do, disregarding HOW and WHO.
Mechanism: HOW and WHO does the WHAT of the Business Function.
Business Process: The order in which Business Functions need to be carried out.
Business Procedure: HOW and WHO does the WHAT in a Business Process.
Full definitions for all of these terms can be found at Integrated Modeling Method
Solution 1: Learn the basic definitions.
Cardinal Error 2: Starting in the Wrong Place
When analysts do not have the definitions for the basic elements for Business Modeling they inevitably start in the wrong place. Once you know that a Process is a definition of the order in which Business Functions need to be carried out, you then know that, before you can model Business Processes you need to have modeled the functions. Simple, but a step missed out by probably 70% of Process Modeling projects.
Solution 2: Start in the right place and model the Business Functions.
Cardinal Error 3: Decomposing Processes
When analysts start in the wrong place and miss out modeling the Business Functions, they then fall into the next trap and model high level Processes, which they then have to decompose to get them to some usable level of detail.
Decomposing processes is a practice to be AVOIDED AT ALL COSTS because 1) it generates up to 300% more diagrams than are necessary and 2) it is an inherently flawed technique when it comes to precedence logic. When you start with the Business Functions, you can do all decomposition in the Function Hierarchy and only draw processes for the Elementary Business Functions, resulting in far fewer diagrams, lots of time and money saved, no logic errors.
Solution 3: Decompose Functions not Processes.
Cardinal Error 4: Modeling the Wrong Thing
For analysts committing Cardinal Error 1, the errors get compounded. Because they cannot tell a Function from a Process, they also cannot tell a Function from a Mechanism. So they start modeling Processes - wrong in itself - they then compound their error by modeling Mechanisms (the HOW and the WHO) as steps in what they think is a Process and end up, without knowing it, modeling Procedure.
If you do not believe my do a search on the Internet for Process Modeling software and 70%, or more, of what you find will be Procedure Modeling software!
Solution 4: Again, learn the basic definitions!
Cardinal Error 5: Using Grandiose Names
Are Process Modeling projects going wrong because analysts are doing the wrong thing? They would say no! They would have you believe that it is because the whole subject is so complicated. But they have developed a magical method or tool (which will have some esoteric name), that is still more complicated, that will solve all of the problems - but it will cost more and will take longer!
No grandiose name can make an inherently flawed approach useable.
Solution 5: If it cannot be explained in plain english, it will not work!
Summary
- Most Process Modeling and BPM projects fail.
- The reason is that most analysts do not know the basics.
- Complex methods and esoteric names are no solution.
- The solution lies in bringing to the projects the power of simplicity and elegance. All analysis flourishes, and always has, when endowed with simplicity and elegance.