To be (customized) or not to be..
Customization is a way of life for most ERP implementations. Only 10% of ERP implementations report no customizations and over 25% report significant or extremely customized ERP environments
The goal is tailoring systems to business needs and sometimes build a customer-specific platform on which to standardize company-wide processes. The end results, however are anything but standardization. Driven by a need to address a hodgepodge of ad-hoc business specific requirements with country by country variation in many cases, many customers end up with a footprint that doesn’t have any resemblance to industry best practice and in many cases results in a forced reimplementation or a large expensive upgrade to a more standard solution.
ERP implementations as recently as a few years tended to focus on an aggressive approach to customization. Faced with the argument that ” current best practice only meets 80% of what we need to run the business and no immediate cost impact – it was just too easy. Rather than adapt the process to meet out of the box, it was change the box to meet the as-is process.
It was just easier to deploy resources to meet the requirements, kept organizational change management considerations to a minimum and kept the army of consultants and support staff occupied with continuous upkeep tasks that added little to drive growth but kept increasing the complexity in small steps, hence the “feed the beast” phenomenon.
A vicious cycle of growing customizations resulting in an ERP environment that becomes cost and resource prohibitive to keep current and increasingly unresponsive to the new digital demands.
- All customizations stay unless you re-implement. Rarely does IT conduct a customization study to “weed out” minimally used customizations. Over time, the customization inventory continues to grow
- All customizations need to be carried over if you upgrade. A significant portion of an upgrade costs is related to evaluating the impact of existing customizations, regression testing, user testing etc. : money, resources, time that could be spent elsewhere
- Customizations beget more customizations. Once an organization veers away from vendor provided best practice, getting back on the highway for new and improved practices get that much more difficult. Changing business conditions require new and modified customizations creating a vicious circle.
Many customer engagements have shown that only 20% of all modifications in an ERP implementation might be used and trying to determine which customizations are no longer being used is nearly impossible
While not immediately visible to the business, these costs are not confined to IT alone:
Business (or indirect) costs of customization
- Decreased competitiveness: In today’s fast changing digital world, companies must be able to continually improve business capabilities without fear of disrupting entire systems. A complex, customized system stands in the way of such confidence.
- Speed to market: Consider a consumer goods company considering a move to enhance its product offering with digital services (such as moving from a subscription to pay as you go) model . This company cannot take months and years to change a highly customized order management and billing systems when a digital-born competitor can do that in days or weeks.
- Less responsiveness from IT innovation: With continued IT focus on “maintaining the beast” and limited resources, business continues to look elsewhere for innovation further widening the chasm between business and IT
On the flip side, it is not realistic that customizations can be avoided completely. The secret sauce is to limit the customization only to those processes which are differentiating and adopt best practice process in those that are not.
A modern approach to customization is one that offers a high degree of flexibility while maintaining the integrity of the core. Developing customizations on a development platform that is tightly linked to the core application capabilities yields the same benefits as customizations yet does not disturb the integrity of the core so necessary to ensure continuous innovations get delivered at the pace of business. All new modern SaaS based applications follow this approach. This extensions and platform based approach to customization enables companies to provide an “agile edge” without disrupting the core. Companies can continue to add new capabilities that reflect their uniqueness in the marketplace without having to customize their core ERP code and lower ensuing risks and costs. A win-win in all regards!
I know the above blog is an argument for S/4 HANA in the cloud, and as such it does a very good job. I just have to put my two cents worth in however.
My company has a highly customised SAP system, and if you were to come and look at the "army" of people who maintain this you would probably ask where the rest of them were, are they all on holiday? The point I would make is that many companies do this (maintain complex custom code) in a chaotic manner, and are their own worst enemy.
I imagine different processes fall in different parts of the diagram above for different companies.
For example the "order to cash" process for my company at least should be in the top right. The standard SAP "best practice" process the standard software delivered was so cumbersome you could not in all good faith expect your order takers to have to endure it. So we "customised" it until the order entry time went down to an incredibly short time. that is what differentiates us from our competitors who use "best practice" standard SAP in this area and the customer has to stay on the phone / mobile device much longer.
"procure to pay" is somewhat the same, as is "hire to retire".
Over the years SAP has made the phrase "best practice" something of a laughing stock, trying to get companies to change their business processes in all sorts of illogical ways, because it fits the way SAP wrote the software.
Nonetheless, I wholeheartedly agree with your recommendation above to get rid of the 90% of custom code that is never used. SAP provides excellent tools to do just this.
I would just say that the 10% of custom code that is used, is being used for a reason.
I also cannot end without mis-quoting from "The Princess Bride".
Best Practice? You keep using that word. I do not think it means, what you think it means.
Cheersy Cheers
Paul
OK - I agree 100% with Paul. Where is my army of consultants, workers, people who maintain the code/system? I've worked for several large companies as well as small and medium. Only one has had an army and that one is huge. But that one is constantly changing and acquiring new businesses. The medium to small companies flex and only use extra help when it is needed on a special project.
Best business practices? For who? There are so many different companies. They sell a wide range or products that the SAP "best business practices" could cripple a company. That would be bad, very bad because then the company would just throw away their huge investment in the SAP software. So customize and keep people happy.
Redesign new business practices. YES! But only where it make sense. There are many times when it doesn't. I could list the reasons.
Now let's add to the argument by saying for S/4 HANA on the cloud is something we can customize. Oops - did I say we? I meant only SAP can customize it. And I'm sorry to say, you guys are not cheap.
So I would say a large analysis would have to be done before easily moving to the cloud just because - well just because SAP says it is the way to go. Yes, I've listened to sales pitches before. This one is one of the better ones.
As Paul says it is a good idea to try to determine what code is no longer needed and retire it. Ah if only we had that army to help us out. We don't. So we will get to it when it makes sense to do it. Let's be honest. If it isn't break, don't touch it. So I have 5000 customized programs. (That's not true) But let's say I do. If they are all reports and interface, (They aren't) then why look too closely at them. The business is getting what they want. It could be better. So that's why I take the time to read and learn what I can. I'm not the only one doing that - gasp - the business people themselves are keeping up to date, and asking for changes. Some are even very valid changes. Did I just say my company has great people working in it? Why yes, yes I did. Some do not keep up with the latest and greatest. That's OK too. That means at times we bring a proposal to them.
Oh boy - I'm getting wordy again.
Michelle
As one customer once said: "Best Practices looks solid, provides all the details and gives all the right reasons why, but i fail to see how it could make my company and employees the Best in the market if i'm behaving just like the rest of the lot".
Felt like a bucket of cold water and ice.
Best practices is indeed a valuable resource and stepping stone for business implementing S4/HANA, but they should not be a barrier or limitation, and business should not feel afraid to explore the gains and optimizations of highly customzed SAP platforms.
It is however an act of balance, how much customizing? how long would it's lifecycle be? how often will business definitions change or evolve and will i be able to keep my system aligned with said changes?
There is no simple answer, and no single path to success.
Thank you all for the helpful information provided. I believe that before proposing a development, the consultant must present how the standard process works, what are the boundaries that can be achieved with configuration and how much more effort it would possibly take by going this way. If the customer still wants to take the development/customization path, then the consultant must make sure the customer knows the pros and cons of this choice. Only then, if the customer still agrees to customize, the consultant should use abap best practices (yes, sap also provides a guide for abap developing) to make any development.