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.
- What are the commitments satisfied by the current system? These can be regulatory, contractual or company policy. Will the new system be expected to continue to satisfy all of these? Are there new regulations or other constraints coming into effect which the new system must satisfy?
- What interfaces does the current solution have with the rest of the world? These can include interfaces with other systems, partners and people. Which of these are necessary in the new solution? What are the inputs and outputs of the system? What triggers execution and what downstream activities must be triggered?
- Is the current system the System of Record for any data? Will the new system be the System of Record for that same data? What are the retention requirements? How will the migration of data from old system to new be handled?
- Who are the stakeholders in the current system? This is one of the areas most likely to change. New systems typically bring higher levels of automation, elimination some current tasks, while creating new ones.
- What are the perceived flaws and weaknesses in the current system? Spend enough time listening to all categories of stakeholders to identify the major flaws.
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.
- Communications are critical. You will be proposing a different approach to project definition. Change always upsets, or even frightens some individuals. You must get the team on-board with the new approach or it is likely to fail. Start during the project kick-off meeting. Describe the new approach, what you will be doing, what you will not be doing that was done in the past and why it is the right approach. Give the team the opportunity to express their concerns and listen carefully to them. Revise your approach as necessary. We are proposing a relatively short As-Is analysis phase for most projects, hold daily status meetings. Review progress, especially tasks completed. Agree on the next day’s plan. Let people raise any new issues or tasks which were discovered during the previous day. Identify key stakeholders who must be scheduled for the next few days, with longer lead times for the most senior people.
- Define an appropriate set of deliverables. It is a well-known management principle that you will get what you measure.
o Document the commitments which the new system must satisfy.
o Document interfaces to existing internal and partner systems. This should be primarily links to those systems documentation.
o Document the proposed organization. Consider a RACI chart (Responsible, Accountable, Consulted, Informed). o Document all assumptions.
o Document Risks identified.
o Provide a very high level transition plan from old system to new.
- Just as important, make explicit what is not to be produced. Many approaches to As-Is modeling start with a “swimlane” diagram. This is inviting the team to produce full documentation of the existing system. Review your existing approach and determine which current artifacts can be eliminated. Communicate clearly the reasons for the changes.
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.
