been running as designed....
Looks like you got what you asked for, not what you wanted...
Avon is writing off a massive SAP-based order management project following a failed pilot in Canada earlier this year. The cosmetics giant, famed for its door-to-door sales reps, is writing off development and future rollout of an order management system that has cost $125m and is based on SAP ERP and CRM applications with a …
Looks like you got what you asked for, not what you wanted...
Based on what exactly? SAP has made an outright business strategy out of born to fail projects like this, counting on the tried and true revenue of management doubling down on their mistakes, and never delivering a working system.
1) Outright lie to the customer and claim that SAP can to anything, that everyone loves it, and the extortionate(and non-refundable) licensing fees will cause money to rain from the SKY.
2) When is becomes clear SAP's in house code cant deliver an acceptable user experience, have the SAP consultants suggest a 3rd part front-end that almost but not-quite meets requirement. Bill client for the new solution and changes required to meet requirements. (See the saga of Overstock.com here)
3) Bill client again when SAP's back-end freaks out talking to third party code. By this point SAP has developed their own version of the Third party solution, and they either lock out the third party code or make sure it never_quite_works. But don't worry because SAP now has their own module that will only add 40% to the project cost and almost does what the client needs. Then bill additional hours to remove the third party code and integrate with the new SAP, which by the way, requires the new version of the SAP platform, more license fees, etc.
4) The new all SAP solution is murderously slow, unusably complicated, and requires tons more hardware, users complain, and transactions the old POS system did in seconds take minutes. Customers fume, everyone requires weeks of training to navigate basic transactions. This is actually the Happy Ending, it does not get better than this. The client pays large amounts of money annually to SAP for licensing, support, and "maintenance" until they get tired of bleeding red ink. The managers responsible for the project watch their careers burn as they fall on their swords, and the SAP consultants move on like a plague of Locusts.
"A strange game. The only winning move is not to play." -J
You were doing very nicely until
"The managers responsible for the project watch their careers burn as they fall on their swords"
at which point I realised you must be in a parallel universe somewhere where most things are the same except that the people who pay themselves megabonuses when things go well (because they're personally responsible) also accept personal responsibility when things don't go so well.
Very good summary, but I think you forgot a fifth step:
"4) The new all SAP solution is murderously slow, unusably complicated, and requires tons more hardware, users complain, and transactions the old POS system did in seconds take minutes. Customers fume, everyone requires weeks of training to navigate basic transactions. This is actually the Happy Ending, it does not get better than this."
5) New managers replacing the ones that initiated the original SAP project -who have already moved to another company at some point between steps (2) and (3) on the heels of their "success" implementing SAP- hear about HANA. HANA will solve everything. HANA will transform a dog slow system into a responsive one. With HANA the world will be much better. Checks for expensive memory intensive clusters are signed off, and new hardware takes two years to be installed and to be able to run some parts of the application. Trouble is, the application is still slow because the gigantic in-memory distributed hash table that is HANA cannot compensate for all the quirks and hacks introduced in steps 1 to 4 by various developers and consultants whose management have spent years racing to the bottom searching for the least qualified (read cheapest) developers that can be still billed as senior level guys.
Sometimes someone qualified takes a look at the system, trying to improve its performance, reduce the maintenance burden or both. But after seeing an insane horror house of unstructured code, copied and pasted code without any consideration for such concepts as "version control" or "test modules", and custom defined tables whose design treats normalization as a joke, he or she runs away, trying to forget it to prevent permanent brain damage. Just looking at the dependency diagram between SAP and external systems with all the data flows entering and exiting boxes can bring insanity to the most stable and serene soul.
As with step 4, no, it does not get any better than this. Only more expensive. As the data grows, HANA requires more license fees, and only escalates by adding more servers. But that is the way to go, as it is still cheaper than trying to untangle the incredible spaghetti maze of dependencies among custom coding, user defined tables and legacy data that no one really understands.
And the cycle continues. Managers and consultants move to another company, hoping to repeat their "success" in transforming a business into a hostage of its ERP software suppliers.
> Looks like you got what you asked for, not what you wanted...
To be fair, if that were so, it would be the requirements people's fault, not the customer's.
P.S.: I've already logged in over at theregister.co.uk, why the fuck do I need to log in again at a different domain I did not even consciously navigate to?????
"P.S.: I've already logged in over at theregister.co.uk, why the fuck do I need to log in again at a different domain I did not even consciously navigate to?????"
PEBKAC, really ?
So you log on to ElReg, click a link that sends you to the channel and have to log on again, and you find that normal ?
And I'm glad to see that there are others in that case.
I was following you until you said:
The managers responsible for the project watch their careers burn as they fall on their swords, and the SAP consultants move on like a plague of Locusts.
in which I believe you made a mistake, that SHOULD read:
The managers responsible for the project
watch their careers burn as they fall on their swords grab all of the bonuses that they can and bail out on the project with a "Golden Parachute" before the realization that the shit has hit the fan, and you are about to experience "blowback", and the SAP consultants move on like a plague of Locusts bunch of greedy Wall Street Bankers out for another score.
The next line goes?
SaviourFailure of the universe
This is what happens when you try to put lipstick on a pig.
Well done Avon. I know a lot lies with the initial spec, but I've been involved in a couple of big SAP projects and they both have turned out to be expensive failures, mostly down to the cumbersome, indeed laybrinthine, methods of the SAP folks, who will complicate what does not need to be complicated, and then try to make it work in their overly-complex product. The two companies who got handed the streaming pile put a big brave grin on their faces and kept marching forward on the very poor grounds that 'well, we've put so much ££ in it so far' when they would have done well to have cut their losses.
I was doing usability on one system and actually quit rather than help deliver something that was not fit for purpose.
God save us all from SAP's EDI implementation. And the version they laughingly call XML. What a crock.
A certain TLA named vendor was part of the reason a FTSE100 listed company that my partner worked in for 20 years died. In retail it helps if you have stock or at least know where it is so you can sell it, but the code they were running didn't seem to be able to do that with consistency.
Unfortunately we run SAP.
The user interface is a left over relic from the 1980's - does anybody who works there own or use a computer with a modern user interface?
SAP is so user hostile that it actually manages to make Lotus Notes look good.
Used to use some of their tyres
To the person who down voted this post ----->
Roadrunners were great tyres on my Bonnieville. Far better than Bridgestones.
This is typical of a bunch of the big vendors whose money goes into marketing, lobbying, lawyering and forms of bribery rather than the software they claim to have.
Like others here, I have worked on my share of big projects using stuff like this and the only reason any of them succeed is people like me spending long nights building work-arounds. In my case, a lot of it on my own dime just to maintain my own self respect.
The people at these places definitely know how to get success if you measure that success by their own growth and increasing wealth. Not so much for their customers. They are very good at balancing their take so they don't kill the host organism, but sometimes their calibration is off and the host company dies anyway.
Fortunately for them, a dead host is only a mere nuisance since the executives that acted as vectors into the host move to a new host and engage all over again. Ironically, this is often based on their (vendor issued) 'award-winning success' with the project that killed their former employer.
Most of the world's working systems are running on Assembly code variants, C, Cobol, Fortan and other old languages used by old programmers. God help us when they all retire. [Note that compiling what is essentially partially crippled C code with a C++ compiler does not make it C++ code, let alone 'object oriented'. Presenting screen-scraped results from CICS does not mean your application is written in the scraping language. That is, it is not going to replace the underlying COBOL code doing the actual heavy lifting. Shout out to Ada. Not sure how much code is written in this language, but a lot of important mission-critical code is written in it and it is (despite being a bit clunky) a sane and sensible language.]
Wishing you posted in two parts. Everything up to the last paragraph is one of the finest accounts of what goes inside these projects. Except that at some point some of us decided to stop the long nights. But please, The Register, you should have some kind of awards for "most insightful post of the decade" for things like this one, at least until the last paragraph.
Pity that in the last paragraph you mixed a few unrelated concepts and confused others. In the end, everything runs in assembly language (machine code, to be pedantically accurate), be it compiled or interpreted. Object orientation is more a matter of style than language. Yes, there are languages that make it easier, but C code can be object oriented just as you can write procedural C++ (not sure if the analogy can be extended to COBOL) And no one is claiming scraped mainframe (or SAP) screens are more than a facade in front of a legacy program, not any more than web pages that make AJAX requests and transform them to put into the browser DOM claim to be written in XSLT.
Re: "Pity that in the last paragraph you mixed a few unrelated concepts and confused others."
I must have communicated badly. The executive summary is this:
Programming language and programming paradigm are germane. When you start with a language that is not known for producing the world's working code, you start with a problem right off the bat. One of the issues I have with this is that a lot of the people producing code in these languages do not properly know how to program.
Most of the world's software is not written in HLLs like SAP's ABAP or whatever they are calling it these days. The people who know what they are doing enough to produce the actual working code we are all running use things like the languages I mentioned. Much of the world's code doing the 'heavy lifting' is old code, written in old languages by old programmers.*** To the extent that a lot of the modern systems work, they are relying upon older code in many places along the path from concept to a running implementation. The guys who built the stuff that works are retiring. Meantime, instead of properly advancing languages and training literate programmers to use them, we are squandering our resources and a generation of programmers on stuff like the SAP systems under discussion. The problem is, at the end of the day they do not produce real hard-core working systems we all actually use.
Re: "In the end, everything runs in assembly language (machine code, to be pedantically accurate), be it compiled or interpreted. Object orientation is more a matter of style than language. Yes, there are languages that make it easier, but C code can be object oriented just as you can write procedural C++"
In the long run, we are all dead. Ultimately everything is running in microcode on the chip. Unless we are building a chip, that level of abstraction is not where we work. Assembly language as a programming abstraction is not equivalent to machine code. It compiles to machine code, but it is not machine code, it is Assembly language. Similarly, languages which target C as an intermediate on the way to compilation (the old C++ did this), are not equivalent to C. They translate to C, but it is not C, it is C++. You can create object oriented code in C, native machine op codes or even lower for that matter, but at the level of C you are not dealing with an object oriented language. I am not crazy about any of the language alternatives, but some languages naturally support object oriented design and C is not one of them.
*** Things like the following are generally not written in the allegedly 'better' new languages, but rather the allegedly inefficient old languages: Operating systems, language compilers, database engines and tools, spreadsheets, word processors, drawing and document creation tools, typesetting, presentation software, browsers, search engines, Email systems, networking systems, web servers, virtualization systems, multimedia systems, security systems, archiving tools, translators and proofing tools, multi-tier architecture infrastructure, GUIs, expert systems, speech recognition and synthesis, etc. They generally trace back to someone scratching an itch and even though the research may have started with other tools and languages such as spreadsheet macros, Algol derivatives or scripting languages, eventually the hard-core production stuff we all use every day is written in languages like Assembler, C/C++, etc. Application stuff running on big iron was written in languages like 360 Assembler and COBOL.
@btrower here is one for explanation of what constitutes a programming language. I've used a few, from assembler to ABAP, and I can testify that the latter one works "only occasionally".
Funny. Upvote for you.
"gradually weaken or destroy"
IBM, Accenture, Thoughtworks, Capita
"Avon selected SAP technology on the back-end engine for its order entry solution. Avon did not use a SAP UI for the web front end."
Good. We do use the SAP GUI. If the year was 1970, it (the SAP GUI) would be awesome.
It is not 1970.
And it's shit.
My last company replaced their old systems with SAP. The old front-end was web based and in-house. The backend ran on AS400 and was creaky but ok.
The new SAP system was so expensive, there was 1 license per 50 users, and the users went back to submitting paper forms to the person with the license. It also didn't help that in the SAP UI you had to raise an order against a fixed cost centre, and then go back and amend the order to add an auxilliary field with the cost-centre in it, because for some reason if you didn't, it couldn't assign costs properly, and sometimes went ahead with orders before they had even been reviewed, let alone authorised. A simple mistake in the UI caused all sorts of pain that took hours to resolve.
I'm very glad to be somewhere else now.
Because there are plenty of other companies in this situation but in general they keep schtumm. Can anybody guess why?
"Can anybody guess why?"
Because nobody likes to admit that they have made a $100 million mistake. Usually there is more than one person involved in the decision and unless you have a complete regime change there will be no admission of fault.
In this case, Avon should be publicly applauded for being so open about the mistake and the fact they have decided to stop throwing good money after bad.
We need more companies like Avon to step forward and admit that SAP is not a solution.
Then we'll get a proper idea of just how many "award-winning" cases are actually a success.
If I were a CEO in a big company I'd be head hunting at Avon. People who own up to their mistakes and fix them are a rare commodity.
Sadly, knowing this is probably part of why I am not a CEO at a big company.
I have managed to avoid SAP so far. My current employer uses Agresso which provides an awful user experience and the last "upgrade " took a week during which no orders could be made. How does SAP measure up to this?
I've never used SAP but a typewriter would be more advanced than Agresso.
Don't know Agresso, but doing better than SAP at anything is not that difficult if you have to make it work the way you want, rather than the way SAP wants to work.
The trouble with SAP is that it does perfectly 80% of what you want it to do. When the business part that wrote the SAP check has to face the fact that they either have to change their company processes in a fundamental way to fit the remaining 20% is where the trouble starts. Because the solution usually involves a compromise that retrofits and shoehorns the process into the SAP view of the world. It is either that or admitting their mistake.
And it is that 20% is going to eat 90% of the budget and time, and nobody is going to be happy with the final result.
In this case, Avon is very, very unconventional in admitting their mistakes and at least trying to fix them.
Like the parent, I have not used SAP so cannot comment on that, but I once in my career came across Agresso. You'd be better off sitting in a corner poking yourself with a sharp stick 24/7 than even *watching* someone use that shit.
We use Agresso here and are currently running a migration to SAP. I haven't used SAP but our implementation project is going pretty well by all accounts. I can't imagine the interface will be actively worse than Agresso, which is barely usable in a number of respects.
Reminds me of an old Murphy's Law :
If you think everything is going fine, you don't have the faintest idea of what's going on.
Peeved enough to take such an act almost seems (or might be) akin to "we're going to SCREW YOU with negative publicity", even though some contracts that run the risk of being outted as boondoggles come ridden with NDAs and such to mitigate the risk of being publicly outted as a money-wasting frackjob.
Still, a $120M tech update, amortized across how many years? Five? 10? 20? If just 5, and solely recouping costs in Canada alone, would mean, expecting Canadians to spend $25M a year on beauty and relevant-cost-center/revenue-center products. Do that many Canadians exist to cover a $25M expectation?
As of mid-2013, it was reported that Canada's population was 25.16 million, up by around 404k. So, I doubt Avon expected maybe 4.8M women (assuming .2 of the population contains the target audience buying enough Avon products...
Wait, 4.8M women (or aggregated, valid consumers of Avon products) who spent $200 each (in just ONE year) would theoretically bring Avon $960M. So, if Avon publicly outted the project as a distracting, major failure, then those women or valid consumers probably sniffed and walked away due to the CRM/related interface, or spent just a fraction of what was hoped for. Even if only 10% of those visiting bought just $100, that could mean $48M, and if that sustained for 5 years (if that was the break-even time), then even THAT crying, low threshold must not have been met in the trial, the test phase, and the projections in meetings. Maybe only 5,000 people actually bought anything in that time, and probably spent only $35 each.
$175,000 won't do it in ANY stretch of accounting tricks in 5 years.
Avon must be seeing blood and tears to have lobbed SAP out the 10th-floor window...
Why would only Canada's customers end up paying for it? Their much larger market is in the US (and maybe elsewhere in the world, I don't know) The article said it was a pilot in Canada, so presumably had it been successful it would have been expanded to Avon in the US/worldwide at a later time.
The ability of Avon to recoup these losses is limited to the extent its customers will pay higher prices. They can't just raise their prices to pay for it as you seem to be implying. If they were able to raise prices and make more money, they should have done so already. Companies price to maximize profit. They don't reach a certain target level of profit and then decide "lucky for our customers we're making enough money, we don't need to raise prices any further!"
Statistics & women are obviously not your strong points, can you seriously imagine that people of the female persuasion, buying cosmetics, consider the CRM system of their lippy/mascara provider a caveat in their purchasing choice?
A woman who can't put through an order, or gets the wrong stuff delivered, or sees an ordered gift get sent astray, might not be thinking 'CRM' but she will be thinking 'there are other companies who offer a similar product--why don't I try one?' Which is why Avon are not happy. Because female customers react in the same way as male customers to messed-up services.
Homo sapiens of any persuasion tend to get pissed when their order isn't processed.
At least on my planet.
....not used SAP for a long time but spent 9 months earlier this year discussing Business Objects licensing with them.
A couple of years ago my employer bought 20 BO licenses. I actually installed them (so they were paying maintenance for 2 years on licenses that were not even installed, but that's another story...). We only needed 11 licenses
so I said to SAP 'We only need 11 of the 20 licenses can can I please pay you 11/20ths of the annual license fee (as we need to save money and why pay for something we are not using...)
SAP : No.
Me : Why not?
SAP : Coz you bought 20 licenses and you have to pay for them.
Me : Even if the 9 I don't need are not installed?
SAP : Yes
Me : So how can I pay for just 11 licenses?
SAP : Stop using all the 20 licenses you bought (and paid for...) and just buy 11 new licenses.
(Repeat every couple of weeks for 9 months until you finally understand how they make so much money......)
For a public sector client I worked with, the SAP licensing model was to charge:
a) per CPU
b) per user
c) per customer record stored
No that's not a multiple choice answer - SAP charged for all three.
And it was unreal how much cash can be wasted, and how failure can be spun into 'opportunity'
In the nearly three years I worked there they were working on an online catalogue for displaying the products they sold.
During that time, and still when I left, there were still 10 internal people working on it, 10 SAP consultants and a multitude of consultants that came in for a few weeks then vanished again.
When, after about 2.5 years, they announced that they could put images of some of the products on a web page there were great celebrations about how amazing the new system was.
I couldn't help feeling that a small team developers working in which ever language they picked (.Net for me, but I'm sure that a J2EE solution would have been as quick) could have had the same functionality working in a couple of months (being really conservative here ;p)
And I thought 'orrible was, well, Oracle....
Licensing fees....forced support....boggled bolt-ons...etc...etc..etc...and the cone of silence....
How do they get that way? Remember
Larry, Larry, quite contrary,
How does your empire grow?
With IP "rights" and patent fights,
And lawyers all in a row....
The trouble with all these "canned" systems is they can't fit all situations, indeed they cannot
completely fit any situation, so they force the business to change their processes (and expectations,
I suspect) to fit that of the software package. Add in contractors, outside experts (business analysts, etc.),
custom code, testing (does happen sometimes...), rewrites, updates, whatever, and you end up
with a behemoth that is almost but not completely unlike what you had in mind....
Better to have invested the time and effort in a home-grown or custom system to fit the actual
requirements....which is why the systems being replaced were often a better fit...
...SAP just borged the ecommerce platform I do most of my work with. They're going to kill it :(
Problem with SAP is that its ALL third party products. Everything with SAP written on it is just another third party product bolted on. Most of the time the things they sell don't even work together or have massive feature overlap.
I've read about this particular project before. To me it smacks of lack of decent project management and proper requirements.
An issue you get with all software stacks. Would probably have had the same outcome with Siebel or any other ERP/CRM type system.
$125m for a CRM system even for SAP system is overkill.
The project was most likely run by the Finance team who's only thought was.
"How can I track what money I have coming in"
Nobody thought about who was going to actually use the system, i.e. untrained door to door sales people.
When did they bring in the actual users for UAT testing? I bet it was at the last minute.
I know SAP has it faults (I've been working with SAP for 20 years), but for years a user should never even have to touch a SAPgui.
I went for an interview with Avon HQ in the UK.
Did the IQ test in 1/2 the alloted time. Threw them into a panic because "nobody ever finishes that". Got shown into the manager. "Don't sit down. You will be bored here. Goodbye!"
And it was for twice the salary I was on.
If they only employ overpaid monkies, then what do they expect!
Guy1: "So who proposed SAP ?"
Guy2: "The consultancy company we hired"
Guy1: "So who did the implementation?"
Guy2: "The same consultancy company"
The front-end provider was Websphere. IBM have declined to comment.
Yup, that's an ERP system all right.
Keep in mind that ABAP (the SAP proprietary language) is not that different from the way MS office is implemented, mostly by chunks of VBA with a core of compiled C/C++ routines.
BTW It took a lot of guts for Avon to go public like this and admit that (effectively) the Emperors new clothes are rubbish and he is in the nuddy. They must have been epically p**sed off.
I wonder does anyone ever feel a need to adopt a cod German accent when discussing SAP? I sense an SAP press release along the line of :-
"Hans Landa III, VP i/c of Large North American Implementations (which is one word in German, honest) commented. 'We have studied this market sector and implemented the most efficient methods into our system. Clearly the failure of Avon to implement it is a result of the weakness of management to firmly disciple dissent within their staff, necessary to ensure full adoption of our solution . A regrettably common cause of failure of SAP implementations globally." " *
*Yes I probably have spent too much time in management sales presentations. But I know I will go to heaven, as I have spent so much time in Hell.
Biting the hand that feeds IT © 1998–2018