back to article You can forget your fancy ERP customisations because that's not how it works in the cloud, SAP's Oliver Betz tells users

SAP customers making the jump to cloud will have to adopt standardised processes and drop customisations, according to a senior veep. The German software business has already made the brave move of telling investors it was slashing revenue expectations to buy itself time to "accelerate the technical migration of our customers …

  1. Lusty

    Not wrong

    He's completely right, this is a great move for many reasons. On the other hand, there are going to be a lot of consultants out there who will no longer have multi-year SAP projects. Will they go along quietly, or will they start to recommend other, more flexible, solutions? SAP are probably big enough to pull this off, but it's still a very brave move

    1. big_D Silver badge

      Re: Not wrong

      If you have spent millions tailoring SAP to your business, are you really going to invest more millions to undo everything you've just done, in order to not run your business the way you want?

      1. Tom 7 Silver badge

        Re: Not wrong

        If you have spent millions having SAP consultants obfuscating in SAP so your business is no longer in your control....

    2. Anonymous Coward
      Anonymous Coward

      Re: Not wrong

      "He's completely right,"

      Which "he"? Admittedly I worked with SAP long ago so things might of changed but, when I read that a SAP rep stated: "... requires standardisation which needs to happen on the customer side" ... I can't help to think that there's no mirrors at SAP (that's as polite as I can put that).

      I despise this "Lease our login" style "cloud" paradigm, but at the same time this statement is kind of off the mark: "Once you move to the cloud, you lose that option... ... you loose that option always when you choose convenience for lock-in, this is even true in OSS unless you want to rewrite a butt load of code. I'm not defending this crappy cloud paradigm in any way, but I think it would help the people who are worried about lock-in to understand that the real difference isn't ownership but accessibility (and a few more things).

    3. Anonymous Coward
      Anonymous Coward

      Yes wrong

      The only reason SAP was ever made to function at most of the places I have seen it deployed was those customizations. The statement they are making isn't bold, it's folly, as tailor YOUR business to THEIR software isn't going to work for many of their existing customers.

      SAP's sales and business model has pretty much been to overpromise in the solutions phase, deliver a broken system after the non-refundable licenses were paid for, and then send in an army of overpaid consultants to "fix" it with customizations ensuring the project is late and badly overbudget.

      This strategy risks shedding all customers that aren't in industries following a cookie cutter set of use cases, or having to bolt a whole external system on the outside and probably run two GUIs as well. Users always love that. Plus retraining.

      No thanks, noping that one

      1. Cliffwilliams44 Bronze badge

        Re: Yes wrong

        This is different for any other ERP system? No, they are all the same. Unless you run a very vanilla business or your ERP is specifically designed for your industry, customization is required. I work in heavy construction and we have now shoehorned JD Edwards into our business, replacing a construction specific ERP (Yes that was old and inadequate). JDE (in the cloud) just does not work for our business so we have all these external tools to make it work. I believe this is what most of these companies will do. Bolt on all these external function to massage data and then push it back into SAP. This will reduce their licensing and consultant costs while increasing their peoples work load.

        It was funny, the mantra during the conversion was "No more Excel spreadsheets!" Now we have 10 times more that we used to!

  2. AMBxx Silver badge

    Time machine?

    Is it 1999 again?

    Give it 2-3 years and they'll introduce customisations.

    1. Anonymous Coward
      Anonymous Coward

      Re: Time machine?

      My understanding is that you are still allowed customisations... but they need to follow certain rules so they can survive version updates.

      In my experience a lot of customers bodged on customisations which didn't follow the rules so are "locked" into an old version... whereas other customers who implemented their customisations in the "correct" way were able to upgrade fairly easily.

    2. Anonymous Coward
      Anonymous Coward

      Re: Time machine?

      Yeah, how much you want to bet they made the mistake of using their own labor pool, and as a result the project is late, overbudget, and not functional enough to ship?

    3. Steve Channell

      Customisation of a poor product

      The idea that all business verticals are basically the same, so should follow the same processes seems like a good idea (especially when the likes of SAP have spent 30 on business analysis) – For Digital transformation process standardisation may well be the cheaper pattern to follow.. but that’s not the case here.

      “Customisation” here is site amendment to ABAP routines that are called by the core application, rather than an Inversion-of-Control injection of a specific interface implementation – akin to editing the error-message file for each language rather than injecting error-message handler at session start.

      What SAP is really saying is that their software wasn’t designed to be flexible enough for the cloud, virtualising the whole application stack is expensive to run and will hobble their attempts to sell new “Digital” offerings.

      Unless they’re very careful they’ll finish the decade lamenting how Open-Source ate their lunch

  3. 0laf

    Same as most other large SAAS products. One size fits no one.

    If you're going to use them (O365 being the hardest to avoid) you have to change your business processes to fit in with what the vendor has built, not the other way round.

  4. alain williams Silver badge

    Try the Open Source route

    There are Open Source ERP systems. Take a look, do they do enough of what you need ? If so: write the bits that are missing (ie customise) and move over.

    Yes: it will cost you, but it costs millions to migrate to SAP and then pay annual license fees - which costs more.

    No support ? Work with others who use your chosen ERP to your mutual benefit. Push up to github/where-ever the code that you write: others will use it (if it is any good) and fix bugs and add features - which is to your benefit.

    Some IT directors will refuse for the same reasons that they bought IBM & Microsoft.

    1. Anonymous Coward
      Anonymous Coward

      Re: Try the Open Source route

      While I'm in 0% disagreement with you, you're entire post assumes companies still want to hire humans i.e. programmers. Dude I'm not suggesting you should hire some JS scripter "kid" to build out an entire software stack for your company... but you could and that proves how far _ALL_ software languages/libraries have come in the last decade. Sadly, no matter what a company chooses this way, they still have to hire a human and that is sooooooo much a mistake.

  5. czechitout

    In my experience, everyone is on board with the "no customisations" ethos, even the business stakeholders, until on roughly day two of the implementation Sandra from accounts payable is told she has to use a link to access her report rather than receiving it as an email attachment (ever heard of data security Sandra) and suddenly this is a MUST HAVE requirement.

    Also, in my experience, every company thinks they are unique and that they have special requirements, but they're not. The number of times a company has a business process which genuinely cannot be met by configuration of the system and a simple process change, you could count on one hand.

    The whole point of SaaS is that you're not hosting the vendors application on your own infrastructure with all the cost associated with patching, updates, upgrades, resources and so on. No customisations are a small price to pay for these benefits.

    1. AMBxx Silver badge

      It's true that no company is unique. It's equally true that they're not all the same!

      1. czechitout

        They are similar enough for these SaaS solutions to met their requirements if they make some reasonable business process changes though. That's the crux.

        1. Anonymous Coward
          Anonymous Coward

          " if they make some reasonable business process changes though. "

          I.e. change their business processes to fit the software. "Reasonable" is meaningless here: *Any* change is reasonable to people selling 'one size fits no-one' -solution.

        2. Cliffwilliams44 Bronze badge

          No they are not! A manufacturer is completely different form a construction company. I know because we have a small manufacturing facility within our very large construction company. The Manufacturing company has its own ERP because our construction focused system cannot work for them. Their are many vertical businesses like this and honestly the best approach is implementing a targeted vertical solution but the bean-counters never want to pay this cost and then implement these behemoth solutions like SAP, JDE, Oracle Business System, etc and try to make them work and end up costing millions more that they should have.

      2. JimboSmith Silver badge

        I worked for a firm who had gone with one software supplier (and their all encompassing suite) where we used to have two. This lot were the king of "our way or no way" if it isn't that way already then it won't ever be. The previous pair were happy to add features if requested. It wasn't added just to your update it went to everyone. As a result we lost functions & functionality and people complained. It was only when somebody senior complained that the decision was looked at again. We kept one part of their suite and used another supplier for the other. The original decision was taken by somebody who didn't use it and didn't understand the issues.

        1. Ilsa Loving


          > The original decision was taken by somebody who didn't use it and didn't understand the issues.

          I was waiting for that line. Far too often these decisions are made by people who are completely divorced from the people who actually need to use the system. I've seen it repeatedly, with predictable results each time.

    2. Nick Ryan Silver badge

      For the majority of organisations the majority of their processes are fairly standard and can be bundled into a "one size fits all" approach that the purveyors of forced obsolence and subscriptions for this like.

      Unfortunately, the majority of organisations have the odd existing, and often critical, business process that is non-standard, or at best are industry specific. These are the sticking points for the blinkered "push it to the cloud and hope it works" approaches. The old 90/10 rule.

    3. Doctor Syntax Silver badge

      "Also, in my experience, every company thinks they are unique and that they have special requirements, but they're not."

      That's your experience. Others have other experiences.

      I had a client in logistics, mostly print logistics and, true enough, that cold be run on an ordinary ERP system. But they also had a few outstations doing reprographics and it turned out that actual print management had a quite different approach. They had a different package just for those. Moved to another client, also in print, and they had a separate print-industry package, basically similar in scope to the previous client but from a different vendor.

      OK, so the print job management task is fairly standardised, just different to ordinary order processing/warehousing etc. but still able to be served by standard packages, just don't expect your ERP approach to work without a lot of changes.

      Moral 1: there may be scope for ERP packages but their nature can vary between

      But client 1 had a contract which required custom printing for which client 2 was sub-contracted. To get the required data in from the customer and then from 1 to 2 required a certain amount of customisation of the ERP system, some from the vendor, some from me. And when the data got to client 2 it was handled by entirely custom software. In fact at client 2 apart from what was, essentially front office functions handled b the bought in package all the production S/W was custom. And none of the custom production print S/W would have been in the least applicable to the ice cream factory gig...

      Moral 2: production control is likely to be custom.

      1. AMBxx Silver badge


        I work in all sorts of vertical markets. At the moment, care, tool hire, import/export, manufacturing, schools. Each of those has it's own software for 'process management', normally interfacing with an accounts package in some way.

        Much more sensible than trying to cram everything into one huge ERP system.

    4. Anonymous Coward
      Anonymous Coward

      Legal extorsion, no more, no less.

      "The whole point of SaaS is that you're not hosting the vendors application on your own infrastructure with all the cost associated with patching, updates, upgrades, resources and so on. No customisations are a small price to pay for these benefits."

      SaaS has exactly one reason to exist: Iron grip vendor lock in and an opportunity to squeeze every penny from "client", aka the victim, budget. Legal extorsion, literally.

      It hasn't and never has had any other function. Once you don't have your own infrastructure there's literally no limits how much "service provider" can, and will, extort from you.

      What are you going to do, shut down whole company or what?

    5. Anonymous Coward
      Anonymous Coward

      "has to use a link to access her report rather than receiving it as an email attachment (ever heard of data security Sandra)"

      A link pointing to some server in the USA with every TLA agency in EU, UK and USA spying on the line. Really, ever heard of data security?

      Company internal email is more secure than that.

  6. CujoDeSoque

    It's all a big circle.

    Many years back (early to mid 90s) SAP was telling new customers that the brand spanking new R/3 product required businesses to mold their processes to the software. There were a bunch of self-serving statements about how SAP has the best consultants and therefore the best processes. That quickly went away. (I'm not going to look it up but feel free to do so if you doubt me.) To me it was a wonderful proclamation. A pity they didn't stick to it. Instead they did pretty much a complete 180-degree turnabout on that that was ABSOLUTELY-NOT-DRIVEN-BY-CONSULTING-FEES-DAMMIT.

    Will this policy go away as well? I have my doubts. But there's already a sunk cost in existing customizations. R/3 is no longer a "simple" ERP system. That base system has all sorts of systems dangling from it such as Solution Damager, GRC, APO, CRM and the like. There's also the third party software that SAP hasn't already bought out.

    It's also a bit short sighted to claim this is going to allow their compulsory upgrades. I'll just leave a simple example of this, there are many others.

    What happens if you're using a third party software that would require upgrade as well and it's not ready or certified?

    I'm sure SAP has a team of very expensive consultants it can supply or subcontract to you. And then we're back to a "bring your own business processes" model again.


    1. CujoDeSoque

      Re: It's all a big circle.

      Silly me! I just recalled the buzzword.

      They called it BPR - Business Process Re-engineering. That got the C-level to shell out bucks on the very expensive consultants and encourage the underpaid and over-talented people in the company to leave.

      HR where I worked at the time (1995) came out and said they wouldn't make salaries competitive since the SAP "boom" would only last a few years. Predictably they lost at least 75% of the best talent in the next two years. My department had a 200% turnover in that two years.

      1. Anonymous Coward
        Anonymous Coward

        Re: It's all a big circle.

        I remember those BPR contractors. They were making over $120/hour in 1996 and we all knew it because the director sent out an unredacted spreadsheet...

  7. Doctor Syntax Silver badge
    IT Angle

    Experiences with two small businesses

    Years ago I had a client who owned a couple of engineers supply companies. Each of the businesses had its own on premises system, fairly standard for the time: an Intel-based tower running SCO and a mass of serial connections to terminals and printers. Everything self-contained.

    A few weeks ago I needed to buy something from a similar but probably smaller business. We've moved forward so there was a web-site but some of the more specialised products weren't on the site so I had to ring for what I needed. There was considerable disgruntlement at the other end of the phone His server wasn't on-prem like my old client's - probably a rented server or SaaS somewhere - and his flaky comms had just gone down so he had to ring back to get the order put through.

    What advances have a couple of decades brought in terms of system availability?

    1. Anonymous Coward
      Anonymous Coward

      Re: Experiences with two small businesses

      Stability is about process, procedure, and testing more than the tools. That said, mess with a robust and stable system at your peril, but people are building equivalently robust systems using cloud parts all the time. I dealt with a factory that made soap products years ago, and because all there machines had a serial controller, fighting to replace all the old ANSI interfaces didn't make much sense, we just got them on newer machines instead of the old terminals at the time.

      Hybrid cloud with onsite server to fail down to might help those that are in production and don't want to idle the floor if the external network is down though.

      1. Anonymous Coward
        Anonymous Coward

        Re: Experiences with two small businesses

        " people are building equivalently robust systems using cloud parts all the time."

        That's BS and you know it. Or you should know it. You have absolutely zero power over cloud provider, so it runs on "best effort" no matter how much money you pour into it. That's how they sell it cheap.

        And *when* it breaks, there's absolutely not a thing you can do, except wait and pray. AWS s3 bucket is either down or unreachable on weekly basis for one of our clients. And the problem is not in our end: You don't even get what you pay for: That exists only on paper.

        Despite having a "dedicated" connection from ISP and AWS.

        So it's lost a) every time it's actually down, b) every time it's cut out of network and c) every time your ISP/back hoe operator has managed to cut you out of network.

        While none of those three has any effect on local data centre and only one of the three has effects on the services you can show to world.

      2. Nick Ryan Silver badge

        Re: Experiences with two small businesses

        Hybrid cloud with onsite server to fail down to might help those that are in production and don't want to idle the floor if the external network is down though.

        This is the aspect that many consultant-lemmings fail to see... use the technology appropriately, not just because it's a current bullshit bingo buzzword top term. By all means move low priority processes and external end point based services online to be hosted on someone else's computers as this can make a lot of sense, although there is usually little in the way of real cost savings. For others, such as business critical databases and/or local processes that need to be available locally it's often nothing but ridiculous to push these online to be operated on someone else's computers and if it weren't for vendor price gouging on non-hosted licenses there would be no question about cost savings through keeping most such systems local.

  8. spireite Silver badge

    Dropping your customisations...

    I've never quite understood what the appeal is for cloud in these instances.

    The caveats of moving to the cloud is obscured by comments such as 'We have an easy workaround'.

    What it fails to appreciate is that even if a company is happy to 'standardise' and move away from the customisations on paper, in reality there is always some other system that is reliable on the customisation - not a user.... and inevitably that is never discovered until a long way in.

    As a result, the company then has to chuck money at it, to build some 'reverse engineering' portal to facilitate an 'on the fly customisation' for the other system(s)

    1. Anonymous Coward
      Anonymous Coward

      Re: Dropping your customisations...

      "I've never quite understood what the appeal is for cloud in these instances."

      Beancounters see only the (low) list price. That's the appeal. To everyone else it's someone else's computer you have 0 power over: When it's down, it's down as long as the owner wants. Too bad.

      That price being absolute BS, and imaginary, isn't changing *anything* once beancounters have decided that "the cloud", i.e. someone else's computer, is the way to go.

      It's also a major vendor lock in, but beancounters do not understand complicated matters like that.

      SAP here is going to "We run this on mainframe, it's cheapest for us *and* clients have no way of escape as *we hold their data as hostage*".

      Really, who is stupid enough to run (major) company financials somewhere outside their own computers?

      SAP can steal & resell literally *everything* from their own servers and there's nothing you can do to stop that. Security and reliability down to drain and no local backups either for you so no disaster recovery either. When SAP goes down, so do you.

      Oh, you are competing with another SAP client? They'll sell your offers to the highest bidder (competitors of yours) in a heartbeat. More profit to them.

  9. Maelstorm Bronze badge

    What if the customer's won't migrate? What are they going to do then? AFAIK, they cannot force the customer to migrate from their own hardware to the cloud. I agree that the cloud's greatest strength is that you don't need to host applications on premise...but that's also it's greatest weakness. What if there's an internet outage, or the cloud goes down? At least with on-premise servers, you can still get work done. Case in point: Microsoft Office 360. They have had a couple of high profile outages in recent weeks.

    Then there's the security issues as well. If something get's put in the cloud, there is no guarantee that it will be secured. Look at all the reports of unsecured databases being discovered in the cloud. Then there is another exploit source: SAP themselves. If people think that SAP won't look at the customizations that their clients have made, think again. They will look at each one, evaluate it, and then incorporate it into their offerings to make money on your code. Furthermore, you will be prohibited from using your own customizations once it conflicts with an offering. I haven't checked, but I'm quite sure there is a clause in the license that allows them to do this.

    SAP is an example of a company that has really outlived their usefulness and has become a money pit of software vendors. It's throwing good money after bad. No amount of cash is going to fix the inherent problems with their software either. After a certain point, you will have to cut your losses and run far away.

  10. Dwarf Silver badge

    Tenant isolation ?

    Does this mean that its one great big shared platform with little in the way of tenant isolation.

    If the tenants are isolated then there should be absolutely no reason that per customer customisations can't be done.

    Without that, their problem is going to be even more difficult to convince customers to migrate.

    1. Duncan Macdonald

      Re: Tenant isolation ?

      UNFORTUNATELY the SAP snake-oil salesmen do not need to convince the technical people - they convince people on the board who are sure that they know all about computers because they can watch YouTube on one!!!

      With GDPR it might well be illegal for a company to have its data in SAP's cloud offering unless SAP can ensure personal data can not be inadvertently revealed. (If the SAP cloud is hosted on any of the US suppliers (eg AWS) then the data can always be accessed by US agencies because of the US CLOUD Act,)

      Icon for what should happen to SAP ==============>

    2. James R Grinter

      Re: Tenant isolation ?

      At the end of the day, it’s the “configuration vs. customisation” debate. It’s the same thing that gets you stuck on an old release, unable to upgrade because you’ve tweaked it up the wazoo and no one who knows how it works is still working for you (or, those that are, know better than to want to get involved).

      ServiceNow, with their SaaS workflow, were already having that challenge with customers over 10 years ago, and as far as I know (I’m no longer working in that orbit) they’ve addressed it by being more restrictive in what you can change/how you can change their stuff.

  11. a_yank_lurker Silver badge

    Check Your Accounts

    When I hear a 'vendor' (shakedown artist really) say you have to do something because... I wonder how big a hit my wallet will take.

    Also, every business has some unique quirks that means customization of commercial software is often a requirement to fit the business' needs. The idiotic assumption all business in a sector have the exact same requirements is laughable to anyone who has a pair of eyes and a semi-functioning brain.

  12. Potemkine! Silver badge

    That's pure BS

    Forcing companies to change their processes because of a software is totally idiot, can break their business model, put their production line on its knees, make the work of Quality, Servicing, Logistics services a hassle. That's stupid.

    I pity the companies which would walk this way because the beancounters say so.

  13. Sean House

    No such thing as a free lunch...

    You want customized software, you need a team of in-house programmers in your Data Center. You want “cheap” software as a service, you get what the cloud provider offers. Why is that difficult to understand? I have worked in IT and SAP implementation for decades only to see executives shutting down IT departments, “off shoring” work to the lowest wage (but not greatest value) provider, and generally “racing to zero”.

    Oh, and IMHO going “to the cloud” is like owing money to the mafia: You had a bad financial year and want to defer IT spending... “shut up and pay me my fees”. You don’t like that? “Who cares, shut up and pay me my fees”.

    As long as corporate executives focus on short term ROI versus strategic investment including investment in differentiating IT solutions, ERP will continue down the commodity, homogeneous solution path.

  14. sitta_europea

    If everybody has the same software, when it goes down everybody will stop work at once so we won't be inconvenienced by having to keep working because nobody else will be able to do anything either so we can all go down the pub.

    If all the data has gone forever (it was all backed up in the cloud too) we may as well stay there.

  15. computing

    Some reasons to go to cloud go up in smoke

    You're right of course.

    But, "people are building equivalently robust systems using cloud parts all the time" is rare. Yes, people build, people shift, and it's mighty convenient -- but people downgrade.

    Many large customers try shift their on-prem data center to the cloud looking for savings in these areas:

    1 - data center infrastructure (airconditioning, fire-suppression, UPS, backup generation)

    2 - manpower for infrastructure management

    3 - money in general (because the cloud supposedly is more efficient)

    But for (1), the cloud provider has near-equivalent expenses; (2) was never that high anyway; and as for (3) the cloud provider wants those juicy profits all for themselves!

    So once the honeymoon is over, the corner-cutting begins:

    - "Do you need premium SSD? What not standard SDD?

    - "Why use SSD at all for non-prod servers?

    - "Why so many non-prod servers? So much disk? So much memory?

    - "Can you switch DEV/TEST off at night and boot in the morning?

    - "Multi-zone redundancy?? But the cloud is so reliable!

    Then come the cloud VMs crashing without notice. And 'live migration', an Azure specialty -- a VM freezes as it's migrated to different hardware. Too bad if you had clustering software with a heartbeat detector sensitive to timing delays.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like

Biting the hand that feeds IT © 1998–2022