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.
That sounds just about like the most revolting and negative endorsement you can make for a business solution.
Every company is special and the flexibility to adapt to a changing environment is what keeps a company alive during those times of crisis, that always come. "We can't do this because the system does not allow it" is great and expected at the warehouse worker level, annoying at the branch manager level and catastrophic at senior management level.
I've seen the flip side where people custom code the heck out of the system. That becomes impossible to upgrade and impossible to take advantage of new features.
I've also seen lots of bad processes continued that could have been re-engineered to be good processes if the implementer and business had an honest conversation. SAP for better or worse forces these conversations by limiting the ways that you can implement the solution.
SAP failed implementations are not unique from other software failed implementations. It doesn't fail because of the product; it fails because of the people and politics of the organization. SAP tends to make the headlines because of the size of the implementations and the eye watering costs.
As a current "big expensive system" consultant (not for SAP, completely different company and line of work), I 100% agree. Every single client I've worked with has shown me a network diagram and with a grin asked if they're the most unique company I've ever worked with. The answer is almost always no. There's just not that many unique ways to do things, and it always comes down to two or three very similar processes done by two or three very similar pieces of software done in almost exactly the same way that produces almost exactly the same result.
The only thing that sets "unique" companies apart is a lack of culture, or a negative culture. Like you said, bad processes that could be re-engineered into good processes if only the company was able to be honest with itself. Unfortunately changing people and process is harder than changing technology and vendors, so if something doesn't fit perfect you just throw away hundreds of millions of dollars, throw a fit in the press, and never address that your company culture is so inflexible that no major project involving an outside vendor could ever possibly be a success.
No, they aren't.
> It doesn't fail because of the product; it fails because of the people and politics of the organization.
Essentially all project failure are for that reason. (Including ones where one intermediary step on the route to failure was that the people and politics in the organization ended up selecting a solution that was a poor fit for the problem.)
It was $110m down the drain on the first product, then another $80m to purchase the second, plus the cost of my consulting time to create custom solutions.
People and politics are the hardest part of any technology implementation. Any article I see blaming SAP, IBM, Oracle, HP, etc of botching a multi-million dollar public project, I always have to wonder: who went wrong... not what went wrong.
The company culture is a central piece of any business problem you are addressing, if your solution doesn't address it, it isn't addressing the actual problem, but at best a lower-dimensional projection.
Interacting with the cultures of some companies is like trying to treat the mental illness of someone in a dissociative fugue state. You might have a solution that fits how things are on the inside—but how are you going to even get through to them to communicate that, when they can’t hear or see you and are instead lost in their own little world?
I think you mean correcting culture to some preferred ideal, and that's likely true.
But what I'm saying is that institutional culture is a factor of every problem facing the institution, whether is a thing to fix as part of the solution or a constraint on viable solutions.
What happened afterwards? Did this trigger management to consider why the purchase was the wrong one? I.e. was it a $110m lesson? Or was it really wasted money?
My company did cut a deal on the consulting for Product B since we had already been working for them on Product A, but the products were charged at full price and to my knowledge none of the cost of Product A was returned to the customer.
As far as management was concerned, Product A was a failure because it was old and inflexible. Management was super happy to see every screen of Product B with their logo on it, which we put on there because we had to develop those screens from scratch anyway. Product B didn't have their logo in the upper right corner, it only had their logo on the printed output.
The only lesson learned was "ask your engineers what product they recommend", which I guess is an important lesson regardless.
In the specific case of SAP, if the problem is "we want to automate our processes" then it's probably a horrible fit.
If, however, the problem is "we need good automated processes", then it can be a great fit.
This is a fun analogy, but in the world of enterprise-level business, the business often is software. Entire businesses today are ran by software, and that software is written according to the same set of specifications: the law. The small particulars that don't have to do with law or common business practices are pretty much reducible to implementation details.
SAP is one such very comprehensive implementation, that is very possibly the only software suite that has a nearly full coverage of the entire "spec" for business purposes. If you can't translate your business operations to SAP, beg your pardon for my abrasiveness but you're doing things wrong.
Coca Cola does their financials the same way Pepsico does. Yet both companies have tried to implement them in unique ways and subsequently have cost them a great deal in terms of IT implementation costs that offer little to no competitive advantage.
I’m strongly agreeing with the GP: it’s both better and cheaper to at least meet half way with software like this. It’s simpler to change processes than to customize business systems.
What becomes painful is that the deployment of some new business system now became a massive reorganization and a complete overhaul of all business processes. But this is still less painful than customizing SAP to any large degree.
All the processes had become "unique" over time, not because the company was special, but because they were coding their own solutions and either the IT staff or the business wanted something done for the benefit of the specific department.
Once the processes were evaluated with a critical eye toward what actually needed to be accomplished, the uniqueness of the existing process couldn't stand up to scrutiny.
Luckily the CIO and the CEO had the courage to face down the IT staff and business leaders, the rank and file cheered for adopting standard processes, they knew the existing processed sucked.
Who wins? The customer? Maybe (how clumsy it may be, he now has a stable, supported process, after all). The vendor? A thousand times this: he has successfully locked-in yet another client, foraging on its inertia.
The real answer is to meet in the middle - sometimes the you have to be willing to tell the customer no - its just how it goes - and sometimes you need to go back and bang on the developers to go get it to work the way the customer thinks it ought to, because the customer is correct, and the devs do not understand the use case.
The key is, dont tell the customer no too often, and dont bang on the devs too often - you gotta strike the balance, and only experience can tell you where that magic line is.
A lot of these larger software packages support different levels of customization, and they usually press people to use the simplest stuff.
It's not completely possible to guarantee reliability once the customer is writing their own code. You can guarantee the app doesn't fall over, and data isn't lost, but ultimately the customer is free to shoot themselves in the foot, and they will.
Yes, businesses often have unique needs and sometimes they're so unique and so critical that they're worth heavily customizing for.
On the other hand, I like telling a story from not that many years ago when a very small business (I'm talking like 10 people) wanted to get off running their own Exchange server. Exchange made sense when they set it up but Gmail and the like had come on the scene since.
The CEO eventually had to mandate it because the person who ran the business side of things was incredibly strongly opposed because they were used to storing emails associated with contracts in a hierarchical folder structure and, at the time, Gmail didn't support nested labels.
In that case, change how you do things to match the software was absolutely the right answer.
FTFY. There's huge benefits in using standardized solutions, like faster upgrades, and fixes to bugs you even didn't know you had but that were solved for other customers.
Look at it like any other utility infrastructure: if you want your factory to hook up to the same power grid as everyone else, it’s your factory that’s got to change, not the power grid. Or do you want to spend half of every new factory bring-up winding your own three-phase-220V-to-five-phase-39.2V transformers to meet your “unique” needs?
A company must consider whether its business processes are a competitive advantage. In well established businesses, chances are they aren't. In that scenario, it really doesn't make much sense to stick with them.
And for a customer of enterprise software I would so much agree. In my experience the people who manage the integration with third party software usually have no clue what the software is about. Instead of being arrogant it would be much smarter to learn from the software vendor, who's an expert in his field and has seen dozens of customer environments, how to solve certain problems.
exactly. People from "unique" camp fail to recognize that SAP isn't just software, it is "best [business] practices" coded into that software, the practices distilled from huge experience during many years with many customers. Granted, for many techies any business practices/processes and related software look disgusting - this is why we're techies, not accountants. At some point in the bright future we'll develop super AI which will take over the world and abolish business processes....
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.
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.
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).
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).
I don't think it's possible for software to suck worse than the Oracle E-Business Suite expenses reporting software.
In expense reporting, at least, sucking really badly reduces the amount the company needs to reimburse ;-)
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.
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...
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.
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.
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.
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.
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.
The data entered into SAP was riddled with errors, it sounds like a great example of "garbage-in, garbage-out".
They essentially choked their nascent competition in the Canadian market out of existence in the very same move that enabled the attempt.
Does anyone offer SAP rollout insurance?
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.
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.
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.
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.
It's easy to underestimate the complexity of an ERP for even a moderately sized company, let alone one the size of LIDL.
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.
A reasonable business case for SAP, I suppose.
Founder here, happy to answer questions.
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.
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.
“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.“
Second, I noticed that the CI build is failing on GitHub.
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.
I do believe they would have gotten more out of spending 500M on an internal team though.
Except an expensive fashion item doesn't ruin your ability to do your job and is still probably cheaper in relative scales.
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.
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.
That kind of "management" is a red flag IMO.
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.
Supply chain may be complex but for heavens sake, 500M euros! and not complete. I can do it for half :)
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".
Of course, at the fraction of the the cost of the SAP solution.