Warning: Creating default object from empty value in /home/johnnz/public_html/wp-content/themes/simplicity/functions/admin-hooks.php on line 160

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


15 Responses to “Modeling the "As Is" then "To Be" is a waste of time”

  1. M Lippe March 26, 2012 10:22 am #

    The neglect of the “as is” aspect of the process appears to have a place in certain areas. However, I would question the use of a well informed member of the executive as a source of valid information. In a large corporation the perception of “as is ” may be vastly different to the reality. Establishing the “as is” via a robust, evidence and data based approach in this scenario is essential. I have found that, quite often, data can throw up a few surprises in the operational aspect of an “as is” model. A bottom up approach is often the best way to establish how the company is actually functioning.

    Businesses are as different as people. A single approach to all business types seems unintelligent.

    Toyota had great success utilising “Systems thinking”, which relies heavily on “as is” as well as “ought to be”

    • John Owens March 26, 2012 10:47 pm #

      Hi Martin

      Thank you for your comment. As you say, businesses are as different as people. However, the ways a person gets healthy and stays healthy are common across millions of people.

      An unhealthy person who continues to do what he or she is doing now is going to remain unhealthy. Tuning their processes so that they can watch more television of eat more food is not going to make them healthier, quite the reverse. Before these people can get healthy they need to know WHAT it is that they OUGHT to be doing. Until then they are doomed to failure.

      So it is with businesses. If they simply tune what they are currently then, far from improving, they might well be getting more and more unhealthy. Before they can improve someone must define exactly WHAT they OUGHT to be doing. The only people in an enterprise who can define this are the senior executives. If an enterprise is run by senior executives that cannot do this, then it is doomed. No amount of bottom-up tuning can save it.

      I am glad that you mentioned Toyota. This is a perfect example of an enterprise where the senior executives have defined exactly WHAT it OUGHT to be doing. They continue to redefine this and ensure that that is what is done in the enterprise day-to-day. Every day they carry out their ‘To Be’ – as all really successful enterprises do!


  2. Amela February 8, 2012 12:34 pm #

    Dear Mr. Owens,

    I work in the filed of Business process mgmt for a few years, and would have practical question related to as is process modelling and KPI.

    We, as BPM’s are supposed to show to our mgmt effects of the business process improvement. So, we have to define KPI for this new/revised/remodelled process (if TO BE process will bring us some savings in: FTEs, costs, time…).
    That brings us that we have to have all indicators for as is process, and to compare it with to be process…am I right?
    The question is how we can define KPI’s if we do not have as is model /its indicators produced. Do you have any practical suggestion on how to avoid too much time on as is modelling for the KPI purposes?
    Thank you in advance,

    • John Owens February 8, 2012 11:26 pm #

      Hello Amela

      The KPIs for the current ‘As Is’ business are already known. You do not have to build an ‘As Is’ model to find them out, they are what is happening in the business as it is today.

      The question is, “Is the business currently doing what is is supposed to be doing?” You cannot answer this question with Process Models. If you have not built the Business Function Model, then you cannot answer the question at all.

      The Function Model is a definition of WHAT it is that the business OUGHT to be doing.

      From this model you can straight away build ‘To Be’ Process Models, define their KPIs and compare them to the KPIs in the business as it is today. Thus showing the improvement to be had over the ‘As Is’.

      Even if the ‘To Be’ KPIs do not show a big improvement re FTEs, etc, the business will be much better off as it will now be doing what it OUGHT to be doing.

      The Function Model is essential, as you cannot derive ‘To Be’ processes from the ‘As Is’. I explain why in ‘Tuning Processes is a Waste of Time’

      I hope that this helps.

      Kind Regards

  3. Lokesh December 20, 2010 4:32 am #

    Dear John Sir,

    Can you please explain me how can you undertake a revamping of systems and technology when you are trapped in utter choas. What approach would you take? How much emphasis would you put on “as-is” and “to-be” modelling to enable decision amongst stakeholders?

    Any special thoughts and insights on Business Analytics in dynamic market like Middle East?

    • John Owens December 29, 2010 12:12 pm #


      The first step in taking an enterprise out of utter chaos is to get the most senior executives to define what it is the the enterprise OUGHT to be doing and model this. The only model that can show this, without duplication and redundancy, is the Function Model. So this is the cornerstone of ALL effective business modelling.

      Modelling the “as Is” processes or procedures is a COMPLETE WASTE OF TIME!! To find out more about this read http://www.johnowensblog.com/imm-approach/as-is-to-be-business-systems-modeling and http://www.johnowensblog.com/imm-approach/tuning-processes-is-a-waste-of-time

      Once you have built the Function Model you will then be able to proceed and build the data model and any necessary process models.

      To answer you questions in more detail I will need to talk to you and so will ring you.


  4. DaveLeslie November 30, 2010 3:20 pm #

    The fact you don’t like as-is documentation is pretty common among the new breed of analysts. Unfortunately, it is way off track, and it is something that is pushed by vendors not wanting evidence their solution has not delivered any real benefits. The as-is forms the basis of the future state, it is the baseline from which any benefits or dis-benefits will be determined. It is also useful considering the huge volume of projects that fail to gather requirements correctly and fail to ensure controls are in place, where the future state has failed, and general traceability.

    • John Owens November 30, 2010 5:26 pm #

      Hi Dave

      With 30+ years in IT and Business & Data Modelling, I don’t think that I can be classified as a “new breed of analyst”.

      The reason I am against modelling the “as is” business processes (and remember, I am only talking about business processes) immediately before they are going to be changed to something else is because it is a huge waste of time, money and the energies of all of the people involved.

      Further, this expenditure of time and money leaves the business exactly where it was. It adds no value whatsoever. Quite the contrary, because it consumes so much time and goodwill, it often leaves the business worse off.

      Then, to add insult to injury, we ask the business to go through the same effort all over again in order to model what the business “ought” to be doing!!

      “Gathering requirements” by definition prohibits simply modelling what is currently done. It is not about “what have we?” it is all about “what do we require?”

      I can understand your scepticism regarding vendors products failing to deliver what they promise. However, there are far simpler, less expensive and more user friendly ways to achieve this.

      The simplest of these is to define a set of what I call Key Improvement Indicators (KIIs). The business should know what its current KPIs are. It should also be able to define the KPIs that need to be delivered in order to achieve a realistic return on Investment (ROI) for the project/system. It should then build the KIIs based on the KPIs into the contract as a condition of payment.

      Thanks for your comment.


  5. Sanja June 8, 2010 9:55 am #

    Hi! I’m from Croatia and I work in a bank. (my english is not that god so I apologize in advance) Few years ago we were in position to have consultants working with us – we were searching how to improve our processes (prepare ourselves for merging with another bank). These poor consultants were so lost with all of us there while modeling AS-IS processes (I don’t have to mention that we also had language barrier – imagine Austrian consultants working with Croatian bankers, discussing in (bad) English :-))
    Anyhow, we managed to create TO-BE processes and find all bad sides of current processes only thanks to this AS-IS models. Trick was in the details which were never documented before.
    Consultants don’t have a clear picture of all the details (of course) and bank managers (directors) they especially don’t have a clue about (bad) details. Officers (like me) do. So, while we were creating AS-IS model, I was fighting to point out all these small things which were wrongly defined long time ago (for “historic reasons”, as we like to say) in current processes and we together created some pretty big improvements. Key was that consultants had to find out what was wrong with our current processes, and they couldn’t see this if they didn’t make a picture of how things work now. (Funny thing is: if one officer, like my self, points out that something could be done more efficient – directors don’t take it seriously – but when consultant says completely the same thing, then for some reason director takes it into a consideration :-))
    For example: if I tell you that I want you to help me improve card transactions processing because currently it’s to slow – you’ll ask me some questions. I will tell you everything I know – and I’m sure you’ll start drawing a picture for your self, just to understand better my words. Well, that picture actually is “AS-IS” (but just in different shape).

    Just to conclude my opinion – if you have precise knowledge/data/information of everything that’s going on in the process (if everything is documented so you know who, why, how…) – then you really don’t need to create AS-IS, you can immediately see what can be TO-BE model. But, if you have complete chaos around you, and lots of all kinds of people who are contradicting to each other and you have to conclude something from what they are saying – making one official AS-IS model is the only thing that can help you do your job well.
    Maybe it’s easy to make TO-BE model, but it’s not always easy to understand people’s wishes.

    Greetings from Croatia,

    • John Owens June 8, 2010 3:22 pm #

      Thank you for your comment, Sanja

      Let me pick up on some of the more salient points.

      If everything you are doing is fully documented, telling you who, why, how, etc, then what you have is a fully documented AS-IS model and there is no need to build another one. What you now need, if it does not already exist, is a properly defined TO-BE model so that senior executives can be sure that what the enterprise is doing (the As-IS) is exactly what it should be doing (the TO-BE).

      If what you have around you is complete chaos then the thing you SHOULD NOT DO is document this chaos. If it is chaos then it is not what the enterprise OUGHT be doing and there is absolutely no value in documenting it, nor is there any way in which you can derive from this chaos what it OUGHT to be.

      What is needed is a definition of WHAT OUGHT to be done and take the enterprise straight there. ONLY senior executives can define WHAT OUGHT to be done as this is not just a systems decision but a commercial decision that can only be made at the highest level. The HOW and the WHO can be done at a lower level, only after the WHAT is defined and understood.

      I have covered this in more detail in my post at http://www.johnowensblog.com/imm-approach/tuning-processes-is-a-waste-of-time

      Your observations regarding the value that senior executives put on the opinions of consultants as opposed to those who completely understand the current HOW is quite right and can seem unfair. It arises for two main reasons:

      1) Senior executives feel that external consultants will bring a fresh and an unbiased view that those currently involved will not have. Also, if things go wrong, the executives can blame the consultants! If they take the opinions or views of junior management and things go wrong they will feel exposed.

      2) Those people who are deeply involved with the systems and the day-to-day business tend to believe that what they are doing is exactly what is needed. It might be running badly and need tuning but it is what the business requires. Sadly, they are very often quite wrong in this assumption as, over the years, the drift that has occurred in the business due to the absence of an OUGHT TO BE model can be enormous.

      It is obvious from your comments that you are passionate about what you do and see so many ways in which it could be improved. However, always remember that fundamental programming maxim: “Before you make sure that the code is right, make sure that it is the right code”.

      Understanding the Function Model and appreciating that it is the most powerful model that any business can have, will greatly assist you in avoiding tuning inappropriate processes and procedures.

      I hope that this helps.


  6. James June 18, 2009 4:48 am #

    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!

    • John Owens June 19, 2009 10:52 pm #


      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.

  7. James June 13, 2009 7:49 am #

    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!!

    • John Owens June 14, 2009 12:57 pm #

      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.

      • John Owens June 15, 2009 9:19 am #

        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.

Leave a Reply