SAP process mapping

Not only can the “As-Is” process mapping damage your project, but it also adds significant amounts of unnecessary cost.

Throughout my experience in 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 – or for that matter, any true Commercial Off-The-Shelf (COTS) project.

If you are purchasing a COTS application such as , 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 .

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 . 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 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. ). Not only do you pay for the wasted time doing unnecessary “As-Is” documentation, but you also get the bonus costsof 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 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.