Get ready to make processes fit the software when shifting to SAP's cloud, users told SAP customers need to change the way they operate to shift their ERP systems to the cloud, according to the CEO of the Americas' SAP Users' group (ASUG). Responding to the results of a joint survey between ASUG and German-speaking user group DSAG, which showed some scepticism towards SAP's lift-and-shift package, Geoff Scott …
Once upon a time.....in a land far away, there was a retailer who adopted PeopleSoft.
.....but the SENIOR people (you know....C-Level folk who know everything) decided that the standard PeopleSoft package was woefully short of retail smarts.
.....so began a million dollar project to customise PeopleSoft with all the required retail smarts. Fantastic job.....just what the doctor ordered.
.....except that for the next ten years it was impossible to apply PeopleSoft patches and upgrades. Oops!
.....then (different) SENIOR people (also C-Level folk) decided on....go on......guess! They decided on another million dollar project to implement the latest version of PeopleSoft....this time plain vanilla....no cute ideas.
Fantastic story......especially for the consultants.....a million dollar project.....then ten years trying to square the circle.....then another million dollar project.
The standard advice then (and now, it seems) was (is) this:
a) Implement STANDARD packages!
b) Adjust your business process to match!
THIS IS NOT NEWS!! How often do we need to hear the same good advice in a forty year time span??
Sometimes, when offered the option to shoot themselves in the foot, management will insist on it. Seems like a few of the other commenters have hit on that point.
That said, vanilla SAP is incapable of providing an efficient, user acceptable solution to so many industries that their(SAP's) whole sales pitch to hook an organization was often based on promising things vanilla SAP couldn't actually do. This is one of the reasons ERP rollouts have had such a high failure rate, and some of us start loading the shotguns if we see SAP reps sniffing round the server room. (like raccoons, they spread brain worms...)
That said, there is also a counter point where the weasels try to convince you change your buiness to fit their software. On occasion that is fine, and if it is a few small changes that are sticking points, being adaptable to change may be the best solution. What isn't the best solution is how often SAP tries to convince customers that hammering screws into the wall is a perfectly good alternative, as SAP has plenty of hammers, but screwdrivers won't be supported till Q1.
"Q1, as in next year?"
"No, two years from now, if is doesn't get cancelled" (with the unspoken bit that your license fees and consulting will be non-refundable in the even screwdrivers are never delivered, even though it was in the spec when the contract was agreed on)
For those of us that have had the "joy" of watching the SAP sales life cycle a few times, this will be familiar. SAP is just as incompetent in it's internal projects as it is managing yours as an external project. As a result, the "next" version arrives years late, buggy, and missing major functionality and support for customization. That won't stop SAP's marketing department branding it as the second coming, and spending a boat load convincing the boss that it's essential to move to it right away.
This is of course suicide for you and your organization, and the carnage may not end there. Failed ERP rollouts do take out c-level staff in mahogany row from time to time.
But SAP really want's to make it's numbers, pay it's dividends, and last another quarter as it sinks and fades to irrelevance. So they will say anything to convince you to buy a ticket on a sinking ship.
The problem is that business process' change. eg. Could be a new business model opportunity introduced by rule changes etc.
So I would opt for option C
C) Use vanilla SAP that can be upgraded in situ whenever. Build a front end system for users that presents data out of SAP as and when requested along with any supplementary info regarding that transaction or record from an auxiliary system. User presses send - update data held in SAP and supplementary data in auxiliary system. Use standard SAP reports where they are useful and use auxiliary system for customized stuff that doesn't fit with SAP's business process. Auxiliary system can be anything your org feels comfortable with using and will almost certainly be a damn site cheaper and quicker than customizing SAP to your orgs needs.
""The traditional on-prem, highly customised ERP solution, absolutely, positively has to give way to a more SaaS-based ERP solution," he said." ... "That's not how the cloud works,"
Which makes me think "Who is the master here?"
If I buy something from you I would expect it to fit in with my requirements not the other way round. Unless that is you are doing it for free. Then I might think about changing the way my business has developed to fit in with your agenda.
Are SAP offering something here without cost? Or can they convince you that by forcing your business processes into their straight-jacket they are doing you a favour?
Because if they are not then "Caveat emptor"
Often if your processes don't nicely fit a given solution I think either 1) You chose the wrong software 2) Your processes aren't best practice
Highly customising a solution leads to massive heartache and often ends with political arguments and a system that doesn't work. I am a SAP Consultant and the areas I see the heavy customisation also seem to be the ones that argue they are different when they aren't really and have deep seated company issues.
Of course light customisation is almost essential in any business, but if you have to heavily customise there are other issues to look at
Heavily customising SAP may lead to a system that doesn't work, but that doesn't necessarily apply to other software.
Whilst I would agree that if there's heavy customisation needed it's possible processes aren't best practice, also :
It may be far cheaper to customise software than change people
The company may be more efficient, or lower cost, from operating in that way.
It also depends how badly you want the business.
I've worked with software that became popular precisely because it could be customised to customer requirements. The customers have been happy with this software for well over a decade in a number of cases and it's created a lot of successful business.
The large downside is that it builds up a huge amount of technical debt unless your development and build systems are very well designed, and in most cases where there are an appreciable number of customers with bespoke systems, this isn't so and the technical debt is kicked down the road. This can lead to distinct differences between a more modern standardised and it's older bespoke product, that involves extra customer cost for any future changes, unless their customisation was incorporated into the base product from the start.
SAP is aiming for a losing position here. If the response to customising software is to reform business processes, my immediate response after doing so would be to look at a less proprietary and more inexpensive solution than SAP.
If a company moves from a bespoke system to a standardised one it also needs to be priced the same or lower *even if it contains extra functionality* unless that additional functionality truly gives the company a competitive advantage rather than being an infrequently used frippery.
In the long run it is probably cheaper to change people (or at least the roles they do)
The number of companies I have been in where roles are massively duplicated is unbelievable, in some places roles exist that essentially unwind what someone else has done. A good holistic strategy should prevent this which means good business practices which suggests a solution might already be available.
Even if moving to a standardised solution is more expensive it could be cheaper in the long run due to decreased technical maintenance and increased throughput (and potentially non-IT resource savings)
If you're planning for the long term and considerably growing the business I wouldn't disagree.
However, plenty of people or company founders want to move on/cash out in a shorter timescale, and that also assumes that the gains in long term planning aren't wiped out by acts of stupidity a few years down the line!
Potentially;
A) Spend vast amounts of cash & time tailoring the software to suite and hope it works.
B) Kneecapping the entire business with a wholesale procedural change and hoping it can continue to operate while everyone learns the new ropes.
At least with the first option a stop decision will usually result in no big discomfort to the daily grind* while stopping the second is stopping the business.
*something is in place and working
......because you don't have the money to write and support your own custom software!!!!
*
Apart from the benefit of saving money and employing fewer IT folk, perhaps there's some downside?
*
Of course there is! You have to make your business process match with the package!
*
Benefits: lower cost, fewer staff, faster implementation. Compromises needed to achieve benefits: Of course!!
*
How hard can this be to understand?
No.
Just no.
I don't care if you think that the process is outdated or not, software should not dictate how the company is run. And no single company should be allowed to dictate to their customers how they run their business.
It's incredible to see that we are now in an age where a software maker decides how you should run your business.
Fuck off. If your software doesn't suit my way of doing things, then you are useless to me. I'm not the one who should change.
So I'm to believe that all those industrial plants using SAP need to review their production lines just so that SAP can integrate the data in the right way ?
Are you out of your fucking mind ?
I use Excel to prepare my invoices, because I've set it up so that it prints out everything I need the way I need it.
Hint : if Microsoft changes Excel so that I have to change my invoices to correspond, I'll stop using Excel.
If you have the 'right' way to do things do all your tools have to be this way?
When you pick a company car do you look at what's on the market and adjust your process for the car you're using, or must it be a 1976 Triumph Stag with 12k on the clock 'cause that is the right one?
SAP is a tool you buy off the shelf, if it's the wrong tool you can buy another or make your own.
If you make it, it'll likely not be as complex, robust or maintainable. If your inflexibility in adapting your processes to new tools is worth that much to you go ahead and spend the time and effort.
Do you see software as a tool, like vehicles or plant, well crafted and artful things at times but tools to serve a purpose, or do you see them as things in themselves which 'must' work in only the way you insist?
Suppose my company comes up with a new way of doing business which is not only better for our customers it also makes more money for us. Unfortunately we are a SAP shop. We have to persuade SAP to change their code to match our new process, in which case our competitors who are also SAP customers have a ready-made solution to do the same!
I supported SAP at a previous employer; their in-house and consultants did not customize and build products on a whim. They spent that time and capital to differentiate their services from the competitors who said it couldn’t be done. If every company is pidgeon-holed into the same result, companies can only compete on price and personality guaranteeing a race to the bottom. This is not something any C-suite is going to accept.
> the way you've operated a certain business process five years ago is not the way you want to operate it today,
I spent 50 years developing and changing bespoke software for several clients. Businesses are deliberately different in order to be competitive against other businesses in the same market. Not only do they want to be different from others in the market, they want to be different than what they were last year.
The business environment changes: eg banks no longer take cheques, the processes need to adjust, the software needs to follow the processes, or indeed, enforce the changes that have been determined by the management.
On the other hand the business will often operate in spite of the laid down procedures.
to many companies have a very poor understanding of what makes them unique.
so they customise everything because they are different/special
certainly customise to support a business process that differentiates you - but for most orgs they are *not* that special when it comes to payroll, invoicing, Hr etc etc
SAP has traditionally be targeted at that 'we are special' (for everything) view of the world and it has made them lots of $$
be interesting to see a) whether orgs can be convinced they are 90% the same as everyone else and b) once they realise that do they keep paying $$$ for SAP
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
