Freigeben über

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

  • Artikel

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: BPM,Process,As-Is

Comments

  • Anonymous
    May 06, 2008
    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.

  • Anonymous
    May 07, 2008
    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"?

  • Anonymous
    May 08, 2008
    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

  • Anonymous
    May 09, 2008
    SDA method? Can you share what that is and a link? I am working-through this challenge myself right now.

  • Anonymous
    May 13, 2008
    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
  1. 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.)
  1. 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!).
  1. 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.
  2. 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/

  • Anonymous
    May 14, 2008
    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

  • Anonymous
    May 14, 2008
    The comment has been removed

  • Anonymous
    May 25, 2008
    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.

  • Anonymous
    May 28, 2008
    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.