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).
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.
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.
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.
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.
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.
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.
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.""
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.
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.
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.
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.
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.
"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.
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.
> 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.
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).
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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 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.
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.
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).
>>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 :-/
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.
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.
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.
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.
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.
> 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.
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.
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.
> 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.)
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.
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
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
"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?
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.
I was an ABAP developer around 10 years ago, wrote a bunch of Planning & Scheduling apps/"screens" running in SAPGUI R/3 and APO for a (brand new) manufacturing plant with a new SAP implementation.
I learned ABAP in a literally one weekend and was able to make stuff really quickly. For the most part, you could just "loop at <giant_table_name>" extract what you want and show it on a screen using one of their existing ui components. There was not much UI to worry about and you know the user is getting a proper input box (for example) with a working typeahead. Honestly, I thought it was a very decent developer experience. I could focus on what I needed to do and not worry about how pretty the thing looks or if I'm querying the database optimally. I ended up writing a very complex genetic algorithm implementation to calculate optimal schedules and it was a joy.
Yes, the table names were basically in german, and abbreviated, and most things were only 8 chars long for some legacy reasons, but it really wasn't that hard to learn that VBAK was sales_orders and VBAP was sales_order_items and move on.
For the most part, the users were totally fine with SAP. It was hyper-focused for the tasks they needed. It was consistent and easily documentable. It didn't crash, it loaded super fast, it didn't eat up gigs of memory. You just load up the gui application and you don't even need a mouse once you know the shortcuts.
Having spent the last 10 years building web and mobile apps, working with salesforce and others, I miss ABAP very often.
It's funny - I spend years as an SAP ABAP developer and the very day I start my new position apart from SAP, it's on the front page of HN.
ABAP will always hold a special, quirky little place in my heart. It's very powerful, but also totally frustrating. The language is a COBOL-like language made by Germans with a keyword graveyard as big as Berlin. The ABAP community (in my experience, online and offline) is totally unacademic: algorithmic complexity is a foreign concept, "code clarity" meant "hitting the Pretty Printer button every few years" (which was a nice feature), and there's no remote concept of best practices.
On the bright side, it makes for a good income, and the debugger is a gem.
No, you got code clarity wrong. Code clarity in ABAP means using System Hungarian Notation and it baffles me that almost every ABAP programmer I talk to think it's not redudant to use a command such as READ TABLE on a variable called GT_VBAK(for non-abapers, G for global variable, T for table).
The only advantage that I see is that for the most part, every program will look almost the same regarding standard SAP tables.
At some clients you have to sign their development guidelines, and you have no choice but to use that notation. The rule at big enterprises is that new rules get added, but old, even archaic rules seldom get removed.
> I could focus on what I needed to do and not worry about how pretty the thing looks or if I'm querying the database optimally.
No offense, but this is probably a big reason for the perception that SAP is a giant slow resource hog. Developers are abstracted so far away from the hardware that they have no way of knowing that their simple little program is resulting in 1500 database queries per page load.
Yeah, of course, as with any higher-level framework/system, someone has to pay for the computing required. If you go try to get a developer instance of SAP to play around with, I believe the minimum requirements was like a 4xl ec2. That's before you even start writing crappy queries :)
My biggest complains is running queries against tables in german. Most of my time is searching tables for fields i actually need. But i'm a complete SAP novice, i understand it gets easier with experience.
One thing I found helpful was to find a "native" transaction that does something similar to what I want then debug it. It was nice to be able to read and debug the existing "SAP" code.
Also, that was the only way I remember to find the "user exits" where you can extend an existing transactions.
For someone with a web development freelancing background wanting to get into enterprise software, would you recommend going into SAP? Would Salesforce be a better path? Which one is better for a freelancer working from home (if any)?
Feel free to share any other thoughts on the matter
I don't know about Salesforce, but SAP courses are really expensive. Just corporate users do them. It's almost impossible to self educate yourself without working in a SAP Consulting firm.
This is the reason I hate SAP. There are a small bunch of people who can know it, and they make huge money largely because of this artificial scarcity.
I think definitely Salesforce if you want to work remotely.
It's easy to get into, much smaller system in both scope and
complexity, and tons of free documentation. Get a couple of certifications, do the trailhead stuff, contact some consulting firms to tell them you're available for work and it should be easy to find work.
Getting into SAP and finding work can be challenging. They have a lot of new things from what I see but the majority of the SAP work you'll find is old non-cloud stuff that you'll basically need to have worked with at a company before to learn.
I went from SAP dev inhouse -> SAP dev consulting then jumped on the Salesforce wagon around 2011.
SAP work was enjoyable to me, partly because I was working in the manufacturing space, which I found interesting. Software-wise, it felt like I was 20 years behind everything, working on a mainframe.
Salesforce, I just immediately hated. It was just limits after limits and some crappy java-like language and html templating that took forever to deploy. It's gotten a bit better with lightning but you'll see the shit underneath pretty quickly. I also found the projects also extremely boring. Going from controlling machines and automated warehouses with SAP to projects about collecting email addresses and creating contacts felt like I made the wrong move.
tldr -- avoid getting locked into proprietary-land if you can help it
Not directly, but via a message sent from SAP to a PLC. The point I was trying to make is that SAP has a big foothold in deep the manufacturing space and Salesforce doesn't, so you generally won't get to work on those kind of projects with salesforce.
Salesforce is a very good path. I did it for a year, did a pm role and a product manager role. Ot was great. Loved the platform. The customer/clients were really into it, and the result ended great in both instances. Of course the platform and ecosystem is not perfect, but it was absolutely not bad. Highly recommended. Get an administrator cert course on Udemy for USD15. Get the administrator cert from Salesforce for USD100, and then profit.
I’ve worked with Salesforce a little (previous company used it and I worked closely with the SF team). It’s easy enough to get started - Apex is basically a stunted version of Java - but the dev and deploy workflow is very uh, “cloud native”, so working from home initially could be challenging depending on the experience the client has with SF, how many devs they have, etc.
All in all though Salesforce is pretty accessible for learning. Plenty of resources out there, and I know SF consultants make nice money.
>A piece of software that plays (at least) one sound on every user action, and the sounds are completely arbitrary and 8bit at best.
I've worked places that have SAP, Oracle, and one place that had both. I've never personally used SAP, and rarely dealt with Oracle.
I would be curious though, if it makes that many sounds - how much error checking is done because something "didn't sound right"? Does doing business tasks sort of turn into a song, with an expected sequence of sounds which feels wrong when not executed correctly?
If I'm typing and talking to someone at the same time, I intuitively know "I typed f rather than g, quick backspace and keep going". Do people internalize the pattern of noises they should hear while completing their work?
I assume that the sound refers to fact that about half of Windows SAPgui components are implemented by embedding MSHTML, which by default makes "click" sound for every onload event.
That sounds like a great feature for making software accessible to blind people. Even for sighted people, I can see how it could be useful.
The next step should be to have a database of standardised, free and open source sounds that can be used by any program, so that the same sound means roughly the same thing across all of them (assuming that this feature is not patent-encumbered).
You're better off spending your time making sure your general accessibility is up to snuff. Given standard OS widgets, textual error messages, proper i18n, etc. screen readers are much better at this than someone gluing on beeps and boops when they think appropriate.
>That sounds like a great feature for making software accessible to blind people.
Perhaps they should main for the larger market of making it accessible to sighted people first.
There are no words for how terrible the interface is. It is purely mouse driven and this is in no way a feature that increases accessibility to blind people.
The best advice about SAP I've had is that when a company is starting to use SAP, the company must adjust its processes to match the SAP model - not the other way around.
If you do it the other way, you'll first spend millions and millions customising SAP and then your project will fail at some point. It will also make all SAP upgrades completely impossible and they will cost millions and millions.
All of the successful SAP stories have been about companies who either match the SAP model already or reconfigure themselves to match it.
>Unlike many of their competitors, Lidl bases its inventory management system on purchase prices. The standard SAP for Retail software uses retail prices. Lidl didn’t want to change, so the software had to be adapted.
It is very possible but then that system is not for you. These systems are incredibly complex already and while there will always be some customization you should question yourself if this is where your competitive advantage is?
Is Lidl earning more money than their competitors because they base their inventory management system on purchase prices while others do not? Then build/buy a system that handles that and it could very well be worth it if you look at the business case
But if it is like that because that is how we started out and we cannot quantify how much better it is...then maybe you should just change your process.
I believe, that the difference between purchase price and retail price is a major and tricky one, if you set for retail, but if you can't solve it for 500 million, then there is something wrong with your software.
Also
"Critics inside Lidl say that KPS was too slow. But Matthias Nollenberger, a senior manager at KPS who was responsible for overseeing the eLWIS project, says his company was working too short deadlines compared to other similar projects"
I belive when you have the choice between aborting 500 million and increasing some deadlines, I doubt they were the problem. It simply was not possible to adobt SAP with reasonable amount of money. And the consulting company or SAP should have said that at some point clearly.
While I share your general notion that companies better adjust to the process of SAP, I still want to comment on the "impossible to upgrade" part, as that is simply not true.
First off, in SAP speech, "customization" is the act of simply adjusting the vast configuration options. This does not affect your upgrade possibilities at all. Even if you go so far as to add custom programming, as long as you (lowest complexity) just have programmed additional "transactions"/reports, you will usually not run into a problem.
The system also provides various mechanisms to extend standard transactions via hooks or to extend standard tables and still be able to upgrade without additional effort. I was actually astonished how much customization SAP allows in that regard while still staying compatible to the standard codebase - probably one of the reasons everything is so damn resource hungry, because there are multiple layers of indirection at work to allow this. From a development point of view, the major annoyance here is there are so many different options to extend stuff from different decades, so for some use cases you will use BADIs (https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=1...), for others "exits" (https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=1...) and it is all a pain to lookup and locate.
The one thing which will get you into trouble is if you manually patch standard programs - which you are able to, the whole business logic comes with sourcecode - and which is usually not necessary.
That "customization" definition is not quite right. Configuration is not typically called customization. A lot of companies use "Z" programs (a prefix indicating something is custom) to front-end or augment existing SAP functionality. Companies may also create user-exits in SAP programs, or additional code to run when something happens ("send xx an email when the first sales order for a customer is created", for example).
When they upgrade, these additional programs require regression testing. Those programs make upgrades risky, and those programs may need to be rebuilt. Historically, companies built a ton of these customizations, then had issues during upgrades. The most recent model (since S4 and HANA emerged) is to do as much as possible in configuration, and limit customization.
Configuration IS typically called customization in SAP. "The Customizing" is SAP speech for the sum of all configuration settings and it IS DEFINED THAT WAY IN THE OFFICIAL DOCUMENTATION, even in the english version (the difference is more blatant in the german version, as "customizen" and "customizing" are not german words, but still used in the german docs to specifically refer to the configuration section of SAP)
Let me quote:
"The term Customizing refers to the process of system configuration during which the members of the project teams make the required system settings. In the SAP System, Customizing activities are performed through the Implementation Guide (IMG)."
And no, this leaves no room for interpretation. The IMG is basically the centralized config setting catalogue of SAP and does not allow programming.
It may not be, what is typically meant with customization or with other systems, but in SAP "customization" refers by definition to anything which can be configured WITHOUT programming.
All documents clearly differentiate between "customizing" = using the configuration, "extending/programming/development" which would be Z-reports etc., "enhancement" with user exits, BADIs and the like and "modifying", which would be patching the standard programs.
And yes, of course upgrades still require testing. But saying it is "impossible" to upgrade just because you have z-reports and the like is plain wrong. Most of the time, especially if we do not speak about a full blown ECC to S4 migration, which involves large scale changes to the underlying database structure of the ERP unlike upgrades within the ECC line itself, you will not require updates to your z reports at all.
I work for a competing ERP software house and this is the first bit of advice i give after introducing myself.
Customising an ERP can be interesting, keeping it supported and updateable 5/10 years after the guy who wrote the mods retired is a nightmare i've seen one too many times before.
SAP today are just plainly incompetent and ripe for disruption. I've had quite a bit of interaction with SAP over the last few years, here are some examples:
- Almost all meetings I've been in start with prospective clients mentioning to SAP consultants that SAP has a 'certain reputation'. The SAP consultants acknowledge this.
- Some of the solution pitch ideas they come up with signal they have almost zero knowledge of how some technologies actually work.
- Services we rely on with SAP frequently fail for no apparent reason.
- They are slow and uncooperative with setting up demo environments and responding to support requests.
- Their licences and consulting fees are outrageously expensive considering the lack of quality and performance when compared to alternatives.
- Tech leads in our own company frequently talk about how bad SAP solutions are.
- Their poor UIs are what they are known for in the market. They've tried to address this with things like UI5, Fiori and Fundamentals which feel like too little too late.
- Their attempts at acquiring startups (AI, chatbots, analytics etc) to stay on the edge provide hardly any real value besides propping up the credibility of the buzzwords they cram into their presentations.
Yet SAP remain entrenched in the market and companies still get into bed with them despite knowing the pain they're in for. A lot of system integration companies have tried to attack this market with open source solutions and have failed to make any real dent. The only major player that has started to eat SAPs lunch recently is Salesforce.
Perhaps I'm missing something but surely it would be better for an organisation to have a solution that can be maintained by more than one company so that the company can be replaced if they aren't performing?
The only example I can think of where this is being addressed is the UK's GDS Service Standard which mandates that all government projects should use open source tools to avoid vendor lock-in. It really is perplexing how SAP still maintains its position in today's market.
It really is insane, I know people who don't even work for SAP, are "IT consultants", whose credentials are a (very good) Art History degree and travel around nationally and internationally to essentially push a button to do SAP database migrations after mergers and acquisitions. There are independent companies that just live off the fact how bad SAP is.
I am an IT Consulting (not with SAP) who has a Computer Science degree. I would not hesitate to hire a liberal arts major for a technical role in my company. Programming and analytical thinking is a tiny fraction of my job; most of it demands public speaking, organizational skills, and business relationship instincts.
If these people work at a firm like Accenture that just outsources the technical challenge, coding skills become completely unnecessary.
Also, a ton of the industry is built around the risk of something unexpected happening after you push the button (as mentioned below) and distributing blame if the end-result isn't precisely what customers anticipated (the old "Nobody gets fired for buying IBM" adage)
It may seem backwards to people outside of giant organizations, but it is a necessary aspect of modern business (and there are tons of industries that make more money while generating less value for society).
Frankly, computer science knowledge and software abilities can be a real liability as an engineer.
Many times what is needed is to let go of a sensible technical approach and just help the organization go where it is trying to go. It may not make sense technically, but it makes sense to the org, and that sort of matters more. I find my knowledge of good architecture often just makes it more painful to watch the code go through the inevitable logjams, rewrites, and process failures that are a crucial part of an organization “feeling” it’s way through a very complex multi-dimensional domain that includes many considerations that have nothing to do with code.
I think in many ways, people with less technical skills can do that better, to live in the meta space.
My brain keeps getting dragged down into the “why can’t we just do the sensible, minimal, technically correct thing that needs to happen for this problem to go away”. But the answer is “because the org doesn’t see the problem the way you do”.
What good is it if I can solve problems no one else in the organization even recognizes as problems?
It must be a little bit more difficult than "pushing a button" if companies have to hire an external consultant for that. But yeah, SAP has huge ecosystem of external companies that profit from SAP's fails
It often really is just pushing a button. But you can never tell in advance, and the real value of such consultant is knowing how to fix whatever breaks if it does.
I suspect the only reason for their continued relevance is that they're too big to fail. So many huge enterprises rely on SAP, and its way too integrated into their core business processes to move off it at that point. Management elsewhere follows the larger players, and from what I've heard, SAP consultants are great at luring.
You should never discount the inherited biases of senior management. So many times I've seen a company implement SAP because the C-level employee in change of a software appraisal stage used SAP before, it worked before and just assume it will blindly work now.
ServiceNow is another disruptor with an interesting approach similar to SalesForce. SNow started as a Remedy alternative, but really saw IT groups as the infrastructure that every other Department relies on. While SAP hold influence in a company by controlling the purse strings, a good ServiceNow implementation holds the Microservice and Technology information every group is reliant on.
I'm not as familiar with SalesForce, but I think it has a similar stake by focusing on CRM. If you start at the customer data, you can influence the profit centers and influence a company that way.
I mostly mention these success stories to say that a Goliath like SAP won't be taken down by one David, but by a ton of ankle-biters eating their lunch. Maybe these ankle-biters will be easily replaceable, but I wonder what an organization where Enterprise Software is constantly hot-swapped will look like, given how inefficient Application Retirement projects can be.
The Industrial Plant I work at uses Service Now (For IT and Helpdesk support) and SAP (For Payroll, HR, Purchasing, Maintenance Scheduling etc.). Service Now is much, much worse. IT department is so dysfunctional and Service Now is a big part of that.
One of my coworkers refers to it as "Service Eventually"
I'm amused by the amount of third parties (Sumologic for example) that have ServiceNow plugins. I'm curious what kind of usage metrics they have on the feature. I suspect it's just a feature parity/selling point but not actually used in practice, like EKS and managed SFTP on AWS.
Nowhere I've worked that used ServiceNow encouraged solving practical problems with it. A grand total of once I took a crack at something that would have been trivial if Sumologic could alert to ServiceNow. It became hilariously obvious in 3 or 4 back and forth emails with the gatekeepers that their 3 month testing process, 45 emails, and 16 meetings requirement for a one line change was not cost effective.
My time was better spent crafting an email forwarding rule that sent the related conversations to the trash and moving on to solvable problems.
And a hundred other specialised systems which fit their niche markets. Not everyone needs a full stack ERP/FSM/CRM solution, their are almost as many players as variations in requirements.
I would agree with your criticisms of most of those companies as not being suitable for large companies, but I would argue Salesforce is definitely an option for large companies. I see job postings for Salesforce developers from companies like Google and Facebook all the time, and personally every company I've worked at as a Salesforce developer has been a Fortune 500 company.
In the logistics sector, transportation, warehousing, forwarding and so on, SAP isn't that strong. I started using Cargowise One in my company (started a couple of month ago, so ask me again next year how I like it!). Warehousing and transportation being things I would use solutions other than SAP and connect them to it. If I really need a MRP-function, that is.
SAP always is an interesting case. It gets close to zero love from HN, yet the platform has some interesting engineering.
For example, they had their own language that abstracts and operates directly over a database. They had their own drag and drop UI builder, that compiles down to a HTML page or a desktop widget - which is again not an ordinary feat. They view code as data, as in even the UI is stored as a configuration and not as some Java code. They had their own VCS back when Git didn’t exist. Of course, all these weren’t best of their class, but they sure did get there ideas right.
All these must have been interesting engineering concepts back during its time, yet there hasn’t been much tech literature on how they accomplished it or what inspired them to. At least not that I know of.
Now that open source is on fire, of course a single company cannot catch up with the pace these open source softwares are racing ahead.
Companies like Zoho and Salesforce are able to catch up because they do two things right.
#1. Cloud
#2. Adopting open-source and making a clever mix of proprietary engineering
The next SAP or Oracle will certainly be companies that get those two things right.
ERPNext is a full featured Open Source ERP (GPL V3, not open core) with reasonable traction. https://github.com/frappe/erpnext Disclaimer: check my bio
I agree with everything you said, they did some pretty neat stuff! the problem is that they started getting things wrong(from the development perspective) somewhere along the way, not sure if due to backwards compatibility or due to massive lock-in's with their own technology.
SAP right now is making a move on cloud using SCP and as open source goes, openUI5 exists.
I don't have much to say about SCP, just that the company I'm on decided to not use it, basically because we don't see advantages and to avoid future lock-ins
About openUI5, I honestly dislike it, the most useful features of that framework are locked inside SAPUI5(a supersetof openUI5) and pull requests are managed by a branch of the company itself and they are pretty harsh on it. SAP documentation on it can be bad and is entirely biased towards deploying things inside SAP or SCP, which is pretty annoying
It isn't. Because when they started, there wasn't any "outer" platform the speak of. The platform underlying SAP is essentially an way to have mainframe-like development environment (updates of almost anything without restart, declarative UI library, minimal overhead for inactive users...) on something that isn't a mainframe.
In the 90's I was one of the project leaders on the internal SAP R/3 deployment at Microsoft. It was one of the most successful IT projects I ever participated in, mostly due to the remarkably strong business leadership the project enjoyed.
It was the third time the company tried to implement SAP's products. I think I may have been one of the very few people who worked on all three attempts. The winning recipe was having a business owner who threw up his hands at the failed efforts to get a larger scoped company-wide project underway and "selfishly" declared that the finance dept would do it for its own benefits. And he tooks his best people out of their day jobs, put them on the project team, and made them move offices to sit in the same open plan war-rooms as the IT staff (which took some doing...Microsoft was pretty much all unshared private offices at that time) I think we reduced the time it took to "close the books" each month from something like 3 weeks to under one week.
And we absolutely changed the business to meet the way the software worked, that's one of the key success factors for implementing any ERP software. Your "unique requirements" for fixed assets accounting and accounts payable processes are not what makes your company successful, but they are what will tank your ERP implementation if you let them.
It was a fascinating project. I especially enjoyed some of the travel to implement it in the subsidiaries, where the really big business wins were. Most of the subs didn't even have a "purchase order" process (they just paid invoices, and had no idea of their outstanding commitments) or any automation around things like employee expense reports. And we got to come up with some decent creative solutions to things like Brazil's requirements for hyperinflationary accounting, without breaking the software.
Fun fact, Concur's expense reporting business was borne out of the Microsoft R/3 implementation -- some of the best consultants and developers took what they built for Microsoft's internal expense reporting and turned it into Concur's expense reporting product.
No idea...I left in 2008. At that time, it was still being promoted as a big success story externally. It was turned into a "IT showcase" case study to show customers that SAP could successfully run on SQL Server and Windows. I did maybe 30 presentations of that case study to different customers at Redmond and South America. Internally, we did what we could to soften the hard edges of the SAP UX for the casual user by putting web app front ends on top of things like purchase orders expense reports.
TBH SAP is almost required for big corporations as they usually are publicly traded companies, require external audits from BIG4(and these guys know how to get data from standard SAP models, not so much from you self-developed system) and have to report their financials in consistent way.
For example Apple, Microsoft, Amazon and Google all can use SAP internally. But it would be false to state that all their businesses are run on SAP...
Every respectable ERP provides ways to export/access the data in a way that covers all national/international requirements for audits and reporting. This is not SAP-specific.
I didn't say that there are no other factors (like for example that CTO won't be fired when SAP/Oracle implementation fails, but will be 100% fired when ERP_X implementation fails)
I only pointed out that the statistics in parent post can be skewed due to the sample of top 500 corporations which can implement SAP for reasons different to running the business.
I would be interested to know if they are actually using SAP. These companies are so much better at software development and they are swimming in so much money that they could even implement something by themselves.
Why would they? It's none of their core business and SAP already has everything covered. Think of all the legal/financial stuff. The UI is not that important in that field, your domain expert in that area knows how to navigate stuff.
It wasn't Amazon's core competency to offer IaaS/PaaS, before they did.
GCP and AWS are closely playing in SAP's enterprise customer base. There is huge addressable market there. They've innovated better than SAP in technology space, on parts other than business software.
If they can succeed developing their own ERP, better than SAP, they could even redeploy the development teams from being cost center to profit center.
If I am SAP, I see them as strategic long term risk.
Established ERP systems take so long to configure that sometimes, it makes more sense to write your own in-house. Tesla did just that. And in only 4 months.
> These companies are so much better at software development
That's like saying "why doesn't Tiger Woods win Wimbledon? He's so much better at sport than anyone else". There are lots of different types of software development, and lots of different types of software engineers. Corporate IT projects don't succeed or fail on algorithmics - it's a completely different job, where 90% of the difficulty is managing people and politics
That's impressive. Of course Apple distributes hardware, so it makes the most sense to me. Microsoft, I suppose, had to distribute Windows boxes at some point, so it makes some sense to me.
But I definitely wonder at which point Google started seeing a need for SAP. As soon as they started selling gadgets? Before then, to generally manage finances?
I always wonder about the reality of these kinds of statements. The truth ranges from the optimistic version "we're heavily making use of this software" through "we made use of it a few years back, and are now phasing it out" and "we use it for one or two core services, but everything else is run on Y" all the way to "we have a single instance somewhere we forgot to switch off and we still pay for", etc. This is a bit of a special case, but still, the reality is probably somewhat different than the face value.
> "[SAP] customers distribute 78% of the world’s food and 82% of the world’s medical devices"
That sounds wrong, as I am pretty sure the majority of the worlds food is distributed in places that can't afford or need SAP (and is essentially sold black market). I doubt that street markets in India use it for example.
It sounds like HN readers could stand to spend a little time studying microeconomics.
I would love to see a Valley solution to the problem of sourcing raw materials including energy, storing raw materials, sourcing packaging, storing packaging, sourcing machine parts, storing machine parts, keeping track of vendors, machine maintenance labor, machine maintenance scheduling, cost accounting for the inputs, manufacturing and machine schedule management, demand forecasting, supply & replenishment planning, WIP inventory management, finished goods inventory management, inventory accounting, sourcing shipping, planning shipping, actually shipping, invoicing, printing invoices, printing all documents (manifest, bills of lading), extending credit, managing credit lines.....
oh yeah accepting purchase orders, making to order, promising inventory, managing inventory allocation in tight markets, managing in transit inventory, collecting payment, transferring cash, reporting all of this to the SEC and IRS so you don't get sued, remitting taxes, managing headcount, paying employees....
I probably forgot a lot of stuff and this is only for domestic sales. Export has so many other problems to solve like tariffs and duties, container management on the dock, steamship management, etc.
I'm not being sarcastic either, I would LOVE to see a solution that has a better UX than SAP that solves all of these problems.
Everyone used to say the same about every product ever created. Until the new market player came into town and proved it could be done.
The answer is pretty simple actually. You make a couple of billions a year. Invest a single billion in a full UX revamp for 5 years down the line, and see how it all works out.
Throwing money at problems doesn't always work, but when you have a lot of money, and a very specific problem, it tends to work.
If the answer you get is this terrible, then maybe you're asking the wrong question.
For example, I know the tale of a large multinational consumer goods company who bought their supplier for X. Coincidentally, the X supplier was also the largest exporter of X goods to the world and had a team of twelve who managed operations. The multinational company, in their great wisdom, decided to move the operations from what we Turks call "bakkal defteri" (basically pen and paper) to SAP. It turns out that twelve people were not enough to run the system over SAP, and they basically had to tenfold the number of operations people just to get it running.
A whole sea of comments, balmost all focused on the tech stack, reporting, UX, integration ..
SAP's selling point is regulatory compliance and financial control. It doesn't matter if you have a great UX or lightweight extensible third party API ecosystem, what matters is "When the IRS / SEC / Congress / Interpol comes calling, am I clear?"
Government regulation is the ultimate "vendor lock-in" and SAP exploits that fact.
I work for an SAP subsidiary and this is the correct answer. You buy SAP software to 1) reduce your chance of getting audited and 2) get through expensive audits quickly.
The everyday end-user of SAP software isn't the one it's designed for. It's designed for lawyers and accountants who need to organize data quickly when the shit hits the fan.
Years ago I was involved in a project to scrape certain info out of a SAP system with a web interface. It would have been easier to do it with a API but my conversations with the SAP people at work were going nowhere (is it me or do SAP IT people have no concept of how things are done outside the world of SAP ?).
Anyway I started looking through the Javascript the browser automatically downloads and found there was 10s of MBs of un optimised code only a tiny percentage of which was being used. It was horrific and it was easy to understand why the system was so mind blowingly slow.
> is it me or do SAP IT people have no concept of how things are done outside the world of SAP ?
SAP has strong NIH syndrome. They could get away with it due to their dominance.
So these guys are in echo chamber of own. It reflects and explains the observation you have here.
> 10s of MBs of un optimised code only a tiny percentage of which was being used
frameworks!
they try to scale development with frameworks, and end up in dilbert-esque side effects like these.
There are/were 5 different Web technologies over the years you could use to make Web apps for SAP. There are also standard WebService (XML SOAP) and REST interfaces over HTTP. There are also SAP native interfaces for specifically transferring data.
There are ways to do stuff in SAP, lots of implementation problems arise from the fact that people don't know how to do it right, and just try to apply whatever they do know. There is documentation and there are books.
The problem with SAP APIs and services is that each user that uses the system is billed individually. When you try to build an app that helps one department you have to pay for each of the user accounts despite the fact they just use your app, not all the other stuff. On top, there are no real pricing schemes to know what is coming at you. Either 100$ per user per month or 5000$. Depends. The cloud solution doesn't make that easier.
I think the logic is that the Web API's are for apps doing things you would otherwise do in SAP's own GUI.
But i agree, SAP is not for those who are sensitive to license prices. Most commonly the solution is a third-party custom built software, that interfaces the data into the back-end SAP system.
The OP's comment was about scraping data from pages generated from SAP Web apps. I tried to point out that it make little sense, as there are proper ways of interfacing data (even over HTTP).
We did that, with one technical user to share data between our backend and SAP, but got the news that it's not legal and must be licensed per user that's using our app. Even over http you can't access data in SAP without paying your fees accordingly.
It is legal to do that. Its the question how tight your app was doing it? If you just send user actions and answers over HTTP back and forth using a technical user, that's like sharing the user. But if you have your own billing software (for example), and submit finished bills with a SOAP request (for example) to SAP, that is completely ok.
ehh if you have access throught http(hopefullly)s into a webbrowser and consume it with your eyes, can't i just puppeteer it ? heck event print screen and OCR ?
We figured out how to get at least some reports to export into Excel. Some others implemented MS Access dbs to postprocess exported SAP data. Browser tricks were also part of the mix. Then the directives came down that working outside of SAP was not acceptable and amounted to criticizing SAP.
I think SAP views APIs as a threat. That COBOL-like ABAP language is part of their lock in.
Working outside SAP for things you are using SAP is one of the worst ideas, ever. You create data redundancy, jeopardize compliance, erode user trust and make migration and even simple changes near impossible. So yes, forbidding that is a good idea. One I enforced more than once. Well, at least I tried. Might even have worked once or twice.
Reasons why people started working outside of SAP:
- because they didn't know the system well enough and didn't receive proper training. Sometimes also out of pure spite.
- sometimes because SAP didn't have that functionality yet. Ship planning for example was an issue in the early 2000s IIRC
- because people wanted and had to use a SAP-standard process, but couldn't because somepone else ripped that standard appart to do something differetn. Either because the original standard for that was itself ripped appart by someone else. Or because people refuse to follow the standard out of reasons. Misusing standards is beast in SAP. Once you start with a single process, that spirals out of control and cannot be stopped. Part of the reason a lot SAP implementations just suck. Not purelySAPs fault so.
> because they didn't know the system well enough and didn't receive proper training
A lot of the interactions that simple employees have with SAP shouldn't require training though.
I shouldn't have to get a training to be able to fill a small list of hours, and it shouldn't take me 30 minutes to do so. I shouldn't have to get a training to be able to read a received request and validate it.
While I get that sentiment I don't really see the ecosystem much worse than vendor lockin at any of the modern PaaS providers from a tech perspective. They always allowed integrators relatively extensive API access to their table model, last time I had to integrate that years ago the only hurdle was a bit of interfacing between the report / ABAP world and exposing it as a web service. Even management / security facilities were, albeit usually clunky, what you expect from a modern ecosystem. These days they seem to offer relatively modern and off the shelf APIs for quite a few of these tasks, especially for their cloud based offerings. I'm not sure that they see it as a threat, rather they want to be the single point of truth and lots of projects (completely separated from any tech aspect) would circumvent that.
Now was that a pain? Yes, sure. Especially the whole legal/certification/consultant crap you need to buy into alongside the software. But honestly, at least here in Germany, SAP ABAP/Java developers and consultants are easy to come by. Most of the problems I've seen in SAP related integrations are process related, not as much tech. If you're dealing with a customer that's already up and running in that ecosystem chances are that they already know their pain points, it's not really any different than any other large B2B integration in the space.
> I think SAP views APIs as a threat. That COBOL-like ABAP language is part of their lock in.
This bit is changing now.
They're still not there, but internal engineering teams are slowly getting it.
There are high priority API first development projects underway.
I once worked on a project that only existed because the end users had seen the SAP web UI and rebelled, hard. In fairness I don't blame them; when we dug down it was easily the worst HTML I've ever seen and some impressively weird behaviour. I can't quite imagine which team at SAP thought it was appropriate to release as a tool.
So, we spent 6 months or so building a front-end that the users wouldn't refuse to touch. HTML5, responsive, attractive, flexible. I mostly worked on the toolkit side of the project to try and keep UIs vaguely standard across the multitude of screens.
And alongside us, the two highest paid contractors I've ever worked with (who seemed to be earning their money), were building what amounted to SQL stored procedures that went into a tool that let them be interfaced as REST APIs. The article talks about the amount to which businesses have to mash themselves around how SAP works - from what I saw and heard, that was even after they'd spent more customising SAP than I would expect to bill to have built very large parts of it from scratch.
So yes. I'm sure that, at a really large corporate scale, SAP has its advantages to organisations. But in a 20 year career it's probably my least favourite technology, including the email server which you could misconfigure so receiving an email would bring down the whole machine. I wouldn't be remotely surprised to see SAP disrupted into oblivion, and a bit of me would love to be part of the disruption.
A lot of this is just plain pointless bravado. Eventually a lot of people have to outsource their payroll and other admin work, it's just cheaper that way.
Then you just discover your are doing many things unique to your company so you kind of have to retrain a lot of finance and office management staff. And keep retraining them. Then also maintain teams of programmers to do maintain your software.
You don't want a car company to focus its resources on payroll software.
Not necessarily true.
The place I work at does the payroll with some cheaper payroll ERP. Most other things...well let's just say a programmer to make the entire thing was cheaper and more effective.
The ERP has to interface with various NFC and barcode scanners, ticket printers, etc other companies appliance interfaces, the consultancy costs to adapt and existing erp and make it keep track of the entire production process and it's unique quirks would be trough the roof and make any subsequent version upgrade unmanageable cost and time wise.
So Tesla is again loosing focus? man, if they would just focus on a) developing EVs and b) mass-produce them traditional car makers wouldn't stand a chance by know. That hybris can kill them one day...
My understanding is that SpaceX built their own ERP system in-house and then shared it with Tesla. So it's possible that "4 months" was really about forking/customizing it for their needs.
SAPs magic is the integration: A company I worked for rolled out SAP for a Production and supply chain distributed across about a dozen countries in Europe and went from 3+ weeks order commitment time (Not lead time) to immediediate including sourcing from external suppliers, logistics Partners and Production facility allocation.
There have been several high-profile cases of German companies migrating to SAP (from their home-grown zoo of different software for different purposes) that have gone spectacularly wrong. They are way over budget, way over time, and sometimes abandoned completely, like with Lidl: https://www.consultancy.uk/news/18243/lidl-cancels-sap-intro...
I have heard (anecdotally, and third-hand) that the only way to successfully introduce SAP (or Oracle, for that matter) is to completely succumb to it and restructure your business along the lines that SAP assumes as default.
You try to keep your little company-specific process for buying christmas gifts to employees? Fine, but it'll cost you several hours with an SAP consultant. You try to keep your non-standard terms with one supplier? Fine, another bag of money.
You do that more than just a very few times? Your migration has failed.
The problem nobody wants to admit is that any competitor to SAP will just become SAP. SAP grew to what it is because it was made to fit everybody's workflow to make sales to businesses wanting ERPs.
Business is a wild world of so many ways to structure the org down from workflows to departments which is basically the only thing that differentiates a large majority of businesses these days.
Sure, you could enforce a single cookie cutter approach for everyone, but then, how is corp A any different B anymore when everything is identical besides the people itself, heck their costs should equalize as they should in theory have the same workflow optimizations and inefficiencies.
"The problem nobody wants to admit is that any competitor to SAP will just become SAP."
This is an entire category of software. Closer to most of our homes, see "bug tracking software", "web frameworks" (frontend or backend), or "programming languages". Countless examples of someone getting frustrated and starting a "lightweight alternative", gets lots of attention, gets lots of customers who find various issues and features get added to address them, and before you know it, 5-10 years later, the "lightweight alternative" has become the monster the next generation of "lightweight alternatives" are being started up against.
I'm actually at the point where I consider advertising something as a "lightweight alternative" to be nearly a strike against one of those things; it likely means the author doesn't understand how the previous things got to where they are and are just going to follow them down the same road. If you've got a coherent story on how to address that, talk directly to that.
Of course, if you're a new bug tracker/framework/language author, you'd probably rather get the numbers you can get from advertising "lightweight!" rather than the smaller numbers you'll get from advertising "we're going to contain complexity by an aggressive modularization system based on the principles of ...".
I think the big difference is that you can re-implement your website in a new web framework, open source it, and then get traction, etc. You can also do this with ETL frameworks (i.e. Airflow) too. Disruptive software is easier here as developers can run this new framework in parallel, or even as a side project to test it, provide feedback, or even help implement changes upstream. If something goes wrong, it usually has minor consequences. Something like an accounting system has challenges as it involves historic records and data, but at least you can test inputted data and results. With an ERP system, it touches the physical world so if a shipment is sent to the wrong place or doesn't happen, etc. the cost could likely be a much larger headache to deal with IMO.
It's easy to roll your eyes when you hear "disruption" because it's often used as a meaningless buzzword, but it describes a very real dynamic where "lightweight" products can disrupt outcompete heavyweight products in a large chunk of the market (https://en.wikipedia.org/wiki/Disruptive_innovation). There are good business reasons that the products became heavyweight, but it leaves an opening where a smaller product can steal a chunk of the competitors.
JSON disrupted XML. There really are ways it's strictly less capable.
The majority of these projects are created to explore an idea, they are not meant to get big. They work well for small companies or niche customer bases. When the public and investors show up with demand to be big and cash is the author supposed to turn it down?
The amount of good money thrown after bad on Kickstarter shows the money has no idea what it's investing in.
And let's not forget Hershey's disaster which they blamed on SAP and their implementation partners, mentioned here with 14 other ERP failures (yes, SAP is predominant, but there are other offenders as well...; article Oct 2019)
SAP projects don't fail because the software doesn't work. They fail when business and IT leadership are weak or don't understand what it takes to get these projects done, or they are doing them for the wrong reasons.
> By using Target’s existing technology, employees in >
Canada could draw on the large amount of expertise in
the U.S. That plan had shortcomings as well. The
technology was not set up to deal with a foreign
country, and it would have to be customized to take
into account the Canadian dollar and even French-
language characters. Those changes would take time
which Target did not have.
Given Target's original system didn't have a multi-currency approach or use UTF8, my guess is the implementer (in this case Target) is also part of the problem.
It is hard to disrupt this type of software as migration involves migrating data, which is hard, in addition to changing a lot of employee workflows. Potentially, if something like 3D printing of metal parts took off, it could mean a new type of ERP system would be necessary, allowing for a new player to come in.
It was Target's fault for not having fully grasp their OWN requirements (I was following this case when it exploded in the media). They just blamed SAP because their mistake cost $1Bn and it looks stupid if they did admit it.
That's not really the impression I got from the article at all. There were many factors that contributed to that debacle, but SAP seems fairly far down the list.
I’ve witnessed several SAP implementations, along with the buying process.
In short, it’s seen as a safe option, because it’s what “everyone else” uses, and the decision makers have typically come from businesses where SAP has been used.
Nobody actually likes it - but they don’t see any alternatives as viable.
Similarly, I’ve seen folks migrate to and from the various MS Dynamics platforms, and it’s a universal shitshow, with the exact same reasoning, just a different tribe.
ERP software generally sucks, as it has to be all things to all men, ends up customised to meet needs which are obsolete by the time the customisation is complete, and it usually either gets to the point where nobody understands any of how it got to be the monster that it is, and a long and painful replatforming happens, and the cycle begins again - either with a new supplier or a new version of the same old.
The question isn't whether it "sucks" or not, but rather to whom it "sucks".
It rightly reads as sucking to us as tech-savvy developers, but that's not the reality for the actual consumers of such products who are not programmers. To them, irregardless of our protests of inefficiency or bloat, there are only 2-3 possible platforms and the competitive advantages of each over the others are judged on entirely different criteria than we would use.
Remember the first rule of design (for better or only in this particle case, almost certainly worse): you do not represent your users.
I was one part of the latter group. And am also part of the former, evidently. User from the latter group hate it, rightly so, for bad UI and UX. I do, too. But then I see the intercontected processes you have to run a busniess. And you have to run your business, to a certian degree at least, digital. from that perspective, SAP sucks the less. Which kind of makes it a good software I guess?
> it seems the consensus is that it really does suck
It sucks to the people who has to use it and maintain it. It doesn't suck for the people who sign the checks that pay for the licenses and the hardware to run it.
The cost/implementation of SAP is so big that the decision to use it can only be signed off at C-Level.
Any company who is looking at SAP is likely doing business in the US - Sarbanes-Oxley means CFO and CEO have to personally sign off on the financial accounts and are criminally liable (am sure it's the same in other countries).
SAP at it's core is all about financial control. SAP sell SAP to CEOs and CFOs by telling them it will provide strict financial controls to their company and avoid them personally going to jail / paying huge fines. It's an easy sell
This is probably even worth it. Once your company has anything more than a few hundred employees, financial accountability itself at any level is a serious problem enough to warrant some kind of financial control.
If you didn't have it a lot of money disappears without a trace.
'More modern' these days appears to be the 'thousand papercuts' approach - many SaaS products that collectively provide the same feature set.
It's still hell, just a different kind of hell.
Bespoke is a genuine competitor. In the UK it's not uncommon for SAP implementations to cost several million £s, this could be used to build bespoke software.
There's a massive risk here though - there are thousands of ways bespoke ERP can go wrong. Underfunding the project causes problems, but arguably the worst projects were overfunded. Then there's recruiting the right people and developing the right culture - archaic business hierarchies are almost mutually exclusive with good software teams.
In other words, there isn't really a very good option. You can understand why business leaders, who are often not technology experts, would go with something that has 'worked' for them in the past.
Bespoke is expensive but sometimes the least expensive option. I worked at a company that just hired an auditing consultant firm to certify their existing system. It took a year of locking down existing processes and slapping approvals and change management on everything, but at the end the system stayed more or less the same with minimal changes in business process required. I think they made the right choice, but they had the personnel, time, size, and money to do it. I think it would have been riskier, taken longer, and been more expensive to buy an ERP (NetSuite and SAP were evaluated), and the business came to the same conclusion. However I would not recommend this for for any company with less than half a billion in revenue already!
M&A (mergers and acquisitions) is a big factor - for most large corps it happens all the time, you haven't finished integrating all your acquisitions before you get new aquisitions or get acquired yourself. So if you go the bespoke path, you have to continuously migrate departments and their data off of SAP or something like that. And when you get acquired, you'll likely have to migrate to SAP or something like that - and, more interestingly, you may come to a situation where you need to migrate to SAP or something like that before an acquisition to remove a potential risk factor for the acquirer you're targeting; that's going to cost a lot but it's worthwhile given the expected M&A money.
True! But than, when Amazon started, there was no solution for their problem, e-commerce with an integrated logistics software suite, available. Which gave Amazon a huge advabtage over competitors. That changes since a couple of years if you ask me. Which could be a problem for Amazon in the long run. Very long, so.
Out of the box, probably nothing. Something that supports all features you will actually want to use? That depends on who you are and what you actually need to do but, then, you'll need to figure out what you want, what you need and what is available on the market. This assessment is, in itself, quite costly.
> I've seen at techcrunch Berlin 2019 that there is something called SAP.io, somewhat opening its plateform ?
No.
SAP.io is how SAP thinks it can hit long arc innovations. It runs accelerators for „entrepreneurs within SAP“ who would otherwise have no chance against corporatized SAP.
What else are they gonna choose? Even SAP implementations fail, it's $10-100m project. Execs are not going to go for slightly better software to increase the risk of blowing through millions and wasting 3-4 year to end up with the same system. That's how SAP sells
"A basic installation of SAP has 20,000 database tables, 3,000 of which are configuration tables. In those tables, there are ~8,000 configuration decisions you need before even getting started."
He's conflating SAP (a company) with the ERP system, but reality is a little different. There are 133,000 tables in a system I just checked, and 40,000 are flagged as configuration.
I suspect an awful lot. I worked at a place that did their own ERP software and that had thousands of database tables, many of which were simply enum fields.
The entire system required magic numbers to be put into various columns in different tables, simply to modify the behaviour of the "logic" code as it resolved to a C++ enum once extracted from the database.
It was horrible, and nobody knew how the entire system worked, so there was a vast disconnect between what it actually did (and the hundreds of auto-generated SQL statements it ran, very slow) and what they thought it did.
As expected, this created wildly different expectations of what was possible from the internal "implementation" team versus developers.
Of course, this was interpreted as the developers' fault, and there was a constant stream of new developers that would stay for a year or two, then leave. Toxic.
I worked one summer (2014) manufacturing emergency stop buttons for ABB.
We used SAP for our incoming orders. Each order was printed on paper as some kind of report from SAP and put in our physical inbox. When we had manufactured buttons for an order, we would go to a desk with two computers, both logged in to SAP. With the first computer we would scan a barcode from the order to find it in the system, mark the order as done, and print a second paper containing the order.
Then we would proceed to the next computer, scanning a barcode from the second paper, and produce a freight order for the outgoing warehouse. This was printed to a third paper, and attached to the buttons, before they went to the outgoing warehouse.
Note that the freight order did not work as a waybill, so the process of shifting paper was probably conducted a couple of more times before the order reached the customer.
For someone really used to working with computers and not against them, it seemed rather innovative to print a paper to transfer an order to another computer two feet away. It was a learning experience and greatly motivated me to go get some higher education.
What did you do with the paper you used between the two computers? Did you toss it or was it filed somewhere?
If it was filed, my guess was that it was an internal control measure. They wanted to make sure there was a paper copy of every transaction for audit purposes, and what better way to make sure of that then requiring the paper to move the order forward?
If you tossed it, then it sounds like they were just too lazy to implement something other than the default config. :)
I used SAP at work to keep track of monthly working hours. The GUI had this... feature that doesn't allow you to resize the form you're working with. And you can scroll vertically, but the first columns are frozen in place. As a result, only 15% of your screen is usable, showing 4 out of the 30 columns you need to fill at a time and requiring constant scrolling.
As a user, I would have been happy to dump it and use anything else. But who am I going to complain to? I'm not the customer, my company was. And it's not like they are going to switch ERPs just because employees hate it (which we all did). Even if they wanted, the cost of switching now would probably be astronomical - not only on migration, but also on training and support.
It's no surprise that SAP is worth that much, seeing as they have the perfect captive audience: the wealthy kind.
I consulted for a company once that had made several attempts to migrate from their ERP (as well as having made several acquisitions and mergers over the decades). When I was there the state of things was 3 ERP systems that they had built, and another 2 that they had gained through mergers, all still operating and ERPing between each other. No matter how many enormous multi-year migration projects they started, they never managed to turn a single one of them off.
This is an interesting thread as despite working for many many years in IT I know next to nothing about SAP. I have worked with people from all parts of the IT ecosystem over the years but not SAP. It appears to be its own little closed world that some people enter but then never leave.
That observation aside does anyone know who writes or customises the SAP NetWeaver for Windows programs ? Is that the function of a highly paid consultant somewhere ? I have seen a few of these in different places and the common factor is they always look like they were written in Visual Basic circa 1992. The one I use makes the same beeping sound if a transaction fails as it does if it succeeds. If the transaction fails this is signalled by status box text saying so in a green font but if it succeeds then text says that in a red font. It takes a special mind to come up with that !
A best case scenario looks like Cisco’s ERP implementation, which took them 9 months and $15 million. In comparison, Dow Chemical’s implementation, for example, took $1 billion and 8 years;
At the last SAP site I worked at the general feeling was implementing SAP had left the company weak. This lead to them being taken over by one of their competitors.
Attunity (now Qlik) Replicate [1] has an SAP ABAP change data capture connector. Replicate directly from SAP to Kafka, AWS/Azure, HDFS, etc., in real-time. I am surprised that more SAP shops are not doing this to separate operational ERP concerns from agility in the rest of the business.
This is what SAP's HANA platform is for, a microbatched CDC framework to an in memory operational data store with a standard SQL engine for traditional reporting and analytics (in theory .... being SAP, it's also weirdly engineered on the backend)
I’m impressed with core HANA performance for reporting, but it comes with a very dear price tag. Multi-tier architecture concept, I’m not sure..?
Kafka can be useful for more than staging reporting data. This pattern is more about separation from core ERP (and core ERP bureaucracy) vs. ERP reporting.
What do you notice among the top three links? All of them are mostly talking from business-speak perspective. For a software engineer learning about SAP for the first time, all I want to know is what does SAP literally do? The top three links do not have screenshots of the software, do not simply explain the technical capabilities of SAP, and do not explain how SAP differs from competing products.
Although I never interact with SAP daily, I have always been curious about what it does, but did not want to waste a lot of time on Google searching for a real explanation. Hence, to have a section like "What ERP software actually looks like" in the parent link fulfills a certain desire to know SAP that I have had in the back of my mind.
To some extent, I can blame laziness on my part—in that I have not researched enough about SAP, but why should it be this hard for a software engineer to learn about another piece of software? This is why sometimes, it is better to have a neutral party (non-SAP affiliated) to explain a product, rather than SAP itself.
In the late 90s (say, 97-98), I was a partner in a custom software firm focused on helping companies use "Internet technologies" internally -- early intranets, delivering things via the browser, that sort of thing. It was novel at the time, and we could make money doing it! Wheee!
Anyway, we needed to integrate with SAP on occasion, partly because one of our biggest clients was in the middle of a HUGE SAP rollout, employing a small army of Arthur Andersen MBAs, etc.
So I went to the SAP technical education conference in Atlanta, to gather info and whatnot. I heard Hasso Platner brag from the stage in the keynote that complaints about SAP's complexity and expense were entirely overblown because "80% of our implementations now take less than 18 months, and come in under $100 million."
Y I K E S.
(Oh, and the company with the SAP rollout we were working with? Eventually, the combined cancer of SAP and AA billing destabilized them enough that agreed to be acquired by their biggest competitor. Yay SAP!)
All in all an interesting article, although some PR piece alarm bells just went off.
I would have loved to have additional information that might not have been provided due to the fact that Retool is a very early stage competitor in the ERP space.
With all the SAP bashing that is happening, there must be some advantages that the SAP software suite has, right? I would love to hear about them.
The rigid nature of the SAP software - and the crazy costs that come with it's customization - is a known problem. I still wonder if this is the real reason why the migrations and implementation projects with big customers fail, or if these are, generally speaking, just really big projects that carry a huge risk. The truth is probably somewhere between both extremes.
What long term structural disadvantage do you see in applying the Retool software model?
Congratulations for getting your product out of the door!
I used to work in a research project where I went to some UX conferences in Germany (not really my field). The big irony/running gag is that SAP seems pretty good in UX-research, Hasso Plattner Institute is fairly recognized for their UX work and yet SAP-UX is a nightmare.
The HPI is a faculty of the public University of Potsdam, it is not a research unit of SAP or anything similar. They have projects with Oracle just as they do with SAP and a ton of other companies.
Also, HN is a hacker crowd with a particular axe to grind re: UI, since all the cool new UI shit makes insta-billionaires, or at least thats the dream.
Whereas with a SAP-using business, the computer isn't the product - the products that the computer allows the company to manufacture/distribute are the only thing that matters - and the SAP UI is intentionally set up by bean-counters.
Once you go SAP, like get into the SAP Zone, you can be quite productive - but like another poster said, SAP is like vim.
I live and work in USA but spend time in Europe. I noticed that in Europe SAP is wildly popular and a large percentage of “software engineers” are “SAP/ABAP programmers”. I have some engineer friends in Eastern Europe and they’re taking about how their employers are in the process of, or considering moving to SAP and away from in-house programming. These are not massive enterprises, mind you. Just small to mid size companies. In the US, on the other hand, I’ve never met a SAP engineer and in-house systems are the norm. What’s the deal with this disparity?
Having worked for many multinationals, I've also noticed such a difference. If it's a US company it would often have a group of in house developed systems that are integrated with each other to some degree, and a team that maintains it, that would manage various things like inventory and lifecycle of systems and products and even sales and customer service. European companies, including those in the UK, would often shy away from such efforts and lean more heavily on enterprise vendors and consultants to attempt to deliver this or try operate with nothing at all. I'm generalising, there are exceptions, but I got the impression that there is a certain kind of engineering culture in the US that is willing to take the risk on such in house projects and realise the value of managing it in house and they also have something that makes them able to execute it successfully.
In-house software development is very rare in the EU if the main business is not software. And every other company that has in-house software tries to migrate from their "legacy in-house solution" to a "industry-standard solution".
I have been working for YEARS on an ERP implementation in a custom manufacturing operation practically by myself.
As bad as I'm sure SAP is to deal with, I crave it or anything else (Salesforce?) that has any sort of easy customization, automation API and fosters some sort of community.
A large part of my particular ERP's business model seems to be to make the data model so esoteric that you are forced to go to them for any type of customization at all. Unfortunately, they make a habit of firing any of their halfway decent employees every time they get acquired (4 or 5 times so far).
I went to the town where SAP is located, once, for work. It's bizarre - it's this fairly average little German town. Next to it, it has an 'industrial area' about the same size as the town, and it's all about SAP:
SAP own Crystal Reports. It's buggy slow garbage, IMHO. Wildly popular for unknown reasons but I found that it threw internal C# exceptions all the time in its own DLLs and was slow and buggy. Awful.
Oddly others thought it was great and accepted it taking 30 seconds to load a report (yes, it's just a few database queries with the output put onto a canvas...) but I think that was because they didn't understand how basic it should be, and knew no alternative (of which there was none!).
I ended up writing my own report system as I detested this so much.
>>"But most importantly, SAP’s software was designed to be extensible from the start. For SAP’s original contract with ICI, SAP didn’t build software from scratch, as was the norm at the time, and instead built on top of a previous project. When SAP released their financial accounting software in 1974, their intention was to build additional software modules on top of it and sell them in the future. This extensibility was SAP’s defining feature. The interoperability across client contexts was considered radical at the time because other approaches started from scratch for every client."
SAP's success can be attributed to something similar to what Facebook and Google did, locking the data and knowledge base to itself. The much bragged "extensibility" is limited to SAP own software modules or will be acquired.
Therefore the extensibility is both the strength and the weakest point of SAP. Unlike most of modern software system, there isn't an open ecosystem for competition at its periphery, resulted in a lackluster UI and unfair challenges to non-SAP software to take advantage of those domain knowledge buried inside the SAP.
SAP's integration doctrine is originated from 1960-1970s. With limit evolution this doctrine has largely ignored the changes in computing for several decades, yet it's still growing its dominance.
Question for those in the know. Do the major Silicon Valley tech giants (i.e. Google, Apple, Amazon) use SAP or even ERP?
I say this as someone who has no experience whatsoever with ERP. But the entire concept seems like an anti-pattern. A kludge that's only necessary when your org lacks basic technical competence.
Why does everything need to be in a single monolithic system? Does HR really need to run on the same database and software as the manufacturing plant? Haven't we learned that small modular, independent systems with well-defined interfaces at the system boundary work. If for some reason manufacturing needs to talk to purchasing, why can't they just do so over JSON/HTTP endpoints or a Kafka message bus or even direct SQL connections? Trying to integrate by just locking everyone together into a single system that tries to be all things to all people sounds like a recipe for disaster.
But, again I don't really have any direct experience with ERP. So that's why I'm really curious what orgs that are actually technically competent do. If Google or Amazon or Netflix was using ERP, despite having the engineering firepower to build alternative systems, then I'd really think that there's something important to the concept that I'm missing.
Technology can bring benefits if, and only if, it diminishes a limitation. -Dr. Eliyahu M. Goldratt
Goldratt was critical of ERP systems, not because they couldn't bring benefit; rather, because many businesses adopted through a cargo cult mentality and viewed them as magical silver bullets. Many companies never understood where their bottlenecks were (Theory of Constraints) and would make things worse with an ERP system, with some going bankrupt.
One reason why SAP perhaps has remained relatively unscathed by competition, beyond the obvious upfront development and implementation cost barriers, is the sales angle.
An ERP is usually sold directly into the office of the CEO. Any ERP startup hoping to get a foothold must have a founder or head of sales with a rolodex full of CEOs. Folks with CEOs in their rolodexes tend to not have the type of risk-tolerance required to go all-in on a startup.
Going through the comments here I notice the recurrent theme that it's your company that has to adapt to SAP and not the other way around.
To me this raises two key questions:
1. Isn't this harmful/limiting for your enterprise in the long run?
2. How can you at some point migrate away from SAP once you adapted to it?
Given these issues and the huge costs, why would it make sense to adopt it in the first place? At least in the year 2020 (maybe the situation was different decades ago).
The closer you stick to "out the box" ERP the more chance you actually have of moving off of it in the future.
Any ERP consulting house worth their fee will know how to move customers from one standard ERP system to their own/another. The difficulties come when you heavily modify your ERP solution to fit your business rather then follow the advice given.
This is where the tender process and requirements will bog down, developers need to be hired or entire business processes need to be rediscovered and rewitten. Since an ERP move might only happen once every 10/15/20 years a lot of business will use the project as an opportunity to reshape business processes, removing a lot of legacy stuff which no longer makes sense.
In some of the repetitive data entry areas, like forms to enter purchase invoices, it used to have the most productive UI I have ever used. The cursor started in the right box, tabbed to the right places etc. I would swap that screen for my current modern one any day
This is the feedback I've got while working on a customisation project based on a different ERP (red one). Users actually expect your interface to behave in the exactly same way as their ERP does (TABs and keyboard shortcuts included).
I don’t know if we are using the latest versions but the UI has many other sins, not the least having buttons in odd places (submit is often at the top), many many screens to get to a place, slow as you say.
I don’t care so much that the UI looks from the 90s. For an internal application, a battleship grey winform is perfectly fine, as long as the workflow is simple, fast and intuitive.
The book Peopleware had a section about this subject.
In one study after another, workers failed
to give much weight to decor in choosing,
for instance, among variously colored panels
and fixtures.
But then:
If you ask specifically about noise, privacy
and table and counter space, though,
[...] matter a lot.
The whole thing about both office space and software is: design matters in the aspects where it gets work done. After that, nobody cares. Your working environment should help you, support you, and then get out of your way.
This corresponds with my personal experience: the win95-ish software design was my peak for daily productivity. Besides, you generally get a main window with grey widgets and colored icons at the sides, and a white working area full of colored items. So the end result isn`t all that boring.
Honestly when I work, I focus on the content. Bloomberg Terminals command based UI is a designer’s nightmare, but you get anywhere you want to go in a few keystrokes, and as far as I can tell, most other users love it too.
I have heard same argument for command line interface in yester years, why switch to Graphical User Interface, when CLI is so much more faster and I love it (and so do my other friends around me).
Attrition (so new employees), interns, fresh campus hires, I guess does not happen in that universe.
No it's not that bad, it has auto-complete, it has search functionalities for both commands and data, and there has been a help button to chat with a bloomberg support person for as long as I have been in this industry.
The Bloomberg terminal does two things which make it much more approachable for beginners than you suggest. Don't know which function you need to do something? Type in what you want (and possibly hit HELP if it doesn't autocomplete for you) and you'll find it 9 times out of 10. The 1 time out of 10 that doesn't work, you start a chat with support and they'll point you in the right direction pretty well immediately.
The one slightly annoying thing is that for a lot of things there are at least 5 different ways to do the same thing/5 different screens with very similar functionality, and everyone seems to use a different one.
But it's also worth saying it's a tool specifically aimed at specialists - it's not going to hold back on giving you a huge number of options over which data you want and how you want it presented, and it's not going to warn you that some data might be incomplete or not the one 'everyone' uses.
Agree with all of this. But the color scheme, screens that distort when resized, US date formats shown to European users, text based graphics, textual commands, etc, would make more than one graphic designer physically sick.
Too many designers, maybe a majority, make "beautiful" software that is a pain to use.
Are forms today better than they used to be? I don't think so. Most "web based" or "web inspired" apps today are slow, unintuitive, and have idiosyncratic behavior.
How often have you had a form that didn't work right because some Javascript request failed and/or it decided your entry wasn't correct? How often did tabbing through fields actually work as you expected?
While your statement is technically correct, it leads to software that just isn't a joy to use. We get used to having bad usability, and we take for granted that forms just don't work 100% and so we take the safe route - for example writing long text in an editor and copy-and-pasting to be sure. Have you never done this?
Having beautiful interfaces is nice, but it should be an afterthought and not a priority. Because it is difficult to optimize everything at the same time, and beauty is lexicographically unimportant compared to efficiency.
Beautiful visual design is not necessarily correlated with beautiful functional design (i.e. being a joy to use, or - as the parent post put it - simple, fast and intuitive). I think the latter is more important for a lot of software (especially software you use every day in your work) but often sacrificed for the former.
I love the SAP UI - yea, its the 90's when UI was far superior than today's whitespace filled, shadow-less buttons, complete lack of skeumorphic elements, magenta gradients and huge typography - See Windows 95 UI: https://twitter.com/tuomassalo/status/978717292023500805
It is dense, extremely clear and consice. I agree with the slowness though.
I feel like there continues to be a huge disconnect between UI designers and their users.
I'm a power user so I am not the best person to ask for UX advice, but I talk to people all the time that just wish they still had the classic Windows 9x UI's and things more or less were "boring".
Reminds me a little bit of a statement about how Taxi drivers can tell you what works architecturally better than an actual architect when it comes to ground floor interaction.
That's because contemporary designers are obsessed with trends, frameworks and aesthetics. When Dieter Rams designed Braun products, he didn't have a UI framework. He deeply thought about interaction and feedback to the user.
Contemporary UI trends bother me except one: websites like drewdevault.com and text.npr.com are refreshing.
That’s the problem with software. There are two categories of software: software that their developers use themselves, and software made for other people. Visual Studio is the prime example of a software made by people who use it, it continuously improves (minus a few hiccups), it is made for the most used functionalities to be at your fingertips, it doesn’t hide stuff in layers of submenus, etc. The list is long of software made for others, and the general rule is “fuck it, good enough”.
This is also why I believe the Windows 8/10 developers must be working on macs.
What language do you write in using Visual Studio?
I use it with C++ and C# and I can't say stress enough how amazing it is to use with C++, compared to the teeth-pulling experience of using xcode for the same tasks (some of which are impossible in xcode, edit-and-continue for example, set next statement).
It might be just me, I use Visual Studio to write C# (not my "first" language) plugins for an older (non C# core) tool.
Sometimes I also use Visual Studio to manage SSIS ETL packages, but I need an older VS version because they are not always backwards compatible - this leaves me with three versions installed on my computer - 2015,2017 and 2019 - each for something else.
To be honest what I don't like is the neverending march of tiled frames for everything - the whole program is one frame, then i have one frame for the code, one frame for the solution explorer, two more frames for error list and output, another one for properties and so on.
A lot of screen space is taken by just blank spaces or dividers.
Another thing that I didn't like was that the 'Comment selection' option is hidden in Edit -> Advanced -> Comment selection. You also have to use two keyboard shortcuts in succession to comment something (Ctrl+K, Ctrl+C) and the uncomment shortcut is different (Ctrl+K, Ctrl+U). All this while Ctrl + / does nothing and could do both at the same time.
I often need the whole VS solution and not just the code when I need to copy paste the project to a different folder or a different machine.
Have you tried moving the frames around a bit? I normally dump all the frames down the bottom particularly for debugging.
The double-keystroke thing is a bit odd yes, and the menu is hidden a bit far away for ease of navigation. Still, it could be worse - it could be a RIBBON!
From my own experience interacting with Microsoft developers, there are more using Macs (with Boot Camp dual boots) then you might expect.
But it's hardly a majority (or even that many at all). If you're developing primarily on the CLR or for one the the many Microsoft sub platforms, the first-party tooling is actually quite good. It's only when you need to do both, or stray from one a bit too much, that things become arduous.
Generally however, the Mac users are almost always essentially Microsoft developers who have to target both Windows and Linux and don't want to deal with managing/maintaining a Linux daily driver. MacOS is "close enough". It's pretty representative of the non-Microsoft developers in similar situations.
And no: the Linux Subsystem isn't enough for them either.
SAP suffers from the same issue as all other universally-malleable systems: at best, they're only as good as the designer allows them to be.
However, just because it resembles 90's UI (which I'm a massive fan of) doesn't mean it follows it philosophically. It regularly breaks its own rules and is deliberately designed to be obscure as possible.
I wasn’t talking about mere resemblance. I’m talking about functionality, density of information, layout, hierarchy of importance exemplified by various aspects of the UI, clarity and intent, feedback and signaling, on and on. The whole thing. The only thing that bothered me about SAP was how clunky it felt, simply because it was slow.
I’ll quote myself: “It is dense, extremely clear and consice.”, yep it’s great to use. I also love JMP statistical software UI and Cinema4D UI. They’re a pleasure to use.
The UI /elements/ of the 90s were fine. That doesn't mean that anyone will necessarily build a good UI using them.
SAP and software designed to offer high levels of customization in general leave the task of building a complete UI to middle managers familiar with business processes. They do not generally have any understanding of UI design and are quite happy to add a 50x50px, non-resizable text box for content that will often span multiple paragraphs.
I don't know any decent CS/software engineering student that would want to work on SAP. As a result, all the SAP consultancies I know are filled with business graduates that happened to know a bit about software. I wonder how much that contributes to the SAP clusterfuck.
I do, especially at SAP itself there was and is lots of interesting work hidden under all the crud. For the rest, relative wages and job security seem to be the driving factors for young graduates to join the space these days. The day to day there isn't really worse or more or less boring than any other B2B integration gig. Consultancies and working at the larger ones also suck for their very own reasons. That'd be the case with SAP or without. They hire business type people because the technical challenge of these projects is minimal compared to other aspects. Sure, most of these projects could often use a bit more of technical seniority, expertise, and overall strategy. But I think it's too easy to attribute failures solely to that, it's a mixture of problems, just like any large scale failure in the space.
I can't say anything about the consulting companies, but the developers in Walldorf that I got to know were all competent.
I can only talk about my experiences and there are many in my social circle (computer science students at KIT) who are capable developers and either work for SAP as working students or would like to join SAP in the course of their professional life.
As a first job, SAP is actually not that popular. But that's due to the fact that many don't want to join Big Corporate directly, but want to work at startups first.
In the last couple years I've been more and more interested in this world of "big enterprise software that seems to be a complex mess but has seemingly unstoppable momentum and makes billions". That whole world seems to be hidden to many of us developers who often see a few lines of code we don't like and assume a whole product will die because of it. Meanwhile there are these giants out there dragging along this weight that companies still spend billions to implement. I see some of this in my day to day but it's not often I find an article that frames it the way this one did. Good stuff!
This whole thread has made me feel like my life writing clean Java and Postgres has been charmed and the future is working on behemoths that are too big to fail.
What the HN crowd might find interesting is that SAP does not support any kind of containerization technology to run their products in, despite the fact that certain components, like the dialog instance or saprouter, are prime candidates for just that. Let's give them a few more decades, they'll get it.
(From randomly perusing their help portal, it seems that there are one or two modern - and quite exotic - software products from SAP that do support Docker and I think also LXC, so it looks like they're slowly moving ahead in this regard. :) )
There are pockets in various parts of the company that are on more modern stacks (building on K8s/part of CNCF), but the old stuff is still the bread + butter, and the first thing anyone thinks of when they hear SAP.
> ...and most engineers probably haven’t seen them in the wild.
This is quite a limited view of our industry. I'd agree that young coders focused on the startup community may not have seen it. But it is pervasive in the enterprise world. By all means, pick it apart, analyze its strengths and weaknesses, and compete/disrupt. But pretending it is some unknown thing shows a lack of understanding of a significant market segment.
I worked as a PeopleSoft developer in college. It's a competitor to SAP. Working with esoteric software taught me how to properly read documents with hundreds of pages. It also showed me how to get by in a less than ideal circumstances.
I am a bit of a maverick in that sort of environment, though. I wrote a JSON encoder [1] to ship PeopleCode objects to the browser via these webscript endpoints you could make in order to use modern web technologies. PeopleSoft actually moved in that exact same direction years later with better JSON support, 'FluidUI', and better html5/javascript support.
ERP systems are hell to work with. It was fun, but ultimately I was glad to get back to the real world. I got back to my main interest C#, but then went fully into the Clojure world :).
ABAP developer ... after looking at some of the code it is amazing that it actually works.
I recently did something called a BDC since the API call did not work so you resort to stuffing values into some internal tables and replaying keystrokes to enter the data into the system.
Well, SAP has for long been a money making blackbox for consulting firms. Think IBM, Accenture and the likes. They rake boatloads of money for multi-year contracts to implement SAP systems for companies wanting ERP solutions.
The system is outdated and obscure with both technical and non-technical people having a tough time understanding it. Last time I worked with some interfacing systems to some SAP modules, it still relied on web services, XML and SOAP. No REST support.
Salesforce is on the same road. In a few years, they will spin up more modules apart from CRM, like manufacturing and payroll.
I've been working on exporting SAP data to a new data lake and it's a tortuous process, though amazing when you finally get the data out and can finally do something with it. SAP works within its own sandbox but woe unto you if you want to integrate data from Google Analytics or third party APIs to do forecasting or more sophisticated business models. The RFC libraries for pulling report data out of SAP are . . . finicky . . . and I spend too much time manually formatting output tables which look like something pretty-printed in J.
At it’s core SAP as it is used in most companies nowadays is mostly just a database of clients, vendors, invoices, purchase orders, and inventory, with a UI for CRUD operations.
Business decisions are usually made on exports in third party tools (Excel, Tableau...). Why is not disrupted yet then? For me it’s the same as Oracle for database engines and IBM mainframes: enterprise sales process and trust in proved decades solutions when you you bet your whole business in a software or hardware solution.
Maybe ERPs are the ultimate test of an agile culture. Sounds weird right? But bear with me.
Most ERP projects fail. They end up over-budget and delivered really late.
Why? They are sold like custom implementations, promising the stakeholders they’ll be adapted to their specific needs. It's rarely the case. The reality requires the whole business to change: its processes, its workflows, its traditions.
Therefore, only companies flexible enough can survive such deep transformations. Companies that are agile.
That judgment is based on the premise that the processes mandated by the ERP software are more effective than the company's current processes.
If a company terminates its adoption of an ERP solution, it does not necessarily mean that the company is not "agile" enough. The company's leadership may simply be concluding that changing its processes to the ones mandated by the ERP would make the company run less efficiently, a consideration that could outweigh the benefits of using a centralized piece of software to manage its operations.
Would someone kindly differentiate between the ERP vs ITSM (IT Service Management) industry in perspective for me? I would in ITSM and often wonder if I would had been better off staying in ERP like SAP?
Secondly, how does ERP fare in terms of complexity between game development vs ERP Software development? I understand the target base is totally different (Gamers vs Enterprise clients)
SAP has a separate product for ITSM: Solution Manager. Everything else is beyond that scope.
What is important to understand is that SAP is standardized way to do business for ALL departments in big corporation. You probably can't be "expert is SAP". You can be expert in SAP treasury system, SAP data warehouse, SAP ITSM, SAP data analysis, SAP call center etc.
I heard that SAP consultants are paid very well and I think it will stay that way. But I guess this thread sums it up perfectly: it is due to the complexity that these implementations bring to organisation and lack of elegant solutions from modern software development world. So in terms of money it is good, but the trade offs are quite big.
A colleague just switched from a game development company to our gig, which is selling Field Service Management Software which integrates with SAP.
So we talked a bit about the differences and I hope this answers your second question.
1. Constant Updates/Upgrades
Most games are a one time effort with some patches and maybe a add on and if it’s really successful a sequel.
Business Software runs for years in a company and needs to be supported. So the customer needs to sign a service contract besides the initial payment and licenses. Games are usually a one time buy. Exceptions are MMOs. Game companies noticed this mishap and are trending to service games now, which would create a steady inflow of money from loyal customers.
2. Complexity
It depends on what the game company focuses on. If you only build games, you need to master a game engine or build your own. It doesn’t need to be customizable if it stays in your company.
With ERP software you need a lot of configuration switches and cover a lot of similar but not same use cases. A standard product is almost never bought my businesses. They want you to build something for THEIR process.
So what SAP did is maximize on this need and they built so many customizations, that you need special training to even begin to understand one of their modules.
ERP is definitely more complex in the realm of more stuff to learn and to remember to get it right.
In terms of complexity defined as difficult I can’t really tell because of my lack of experience with game development. But I guess mastering a game engine is difficult, but less “complex” than ERP software.
Funny side note: I did a SAP training one and half years ago at their HQ in Walldorf, Germany. And they own pretty much the small town. There were so many foreigners in town to visit SAP. The SAP campus had the same size as the town :)
On your second question - as an enterprise software developer and hobbyist game developer of ~8 years, I'd say they're complex in different ways...
ERP software is mostly a giant CRUD app/database, with APIs, reporting functionality, and a ton of relatively simple code for automating the system/business processes attached to it. These parts taken alone are usually fairly simple, however the complexity really stems from the enormous scale, interfacing elements, moving requirements, and mutability of everything. It’s easy to knock SAP, but it’s difficult to keep software nice when you're dealing with these attributes.
As for game development, I tend to find it more computationally complex, but that can depend on the game and tools you use. By computationally complex, I mean the code itself is generally more complicated. However, what’s easier in game development is the amount of control over things you have. In comparison, you largely dictate how much mutability your game will end up dealing with, the data it will use, and how large the game will be. Players aren’t going to be dictating this. Not to say game development is easy, but it’s easy to make slick software when you have complete control over the nature of things.
So in short, ERP software is complex (and crappy) mostly due to the enormous scale and the complicated nature surrounding the software - whereas games are complex in regards to the nature of software itself.
Regarding the second question, it is not comparable at all. ERPs are still "standard" software, despite what the article implies. The difficulty is not so much on the software side, but on getting the software actually agree with the business processes and often the fault is less the software, more a convoluted business process which is simply not truly automatable. Then you run against the whole organizational inertia while implementing.
I can only speak from a bit of SAP experience:
So usually, implementing an ERP, at least SAP, first means "customizing" it, that means adapting the thousands of configuration parameters to the organization. This is no programming task, in fact you "just" operate a GUI. The difficulty is more in finding the proper the option.
True development tasks are often very restricted in scope - most often it is just the development of a new report or custom data export (one of the annoying things of SAP ECC always was, that it really really really loves to keep its data to itself. While theoretically everything is open - you can even browse the underlying the database directly from the UI, with appropriate rights, and can also quite comfortable run even DDL statements against it - often you are back to ABAP very soon for any kind of interfacing tasks simply because SAP likes to live in its own world with its own standards for data import/export (Idocs for example or its proprietary RFC interface). Things might have gotten better recently with e.g. the OData support, but I haven't yet worked with a system which had that.
Wow, its a little bit crazy how much SAP actually does, but it does seem like it's been around so long and has embedded itself into so much that people just take it for granted that their stuck with it.
I would love to see some case studies of replacing SAP with even an in-house product.
Infact in certain cases I would imagine that an in-house solution with maintenance etc would be more cost efficient.
After Amazon clearly stated they are off Oracle Larry Ellison has been touting that SAP lunch is up for the grab and all SAP customers are moving to a legit Larry setup. Sap denies any migration taking place.
When Larry starts to mention a market it is a signal is innovation can be expected from his competitors. AWS Aurora, Google Cloud Spanner that are competing with Oracle legacy solutions.
Having worked in the ERP space for close to 15 years, I have seen no other software even come close to the features of SAP & Oracle. A lot of next gen software even lacked basic features like revenue splitting or multi-currency or multi-org that are pivotal to any company that has any more than 500M in revenue.
In Germany there is a saying that translates to something like: "SAP sucks the blood out of the Mittelstand" - Mittelstand being the SMB up to 50M revenue p.a. There has to be yet a moment, where I hear someone emphatically speaking about the mess that SAP is.
SAP is a company (and software system) that exists to buy up other company's software, business, and services and then integrate that all into SAP's "core" systems, and do so in such a poor manner that their name and the system has almost become synonymous with the words and phrases "nasty", "unreliable", "run away now", "if you know what's good for ya" and a host of others.
However, due to their entrenchment in various other markets (and who knows if there is any graft or other under-the-table business going on), they continue to manage to exist, and scary enough sell their products to new victims (ahem - customers).
SAP is the old-is-new-again-we're-IBM type of business; nobody ever got fired for buying SAP (but the golden parachute was nice)?
Ok - hyperbole and I don't really know what I'm talking about, so the above should probably be ignored...
...that said - I don't think I'm too far off, either.
SAP is a test suite to determine the resilience of a company against the highest form of software bullshittery. If a company actually survives a SAP rollout, it's pretty solidly positioned. The downside is, those tests cost a shitload of budget.
Does anyone else think that over a period of years products like SAP provide diminishing returns for the efforts and money put in, over software built from scratch in house ?
Yes, software built form scratch can also be messy, but which is the lesser evil?
I love this. I am obsessed with back office admin systems (software that helps an org run and their various workflows). Quit my job last month to take a stab at it. Working on boomadmin.com. (Still working on landing page and an MVP)
> A basic installation of SAP has 20,000 database tables, 3,000 of which are configuration tables. In those tables, there are ~8,000 configuration decisions you need before even getting started.
We had this at a telecom I worked at in the early 2000s. It's easy to sit back and bitch about "the things you have to use at work", so I usually avoid it. However, short of whatever-the-heck-is-used-for time tracking/time sheets[0], this application was the single largest software cause of rage at the company that I've ever been exposed to in my entire working life.
My experience with the application was limited mostly to expense report submissions and for that simple task, it was abysmal. It was so bad that it was hard not to conclude that it was chosen due to its horribleness: making employees think twice about sending in expense reports. And we did. If it was a small dollar amount, the time cost exceeded the monetary cost.
The UI, at the time (2005...ish), actually looked pretty slick compared to most web-based tools. It stopped there. Date fields, upon clicking, reloaded the whole page (which you waited for), to display a pop-up calendar, which when the date was clicked, reloaded the whole page. At least once while filling in the expense reports myriad of screens, the page would fail to load and you'd have to hit the refresh button, or you'd make a mistake and need to go back. Clicking any of the usual buttons in the browser for those functions invariably lead to an account DoS feature.
I don't remember the details, but it basically caused the system to get confused into thinking there were two of you and it gave priority to the "you" living in the alternate universe where you didn't click "Back" or "Refresh" and were still filling out your expense report. You had to wait for the first session to time out before you could continue, and the error message you received was placed in the "status bar" and appeared to be the name of a const variable "APP_BOWEL_MVMT_ERR" that gave no hint as to what the fsck was wrong. There was admin "unlock" feature (help desk calls were met with "just sit tight"). So you would give up and forget to return 3 hours later. A few days of this and the expense deadline passed.
There wasn't a more hated "enterprise tool" in our shop and we ran every single one of Microsoft's early attempts at web-ifying the world (early Sharepoint is the only I recall, but we had others).
It was decided to shelve it after a last-ditch effort was made to fix it. We'd put a job opening up to get a solid SAP developer and got ... someone ... after bumping the salary up several times. The rumor is that the gentleman we hired was the highest paid developer at the company. He lasted 3 months before taking a job at IBM at a substantially higher salary. A look at his job history and the circumstances surrounding it made it not unreasonable to conclude that we weren't the job he was ever interested in and talking to other SAP folks ... this sounded extremely common. The joke was "if you have to work with that crap, it better pay well".
We finally ditched it when we were acquired by another telecom; while most of the choices "our side"'s IT made were fought for, nobody advocated for keeping SAP ... even having no idea of what the acquiring company was using -- we knew if it wasn't SAP, it had to be better. It was Oracle; and it might be the only time I've heard a colleague speak positively about "Oracle" outside of The Matrix[1].
[0] Time sheet software always comes to mind. Nobody likes doing "time sheets" at any job I've ever had, but at every company I've ever worked for, we've had a home-grown time tracking tool. 30,000 employees to 100 employees. Every. Single. Company. It's such a necessary "evil" that even at those places where executives had known deadly-allergic reactions to building anything in-house, somehow a case was able to be made to build a completely custom time tracking tool tailored precisely to the businesses perceived needs. Death, taxes and time sheets, I guess.
[1] My experience with Oracle up to that point was Sun's acquisition and a perception-backed-by-coincidence that when the Oracle sales guys couldn't land a deal, their software auditors would step in to give the necessary motivation.
I recently worked on SAP as a PM, having never worked on it before. In some ways it reminds me of Lotus Notes, in that all data and "code" is stored in the underlying database.
After reading all these comments, I think the market opportunity is building lightweight SaaSy UIs on top of SAP to make it easier to work with. Someone write me a check
The author spends a whole section on "The importance of integration", the value being sold as "...the two [SAP] modules were able to seamlessly interact with each other since they shared the same database." and "because these [other] systems don’t interact, they needed to be synced regularly, and that often meant having a human manually move data around." ... "Integrated software solves this by facilitating communication".
In the very last paragraph of the article they then say "...on the back-end, most modern enterprise software (e.g. Salesforce, Jira, etc.) now have good APIs for exporting data. ETL + data lakes are on the rise...".
This is a mistake I see made a lot; not because of naivete tho': usually because the concerns cut across each other so much.
The economic and efficiency incentives around integration are very delicate. SAP is so complex that (assuming you can hire great engineers, which isn't necessarily a given outside the tech sector) you can probably build most of what you need with a small team that's much cheaper than SAP. However, you can't successfully (even with good access to great tech sector talent) grow that software as quickly or as broadly as what you'd get from SAP. You also carry a lot more risk. ...and that's risk outside of the core focus of your business. The article even includes one quote, "competitive advantage in this industry might just come from doing the best and cheapest job at implementing SAP." which recognises this as an operational rather than capital problem.
...but even if you can accomplish it, it's the integration that gives you the value. You're always going to have higher operational costs for your thing if you build it out of something like Salesforce and Jira sewn together with APIs. ETL is hard to do well for anything other than reporting (and even then it's not easy).
Data lakes are the epitome of loosely integrated data structures. Most of the time they're a collection of files full of data in weakly-or-stringly typed formats such as CSV, JSON and XML. Getting at the domain models of the producing software is always a pain. For all these things, your talent pool for effective support is small and gets smaller as you add more products to the mix.
So the three options are:
1) Buy (+ professional services)
2) Build
3) Integrate (e.g. "Salesforce + Jira")
3 (Integrate) is the mistake because it's less than the sum of it's parts. You carry all the risk of "Build" and don't get the brand stability and integration of "Buy". Multiple vendors gives you more risk than a single one in this scenario because you're buying different things from different vendors. So now you have more chances for failure: failure or withdrawal of one of the vendors, API changes that you don't control, etc, etc.
As the SaaS markets become more mature I'd hope to see consortiums of vendors who had products that they would certify as working together. I don't think we're quite there yet tho'.
2 (Build) is the Big Bet because you're taking a capital expenditure approach to an operational problem. You're investing in intellectual property outside of your core business. ...and you own all the risk.
1 (Buy) is difficult because it is expensive and loads of things you want are still only sold on a professional services basis, rather than as a product. It's also a market designed for the large companies with between 6 and 9 figures to spend. It's also one of those infrastructure projects that is usually shaped as something that doesn't deliver any value until it has been rolled out everywhere. However, this is the option where you hold the least technical risk and most of the risk you do hold is related to abilities that are hopefully aligned with your existing skills of management and operational delivery.
Having brought up an ERP solution with a team, this is no joke. A company with payroll, inventory, contracts, and logistics (to name a few), needs an ENORMOUS infrastructure of software to keep things running. There's a reason ERP is so expensive. In fact, I'm surprised it is only a US$41B industry. I would expect 10x that.
SAP is the one of the few software companies who manages to consistently produce the worst possible user experience. They actually made it into an art form. There is nothing about an SAP product that is usable. Its a big steaming pile of shit. I don't even want to know how the code looks like.
A bit unfair. In fact most of the SAP books unfortunately are a waste of money because 99% of the content just repeats the help on their webpage.
If there is something I would complain about, it is that their help pages are a convoluted mess of years of content with broken links galore, lots of duplicated content between help pages between different versions and an on site search which is just not very good.
So basically you have to Google stuff, then unfortunately come out on the help pages for an edition you do not actually have and then will have trouble finding the corresponding help page for the thing you actually run.
Until you know the internals of SAP ;). They have/had an own programming language (ABAP) which is the worst combination of BASIC and SQL you could imagine. Do not know the status in 2020, 2007 it was still a combination of ABAP and Java.
Interestingly, the source code of SAP is openly readable (once you have their software installed).
SAP is effectively open source, IIRC there were/still are options to install local development stacks for free... but without an army of experienced consultants it's gonna be useless for you and they won't touch a pirated/cloned system with a 10 feet pole.
If you're a big enough organisation to need an ERP like SAP, it would cost more to manage your data with spreadsheets than it would cost to just license SAP.
I mean, that's literally how you price enterprise software.
Interesting. Was thinking that some startup could exactly do this, but realized that given how deeply integrated SAP/Oracle is (as mentioned in the article) it's very hard to do.
Basically: Make a really bad product + make it mission critical = a product that people are literally glued to using
Ridiculous to even suggest that the stock management, ordering, billing and delivery tracking for companies like Adidas and their partners worldwide could run on some Excel spreadsheets. Shows stunning disconnect from how much heavy lifting enterprise software like SAP does.
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.