Customization is key, you CAN't customize. I worked on an SAP implementation, a Fortune 500 company, complexity like crazy, sub-companies, of sub-companies, of sub-companies, federal, state and local compliance for what the company did, operating in 50 states, with an International supply chain, and our integrator was nothing special.
We held firm to the NO CUSTOMIZATION rule, we re-engineered our processes to fit SAP. Other than a few hiccups when integrating all aspects of a company that has 100 sub companies, and is under federal, state and local regulation the project basically went off without a hitch.
They are still taking upgrades 6 years later, without issue.
Most companies think they are unique, and special, and feel justified in needed to customize, all those companies are wrong.
It is ridiculously expensive and complex. I know that the problems it aims to solve are also highly complex and very specific, but reading stories like this, plus (if you live in Germany and work in the IT industry) sometimes hearing unbelievable stories from your peers, it always confuses me that companies still want so much SAP.
In the late 90s/early 00s a lot of people had seemingly infinite trust in IBM. Maybe the same logic applies here as well.
Former SAP employee here, who btw, is very critical of SAP. I also happen to have worked in Escalation Management at SAP, who's prime responsibility was to take SAP projects that were about to go south and put them into "escalation" before they the hit newspapers.
Let me try to explain the mystery around SAP.
1. Most of the situations where SAP projects go haywire is largely due to (a) incorrect implementation by the service integrator and (b) challenges between business processes and systems support for those business processes. Sally in accounting wants to see sales per unit for the Germany promotional rollout, while Karen in marketing wants to see overall sales for 100 store locations in both Germany and Netherlands. The NL's retail stores don't split out VAT because their POS systems don't allow you to do that...etc etc. You can see where this is going...
2. Implementing ERP at the global level is incredibly complex. There's this idea (especially in the HN circles) to just "throw SaaS" at the problem, but it's not that simple. If you haven't been involved with an implementation at this size, it's not worth discussing. It's a wonderful hodgepodge of culture challenges, project management methodology clashes, and misalignment of strategy.
3. Yes, no one ever got fired for hiring SAP, just like they did with IBM. This is obviously changing, but still has some truth to it (see next point).
4. Honestly, being a CIO of a global F500 company absolutely sucks. If you try to stick your head out and do anything innovative and it fails, your axed. Many CIOs simply go into turtle mode - protect the budget you're given by the CFO and just don't f anything up. A CIO who choses to build a custom ERP and fails will be fired 100x faster than one who uses a packaged solution and it fails.
5. What's the alternative? Oracle? At this level, they're all the same (ok, not totally true, but generally accurate).
Happy to answer any questions...this area is unfortunately/fortunately close to my heart.
Not quite. I have worked with sap at many different clients. Some Reasons for buying SAP ( by that i mean their ERP as well as funxtional or industry specific tools and applications.) are as follows
Scale: at this size, you pick SAP or Oracle. There's very little else out there in the market.
Proven implementation: speaking for most clients, you cannot get a major ERP implementation done without outside help. You will turn to either the vendors or major integrators. You will then ask them to give you advice and prove their expertise. They will give you a list of prior successes, which is in my sector always going to favour SAP as Oracle have a bad track record. You will then pick the system and configuration and maybe even architecture they are recommending.
Industry Expertise: SAP, in many industry sectors, know their shit. You can try making your own tools, you can try pulling 20 different apps together to get the functionality you want. But that increases cost, complexity and often violates architectural principles. So you just buy SAP and all the modules, because they have every possible business process mapped out, data structures configured, suppliers and product catalogues ready to go, etc. Oracle has this too, but fewer products support or integrate well in my limited experience.
Of course, SAP isn't without its issues or drawbacks, but i have consulted with clients across many projects including the initiak upstream business cases, and these are often the key deciding factors.
As the other commenters have noted, none of the offerings in the large-scale ERP space are "good" for most measures of good, but they tend to be good enough to keep things operational. SAP is reputedly the least bad vendor in this space (we use a competing system and it is much worse).
ERPs are tedious, uninspiring, production-level software that have to deal with all manners of ill-defined business rules and variations. It's almost impossible to come up with an elegant product because the problem space itself is inelegant and in many cases irreducibly so. I imagine it's hard to attract talented developers (except those solely attracted to money) to this space because the feedback loop and intellectual payoff is so unrewarding. Most of the time the implementation problems have to do with human problems, not technical ones. Most ERP customization is outsourced to pools of fungible labor.
But when you run a large enterprise, ERPs are absolutely necessary, so someone's gotta do it.
ERP is probably the slowest moving market in software. Trying to sell ERPs for almost a decade now here is what I learned
1. The first reason for this is compliance. Most large companies are worried about compliance and trust only comes with many years of successful deployments. For a new entrant to be recognized can take upto 10 years and for clients to accept the solution as a solid one.
2. The second reason is complexity. When you consider the scale and complexity of an implementation, most new ERP companies do not understand the effort goes into pre-sales and going through hundreds of pages of RFPs. There are system integrators, consultancies and entire ecosystems locked in to this duo-poly.
But things are changing. We run an open source product (https://erpnext.org) and we have seen people are looking to move away from the SAP-Oracle duopoly. Innovative companies where the CTO has as much as a say as a CIO in such decisions are willing to look outside at Open Source. It is still very early days, but this space looks exciting right now.
I don't know much about SAP besides the fact that I don't think I've ever heard anything positive about it (but then again, nobody talks about the trains that are on time). I always assumed that it was a "nobody gets fired for choosing SAP" situation. It's huge, it might be clunky but you know that if you pay for the support it'll probably end up doing mostly what you want and it'll mostly keep working. The alternatives would be either using a less popular solution or creating one in-house but in both cases you're taking additional risks even if it might pay off in the end if everything goes right.
It's the same situation with Oracle, Microsoft Windows and countless other "corporate" software solutions. If you look at it from a hacker point of view it makes no sense, it's ridiculously expensive, it's often overkill, it's not elegant, you could do the same thing for 1% the cost and it'd work better etc... Now if you look at it from the point of view of a company that needs something that will work 100% by a given deadline and you want somebody you can yell at if it doesn't (and you want to know they'll still be here 6 months from now) it makes total sense.
Using services from big name companies is (half) the corporate world version of an expensive fashion item/fancy car and half "wanting someone to sue in case things go wrong".
Except an expensive fashion item doesn't ruin your ability to do your job and is still probably cheaper in relative scales.
The problem is that most SAP projects are in reality change management projects. Unfortunately, change management doesn't sound sexy and everybody focuses on the software side of things. But any IT project at that scale will require a lot of change and a really deep understanding of the current and future business processes and the value you want to get from that change
My "favourite" SAP experience was at the last company I worked at who used it for everything.
One guy who worked for me did a 4 day week - he sometimes took half a day of leave, and when he got to his last half day he could never book it, because the system was adamant he only had 0.49 days of leave remaining.
Not sure if that was bad configuration when it was implemented ... or the product being a bit ropey when something doesn't fit their model perfectly, but it stuck with me and made me forever wary.
Totally agree. It seems that the main advantage it has is that the complexity can be skewed to any angle (helpful for sales), and that the decision-making process at many large companies is an exercise in check-box procurement - rather than, say, genuine understanding of the problems to solve or the user(s) needs.
I have not yet seen a SAP software that could not be replaced with a homemade Django/Rails web app (90% CRUD) and some external API integrations to other services that may exist in the company such HR, invoicing etc.
Of course, at the fraction of the the cost of the SAP solution.
I was a project leader on a successful SAP implementation at a DOW 30 firm back in the 90's. This was a third attempt at it, and I think I may be one of the only people who was on the team for attempts #1 and #2 which failed.
One of the simplest things an SAP implementation team can do to promote their success is to strictly limit the number of ABAP developers on the team. Developers are going to develop and while some customization will be needed, with a team of 10 or 20 ABAP developers you are going to generate way more customizations than you will with only 3 or 5 developers. Resource and skill scarcity will drive the discussions of "do we need this?"
More rare is that you also you need an exec sponsor at a CxO level (other than the CIO) who has the intestinal fortitude and leadership skills to tell their employees "we are going to conform our process to what the software offers" rather than the opposite. Your unique methods of fixed asset management and accounting (to take one example) are not where your company needs to invest in being different from every other company, much as your accounting manager who rails "this is how we always have done it because of our special situation" will complain to the contrary unless the CFO is telling them otherwise.
Human translation (I should practice my German anyway):
Because introducing a new data system didn't work out, the Deutsche Post (German Mail) has already booked higher losses a few years ago. The same now happened to Lidl. The planned system still doesn't work smoothly after seven years and more than half a billion euros in costs. Now, the discount store pulled the kill chord.
For years, Lidl is expanding operations. The discount store from Neckarsulm has stores in almost all European countries and is now also expanding in the USA. A new inventory management system should support purchases and logistics to keep track of ever more complex business. That was the decision in 2011.
System is not suitable for high-turnover countries
The software of the development concern SAP from Walldorf should be adapted to the needs of Lidl. Until now, the system is only being used in small places in Austria, Northern Ireland and the USA. It was clearly shown that the by over a hundred IT specialists developed SAP version is not suitable for high-turnover countries. Now, Lidl has stopped the project. In a paper called "Heilbronner Stimme", an article writes to the employees that the goal is not achievable "with reasonable effort". Until now, the project cost over half a billion euros according to expert opinions -- for example for costly IT consultants and SAP licenses. Now, Lidl says they want to further develop their old inventory management system.
---
Edit: I've never had much to do with SAP, but just today I've been applying for jobs in Germany and two of the places (out of five or so) use some SAP system for their online applications. The former threw a HTTP 400 and later HTTP 500 errors so I couldn't complete the application. The latter is currently stuck on registering: I've been waiting for the page to load for 4 minutes now. Pretty sure that one is broken, too.
> Software from the Walldorf-based software company SAP was to be adapted to the needs of Lidl. So far, however, the new system has only been introduced in the small agencies in Austria, Northern Ireland and the USA. It has been shown that the SAP version developed by over one hundred IT specialists is not suitable for high-turnover countries.
I realize these words are not directly from the company and I am reading them through Google translate, but I do think they accurately reflect what makes these implementations work or not. If you are getting into SAP and "adapting it to your needs" then you will almost certainly fail.
Scenario: I am implementing SAP's invoice approval workflow in a company that already has an invoice approval workflow that a former CFO designed quickly after a problem a few years earlier. Its worked fine.
Companies who are successful implementing SAP: "I mean SAP's workflow makes sense, is already implemented, works for much larger companies, and has no bearing on our core business, so lets just switch to that.
Companies who fail at implementing SAP: "Lets hire some consultants to adapt SAP to our needs"
Source: I did process flows in preparation for SAP implementations in the late 2000s.
This is what I always said; you change your company to adapt to SAP, not the other way around. Then you chose the wrong product. SAP has everything and then a billion configuration switches which should match what you want; they say they would want you to adapt it to your needs by programming, but really it's not very good for that.
On the other hand I know some consultants making millions by creating customizations to SAP specific in their vertical and then sell that as a packaged product to all competitors. Usually these products are incredibly niche (like a specific workflow for Scandinavian utility companies that implements some stuff all Scandinavian utility companies require by law but SAP does not provide. Picking between then implementing it by hiring Accenture or buying off the shelve from someone who did this before is easy.
> If you are getting into SAP and "adapting it to your needs" then you will almost certainly fail.
This is a tricky topic. If you're getting into SAP and you're not adapting it to your needs, you're almost certainly doing something wrong.
The trick is that it _has_ to be a "meet in the middle" kind of situation, where SAP wants to be used in a certain fashion, but also allows a certain amount of leeway — any non-trivial implementation project will involve both tweaking the knobs SAP provides to fit the customer, and developing bespoke components for those scenarios that SAP either doesn't cover at all, or doesn't handle the way you'd like.
If you don't, basically, change your organization to the way SAP (or any such "product") already is set up to run, you are essentially buying a programming language (or perhaps framework) that is poorly documented, with a much smaller online community (for examples, tutorials, Stack Overflow questions, etc.). So it is the same problem you already don't like your solution to, except with a lot of things stacked against you now.
But, they won't make the sale if they honestly say "use it the way it is or else don't buy it", so they say something more along the lines of "you can customize it".
One thing I haven't seen in the comments, but have observed personally is the accounting implications and reasoning for these failed SAP projects.
Sometimes the project cannot be stopped immediately during development, even if it is already known that the project is a failure. The reason is that some companies capitalize the cost of the development over many years, and if they were to cancel the project they would have to book the entire amount as an expense in a given year, instead of depreciating it over multiple years.
I know of one company that worked on an SAP implementation for about 5 years, when it was only supposed to take 6 months or so, and the reason was that if they stopped the project they would have to book the entire cost as an expense in the current financial year. The exec team, who had financially-based bonuses, weren't keen on that.
Instead the project was put together to the extent possible so that it could be declared usable, and then promptly shelved. However, it was "completed" so in theory the sunk cost could have been spread out over multiple years.
"SAP is the best thing that ever happened to computer people. It appeals
to businesses that are too stupid to understand and model their own
processes but too rich to simply continue relying on secretaries and
file cabinets."
-- Philip Greenspun:
http://philip.greenspun.com/panda/future
In defense of ... well actually I don’t know whom I defending here, but what is undereported by German media in this case is “Scheinselbständigkeit”. The remainder of the story then fits the common narrative that developers share about SAP (look, enterprise software in action) and consultants (all overpaid underperformers).
“Scheinselbständigkeit” is a legal term, translatable as “fake entrepreneurialism” and a common problem for German IT freelancers and contractors because it basically states, that you aren’t a freelancer if you serve one client exclusively for more than 6 consecutive months. This could result in huge fines for you but more likely your client as you become retroactively an employee of your client which in turn must pay social security for the years you served him.
It is still a vague term though and in result causes a giant legal grey area, which in turn results in each sector copying what its dominant company’s legal team declared.
For Lidl this means that in the middle of this project, they just happened to fire all of the freelancers.
You can imagine the impact: the most capable and experienced developers had to be replaced with inexperienced freshmen or stuff had to be outsourced to agencies staffed with inexperienced freshmen.
Years ago I did some contract work for a company that was being taken over by a competitor. The consensus in the business was that implementing SAP had weakened the business so much they had become an easy target for takeover.
I've been working in this field a bit, not the big two SAP/Oracle but a smaller ERP(PAAS/SAAS) player. Our solutions manage a few steel plants in Slovenia.
The way I see it is that it's tough, solutions are rarely chosen based on technical merits. It's a mix of "nobody gets fired for choosing SAP/Oracle", decisionmaker's ignorance, having someone who will be there to point the finger at in 5 years and... politics.
The bigger the company, the harder it gets to find anyone who would know or care what the hell is going on in the company and what their needs are. The few cases where you can win over SAP/Oracle is when a company is cornered because they have either failed to implement one of the big player's solution or they are out of money so they have to "compromise". IMHO having to "compromise" has turned out very well for some. The level of customization that we did would be very hard or impossible to achieve with SAP/Oracle.
The Steel plant I work at uses SAP, though personally I don't touch it and only know vague details about it.
I know all non-routine maintenance, mandatory inspections, contractors and warehouse supplies etc is booked in it. Stuff like fire extinguishers, elevator mechanic call outs for breakdowns, replacement hydraulic fluid stuff like that is done via SAP. I think even general 'consumables' stuff like toner for printers in offices / control rooms, fluorescent light tube replacement etc are managed by it.
When you think about it these systems are horrendously complicated.
My wife worked for a large law firm that decided to standardize on SAP. That's sensible - there are loads of legal practice management suites out there that are designed to cope with the peculiar demands of legal billing - so let's ignore all those and buy a product that doesn't do it, and spend millions adding customization to get what we want.
Of course the project was killed after 3/4 years and millions spent.
A good thing for SAP that in the large firms they target, mediocrity floats upwards!
This is so unacceptable yet happens so often. Here in the Netherlands the government has several projects that failed with costs amounting to hundreds of millions. For sums as these any Organisation can just setup a more capable development company that could handle all of the internal projects and its developers could be top of the line.
The thing is, yes you can set up a new company and make a new product from scratch whose requirements are exactly defined by you and after a few years of work they'll have a working product. Then what? You'll still be running the same software in 10 years, are you going to keep paying an entire company's worth of employees during those 10 years so they can hang out and be ready to implement all the changes you'll eventually need, to fix bugs and provide support? The costs of that would be far higher.
Most non-enterprise people don't get it (as seen in this thread where most people are only taking into consideration the cost of development): In a software suite's lifecycle, the initial implementation cost is nothing compared to the total cost until sunset.
Application lifecycle management (or product lifecycle management in a broader context) is a hugely important thing for a corporation that plans on existing for more than a couple years.
This specific case, though, is totally acceptable : Lidl is a company in a market with great opportunities for competition. If this decision was a waste of money, a smaller , SAPless company can come and eat their lunch.
The Dutch government is a very different story. Until we have a few parallel governments between which we can easily choose , without having to uproot our entire lives, it is a pathetic waste of tax payer money. I dream sweet dreams of accountability and proper incentive structures for government and public servants.
That's what I thought. I have direct experience from two companies who wasted a shit-ton on SAP, and pretty much everybody who had to deal with it was happy afterwards. And I'm not just talking people being grumpy because they had to get used to something new. Often used processes became much more complicated, logic flaws were introduced (I witnessed someone breaking into tears a couple weeks in).
One of those companies also wen't bankrupt a couple years later. They weren't doing all too well before either, so wasting a huge load of money on a system that basically makes your internal processes grind to a halt probably didn't help.
Hearing that you waste half a billion on this really makes me wonder if it isn't much more practical to just develop custom made software in house.
This reminds me about my apprenticeship, which started near the year 2000. Worked in big swiss retail company (comparable to Lidl, but much lesser in size). They already had SAP R2 and AS400 (IBM?) and wanted to migrated to SAP R3... well they finally did, but it took many (5-6) years and it also cost millions, if I remember correctly 60 millions. The headquarter who consisted of two houses with each 4 floors had at least two of the 8 floors packed with external SAP consultants. In 2005 or 2006 the company had to sell one of its sub companies after the other to get more money and the whole group was finally sold to a German competitor (I think they use also SAP R3 :-) ).
minimally corrected google translation of the (short) article:
Lidl is wasting 500 million euros
Because the introduction of a new data system did not work out, Deutsche Post already had to record a high loss several years ago. The same thing happened to Lidl. After seven years and costs of more than half a billion euros, the planned system is still not running smoothly. Now the discounter has pulled the ripcord.
Lidl has been on an expansion course for years. The discount store from Neckarsulm now has branches in almost every country in Europe and is now also growing in the USA. A new merchandise management system was needed to easily keep track of the increasingly complex business processes and to control branches, purchasing and logistics. Therefor the decision in 2011.
System is not good for high-turnover countries
Software from the Walldorf-based software company SAP was to be adapted to the needs of Lidl. So far, however, the new system has only been introduced in some small agencies in Austria, Northern Ireland and the USA. It has been shown that the SAP version developed by over one hundred IT specialists is not suitable for high-turnover countries. Now Lidl has stopped the project. In one of the newspaper "Heilbronner Stimme" present letter to the coworkers it is said that the actual "goals" are "not reachable with justifiable effort". So far, according to expert opinion, the project has consumed more than half a billion euros - for expensive IT consultants and SAP licenses, for example. Now Lidl wants to further develop its own inventory management system.
My previous contract PM role was working in HR on a SAP contract. I'd never come across it before and it's very strange. The thing it reminds me most of is Lotus Notes, in that it has its own specific vocabulary and the whole system is stored in its own database.
Screen are rarely referred to by name, but have weird codes like XQ44 and are ugly AF. It also has a whole bunch of utilities for fixing up the referential identity on records, importing data etc.
Anyone have a good recommendation for SAP alternative for small medium businesses (SMB)? All the companies I work for use something equally convoluted like Oracle and SAP. When I worked at a startup, I debated for a long time which ERP/PDM system will be the most effective (which I never answered).
You could implement SAP for SMB as well. I even know several startups who decided to go SAP.
The key is to limit customization(I bet you don't have complicated accounting or logistics processes) and stick to SAP consultants from Eastern-Europe(2 times cheaper compared to German consultants, due to their lack of German , wich you don't need) - just search linked in for consultants fromt he biggest SAP hubs in the region: Slovakia, Poland(mostly SAP Basis consultants), Latvia (Project management, ABAP and SAP ERP).
Good luck!
I'm an SE for an ecommerce platform aimed at the mid-market (Workarea), and there are a lot of ERP/PDM options out there for SMB, and they all take work to implement and maintain. In the interest of full disclosure, my only affiliation on that side of things is with a company called OrderBot; if you hit me up at my handle @gmail.com I might have some suggestions for you depending on what you're looking for - mostly based on what I've seen out there in terms of what we've been connecting Workarea to.
Which country, potentially which industry? This is something where from what I've seen there's often local players which are interesting, but would be a bad choice in other places.
My model is basic, but at $1200/day per consultant, with 100 consultants, that's still about 4160 days, or about 11 years. Not what I would consider fast.
[+] [-] netinmate|7 years ago|reply
We held firm to the NO CUSTOMIZATION rule, we re-engineered our processes to fit SAP. Other than a few hiccups when integrating all aspects of a company that has 100 sub companies, and is under federal, state and local regulation the project basically went off without a hitch.
They are still taking upgrades 6 years later, without issue.
Most companies think they are unique, and special, and feel justified in needed to customize, all those companies are wrong.
[+] [-] DrinkWater|7 years ago|reply
It is ridiculously expensive and complex. I know that the problems it aims to solve are also highly complex and very specific, but reading stories like this, plus (if you live in Germany and work in the IT industry) sometimes hearing unbelievable stories from your peers, it always confuses me that companies still want so much SAP.
In the late 90s/early 00s a lot of people had seemingly infinite trust in IBM. Maybe the same logic applies here as well.
[+] [-] mbesto|7 years ago|reply
Let me try to explain the mystery around SAP.
1. Most of the situations where SAP projects go haywire is largely due to (a) incorrect implementation by the service integrator and (b) challenges between business processes and systems support for those business processes. Sally in accounting wants to see sales per unit for the Germany promotional rollout, while Karen in marketing wants to see overall sales for 100 store locations in both Germany and Netherlands. The NL's retail stores don't split out VAT because their POS systems don't allow you to do that...etc etc. You can see where this is going...
2. Implementing ERP at the global level is incredibly complex. There's this idea (especially in the HN circles) to just "throw SaaS" at the problem, but it's not that simple. If you haven't been involved with an implementation at this size, it's not worth discussing. It's a wonderful hodgepodge of culture challenges, project management methodology clashes, and misalignment of strategy.
3. Yes, no one ever got fired for hiring SAP, just like they did with IBM. This is obviously changing, but still has some truth to it (see next point).
4. Honestly, being a CIO of a global F500 company absolutely sucks. If you try to stick your head out and do anything innovative and it fails, your axed. Many CIOs simply go into turtle mode - protect the budget you're given by the CFO and just don't f anything up. A CIO who choses to build a custom ERP and fails will be fired 100x faster than one who uses a packaged solution and it fails.
5. What's the alternative? Oracle? At this level, they're all the same (ok, not totally true, but generally accurate).
Happy to answer any questions...this area is unfortunately/fortunately close to my heart.
[+] [-] arbitrary_name|7 years ago|reply
Scale: at this size, you pick SAP or Oracle. There's very little else out there in the market.
Proven implementation: speaking for most clients, you cannot get a major ERP implementation done without outside help. You will turn to either the vendors or major integrators. You will then ask them to give you advice and prove their expertise. They will give you a list of prior successes, which is in my sector always going to favour SAP as Oracle have a bad track record. You will then pick the system and configuration and maybe even architecture they are recommending.
Industry Expertise: SAP, in many industry sectors, know their shit. You can try making your own tools, you can try pulling 20 different apps together to get the functionality you want. But that increases cost, complexity and often violates architectural principles. So you just buy SAP and all the modules, because they have every possible business process mapped out, data structures configured, suppliers and product catalogues ready to go, etc. Oracle has this too, but fewer products support or integrate well in my limited experience.
Of course, SAP isn't without its issues or drawbacks, but i have consulted with clients across many projects including the initiak upstream business cases, and these are often the key deciding factors.
[+] [-] wenc|7 years ago|reply
ERPs are tedious, uninspiring, production-level software that have to deal with all manners of ill-defined business rules and variations. It's almost impossible to come up with an elegant product because the problem space itself is inelegant and in many cases irreducibly so. I imagine it's hard to attract talented developers (except those solely attracted to money) to this space because the feedback loop and intellectual payoff is so unrewarding. Most of the time the implementation problems have to do with human problems, not technical ones. Most ERP customization is outsourced to pools of fungible labor.
But when you run a large enterprise, ERPs are absolutely necessary, so someone's gotta do it.
[+] [-] rushabh|7 years ago|reply
1. The first reason for this is compliance. Most large companies are worried about compliance and trust only comes with many years of successful deployments. For a new entrant to be recognized can take upto 10 years and for clients to accept the solution as a solid one.
2. The second reason is complexity. When you consider the scale and complexity of an implementation, most new ERP companies do not understand the effort goes into pre-sales and going through hundreds of pages of RFPs. There are system integrators, consultancies and entire ecosystems locked in to this duo-poly.
But things are changing. We run an open source product (https://erpnext.org) and we have seen people are looking to move away from the SAP-Oracle duopoly. Innovative companies where the CTO has as much as a say as a CIO in such decisions are willing to look outside at Open Source. It is still very early days, but this space looks exciting right now.
[+] [-] simias|7 years ago|reply
It's the same situation with Oracle, Microsoft Windows and countless other "corporate" software solutions. If you look at it from a hacker point of view it makes no sense, it's ridiculously expensive, it's often overkill, it's not elegant, you could do the same thing for 1% the cost and it'd work better etc... Now if you look at it from the point of view of a company that needs something that will work 100% by a given deadline and you want somebody you can yell at if it doesn't (and you want to know they'll still be here 6 months from now) it makes total sense.
[+] [-] raverbashing|7 years ago|reply
Except an expensive fashion item doesn't ruin your ability to do your job and is still probably cheaper in relative scales.
[+] [-] kfk|7 years ago|reply
[+] [-] philjohn|7 years ago|reply
One guy who worked for me did a 4 day week - he sometimes took half a day of leave, and when he got to his last half day he could never book it, because the system was adamant he only had 0.49 days of leave remaining.
Not sure if that was bad configuration when it was implemented ... or the product being a bit ropey when something doesn't fit their model perfectly, but it stuck with me and made me forever wary.
[+] [-] adrian_mrd|7 years ago|reply
[+] [-] laythea|7 years ago|reply
Supply chain may be complex but for heavens sake, 500M euros! and not complete. I can do it for half :)
[+] [-] avip|7 years ago|reply
[+] [-] coldtea|7 years ago|reply
You probably conflate that period with the 60s-70s.
In the late 90s/00s it was when IBM regained some mojo by adopting Linux and OSS and building on top of them.
It was not its time of "infinite trust", but a time of a recovery into "some trust".
[+] [-] sparkling|7 years ago|reply
Of course, at the fraction of the the cost of the SAP solution.
[+] [-] patja|7 years ago|reply
One of the simplest things an SAP implementation team can do to promote their success is to strictly limit the number of ABAP developers on the team. Developers are going to develop and while some customization will be needed, with a team of 10 or 20 ABAP developers you are going to generate way more customizations than you will with only 3 or 5 developers. Resource and skill scarcity will drive the discussions of "do we need this?"
More rare is that you also you need an exec sponsor at a CxO level (other than the CIO) who has the intestinal fortitude and leadership skills to tell their employees "we are going to conform our process to what the software offers" rather than the opposite. Your unique methods of fixed asset management and accounting (to take one example) are not where your company needs to invest in being different from every other company, much as your accounting manager who rails "this is how we always have done it because of our special situation" will complain to the contrary unless the CFO is telling them otherwise.
[+] [-] lucb1e|7 years ago|reply
Because introducing a new data system didn't work out, the Deutsche Post (German Mail) has already booked higher losses a few years ago. The same now happened to Lidl. The planned system still doesn't work smoothly after seven years and more than half a billion euros in costs. Now, the discount store pulled the kill chord.
For years, Lidl is expanding operations. The discount store from Neckarsulm has stores in almost all European countries and is now also expanding in the USA. A new inventory management system should support purchases and logistics to keep track of ever more complex business. That was the decision in 2011.
System is not suitable for high-turnover countries
The software of the development concern SAP from Walldorf should be adapted to the needs of Lidl. Until now, the system is only being used in small places in Austria, Northern Ireland and the USA. It was clearly shown that the by over a hundred IT specialists developed SAP version is not suitable for high-turnover countries. Now, Lidl has stopped the project. In a paper called "Heilbronner Stimme", an article writes to the employees that the goal is not achievable "with reasonable effort". Until now, the project cost over half a billion euros according to expert opinions -- for example for costly IT consultants and SAP licenses. Now, Lidl says they want to further develop their old inventory management system.
---
Edit: I've never had much to do with SAP, but just today I've been applying for jobs in Germany and two of the places (out of five or so) use some SAP system for their online applications. The former threw a HTTP 400 and later HTTP 500 errors so I couldn't complete the application. The latter is currently stuck on registering: I've been waiting for the page to load for 4 minutes now. Pretty sure that one is broken, too.
[+] [-] philipodonnell|7 years ago|reply
I realize these words are not directly from the company and I am reading them through Google translate, but I do think they accurately reflect what makes these implementations work or not. If you are getting into SAP and "adapting it to your needs" then you will almost certainly fail.
Scenario: I am implementing SAP's invoice approval workflow in a company that already has an invoice approval workflow that a former CFO designed quickly after a problem a few years earlier. Its worked fine.
Companies who are successful implementing SAP: "I mean SAP's workflow makes sense, is already implemented, works for much larger companies, and has no bearing on our core business, so lets just switch to that.
Companies who fail at implementing SAP: "Lets hire some consultants to adapt SAP to our needs"
Source: I did process flows in preparation for SAP implementations in the late 2000s.
[+] [-] tluyben2|7 years ago|reply
On the other hand I know some consultants making millions by creating customizations to SAP specific in their vertical and then sell that as a packaged product to all competitors. Usually these products are incredibly niche (like a specific workflow for Scandinavian utility companies that implements some stuff all Scandinavian utility companies require by law but SAP does not provide. Picking between then implementing it by hiring Accenture or buying off the shelve from someone who did this before is easy.
[+] [-] pdpi|7 years ago|reply
This is a tricky topic. If you're getting into SAP and you're not adapting it to your needs, you're almost certainly doing something wrong.
The trick is that it _has_ to be a "meet in the middle" kind of situation, where SAP wants to be used in a certain fashion, but also allows a certain amount of leeway — any non-trivial implementation project will involve both tweaking the knobs SAP provides to fit the customer, and developing bespoke components for those scenarios that SAP either doesn't cover at all, or doesn't handle the way you'd like.
[+] [-] rossdavidh|7 years ago|reply
But, they won't make the sale if they honestly say "use it the way it is or else don't buy it", so they say something more along the lines of "you can customize it".
[+] [-] adamdrake|7 years ago|reply
Sometimes the project cannot be stopped immediately during development, even if it is already known that the project is a failure. The reason is that some companies capitalize the cost of the development over many years, and if they were to cancel the project they would have to book the entire amount as an expense in a given year, instead of depreciating it over multiple years.
I know of one company that worked on an SAP implementation for about 5 years, when it was only supposed to take 6 months or so, and the reason was that if they stopped the project they would have to book the entire cost as an expense in the current financial year. The exec team, who had financially-based bonuses, weren't keen on that.
Instead the project was put together to the extent possible so that it could be declared usable, and then promptly shelved. However, it was "completed" so in theory the sunk cost could have been spread out over multiple years.
Sometimes, you just have to follow the money.
[+] [-] e12e|7 years ago|reply
[+] [-] woodpanel|7 years ago|reply
In defense of ... well actually I don’t know whom I defending here, but what is undereported by German media in this case is “Scheinselbständigkeit”. The remainder of the story then fits the common narrative that developers share about SAP (look, enterprise software in action) and consultants (all overpaid underperformers).
“Scheinselbständigkeit” is a legal term, translatable as “fake entrepreneurialism” and a common problem for German IT freelancers and contractors because it basically states, that you aren’t a freelancer if you serve one client exclusively for more than 6 consecutive months. This could result in huge fines for you but more likely your client as you become retroactively an employee of your client which in turn must pay social security for the years you served him.
It is still a vague term though and in result causes a giant legal grey area, which in turn results in each sector copying what its dominant company’s legal team declared.
For Lidl this means that in the middle of this project, they just happened to fire all of the freelancers.
You can imagine the impact: the most capable and experienced developers had to be replaced with inexperienced freshmen or stuff had to be outsourced to agencies staffed with inexperienced freshmen.
[+] [-] acdha|7 years ago|reply
[+] [-] tonyedgecombe|7 years ago|reply
[+] [-] solarkraft|7 years ago|reply
[+] [-] throwaway_2q121|7 years ago|reply
The way I see it is that it's tough, solutions are rarely chosen based on technical merits. It's a mix of "nobody gets fired for choosing SAP/Oracle", decisionmaker's ignorance, having someone who will be there to point the finger at in 5 years and... politics.
The bigger the company, the harder it gets to find anyone who would know or care what the hell is going on in the company and what their needs are. The few cases where you can win over SAP/Oracle is when a company is cornered because they have either failed to implement one of the big player's solution or they are out of money so they have to "compromise". IMHO having to "compromise" has turned out very well for some. The level of customization that we did would be very hard or impossible to achieve with SAP/Oracle.
[+] [-] bigger_cheese|7 years ago|reply
I know all non-routine maintenance, mandatory inspections, contractors and warehouse supplies etc is booked in it. Stuff like fire extinguishers, elevator mechanic call outs for breakdowns, replacement hydraulic fluid stuff like that is done via SAP. I think even general 'consumables' stuff like toner for printers in offices / control rooms, fluorescent light tube replacement etc are managed by it.
When you think about it these systems are horrendously complicated.
[+] [-] spsrich|7 years ago|reply
Of course the project was killed after 3/4 years and millions spent.
A good thing for SAP that in the large firms they target, mediocrity floats upwards!
[+] [-] callesgg|7 years ago|reply
The main problem is not the actual software it is the people who implement it.
Sap as a company has no control over the implementors. The implementors don’t understand how the software is intended to work.
I can compare it to Samsung Android vs Google Android.
[+] [-] mosselman|7 years ago|reply
[+] [-] lagadu|7 years ago|reply
Most non-enterprise people don't get it (as seen in this thread where most people are only taking into consideration the cost of development): In a software suite's lifecycle, the initial implementation cost is nothing compared to the total cost until sunset.
Application lifecycle management (or product lifecycle management in a broader context) is a hugely important thing for a corporation that plans on existing for more than a couple years.
[+] [-] nothrabannosir|7 years ago|reply
The Dutch government is a very different story. Until we have a few parallel governments between which we can easily choose , without having to uproot our entire lives, it is a pathetic waste of tax payer money. I dream sweet dreams of accountability and proper incentive structures for government and public servants.
One day.
[+] [-] raverbashing|7 years ago|reply
[+] [-] fps_doug|7 years ago|reply
One of those companies also wen't bankrupt a couple years later. They weren't doing all too well before either, so wasting a huge load of money on a system that basically makes your internal processes grind to a halt probably didn't help.
Hearing that you waste half a billion on this really makes me wonder if it isn't much more practical to just develop custom made software in house.
[+] [-] Shihan|7 years ago|reply
[+] [-] Roxxik|7 years ago|reply
Lidl is wasting 500 million euros
Because the introduction of a new data system did not work out, Deutsche Post already had to record a high loss several years ago. The same thing happened to Lidl. After seven years and costs of more than half a billion euros, the planned system is still not running smoothly. Now the discounter has pulled the ripcord.
Lidl has been on an expansion course for years. The discount store from Neckarsulm now has branches in almost every country in Europe and is now also growing in the USA. A new merchandise management system was needed to easily keep track of the increasingly complex business processes and to control branches, purchasing and logistics. Therefor the decision in 2011.
System is not good for high-turnover countries
Software from the Walldorf-based software company SAP was to be adapted to the needs of Lidl. So far, however, the new system has only been introduced in some small agencies in Austria, Northern Ireland and the USA. It has been shown that the SAP version developed by over one hundred IT specialists is not suitable for high-turnover countries. Now Lidl has stopped the project. In one of the newspaper "Heilbronner Stimme" present letter to the coworkers it is said that the actual "goals" are "not reachable with justifiable effort". So far, according to expert opinion, the project has consumed more than half a billion euros - for expensive IT consultants and SAP licenses, for example. Now Lidl wants to further develop its own inventory management system.
[+] [-] gadders|7 years ago|reply
Screen are rarely referred to by name, but have weird codes like XQ44 and are ugly AF. It also has a whole bunch of utilities for fixing up the referential identity on records, importing data etc.
[+] [-] syntaxing|7 years ago|reply
[+] [-] berns|7 years ago|reply
https://www.odoo.com/page/compare-odoo-vs-sap
[+] [-] fargozzi|7 years ago|reply
[+] [-] leviathant|7 years ago|reply
[+] [-] detaro|7 years ago|reply
[+] [-] patja|7 years ago|reply
[+] [-] passing_by_and|7 years ago|reply
[+] [-] zebrafish|7 years ago|reply
[+] [-] _Codemonkeyism|7 years ago|reply
[+] [-] antpls|7 years ago|reply
[+] [-] spsrich|7 years ago|reply