Business Solutions with SAP

3 Keys to Reduce SAP TCO & Move to SAP ROI

June 26th, 2011 by
Building an SAP Center of Excellence

SAP Business Convergence

I only have a couple more posts in my series on overcoming vendor sales tactics so I thought I would provide a brief distraction and look at a few key areas for SAP organizations to move to “excellence.”  This post focuses on some of the considerations for SAP Total Cost of Ownership (TCO) and SAP Return on Investment (ROI).

One key to achieving SAP ROI is through convergence or integration of the SAP staff into the business.  I’ve started down this path as part of a follow-up to the recent ASUG Atlanta conference presentation I did on “Beyond Business to IT Alignment – Creating Convergence in the SAP Enterprise.”  Those materials are now available online.  The first part of them consists of a two-piece resource kit, and the Roadmap Builder, can help to transform your enterprise and business prospects.

Preparing the SAP and IT Organization for a Center of Excellence

This post will provide an overview of ways to achieve business benefit, reduce costs, and achieve ROI.  While I would like to go into detail for each of these components it is best to leave them in a list format.  To expand on them would create a 20 or 30 page document.

Your goal is to drive business innovation and marketplace differentiation

So, to keep things simple I will condense this down into a bullet-point list covering the 3 key topic areas of

1) Engaging the Business,

2) Reducing Complexity, and

3) Delivering Excellence.

The SAP Organization Must Engage the Business

  • Converge IT and Business efforts
    • Regularly convene a senior business representative steering committee
    • Facilitate business and IT planning sessions
    • Use business resources to help manage the project
  • Develop dotted line IT staff to business organization relationships
    • Assign one or more IT staff to each business area
    • Have IT / SAP resources work in the business areas on a regular basis
    • Ensure they perform some of the routine tasks in the business area
    • Develop improvements, solutions, or ideas in conjunction with business users
  • Create Service Level Agreements (SLAs) for post production activities
    • New feature or functionality requests
    • System performance and uptime
    • Issue escalation and resolution
  • Build Technology Solution Roadmaps
    • Define and prioritize technology requests
      • Need
      • Want
      • Market impact
      • Strategy impact
      • Business area(s) impacted
    • Perform cost / benefit analysis
    • Evaluate alternatives

The IT and SAP Staff Must Reduce Complexity

  • Consolidate
    • Hardware
    • Applications
    • Network infrastructure
    • Application delivery infrastructure
    • Interfaces
  • Decommission legacy systems
    • Reduce license management
    • Reduce technical support costs
    • Reduce interfaces
    • Improve data consistency
  • Reduce custom solutions – clear custom development

The SAP and IT Organization Need to Deliver Excellence

  • Lean implementation
    • Use SAP Solution Composer
    • Use SAP Solution Manager
    • Employ ASAP methodology
    • Leverage vendor templates where they are useful
  • Optimize performance
    • Make use of automated batch jobs for repetitive transaction tasks
    • Use performance and monitoring tools
    • Create additional database indexes where useful
  • Use QA processes to ensure Quality results
    • Ensure all project code is QA checked
    • Perform project QA’s at key milestones
    • Ensure deliverables are complete and useful (if they are not value added they are a waste of time)
      • An example of a wasted deliverable is something that serves only administrative “reporting” functions.
    • Ensure testing is thorough and challenge testing is performed
  • Employ proper IT Governance Principles
    • Ensure proper standards are created and then followed
    • Evaluate, review, and escalate as necessary
    • Ensure key decisions are time bound
    • Be prepared to transition to support at go-live
    • Create issue and risk management processes
  • Ensure knowledge transfer
    • Make sure that company IT or business staff can support the solution
    • Ensure end user training is thorough
    • Send IT or business support staff to SAP courses (pay now or you will pay far more later)
    • Use post production learning and improvement sessions

Conclusion on Reducing SAP TCO While Realizing SAP ROI

Customers who are either considering or undergoing an SAP project must perform due diligence to ensure they get what they are paying for.  Not only do you have to evaluate cost savings, but the cost of ownership (software, ongoing support, and maintenance costs).  Together with that it is important to ensure you get some business value from your SAP investment.  More than just promises it is important to define, develop, and then measure success criteria after the SAP implementation.

To make things even more complicated your SAP and IT support staff must work to become directly integrated into the business.  Your goal is to drive business innovation and marketplace differentiation.

Related Posts:

SAP Project Implementation Strategies and Approaches

October 25th, 2010 by

SAP project successFor a brief intermission before I make the final posts on managing the shared responsibilities for SAP project success I thought I would offer this explanation of the different strategies and approaches for an SAP project.

 There are three key dimensions to an implementation strategy–, they are: 1) the vendor type; 2) the methodology-tools-templates-resources for a project, and; 3) the implementation approach.  The decisions you make around these three areas generally make up the implementation strategy for your SAP project.

SAP Implementation Methodology

For the methodology approach I will assume you are using the SAP ASAP methodology.  As a result other than mentioning it here I won’t spend a lot of time on this one.  With only a few exceptions, nearly every SAP system integrator claims they follow the SAP ASAP methodology.  As an ASAP certified consultant since the late 90’s I can assure you that few SAP system integrator project managers actually follow much of the ASAP methodology no matter what claims they make during the sales cycle.

The SAP ASAP methodology will help to ensure you are doing the right things in the right way

I’ve written on the ASAP methodology in A New SAP Implementation Methodology and Implementation Steps and for more background on the different vendor or project approaches see Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP .  And let’s put this in context, the SAP ASAP methodology has been used literally tens of thousands of times.  It is tested, proven, and it plain works!

The SAP ASAP Methodology is tested, proven, and it plain works!

As a parting note I would strongly encourage any SAP customer to get their own copy of the ASAP methodology.  No matter what stage of your SAP project the SAP ASAP methodology will help to ensure you are doing the right things in the right way. 

For more information on acquiring your own copy of the SAP ASAP methodology, see the 10 steps I previously outlined under the section “Where to start with developing a solid SAP business case based on business and IT strategy” in the post ERP and SAP Business Case for ROI, Business Benefit, and Success.  During the sales cycle (or during your project if you are past that) ask your SAP system integrator to show you the SAP ASAP methodology.  There are two identical versions, one is an HTML web server version and the other is integrated into Solution Manager.  Both are free, and the HTML version is available to any customer or vendor free of charge who wants to download it directly from SAP.  There really is no reason they can not make it available.  Because of its wide availability you should beware of any vendor who pitches the SAP ASAP methodology and can not make it available to you! 

If you are an end SAP customer contact me and I will arrange for you to get your own copy!

SAP System Integrator or Implementation Vendor Type

This topic is a little different because there are several possibilities for how you approach your vendor selection or project staffing.  Each of them has their benefits and drawbacks and some of them can be substantially different in cost and results.  The type of implementation vendor and consultants you use will also affect your implementation strategy.

You may wish to employ a well established system integrator; a “boutique” consulting firm; or completely manage the project with your own selected staff of contractors; or you may want to consider a hybrid approach.  If you are considering the contractor route, of staffing a project yourself, you might wish to review the screening methods to find the right consultant Part 1 and Part 2.

You will also need to determine your project implementation model.  Will you do a pure time and materials approach, or fixed fee, or time and materials with penalties for under-delivery (over budget, over time) and rewards for over delivery (under budget, early), or time and materials with cost controls, or a blend of some of the approaches.

Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP

If you choose the large integrator be prepared for the full sales pitch about their “special” methodology (whether it actually exists or not).  This is one of the classic approaches the larger consulting firms use to try to differentiate themselves.  However the SAP ASAP Methodology has been tested and proven so many thousands of times that any other approach actually introduces risk into the project.  That does not mean that there aren’t ways to supplement that methodology — there are a few gaps — but the ASAP methodology is very solid, reliable, proven and consistent.

The boutique firm may work well for many companies, but they have the drawback of being focused on a narrow niche area. 

The company run implementation with outside contractors (rather than a system integrator) requires a very experienced, very skilled SAP project manager.  I have participated on two of these projects that were very successful and their rates were about 35 – 50% less expensive than other consulting options.  One significant caution here is this type of approach can be a disaster without the means to carefully screen consultants and without a very seasoned SAP project manager.  The other problem is that many (though not all) of the staffing and recruiting firms are so “sleazy” that you are better off putting in the effort to screen yourself.  Back to the chicken or the egg problem, this requires someone who has the capability to do the screening.  This approach has probably the highest reward and the greatest risks associated with it. 

SAP Project Implementation Approach

Over the years I’ve only ever seen two key approaches to SAP implementation projects–, Big Bang or Rollout projects.  Within these two methods you can do a Phased Approach as well, but that is more of an issue of functionality scope rather than organizational scope.

Organizational scope would cover the “Big Bang” SAP implementation approach and the “Rollout” SAP implementation approach.  It affects the amount of the company or organization that is affected by the project. 

Functional scope would address the amount of the SAP business software that you plan on bringing into your organization(s).  This would generally be a “Phase” of the project.  For example you might bring in Financials and Supply Chain functionality in Phase 1, and then CRM or online ordering or BI / BW (reporting) in Phase 2, etc.

ERP Big Bang

The “Big Bang” SAP approach is probably the most common and generally involves a single major functional event.  It usually affects all “legal companies” where financial reporting is required for taxes or regulatory requirements.  This can be a large implementation across multiple countries, multiple business divisions or product lines, and generally affects the whole of the organization.

The “Big Bang” approach may be easier from a single “change event” or “change shock” to the company and organization but it has a number of drawbacks as well.  For example with any ERP application some of the potential design, data, and knowledge transfer problems are only discovered after the system is live.  So if your SAP system integrator or vendor is not as skilled as their sales presentation might have indicated you could end up with serious long-term difficulties, cleanup, and ongoing maintenance headaches.

ERP Rollout

The Rollout approach is fairly popular among a number of larger SAP customers with several legal companies, several locations, or multi-nationals that do business in several countries. 

Advantages of this approach includes the ability to “learn” from each rollout and improve subsequent operational rollouts.  Rollout risk can be more carefully managed because data and configuration inconsistencies can be discovered, remedied, and resolved while the subsequent rollout is occurring.  Change is better absorbed over a longer period of time in the company and knowledge transfer is generally better handled if the customer insists their resources are involved (done correctly this can actually reduce overall implementation costs).

Disadvantages of this approach are that it generally costs more because cumulatively it takes more time and effort to manage the ongoing operations while also bringing on new operations.  Also the blueprint will need to be re-visited for each rollout location because no matter what ANY integrator says (or what the SAP documentation purports) there always seems to be some legitimate differences between each rollout location.  Failure to re-visit the blueprint for each rollout, no matter what the integrator or SAP might say, can cause more difficulties than it is worth.  However, these later stage blueprint reviews and adjustments are not as intense or time consuming.

ERP Phased Approach

Because of the many variations and options we will re-visit the Phased Approach at a later date with more details.

Popular Searches:

  • SAP Implementation strategy

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: