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.
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.
As a former consultant in SAP - Most companies aren't that unique in how they execute most processes. For instance, AP payments generally looks the same at a high level. For the variations of business processes, SAP gives you lots of room to modify configuration to fit your process. If you're in a specialized industry like Aerospace or Oil and Gas, they have unique industry specific solutions.
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.
>Most companies aren't that unique in how they execute most processes
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.
> SAP failed implementations are unique from other software failed implementations.
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.)
The last big project failure I had was due to the company selecting the right technology for the problem, but the wrong one for the company culture. The company's engineers were young and viewed themselves as a startup, which means they like to use bleeding-edge solutions. The company themselves were an old enterprise with well-worn problems, and picked exactly the technology they should have. Unfortunately a newer, sexier product was part of the selection process, and the engineering staff didn't like that management picked the "wrong" one. They stonewalled the project until it failed, management complained about how inflexible the product was, and they switched to the other, newer, sexier product (I work for a vendor-agnostic consulting organization, so I stayed on for both products) and we ended up developing custom solutions for every problem we encountered with the new sexy product. Solutions that were solved out of the box with the older and more mature product.
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 last big project failure I had was due to the company selecting the right technology for the problem, but the wrong one for the company culture.
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.
Usually there’s no interface to addressing such problems.
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?
> Usually there’s no interface to addressing such problem
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.
> It was $110m down the drain on the first product
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?
The $110m spent on the first product was the cost of the product plus the consultant time to implement it. Both of those were sunk at that point and could not be refunded. The decision was made that Product A was not working for the company's needs, and listening to the engineers, the executives decided to switch to Product B. The blame went to Product A and the company that makes Product A, because it's pretty fashionable to hate them right now. "The product is outdated, it's inflexible, it's not able to be customized" and so on. Product B was brought it and it's so much more flexible since it includes absolutely nothing out of the box, so more money was spent on custom development to build the batteries that Product A includes by default.
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.
Thanks, extremely insightful. I've never worked on projects worth more than, say, 5 million euros so these 100+m projects have a sense of scale that's hard to comprehend.
No, your company isn't special. Look at it from an engineering perspective. The law, by which I mean all laws that you operate under—local, regional, state-level, federal, international alike—is really not much more than a specification that you have to adhere to. More active markets and more rules and laws you're bound to just means a more complex set of specifications. Just like in the software world, we need a process, an implementation to adhere to that specification in order to do business by it. And at the end of the day, if two different implementations are compliant to the same specifications, the complexity of moving from one to another is always going to be minimal. One particular caveat is even similar to software engineering: if you're doing special, non-standard stuff outside of the spec, you should probably not be doing that at all.
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.
This is true, with the caveat that most points are clustered. It is possible to translate from one point to another (the "one SAP true way", for instance) within this space by re-engineering processes. Parent's point is - this is easier than most people assume - especially those who say "our business is unique"
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.
There is a bit of uniqueness that companies actually have, and the rest of “how we do things” and “what our processes are” is basically a symptom of inertia and - how the last system worked. It will turn out that every process and every structure is influenced by the system that is used. They are one.
So the idea of customizing a business system to fit a business doesn’t exist - in reality it’s often customizing it to fit whatever the last system did (to processes and structures), which is something else, and not nearly as great sounding an ideaas “tailoring a system to our unique business”
The key is to identify what parts of the process are “how we always did things, but for no apparent reason” which probably turns out to be a lot of things. It’s painful because it causes a lot of turmoil when everyone has to question every process. But it’s good pain.
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.
Frankly doing an SAP installation with no customization is no different than using a SaaS platform, there are a lot of options, but no code customizations.
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.
The book Softwars spends a lot of time on this topic, where Larry Ellison blasted all of his integration partners for over-customizing their solutions when the correct approach was to update the business processes to match the software:
So, let's say you manage to update your client's processes to the ones that best fit the SW you are selling. Eventually, the time for upgrading will come. Magically the specification for the new system will be: "it has to work exactly like the last one", and the last one will naturally happen to be yours.
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.
I make custom systems for a living, I also support a CRM/ERP solution for SciFi conventions which often has custom enhancements for customers.
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.
> That sounds just about like the most revolting and negative endorsement you can make for a business solution.
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.
There's usually some happy or at least less unhappy middle ground.
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.
Yes, every company is special. That doesn’t mean your company has any valid justification for being special, instead of adhering to standards that business technologies can be targeted toward. Most ways that companies are special are just ways that those companies are broken. (Calling to mind the classic “Happy families are all alike; every unhappy family is unhappy in its own way” quote.)
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.
This pretty much applies to _all_ software development as well, especially in a standard environment like ERP. There is not much need for new stuff, just learn the ropes for what already worked the last ten years, then handle the complexity of enterprise life with simply applying them. Creativity is only useful if you can handle >90% of the cases with ease already.
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.
I’ve rolled out SAP throughout all three of our SME-sized family companies. My mantra has always been ”we don’t install SAP into our company; we mould our company into SAP”. Ten years in and the strategy seems to have worked.
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....
The psychology is fascinating. I worked at a place with a heavily customized fork of a vendor system which was almost old enough to drink. They had a stable of developers in an increasingly uncommon language, upgrades were year+ exercises with hefty consulting bills, etc. but most of the management were convinced that this was the easiest option because everyone was used to it.
Sap brings transparency to the processes inside your company.
You don't know what is happening in the mind of you accountant on the other side of the World. How bills are issues and if these are payed correctly and in-time?
How do we choose credit control, who is approving purchasing spends?
Internal and external audits could not see whole picture and they are not there all the time and even more - if someone would like to hide something from them it could be easily done in most cases.
The profit is in having the ability to upgrade on a whim, to refer to the masses of documentation and expertise without having to translate it into your own lingo and to use off the shelf components without needing to customise them too.
Plus hiring and getting new employees up to speed is much much faster. This is especially useful with SAP consultants who are quite expensive. The initial cost may be high but once it's done it's savings at every step.
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.
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.
> Kill cords are a thing (on powerboats, particularly) and the original metaphor is fine.
The expression "pulling the plug" is idiomatic English (at least in the North American variety). "Pulled the kill chord" may be an accurate metaphor, but the audience is far less likely to be familiar with the reference.
Which is good advice if the audience is exclusively American and fears difference, diversity or the unexpected. Other than cord/chord (which my brain quickly dismissed as a typo) the original post sounds completely fine to me.
FYI, especially those who took this the wrong way: GP said he's practising German, so I simply offered how I (native German) would've translated it a bit differently. I never said and certainly did not mean to imply that "mine is right" and "his is wrong".
I'm betting it's inventory turnover (e.g. busier stores). It sounds like they were have problems with the inventory management component of SAP keeping up with the rate and volume of transaction that they were putting through it.
In the context of a retailer, "high turnover" means that individual products spend very little time on the shelf before being sold, and they are replaced with new products very quickly. For LIDL that means places where they have very busy stores. These places are "lucrative" because they are busy, but are not at all "high profit" - they sell products with extremely small profit margins.
> 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.
Absolutely. The bar we always tried to hit was whether the process we were being asked to change was represented a fundamental way in which this company was intentionally different from other large companies, or whether it was just the way it was before they saw what the SAP version looked like.
90% of back-office stuff is exactly the same between very large companies no matter the industry or history, but that is very hard to get across to the career accounting manager who designed those processes and now is having SAP shoved down their throats.
Secretly, I always suspected that one reason for bringing in SAP was that the senior executives recognized how inefficient their backoffice was but weren't willing to force huge process changes and create ill-will for barely marginal benefits, so they hired SAP to come in and be the bad guy to argue about it for them. Then they can say "Yeah man, SAP sucks, soooo inflexible, I argued against it but what are you gonna do, changing it is really expensive, I guess we'll just have to do it their way" and message boards fill up with complaints about how inflexible and expensive SAP is. Funny how that works!
> Then they can say "Yeah man, SAP sucks, soooo inflexible, I argued against it but what are you gonna do, changing it is really expensive, I guess we'll just have to do it their way" and message boards fill up with complaints about how inflexible and expensive SAP is. Funny how that works!
Scapegoat as a Service. I wonder just how common this is in practice.
I think it depends what adapting means. People often (and I guess LIDL fell for that too) just think they can adapt everything to their needs and that really is not possible. A lot of processes benefit more from changing the processes than the SAP implementation of those processes. IMHO.
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.
Nope, but from what I hear the systems are old, organically grown complex systems (see other commenters here that worked for/with SAP and shared their story). I doubt Lidl can quit on SAP altogether, it's rather the question of how to achieve the business goals with SAP in use.
Seems like all the more reason to hire a couple more employees than trying to save an infinitesimal amount playing games to pretend that they’re contractors
Why should freelancers be forced to become employees? And how is Lidl supposed to find suitable candidates, if - as I said - the most capable and suitable ones, are freelancers?
Who said anything about forcing anyone? The problem described was LIDL sacking a bunch of people who had worked exclusively for them for 6 months and presumably would have been happy to continue doing so, except that LIDL would have had to pay a little more tax.
Also, if you can’t find people to hire for a mission critical system, that’s a strong sign that you either need to not make it critical or start aggressively investing in training — which is still considerably cheaper than a 500M write-off.
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 the most realistic answer here. SAP is legacy software. Any company that has been using SAP since the 1990s is still probably running parts of software that were written around that time - or even earlier (!)
Actually, this leads to the same types of problems that everyone is discussing here over 'customizing'... at the root it is a collision of ever larger growing global companies with ever-increasing complex process that must rely on older and older code (or customizing) bases, because stopping everything and doing a total overhaul just isn't feasible at such scale.
Every custom program or customized process brings rise to a future risk of headaches/breakages when the system is upgraded, a process is once again changed, or something should be added to the process.
I guess the best analogy I can think of as an ABAP developer, is that it sometimes feels like running on a treadmill that just keeps getting faster...
Someone commented above how IBM used to be the company that was infinitely trusted... and indeed, SAP itself as a company is certainly not at fault, but until the environment changes with SAP customers and all their custom code and processes... I guess only time will tell...
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.
There is never just one project. So these employees can keep improving the original project and create new ones. Do you think these consultants will do all that maintenance? Many projects fail before release and others just last for a few years. A government owned software department would be a great way to save money and improve all aspects of the application life-cycle.
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.
$150 per hour is on the low end for good SAP consultants. We were paying $300 per hour for some InfoSys SAP HANA people, and even independents were around $200+.
If they're doing anything beyond vanilla consulting work with SAP then I doubt they're using cheaper offshore talent. Or maybe they are and that's why this project has failed so spectacularly. (Note: I'm not saying all offshore talent is hot garbage, I'm saying the cheap talent is hot garbage, especially SAP consultants).
I think that price is a little inflated. 1200€ a day for a freelancer maybe, but the "normal" consultants will cost no more than 800-900€ a day because of blanket orders, etc.
My thoughts on this having worked in a team doing an ERP (think SAP lite) and now working in a sap shop (my job often involves avoiding interacting with SAP to the maximum extent possible):
ERPs are hard. ERPs are not software for modelling business processes, they are software for creating software that models business processes. And at the next layer you have all of the shortcuts that the vendor and the customer took during getting something that works out the door. Which happens a lot, at both levels. This is of course a recipe for fun interesting times with lots of billable hours.
Problem is that many companies when starting SAP implementation ending up building their own ERP on top of SAP. And that is ridiculous waste of money.
From my experience that is mostly due to internal company politics and lack of IT management skills.
Just one example : we had a big implementation in the big region where Implementation manager for SAP introduction was originally from. He was approached by some factory director and asked if we could change the standard process as "You know we have these guys working for years and they are not very adaptive for changes..let's make it easier for them, will ya?" And Implementation manager agreed. "As ERPs come and go, but connections and people stay there". So it took 3 consultants + 2 developers three months to rework the process. It later was not working perfectly, so many bugs and enhancements(as these guys couldn't stop asking for more changes) caused more money spent in support.. And it's just one episode in several years long implementation cycles.
On other hand I had very smooth implementation in TOP 50 company. But for them it was not only to implement as software, but also to audit their internal processes and to eliminate waste. There dedicated Implementation Manager started introduction to SAP with words: "We are Columbus, SAP is as ship which will bring us to America. And wont be easy, but I hope you will all jump on this ship otherwise we will have to leave you..".
SAP ERP is made for standardizing and simplifying processes, so just don't invent light-bulb every time you need a light in a room.
That is an unbelievable amount of money to waste on a cancelled project. It's funny how these turn into an ego thing for the project owner. If the person in charge has good links and reputation, they can keep getting funding year on year, even when the project has gone bad. Usually they are good talkers, but bad executors and have been at a firm for a significant number of years (so people think twice about firing them because of the severance package alone). I've seen this at every investment bank I've worked in, with projects racking up GBP 40m in spend before getting canned. I suppose it uplifts the GDP at least...
Looks like they canceled it in the testing phase and noticed it simply didn't work or under performed. With those very expensive consultant hires (SAP is notoriously expensive, both licensing and consulting) it might have been cheaper to cancel it outright then to dragging it along. I applaud their idea to do it in house as they are big enough to have IT/Supply line software as a core principle which can save you money in the end, and not as an external expense which is just an annoyance.
I think it has to with peoples inherent lack of discounting sunk costs. “We have already spent X amount. We must make sure it isn’t wasted, so let’s spend Y more and see if that’ll fix it”. At least they pulled the plug.
It often isn’t clear that spending Y more won’t fix it, or that spending Z on a new project will - by the time you’re anywhere near half a billion euros into a project you’ve already worked around an incredible amount of unforeseen issues, lost cultural knowledge about them once they’re fixed, and there’s every chance that those issues (or more) will show up again if you start from scratch.
I have worked in three organizations that used SAP. All three had problems and the high sunk costs made it hard to move elsewhere. I think a good way to measure theefficiency of the systems is to call three random admins or secretaries at an institution. In my experience, everyone complained about version incompatibilities, speed, logic (I got to see the UX once, it was a nightmare).
I would estimate using the SAP systems costs about 10% of productivity (net after gains through digitalization of processes).
Problems with new data system: Lidl blows 500 million euros
The Lidl brand plate at a branch. Picture: BR/Herbert Ebner
Lidl has been expanding for years. The discounter from Neckarsulm now has branches in almost all countries in Europe and is now also growing in the USA. A new merchandise management system was needed to provide an easy overview of the increasingly complex business processes and to control the stores, purchasing and logistics. That was the decision made in 2011.
System is not suitable for high-turnover countries
Software from the Walldorf-based operating software group SAP was to be adapted to Lidl's needs. So far, however, the new system has only been introduced in the small agencies in Austria, Northern Ireland and the USA. This has shown that the SAP version developed by more than a hundred IT specialists is not suitable for high-revenue countries. Now Lidl has stopped the project. In a letter to the staff of the newspaper "Heilbronner Stimme" it was stated that the actual "goals" could not be achieved "with justifiable effort". Experts believe that the project has already cost more than half a billion euros - for costly IT consultants and SAP licenses, for example. Lidl now wants to further develop its old merchandise management system.
Join a SAP customer or SAP integrator. At a customer you'll normally get sent on several multi week training sessions. At integrators you'll get some PDF's and be thrown in the deep immediately. As a junior, the pay is bad, so be sure to move on quickly, don't stick around at the same position (this is the norm). After 5 years or so you should have multiple certifications, a few war stories to tell and the contacts to become independent.
The IT part of SAP is quite small and easy to grok if you have CS training, what you will learn is mostly SAP specific terminology, the details of the business process(es) you're working with, learning to work with outdated software packages and learning to work around people in an IT role who have no interest (or skill) in IT.
What I came to realize after reading all these insightful comments is this: whenever a company buys SAP, they also buy an ERP or whatever system but, most often, they buy first and foremost safety. Safety that everybody else is using the same system (social proof). Often this includes the personal safety of the CIO for not getting fired if anything goes wrong...
The article says that in the end, “Lidl” decided to ditch “SAP” and continue developing their own, internal solution. From my own experience: good on them; it’ll certainly cost them an order of magnitude less, on the order of five million, to get it going again and then maybe 750 grand a year for the staff salaries. Good on “Lidl” for going back to classic IT.
> and then maybe 750 grand a year for the staff salaries.
That is completely unrealistic, it arguably won't even cover the operations teams that you need to have in place for keeping it running and the teams for maintaining and updating the software are going to be a lot more than that.
Even two good full stack, experienced system engineers are enough, and their combined salaries won’t come anywhere close to 750 grand a year. Hell we could engineer you high performing, high availability infrastructure around it for just several grand, and you won’t find any of the usual enterprise garbage like DELL/hp/Cisco/hardware RAID/SAN in the delivered solution because we design our own systems from bottom to top for performance, reliability and economy. Are such people hard to find? Yes they are, but it’s clear why.
A colleague and myself handle many such applications by automating the living daylights out of everything around them. I just finished SAS integration system engineering project, fully automated. Two weeks’ worth of work which took the previous engineer six months non-stop. 750 grand was a generous overkill.
And you have variance in the industries, location, travel requirements presumably, etc. Sure. But with a project of this size and scope I'd be impressed if they'd be able to find (great) devs wanting to work on it below 65-70k and not quit after a year. IMHO and so on based on way smaller projects.
I think if you're going to link to a non-English story you should either find an English version of it and link to that or host a translation of it somewhere yourself. This after all is why I have kept from posting some interesting Danish content.
As a HN reader, I would ask you to _do_ post Danish content, or in any other language that you know. There is so much more info on the web that is not available in English. And once we know about, Google translate helps to read it.
Looks like the only source is a letter from Lidl to employees that a local newspaper ('Heilbronner Stimme') got hold of. Lidl is usually very secretive.
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.