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.

Thanks for sharing, great insights there!

How do you see the chance for classical “low-end disruption” like Christensen described? i.e. small players buy small solutions because they’re cheaper and have less scope. Then larger companies start using the low-cost software etc.

Just look at Concur, Fieldglass, SuccessFactors, BusinessObjects, etc

All were acquired by SAP because SAP can't do SaaS right and filled specific product areas of ERP.

SalesForce is also the greatest example of someone who started fairly small scope (small team CRM) and moved into bigger scope (enterprise CRM + enterprise application platform development).

Seems like Concur has been suffering under SAP based on the outages I keep seeing.

Great insights. Are you seeing startups that grow into multi-nationals adopting SAP? or are their smaller system growing up with their needs? E.g. what does Google, etc. use for ERP?

Google had NIH syndrome to a rediculous degree. I don't know what they use for ERP but when I was there, external software had a shelf of just a few years before a Google engineer was sufficient annoyed to write a replacement in his 20% time.

Amazon is home grown.

Apple is definitely a big SAP shop.

Honestly don't know the others, but I would guess SAP/Oracle (and very likely under very strict NDA).

> 5. What's the alternative? Oracle?

I don't think it's possible for software to suck worse than the Oracle E-Business Suite expenses reporting software.

All enterprise software suck at one function or another.

In expense reporting, at least, sucking really badly reduces the amount the company needs to reimburse ;-)

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.

I've used some SAP-based solutions a few times and the closest experience I can relate it to is late 90s MS Access applications: Everything takes ages. Things that should be easy and quick (e.g. viewing a related record or item) are often difficult and take time. Every form of search function doesn't really work, even with perfect input data. Searching doesn't work if your input is slightly off (e.g. names in wrong order or a typo). Searching takes much longer than makes sense in any sensible manner.

Of course, user's experiences don't matter when selling or supporting a software like this. I don't think it's part of the decision maker's conscious that usability (in the sense of being able to accomplish tasks efficiently) for a software that will be used by a larger part of the corporate workforce might be important not only for the employees using it, but also for the company. These systems can eat up so much work time of employees and create so many issues within a company and in customer or supplier relations...

One of the reasons companies adopt software like SAP is to replace process expertise with software. If a highly paid process expert accomplishes a task in half the time a poorly paid person accomplishes the same task with SAP, SAP wins if the poorly paid person makes half as much as the well paid one.

Also there is a question of scalability - the supply of smart people is limited and depending on smarts is risky. Hiring people that may even be smart when that's not required and that can't do any damage because the software prevents them from doing it will scale better than having to hire only smart people to operate more flexible software.

> One of the reasons companies adopt software like SAP is to replace process expertise with software. If a highly paid process expert accomplishes a task in half the time a poorly paid person accomplishes the same task with SAP, SAP wins if the poorly paid person makes half as much as the well paid one.

Assuming SAP is free both to license and implement. From what I've heard of SAP installations, that's rather far from the normal case.

It really depends on your scale. If you replace a thousand people who earn a thousand more than their replacements, you made a million right there.

> If you replace a thousand people who earn a thousand more than their replacements, you made a million right there.

Well, no, doing some quick research, because SAP annual license costs are substantially > $1000 per user, you've lost something like at least half a million and potentially several million in that case. Just considering license fees, and not other SAP-related costs.

What SAP and Oracle have in common is that they have a very capable sales force, that is able to convince companies that their business case will fit nicely into their model.

Then, once the implementation is ongoing and it turns out that there are some corner cases which were overlooked and that don't fit into the SAP model at all, SAP has another option available: hire their expensive consultants. Depending on how locked-in they are and how big their projects, this can completely destroy some companies.

Do you know of any case studies of companies being completely destroyed by this process? I have certainly heard of such projects getting into trouble, would be interested to know of any cases where it went as far as the customer going bankrupt.

I witnessed one myself when I was working as a consultant. It was a hospital that chose SAP to automate its invoicing system. When the implementation got stuck, the hospital was unable to send out any invoice for almost a year. In the end the money was finished and the government had to jump in and take over.

It is true that the management of the hospital made some big mistakes, but on the other hand it was SAP's sales team that had been very good at giving them opportunities to hang themselves.

Interesting, there must be a good reason for not going back to the old system or a manual system. A year is a long time without Billing and plan B

I've read that Target's botched expansion into Canada was largely attributable to SAP being awful. They haven't gone bankrupt, but years later their stock is still reeling.

There were all sorts of problems with Target's expansion into Canada, I'm not sure you could blame them specifically on SAP:

https://www.canadianbusiness.com/the-last-days-of-target-can...

https://news.ycombinator.com/item?id=10956638

The data entered into SAP was riddled with errors, it sounds like a great example of "garbage-in, garbage-out".

My understanding was that the land Target used in Canada for their stores was leased to them by Walmart (who happened to own it for some reason, even though most of the lots used to be Zellers stores, and Eatons before that.) Walmart gave them extortionate prices and conditions on their lease.

They essentially choked their nascent competition in the Canadian market out of existence in the very same move that enabled the attempt.

Here are two examples where such claims were made:

https://www.computerworld.com/article/2530405/it-careers/sap...

https://www.t-online.de/finanzen/boerse/news/id_47703844/sch...

From the first:> Shane Co. signed a contract with SAP AG in 2005 for a "highly sophisticated point-of-sale and inventory management system," with an original projected cost of $8 million to $10 million and a one-year rollout schedule, the filing states. But costs ended up skyrocketing to $36 million, and the implementation stretched out to 32 months before the ERP system eventually went live in September 2007.

Does anyone offer SAP rollout insurance?

If such a case exists, in my opinion, it would say more about the company than SAP.

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.

Can't they split the project and try to introduce the tool or fail by pieces? I know management and sales wants big figures to compute a mass discount and be in the press, but in the nitty gritty, isn't it better to screw up only part of the company?

Yes - most roll-outs will do phase approaches (unclear if Lidl did this or not). A good strategy is to do a smaller country roll-out for example, learn all of the lessons and then roll it out elsewhere. It's however not a blanket strategy and requires context to decide which is the right way.

Lidl rolled it out in the smaller countries, learned the lesson that it's not going to work, and stopped it.

What I find crazy is that it still took 500M to figure that out.

It took that much for all levels of management involved to admit it was hopeless and for the top level to ax them.

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 looked around https://erpnext.org , got to https://erpnext.org/get-started , where there is a broken link "Start a Free Trial on ERPNext.com" ( https://erpnext.com/sign-up ).

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.

"you could do the same thing for 1% the cost and it'd work better etc."

I used to think that - then I did some work with large scale ERP systems and realised that I was wildly wrong. Fortunately I moved into other areas while I still had some sanity.

Well that's an other thing, when you look at these solutions from afar you often see the core functionality and think it's not a big deal but the devil is always in the details, the millions of small functionalities hidden everywhere for specific tasks is what makes it very hard to compete. Every company has specificities, they want to interface with $external_software, they want to import $arcane_data_format etc... You start by writing a slim and tidy database engine and the next thing you know you have to implement an MS Excel to protobuf converter.

It's easy to underestimate the complexity of an ERP for even a moderately sized company, let alone one the size of LIDL.

ERP systems are basically accounts packages with aspirations for world domination.

From a long way, and I mean a really long way, they seem straightforward - but get close and they are Lovecraftian horrors.

Remember, SAP is how Lucifer interacts with our world.

Whereas Oracle is how Larry Ellison interacts with our world.

A reasonable business case for SAP, I suppose.

I'd take my chances with Lucifer.

Its actually much worse than that. I have considerable experience in a similar class of system, electronic medial records. A common thread I saw in both our PeopleSoft implementation and our EMR implementation was that both are not really packaged products, but platforms to implement our organizations workflows. We were not about to adapt our workflow to some software package so really we buy the product and then spend hundreds of millions using it to encode how we want to operate. By the time you are actually inside the database you typically find a data model that is optimized for flexibility over anything else. So its not really that we need weird connectors, its that we say oh no, we actually have this functionality in this weird department that no one else has with data that is subtlety different from other organizations and a workflow that no one else has. Then repeat that thousands of times.

Every few years, over the past 20 years, I look around to see if there are any open source contenders in the ERP space. There are usually a couple, but you never get to hear about them again. I think it's a difficult space to enter and succeed in and I think most efforts probably underestimate the complexity and isn't funded or run well enough to tackle that adequately.

ERPNext has been around for a decade now and doing quite well! https://github.com/frappe/erpnext.

Founder here, happy to answer questions.

I've been interested in ERPNext for years and always kept an eye on it as an alternative or replacement for our in-house developed ERP, which currently grows in complexity and may end up at a point where it's too much of a burden for a small team like ours.

One area where ERPNext really seems to be lacking is marketing and presentation. You definitely have the features, but I don't think you're doing a good job of showcasing and documenting them, particualrly before I create an account. You try to show those features in Youtube videos, but the production value doesn't seem to be much higher than a private screencast - I'm worried that this kind of presentation actually hurts you.

Another problem is language support. Last time I checked you worked on community based translation efforts, which resulted in experimental international support. May the quality of the translations has improved since then, and of course I could (and did) help, but without proper doemstic language support (german in my case), there's no way I could use ERPNext with our non-tech, barely english speaking staff.

Other than that I've been intrigued for a long time and wish you would not delete free single user accounts so soon (do they still exist at all?) - I tend to try ERPNext from time to time, with long pauses inbetween, and often have to create a new account.

Did you underestimate the complexity? Did you limit scope to not go insane? What is the typical size/complexity of a typical using company? Could LIDL have used your software for 500M€, could they have even implemented their completely own solution for that money? Thanks!

There have been a few very large implementations of ERPNext. If I were to consult Lidl, we would have done a few low risk pilots, starting with their warehouses or back-office.

I would have gone for a federated architecture where each store / warehouse would have its own system that would then be consolidated at higher levels, rather than going for a mega instance with zillions of transaction rows.

There are many interesting things you can do when you have an open source system you can work to your advantage.

I was curious to learn more about the project, and would like to share some quick feedback; the first thing I noticed was that the first page of the documentation which I opened has multiple spelling and grammar errors:

“Distrobutors have large part of their net worth is invested in the stock in hand. With ERPNext, you can always keep a birds eye view on your stock availability, replineshment, procurement and sales.“ https://erpnext.org/docs/user/manual/en/stock

Second, I noticed that the CI build is failing on GitHub.

If you have questions, there is a very active community at https://discuss.erpnext.com

Typo: Thanks for the report. We will get it fixed.

CI: The marker is for the develop branch. So if you are on master, its much more stable.

That is what I tell people that think they could do the same for 1% of the cost: You can't.

I do believe they would have gotten more out of spending 500M on an internal team though.

Care to elaborate?

Consider this:

https://en.wikipedia.org/wiki/Enterprise_resource_planning#F...

The problem is, I think, that using SAP essentially is creating your own solution in-house... but being tied to a certain amount of structure from the start rather than being able to go off and completely do your own thing. The way it’s implemented also doesn’t generally allow for creating small solutions and building up - either the entire project succeeds several years after it’s started, or it all fails.

I once worked with an SAP consultant who had worked on SAP projects that were 100% custom development. They used it strictly as a form-building app dev platform with solid scalable transaction processing and reporting capabilities, and used zero of the pre-defined configuration or data structures. I think they had a bit of the "when your only tool is a hammer" mentality.

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.

I think the big attraction of SAP is that it lets CEOs smooth out earnings.

They can get projections of what the number are going to be for the quarter continuously so in the last few weeks of the quarter they can speed up or slow down sales and spending to hit the earnings numbers they want.

Not sure why you are being downvoted - I used to know a guy who had been head of sales for a large tech company that you will have heard of and he said they did exactly that - delay sales from one period to the next to smooth things out and to be closer to market expectations.

Their sales contracts apparently had clauses allowing them to delay sales for just this reason.

NB That kind of sales reporting isn't just from SAP - Oracle Hyperion and IBM Cognos are the biggest players in consolidated financial reporting.

Cisco Systems used to be renowned for hitting consensus revenue projections precisely, always consensus +1 cent.

That kind of "management" is a red flag IMO.

And the "wanting someone to sue in case things go wrong" strategy is typically a pipe dream as well - you're simply fucked and paid a lot of money for nothing in case things go wrong.

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.

Is this situation not produced by the "nobody got fired for using IBM" mentality.

Supply chain may be complex but for heavens sake, 500M euros! and not complete. I can do it for half :)

When Oracle is your alternative, SAP suddenly looks better.

>In the late 90s/early 00s a lot of people had seemingly infinite trust in IBM.

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".

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.

The moment you touch anything related to accounting or subject to laws / regulations, stuff gets very hairy.

There might be more offered by SAP than you are accounting for. You would have to re-create all of the features for things like demand management aggregated forecasting by product line, including integration with supply chain ordering and EDI integration with your global suppliers and customers. You might also need a solution for maintaining separate general ledgers for local hyperinflationary accounting requirements in Brazil in parallel with GAAP reporting in the US. And those other services such as HR and invoicing...they are also all in the box with SAP if you choose to go whole hog.

OpenERP is not Django based IIRC, but they basically thought the same thing and went at it with some good success.

I seriously doubt OpenERP has the same scope as SAP. It works for smaller structures but, like mentioned before, if your operations cross too many national borders, things get insanely complicated really quickly.

That is one hell of a Django app.