“Standardisation” is something which every company I have worked for strives for within SAP. Who can argue with this? Lower cost of maintenance, availability of standard process flows and test scripts and ready-made customizing and development all feed into an overall lower total cost of ownership (more of this later).
SAP has refined their standard offering by recognising that it is not possible to provide a “one size fits all” solution. In the old days, that meant “industry solutions”, where SAP solutions were developed along different lines for different industries – around 30 of them, including Oil & Gas, Banking, Utilities, Retail and Media. These solutions were prefixed with “IS” and so we had “IS-Oil” and “IS-Retail” for example.
Since then, the movement has been in the direction of providing pre-configured solutions around a “Model Company” approach, so as to speed up implementations. Read Eursap’s previous Blog article for More information on Model Companies for SAP.
These innovations mean that SAP has such a broad footprint in its standard offerings, that “SAP Standard” is now pretty much accepted as the same as “Gold Standard”. But is that really true?
Firstly what exactly do we mean by “SAP standard”?
SAP provides a template for configuring the system to meet business requirements. This is designed to meet the vast majority of business practices. The flexibility here is the beauty – where the existing configuration may not meet your needs, standard customising options allow you to extend the existing configuration so it meets your requirements, whilst also sticking to “SAP standard”.
Example: In sales pricing, SAP provides a standard list price condition type “PR00” with the following options available for creating prices by users:
However, basing your price on one of these three combinations only is almost always never enough for an SAP customer. Therefore SAP allows you the flexibility to extend the configuration to add your own options through configuring the pricing access sequence. Existing access sequence looks like this:
Add new option here:
New options for pricing now looks as follows for your users:
By doing this, the options for pricing are extended by using standard SAP customizing methods. This allows you to stick to the standard SAP way of doing things, but flexing the system based upon customization only – no development or coding required.
So when would you ever need to digress from standard SAP? In truth, this is the wrong question to ask. The issue here is should you amend your business practice to fit SAP standard or should you develop SAP to meet your requirements, thus diverging from SAP standard?
Total Cost of Ownership (TCO) – priority number 1
A good and honest project manager on an SAP implementation project will tell you that the ongoing TCO is one of the most important factors to consider. There are a whole myriad of ways to reduce your TCO and standardisation is a key weapon in your armoury here. I have heard many times a development justified because it is only “a few lines of code” but what this fails to take into account are the knock on impacts this might have on other areas:
• Functional and technical specification writing – every change must be documented for traceability purposes and onboarding of new analysts and developers.
• Unit testing
• User Acceptance Testing
• Regression Testing – does this adversely affect any existing processes?
• Ongoing maintenance – because the development is on top of standard SAP functionality, any amendment to standard customization may cause errors to arise. I have witnessed this countless times – one example which jumps to mind was a development in the sales orders user exit which set the item level tax classification according to the item category. The problem here was that the item category was hard coded into the development and so when a new item category was configured for a different scenario, suddenly the tax classification was not being set for that new item category. The lesson here is that non-standard development has implications for configuration.
• System upgrades – when upgrading your system, has the data object you are amending changed in any way in the new system version? If so, you would need to analyse your code to see if any amendments are required. Do not underestimate this – a regular maintenance strategy can mean ABAP code analysis is an almost constant thorn in your side.
• Training – when you take on new starters, the onboarding process will be much faster the closer you stick to standard SAP.
Before you know it, your costs around this “few lines of code” are spiralling out of control – your TCO is increasing.
Future proofing and making the best of standard innovations
Another issue to take into consideration when deciding upon the right course of action for a given requirement, is the future proofing of the system. By this I am talking about future upgrades, existing innovations and bolt-on applications.
Take my example earlier about the development of sales user exit code to update the tax classification of a sales item. If you deployed a tax engine as an embedded application within your SAP environment, then you could be running into trouble. The application could be an approved SAP partner but this does not mean it won’t fall foul of your custom development.
Furthermore, SAP are always developing their standard solution through service pack stack, enhancement packs and software releases. Deployment of a new release, SPS or EHP could also run into problems if the development changes something your custom code has already amended.
How to follow SAP Standard
There is only one way to approach an SAP implementation if you want to deploy a standardised model as much as possible. Your business processes must be up for grabs. What I mean by that is if you want a short, low cost and successful implementation, you must be ready to plough your resources in to redesigning your business processes to follow SAP standard as much as possible. This means that the Organization Change Management stream must be beefed up and ready to take on the changes which become inherent in the project.
All too often organizations try to shoehorn their existing business processes into SAP, causing long development efforts and difficult and costly projects. “It’s always been done like that”. Ever heard that on a project? Project managers must ban the use of such phrases; the standard SAP processes must be presented and the business must be willing to justify why their process demands an amendment. Bear in mind all the issues we have already been through before you agree to develop a new solution!
Your SAP development may well be very elegant and you may find that it fits your business requirements far better than standard SAP does. However, as already mentioned, that is the wrong way to look at it. Is SAP standard the same as gold standard? The answer here is probably no; at least, not all the time. As we have seen, whether you follow SAP standard or not is contingent upon lots of factors, not only whether it is the gold standard or not.
However, don’t forget that SAP is a global $27.55 billion business. Their R&D department is focused exclusively on innovations in their software. You just can’t compete with that and so at some point you will have to accept that the SAP Standard solution is more than likely the most practical, the most cost effective and in many cases, the best solution there is. As system analysts and developers, we love tinkering with things and developing new ideas and programs, but beware! It is unlikely that in the long run, you will be thanked for it.
Stay tuned for more insights on Eursap’s Blog…
Please also check out Eursap’s weekly SAP Tips!
Get in touch with Eursap – Europe’s Specialist SAP Recruitment Agency