//As-Is versus To-Be… what to model first

As-Is versus To-Be… what to model first

I have always taken the advice at face value: the "to be" model matters much more than the "as is" model does.  Implicit in that: spend as little time on the "as is" model as you can.  Perhaps, even, do the "to be" model first.

Of course, I wouldn’t be blogging this point if I didn’t run into that bit of advice today.  We are modeling the ‘as is’ process first.  And spending a good bit of time on it.  Why in the world would we do that?

Because, there’s a BPM benefit to modeling the ‘as is’ process, and sometime we have to earn that benefit before we can wander in the clouds of ‘what will come.’ 

Sometimes we have to be willing to write down what others have not wanted to write down: that the customer doesn’t experience a simple process… that our methods are not efficient or effective… that different people use overlapping words in confusing ways… that levels of abstraction create layers of confusion that can be impenetrable for "outsiders" to understand.

Once the complexities are pointed out, and sometimes only after they have, can we begin to get people focused on the future.

Sometimes, we have to take the time to consider where we are before we can begin to understand where we are going.

Technorati Tags: ,,
By |2008-05-07T00:06:18+00:00May 7th, 2008|Enterprise Architecture|9 Comments

About the Author:

President of Vanguard EA, an Enterprise Architecture consulting firm in Seattle focused on the Pacific coast of the US. Nick has over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

9 Comments

  1. Mike Burke May 7, 2008 at 3:18 am - Reply

    Well – to frame it more simply – how do you know how to get somewhere if you don’t know where you are?

    My opinion – focusing just on the ‘ideal world’ is a big reason why terms like ‘architecture astronauts’ and ‘ivory tower’ are often bandied around in this context.

    I think you can create a lot of value through capturing current world. Not just in the artefacts you produce out the other end, but in the conversations and connections you and the people you speak to have during the process.

    It also gives you a lot more credibility when you turn around and tell people what you want to change.

  2. Mmartin May 7, 2008 at 12:35 pm - Reply

    So – is there any guidance other than gut instinct to help decide how much "as-is" research & documentation is appropriate?  Or, assuming a fixed budget/schedule, to decide how to proportion the effort between "as-is" and "to-be"?

  3. NickMalik May 8, 2008 at 11:40 am - Reply

    Hello MMartin,

    Good question.  The method I’m using (SDA) draws the existing functional needs from the ‘as-is’ process.  Then, as the process folks work on the ‘to-be’ process, we have a functional list to compare against to insure that no functional requirements are missed.

    Therefore, the amount of necessary process is literally "do only the minimum amount" needed to produce that list of software features.

    — Nick

  4. Kevin May 9, 2008 at 10:20 am - Reply

    SDA method? Can you share what that is and a link? I am working-through this challenge myself right now.

  5. Hiren Bhatt May 14, 2008 at 1:44 am - Reply

    The analysis and documentation of the "as-is" process models provide a roadmap for “transformation management” or “change management” from many perspectives:

    1. People and Organizational teams

    – How their roles may/will change

    – How their "day if life" will change

    2. Forms

    – Forms are “Touch points” for customers with organizations for data entry

    – analyze each and every form and ask

    “Do we really need this form?”

    “Can we automate this?”

    “Can customers submit this information some other way?”

    Depending on the answers, the “to-be” process model will enhance the “as-is” process and it should trigger a communication to the affected parties (e.g., form printing and inventory, system designers etc.)

    3. Equipments and Materials

    – Equipments are used in almost all business processes and many times the processes handle materials. E.g., upon receipt of payment, ship out goods to the customers. Or in case of Netflix, upon receipt of the DVDs at the warehouse, send out the next DVDs to the customer.

    Changing the business process for Netflix (and I really want this feature from Netflix!) – e.g., if they establish some type of partnership with USPS then USPS can notify when they collect the DVDs being returned from the customers. This change in “As-is” business process will require purchase/installation/management/handling of additional equipments/materials by USPS and Netflix and will require formal change management (not to mention legal and financial contracts!).

    4. Systems

    – This one is obvious – if you are thinking about implementing a new business process, you will need to understand the existing systems which support “as-is” business processes, make an assessment – enhance or build new systems and accordingly create a system implementation roadmap.

    5. Communication to the customers/trading partners ("affected parties") etc.

    – A common theme in all the points above

    Did I miss anything? Would love to hear your thoughts.

    Hiren Bhatt

    Founder and Chief Architect

    Innowix

    http://www.innowix.com/blog/

  6. NickMalik May 14, 2008 at 12:18 pm - Reply

    Hello Hiren,

    One of the best, and most comprehensive, responses I’ve ever had!  Thank you!

    I spoke about recognizing the BAD things we are doing before figuring out what GOOD things we want to do.  

    You added to my effort immesurably by pointing out that the GOOD things they are doing will need to change to get to a BETTER place, and you need to know both (current and future) in order to plan for those changes.

    If you would be so kind, I’d like to ask you a question.  In your opinion, is it better to (a) create a future state process and test the idea first, before you begin to plan the "change management" issues, or (b) should we plan the change management issues at the same time as we model the future state, in order to create a better estimate of the cost of change?

    — N

  7. Hiren May 15, 2008 at 12:50 am - Reply

    Nick,

    I am glad I could help.

    In my mind, these two things should go in parallel. In the initial phases of BPA, you have to let “imaginations run wild” and create a high-level view of “to-be” process. Then you have to review the impact on “change management” aspects which will drive the cost equation. You take out those high cost items from the “to-be” process and come up with more reasonable approach. You may have to go through two or three (or more) iterations to arrive at the most pragmatic and cost effective “to-be” process models which are implementable.

    With this approach you can also create “hooks” into the scaled down “to-be” process which can be exploited in future as and when the value creation due to the new processes justifies more investments.

    To illustrate this, let me give you an example. I have worked on implementing Department of Motor Vehicle systems for various state governments. One of the business processes is for DMV to administer Driver’s License tests. Typically the DMV Inspector will carry a paper form with him/her while observing the driver drive through the course. She will keep noting down the observations/points during the tests and will update the system once they get back to the DMV office.

    One of the recommendations for the “to-be” process was to use a Tablet PC for recording the results during the tests and send it wirelessly – instantaneously – through a mobile wireless network. However, cost of wireless connections and the tablet PCs were too high for such solutions and hence we had to drop that from the solution (not to mention that it didn’t add that much of a value to the business!). However, when we architected the system (specifically the user interface), we designed it for Tablet PC usage.

    I hope this helps!

    Hiren

  8. Atif May 26, 2008 at 3:56 am - Reply

    From my personal expereince, the decision on what should be done first and to what level should it be taken, depends upon the type of proeject you are excuting.  For example for an ERP project I would like to keep my as is modelling between cloud and sea level as it makes more sense.  However, for something like a simple three page form jumping to ‘to be’ is no harm.

  9. Bruce Silver May 28, 2008 at 2:30 pm - Reply

    Another benefit to getting as-is right first is in getting the simulation parameters close to "real."  If your process model can capture the exception paths that drive delays, cost, and errors, then simulation analysis of the process model can project performance improvement before implementation of the to-be.  It is common to have some idea of the aggregate as-is performance metrics but only guesses as to the individual activity parameters.  Simulation of the as-is lets you get those sort-of right, which makes the expected to-be gains more believable.

Leave A Comment

four × three =