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