Enterprise Initiatives

Last fall, my company embarked on a business processing reengineering effort that focused on the the sales creation to product delivery life cycle. In just over two months we documented the current state of our business processes, identified the desired future state, performed a gap analysis, identified a roadmap to get us to the desired future state, and built a portfolio of key projects backed by key financial data including ROI analysis and NPV. This portfolio of projects is where we are focusing our BPM and SOA efforts today.

One thing I have been pondering as we get ready to launch our second business process reengineering exercise for another business unit is.....

Is it better to start with the current state and then analyze future state

or

should we focus first on the future state and then analyze the current state processes that are barriers to achieving future state?

There are two reasons why I feel that doing future state first might be better.

1. Focus more on where you want to go and less on where you have been
2. Allows you to start your analysis with the overall business objectives and drill down instead of focusing on deficiencies and working up.
   

It feels like going from current state to future state constrains you when you start defining the future state. When we had business users in the room brainstorming about the future, they would start with the current business environment and start trying to improve upon it. Wouldn't it be better to start with a blank slate and define what the future state should be like without any restrictions? Once that work is complete, we could perform the current state analysis and then figure out how to get from current to future. Granted, some of the future state ideas may not be feasible but why not get all of the innovative ideas out on the table before they are written off?

This is the same approach we are taking from the architecture viewpoint. We are starting with a clean slate. We are establishing a methodology, standards, and best practices purely targeted at a services oriented architecture. Our current methodology is not really built for agile development so why should I try to make it fit for SOA? Our current design standards hardly apply to enterprise wide development. Most of the development we have done before SOA was very application specific. Again, why put a square in a round hole?

I am really just thinking out loud here and not really recommending one versus the other. I have experience starting with current state and moving to future state. We have been successful but it feels like it is a much slower path to the promised land. I would love to hear from those of you who have been through an exercise like this and what your opinions are.