Business Solutions with SAP

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

January 3rd, 2011 by
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.

Popular Searches:

  • sap process maps
  • when Is AS IS process mapping unnecessary

Related Posts:

Software Consulting Firms and Clients Myths and Half Truths

December 6th, 2010 by

DirectionA recent post from my friend Steve Phillips who runs a great site entitled “Street Smart ERP Blog“.  This is a nice complement to the series I just finished on SAP and ERP critical success factors.


Steve Phillips writes:

Having spent the majority of my career in the shoes of a software consultant or client, I have often wondered why many find it necessary to perpetuate the old myths and half-truths regarding the consultant / client relationship. My feeling is given the track record of ERP we are not doing anyone any favors. In fact, we are causing more harm than good by setting false expectations regarding what consultants are, what they are not, and what the client should be doing.

One answer is …the myths are self-perpetuating. That is, consultants want clients to believe them (more billable hours) and clients desperately hope they are true (even though deep down they know better).

The other answer could be consultants actually believe they are super-human and clients play into this by getting the consultants to assume all the project risks. The real answer is …we are all a lot smarter than that.

In this and the next series of blog entries, I explore this topic by addressing each of the fifteen myths. No doubt, some will not like what I have to say. But if we cannot acknowledge the problems, we certainly cannot address them (and for the sake of everyone involved, let’s face it, they really do need to be addressed). Here is the first one.


TRUTH: Consultants can educate, suggest and coach but cannot make the client do much of anything. In fact, for most ERP “critical success factors” consultants have no direct authority or control over the outcomes.

There might be a few superhuman consultants out there, but 99.9% of them are not.

Only the client can:

  • Own and communicate the business case and drivers for the change.
  • Clearly define and communicate their project objectives.
  • Implement measurements to support the desired behavior and process changes.
  • Approve and contain the project scope.
  • Require (not just sell) the cooperation of employees at all levels of the organization.
  • Assign the right internal employees to the project team.
  • Free-up the required time for those assigned to participate.
  • Expect (not hope) the internal team eventually becomes software experts.
  • Hire employees with the right skills and knowledge when necessary.
  • Manage and utilize outside consultants correctly.
  • Hold functional managers and the team accountable for fulfilling their roles
  • Make necessary changes in operating paradigms and business processes.
  • Limit software mods through justification or changing business processes.
  • Remove the people barriers and naysayers that get in the way.
  • Tackle project issues and decisions in a timely fashion.
  • Take end-user training seriously and require employees to attend.

Again, no matter how great your ERP software or consultants, these are things only the organization can do.

So can your software consultants make you successful?

Related Posts:

A New SAP Implementation Methodology and Implementation Steps

June 28th, 2010 by
SAP Project Dimensions

SAP Project Dimensions

Studies have shown that there is a critical disconnect between projected benefits in business cases for IT investments and actual value achieved, because so many firms focus on going live with a project rather than its value delivery. An SAP / ASUG best-practice survey on the ability to capture the projected benefits of an IT project found that 73% of companies do not quantitatively measure value post-implementation. (SAP Executive Insight Series, pg. 7, 2009).

Critical business benefits for an SAP project require taking a hard look at the enterprise and its goals or direction [FN1].   The successful SAP project scope must encompass more than just operational considerations (process improvement and automation); they must include the critical components of focusing on the customer and product or service innovation (see e.g., Process Execution of Business and IT Innovation).  This is a significant departure from current consulting and system integrator paradigms.  Modern business no longer has the luxury of relying on static business processes that pay lip service to the customer or ignore the imperative for innovation.

Across the enterprise landscape, globalization, the Internet, disruptive innovation, and the threat of rapid commoditization have ignited the speed of change. It’s no longer a matter of keeping up, but rather of continuously reassessing, reinventing, and transforming operations on the fly. The pressure to adapt business processes—once thought of as airtight—at an ever-accelerating pace has never been greater… Rigid infrastructures and organizational models that hamper agility prevent businesses from growing or even coping (Bouhdary pg. 52, 2008). [T]he successful enterprise must think of its business as a holistic network, able to adjust and make changes on the fly and also able to free up resources for innovation rather than administration (Ibid. pg. 53, 2008).

This is obviously not a small task, but it is achievable.  To make this happen takes a conscious, concerted, and sustained effort to link technology to business needs and not just to implement technology for the sake of technology.

Companies that implement enterprise resource planning (ERP) systems aligned with the overall business strategy enjoy performance gains unknown to firms who do not implement these solutions…

While many commentators would suggest this approach takes a new SAP Implementation Methodology, in reality the approach, tools, techniques, and requirements have been spelled out for several years in the SAP ASAP methodology.  Unfortunately too few companies bother with following that methodology even though they routinely commit to it in all of their sales presentations and literature.

SAP Projects Must Produce Business Benefit, ROI, while Reducing Current TCO

Research indicates that ERP benefits require in depth discussion and strong coordination of goals and resources across business and IT personnel (Willcocks and Sykes, pg. 33-38, 2000).  These benefits, or the measurement of ERP success, are at least partially dependent on managing requirements throughout the entire ERP lifecycle (Holland and Light, pg. 1630-1636, 1999), including acquiring and managing user requirements (Ginzberg, pg. 459-476, 1981).

To manage the ERP lifecycle, goals must be established along with the education and communication of the long-term impact of the goals on the organization (Chang, pg. 6, 2004).

The answer to any successful business transformation is the establishment of open communication channels woven throughout the firm and its network of partners…

Research conducted by faculty at New York University, Massachusetts Institute of Technology, and Georgia Institute of Technology shows that companies that implement enterprise resource planning (ERP) systems aligned with the overall business strategy enjoy performance gains unknown to firms who do not implement these solutions (SAP Executive Insight Series, pg. 4, 2009).

The next generation of technology alignment will require a much more collaborative environment where the business is able to extract critical information from all of the business stakeholders:

  • employees,
  • customers,
  • vendors, and
  • any marketplace or trade sources.

Economic pressures, global competition, changing political landscapes, and the explosion in information sources available to consumers have forever altered the competitive business landscape.  While capital is not as easily available as in times past, it is still far more readily available across the globe, and in developing nations like never before in history.

The rise in consumer power, facilitated by easy access to capital and the Internet, is converging with technology to drive rapid commoditization, necessitating the continuous assessment, reinvention, and innovation of business models at greater speeds…  The answer to any successful business transformation is the establishment of open communication channels woven throughout the firm and its network of partners, making it a hotbed of inventive ideas. An organizational structure must facilitate and nurture those ideas so they can quickly find their way to the top and become strategic assets (Bouhdary ppg. 54, 2008).

Tomorrow’s most successful enterprises will be able to harness the various sources of information and then quickly assimilate and distill the information into actionable objectives.  These actionable objectives will be aligned to key goals and competitive pressures unique to that company or organization [FN2]

The Marketplace is Finally Seeking the Value SAP Implementation Methdology

The marketplace is beginning to show signs of demanding a new SAP Implementation methodology; a new guide or new implementation steps focusing more clearly on the two business value propositions of innovation and customer focus. The marketplace is finally beginning to demand the value portion of the SAP ASAP Implementation Methodology that has been around for over 10 years that I know of.


[FN1]  KPI Development, Business to Technology Alignment, and getting real business benefit from technology investments.

[FN2]  The next generation of enterprise applications will rely heavily on the integration of collaboration.  These next generation systems will focus on how a company can integrate and develop both collaboration and customer-centric products and services.



Bouhdary, C., (from SAP Fall / Winter 2008). Built to Adapt: High-Velocity Transformation and Integration.  The Journal of the EDS Agility Alliance, Volume 3 Issue 3,

Ginzberg, M. J. (1981). Early Diagnosis of MIS Implementation Failure: Promising Results and Unanswered Questions. Management Science, Vol. 27, Iss. 4.

Holland, C. and Light, B. (May / June 1999). Critical Success Factors Model for ERP Implementation, IEEE Software.

SAP Executive Insight Series (September 7, 2009).  Accelerate Value Creation: The Virtuous Cycle of Using Technology to Maximize Business Value. (retrieved 4/23/2010).

Willcocks, L. P. and Sykes, R. (2000). The Role of the CIO and IT Function in ERP. Communications of the ACM, Vol. 43, Iss. 4.


Popular Searches:

  • sap implementation methodology
  • sap asap methodology steps

Related Posts: