Modeling the “As Is” then “To Be” is a waste of time
[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
If you enjoyed this post, make sure you subscribe to my RSS feed!
James
Your assertion that “if you want to know where you want to go, unless you know where you are, how can you know where you want to go?” is one of the greatest traps into which business analysts fall. Once you know where the business ought to be do not bother modelling the hell ought of where it currently is - it is of absolutely no value (unless you are a consultancy that gets paid for drawing models).
Go straight to where you ought to be. How to get there is achieved by mapping a route to the destination not by mapping the origin.
If I am in London when I should be in Paris, mapping the hell out of London will not not get me any closer to Paris. All I need to know is the route to the station or the airport.
Mr. Owens:
I know you were talking about a specific scenario where you felt that the corporations were wasting time and money. This would well fit for the re-engineering effort. You would benefit simply by focusing on the “what OUGHT to be done”. I am taking the stand where, if you want to know where you want to go, unless you know where you are, how can you know where you want to go?
Understanding where you are today will provide very good insight on where you want to go in the future. That is all I am saying. Modeling is a means of understand the reality through abstraction. All we are trying to do is get to the “End” using the best possible “means”. I really enjoyed blogging with you!
Hi James
You are missing the overall point made in the title of this post. I am NOT saying that the current processes and systems in an organisation should not be documented - quite the reverse. All good businesses will have all of their functions, systems, data structures and processes fully documented and updated on a regular basis. The title of the post is “Modelling the ‘As-Is’ then the ‘To-Be’ is a waste of time”. I have seen this proven time-and-time-again around the UK and Europe.
If your existing processes and systems are not doing what is required of them and need to be changed then deciding to document the hell out of them prior to changing them is an insane waste of time and money!
Too many (misguided) analysts also make the hugely costly mistake of thinking that they can infer what is required by the business by analysing in details what the business is currently doing - even though what is been done is not what is required!! Surely a form of insanity? If you want to know what the business OUGHT to be doing then you must ask senior business executives and then put this in place with middle management.
It is time for business analysts to around the world to stop these self indulgent practices that bring no real benefit to any business. They only ensure ongoing work for analysts and bring business analysis into disrepute.
Hi James
I am glad that you chose the example of remodelling a house as it proves my point very effectively.
Why would I be remodelling my house? Because is not meeting my requirements. It is not doing what it ought to be doing. What are my requirements? How do I define these? By looking in detail at every aspect of my existing house? Very definitely not. It is this crazy circular logic that wastes so much time in process and business improvement around the world.
Your assertion that my argument that Function and Process modelling must be based on what the business OUGHT to be doing “is just an argument and definitely not aligned with any type of engineering principles” is quite wrong. All successful engineering projects will ALWAYS start by establishing what it is that the new structure is intended to achieve or what it “OUGHT” to be doing. Any engineering project starting with any other driver will fail to achieve what is meant to be achieved. Maintenance engineering projects are different in that they are stuck with what is in place and all that they can hope to so is maintain that structure and prevent it from failing.
For people stuck in businesses that are not interested in knowing what is it that they ought to be doing and are only interested in preventing themselves from failing, the the “as-is” model, with all of it shortcomings, must seem like the “Holy Grail”.
For dynamic, successful businesses the “OUGHT TO” model is the only viable option.
Mr. Owns:
I must say, I COMPLETELY disagree with you regarding what you said about modeling the “as-is” processes of your business. Let me ask you a direct question, if you are remodeling your house, where do you start first? Logically, you will look for the blueprint of your house to begin with. Why do you do this? Because, you want to understnad the “as-is” of the house plan. You want to look at it to understand the impact on the “as-is” to the “change” you are about to bring to your existing house. Similarly, if you do not have a model of your existing business process, what is the reason behind saying “The business OUGHT to be functioning as they are SUPPOSED TO”!! This type of argument is just an argument and definitely not aligned with any type of engineering principles. On the other hand, I understand that when you do not have any process at all, you should be modeling how the process “ought” to be working. When it comes to making any “changes”, you simply cannot avoid looking at the “as-is” models. To do that, one has to develop the “as-is” model to analyze the process.
Lastly, when you want to understand how your business processes are performing and you want to take measurements, you need model the “as-is”. If you cant model it, you cant measure it!!