Skip to Content

The most important message of SAPPHIRE 2015: GO BACK TO STANDARD

As SAPPHIRE starts in Orlando Tomorrow, we, customers and partners, will be bombarded with information about S4/HANA. It is clear it is dead center in the SAP strategy for the next years.

The value of a renewed Business Suite will become clearer and cleared the more we hear about Simple Finance and now Simple Logistics. The roadmap looks very exciting with Fiori apps covering great scope and with the upcoming of Business Suite merge (Different components of the business suite, like CRM and SCM will now merge back with ERP to form a single system).

This transformation is still in its early stages. Financials are far ahead while logistics is coming soon. The roadmap for the “repatriation” of external business suite functions back to the ERP Core is just starting. I foresee a roadmap of 3-5 yrs until we see a complete fusion.

But what is clear is that SAP has addressed 2 of its most important issues: Simplification of SAP footprint AND User-Interface. We will soon see customers running ERP on HANA (S4/HANA) with complete business suite functions like Global ATP and eWM back in the core ERP. No more parallel SCM and/or CRM landscapes. No data replication. Shorter implementation, lower TCO.

So, all this is great, but there is a catch: Current SAP customers looking at jumping into S4/HANA need to revise their current SAP solution and consider return (as much as possible) back to standard functionality.

Customer have been running SAP for many years (some for decades) so they built on the Business Suite for 2 reasons: Either implement something that was not available at the time (early customers) or to implement customer specific requirements.

What we see more clearly now than before, is that the price to implement and maintain these customer “customizations” is much higher than just the implementation development hours. It may hinder adoption of future functionality. This is exactly what is happening now. Here are 2 major examples:

  1. Custom code – Customers often support thousands of custom built programs. Migrating to ERP on HANA requires a revision of this code so it can run properly (not talking about performance here, some DB practices differ and bad ABAP code of today will NOT run correctly on HANA. They NEED fixing)
  2. The more custom code and advanced configuration, the farther apart a customer will be from adopting 2 of the most important values of the S4HANA proposition. Guided Configuration and Standard Fiori apps.

So, now that it is more evident than ever that it pays to adopt standard practices and reduce customization to the max, isn’t it time to adopt SAP pace of innovation and stop trying to build IT solutions ourselves? Wasn’t THAT the original proposition of buying an ERP software in the first place?

You must be Logged on to comment or reply to a post.
  • Hi Leo,

    The obvious other angle you could take in parallel to above is architect, design and nurture your custom code if it is really required.  For example, I’ve heard SAP pushing that in the interim you may want to develop your own Fiori apps for areas without current pans for renew; and because it is more about processes and role definitions, that should be fine in the long run for your business.

    To illustrate further, in a recent example (1 of many similar examples), working with a customer, we completely re-did the expected standard process for EH&S Incident Management to make it usable (which is almost ridiculously complex for your average manager who just wants to manage an incident, get some activities assigned, and close out the incident successfully). This is a much higher value proposition than sticking to standard where it was not being used. 

    Plus I’d be very surprised if anything I’ve been a part of in the past would ever have an issue running on HANA (including custom billing engines) – though there would be plenty of opportunities to leverage HANA for even more efficiency in some places (e.g. Use of fuzzy search where previously a secondary table may have been required to do Google like searches).

    That said, We’ve all seen solutions built without thinking about the database design and real world processes where some people think the solution for problems that arise is to buy HANA, more app servers, more memory; rather than realising they should not have build this custom solution in the first place, or at least in the way they built it.

    But as I always say, and to reinforce your statement – use standard by default, but don’t be afraid to build a well integrated and well designed custom piece if absolutely required, which typically, never has issues during upgrades – including to early versions of S/4 I imagine (well at least until your company purchases the version where you can’t modify the ABAP!).



    • Yes. Completely Agree. There will ALWAYS be a place for custom code. I just challenge the need in most cases. Customers should approach custom development very carefully, weighing in all the real lifecycle costs and most importantly, leveraging standard functionality to the most. (not reinventing the wheel or creating something that doesn’t adhere to the SAP logic).
      if well thought out, conceived and coded, abap (as any other language) can be timeless…

      Hope to see you here!

  • I agree completely but at the at same-time I remember hearing that SD was nothing more than a “giant user exit” among other things during many ERP implementation.  The open SAP course on S/4 HANA made it clear that as we migrate(exchange) from the classic ERP modules to new S/4 versions that we will need to review these extensions/code.    I have also heard that the “cloud” version of S/4 will be more “locked down” than on-premise(you can’t cheat, can only extend in certain fashion), but perhaps you can find out the differences for us 🙂 .

    In many ways we are coming back to what was preached(but not practiced) when R/3 was introduced was to use the standard processes.  It’s going to be interesting to see how this shakes out.

    Take care,


    • Yes . you are right. Big change in approach and focus.
      YES the public solution S4HANA will be very locked down. I am trying to play with it and I will share what I find. But again, public solution is cloud and is multi tenancy. So cross client changes (or anything deeper than simple) will most likely not be allowed.

      Are you in Orlando this week?


  • I’m looking forward to seeing SAP and the customers refocus on ERP.  I’ve never liked how what was once a single product turned into a suite approach.  Why is all of the shopping cart and vendor analysis now down in SRM?  Why shouldn’t it be in ERP? 

    This is a road that other software companies have gone down as well but I’m enjoying watching the pendulum swing back to ERP.  Though in SAP’s defense, the industry kind of wanted all of the big software vendors to do this.  The pendulum is constantly swinging between best-of-breed and one-system-to-rule-them-all.

  • Leonardo, nice post! Thanks

    What do you think about existing licenses with significant core of custom codes? is the new release able to perform in high level for sFIN, sLOG…?

    I am wondering countries which have lots of localization deltas like Brazil and custom codes are searching for old views.

    • We have to wait and see. It will be a case by case thing (IMHO).

      We cannot predict how well custom code will behave cause , as you know, quality is all over the place. Bad custom code is, well, bad code. 😉

      There are cases that it may run slow, and some cases where the results will be wrong (read about bad practices in implicit query sorting in old DB…)

      As for “looking for old views”, SAP is trying the approach of replacing redundant tables by views. This way, code still runs.

      Lets wait ans see for SLOG