Not only can the “As-Is” process mapping damage your project, but it also adds significant amounts of unnecessary cost.
Throughout my experience in SAP projects, I have participated in the “As-Is” and “To-Be” processing mapping exercises many times. Along the way, I learned a few key lessons.
First, the old “As-Is” process mapping approach was (and is) critical for software engineering projects. As-Is process mapping efforts have very limited application to an SAP implementation– or for that matter, any true Commercial Off-The-Shelf (COTS) business software project.
If you are purchasing a COTS application such as SAP, Oracle, or JDE, you generally plan to replace custom-built applications with standard, off-the-shelf package solutions. To do so, you often need to change your business to match application functions and processes. To keep the application as close to standard as possible, you need business process engineering rather than software engineering (see SAP Implementation Focus, Software Engineering or Business Process Engineering? ).
As that post points out, software engineering is sometimes justified, but that is an exception. Software development or software engineering with a COTS software package may be justified when you have a clear business justification, not just a “convenience” issue to resolve.
“As-Is” process mapping is critical for software engineering, but it offers little value to an SAP implementation.
If you have made a firm commitment to the business process engineering, then the “As-Is” process mapping exercise not only wastes time but also keeps your business stuck in the old ways of doing things, creating a high likelihood of demands for custom development. Correct SAP blueprinting methods automatically review the “As-Is” processes, but briefly enough to ensure that the future state covers all of the requirements.
Effectively Mapping Business Processes to the SAP Future State (To-Be)
The correct SAP ASAP approach, which is focused on business process engineering rather than software engineering, relies heavily on a good process scope. From that process scope, you conduct your requirements workshops to map the old processes to the new SAP “best practices” and determine any gaps. If the process gaps are business critical, they may justify some amount of custom development to meet an actual business need. At the same time, doing full-blown “As-Is” process mapping can create serious problems.
Being committed to business process engineering rather than software engineering makes the “As-Is” efforts throwaway work.
By focusing on the “To-Be” process state, a good SAP consultant walks through the “As-Is” processes to ensure they have captured all of the future state requirements. In other words, during the blueprint process, I may map out the current process on a white board, but only to ensure I have sufficiently captured all of the required blueprint details for the future process. Unless I find something unusual or business critical, I only map the future state (To-Be) processes with all of the existing business details.
By mapping processes in your SAP scope to the existing business processes, you are only looking for process gaps and process differences that may need to be addressed through change management. You are not wasting your time and effort, or expensive consulting resources, on mapping “As-Is” processes. You are reducing how much time your consultants and your own employees are immersed in something you want to change.
The ASAP Approach that Saves Money, Time, and Reduces SAP Total Cost of Ownership
Because custom coding and ongoing support of custom-coded solutions carry significant expense, your SAP Total Cost of Ownership (TCO) can be dramatically increased by getting immersed in the “As-Is” paradigm (see Lower SAP Application Support Costs – TCO – by Reducing Custom Solutions ). Think about it: If your project focuses on the current state rather than the future state, you are keeping your employees and project leadership immersed in current ways of doing things. That mindset leads to project team members who believe they must get everything custom-coded to match exactly what is done today. They complete little business process engineering, expending more money for an army of coders to engage in a software engineering project rather than a business process project.
Sometimes you need custom-coded software solutions, but they must serve a clear business purpose beyond a convenience or desire to do things the old way.
Being committed to business process engineering rather than software engineering makes the “As-Is” process mapping efforts throwaway work. When you reduce the time and effort on “As-Is” processes and focus on the future state, you reduce project costs and TCO by avoiding a huge, unnecessary investment.
Conclusion on the Dangers of “As-Is” SAP Process Mapping
When they spend too much time and energy on the “As-Is” state, your employees stay focused and attached to all of the old ways of doing things. Because of this focus, they naturally see more need for custom software engineering rather than business process engineering (i.e. change management). Not only do you pay for the wasted time doing unnecessary “As-Is” documentation, but you also get the “bonus costs” of software engineering. Your total cost of ownership for a COTS application goes through the roof.
When you focus the project on the “To-Be” state right from the beginning, you won’t eliminate all custom coding, but you will reduce it. This way, you reduce meetings/meeting time, decrease the amount of time and effort in blueprinting, and focus on value-added efforts. When you insist on a forward-looking focus on the future state and use a “To-Be” review as an analysis to ensure the project scope is complete, you reduce the time employees are enmeshed on the “old ways” of doing thing. This type of expectation setting is critical to a successful business process engineering project enabled by SAP business software applications.
Once again, I will clarify: Sometimes you need custom-coded solutions. However, they must serve a clear business purpose beyond a convenience or desire to do things the “old way.” As a result, the current way of doing business sometimes justifies the “As-Is” approach.
Realize I am “late to the party” here – but felt so strongly after stumbling across this that I had to comment.
I have seen more COTS/SAP/MS Dynamics projects fail because of “as is” than I care to remember. One spectacular failure actually never got out of the “as is” TO the “to be” because 1. the consultants “modeling” the process were absolutely novice and had no idea how to manage the process correctly. They ended up going back 3 times to the customers to try and “get it right” – and never did. and 2. the organization management and customers ended up simply mired in their old, territorial conflicts and unable to move forward. The project budget was quickly burned through, the project was never implemented – and the business “consultants” were actually rewarded for their ineptitude. The project never achieved any sort of critical mass towards delivery – at all.
I agree with the author. Quickly scope what is necessary – and move the customers towards thinking in the new ways that the new system offers. SAP (et al) is a challenge and a great opportunity – and the promotion of that aspect is often underwhelming by senior management. I love the line “reduce.. the amount of time your consultants and your own employees are immersed in something you want to change.”
I couldn’t agree more.
Thanks for the comments. I have personally seen the “As-Is” frequently damage SAP projects. As I wrote here, they do this by entrenching a project team in the old ways of doing things. The SAP application then ends up looking like the old system(s) being replaced.
Now, exploration of the current state (the “As-Is”) must take place when developing the future state. But ONLY enough to ensure that the processing requirements are covered. NOT to the extent that current processes are being mapped in detail, and then set up on paper altars to be worshipped.
I have personally used the approach of current state references several times VERY successfully to help accelerate projects, move to more standard functionality, make project dates and keep budgets from ballooning. IT WORKS!
Get people focused on the future state for success…
Bill,
The As-Is phase was always the consulting partner’s retirement fund phase. The only value I have ever seen from this exercise is the “starter kit” to teaching clients how to design a business process (by first understanding an existing process). It doesn’t take a $160 per hour consultant to do this.
As-is process mapping is just as necessary as you have to know your starting point when planning for a trip. No way to reach any goal if you don’t know where you’re starting from.
This article seems to be based on the premise that As-Is mapping is a long, tedious process. It doesn’t have to be. A solid method can get you through significant detailed mapping very quickly.
< < Explicit Sales Material promoting and advertising "As-Is" process mapping tools was removed >>
The author states that you need to identify gaps between the current process and the To-Be process, that “a good SAP consultant will walk through the “As-Is” process” and that the author “may map out the current process on a white board”. These all support As-Is mapping and are somewhat conflicting with the idea that As-Is mapping is unnecessary or even dangerous.
Mapping As-Is processes gets undeserved negative press because many folks just don’t do it well. I have seen a tremendous amount of mapping that is more like high-level guesswork than structured process mapping. It doesn’t provide much value. It is unfortunate that many folks attempt to adapt box and arrow programming flowcharting method to business processes where it just doesn’t fit well. I have also seen good detail process maps prepared quickly that provided significant value.
A solid mapping method applied correctly provides significant advantage to makeshift mapping or no mapping at all and provides opportunity to tap into years of organization-specific experience that may otherwise be ignored or given only superficial consideration.
For COTS enterprise applications (like SAP’s applications) a formal structured approach to process mapping “As-Is” processes creates a fixation on the “old ways.” While a REVIEW of “As-Is” processes may be needed, that is only in the context of a future state and to identify gaps. It is not to map out the old, “As-Is” processes.
The dangers involve the tendency of a client who is focused on the “As-Is” state to then focus on custom coding rather than business process engineering.
Read the article carefully, true “As-Is” process mapping is valuable for software engineering projects that do not use COTS (Commercial, Off-the-Shelf) applications. However “As-Is” process mapping is a complete and total waste of time, effort, and money for any company that wants lower TCO for their applications and the ability to make additional SAP functionality available at a lower cost later on.
Further, anyone who really wants to do process mapping has numerous tools available, like Microsoft’s Visio which is easy to use and well-known.