Driving Value by Sticking with Standard SAP Functionality

Standard Functionality vs. Custom

Okay, maybe it’s not as easy as installing off the shelf software, but when you choose to stick to standard SAP functionality you can lower your total cost of ownership while reducing your implementation timeline.

In years working on SAP implementations, we have been fortunate enough to be on projects at both ends of the spectrum. We worked with an organization that understood the true value of sticking to standard SAP (or fit to standard). It was a mantra driven top down by business leaders, resulting in stringent change requests for any development related to enhancements, interfaces and workflow.

In contrast, we have also worked with an organization that valued current as-is business processes above all things. The goal of this project was very much to take the functionality from their legacy systems and transpose it into an SAP environment.

We know it’s difficult to make apples to apples comparisons as all organizations operate differently, but the companies in these examples were similar in size and revenue, both had similar core business processes, but very different approaches to how they went about implementing an Enterprise System.

One took 7 months from blueprint to go live, the other one is in its 4th year and still not live. As time is money: the latter project is much more expensive than the former.

Decreasing Total Cost of Ownership

“Oh don’t worry, it’s only a few hours of development. That barely makes a dent into our budget and wont impact our timeline”.

Sound familiar?

Organizations with this mindset do not take into account the total cost of ownership when deciding to move forward with custom development objects.

These cost considerations can be similar to those one would take when purchasing a condo. There are one-time fees to purchase the asset and ongoing maintenance fees required each year after.

Development hours are typically the main factors driving this decision making process. But other things are often overlooked: Did we consider the number of hours required for functional unit testing? What about integration testing scenarios? Does this development break any existing functionality? If so we need to ensure this is regression tested.

These are some of the work items we need to consider when we try to put a number behind the effort and ultimately the initial cost of the development object.

Perhaps more important are the maintenance costs associated with the lifetime of this development object? What do we need to consider?

Upgrades

Custom RICEFW development objects (reports, interfaces, conversions, enhancements, forms, workflow) need to be accounted for every time we upgrade to the next release/version of SAP.

This means that we need to run integration test scripts for impacted functionality. Any testing defects will require time from functional and technical resources for resolution.

Many upgrades are run like implementation projects and typically we’ve seen clients use this rule of thumb, 20% of the initial development cost, to estimate the time and effort for this element of an upgrade.

Clearly the more initial development you have, the more time and effort required for an upgrade.

Maintenance

Once live in production we will need to spend time and effort to maintain custom development.

Eventually, we’ll want to implement new processes or functionality as part of continuous improvement projects.

An example of this is configuring a new item category to support third party drop ship orders. To implement this standard SAP process, we may need to make changes to custom development objects in order to account for this new item category. There may be user exits or interfaces that rely on this value to drive logic in our current solution.

This means that a series of regression test cases must be run to ensure existing functionality is not broken. As a rule of thumb, we’ve seen clients typically allocate ~10% of the initial development cost to support this ongoing maintenance.

People

Sticking to standard SAP functionality also makes going to market for resources much easier.

For example, the available resource pool of SD consultants will know how to configure the standard drop ship (3rd party order process). But they won’t know your custom billing solution.

For this reason, we also need to take into consideration the time required for resources to ramp up and learn your business and technical solution. Although one could argue this is required to onboard any resources in an organization, this will take considerably longer if you live in a highly customized environment.

Making the Right Decision

We have seen our fair share of projects that start off with the intention of using standard SAP only to fall into a laundry list of development objects.

This breakdown usually happens when SAP processes do not align with how the business operates. As implementation consultants we are in constant conversation about why we should always stick to the SAP delivered business processes as much as possible, but we will not win every battle.

In our experience, we’ve found that project teams are more likely to stick to standard SAP if we take the time to review the high level business process with decision makers in the organization.

By doing so, we are able to determine which elements of the businesses can utilize standard SAP and which processes are business critical and may need development to support. By having these decisions made ahead of blueprinting, the tone is set that we are using standard SAP for a defined set of business processes.

We recommend making these key decisions early in the project lifecycle – during a preplanning phase. This will further reinforce that standard SAP is a priority being driven top-down by the leadership team on the project and within the organization. We’ve seen the most success keeping to standard SAP when this is done.

Two questions really help us determine whether or not we need to spend time and effort diverging from standard SAP:

1. Does the business process/functionality provide us with a competitive advantage in the market place?
2. If we do not have this functionality as it stands today, will we negatively impact our customers?

If the answer is no to both these questions, we should really be asking why we can’t use standard SAP.