Most process design methodologies start by modeling the As-Is processes before proceeding to define the To-Be processes. In our experience, many projects spend more time than is necessary modeling the As-Is, when they should be working towards the future. Time and resources spent modeling the As-Is delay the delivery of the final project, and should only be done to the extent that they add value. In this article, we will discuss the purpose of as-is modeling, common pitfalls which lead to excessive effort and concrete guidance on how to improve results with less effort and expense. While studying, current practices can be valuable, the current process must be flawed or you wouldn't be replacing it. The last thing you want to do is replicate the flaws of the existing solution.
Why do As-Is Modeling
As noted above, most process design methodologies start with As-Is modeling. The goal must not be creation of a complete detailed model of the current solution; you must remain focused on building the new solution. If you task a group of experienced modelers to create an As-Is model, that is what you will get. More than likely it will have taken much longer and cost much more than is necessary. In the extreme, the project is so far over budget at this point that it is cancelled. If the goal is not to build an As-Is model, then what are the requirements for As-Is modeling? You want to learn the details of the current solution which are necessary to design and build a superior replacement.
Note that none of the above really requires a model of the existing system. You want to focus only on those aspects which define essential characteristics of the new solution. We explicitly avoided documenting how the current system does the work. That may be useful reference information, but the new system should not be restrained by the design of the existing one except where essential, externally observable behavior is involved.
How much As-Is Modeling should we do?
There is no simple answer which fits all projects. Some of the considerations are the impact of the solution on the business, the relationship of existing and new solutions and the planned transition from new to old.
The first consideration in determining the scope of As-Is modeling is the relationship between the current solution and the proposed replacement. Is it a technology upgrade for basically the same business functionality? Is it incremental improvement on the same basic business model? Is it driven by mergers and the need to consolidate different solutions? Is it entry into a completely new business where there really is no existing solution? Each of these scenarios requires a different approach to As-Is modeling. The closer the future state is to the current, the more value there will be in studying the current solution.
The next factor to consider is the impact of the current solution on the business. Is it a mission critical system which creates a key competitive advantage, or is it one of the multitude of mundane things necessary to keep the business running. Is the current system considered a liability or an asset to the organization? Is replacing it a necessity for survival due to its failures or an opportunity for gain due to its impact? Obviously mission critical systems deserve more modeling effort than routine support systems. When the current system is perceived as a failure, analysis should focus on determining why and avoiding those mistakes.
Another important consideration is the transition from the old solution to the new one. Is the current system of record for long-lived data being replaced? If so, then you obviously need to understand that data to ensure that the new system does not change historical records. Will there be long duration which must be switched from the old solution to the new mid-cycle, or will the two coexist until work completes in the old. When it is an immediate switch-over of work in progress it is necessary to determine all of the transitions.
When Are You Done?
To quote a modeling theory expert: “The time to terminate a modeling activity is thus not when the model is perfect (which will never happen) but when it has reached a state where further modeling is less beneficial than applying the model in its current state” (Lindland, Sindre & Solvberg: Understanding Quality in Conceptual Modeling 1994). As-Is and To-Be modeling should not be thought of as a strict sequence, but rather a repeated iteration. As soon as possible start hypothesizing the future system. Where there are gaps in your understanding, ask yourself if further analysis of the As-Is will help. If so, go back to As-Is modeling to close the gap, then return to working on the future state. When in doubt, move forward. If you don’t know enough it will become apparent quickly. Don’t try to understand every detail of the current solution, much of it is irrelevant to the task of building the future solution. Remember that your goal is to build the new solution, not to create perfect documentation of the solution being retired.
As-Is modeling remains an important step in Business Process development, but often we have observed it becoming a goal in itself and consuming unnecessary resources. Always remember the end goal and use As-Is modeling judiciously to achieve it. Stop as soon as you think you have enough information to start modeling the future. You can always go back if necessary.
How do we accomplish this?
We will close by presenting some concrete steps you can try on your next project to optimize the effort you are spending on As-Is Modeling. Each organization and project will need to adapt these ideas to fit in their organization and culture.
We hope that this article will lead you to think about your approach to your next Process improvement project and try at least some of the ideas presented here. We believe that if you do you can reduce your project cost and timeline by focusing efforts on the future state, not the past.