Hacker News new | past | comments | ask | show | jobs | submit login
What's SAP? (retool.com)
1221 points by dvdhsu on Feb 5, 2020 | hide | past | favorite | 600 comments

I teach enterprise systems at a university, with emphasis on SAP.

It's hideous. Hideous. My students complain it is unusable (agree), doesn't make sense (agree), that they can't see the point (agree).

When you look at the underlying database 'schema' (inverted commas deliberate) you'll find it's a massive, denormalised mess.

Much of what SAP can do can be done at the local level using intuitive software. Reports, for example, against a well-designed schema or data warehouse are easy. Power BI, Tableau, whatever your poison. You can even aggregate and present data in raw SQL if you like. Each technique is far easier than trying to achieve the same in SAP.

What SAP does do well is multinational, enterprise-wide integration. Are you a company comprised of many mergers and acquisitions? You can do HR one way, universally, across your organisation. Credit control? Replace your spreadsheets and custom apps you have deployed across your many siloed finance departments with the FI/CO modules.

I (am actually told to) teach that changing the business to fit SAP is preferable to changing SAP to fit the business. And it's accurate advice. It shouldn't be, but it is. SAP is SAP. It doesn't care about your USP. Or your custom approach to business. As far as SAP is concerned all businesses are the same, they do the same things, and all must conform. Resistance is futile.

> SAP can do can be done at the local level using intuitive software

No they cannot. ERP's are beasts of expert domain knowledge hidden in shitty codebases, but don't be confused for an even a moment to think you can do it yourself. It's a fools errand, and I'd fire or not hire anyone that tried to intentionally do this rather than just build something basic to hedge time until you have to implement something more serious - be it SAP, Sage, Dynamix, BlueCherry, NetSuite etc.

Also good luck passing an accounting audit with your vastly inadequate internal tools. Did you implement GAAP? FIFO for inventory? Tools to provide receipt of goods scanning and reconciliation vs the original invoice? How about split shipments of PO's? Landed costs? Accrual accounts?

How about providing your accounting, finance, planning, and merchandising teams with the tools they need to get their jobs done? I'm sure you'll be super happy you spent a year building those internal tools only to discover no one likes them because your team lacked the context and domain expertise to understand all the nuances of how things come together and the business processes the tools and ERP modules supported.

The problems that ERP's solve are incredibly esoteric and require incredible expertise across a number of fields to appreciate why things are done the way they are (horrible code/APIs aside).

The correct answer here is "it depends".

SAP isn't (just) a giant pile of steaming data model mess because of the thousands of people involved building that software, but really because it can model every tax case in every country in the world. Thought you had a great model for your sales tax that covered US and the EU? Well, enter Brazil and think again, with four slightly different taxes, some of which are applied on the net and some on the gross amount.

Then again, if your plan does not include entering Brazil, you might actually be better off using smaller or your own software, as configuring SAP to do what you want it to do is often on par with writing your own system from scratch.

There's a slight shortcut to that, which is using industry templates, but these only fit established business models like Telcos or Ad Agencies.

As our business model in the movie marketing industry was sufficiently different to everything existing, it was clear we would have to bend the limits of any COTS ERP so much that building it ourselves seemed like the saner option.

So we've dared to build our own multinational and fully integrated CRM and ERP system specifically for our industry and business model and so far, we really love the results (biggest client just saw our tooling stack and told us we're 10 years ahead of the ad agencies working in the same space).

But make no mistake, if you don't know exactly what you're doing (I have a slight background in finance, accounting and two failed SAP integrations), you're probably screwed one way or the other. I would recommend almost anyone to not build this kind of system from scratch.

> configuring SAP to do what you want it to do is often on par with writing your own system from scratch.

Hyperbole. A lot of working with an ERP is developing middleware or custom modules that implement business-specific logic on top of an existing API and schema. It's like saying building a Facebook App is equivalent to rebuilding the entire Facebook Platform.

> So we've dared to build our own multinational and fully integrated CRM and ERP

I hear this all the time, and it's almost always wrong. Engineers and businesses are always convinced they're special and don't fit the mold. That's rarely the case, and the money used on these initiatives was probably better spent elsewhere. Usually when someone thinks they have some sort of special edge case or unique business, it's more often than not they don't understand GAAP/IFRS/IAS etc and how their finances can be modeled.

At the end of the day it's about capital investment. Either you believe you can do it better and you're willing to back it with money, or you realize it's not core to your business and buy something off the shelf because it delivers the best bang for the buck and more importantly lets you focus on other projects that are actually aligned with your business model.

> if you don't know exactly what you're doing

There's the caveat. You either find someone that's worked with ERP's for at least 20+ years, or you build your own over a decade and gain it 1st hand.

> A lot of working with an ERP is developing middleware or custom modules that implement business-specific logic

Indeed. It does, however, seem that these are developed on a system that isn't designed to intuitively express the degree of logic required - or even trivial logic. There are poor souls slogging through whichever level of hell uses SAP for customer relations, purely because that's the way it's done. That attitude worked out poorly for taxis, who's shitty UX was replaced by Uber.

I predict that millennials, who increasingly refuse to interact with anything below "app quality," won't bother with this horseshit. There will be fewer and fewer willing to subject themselves to that awful software, as developers, and everyone will build their own faulty but usable ERP systems.

ERP will be a unicorn in the next decade. The industry is ridden with complacent dinosaurs.

To give you an idea about the real scope of what is behind an ERP system, here is a link to the database definitions behind QAD's MFG/Pro:


This is a product designed for small to medium sized businesses so it is not as comprehensive as a SAP. Take a serious look at the schema and imagine if you just had to write CRUD, it would take hundreds of man years. But it is not a CRUD app because there is business logic behind ever module.

Now imagine that there is also a whole ecosystem of vendors that sit under the QAD tree to provide niche solutions for the various use cases not covered by QAD. So not only do you have to write the ERP, but you have to write the pieces picked up by the other vendors in this ecosystem.

Is this supposed to pass as documentation? Looking at that document the first reaction is that I would rather spend a decade implementing my own ERP than go anywhere near that mess.

I get that a list of tables and fields is not great documentation by itself, but QAD also provides ERD diagrams, implementation guides, user guides, administrative guides, and other documents. The overall quality of their documentation is outstanding. I worked in a QAD shop for over ten years, and their documentation is complete, accurate, well organized, and easy to understand.

This looks ... terrible. I bet it works and delivers value or something, but that doesn't mean it's something to be proud of or to defend how it's designed.

I mean surely there is a better way than thousands of database tables ... with separate business logic.

Do I understand correctly that for a "small to medium" business, they would only use a fraction of the functionality / database tables, but in order to support all potential "small to medium" businesses, it needs to be this convoluted mess?

> developed on a system that isn't designed to intuitively express the degree of logic required

The poor souls are such because they usually fundamentally do not have the knowledge required across the broad spectrum of responsibilities an ERP does and how that all ties into managing a business.

> I predict that millennials, who increasingly refuse to interact with anything below "app quality,"

This makes no sense. What do millennials have to do with anything? I fail to see how a generation label makes any difference to how ERPs are involved in business management and how accounting and finance in general work. How supply chains are managed isn't going to change because of a bunch of woke millennials.

> everyone will build their own faulty but usable ERP systems.

Always said by people that do not understand what an ERP does and the complexities involved in managing a business. I used to think this way myself, until I actually had to deal with these issues in a senior management position with investors breathing down my neck. My naivety was amusing in hindsight.

> How supply chains are managed isn't going to change because of a bunch of woke millennials.

Parent's point was that systems require trained and capable people.

If the job entails dealing with something arcane, and you can't pay more (because cost center), then at some point you face a labor gap.

I can't see this happening any more than mechanics influencing how engines are designed. It sounds nice to rah-rah-rah the revolution, but ERPs are the dark underbelly of business are not going away any time soon while we depend on the 3 statement model.

Well, "app quality", you mean those shiny UIs with abysmal usability. Because usability is more about the behavior of a syste m then removal of button edges. ERP and SAP is definetely neither sexy nor hipp nor woke nor does it have an even acceptable usability, but it doesn't have to. It has to help making money. And that's a business, as tough as they come.

> I hear this all the time, and it's almost always wrong. Engineers and businesses are always convinced they're special and don't fit the mold. That's rarely the case, and the money used on these initiatives was probably better spent elsewhere.

That seems like big statement given you have no context about the person making it.

I also work on a team that has built large potions of this intentionally and willingly. And the results have been great.

The reason is we don't hand off our business to a black box part way through our business process. We own it. Top to bottom.

This means when we change the products we sell, how we sell them and how we support them, we know the impact on our back office, reporting, invoicing and accounting systems. And vice versa

Yes owning the whole stack is expensive. But we also have parts of our company that rely on ERPs and other similar products.

I can tell you very clearly that our ability to develop products is an order of magnitude faster and cheaper than those relying on an ERP.

And for those who wonder how hard can it be to understand those accounting standards, this is what a typical accounting standard book looks like:


This thing will definitely hurt your foot if you drop it.

So your point is basically that everybody should keep using badly complicated software forever because they're not that special and what they really want anyway, is beyond their mortal comprehension.

Seriously though, how do you envision a future where a leaner, better coded alternative appears?

Also honestly, why are you being so defensive about it.

The key insight in what you wrote here, "(biggest client just saw our tooling stack and told us we're 10 years ahead of the ad agencies working in the same space)", is the word client.

If you are going to build your own ERP software, make sure that is the product your company is selling. The same goes for building a new 'web framework' for your web company. Never build a complex product from scratch if that isn't going to be your business. It never works out, because when you have to choose between revenue and improving something in your framework, you'll going to have to chose the former.

Years later, your company, if it is successful in doing what its supposed to do, is going to be paying big $ to retool and replace what you have built. The 2010s were the decade of teams replacing the custom shit they built in the 00s.

Well, Django is a success and was done by a newspaper.

And how many dead and moribund frameworks are out there for each Django? I'd say probably something between 10 000 and 100 000...

Full ERP? For what size organisation? I expect the finance team are using a 'real' ERP behind the scenes and posting the values from the custom system manually every month, copying and pasting from it almost as if it was an old fashioned day-book.

> I expect the finance team are using a 'real' ERP behind the scenes and posting the values from the custom system manually every month

Exactly this.

At a prior startup years ago, I noticed that the accounting & finance team was always in the office late along with the engineers. I would ask them to show me the spreadsheets/models/forecasts they were working on and how it all worked because it seemed so important to the CEO & CFO.

I casually commented I could build this more effectively in code, and a half dozen people laughed at my joke. They then sat me down and showed me things like journal entries, how deferred revenue is managed or annual subscriptions are recognized. There were dozens of examples of scenarios that were completely unique from each other and required tools to allow them to capture these things and roll them up into a consistent P&L and income statement, balance sheet, and cash flow statements all adding up nicely.

And you realize that it's completely impossible for a company to capture all of this correctly "in flight", and things are going to be messy and wrong. ERP's have decades of experience capturing the nightmare that is actually managing a business and it's not sexy, but it works better than most alternatives.

> it's not sexy

which is easily made up for how condescending you get to be about it.

As a financial auditor, if a client uses SAP or some other standard ERP we can just ask for a general ledger report and get to work. If they are using something bespoke I would probably put my head in my hands and send an urgent email to our dreaded IT systems audit team, at major expense to the client.

This reminds me an interview to Eric Schmidt [1].

Here is the interesting excerpt on Google decision to buy Oracle instead of building their own ERP.

"__ How did you convince them that you needed to do this? __

Well, it was actually very interesting. Larry and Sergey suggested that we should build our own, because most of the existing accounting systems weren't any good. And I said, "I'm sure that's true, but you'll never get it audited," And I thought that was a pretty clever argument. The auditors would never pass financials (generated out of software) that we built ourselves. And Larry and Sergey today will complain about the Oracle system, but they'll also say "We had to get one that was auditable.""

[1] https://www.wired.com/2007/04/my-other-interv/

That's just a lie though. Custom software can be audited. I have first hand experience with this

Yeah... when my family business installed SAP the auditors were delighted. But... here’s the thing: standardised ledgers that make a company easy to audit have no positive correlation with corporate effectiveness and competitive advantage. It’s great that your work is simplified, but frankly, it’s totally irrelevant. I’d rather my auditors had to hail their dreaded IT departments than having the whole firm rendered essentially paralysed by Satan’s Accounting Package.

> It’s great that your work is simplified, but frankly, it’s totally irrelevant

It's the other way around. It's totally irrelevant to re-invent the wheel and do something in a non-standard way.

> I’d rather my auditors had to hail their dreaded IT departments

That's not how auditing works. The point of GAAP is that things are done a certain way, and if you do things differently you need to provide that it isn't bullshit. Otherwise Enron & WorldCom all over again.

The problem is that installing SAP into a going concern does force you to reinvent the wheel: as an auditor you might not notice it or might even rejoice, but the truth is that the whole operative side of the business needs to reinvent itself in order to conform to the mould the new ERP software requires. Auditing, accountancy, control... those are offline, non-value-adding activities and services that quite frankly the enterprise-minded couldn’t care less about.

> whole operative side of the business needs to reinvent itself in order to conform to the mould the new ERP software requires

This is exactly expected and a desired outcome in a vast majority of scenarios. These jobs/roles are not snowflakes.

I've been dependent on businesses that just went through such a transition and it's terrible.

It's not a desired outcome at all.

The "not snowflakes" good people leave, and the ossified ones who really just keep their head above water and need the job, are what you have to deal with. And they have the exact same attitude to succumb to the system or else you're SOL.

I really truly think you do not understand.

It's rare but I know from first hand experience that it can be different.

> I really truly think you do not understand.

Totally. My clearly poorly researched comment and seemingly lack of knowledge on the subject clearly reveals me as a fraud. You got me.

Hey, can you maybe knock it off?!

You've been sending replies to my old comments for the past THREE DAYS, and then editing and deleting them. I got "HN Replies" enabled so they do end up in my mailbox even if you edit or delete them shortly after. So I do get to see EVERY TIME you wrote me in the past couple of days that you believe I am "not qualified to have an opinion. full stop". No discussion, no arguments, not even trying to engage what I said, just attacks telling me over and over how much better you understand SAP. Just attacks or stating your credentials. Which is no discussion but I don't care any more, I want you to knock it off, now.

At this point I honestly don't care what your opinion is on ERP, that you're the Queen of SAP, or whether you think I get to have an opinion or not. You deleted that remark, but it was the straw. I just want to cease communicating with you, which I did from my end already nearly a week ago.

Now I understand when sometimes people post while in a bad mood, causing them to post things they regret. And if you delete those messages, then that is fine with me. But what I'm a little bit worried about, is that I got to wake up to a new reply from you, telling me how stupid I am and that I don't deserve to have an opinion, for the past THREE DAYS. That's not a bad mood. And I don't care what it is. Just let it go, alright?

Please don't reply to this comment with anything less than an apology.

> That’s not how auditing works. The point of GAAP...

Hate to break it to you, but there’s other countries and other regimens out there.

> > That’s not how auditing works. The point of GAAP...

> Hate to break it to you, but there’s other countries and other regimens out there.

Which country are you from that it doesn't have Generally Accepted Accounting Principles? Are you saying that in your country every company can make up what they want and the authorities are OK with that?

congrats, you just had discovered the dark web, where things are done in non-GAAP way. surprisingly enough, there are lot of "business transactions" going on out there than all these innocent corporations combined.

What does the dark web have to do anything? Should we bring up school kids mowing lawns? We're talking about serious companies managing millions in cash flow with investors or loans providing them a swift kick of responsibility.

we were talking about "small to medium" companies but sure

Of course USGAAP is not the only financial reporting standard (I posted a parent comment and I work in the UK on IFRS which is used in almost every other country) but US audit standards are quite close, and converging, to International Standards on Auditing from the IAASB used internationally.

Doesn't take a lot of imagination to replace GAAP with IFRS or your acronym of choice.

"Beasts of expert domain knowledge hidden in shitty codebases" is a great way to describe most of the enterprise software I've spent my career configuring and administering. And it highlights what most users of enterprise software don't fully grasp: You don't buy it because it's user-friendly or because it's the most modern technology; you buy it for the battle-tested built-in domain knowledge.

> you buy it for the battle-tested built-in domain knowledge.

This was my hardest lesson to learn. Code is only as good as the domain knowledge going into it. I love games because the domain is more often than not in the realm of fellow programmers and erudites like mathematicians and 3D animators that capture their domain knowledge in physics, sound effects, motion capture, fluid dynamics, FSM AI, or combining geometric and linear algebra to improve gimbal lock.

An ERP on the other hand captures the domain of accounting, finance, procurement, manufacturing (bills of material), order management, taxes, product lifecycle management, and other considerably less sexy but equally important subjects.

captured a bunch of "domain knowledge" of which only 20-30% is relevant to your business.

let me guess, they did not captured/predicted the domain knowledge required to run the following business huh: - search engine (google) - marketplace for arranging or offering lodging ( airbnb ) - ride sharing ( uber ) - social networks (twitter/facebook)

if all businesses does everything the same way (because some german company thinks it is), all end-products will look all the same. The same way if all chefs is following the same recipe.

IMHO the tools/choices to send invoice, manage orders, product lifecycle can also be a differentiator for your business.

> The same way if all chefs is following the same recipe.

It's more like chefs using the same kitchen appliances, pots, pans and equipment as everyone else. And they do. You use a Salamander Broiler because it does the job.

Tesla doesn't have SAP and it's home grown. SAP is ymmv thing. Not all businesses fit in their framework.

With respect, Tesla isn’t exactly the poster child of “well run companies with excellent corporate governance.”

Splendid joke:-)

Tesla makes hell of a great cars.

“excellent corporate governance” could be rather irrelevant.

They might make even more of them—and do so more effectively—if they didn't have to spend as much time arguing with the government, investors, or lawyers about who or what Elon Musk defamed/tweeted/accidentally said on a podcast/whatever.

Your tone sounds a bit insulted, what's the matter? Is it because they called SAP hideous?

I don't know what many of the terms mean you name, and I severely doubt that every business (or most) does. Doesn't mean they're not important, but most definitely just firing off a bunch of random terms fully expecting people not to understand most of them, is a weak way to prove a point.

I have seen however on the consumer side what happens when businesses "changes the business" to fit a particular piece of business planning software that is "Hideous. hideous". You're working with nice people, well-meaning people, doing their best for you the customer. And it everything well for a while and you place your trust in them. But then walls appear. And appointments get rescheduled. And they want to help you but they can't. Some people leave, a particular kind of person stays. Communication between peers grinds to a halt. If something goes wrong, they can't pick it up so it falls on you the customer to deal with or reschedule (or other inconvenience), every time. You want to get angry at the people, but you also see they are so very much doing their best, but something is holding them back. A particular kind of person is particularly good at merely keeping their head above water and not suffer the burnout many of their ex-colleagues did.

I'm not saying that it can't work well. I bet it's great when it works well. But when it doesn't it's a silent killer.

What if you were given a budget of $100 million to $500 million - just for 1 company? What about $1 billion like Dow Chemical and the US Navy?

My thought is that you will spend first year hiring talents.

> I (am actually told to) teach that changing the business to fit SAP is preferable to changing SAP to fit the business. And it's accurate advice. It shouldn't be, but it is. SAP is SAP. It doesn't care about your USP. Or your custom approach to business. As far as SAP is concerned all businesses are the same, they do the same things, and all must conform. Resistance is futile.

I've worked in companies making decisions around which ERPs to implement. You have two options: roll your own ERP or adapt your processes to an existing one.

The first approach means that you are basically committed to becoming a software company. At a minimum an ERP needs to tie together your accounting, supply chain and inventory. So it's not a simple endeavor and it's easy to mess up. You'll need a team of people to build it and you'll need ongoing support. Compared to these costs, the price that SAP or NetSuite will charge you for their ERP is trivial.

Alternatively, you can adapt your processes to an ERP. In many cases, this is the right thing to do. It means that you can use readily-available software and have practices that are good enough.

I once worked for a company that let me go because I looked bad on their bottom line and they were looking to sell the company, around 2003. So, severance package in hand, and one week later I had a new position at another company making much more than I was originally.

Anyhow - I was essentially the sole developer of a simple ERP system written in VB6 and using an Access 2003 MDB file for storage. It was being used in-house by most of the company at that point, from billing, to shipping software and patches, to other reporting, CRM, etc. I looked bad to the bottom line because my salary was going entirely into this in-house developed product, that was producing no revenue for the company. I was a literal cost center; I don't blame them for letting me go - it was probably a good business decision...

When I was let go, I was trying to transition to postgresql for the backend (away from the MDB file), and hopefully move the frontend away from VB6 - and make the whole thing a web application in some manner.

They told me when I was let go they told me they were looking into other options to replace the software I had almost single-handedly written to manage the business.

So - I was let go, and the business was sold. Twice. Today, it's part of HP, last I was aware - about 3 years ago. That was about the time that I had to look for a new job, and talked to my former supervisor there (he'd since become VP of his department).

Yep - still using the same old software, with virtually no updates or fixes. Still running on the MDB file. And somehow, it was still all working, nearly 15 years later. I'm amazed, impressed, shocked, and also in complete wonderment how it hasn't fallen over hard since then.

As far as I know - they are still using it. I've been told that both the original company that bought them, then HP (after they bought that company), both looked at the software and wanted to monetize it - everyone who's seen it has been fairly impressed with it, from what I understand. But, because it's so tightly integrated with the business, plus that it was never designed to be modular and salable, has meant that without a major refactor, it can't be easily done.

Honestly, I'm glad it can't - I'd do so many things differently today that I didn't do then (and if done, they could probably sell it as well); it's the kind of code that I know some developer will look at, then want to track me down for a good ol' fashioned murdering - or at least to beat me with a baseball bat.

That must be the magic of Windows in action. Software still running after 15 years.

I have to do some maintenance or decommissioning of very old apps in an old bank. I find anything Linux and C or C++ related is the worst, because the system libraries themselves are unstable. Applications fail because of .so dependencies breaking, both system libraries and application libraries (themselves forming a tree of dependencies). It can be extremely hard to rebuild and relink the software with the whole chain of dependencies for the current platform.

Linux executables die along major OS releases every few years, but Windows binaries can keep working for more than a decade easily.

are there no fat binaries in linux? or are they just not used?

It's possible to make statically linked applications but it's pretty much never done.

And it's against the linux packaging mantra, where you should be able to "apt-get install libqt" for example (noting that libqt package is completely detached from the release cycle of your application).

This leads to a ton of accidental dependencies and they're tied to the OS release. Even the simplest of apps might eventually depend on libc, pcre, openssl, etc...

Windows is simply different on this aspect. It's more friendly to static builds and the system libraries are more stable. If you built against some win32 API or the Visual Studio 2005 SDK, the DLL are still present and working.

Even in the dotnet era, you have WinSxS and exe/dll specific manifests pinning specific library artifacts with apps and a loader that keeps a repository of every version referred to on the system. The linux/ELF ecosystem on the otherhand decided to try to implement various degrees of semantic library versioning, with differing (often poor) degrees of success.

When your target is a system image thats rebuilt entirely from source you can get away with the latter somewhat more easily, but its definitely no panacea. Just look at OpenSSL. (libmemcache is another personal 'favorite' of mine.)

It's why MS tried to push the British gov to accept their shitty ODF format rather than a proper one. Because they wanted backwards compatibility with their modern and stoneage office suite versions with their own quirks and issues.

They're obsessed with backwards compatibility and it has it's own issues.

Microsoft Office's native format is OOXML (Office Open XML). The ODF (OpenDocument Format) is the native format of LibreOffice, and the UK decided to go with this one (despite Microsoft's lobbying).



Reminds me of a recent HN post about the uncanny survival of MS Access https://news.ycombinator.com/item?id=21401198

I probably posted to that one as well...

I should have posted to that.

Great story, I don't want to know the number of companies that run business critical stuff on excel vba macros + access DB some guy wrote 15 years ago.

My family business was very happily centralised on IBM’s (admittedly legacy) ADB package running on an ultra-reliable AS/400 (later iSeries).

SAP was a disaster.

A few years ago the company I’m at now tried doing the former while also trying to launch a SaaS application while also also trying to be a service provider.

Five years later (of which I’ve been on board for 3) they’re still trying to dig themselves out from under that with a development team of exactly four developers, and management finally got the first time today said what a horrendously bad idea it was, but refuse to move on because someone in leadership loves their sunk costs.

There's a third option - customize the ERP to conform to your existing processes. The last place I worked chose that option, they were a medical device company and didn't want to change their processes. Of course it made a huge amount of extra work, much of which was done by expensive contractors.

That option is a long thick gray line.

Every ERP will be "customized". It has to be - provide your own chartfields, business units, workflows, decision points, etc.

It's the amount of the customization that makes the difference. I've been on ERP implementation projects that were 28 days long, and 5 years long.

I am the "expensive contractor", and I have never ever in 20 years met another expensive contractor who did not fight, tooth and nail, to minimize customization. From the initial business requirements and scoping, to the constant CRs likely to be encountered during implementation.

On average/as a generalization, contractors/consultants have seen many businesses and see the commonalities, seen dangers of customizations, and fight them; clients know only themselves, believe in their uniqueness, and don't have a good vision or image of themselves post-transformation - how they could possibly do things differently. Consultants want their Time & Material bills, sure; but even more want successful project and references - not to mention sanity, semblance of life, and feeling like they did good work and helped the client.

That's so true. We are running SAP, which is so heavenly customized (someone 10 years ago thought it was a great idea, thanks!) that applying patches is nearly impossible and requires months of pain and expensive contractors.

Yes, after all the customizations they decide to upgrade to a new version of SAP. The whole shebang can start over again. At least these days it's all SAP S/4HANA. HANA is not bad actually.

And you need to pay up every time you data grows by 64 GB. I guess sap is happy

Every customization is technical debt you'll have to drag forward on every new release.


It´s buying what doesn´t add much value/differentiation to focus on the things that are important to the company.

I've lost track of the months I've spent building for some specific custom request. I haven't done ERP, but back in the 00s I did a bunch of work customizing software for the 'big enterprise' potential customers that were going to 'save the day'. Months being, one month for each weird request, because somewhere a Karen or Dave says we 'always have done it this way'.

I think your comment trivialises what ERP does. Analytics is trivial compared to standardizing processes. I like that when I create a BOM and routing I can be sure that all the inventory created using it will have the correct cost absorbed, and I can prove it to my auditor so I don't get a qualified audit, and a SOX violation and lose my company. You can't do that in a spreadsheet. I like the way I can have hundreds of people involved, I can have hundreds of sales orders, hundreds of production orders, hundreds of picks, hundreds of goods receipts, hundreds of purchase orders from hundreds of suppliers, entered by hundreds of people, and yet I still know my stock level and value, my back orders, my revenue to a very high degree of certainty. And I can audit every one.

You must be much better at Excel than I am if you can ensure consistency with multiple users and millions of rows?

ERPs track inventory, and orders very well. They don't need pretty graphs to do that.

That's similar to Epic's value proposition in the healthcare space. Sure, their software is above average (with "average" being barely functional or vaporware), but their main selling point is their ability to assist leadership in strongarming an organization to adopt standardized workflows.

As someone working in healthcare, I can attest to the value in getting an healthcare org to adopt standardized workflows. I'll take an org that follows process over better software that isn't used in a consistent manner.

There is too much operational and human complexity to solve healthcare with software alone.

Oh, absolutely. My previous employer used an Epic migration to standardize workflows across a dozen hospitals that were brought together through a bunch of different mergers over three decades. Before the Epic migration, nurses/schedulers/etc. couldn't easily pick up shifts in other locations because the workflows were so different.

One of my amazements in healthcare is that you could go to 19 different hospitals with the same issue and get as many variations of treatment.

Same input, but vastly different outputs.

And I don’t think their differing constraints can appropriately justify it.

Years after I worked for the company I mentioned before (building an in-house VB6-based ERP system), I worked for another web applications development company who had a client I was "assigned to" to develop software for healthcare management and billing, etc.

It was all web-based - we even had a version for "mobile" (at the time which meant a ipaq personal assistant, running a version of Windows CE and a browser that made IE6 look sane).

The idea behind it was "patient-centricity"; the patient could manage, view, and "edit" their own healthcare records, and any physician on the system could have access to that patient's records (the patient would have to give approval to share with the provider).

It wasn't ever going to replace EPIC or any of the other large medical record systems, but the fact that a patient could control their own data was a significant part of the core marketing behind it - provided you could get other providers and support people on-board.

Things were going rather smoothly (but not very quickly) in the progress of the development of this app, until the client wanted to make the entire thing HIPAA compliant. At the time, this meant taking it off our in-house shared hosting environment, and get it on something else. What we found was, at the time the only option was to lease a full rack from Rackspace and use their services (and servers), as they were (supposedly) fully HIPAA compliant.

The client balked at the cost to implement such a system, and instead opted to roll their own. Then the client decided to hire their own developer (without telling us), and wanted us to backdate some HIPAA "compliancy documents" to say their system was fully compliant on a date when it wasn't. My employer thankfully decided not to go down that road, and instead to drop the client and contract (probably the best decision he ever made).

What happens when the disease in my body declines to adapt to Epic's standardized workflow?

Helsinki recently adopted Epic (under the local branding “Apotti”).

One hospital death has already been confirmed as being due to UX difficulties with the new system. Link in Finnish: https://www.hs.fi/kaupunki/art-2000006391154.html

Not to downplay that tragedy, but we don't have any information on how many deaths were prevented by switching away from their old system.

In Denmark, a country of approximately 6 million people, there are three different regions running the public hospitals. Two of the three regions choose a custom system, whereas the third choose Epic.

The results apparently doesn’t favor Epic in that it costs 4-5 times as much [1] and has caused productivity loss 1.5 years after implementation [2] (links in danish)

Still don’t know if is a fair comparison though, since you probably pay the costs of adhering to process to start off with and only reap the benefits later. However the Epic implementation has also been bug riddled and I’ve also read that the procedures are designed for a litigation happy US and thus are not rational to apply here.

[1] https://www.computerworld.dk/art/248393/sundhedsplatformen-e...

[2] https://www.rigsrevisionen.dk/media/2104845/sr1717.pdf

probably nothing good, but the alternate question is, what happens to the well-being of patients overall if no standardized workflow exists, what error rate and dysfunction will it produce across the entire system?

Complaining about large corporate structures failing to meet individual needs is always a very appealing criticism, but people rarely seem to point out that these large behemoths need to be judged by their overall throughput.

The mass of people who benefit from standardized workflows are always anonymous, the failure cases always have a face, but it doesn't mean the trade-off isn't net positive.

Enterprises don't care at the micro level. There's near infinite more that do and that's where they make money.

There's also a lot more suffering to be averted. Simple standardized things like following basic protocols to reduce errors (handwashing, surgical instrument inventory) or encouraging better patient compliance (taking meds regularly, for instance) save tons of lives.

I feel like your "following process over better software" remark holds true to any company I've seen.

Mostly agree. However, I think pure software companies/ software companies that have far less human complexity can get away with building better software over improving processes and compliance.

Cerner does pretty much the same thing. They are trying to approach the hospital market pretty broadly. Much of the software is pretty rigid and if you sign up for them, you are customizing their software and meeting in the middle by reorganizing your business. Many integration issues between vendors are conflicts about where this midpoint is.

> I (am actually told to) teach that changing the business to fit SAP is preferable to changing SAP to fit the business. And it's accurate advice. It shouldn't be, but it is.

This isn't necessarily bad advice when moving to a new system.

If the development cost exceeds or far exceeds the retraining cost then this is sound advice. I appreciate that this could be a tough calculation to make.

Change resistance will likely be a factor here but sometimes the old processes were hated by the actual users, though not the managers, making the decisions.

And while not every single SAP strandard might fit every single edge case in a given business, SAP standard processes are pretty much a condesation of best practices across hundreds of businesses. So they aren't that bad.

That SAP charges extra for industry specific solution, aerospace, process / chemical, and so on, is a different story.

It's also a good practice to keep a massive system as close to the original as possible and tweak it to business needs only when absolutely necessary, otherwise it becomes a beast of its own to support and upgrade later on.

This is a great example of technical debt when adding custom features to an existing commercial platform.

I have seen such customizations go badly soooo many times..

It likely should be a combination. If processes are so different than the "standard" vendor approach, is there a good reason? Step two would be answering what is the key 10% that is different to customize.

> I (am actually told to) teach that changing the business to fit SAP is preferable to changing SAP to fit the business.

That is my goto advice on buy vs build. If you buy, then you should be willing to change your business to fit. Otherwise you should build. The more you resist changing your business the more you should build. The more you don't want to build, the more you should be willing to adapt.

I work in some other industry with some other software which is "our SAP"... and i look at it as "another IBM".

You have a bunch of smaller companies with different products, and whichever you pick, it will have some faults, missing features bugs, etc., and you'll the the one blamed for picking the "wrong" software.

...or you pick IBM/SAP/..., which is "de facto standard" in your {industry}, and whatever is wrong, is not your fault, but IBMs/SAPs/...s.

The Ticketmaster value proposition.

Which industry?

...most of them.

When I was overseeing a deployment of SAP into the family business (a really inane decision taken on a whim by my father and his trusted CFO) I was told, to my utmost horror but with utmost seriousness by an earnest SAP consultant, that “a company does not install SAP, a company conforms to SAP’s best practices”.

Years of consolidated competitive advantage went down the drain.

To be fair, most businesses never designed their processes and don't really have a need to be "different" from other companies. And if you've ever tried to build a single system for more than one client, you know how frustrating little, tiny differences between companies can be. At least big differences can be charged as a new module!

I worked for a 500 people Swiss company that had this big,fat,custom built thing based on Lotus Notes.It was ERP of sorts. We hated it. change backlog was 2-3 years.It took us a year to get a single button added. Then I moved on and ended up in a position where I was no longer the end user but rather the one behind the system.5 years later and I still keep "borrowing" design ideas from that system we all hated. Shortly after I quit, a 5000 people US company acquired it and decided to migrate all the data to their own,more modern system. 6 month later and the project was still in Excel only with no hopes of completing it at all. Don't underestimate what SAP can do.

> I teach enterprise systems at a university, with emphasis on SAP.... My students complain it is unusable (agree), doesn't make sense (agree), that they can't see the point (agree).

If you agree on all those points, why do you teach it?

>changing the business to fit SAP is preferable to changing SAP to fit the business. And it's accurate advice. It shouldn't be, but it is.

This is a common misunderstanding. Many people miss the underlying philosophy of SAP software. The reason SAP encourages businesses to adopt SAP's way of doing things is that they did research into the optimal way of doing the common business processes that don't differentiate you from your competitors. A common industry lingo to encompass that was Business Process Reengineering. That's why implementations of SAP in the 1990s were done by Big 4 firms to rework the processes of business actions alongside the installation of the software itself. In other words, kill 2 birds with one stone: if we're already spending millions to install ERP software, let's also modernize our business processes into "best practices" because those are already the likely default configuration in SAP.

E.g. there's an optimal way to manage Purchase Orders and SAP encoded that sequence of actions into SAP's data model and GUI data entry flow. You're not going to beat your competitors by insisting that your snowflake way of handling your Purchase Orders is special and "SAP should conform to it". PO's are not your "secret sauce" to dominate the market.

An analogy might be in carpentry where the optimal process is: Measure twice and cut once. -- therefore the standard SAP data entry screen might have 2 text boxes "measurement #1" and "measurement #2"

But another custom carpentry/woodworking shop says SAP is inflexible because they want to customize SAP's system so it's: Measure once and sometimes have to cut twice because of occasional measurement error. -- and SAP's response to that is "you're doing it wrong" -- and SAP's research is often correct -- so don't spend consulting hours to customize SAP into doing the suboptimal thing. Nevertheless, the oddball carpentry shop insists they're "special" so they want the UI text boxes to be customized to be "cut #1" and "cut #2 redo". Well, say hello to expensive consulting billing hours and painful upgrades.

The bottom line is to use SAP for what it's good at: the boring back office enterprise stuff that will not differentiate you from the competition.

> It doesn't care about your USP.

But asking SAP software to "care about your Unique Selling Proposition" is out of scope for the software's intended use. For example, Microsoft and Google use SAP internally even though SAP's ERP capabilities are out-of-scope for Microsoft managing an army of programmers to develop the next Windows operating system or Office suite. Same for SAP not being suitable for Google to run the AdWords system. And yet, Microsoft and Google bought expensive SAP licenses to use what SAP is good for: corporate enterprise financial systems.

The research that was put into finding optimal processes for those non-differentiating business functions can of course be invalidated at a later time. We all put lead in gasoline because it seemed optimal, then later we kept putting it in gasoline well past the point it was known to be harmful, because everything was designed around it.

Sure. We also found out that Micro-USB as a charging plug for phones does not cover all new uses. But standardizing on Micro-USB was still the correct course of action at the time.

Not sure you got the OP's comment.

What OP is saying - Perhaps SAP 'optimal processes' made absolutely sense few decades back, but when new time came and world or best practices changed, those optimal processes were no longer optimal, but still one needs to keep using those.. because SAP.

From Micro-USB analogy - world has changed, but you still need to keep using Micro-USB for your USB-C phone... because SAP.

> when new time came and world or best practices changed, those optimal processes were no longer optimal, but still one needs to keep using those.. because SAP

The underlying assertion here - made without evidence - is that business processes have changed enough to move away from the SAP-defined ones.

Have they?

The underlying assertion is there's -no way to tell- any more. Because there's not continual research being done, and there's not even much in the way of anecdotal evidence to inspire research because any large enough company ends up needing SAP (or similar) and has to adopt their workflows as part of it.

I understood GP perfectly. What I'm saying is that the future need for a different business process does not necessarily outweigh the benefit of standardizing on something else today, just like a USB-C future does not invalidate the original decision of standardizing on USB-C.


But let's examine the question in this light - Today a new CEO was hired in a new company, she is smart AND has multi-millions to spend on an ERP, which she considers absolute must for smooth running of company operations.

Now since she is smart, she is aware of SAP's reputation - i.e., SAP has absolutely nailed down today's optimal business processes (never mind those are actually decades old practices), however SAP would be very inflexible when she wants to innovate on business processes due to anticipated business landscape change (Ex. manufacturing moving back to home from China, and maybe lights out manufacturing).

Being smart, what would she do - would she go for SAP?

Can she even get SAP for 5 million? Enterprise software doesn't come cheap, then some more money in integration and training.

She should look into SAP and major competitors. Maybe some cheaper ones.

Sure thing is she's not going to develop an ERP with much features for 5 million. That can cover a team of a dozen people for 1 to 3 years. They can develop some stuff but really not much.

> (Ex. manufacturing moving back to home from China, and maybe lights out manufacturing).

Badly chosen example, though. Looks like a case which can be handled through configuration alone in SAP ;-) In general, automated physical processes of all kinds usually can easily be automated in software, too. Problems are often because in most companies, especially in procurement and production prioritization, lots of of manual, ad hoc decision making is at work without formalized processes.

The actual problems with ERPs are usually more a "devil in the details" thing.

To give a real life example where people run into problems with standard ERPs: (it is pretty boring actually, but boring stuff like that can make or break a company)

I for example once had a customer running SAP. Hope I still get all the details right, it was a while ago. Customer was mostly a home decor trading company which sold to chains. It manufactured parts of its products in a subsidiary in another country and also bought various products in China. I was drawn into the project to "translate" between the company's management and their SAP consultant/developer, as there were, uh, problems there.

Problems started when, after a takeover of the company, they wanted to move to a more just-in-time process for their own manufacturing to reduce warehouse sizes while at the same time their eager sales team committed for some large customers to delivery times which were impossible to fulfill if the ordered product is lying somewhere for more than a day, so they had the problem that they had like 5000 different products, were not allowed to stock them anymore, but had to deliver orders after 7 days while the product was "on the street" for at least 4 and half of these days.

Basically that meant, if an order was somewhere stuck in the process for over half a day after they accepted it, they were fucked and had to pay damages to the customer.

So, task was to tighten the schedules so everything goes smoothly, while at the same time manufacturing capacities where limited, the physical process itself also had limitations (like, even if a customer ordered 1 product of a certain kind, at least 8 of that kind had to be produced, so sometimes it was a good choice to produce something a day too early and stock it for a day to optimally use the production capacities), so it was important that an order was denied right at the start and that the estimates if it can be fulfilled at all were correct from the beginning.

Now, SAP has mechanisms for all of this. Just not the way the company needed (at least not with the ERP alone. Additional components, like SAP APO, might have improved this, but those were not licensed and implemented). Basically, there were two types of sales orders in the system, both did about 80% of what the company needed, you could either produce for stock and sell from stock like they used do when they still had their larger warehouse, but this caused problems as manufactured product sometimes was not packed optimally, so stuff had to be taken apart and repacked for final delivery (because from the manufacturing plants point of view, only an order for e.g. 50 units of product X came in for that way), or express orders came in for identical goods and because not enough could be produced in time, the less important customer got the delivery when both where overpromised.

Alternatively, as would have been the better choice, they could have used make-to-order production in the manufacturing plant and directly associate sales orders and manufacturing orders. This would have been the natural way to do it, but there were "reasons", again routed in the way labor was organized at that plant, that this could not be done.

Oh, and of course, even after solving the production orders, there was still the problem that the sales orders also contained trading goods from China, so that also had to be integrated into the final delivery to the customer at an optimal point in time.

So the company basically needed a custom cross of both methods, which the ERP naturally did and could not support, as the special circumstances could never have been foreseen (Actually, to this day, I would say this was a typical case of politics and company inertia at work. The labor processes actually would better have been reorganized in a way to make a standard process work. I warned the customer, the SAP consultancy warned the customer, but "nothing can be done about this").

So this was unfortunately the time where we had to heavily make changes to the system - custom reports for availability planning, some custom user exits to modify the production start times when orders where transferred between sales and production, lots of small detail stuff like that to make the process go flawlessly at least in software.

The software project actually was successful, mainly because the SAP consultancy was not as bad as my customer believed, they just needed someone who could actually properly describe the problem, so we got away with about 100 development hours, which is not much in an SAP context, simply because the system is so darn huge, you will probably spend 10 hours alone to find the proper location in the business process to apply your change to.

Sadly, customer still went bankrupt. Because the physical process was suboptimal still. But at least the software could model it in the end ;-)

The last two things don't have anything to do with SAP whatsoever. Just saying.

"The research that was put into finding optimal processes for those non-differentiating business functions can of course be invalidated at a later time."

And there's a good chance the new, improved process will make it into SAP sooner than you could develop a new software system reflecting the new process.

Does SAP include the optimal business process for software engineering? What is it?

Very good response, this explains a lot. Thank you

When it comes to Financial Accounting for asset heavy and inventory heavy businesses who need audit ready financial reporting (IFRS/GAAP), most are going to have pretty standard Order-To-Cash, P2P etc. workflows with similar controls.

But yes, what changes are the business end users requirements for slicing and dicing performance data from 'subsets of this' and 'subsets of that'. I think HANA plus the move to the cloud will potentially help this.

I’m not sure I agree with your finally point. There is a lot of software out there that can be customised extensively to fit any particular business, and it’s awfully tempting to do so because you incur a financial cost rather than a social one. But while the social cost of changing how you do things might have been a one off thing the financial cost will turn into a recurring thing every time you want to upgrade.

It is literally equivalent to forking software and merging each new release from upstream, but usually without access to something like git to help deal with this.

It doesn’t even help to skip versions because now you’ll have even more changes to merge with when you finally upgrade.

This is one of the biggest reasons I’ve seen for people sticking with old versions of software for decades. You reach a point where any upgrade will be as expensive as a whole new system, so you might as well hold out till you request quotes for replacing the whole thing, and probably repeat the mistake all over again.

Or instead of being trapped a monstrous framework, you can integrate off the shelf libraries (no forking needed) into your architecture.

Ask Rob Pike about Go vs Enterprise Java.

I integrate my work systems with SAP. It's not just SAP that's a mess, I think it's a property of ERPs in general.

That's because it's not code for running your business, it's code to write code for running your business. So you have two obvious problems here. First is all the shortcuts made by SAP to get something out the door to customers. Second is all the shortcuts your business used on top of SAP to get things out the door. This is a pattern that can easily create a huge mess. I've experienced this working on a product in a similar space to SAP in the past.

Second thing: I don't find working with SAP too hard. One of the tricks is to work out how to keep SAP as out of scope as possible during the discovery phase using existing functionality or workarounds (that don't impact on sap as the source of truth).

We made a business game, scale-up, to teach ERP differently in universities. It's a role play game based on Odoo.

It's free for teachers (and students), you can get boxes here: https://odoo.com/scaleup

>>I (am actually told to) teach that changing the business to fit SAP is preferable to changing SAP to fit the business. And it's accurate advice.

Never worked with SAP, but spent a lifetime working on other ERPs, and would agree.

Your USP is NOT how you do HR, Finance, etc. Walmart's expertise is Retail/Supply-Chain Management. SpaceX's expertise is rockets. Backoffice is a cost centre, and the assumption (validated by decades of projects) is that you are probably (exceptions do exist) not a special snowflake when it comes to HR or Financials, no matter how much Sally in Accounting or Joe in Recruitment office insist.

As I've mentioned elsewhere on this site, the #1 success criteria for ERP implementation is whether you take it as an IT, or a BT project.

- Take it as an IT project, try to adapt a COTS system to whatever gobblety-gook of disjoint processes you have right now through a myriad of customizations, and you will have a failed implementation project which will be over-budget, over-schedule, and result in dissatisfaction of all stakeholders.

- Take is as a BT (Business Transformation) project, and adapt your backoffice processes to match the industry standards and best practices as exemplified in the ERP, and you'll have a smoother implementation project and at least a chance that some stakeholders will satisfied - though more likely to be VP of Finance or HR, rather than Sally & Joe, because Sally & Joe, while experts in their field, are humans who are resistant to change, but more importantly unfortunately in most companies are not privy to the big picture results.

It is absolutely true that most ERPs are hobbled by decades of legacy code; I would agree in principle that it's theoretically possible that a company could make their own ERP that is more efficient; but in reality, company's expertise is probably not making efficient ERPs, and in the end it would be seen as an IT project and no business transformation would take place - IT in service of business, after all. Even as a techie, my jaded/experienced view now is that amongst other things, when done right, ERPs provide drive and impetus for business transformation that needs to take place.

As a techie, I would agree with your students on probably all the issues they see with ERPs. But their USP is not the brilliance of technical design - it's the proven business workflow and processes that have been standardized over decades of experience across hundreds and thousands of real world enterprises. Students are also likely to see inelegance of code or even business processes in isolation, but may not have real-world experience to understand why some business workflows are the way they are; why processes are seemingly inefficient but minimize ambiguity, or provide traceability and auditability; and myriad other unfortunate but realistic real-world constraints, scenarios, and frictions :-/

This is exactly the experience I had with MS Dynamics. Hideous. So hideous I refuse to work in that field anymore.

You should specify which MS Dynamics you mean. Because Dynamics has AX/GP/CRM, everything under Dynamics 365 umbrella.

Working with Dynamics CRM and it is an absolute joy customizing the system and building custom stuff on top of it. Very well architected under the hood. Well, it's CRM ofcourse and not ERP monster.

Ooo, this is fascinating. What's your syllabus? I'd love to understand the economics of buying this kind of software, versus buying lots of niche software versus hiring a services firm to build versus hybrid approaches.

Not the Op nor teaching in this field.

Back the day I worked for a couple of years as super key user for SAP, modules MM and PP (material amangement / demand planning and production planning). The one, unbeatable, benefit SAP (or similar monolithic ERP systems) offers is compliance. As every single process is connected to other processes the whole system is auditable and compliant to any tax or accounting legislation out there. Same goes for industry specific things like serial numbers (crucial in aerospace where I used to work). You will never get that by combining nieche products. Not if you aren't willing to create your own in-house developer department. And that will have to be on par with SAPs. Downside, then, is of course that you get zero benefit from improvements out of other companies. Something you will ultimately get using SAP for example.

IMHO, SAP makes perfectly sense if you are a big company with an in-house production. Than you hugely beenfit from SAPs MRP-core, which you need anyway. On-top you get the other modules integrated in the same system. Without production? I would stay away from it.

For my own company, managing logistics and service providers for clients, I opted for another software solution. There is no production to manage, and SAPs solutions for pure logistics, warehousing and transportation but also customs and such things, other providers are way better.

Hybrids can make sense. Customs can be done outside SAP. Same goes for transportation and warehousing. But then interfaces become an issue. Doable, yes. But added complexity and failure modes. It's a trade off between functionality and complexity in these cases.

For production management (classic MRP), I have yet to see something better then SAP. MS Dynamics doesn't look to bad, but I never actually worked with it.

Wow I couldn’t agree more! I studied business analytics at Clemson and we used SAP products because they were “best in industry”. Clunky UI, 20th Century Runtimes, and horrible UX... the market is ready for a change.

>It's hideous. Hideous. My students complain it is unusable (agree), doesn't make sense (agree), that they can't see the point (agree).

I haven't used it in 13.5 years but when was at DHS as a contractor we used it. Fully agree, it was a steaming pile and made made my job unnecessarily difficult.

But I went from it to being in AS400/BlueZone at the next job (my current job) though so... yeah... actually my email was in AS400 from 2006-2009ish... yeah.

The company my dad worked for went through the migration to SAP in the 90's and he said the same thing about not changing SAP, but changing the company as well.

Sounds like my experience with the Avaloq core banking system. Lowest quality crap I ever had to touch.

I remember having to pull data from SAP for some university courses. It was misery incarnate

Why is that taught at a university? It seems a junior college topic.

College for undergrads vs University for graduates is a UK and US thing, in most of the rest of the world you just have universities (or, like in my country, you have non-profit state-funded research universities that also teach undergrads and graduates and you have for-profit private colleges which are a lot lower quality who also teach undergrads and a few graduates, probably because a university degree is considered worth more so all the talented students go there and therefore you have to tech much slower in a college).

SAP, IBM and Oracle mostly rely on free fiat money straight from the government or other artificial monopolies to keep their businesses going. They don't need to deliver anything. What they do is beyond inefficient. Companies would be better off using open source solutions and hiring developers to integrate various systems from scratch.

==Companies would be better off using open source solutions and hiring developers to integrate various systems from scratch.==

Funny enough, this is the type of solution SAP is typically displacing. There are huge flaws in the fully-customized process you suggest.

I'm not sure any comparable open source enterprise ERPs even exist. They almost all target small and medium businesses. Enterprise ERPs are gigantic pieces of software.

Then there's the issue of expecting a widget-factory to become experts in their own ERP implementation.

Maybe, but I feel like boring business processes are exactly the area where open source solutions are severely lacking.

Also, how are these businesses supposes to hire developers if there is no one in house already with the knowledge to ensure they are actually building something useful?

They are likely to end up with a barely functioning HR and Accounting system and developers with a load of boxes checked on their CV ready for the next job.

Wow... that's.... nope.

ERP software and in particular SAP is awful, has some major limitations, and is a pain to use, but the alternatives are much worse. Only a company like IBM might manage to develop an in-house ERP based on open source technology... but more likely they'd fail.

Some "enterprise grade" software is literally that. SAP works. It sucks and it's expensive, but it works.

SAP has enabled/mandated an army of people at my company who manage it and ruthlessly control even read access to it. The software is user-hostile, intentionally obscure, and all requests for slightly customized reports have to go through a multilayered approval process - often up to corporate - where it competes for funding against other survivors. Needing something custom invites constant questions of why the standard process is not enough.

It was sprung essentially overnight with no training and expectations to show immediate positive results with no criticism tolerated. The rollout was preceded by a couple of years of secretive process reworking where the business was modified to the way SAP said it ought to be done. We expand it to "Stop All Progress" because it marked the formal transition from a technology influenced company to an integrator focusing on acquiring tech from others.

> The software is user-hostile, intentionally obscure

This a million times. I don't know if good interfaces can not be built in SAP, or if it's very difficult to do, or if the developers of apps on SAP platform just don't care.

It's a real headache to use and completely confusing.

It's 2020 and one would hope software companies realize the value of a good, clear, effective user interface.

I take a very neutral position to this. Enterprise software at the scale SAP is operating (mainly its core ERP) at a Fortune 500 enterprise level. This characteristic (needs at that level) are user-hostile, not the software.

Imagine this situation:

- You're a F500 pipe manufacturer and a sales person needs to enter an order for 100 pipes to be manufactured and sent to a customer in the US

Now imagine you need to:

- Order your materials from your Brazilian plant

- Procure raw materials from your Chinese plant to be sent to your Brazilian plant

- Ship the raw materials from your Chinese plant to your Brazilian plant

- Ship the 100 pipes from Brazil to the client's plants, 50 to their plant in the Indianapolis and 50 to their plant in Canada

Now imagine from a systems perspective your software needs to:

- Determine import costs for sending raw materials from China to Brazil to the USA

- Integrate with a 3PL to calculate shipping across all 4 sites

- etc. etc.

Oh and your software needs to:

- Be extensible to adapt to any modifications and user exits.

- Have a beautiful interface that anyone from the age of 22-65 can use.

- have full audit capabilities to adhere to local/regional compliance

- have capabilities for reporting and analytics

The real world is messy, especially at scale.

For the record - I started my career as a millennial at SAP and was appalled that most F500 use it. I've learned a lot about the "real world" since then.

I really like this industrial parallel:


> The first time I walked into the bakery I couldn’t believe what a mess it was. The sides of the ovens were yellowing, machines were rusting, there was grease everywhere.

> “Is it always this messy?” I asked.

> “What? What are you talking about?” the manager said. “We just finished cleaning. This is the cleanest it’s been in weeks.”

> Oh boy.

> It took me a couple of months of cleaning the bakery every morning before I realized what they meant. In the bakery, clean meant no dough on the machines. Clean meant no fermenting dough in the trash. Clean meant no dough on the floors.

> Clean did not mean the paint on the ovens was nice and white. Painting the ovens was something you did every decade, not every day. Clean did not mean no grease. In fact there were a lot of machines that needed to be greased or oiled regularly and a thin layer of clean oil was usually a sign of a machine that had just been cleaned.

The provided example is a bit questionable. Sure it "works", but this is a perfect example for using a typed language, so the compiler/transpiler/static analyzer can immediately tell you that type EncodedString can not be implicitly converted to string.

No need for naming conventions that have to be taught to everyone and half of the people keep forgetting. Of course that doesn't take away the responsibility to teach people why there are two types, but even if they don't know and just copy-paste, it's better than someone mislabeling a variable name and thus not making it any easier to track down a bug because of it.

> I've learned a lot about the "real world" since then.

This is key. It's the make or buy decision, which is also the "adapt software to process or process to software decision". Building something custom in order to get rid of SAP is a project that would take years and probably fail because different departments spread across countries won't agree on a way of work.

SAP allows C-level to say "just deal with it" and force people to adapt rather than try and get everyone happy with the software. This is the definition of use hostile, but it's also a way to get things done, in stead of just discussing what to get done.

This should be higher up. Everyone here thinks a simple shinny crud app to order materials for a fancy start up would be so much easier. In reality anything that starts like this will need to face this complexity at some point. Turns out the SAP way is a compromise between usability and extensibility that worked for a long time.

I don't buy the "real world is complex deal with it" explanation.

Banking (especially in US) is a total complexity nightmare. Yet you have Stripe.com who simplify it.

Your PC operating system complexity and the International Network of computers is so complex you cannot figure it all with your brain alone. Yet you write your email everyday with it and your colleague in China get's it in seconds.

Your supply chain is a nightmare so SAP must be a nightmare to use ? Why ?

My understanding was that Stripe only does a very very small, specific portion of what "Banking" does, for a fairly specific subset and type of customers, for clearly defined types of transactions and needs. They were successful specifically because they would take well-defined, well-understood bites of the overall "Banking" problem that could be simplified, even at the cost of excluding the 1% or 0.1% "edge cases". I'm sure people here or Patio11 could correct me :)

I feel the failure of extrapolation between Stripe and Banking is exactly the failure of imagination most IT folks have between "single or multi purpose application" and "Enterprise Resource Planning Application".

One of the implementations I've worked on had 128 labour agreements. That's like 128 companies or ways of handling employees, in one. 10's of thousands of time and labour rules. Across 50+ government departments. A smart, focused company like Stripe would not touch that project with a 10,000 foot pole - but it still needs to be done :).

You're asking the wrong question, really. SAP is a result of what's built when a software company is started to solve megascale business process automation problems. It is literally impossible to create a great user experience when developing software in or for enterprise IT departments, for a lot of reasons.

1. Budgetary restrictions

2. Quality of engineering teams

3. Lack of autonomy to make and enforce product functionality (or even UI) decisions

4. Competing stakeholders

5. Inconsistent workflows

The chasm between product development at a "digital native" and how business software is created in captive IT are worlds apart (and my list doesn't even touch the added challenges when it's outsourced IT).

Traditional mortgage lending is actually a great example of 'adapt the business to the process'. Whereas you used to have local branch managers approving mortgages who knew their customers, now you have a credit score (and a thousand other metrics) and the job of the people in the branch/on the phone is to help their customers tailor their mortgage applications to meet the computer's requirements. It's literally the reverse of how it used to work.

> Banking (especially in US) is a total complexity nightmare. Yet you have Stripe.com who simplify it.

Oh man, where do I start with this one. Calling Stripe banking is like calling a porpoise a fish. Sure they both swim in an ocean, but they are very different types of animals.

> Banking (especially in US) is a total complexity nightmare. Yet you have Stripe.com who simplify it.

Strip only handle a tiny fraction of what banks do.

It's simpler than that: Stripe does the things that banks weren't even good at (APIs for programmatic payments).

> Banking (especially in US) is a total complexity nightmare. Yet you have Stripe.com who simplify it.

In this analogy the ERP system is the Stripe plumbing that simplifies it for the endpoints (factory logistics manager, salespersons etc) just like Stripe does for its endpoints (merchants and customers).

You might find that re-implementing Stripe is not so simple because of the nightmares of naturally-grown international payment networks. Similarly, implementing an ERP system over an F500 company's logistics/manufacturing/sales pipeline that grew in a complex nightmarish fashion through M&A and diverse international legal/tax/regulatory frameworks.

Please note that I am not saying it is easy ! Far from it. I say it is possible to obtain something friendly that actaully help you get the job done.

I discovered that Lidl spent 500 millions $ for nothing (literally) trying to implement SAP.

Give 500 millions euros to a talented group of Stripe - like engineers and, maybe, you will have something sorted out and maintained for a few decades.

Half a billion dollars....

50 engineers well paid (5000$ net after taxes / month) cost 6 millions a year (France)

With 500 millions your system can be build and maintained for a century.

Ah, but you're not just paying coders.

You need tax lawyers to ensure you're doing that right. You need employment lawyers to ensure your termination process follows the law. You need accounting experts to ensure you're reporting correctly. In every legally distinct market.

How many laws, regulations and reporting requirements does your average chemical plant comply with?

The press headlines of how much was spent on an IT system; as well as how much actually went to "coding" portion; in my experience can be sensationalized and wrong by several orders of magnitude.

As indicated elsewhere, ERP implementations can go spectacularly badly - and I maintain my claim that treating them as an IT project, which your estimate/equations are doing, is the #1 way of setting them up for failure.

In fact, I would imagine that the key work done at Stripe is not by talented engineers/coders with IT/systems knowledge (not to in any way put them down), but by business/financials/law/banking experts (who ideally would have some or lots of IT knowedge or background so as to not be dangerous). Again, think of our friendly neighbourhood patio11 as a perfect example of technical skills and hard-earned real-world business experience.

Even if you're in France working for the worst staffing companies, the lowest bill for a developer is 400 E a day, times 218 working days per year so roughly $100k a year.

So we're already starting at almost double what you planned for and there are much more costs to cover than just staff. Large scale projects are insanely expensive and hard. It's not just mismanagement.

While I sympathise with the frustrations expressed by other commenters, especially the ones you are replying to, this kind of illustration of the complexity the system deals with is super valuable and eye-opening to me in the same way the original article was. Thank you for sharing.

My experience with Oracle's products is similar. At these kinds of scales simple tasks like paying someone or restocking widgets become user hostile because of all the process complexity required to capture all the cases.

> I don't know if good interfaces can not be built in SAP, or if it's very difficult to do, or if the developers of apps on SAP platform just don't care.

Up until some 5 years back, UX really was afterthought to them. Why? Answer is in how enterprise software was (and largely still) sold. Buying was done by CIO, based on all parameters (account relationship, FOMO, $$$ discounts, functional reliability etc.) except user acceptance.

SAP simply didn't have incentive and KPI to see UX as focus. Users were "trained" to use SAP after rollouts.

With what is fancy termed as "consumerization of IT", SAP has been forced to change. They've been trying their best with Fiori v1, v2, v3 since then. Change takes time to get hold in SAP world, specially given large on-premise installed base, where customers take years to adopt a release upgrade.

SAP is designed based on priority of the requirements by people in a company who will never use it but will ask their staff to extract the data and present them in PowerPoint or excel.

So the UI design of SAP is user hostile. Even by embracing modern web components and openUI toolkit SAP will continue to be user hostile design.

SAP will need to change the foundations completely to change it and also re do things. But then it will put them in direct competition with modern software makers who can beat them.

So I am doubtful things will change, SAP will go the path of IBM in times to come.

Not having much experience with SAP (but having dealt with frustrating enterprise software), I know what people mean by user-hostile UI/UX. It's a symptom of a systemic issue commonly seen in corporations, government, public administration, any large institution.

It's what happens when the users have no choice in the matter, there is no reasonable alternative or competition - therefore no incentive to change or improve.

Whether it's intentionally designed to be user-hostile, I've suspected (and doubted) that myself.. There might be a logical explanation how that's desirable or even profitable, as a kind of moat or gate-keeping.

With its legacy and massive complexity, SAP would require a visionary to re-architect it from the ground up. Unfortunately, that rarely happens in enterprise software.

We can only hope that scrappy startups arise to replace and evolve.

While the first thing is in itself bad enough, it becomes just dangerous when these powerpoint higher-ups refuse to, and don't, understand how SAP, and thus an integral part of their business, works. Saw that more than once. Which is also one big reason why the SAP instances I worked with at multiple companies are that bad. Not necessarily bacause of SAP, but because of tech-iliterate old-guard managers trying to work with "computers" and "software".

one has to differentiate between SAP the product and SAP as implemented by random big-co. The parts that are user actively confusing and user hostile are usually result of customization done during the implementation (and motivated either by requirement to keep some existing ad-hoc process or by requirement to have some report contain something that is otherwise irrelevant for its contents).

It is certainly not true that SAP does not care about UX (in fact the reason why SAPgui has it's decidedly non-native look is result of some UX research in late 90's), only the UX they care about is not about easy onboarding, but about efficiency of use. And by the way in my opinion SAPgui manages exceptionally well to combine power user features with discoverability (on the UI toolkit level).

In my previous company, there is a senior worked on SAP for a long period of time. In his point of view, the UI of SAP was nice in 90s, but they are outdated now. And you can’t customise the user interface with what you want. He also thinks we should not put too much effort in learning SAP product as a developer because he thinks ERP is not not for this generation. He suggested We can learn the integration with SAP, but don’t waste most our time to learn the SAP configuration from the top to the bottom, SAP programming etc.

> ERP is not not for this generation

This generation has options for creating full custom software faster than one can configure an ERP.

> This generation has options for creating full custom software faster than one can configure an ERP.

No we can't do that, because the real world is messy. I currently work on a SAP system and the amount of localization and customization that was done for you is inexpensive for big corp. And you know that SAP will last the next 30 years, you don't know that about your Framework of choice.

It brought the "swim lane" mentality to my outfit. There is a "process is king" mindset where people exist to run some report or the other with a completely impenetrable abbreviation and set of unmarked mandatory fields also with no intuitive signifcance. Grab the next item on the work list, do your thing, and mark it complete. If some project asks what's required on either end or how to move their need forward, that's not your problem. That project has to divert someone to first figure out the unpublished process and then contact everyone in the chain. If you can't run reports yourself, you're at the mercy of others. And the first rule of SAP is that there is no mercy.

> There is a "process is king" mindset where people exist to run some report or the other with a completely impenetrable abbreviation and set of unmarked mandatory fields also with no intuitive signifcance. Grab the next item on the work list, do your thing, and mark it complete.

Those are birth pains as felt from inside. It's a beginning of a new sentient life; your company is acquiring its own mind. You and your coworkers are now just nodes in the network. Individual reports don't make intuitive sense for the same reason a random block of machine code doesn't tell you much about the purpose of a program, or why a random neuron doesn't know what the brain is thinking. You're part of something greater now. You're compute incarnate, the process made flesh. Welcome to the collective. Resistance is futile.

(Honestly though, this applies to many corporations in general; I think SAP is a kind of parasite that thrives off corporate life forms, exploiting popularity as a reproduction vector. After infecting a corporation, SAP keeps it alive and makes it display the signs of infection, which is used to encourage other corporate life forms to get infected themselves.)

> Those are birth pains as felt from inside. It's a beginning of a new sentient life; your company is acquiring its own mind.

Yeah. Kind of like 'Aliens' when one bursts through a chest cavity.

> Those are birth pains as felt from inside. It's a beginning of a new sentient life; your company is acquiring its own mind.

Kind of like the ant colony being sentient but the individual ants not (see Gödel, Escher, Bach).

Process is king in mature industries where profits are extracted from scale and volume. Anything outside of standard process is expensive. If there is no external entity to bear the cost, then this cost is to be minimised.

You and I may not agree with this approach, and the formula is somewhat different for creative industries, but numbers don't lie. It's always a compromise between agility/adaptability and cost when in a production line.

A main function of an ERP system like SAP is to maximise this extraction.

And now you have a company incapable of evolving in any meaningful way. The company will die with its current line of products.

Unless incumbents are not susceptible to shakeups, like when that business is within for instance extraction of oil

Or a hospital

Or a drug manufacturer

Rather with it's current way of doing business. But yes, in a way you're right.

> with no intuitive signifcance

This isn't a problem with a standardized process, this is a problem with leadership not explaining to those doing the work how they fit into the whole and why their actions are important.

"Process driven" does not have to mean rote, mindless, automaton-like action. It should be more about thoughtful action conscious of how those actions have downstream effects rather than intuitive "do what feels right" methods

this requires trust in the workers from the C-level. But they can't hire people they can trust, because they are paying minimal wage.

> It's 2020 and one would hope software companies realize the value of a good, clear, effective user interface.

Nope. Forget about it! :-)

I think another problem with these horrific ERP's is that their tentacles are everywhere in the org.

Oracle EBS, my personal "favorite", runs PLM (product lifecycle management), inventory, order management, work orders, customer install base, finance, purchasing, AND PTO entry, F.M.L. !

We can't have nice things in, say, PLM because the whole damn system is tied up tight as "modules" in Oracle EBS. Any kind of change or request involves, at a minimum, harassing a overworked guy in India who is constantly dealing with battle-axe personalities in finance and order management.

Things that SHOULD be taken for granted, like being able to create a hyperlink to the bill of materials for any part number-- that's seriously impossible, it's like a freaking moon shot for them (or so they say).

I won't disagree with you when you say they are horrible but there is also a difference between lets say the user interface of something you rarely use and something that is your job. I've never worked in SAP myself but I've seen others do things very quickly in that ugly user interface just because they have learned how to jump around quickly and what fields to fill in.

It might still be bad but for them it works pretty well after they have learned it. As a counter they think my writing commands in a shell as an incredibly bad interface while I think it is very efficient because I've learned it.

> Things that SHOULD be taken for granted, like being able to create a hyperlink to the bill of materials for any part number-- that's seriously impossible, it's like a freaking moon shot for them (or so they say).

One of pain points I was talking about. I'm not sure how a screen/module is developed in SAP, but there are huge inconsistencies in various interactions I come across. I am inclined to believe that the third party developer of the screen ought to do some wiring to, say enable hyperlinks, or do logical linked screens but somehow the QA is so bad that it's frustrating.

For example, in our company, when I search for a Material code, there is no way / menu / system to automatically list all Purchase Orders, that contain that Material Code, sorted by date / department. I am guessing that the 3rd party developer ought to have built that functionality, but then what would be the point? After so many years in the ERP domain, shouldn't SAP have an automated system to do that?

If you think, that SAP's UI is inconsistent then you haven't seen the above mentioned EBS ;)

Input boxes behaving as buttons, tabs either changing behavior of UI components that are clearly drawn as being outside of the tab, or outright behaving as buttons that cause random actions, loads and loads of nested modal dialogs...

> It's 2020 and one would hope software companies realize the value of a good, clear, effective user interface.

SAP is not the only one; ever tried the enterprise software from Oracle? Or the open source ERPs/CRMs? Painful.

But everything has API's these days, so lot of departmental work is done on top. Small budgets so they have small, simple LoB apps made on top which are 'idiot proof'. These apps are very localized though; they cannot translate to other verticals, or even other companies, or even other countries because they are tailored exactly to how that department works.

I have to agree. I've had the massive misfortune to have to implement and test (almost?) every open source ERP/CRM system out there from vTiger, Odoo, SuiteCRM, Yeti, NextERP, Dolibarr, ...and more that I can't recall from the top of my head.

Each and every one of these systems suck. Sometimes they suck in creative and extraordinary ways. But, one thing you can count on is that there's a real reason that they suck. It turns out that the real world of business is complicated and messy. So, as you say, businesses build their own solution on top of these systems to simplify it for their users while keeping the capabilities of the underlying system intact. Of course, nobody is ever happy with the end result - it's always just the least terrible option.

On a slightly related topic since this may be seen by folks who can benefit from this information.

A lot of "Open Source" systems these days are not what you could honestly call open source. Odoo is the example I'll use, but what I'm about to say applies to a lot more than just Odoo. Most of the organizations behind these solutions are predatory. I've seen features get taken out, hidden, intentionally broken, or have fixes released that are only available in the 'pay us' versions. [0-1]Odoo's accounting functions are one such example.



Which of the open source ERP systems is the least bad?

If forced, I'd say Dolibarr is probably the best for 'real' ERP use-cases. I say 'real' because ERP is a buzzword that has been beaten to death to describe things that don't even approach what it's intended to mean.

A close second is Vienna Advantage. IIRC the development actually came from former SAP devs who have real-world exposure to the problems ERP is supposed to solve.

There is also https://www.axelor.com/ It seems very promising. I will test it next week for my business.

We actually tested Axelor as well! At the time, their documentation was quite lacking (in English at least) to the point that their installation instructions didn't result in a working system. (We got it working using a windows system and an older version, but weren't able to do so on a Debian?? system with the latest version at the time) I would be very happy to hear that things have improved because Axelor is probably the most 'user-friendly' and 'pretty' system we tested - assuming it's functioning.

ERPNext in my opinion: https://erpnext.com/

At least as a software engineer for such kind of integrations you can take fulfilment by knowing you are helping real people do their job in a less painful way.

I know a few colleagues who enjoy that kind of work, slapping a much better and intuitive UI on top of their own services integrating with SAP, Salesforce and so on.

You improve overall productivity and can show that data comparing how much faster someone using your interface is versus the likes of SAPgui, etc.

From my experience, to integrate with SAP may not be that trivial with just calling SAP’s RFC. Companies may need to workaround SAP issues, for example, user license, slow RFC response. And also need to consider the case of error recovery, otherwise you will suffer from data inconsistent. What you end up actually are a set of “micro service” to build on top of SAP

Absolutely. I think that it's a necessity for businesses to periodically review their processes and see how 'tool x' fits in, and whether it can fit better. Filling in the gaps or improving workflows can unlock treasure troves of hidden value that are often left unnoticed. Fortunately, I think awareness about what is possible in that department is growing and that we'll see a lot more focus (rather, jobs) on such optimizations over the next 5-10 years.

Odoo was the worst experience I ever had. Granted, processes at that company could only be described, on a good day with a lot understatement, as st. But still, it felt like half of it was missing and the other half wasn't working properly. That and that the external developers had no idea how to manage inventories.

ERPNext (GPL V3, https://github.com/frappe/erpnext) is being deployed by many large companies as we speak. India's largest Stock Broker Zerodha (https://www.youtube.com/watch?v=4B6nfq1UR3Y) and biggest Listed Company (https://www.youtube.com/watch?v=jnoWwSBDQlI) are actively using ERPNext.

ERPNext is not open core like Odoo.

Disclaimer: I am the founder of ERPNext

What part of ERPNext is GPL'd, if not the core?

All of it.

I think rushabh's point was that the Odoo model is an open source core with closed source paid components, whereas ERPNext is fully GPL'd.

ERPNext monetize via a SaaS model, but you are free to self-host.

I have only been exposed to SAP a long, long while ago, but back then it was leaps and bounds better than the two ERP systems the company had used previously. If you think SAP is a nightmare, these other systems would probably drive you clinically insane.

One system had three completely different, supposedly equivalent, client UIs. Each was equally undiscoverable, and had its own set of arcane, non-standard and inconsistent UI conventions that was completely different fron the other clients. So even if you knew how to enter a certain record in one client, your knowledge was almost wntirely useless with confronted with one of the other two. I am not even getting started on the server implementation and the myriad of bugs in the system.

One important factor is that folks who use SAP (or other enterprise software) get really good and fast at using it. Any changes to the UI and you have a major revolt on your hands.

Not with SAP but having been a part of a project to modernize the UI an enterprise software solution, it usually isn't worth it. Users don't care about how it looks, they just want to get their jobs done as quickly and efficiently as possible. Any changes to what is displayed on what screen or location of buttons etc. causes a major disruption to the way they work.

> It's a real headache to use and completely confusing.

You could say the same about Vim.

I suspect there are workflows and shortcuts heavy SAP users have learned over time that make them highly effective, and they are now resistant to change.

Except vim does not take over your process and data, and is happy to sit there and wait out your tryst with nano, sublime, vs code or frigging notepad.

It's fine to have an inscrutable, beginner-hostile power tool as an option.

Except that instead of getting high powered modal editing actions where editing text behaves like executing code, you're stuck in insert and can only move by arrow keys, one at the time.

This is what we hear from our customers all the time.

Our product has been so successful, I think, because people on the floor of the factories like using it. Our developers visit the sites, talk to users, and we take everything into account in the design of our UX.

I talk with a lot of our users and their biggest frustration is SAP. It's only available on particular work stations, you have to manually enter your forms from the paper ones (data entry in 2020 is still a job), and the interface is arcane and painful. When it doesn't work nobody knows how to fix it and it can lock down the release of millions of dollars worth of product. You can't get any reporting out of it without IT approval and it can take years and millions of dollars to get anything done with it.

Our stuff is mobile-first, easy to use, and we deployed it in months instead of years. We met resistance from our customers' IT departments who were irate that the factories weren't waiting for their SAP solution to roll out (it had been several years by the time we came into the picture). So, there's a big win there in UX alone.

We do more than UX but it's still such an important part of software.

Care to share what you product is?

Yeah. Kind of an integral part of the story.

One way to think about it is this: if having good UI in internal enterprise tools was a competitive advantage, companies would move to having good UI.

It's a competitive advantage in ONE category.

If your business model is being a gatekeeper who requires expensive training and long adoption periods just for users to do basic shit, and then never switch because they think ALL software is that complicated to learn, then....

What I'm trying to say is, the intricacy is intentional. They thrive on their consultant/contractor money.

No one will make a trillion dollars disrupting them. But they will be disrupted.

It is a competitive advantage. A good, consistent UI would make people at-least not hate their job when it comes to handling SAP systems.

See, using an SAP system requires a lot of unnecessary cognitive load, so much to remember, so much to digest. So un-intuitive.

I am sure people would be more productive with a UI that is not complete crap.

Neither of these things are directly connected to the SAP relationship with your company. The people feeling the pain from the bad user experience are multiple steps removed, and generally powerless to do anything. When they complain, they get presented with an improve UI versus implement thing that auditors need argument. Normal people are going to pick the latter.

Sounds like a startup opportunity.

Absolutely. I am thinking that a reasonably efficient system can be built with that 100 million put in a bank and pay the interest (4%, 4 million), to about 10 - 15 developers and use standard practices and open source systems for a custom erp system.

But I guess the reason products like SAP survive is because in a corporate environment, people have the "No one was fired for buying IBM" mentality.

If an SAP implementation is thrust upon the organization, then there will not be anyone particular to blame. Just the 3rd party devs perhaps.

I suspect the startup graveyard has many tombstones throughout the decades engraved with the words "We tried to disrupt SAP".

The last paragraph is the core issue, IMHO. SAP, while as software is cumbersome, user hostile and the opposite of intuitive, has some really great standard processes. Stick to them and SAP as an ERP system will run, almost, like a charm . When your company has the scale to benefit from it. And sticks to 90% of the standard processes.

Try to implement it without the necessary scale of operations, with sticking to standards and without training at your own peril.

That being said, without any production going on I would never even consider SAP. When don't have any use for their MRP-functions, forming the very core of SAP, you are better of with different solutions. And their licensing schemes are just aweful, not to even to talking about pricing yet...

What would you say is the right scale for something like SAP? We are only at a few million right bald and around 250 people and are starting to think about it.

I would not recommend it at that scale. You’ll grind your sales people down for no good reason, and flush several million dollars down the toilet on a project that will most likely get canceled and several people fired (gotta have fall guys at that level...). The right time to implement an ERP is at the last possible second that you are legally or contractually obligated to, or a make or break $50-100M sales contract is in play. And in the latter case, losing the contract and flushing the SAP project down the toilet are real risks. I’ve lived this project at a company the size you describe and it ended very poorly.

As the other comment stated, I would say you're not there yet, sclae-wise. Hard to tell without further details, so. If you decide to the SAP-route in the future I would advise the following (no complete list by far, so):

- Stick to the standard, the smaller you are the less customization you do. ususally I'd say 90% standard, if you're small aim for 100%. makes it faster and easier to implement. And cheaper, because you need less external resources.

- Wait. SAP is deprecating SAP APO by 2023 (IIRC, something like that). So implementing before that could be a problem. Either you end with a legacy system and have your first release change right after, or during, implementation. And release changes are unique kind of hell themselves. or you end up with a new system that is yet untested. I wouldn't want either of that.

- Try to model your business already now along SAP-processes. First, these processes aren't that bad. especailly for the back office side of things as other pointed out already. Plus, it makes and future SAP implementation a lot easier. Same should be true for other ERP-systems, but I have not that much experience with those. Aside Odoo, which I wouldn't touch with a ten feet pole ever again in my life.

- get external consultants. Really, get them. get the good ones. A lot of hours. At least one for every module of SAP you want to implement. And have one of your own devs sitt on the consultants lap during the project. One per consultant. It's expensive, sure. But less expensive than an aborted SAP-project.

- Invest hours, days, weeks and months in user training. From day one, ideally as soon as you have a test envioronment. Start with key-users, experienced, smart peolple open for change. And work from ther to every singel user of the system. You need their buy in, without even the best SAP-project will fail. These people are alos the backbone for the future, trea them well and listen to them.

In case you want to hear more of my rambling, just shoot me a mail, adress is in my profile.

Just curious, what put you off Odoo so much? (I've not used it myself)

There are other alternatives such as Workday: https://en.wikipedia.org/wiki/Workday,_Inc.

Never used it but it does not have to be SAP/Oracle at that size. Could still be the best solution though, I'm no expert.

If you absolutely need training to understand a UI, your UI sucks. Badly.

Definitely some truth to this buf, also a bit different for highly specialized software which people are using to do the same things consistently. Almost like looking at an airplane cockpit and thinking it's too complicated.

Horrible example considering how many planes have had fatal wrecks because of this exact problem recently...

So, like vim and photoshop then?

When my organization (20k+ employees) started its process to migrate many systems to SAP, this project filled a seven-story building. Cost: 2 billion NOK, so far.

Which company? 20k+ employees is one of a handful norwegian companies.



Total cost means nothing. What was forecast? What was the original budget?

If the original was billed at 1.3 billion NOK and we're at 2 that's still very high, but it's a different discussion from a 400K NOK estimate.

"Take whatever you think you need and double it" comes to mind.

Of course TCO means something. You have an expected ROI when you go into an ERP. In this specific situation TCO far exceeded possible ROI.

It exactly feels like you are telling the story of my previous company. Although they started using SAP because company was going public and it E&Y advised company to implement SAP. Implementation was never successful. Day to day productivity greatly suffered. You had to do things SAP way, regardless of it being right or wrong. There were training sessions every weekend. Even trainers were confused. Everyone was mad.

Soon after our company went public, we gave up on SAP and started doing things old ways.

my friend works ata company that is an sap partner and they are required to use some sap software (i think some helpdesk component) and they use some external software and import stuff into sap later. afaik the reason is partly how bad it is and how the licensing does not make sense.

Make a really bad product + make it mission critical = a product that people are literally glued to using

HR data is necessarily controlled though, there are pretty stingent controls in law around that. I understand the pain of not being able to report on stuff, but there is probably a sound reason. However, the delivery you describe sounds like a broken organisation tbh

No, this is the SAP business model. If people think that Apple, Sony, or Microsoft try to lock you in to their 'walled garden' then these people have never seen an SAP installation/integration.

It's almost its own industry. There are fleets of consultants charging ~$1000 a day just to install the system. Then, as the OP said, they charge by the hour for customised reports which means that businesses have to choose their report very carefully, and will probably need several more hours consulting when one aspect didn't work quite how they thought.

I would be surprised if the commenter here was someone who didn't already have access to the data. They are being frustrated by consultants who want to keep their billable hours up, and extraneously restricting access under guises such as "this person doesn't have enough training to touch the system," because it keeps them in paid work.

Source: Friend of mine. Man on the inside.

I'm not sure comparing walled gardens is that benefitial here. Most larger firms will either have consultancies on retainer or in-house personnel that can generate these reports anyway.

> They are being frustrated by consultants who want to keep their billable hours up, and extraneously restricting access under guises such as "this person doesn't have enough training to touch the system," because it keeps them in paid work.

I'm not sure why there's quite a few people pointing these aspects out in here. As opposed to the person using that data to keep their own billables up? "this person doesn't have enough training to touch the system," seems like a perfectly valid thing to say given what these systems do and is certainly not unique to SAP. The learning curve might be steep, the documentation looks ancient, the ecosystem might seem unapproachable, but at the end of the day this isn't that different to similarly scaled products from players like AWS or MS for example. They might have more approachable lower tiers and are nicer in quite a few technical aspects but other than that? It's often consultants and "certification or gtfo" as well. It's not like the consultant costs come as a surprise to anybody in these industries. Sure, it's their own little sub industry but you could say the same about these other ecosystems as well, that's not special - it is just how a few of these sub sectors are structured.

The difference between an SAP consultant, even on retainer, saying someone else can't do it because it's "too hard for them", and an employee being on the receiving end of that remark, is that the employee is an investment on the part of the company, the consultant is an expense. One is the equivalent of the programmer obfuscating his code to keep himself in a job, the other is an employee learning something new and becoming more valuable to the business.

I work in infrastructure an automation on the AWS/MS platforms and work with just about every level of their technical capabilities. I don't have any certification. I don't even have a university degree. I can work with the documentation, which is more often than not up to date and worthwhile. Though the curve is often steep, this doesn't mean it is beyond people with a careers worth of experience around the subject.

I have also learned a small amount about the sort of work involved in these custom queries from my friend. For the most part it's no more difficult than basic database administration; i.e. it's a query language, akin to SQL. It's difficult enough that I can see why someone would want training in it before touching a production DB. But from what I hear these consultants often work straight on Live and then rack up more billable hours fixing the mistakes they made with the customers' live data.

All of this is anecdotal, but the business model (essential monopoly) makes me squirm at the best of times.

Reminds me. I once wanted / needed a KPI to monitor consignment stocks. So I needed agregated inventroy numbers fo the past. Quite a simple calculation, SAP has stock movements and the current stock. So just plus / minus, right? The external devs wanted 70k € back in 2011/12 to put that into SAPs Business Warehouse. Not being able to programm ABAP myself, I went to my manager. He came up with a report, in the prodcution system, after 2 hours, half of it during his lunch brake.

All big ERP Software is like this. SAP is not unique in this regard, it is just everywhere in this market segment. Studies show that ERP user dissatisfaction grows exponentially with project / company size for all systems / implementation partners.

As an employer, it felt equally as hostile. Every process was riddled with more process. Approvals were miles deep. Getting appropriate hardware and software that wasn't on The List was nearly impossible. Good times were had by all.

How industry dependent is this? Is this an artifact of the needs of a particular industry (aerospace, automotive) that has a lot of process to cover supplier quality concerns?

I've been in the ISP, MSP, Fed'Gov, and Manufacturing sectors in one way or another, and dealt with SAP in most/all of them. Some were worse than others about this, but it was a universal problem.

"CYA is SOP", hence millions of layers of approvals, QA, and change controls. Feddy'Gov was actually the fastest moving, in my experience, but they also didn't have to worry about manufacturing defects or breaking BGP nationwide.

On prem software is notoriously hard to keep modern. Every customization makes upgrades that much harder. SAP’s approach is “We know best.” Oracle is even worse. At least with SAP if they say the App does something, they aren’t lying.

The army of SAP trained technicians and extreme sunk-cost based lock-in sounds a lot like Epic.

Same biz model.

> intentionally obscure

Never attribute to malice what can equally be explained by stupidity.

People complaining about how user-unfriendly SAP is or how companies adapt to SAP instead of the other way around are missing the point of SAP.

The point of SAP is that the module for your type of business is being implemented at the market leader in your area, because they are the only ones who can afford it. SAP will come to the market leader and put their processes into software.

Then everybody else adapts to SAP not because adapting SAP is impossible but because SAP implements the processes that made the market leader successful (at least that's the idea).

So it is very intentional that you adapt to SAP and not the other way around. You do it to emulate the market leader.

And the user friendliness is also on purpose. If you go visit a company using SAP, you will find that you have a certain job in the company and it needs two or three things from SAP. Jobs are very specialized, so SAP is, too. Nobody is supposed to just wing it with SAP. You are supposed to learn how to do your transaction with SAP, and that transaction is then meant to be super efficient.

If you actually go visit a somebody from an enterprise environment interact with SAP, you will be astounded how quickly they can do what they are supposed to do. It's almost as if the software was optimized for frictionless efficiency.

Also note that user friendliness is a subjective and mysterious area. If you go look at an airplane cockpit, where actual research was done into how to optimize user interfaces so that the pilot will not be confused under stress, you will see that there is a separate button for everything. There is no "shift key", no different modes. If you need to use it, there is a button for it. To someone who has not learned how to use that UI, it appears alien and unfriendly. But the the trained pilot it is the pinnacle of perfection.

It seems super strange to adopt the market leader’s processes. You’d think the spirit should be that you can outdo/outcompete then instead of adopting what they’re doing...

Corporations running at the scale where SAP operates are so huge that basically nobody fully understands them or really know what they're doing (but they're also big and entrenched enough that they don't need to - inertia, institutional memory, brand awareness and existing product-market fit will do the job as long as the market doesn't radically shift from under their feet, cf. disruption). Seen through that lens it's no surprise that cargo culting is so widespread, or that huge businesses like SAP, Oracle and McKinsey can make massive profits off of essentially giving upper management in big corporations the reassurance that 'they are doing what everyone else is doing' so hopefully the good times will keep rolling.

Competitors cannot outsmart the leader in every facet of business. They creatively optimize some processes, but for the rest of the business their choices are wing it or purchase the Commercial Software solution.

Even a bleeding-edge company will hit an obstacle they cannot improvise through (like in QA or Compliance). That's when enterprise software creeps into an otherwise lean operation.

Think POs, procurement, payables, receivables, treasury and inventory management etc. Is following what Toyota does strange?

It makes getting bought by the market leader easier at least.

Yes, Its really super strange to adopt Google, Microsoft, Apple processes.. Yes?

This is like assuming that Microsoft or Google is successful because of the version control software they use, rather than because of the actual software they wrote. It may be a useful hint about good practices, but it's quite possible that it's not the best solution for you and it is certainly not THE way to be successful.

The other way to look at it is that if you truly believe your strength is your product (the software you write), you might as well not risk in other areas where you could either make a right or a wrong decision, and just standardize on every other process so you're on a level playing field. This way you lose the chance of innovating on how to do payroll more efficiently, but you focus your innovation efforts on your product (your software).

You mean like stack rating, the microservices crazy, massively parallel cluster for dealing with 1GB of data, letting an army of very competent developers to unproductive companies because all you care about is brain teasers, creating user-hostile interfaces because of "design", and other things like that?

If Google had tried hard to adopt Yahoo, it wouldn't have gone very well for them, I figure.

Apple did not use Microsofts processes to get where they are today. Neither did Google.

If you want to be better than them, then I'd say Yes.

The key is to figure out what to copy and what to innovate. This is usually captured by the idea of "core competency": figure out what your company's unique competency is, innovate in that area, and avoid trying to innovate in other areas in order to save time.

Actually yes. I saw numerous teams adopting monorepos, k8s, microservices and other buzzwords, and either suffering infinitely or putting enormous effort into dragging those to the point of sheer mediocrity. Because they are not Google and will never be.

Scale matters.

Unless your company has thousands of employees and billions in revenue, Google/Microsoft/Apple processes are probably not for you.

==Unless your company has thousands of employees and billions in revenue, Google/Microsoft/Apple processes are probably not for you.==

Then you probably don't need and shouldn't buy SAP.

Correct. Random companies cargo-culting what Google does has made half the industry massively dysfunctional e.g. in hiring processes

You say this, but I can think of two large market leading electronics corporations who are using a big pile of excel spreadsheets to bridge gaps in SAP, as the regulatory environment is moving faster than their development cycle.

I integrate into SAP for manufacturing and the users can certainly do every transaction they need to do to account for cost and shipping product and keep finance / supply chain happy.

But yes, to actually plan and run their manufacturing area, that's where the software I write comes in... as well as a ton of spreadsheets :)

As lng as the data in these spreadsheets goes back into SAP. If it doesnt' you can kill SAPs MRP. I saw that happen. Which is then kind of hell's hell. And then the spreadsheet-users complain about SAP.

Yeah - one of the outfits I mentioned had a bit of a catastrophe due to this - BOMs in SAP and XLS were different, they made a medical product (for children) that exceeded RoHS and REACH lead and mercury thresholds. They made millions of units before the mistake was realised. Oops.

Damn. That's worse than anything I saw so far... Hope nothing was actually shipped, or if it was nothing serious happened.

"If you go look at an airplane cockpit, where actual research was done into how to optimize user interfaces so that the pilot will not be confused under stress, you will see that there is a separate button for everything. There is no "shift key", no different modes. If you need to use it, there is a button for it. To someone who has not learned how to use that UI, it appears alien and unfriendly. But the the trained pilot it is the pinnacle of perfection. "

My design professor used cockpits as a example of bad UI. Grown over the years and understood only by repetive drill and not at all intuitive.

So there might have been research to better it, but I doubt there was a major redesign, or was there?

> People complaining about how user-unfriendly SAP is or how companies adapt to SAP instead of the other way around are missing the point of SAP.

> The point of SAP is that the module for your type of business is being implemented at the market leader in your area...

I understand that SAP apparently delivers an insane range of good defaults, complex business transactions and covers any imaginable niche use case. That's valuable.

However why does that rule out friendly, accessable and sane UI? Excellent form design, intuitive navigation and generally things that enable efficient work without weeks of training? That seems like low hanging fruit to me. Something as boring as lists and forms can still be a joy to use if done right.

> Nobody is supposed to just wing it with SAP. You are supposed to learn how to do your transaction with SAP, and that transaction is then meant to be super efficient.

But many employees have to interact with SAP only from time to time. They're not supposed to be specialists at it, just get one action done from time to time.

Everyone in my company has to enter their hours in SAP monthly. The interface is terrible; is everyone supposed to learn how to enter a few numbers in a table once a month?

Or say there's a process I need to approve. I just need to read the attached PDF, and click I'm ok with it, maybe a couple of times a month. Where is the benefit of making me learn a complete new and arcane way of validating a task?

If you are not working for SAP SMM they should give you a call :)

You see SAP SMM effect in action – they trick IT guys into vocalizing their mantra in this exact form, since they know who their real threat is. SAP+IBM is a most powerful combo. The total price is so astronomical that IT guys who know how to manage it can have stellar salaries and still look like small happy asteroids floating around this SMBH.

I once worked for a company that uses SAP for several important business processes. The software provides great support for well defined areas like payroll, benefits, accounting and so on. It does not work well for things that are unique about the business (i.e. how it sells to- or services customers). For those things custom built software is usually a better choice.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact