INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

Do You Know When To Do SAP Custom Development?

April 11th, 2011 by

Use SAP Best Business Practices for commodity processes and development for value added processesUse SAP Best Business Practices For Commodity Processes But More Carefully Evaluate Competitive Processes

The debate and discussion around SAP best business practices usually assumes an “either-or” mindset.  Either you use the SAP best business practices as they are or you abandon them (for more background on SAP’s “Best Business Practices” see What are SAP Best Business Practices Anyway).  Several commentators suggest you should not do a software vendor’s “best practices” because you are adopting the “herd” mentality and will not be competitive in the marketplace.  They completely ignore the reality that some processes do not need huge development investments.  SAP provides a number of tools and resources to evaluate its solutions for your enterprise’s business processes (see Using SAP Solution Composer for SAP Scope – Process Alignment).

Commentators who are broadly against “best practices” have failed to recognize that there are different types of business processes.  One type are what I call “commodity processes” or the things you must do to run business, that everyone does, but adds little or no value to reducing cost, increasing revenue, or improving margins.  The other type are “value added” processes where the process itself (not ancillary manual steps) directly aid in reducing cost, increasing revenue, or improving margins.  Some business processes justify custom development when a standard solution will not do certain business critical processes (see e.g. Lower SAP Application Support Costs – TCO – by Reducing Custom Solutions).

Value added processes must directly contribute to market share or address a specific pressure from a competitor or they are commodity practices which are good candidate for “best practices.”  By reducing costs or increasing revenue and margins you are directly affecting your competitive posture in the marketplace.

What Are Value Added Processes in the SAP Organization?

Let me clarify one thing here, a “value added” process can be any process in a company.  In one company or environment a process may be a commodity process, however in another company, or industry, that same process may be a value added process.  The test for a “value added” process is whether or not it adds to your business marketplace competitive advantage.  That generally means it has to reduce cost or increase revenue in more than a minimal way.  As an illustration ask yourself, if you significantly increase your margins on a slow moving, outdated, low volume product or service is it worth a huge amount of time and effort?  Was the investment worth it?

Management’s primary responsibilities are to increase revenue, reduce cost, and improve margins

A value added business process will generally have some type of reporting requirement attached to it.  Some way to measure its performance because the process is critical to the organization’s mission.  If you have developed KPI’s, goals, metrics, or reports for a particular portion of your business processing you can be sure it is a good candidate for special attention as a “value added” process (see Why Indexed KPIs are Critical for Business Performance and Success and Using Key Performance Indicators for Building a Strategy Focused Organization).

What are Commodity Processes in the SAP Organization?

In most companies “commodity” processes would include purchasing, warehousing, inventory, distribution, or other routine processes.  Commodity processes and those business functions that do not have a direct impact on your competitive position.  If you are a third-party logistics provider then your competitive processes would include warehousing and distribution.  It is the core of your business and what you do.  However in other businesses those would be commodity processes.  If you are a consumer products company then sales and marketing processes would be value added where purchasing and inventory would be more commodity processes.

Worse still, in recent years IT has been seen as a “commodity” resource to be outsourced.  As IT and technology functions have become more and more focused on cutting costs and shaving pennies from a few process areas they are finding smaller and smaller returns at more and more cost.  As new technology is rolled out and it stabilizes the business and senior management see IT as more and more of an expensive cost center with functions that can be performed elsewhere at a lower cost.  IT organizations everywhere must begin to aggressively focus on business integration and value realization or become prey to outsourcing themselves (see IT Outsourcing, Off Shore Support, Cost Cutting and IT Department Changes).

SAP Software Best Business Practice Processes

While I have long advocated for business process engineering rather than software engineering there are times when custom development is justified.  The key to understanding when you might choose one approach or the other is related to whether a process (or sub-process) is a “commodity” process or a “value added” process.

Considering cost, revenue, and margins separated from marketplace competitiveness is misplaced.  Unless there is some significant competitive advantage or directly aligned business driver then only standard functionality should be used.

When you consider your SAP software investment it would provide the greatest business benefit to pay special attention to value added processes. Do not waste time or development effort on commodity processes.  Spend the time, effort, and money on change management for commodity processes because after the initial change cost ongoing Total Cost of Ownership (TCO) for these SAP processes will be the least expensive (see Where do you Start with SAP Return on Investment or SAP ROI?).  Regression testing, patches, fixes, new functionality, and all of the other things you do with SAP business applications will be easier and less expensive for the commodity processes.




Popular Searches:


  • sap custom development
  • sap custom development program

Related Posts:

SAP and Waste Management Finally Settle

May 12th, 2010 by

lost cashAfter a contentious battle that started brewing in March of 2008 SAP and Waste Management have reached a settlement agreement.  While the details are undisclosed, it appears that the whole issue was becoming so expensive to litigate that it was probably more cost effective to move on.

In a CIO article published on April 9, 2009, SAP had 25 – 30 contract attorneys working on the litigation and it had cost them millions.  Over and above that SAP also claimed that their legal discovery process had also cost over a million dollars as well [FN1].   That was just over a year ago. 

There are additional interesting twists and turns in this saga and while I am not claiming SAP is completely innocent there are certainly lessons to be learned.  For example, one writer points out that Waste Management’s leadership was terminated for “agressive” accounting practices, and then replaced, and shortly afterward the SAP ERP implementation was started.  It would certainly be reasonable to assume that that new management was not familiar enough with the company or its employees to find the right people to make the right decisions.

Waste Management was a company in crisis. SEC Administrative Proceeding No. 3-10513 had found the following: “As early as 1988, members of Andersen’s audit engagement tram recognized that Waste Management employed ‘aggressive’ accounting practices to enhance its earnings.” In the brouhaha that followed, Waste Management’s board fired the company’s management.

Waste Management’s executive suite attained their current positions in 2004. As such, it seems that the company had a lot on its plate at once: overcoming an crisis, appointing new leadership, and launching a major ERP project…

If SAP’s software is indeed a “complete failure,” Waste Management’s executives might well have been asleep at the wheel; no one should pay $100 million and wait two years to find out they’ve bought a defective product. [FN2]

The normal course of litigation over the failed SAP implementation had both parties making claims and pointing fingers.  There were the claims, and the counterclaims, and the back and forth, and the armies of lawyers, and the thousands of pages of court filings, and the millions spent by both sides on the litigation.  It was time for this to finally end.

Waste Management claimed in its lawsuit that they “wanted an ERP package that could meet its business requirements without large amounts of custom development…” They also claimed “SAP used a ‘fake’ product demonstration” and “SAP’s technical team had ‘recommended that SAP deliver to Waste Management a later version of the software than the version SAP in fact delivered’.” They also claimed SAP knew the software was “unstable and lacking key functionality…” [FN3]

SAP claimed in its legal counterclaims that “Waste Management didn’t ‘timely and accurately define its business requirements’ nor provide ‘sufficient, knowledgeable, decision-empowered users and managers’ to work on the project.” [FN3]

SAP Implementation Failure Lesson Learned

First, as I have often noted, senior management support is critical for success.  However their support is not enough, what the Waste Management lawsuit points out is that risk management (risk identification and risk mitigation) are critical components of an SAP project.

Too often we hear about the “success factors” of an SAP or large ERP project.  But behind those success factors is the risk if those factors are lacking.  In this case it seems entirely reasonable, and plausible, that Waste Management did not provide key, timely information or key decision-makers as SAP had said.  However, I also find some of Waste Mangement’s other claims they made in later pleadings that the SAP sales force had a strong hand in creating the problem because the sales person was concerned about getting their million dollar commission. 

So, while I do not put a lot of store in serious application gaps or problems, I do give some credence to their claims about the nastier side of business.  The acceptance of sales scams and the failure of SAP to adequately assess and then mitigate the implementation risks.  The idea that the company did not provide good resources, or that those resources would not make decisions is likely valid but those are known risks that should have been raised to the steering committee.  In the end, this lawsuit should have never happened.

[FN1]  SAP: We’ve Spent Millions So Far on Waste Management Suit.  CIO.com from IDG Press. http://www.cio.com/article/488866/SAP_We_ve_Spent_Millions_So_Far_on_Waste_Management_Suit (retrieved 5/11/2010).

[FN2] SAP sued by Waste Management, March 27, 2008.  http://itknowledgeexchange.techtarget.com/sap-watch/sap-sued-by-waste-management/ (retrieved 5/11/2010)

[FN3] [FN3]  SAP, Waste Management settle lawsuit.  Business Week. May 3, 2010. http://www.businessweek.com/idg/2010-05-03/sap-waste-management-settle-lawsuit.html (retrieved 5/11/2010)

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 http://www.sap.com and search for “Solution Composer” (or use this link http://www.sap.com/solutions/businessmaps/composer – 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: