[I wrote the following comments in response to a blog that was advocating starting off by modeling the "as is" processes in the business as the starting point for business improvement.]
One of the major errors taken in business analysis and modeling is that of modeling the “As Is”, then the “To Be” and then trying to plot a trail from the one to the other. This approach is hugely wasteful of time, money and peoples’ goodwill. Most modeling projects run in this way take so long to deliver results that they fail.
If the business is not currently doing what it ought to be doing in the way that it ought to be doing it, then modeling it is about as useful as modeling what it was doing last week, last month or last year.
And what have you got at the end? A detailed model of what the business OUGHT NOT doing!
All good business analysis starts by modeling WHAT the business OUGHT to be doing. This is the only model that is of any value.
Sadly, many analysts actually believe that this cannot be done. When they make this statement they are actually saying “Nobody in this business knows what they ought to be doing”! If this is the case the business may as well shut up shop.
Good analysts find the key senior executives in the business – going to director level if necessary – who know what ought to be done, interview them and the then build a series or really powerful models that can take the business to where it ought to be – at an accelerated pace.
The next major error the analysts make is by starting out modeling business processes as opposed to business functions. But that is a whole other story.
Business analysis and modeling is a very powerful tool that can bring real business benefits when it is done corectly. Sadly, too many analysts and consultants squander this opportunity by starting in the wrong place and modeling the wrong thing.
[I then got this reply from Jonathan Babcock at http://practicalanalyst.com. My responses are shown in blue italics]
John, You make some good points. I found your comment on the usefulness (or lack thereof) of current state modeling particularly interesting. I’m might have to chew on that one for a bit, though.
I certainly see where it would be preferable to save time and effort and only do desired/optimized or “ought to be doing” state. At the same time, I think having the current model for context in defining/explaining the business problem can be useful.
The current problem is always that the business/system is doing something other than what it ought to be doing. Understanding this problem is essential, but this can be achieved without modeling all that the business is doing wrong in detail.
The most powerful question to ask is, “What ought you (or the system) be doing?”
Maybe it’s not that the business is doing what they ought not to as much as there may not be a clear understanding across stakeholders from different business units/departments/etc (you know, “silos”) of exactly how they’re going about it.
It is true that there is misunderstanding across the ‘silos’. Clarity can be brought about by modelling what ought to be done and asking “is this what you are doing?”. If the answer is “yes” then no problem, if “no”, then they know what they ought be doing.
I’ve found that doing the side by side comparison of current vs. desired state can be helpful in illustrating the benefits of the desired state to business stakeholders as contrasted with the waste and other faults in the current state.
Modeling the “ought” state on its own actually makes it very clear to stakeholders what the benefits of the project / system will be.
In my mind, though, the current state model is just another tool available for helping define the problem. When it doesn’t add any value, I’m all for dropping it.
I would be interested in hearing your thoughts on modeling business functions vs. processes, too. I’ll check out your site and see what you have there.
I have not come across a case where modelling the existing state has added any real value. It makes analysts feel comfortable because they believe that this is where they should start.
In the Integrated Modeling Method I have shifted this paradigm completely and defined the starting point always to be “what” the business “ought” to be doing.
This forces me to find people in the business who can answer this question and stops me wasting time modeling something else. This has resulted in greatly increased productivity and accelerated solutions.
Process modeling is a secondary modeling technique. The two primary business modeling techniques are Function Modeling and Data Structure Modeling.
The core activities of any business are Business Functions. These are the discrete, coherent activities that a business must perform in order to meet its objectives and remain in business.
When you need to know the order in which Functions need to be carried out then you use Process Modeling. Every step in a Process is a Function. So, know the Functions first.
The other great error perpetrated in Process Modeling is decomposing Processes. This results in generating up to 300% more models that are necessary and introduces inherent logic errors.
I have expanded on all of this in a series of eBooks I have written, which are available at: Business Systems Analysis eBooks