INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP
Business Process Engineering or Software Engineering

SAP ERP business software implementation

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

After over 20 SAP projects since 1994 I’ve 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’re buying a COTS application like SAP, Oracle, JDE, or any other major ERP business software package you generally go into it with the idea that you are replacing custom-built applications with “standard” off-the-shelf package solutions.  This generally requires an expectation that you will change your busines to match application functions and processes.  To keep the application as close to standard as possible you will do business process engineering rather than software engineering (see SAP Implementation Focus, Software Engineering or Business Process Engineering? ).  As that post points out, there are times when software engineering is justified, but those are exceptions.  Software development or software engineering with a COTS software package may be justified when there is a clear business justification, not just a “convenience” issue to resolve.

“As-Is” process mapping was 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 it keeps your business stuck in the old ways of doing things and creates a high likelihood of demands for custom development.  Correct SAP blueprinting methods will automatically review the “As-Is” processes but only 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 throw away work.

By focusing on the “To-Be” process state a good SAP consultant will walk 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 there is something very 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 the amount of 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 of the huge expense in custom coding and in ongoing support and maintenance of custom coded solutions 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.  Very little business process engineering is done and more money is expended for an army of coders to engage in a software engineering project rather than a business process project.

There are times when custom-coded software solutions are necessary 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 throw away work.  By reducing the time and effort on “As-Is” processes and focusing on the future state you reduce project costs and TCO by avoiding a huge investment in what will eventually become garbage.

Conclusion on the Dangers of “As-Is” SAP Process Mapping

By spending 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 will naturally see more need for custom software engineering rather than business process engineering (i.e. change management). So in the end 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.

By focusing the project on the “To-Be” state right from the beginning you won’t eliminate all custom coding but you will reduce it.  In this way you reduce meetings and meeting time, reduce the amount of time and effort in blueprinting, and you focus on value-added efforts.  By insisting on a forward looking focus on the future state and using a “To-Be”  review as an analysis to ensure the project scope is complete enough you will reduce the amount of 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, there are times when custom-coded software solutions are necessary but they must serve a clear business purpose beyond a convenience or desire to do things the “old way.”  So there are some times when the current way of doing business might justify the “As-Is” approach.

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175
Bill Wood contact

=========================





Popular Searches:


  • as is process in sap implementation
  • as is process map
  • sap to-be process
  • As-is To-Be process mapping
  • as-is to-be process mapping tools
  • erp blueprint
  • what is as is process map
  • why and organization might choose to change its process to fit the blueprint

Related Posts:

6 Responses to “How “As-Is” Process Mapping Can Damage Your SAP Project”

  1. Ben Graham says:

    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.

    • Bill Wood says:

      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.

  2. John Strend says:

    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.

  3. Michael Doane says:

    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.

  4. Bill Wood says:

    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…

  5. Chana O'Leary says:

    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.

Leave a Reply