You can forget your fancy ERP customisations because that's not how it works in the cloud, SAP's Oliver Betz tells users
- Reference: 1604921131
- News link: https://www.theregister.co.uk/2020/11/09/erp_cloud_sap_ukisug/
- Source link:
The German software business has already made the brave move of [1]telling investors it was slashing revenue expectations to buy itself time to "accelerate the technical migration of our customers' most important business applications to the cloud," [2]as CEO Christian Klein put it .
But for many customers, it will be anything but a simple technical migration. Those who have made modifications to the software to fit their business will be in for a rude awakening as they consider the leap to the cloud, where standard – if configurable – systems are the name of the game.
Speaking to a UK and Ireland SAP User Group (UKISUG) webinar last week, Oliver Betz, SVP head of product management for SAP S/4HANA, said: "I'm a true believer in the cloud as the future state-of-the-art model. However, that requires standardisation which needs to happen on the customer side: they have to agree on standardised processes. You cannot have these modifications that you had in the on-premises world, that's not how the cloud works. You will go in a direction where you have quarterly or at least twice per year releases, which you have to absorb and agree to."
He likened these updates to the ones dished out to Microsoft Office customers, which users cannot realistically avoid.
While adopting standardised processes may make sense on a whiteboard, few envy the CIO who has to tell business units to change the way they work because a software upgrade says so.
But SAP is also promising to make its upgrades easier to consume, avoiding the daunting mega-projects with [3]a more modular approach to new solutions to give customers flexibility in how they adopt the software.
And in the medium term, the enterprise software giant says it will give customers choice over remaining on-premises, lifting to the cloud only as an infrastructure choice, or moving to a cloud subscription model.
Clarifying questions over whether customers could continue to be able to use on-premises licences in the cloud, a SAP spokesman said customers could retain licences and continue to pay maintenance, transferring the software to a managed service (IaaS) that customers purchase separately, a so-called "Bring Your Own License" to a partner-hosted service.
Alternatively, the user could terminate licence and maintenance for existing on-premises software and follow SAP's "Cloud Extension Policy", purchasing cloud software subscriptions instead. That option also terminates use rights of the on-premises licence contract and reduces the maintenance base and fees, the spokesman said.
While cloud is the undeniable direction of travel, SAP customers were also wary of avoiding lock-in with their cloud provider, said R "Ray" Wang, principal analyst and founder of Constellation Research, who was also on the UKISUG call.
After figuring out that hope is not a strategy, SAP has a new one: We're gonna shift on-prem customers to the cloud! [4]READ MORE
"We're starting to see a fear of vendor lock-in in the cloud because you don't own the software so you can't say 'I'm not going to pay for maintenance' and keep holding on to the software for as long as you own that product. Once you move to the cloud, you lose that option. I never thought I'd hear that from customers. But some of the early cloud adopters for some types of software are saying to themselves, 'maybe we should own this and ride it out to the very end'."
However, customers will have to bite the bullet one way or the other [5]as SAP sees its future in cloud/subscription software .
On-premises is "not sustainable in the long run unless you're going to build your own ERP system [6]as Tesla did . Not every company is going to be a Tesla," Wang said. ®
Get our [7]Tech Resources
[1] https://www.theregister.com/2020/10/26/sap_covid_crash/
[2] https://www.theregister.com/2020/10/28/sap_new_strategy/
[3] https://www.theregister.com/2020/06/29/bite_sized_sap/
[4] https://www.theregister.com/2020/10/28/sap_new_strategy/
[5] https://www.theregister.com/2020/10/28/sap_new_strategy/
[6] https://techcrunch.com/2013/10/31/being-a-cio-at-tesla-motors-a-startup-that-builds-cars-and-its-own-it
[7] https://whitepapers.theregister.com/
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?
Re: Not wrong
If you have spent millions having SAP consultants obfuscating in SAP so your business is no longer in your control....
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).
Time machine?
Is it 1999 again?
Give it 2-3 years and they'll introduce customisations.
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.
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.
Try the Open Source route
There are [1]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] https://opensource.com/tools/enterprise-resource-planning
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.
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.
It's true that no company is unique. It's equally true that they're not all the same!
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.
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.
"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.
Yep.
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.
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.
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?
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)
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