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.

Related Posts:

Aligning SAP Scope to Meaningful Business Requirements

April 13th, 2010 by

ERP or SAP Business Case, CRM, ERP, BI, and IT investment, where is the business benefit?I’m always amazed at how many projects miss one of the most important (and relatively simple) scoping requirements.  The worst part is that projects don’t just miss it but they get it completely backward!

After doing SAP projects since 1994, I still can’t believe SAP’s customers don’t use the old “Seven Habits” step of starting with the end in mind.  What do I mean by that? 

Start your SAP project with REPORTS and BUSINESS requirements! 

Come on now, WHY do so many projects wait until they are live with some new system to figure out what the reporting requirements are?  Reporting requirements must become part of the initial SAP scoping exercise.  Even if it is not spoken, every business that undertakes a massive ERP or IT project like SAP wants actionable information from the system after it is installed.  You want critical information that can enable you to:

  • Make better management decisions
  • Make better financial decisions
  • Determine what products or services have good margins (and which ones don’t)
  • How different product lines or geographies are performing
  • What future business directions you should take based on ACTIONABLE information
  • What competitive pressures in the marketplace to focus on
  • Etc.

Aside from the operational automation and getting business processes defined, reporting is the key for :

  • compliance,
  • operations decisions,
  • sales and product (or service) decisions,
  • and for every part of the business. 

Reporting is so critical to a business yet on almost every project it is treated as an afterthought.  Too often “reporting projects” start after the system is in place and people start working in it.  From a budget and cost perspective you don’t need all of your reports done as soon as the system is installed, but the system must be designed from the beginning to support all of the data needed for those reports.  It must be designed from the start to produce actionable information after the operational and automation components are implemented. 

If you start from the beginning with your reporting requirements you can ensure that the system design addresses any reporting gaps.  By doing this from the beginning you will not have the system installed and then be disappointed that it does not provide you with the key actionable information you need for your business.

Using Reports for Driving Meaningful Business to IT Alignment

Without knowing in advance what the final actionable reporting requirements are you will not be able to take advantage of some of the really great information that a system like SAP can offer.  When an SAP system is properly implemented and constructed SAP provides mountains of data and field options.  There is the ability to add custom fields, re-purpose existing fields [FN1], and add other data dimensions so that you can track and report on any piece of information in any way you can imagine.  However, if this is not planned for in the beginning, and then set up and trained so that you can maintain that data, then after you go live you may be disappointed. 

If you do not do this up front exercise you may discover that you need certain key data requiring expensive rework, expensive customization, and additional time budgeted.  And in the worst case, depending on the system design, you may end up creating a design dilemma causing even more trouble down the road.  Worse still you may discover that the way the system was designed and implemented may prevent you from ever realizing key decision-making information.

There is one other benefit from this approach as well.  By defining end-state reporting needs and end-state actionable information needs you can use this during vendor selection to separate the capable from the incompetent.  The ideal situation would go so far as to provide actual desired end-state reporting examples (field names, field values, etc.).

By doing this exercise you also have the additional benefit of focusing the entire project, right from the beginning, on the end-state goal.  This will help to distill the project down into actual business needs and business requirements for success.

Where to Begin with SAP Scoping and Reporting

Every customer considering an SAP implementation should carefully read through the article on developing an SAP business case (ERP and SAP Business Case for ROI, Business Benefit, and Success, PDF version attached here). 

The key steps to getting the most from your SAP implementation or your SAP scoping exercise is to start with the tools and resources SAP provides free of charge to their customers (and prospects).  There are a couple of tools in particular that every customer, or prospective customer should insist on working with before doing their SAP implementation.  The first is the SAP Solution Composer [FN2], it is a free download and it is a great tool for understanding how to scope your SAP implementation.  As mentioned in the article linked above on developing the SAP business case, it is a great tool for:

  • Developing an initial scope
  • Creating process lists for starting some of the critical change management discussions
  • Communicating in a “new” but common language about the processes.

The next tool available for a high quality project is the ASAP methodology.  It is an active HTML and Java script based repository which contains templates, resources, materials, and a project plan for ensuring you have a successful implementation or upgrade. 

Take Inventory of Your Existing Reporting Landscape and Define Desired Metrics

After your initial SAP scoping exercise it will be important to take an inventory of all of the spreadsheets, databases, and system reports that exist.  From these you can get a good idea of what will need to be accommodated in the system.  And from these existing reports the master data requirements that are required can also be derived.

After gathering the existing reports, begin short duration management workshops to define desired reports.  In other words what has been lacking from the business decision-making process that would provide strategic or tactical insight going forward.  For more information on one reporting and metrics strategy see the posts related to defining and understanding real Key Performance Indicators for business performance (see Why Indexed KPIs are Critical for Business Performance and Success, and Using Key Performance Indicators for Building a Strategy Focused Organization).

Once the initial operational requirements, existing reporting requirements, and desired reporting requirements are defined a final scope and blueprint can then be determined which will propel the business forward strategically into the future.

Conclusion / Summary on

Early Reporting Requirements in SAP Scoping and Blueprinting

In the end I’m still suprirsed at how many organizations finally get around to SAP reporting requirements after the system is already implemented an in place.  Just because you consider and plan for them from the beginning does not mean that you have to complete them by the time the system is in.  On the other hand, you will need them at some point so having the key data and understanding the business drivers for key information is crucial in your SAP implementation.

Too often the reporting metrics, goals, and drivers for business decision-making are treated as an afterthought.  Those reporting metrics and the business goals, key performance indicators, or business direction they represent are generally the reason for the huge investment in new systems to begin with. 

Stop and think about it, how will you ever know if any of the business-centered success criteria was delivered if you don’t have a clear direction in advance?  Those reporting requirements must include current and desired actionable data requirements in some measure of detail.  Certainly as a company and then during the sales cycles the buzz words and generalities of the information end-state are discussed;

  • during the early research,
  • during RFP preparation, and then 
  • during the vendor sales cycles when all of those promises are made about a “future state” for your business. 

Some of the actionable data requirements, or efficiency improvements, or competitive improvements, or other business drivers are also explored during this period.  If they are not captured and distilled into some detail, and then included in your RFP and project charter how will you know if they were ever delivered without defining these critical business justifications for the system to begin with?

One other thing to keep in mind is that no system, no matter how good or how well implemented will change a business by itself, but properly implemented it will provide the actionable information to make sound business decisions for marketplace success (see also SAP as a Change Enabler, Using SAP to Improve Revenue and Profitability, and Change How You Look at SAP to Create ROI).

[FN1] SAP provides a huge number of fields that are never used on most projects.  Some of them are directly tied to application functions and can not be used, still others are not and without doing any custom coding or application changes you can use some of these fields for other purposes.  This “re-purposing” of some fields is a very easy, cost-effective way to solve a number of issues.

[FN2] Go to and search for “Solution Composer” (or use this link – retrieved 4/13/2010).

Additional SAP Project Success Reading:

ERP and SAP Business Case for ROI, Business Benefit, and Success

Why SAP Projects Fail to Deliver ROI (and How to Change IT)

Related Posts:

ERP, SAP, or IT Project Management and Prototyping for Success

March 15th, 2010 by

Project GuidanceOver the years I’ve been on projects where there was great project management and others where the project management really stunk!  The projects with really good project management generally ran smoother, had less stress, and the project team was generally more productive.

A FEW of the Characteristics of a Well Managed ERP Project

There are a few things that I saw which were consistent with projects that were well managed.  In a nutshell they are summed up in the following key points:

  1. The project manager produces a published project plan with tasks, timelines, deliverables, milestones, and checkpoints.
  2. The project plan was at sufficient detail to manage the rolled up tasks, but not so detailed that the individual tasks were micromanaged. 
  3. Team leads had individual responsibility at a deliverables level.
  4. The deliverables were constructed at the detailed task level so that their progress could be reported to the rolled up project task.
  5. The project manager knew ahead of time what was coming in the next major phase and communicated that to the whole project team ahead of time, and at the transition times to the next phase.
  6. The “tools” or deliverables templates, resources, and tracking mechanisms were defined AHEAD of time, and then presented to the whole project team with explanations on what information was needed and how to use them as they were needed (JIT or Just In Time).
  7. Team leads held regular weekly status and progress meetings on deliverables status which was then regularly reported to the project manager and directly tied into the rolled up project tasks.
  8. There were several scheduled proof of concepts / prototypes / demos of functionality long before a solution went to testing.

This list is fairly generic and can be applied to just about any project.  Many, if not all of these items may seem common sense, intuitive, or basic but you would be shocked at how many projects deviate from these basic principles. 

SAP Prototyping, Proof of Concepts, Functionality Demonstrations, or Playback Sessions

And that last item, the numerous proof of concept reviews, prototypes, or functionality demonstrations throughout the project were critical.  These prototyping sessions were valuable because if they were properly scheduled (early and often) they quickly reveal:

  • Consultants who might be better on your competitor’s project(s)
  • Areas for genuine business value-add or ROI that might require a scope adjustment but the benefit far outweighed the cost
  • Capture and correction of process gaps before integration testing
  • Adjustment to process focus through better articulation of business need after “seeing” what functionality is there
  • Identification of gaps and risks in application functionality
  • Indicates whether your outside project manager is able to coordinate the necessary work-streams to accomplish the proof of concept sessions
  • Work through and resolve any early warning signs of performance problems

By insisting that your first proof of concept or prototype session occur right at the end of blueprint you have sufficient time to make any necessary staffing adjustments.  Maybe your competitors need some “help” on their projects :)

Warning Signs to Be Aware of In Prototyping

The first warning sign is if a prototyping session or timeline is missed without a clear justification.  For example, if the system landscape was not set up in a timely manner to construct the demo or prototype.  Unless this was due to procurement, logistics, or security issues outside of the project manager’s control then this should be viewed with suspicion. 

If there are SAP or ERP application problems which cause the delay you may want to take a hard look at any consultants who are responsible for installing and maintaining the various software applications.

Another warning sign is if the prototyping sessions are chaotic, disjointed, and generally fouled up experiences.  Usually this will fall into two categories, either a) the project manager is not as experienced as you might need, and therefore might be better off working for your competitor(s), or b) the project timeline might be too tight and there is not enough time to do the prototyping in a proper manner.  How can you tell the difference? 

There are lots of things to consider, but here are a few:

  • Is the problem because one key process area is not ready
    • Is the dependent process, or process bottleneck too complex for the time frame?
  • Would a few more days make a significant difference in the readiness, coordination, and execution of the prototype / demo?
    • If only a small time adjustment is needed, and there are obvious or clear results from just a few days, the timeline might be a little too tight
    • If a short delay does not produce a significant improvement in the organization of the prototype presentation as well as the fit and finish then you may have a project management or a consultant problem that needs to be addressed

To gain additional insight on this critical stage of the project, especially in the beginning when a properly formed foundation is so critical please see the post entitled “Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results.”

Related Posts: