It’s a really broken system that no one seems interested in fixing.

Authored by Joseph W Kernodle of CLEMSON APPAREL RESEARCH.

Later I meet a former procurement officer who was reprimanded for excess purchases in the year leading up to the system launch. In the end his team was the only one able to provide equipment for an extended period of time after the new system was introduced. Everyone else had relied in JIT supply chains, but this guy didn't believe that the new system would work and spend a year building up inventory.

In this case, it sounds like they should’ve bolted the JIT platform onto SAP

I developed a custom engine for things like aluminium rails, and thermal sensors, to generate a new product with the production tree in SAP, so it would be able to decrease the right ammount of raw materials from the warehouse.

It can work for a long time, but eventually it does create opportunities for competitors.

You're absolutely right that there's a floor for how simple these products can be, but most of the incumbents aren't anywhere close to that.

However, I do believe a (slightly) better competitor could be created, with better technology, better workflow, etc. If well-capitalized. If it had well-factored plugins. If you had a top-notch team to design all that and then build it.

That's a lot of ifs. Joel says it isn't guaranteed a brand new team will even do better than the old on the essential angle. It's risky and costly enough to prevent it from happening.

But the most likely scenario, I think, is that built-for-purpose competitors will build products that peel away small pockets of SAP's customer base over time.

The irony of course is that a product like SAP is the end result of similar built-for-purpose products being hoovered up and merged together in the first place.

Everything is a pendulum!

[1] https://www.cbinsights.com/research/craigslist-unbundling/

Switching costs and risk are the major reasons these systems stay around forever. If you've got something that works. Even if it's sub-optimal, you're never going to move away from it. I worked at a place that used an ERP from a company that went out of business, so they would install DOS emulators for a really ancient version of DOS on every computer for people who needed access to the ERP. This was seen as a better solution than the perceived risk of switching ERPs. This was 10+ years ago, but to my knowledge they're still doing this.

Apparently Stanford had its own homebrew system, and some dean had decreed that they had to move to Oracle Financials. For literally years, these poor people struggled with it.

I never worked with that or SAP so I can't compare them, but I think both are the Full Employment Act for consultants.

Now what does this say, about LIDL, a discounter who dumped 500 m with SAP?

https://www.computerweekly.com/news/252446965/Lidl-dumps-500...

Basically, if your buisness process match that of SAP, everything is fine, if not, good riddance. Or in the words of a former SAP manager about Lidl: “They don’t have the right level of business engagement”

Meaning they did not adapt to SAP enough.

For every "We had a great internal platform that we custom built" story, there are multiple "We used a small vendor's product, and it was a nightmare."

Why is SAP successful? Because the general purpose tools (or worse, amalgamations of multiple single-purpose tools) that came before were absolute shit, and SAP is instead only difficult to use.

Progress!

(Also, a TAM that is literally every company, ever)

Customers are growing increasingly frustrated, the company has dipped its toe into political agendas and they regularly get lit up on Twitter as a result, and Bloomberg has targeted them due to questionable moral practices (most recently, silencing rape victims).

SAP is more concerned with protecting their reputation than actually developing quality software. Sooner or later that is going to catch up with them. They are constantly playing damage control. It's only a matter of time before more and more comes out (and there is plenty to come out).

What it turns into is another story though :-).

Upgrade windows aside, it's ok. I imagine that the sweet-spot for Netsuite are businesses that do 5MM to 100MM ARR. Possibly less if there's a heavy need for EDI, volumetric shipping, etc.

SAP will fall from a thousand cuts of the facade pattern.

Yes, it does it correctly for tax purposes everywhere and can be used in a way which conforms with how these companies want to do their accountings for shareholders reporting. Also it used by so many companies that every niche thing you want to do has probably already been done.

The people here complaining about the UX for reporting their hours just have no idea of the mind boggling complexity of the problem space. There is a reason everyone use SAP and it’s not because it’s bad.

That depends. I’ve seen a lot of adaptation to processes that are legitimately & measurably better in time & accuracy ignored in favor of costly customizations out of nothing more than “not created here” syndrome. If a customer doesn’t like that then an off the shelf product is the worst choice they can make unless they are prepared to hire a significant in house dev team.

Otherwise, if you have been adapting your current business processes to deal with the limitations of a legacy system first deployed in the early 80's then there's an excellent chance that at least some of those things can be done more easily in a more modern system. (Though SAP may not always be the best place for that to actually be the case).

Every. Single. Customization. You make, which makes so much sense to seemingly eagerly satisfy the user during implementation, will be a massive pain, forever, with every patch and upgrade and new functionality released by vendor in perpetuity, and will inevitably cause performance and failure issues eventually. And will only be getting more expensive and painful to maintain exponentially over many years.

Yes, you should customize erp for your very specific edge cases that you a absolutely need. But:

A) number of processes Bob from accounting or Fatima from HR believe are absolutely crucial and immutable and special and unicorn and mandatory, is way way higher than processes which actually are special and must be preserved. Personal inertia is huge. More often than not, special ways of doing things which are not your core business are an unnecessary cost, whether through erp or not.

This may seem like I'm a traditional grognard IT head who disregards users and their needs, but it's quite the opposite so let me clarify with

B) The threshold of customization at which erp no longer makes sense is in fact very very low.

If you actually, really properly are a special snowflake of a company and your convoluted hr or finance or pay processes are your key immutable competitive advantage, then don't get an erp. Other name for erp is cots, commercial off the shelf, which strongly hints as to how its meant to be used. With erp, customizations should be fought tooth and nail on every level,and that's a largely accepted industry wisdom.

> I don't work with SAP ..

Yeah.. that's just it. Your experience doesn't matter. Adjusting your business to fit SAP nearly as much as an unspoken requirement. It's not just a smart bit of wisdom people throw around. It's literally what you have to do if you want to have any hope of implementing SAP successfully, because it is such a colossal, messy charlie-foxtrot that there is no hope otherwise. Not even SAP's own people understand their own mess.

Adapting Dynamics ERP to business process is a challenge of its own, and not every company can do it. At least it's possible in Dynamics, SAP is a mess - most customers I know with SAP have to use external software and import/export for significant customization.

But then, did you really gain anything by using an ERP instead of just a dumb database, which would have worked just as well as backed for those applications?

Is this facetious, or unintentionally so? Do you mean you need to replace one in-house staff with between 3 and 5 and presumably very expensive consultants?

The most obvious failure modes are going for the lowest bidders incentivizing them to deliver with a skeleton crew, trying to nickel and dime the budget cutting features or their scope or straight up coming at the table with no documentation of how orgs own internal processes actually work.

I know of no project failing because of sap or their consultant on its own without any of the above comorbidities.

In my experience, what demotivate them is that a lot of the features in the marketing materials for these types of products are lies and they are filled with bugs. The executive who chose the product typically don't use it so they think it's a great tool. When you report major problems or workflows that makes no sense, they brush it off like it's just small details that need to be ironed out in the future because aren't the ones dealing directly with them on a daily basis.

The exec get sold on an AI feature and it's the intern who is then forced to deal with a search bar that take 2 minutes instead of 0.5s to search and gives you vastly inferior results.

By the way, edge cases, if if they work in a legacy system, are a thing to get rid of during a SAP / ERP implementation. Most people see ERP systems as IT projects and fail. ERP projects are at least as much business reengineering projects as they are IT projects.

Anyone who's ever worked with ERP software knows the entire system pushes you to do the reverse - adapt the business to the ERP. Going against that flow is possible, but expensive. This is especially the case with SAP which was always even more difficult and expensive to customize.

Unfortunately I don't think this is realistic scenario because when you start a company you probably don't have time/money or need for SAP or anything like that.

Here are things upper management doesn't consider:

* Picking the same ERP solution everyone else in your industry uses means you have zero competitive advantage now. Homegrown solutions with teams staffed to run them could give you an advantage.

* You need to pay expensive consultants to do things with ERP. If you want any customizations they will be a bottleneck for all future updates, possibly having to bring in expensive consultants every time you need to upgrade.

* The culture shift for employees is usually negative across the board. The IT people supporting it, the end users inside the company, basically the choice implies that management doesn't value its people or their thoughts on how to do their work.

* Vendor lock in. Switching from one ERP to another isn't likely to happen. They can raise their licensing/cloud costs when contracts are up and your company is likely stuck.

It would be like interacting with other people who knew based on the average of everyone on Earth as opposed to dealing with the person you knew based on their own personality.

But it's easy to manage based on these kinds of broad generalities and, as the saying at least once went, no one gets fired for choosing IBM.

"Successfully lead SAP implementation bla bla bla saving bla bla bla streamlining bla bla bla"

The pointy-haired bosses of our nightmares are real.

The complexity of the task is eventually discovered in production.

The short answer is that a sales guy in a nice suit took some execs out for steaks and more than a couple cocktails.

The long answer is that management, these days, is trained to outsource everything while still being clueless about what the people they're replacing actually do.

If the software needs to change due to industry changes or regulations or something like that, it will probably be a lot more expensive to implement it yourself compared to using an off-the-shelf tool developed by a company who's sole purpose it is to respond to those kind of changes.

It’s infuriating as anybody below senior management can see right through it

A system completely broken forever is something only the upper management can create.

Often times it's very difficult to correctly specify a system. This is one of the problems with lock files and why some people have gone over to docker for development.

IMO, the people to blame are management, who needed to appropriately staff the transition for enough time to get it right.

> Should they have stayed with their (admittedly not good enough) internally developed system?

What evidence is there that it wasn't good enough? Sometimes management gets sold on a "better" system, only to find out that it isn't actually better.

Also you can re-write everything in Rust https://blogs.sap.com/2020/07/23/learning-rust-with-cap-part...

Already happening: https://apphaus.sap.com/location/heidelberg

on't forget rewriting all the scripts in Zig of course.

a) Engineering: Nobody will rewrite 20 year old views just to improve the UX. In many cases, nobody even dares to touch the 20 years old spaghetti code.

b) Sales: The buyer is not the user. The buyer (playing golf with a sales rep) doesn't give a damn about the actual productivity of what he is buying.

c) Management: There is a solid economical rationale in not giving a fcuk about UX. Over the years, SAP outcompeted and absorbed many competitors that were more interested in UX than golf. Golf won every single time. Nobody at the top understands or cares about UX because it does not bring more revenue, it is a cost.

Source: I am an ex SAP.

Two main reasons:

- It's actually terminal software, that's translated into a GUI from a text interface on the fly.

- The people that buy SAP never have to use SAP. Its interface is not a selling point.

I jest. But that's kind of the point. SAP is terrible by the nature of the beast. It's a closed off system with specialised developers who require all sorts of expensive certifications. That doesn't make for good developers, that makes for pigeon-holed developers who don't have a lot of competition.

A terrible SAP developer with all the certifications to their name would probably still find plenty of work, because the expectations are low to begin with, as proven by SAP being held in low regard across the industry.

To me, needing expensive certifications to prove your worth (as if...) is a big red flag. I'm a developer who has 20+ years of experience, I recently worked for Apple and other Fortune top 50 companies, I went from startups to enormous companies.

Nowhere did I need certifications. And my past experience was never enough to land a job. I'd have to prove myself in every job application. That's tiresome and feels extremely unnecessary, but it requires me (and my peers) to stay sharp.

Of course, none of the above is very black and white. There are certified developers who are amazing, and there are open-source developers who keep themselves relevant who actually suck at what they do.

But I'd argue that the SAP group of developers have far more developers who aren't very good and grow complacent, oftentimes because of their certifications. That, combined with a closed-off system, bad documentation, a lack of online support, and a much smaller community, will MORE often lead to software that is of lower quality.

Anyway SAP/ERPs aren't code for running your business. They're code for running code to run your business. Now you have all the shortcuts SAP made to get stuff out the door, and on top of that you've got all the layers of shortcuts your business has made to get things out the door too. Therefore lots of nasty difficult complexity.

And finally I've seen evidence that in SAP people treat it like the fundamental abstraction layer is the spreadsheet[1]. So like in unix everything is a file, in SAP everything is a spreadsheet. This is a nasty complicated fundamental abstraction without the natural elegance of Unix's one.

[1] Maybe it really is, maybe it isn't but that's how a large chunk of the ABAP code I've seen treats it.

It definitively is neither pretty, discoverable nor intuitive, but in the hands of experienced power users (who have spent a lot of time learning the UI), it works really well. I have seen people (who have used the system probably for > 10 years) dig the most arcane information out in seconds, navigating through about ten different views without ever touching a mouse.

It's a UI from another era, but if you take the time to learn it properly, it can be very efficient.

With a lot of the nice looking web based apps we're used to looking at, the UX and the target domain evolve together and if there isn't an elegant way of doing a particular operation then there's going to be pressure to drop that operation entirely. SAP deployments always have to do everything in the organisation so complicated corner cases either get dropped (bad) or end up with suboptimal interfaces (also not great!).

Why did AWS, a group probably fairly technical savy and a direct competitor to its vendor, take so long [1] to migrate from Oracle?

Why does Google, as of today, have job openings for SAP in its Rev Rec division [2], and more widely in areas touching [3] “ SAP ERP domains (e.g. Finance, Revenue/Cost Management, Billing, Materials Management, Sourcing, Procurement and/or Inventory Management)”?

Granted you could say, and I believe in one of the many google “corporate biography” books Eric Schmidt allegedly worked through this same problem: hey is an ERP a product for us? A core competency? Should we build it? [Seems HN discussed this in 2021 already, 4]

Conversely, given the wide ranging scope of random things Google has built and how naively simple accounting and something like a fixed asset ledger looks at first glance…why did they never do it? Surely not because building 7 conflicting chat tools was a priority.

My guess (as a non developer) would be it’s crazy hard to build SAP. From personal experience even QB Online has a daunting level of “backwards compatible” complexity [5] in its data scheme even coming from an accounting background. The API keeps versioning up incrementally and you’ll find gems like “XYZ local French Tax” and other accumulated baggage. As an anecdote, using arguably a knowledgeable vendor, as of a year ago it wasn’t possible to populate a full simple profit and loss statement via Fivetrans ETL tool [6], even though they did a phenomenal job in mapping out the ERD compared to anything else that existed imho [7]. CDATA let you run SQL queries, but the complexity of scripting some of the reports was much more fragile. The community even built a DBT layer [8] and given how cumbersome it was to generate even just the “Revenue” line on the P&L out of a simple non-enterprise tool like QBO, SAP seems 1000x harder.

That’s probably why everything in-market, post-sales cycle is garbage. But hey, someone in a dorm room might be working on replacing SAP right now :)

Note: this excludes versioning, which I believe Workday does every six months, which is also a bunch of work twice a year.

1. https://aws.amazon.com/blogs/aws/migration-complete-amazons-...

2. https://careers.google.com/jobs/results/142858723165905606-r...

3. https://careers.google.com/jobs/results/118792275728704198-s...

4. https://news.ycombinator.com/item?id=26706991

5.(imprecise but good starting point) https://developer.intuit.com/app/developer/qbo/docs/api/acco...

6. https://fivetran.com/docs/applications/quickbooks

7. https://docs.google.com/presentation/u/0/d/1u0dnyq5L_rcEgR2_...

8. https://fivetran.com/docs/transformations/dbt/data-models/qu...

But lots of domain specific languages have idiosyncrasies. The Apex language used to program Salesforce is a half-implemented clone of Java from a decade ago. And they didn't cherry pick the best parts.

It may take just as much talent to write interfaces for obscure audio hardware and deal with janky bluetooth edge cases, but that doesn't mint the same $$$$ as a SAP guru who refactors a business process to be more efficient.

Telling that losing your uniqueness and being like “everyone else” will actually become your competitive advantage is something that only SAP can come up with.

If you already grew big, you won't grow bigger by adopting SAP. You can stagnate at best, as shown a million times in the real world. Companies that still want to grow just don't use SAP. Period.

Either is SAP though so, who knows.

   > There's virtually no competitive advantage to having unique business processes.

Take "Time Accounting" for example. I'm not referring to tracking hourly employee hours for payroll, I'm referring to tracking salary employee "project time." Every past salaried position I've had at a company with more than 90 employees had its own custom time tracking software[1]. The first company to do this was a multi-national telecom that I worked for. It was done so that each project could be broken out into its stages and the portion of the employees' salary could be itemized among "Capital Expenses" and "Operational Expenses". This was so important to the company that it warranted a massive development effort along with a corporate initiative to get 100% of time reporting in "on time." They did this as you'd expect a huge company would -- fail to hand in a time sheet on time a few weeks in a row and you'd get dinged more for that mistake than anything else.

The second and third companies ended up "accidentally developing time tracking software" specifically because there was competitive advantages to improving "Resource Planning". It was most helpful to my last employer. Their businesses was creating new products (often hardware/software combinations) for companies. This involved hiring a large number of people specialized in things that had limited cross-over. Resource Planning was predicting when what skills at what level would be available. This, necessarily, involved tracking what time was spent on projects in the past to improve those predictions and ultimately ballooned into a full time management and accounting application for the business (they sold "our time" to customers at the end of the day so it helped them to plan what to charge).

I'm curious -- from your perspective, is it that the competitive advantage is lost "because the tools that everyone is stuck with won't work" if you stray too far from "standardized" or is there another advantage to this standardization?

[0] Unique business processes and marketing are frequently the difference between the #1 and #2 company in a given space.

[1] In one case (about 250 employee global company), the company wrote it as a concept for a future product but once it was available, the existing solution was tossed primarily because the business side really liked the flexibility. In another it grew out of a pet project and became entrenched. At the remaining two, a decision was made to develop something from the ground up.

Imagine what wiring an office building would be like if all the wires, circuit breakers and tools could only be bought from a single vendor. Boggles the mind.

> Lidl based its inventory management system on purchase prices. The standard SAP for retail software uses retail prices, and fearing the group could lose a competitive edge by compromising, Lidl declined to change, so the software was instead adapted.

https://www.henricodolfing.com/2020/05/case-study-lidl-sap-d...

If you go too far, a SAP version upgrade is no longer a drop-in operation, but rather a year long project of porting all your changes to the new version.

If you stay as vanilla as possible, upgrades are a lot easier.

It's funny to see people here defending SAP, because the way I see even the smaller shops that did bend to SAP's will ended up with much of the same problems but with less much to address them and on top of that, much like other enterprise grade ERPs they had to spend a lot of money on infrastructure to process only a few RPS while struggling with high availability.

The lock-in is huger than huge. I don't think a single company on earth managed the art of locking in customers as well as SAP. Does anyone ever drop SAP? I don't know: the cases have to be exceptionally rare.

It's a racket. Highway robbery. This kind of behavior brings in a lot of revenues.

I personally do think the sale to the customer is complete and total misinformation. And once you've fallen for it, there's no way out.

Very hard to throw/replace ERP. It might happen but it‘ll take decades for global SAP installed base to shrink seriously.

> Is it solely customer misinformation?

SAP (and other „enterprise sales“ players) sold to CIO with „account relationships“. Then software is shoved down the throat of business users.

First you should know that the market for ERP systems is very wide. There are LOTS of various companies that offer their ERP systems. Also a lot of those "ERP" systems are "enterprise resource planning" in name only. The smaller ones often are focused on one thing only: bookkeeping, warehousing, invoicing, purchase management, salary calculation. Often they started as something that does one thing (usually: bookkeeping) and then more and more stuff was added on top -> as requested by customers. There was this old theory, that at some point each peace of popular software becomes so big that it can handle email. And guess what, SAP can send emails too. Tons of those other ERP systems can send email too. Different thing is if they really should.

The smaller ERP solutions often dont scale well (they cannot handle too many "things" e.g. millions of invoices, millions inventory SKUs, 20 different countries..) or are too simple / not flexible enough to actually customize. With those smaller systems, you can understand them (e.g. the whole system has few thousand tables), but this comes at the surprising cost of lower flexibility, because in order to handle the complicated business cases you have to recreate the complicated logic as well. SAP was used by so many big companies that a lot of the complicated logic is already there in its 'standard' (and as others pointed out: if you want your life easy, you should adjust your company to the standard, instead of trying to customize). Different thing is that you need a consultant to even know that those features exist. And as you can imagine SAP is so big that even the consultants can only focus on a certain part. [also I personally knew a situation where consultants wrote a custom extension for something that was available in standard -> they didn't know standard SAP standard well enough..]

I kind of disagree that a typical configuration of SAP has 20 000 tables. The ones I knew usually had 50 000+ and those were just few "modules". Using SAP terminology you have modules like FI (finance: bookkeeping), CO (controlling - financial reporting), FI-AA (asset accounting -> think list of assets the company owns), SD (sales & distribtion - e.g. issuing invoices). There are lots of those modules and usually the consultants know "their" module + the finance module. Because at the end the FI (finance) and CO (controlling) modules are always on the top -> you want to register the things that happen in financial ledgers and make some reports out of it.

For example: the consultant that sets up invoicing for you will know SD module (to set up the actual layout of invoices - how it looks like when you print it, the process flow etc) and FI (to help you configure that the invoices land on correct sales accounts). Someone else sets up the PM (plant management) module. Someone else handles access rights / authorization (small ERP systems often struggle at this part - and often "everyone can see everything" what is a big no-no in times of GDPR and just batshit insane when we think about corporate espionage).

A lot of complication with SAP comes from the fact that it can do things as per laws of different countries (please note: not necessarily out of the box, usually you need configurations and external add-ons). For example if you want the taxes calculated by the system for USA, Germany, Poland and Japan - then SAP can do it for you. The system (after painful configuration) will calculate the sales tax / VAT tax and also provide data to calculate CIT (I am not sure if any company calculates corporate income tax out of the box, I always saw an expert from SAP to some data/warehouse and a magic Excel file on top). Also laws change all the time, so system has to change all the time.

Even the basic stuff gets complicated once you need to handle it at scale + for many countries e.g. you want to issue the invoice, you need to use the correct tax type (e.g. VAT in Europe), the correct tax rate (e.g. like 50++ rates per each country), then you need to handle things like invoice corrections, exchange rates, handling exchange rate differences, withholding tax. And it is like this with >everything<. Every business activity that can be handled can be cancelled/reversed, what makes the logic of everything convoluted (e.g. when you reverse the invoice 3 weeks after it happened you need to use the correct exchange rate as per each country's law), because the bigger the company the more probable is that they will do something that shouldnt happen. SAP can handle this at scale.

Other thing is that there is a big moat. The process of setting up any ERP system takes at least months and generally years. The article explained it quite well. You need to migrate data to the system, check if it works, see if can handle your cases, train the users (the training part often is ignored, so lots of features are not used). Often the companies also dont have anyone to help with customization AFTER the migration, what is another big problem. It is public knowledge that more than 50% of ERP implementations fail.

There is also some degree of economy of scale. People who used SAP at one company have it easier to use at another. Although devil is in the configuration details. But at least they dont need to relearn the interface (that is awful in most ERP systems).

In a typical big company at some point you need to have your own in-house ERP administrators, who outsource parts of requirements to external sources and deal with the easier stuff on its own. The smaller systems are often inflexible for that - source code is not available. Different thing is if you want to handle the SAP source code with comments in German (yes, that's how it looks in some places; table and column names are German abbreviations too).

Speaking about incumbents: I read that there is some "magic" open ERP system (forgot its name - maybe it was OpenERP), that has just under 20 tables that supposedly can handle everything, but I never looked much into it. Perhaps 20 tables with 1000+ columns each (maybe still better than 50 000 tables with 10 columns each).

And to end it: ERP systems are like elephants. Once you set it up and it "kind of" works, then you dont want to touch it. You dont want another few years spent putting lots of effort on your tooling. You want to deal with actual core business part of the business. The article also pointed it out -> the quote that in some markets being able to implement the ERP better than the competition is the competitive edge is quite true. There are lots of companies with very very bad ERP, or multiple systems that dont talk with each other. What makes reporting hell. (not that reporting in SAP is easy) And without good reporting, the decisions are taken too late, or not at all.

I always see this comment on HN, I think I have been using Jira for a decade, never really had any major complaints.

I dunno. I find Jira pretty easy to use, like Git. Focus on the main fields/commands and open a new ticket/clone again if you mess up.

/s

BTW, on the last point - ABAP (SAP's proprietary language) has improved a lot over the years. Variable names are no longer so short (a vestige of the R/2 mainframe days) and the language has adopted a lot of features from Java and JavaScript. Not always the best (OOP like it's Java in 1998, woo!), but definitely a lot better than in the past.

It’s a strategy. No products. No quadrants. Just a more reasonable way of looking at business IT and enterprise development.

It happens to mesh well with my experiences and it’s sometimes nice to be able to whack “Gartner” about in certain settings - especially when someone’s trying to get traction for a magic quadrant product! :)

And to be fair - this is a thread about SAP and ERP…

Might not have official support, but personally I've never had problems with Firefox on Mac using UI5.

I currently work on a UI5-app at SAP and even though we don't use odata, I honestly don't find the process of developing it all that unpleasant. I found it really quite easy to onboard (being productive within like 2 weeks), though it may have helped me that I didn't really have much relevant frontend experience beforehand.

Some decently cool stuff is happening behind the scenes though. I believe they're working on getting rid of the jQuery dependency, and typescript support is also coming (though still somewhat in its infancy).

I will agree that it's pretty slow though, and very heavy as frameworks go. You can do a good bit to make it quicker, but it will never win any speed awards in its current form.

FWIW, I'm a massive HANA skeptic - I think it's overpriced and SAP betting the farm on it a few years ago wasn't necessarily the best option. It's a product that was put together from various disparate components - TREX, P*TIME (from Transact in Memory), etc - and that shows. It hangs together like something made of brown paper and string, with so many tuneables it puts Oracle to shame.

My task was replacing it with Spark/S3 :P

Of course, the reality is that many of those consultants who are being charged to customers at eyewatering rates just finished the training course last week and are now "senior".

the few consultants that I know that work with these two seems to be paid more than generalist consultants.

3rd party were working closely with customers and helped them maintaining the stuff

My first ever SAP implementation was for a large retailer and the project was cancelled (they later implemented SAP ~10 years later after the product matured somewhat) and another project 8 years later was also cancelled. Only two SAP projects I've been involved in that have been cancelled and both were retail (and using IS-Retail, SAP's solution for retail industries).

But there's literally decades of use cases and experience contained in that code. That's one major issue with people thinking about rewriting software, they vastly underestimate the amount of things in there.

I mean on the surface SAP is just a database with a UI and some business rules - 99% of software is - but that in itself is so often underestimated.

(Source: anecdotal, I underestimated 'just' a configuration interface, except that it had hundreds of models and thousands of fields. In hindsight I should've looked for an off-the-shelf data management thing where all I would have had to do was configure the fields and validation rules and some rough layout. Instead I tried to build it in naive Go, sqlite, a REST API and a React/bootstrap front-end. It's a great solution IMO, but not if you're a solo developer working on a domain that big).

The problem is who gets to decide what is "core" to your business?

Look at airlines, once the McKinsey types were let loose it turned out none of the stuff we think is core is needed at an airline; no need for in-house staff, catering, baggage handling, check-in, maintenance or even [owning] any actual aircraft. So much easier to operate without all that stuff to look after!

Taken to the extreme presuambly one would end up with nothing but an airline's name and trademarks, a handful of overpaid management types, and maybe a bunch of lawyers to look after all the outsourcing/subcontracting and licencing deals.

Except there are many businesses that have and are doing very nicely precisely because they ignored what would labeled as non-core activity by many. Take Apple for example, where would it be if it had stuck to making Macs? Or more recently spent billions moving to their own chips. What about Amazon?

Truth is more subtle. And with SAP, it's easy to understand both why businesses buy it - and at the same time - why most competent software developers believe if they were given the same investment they could do better.

This I have experienced first hand where this junior product manager who wrote some ticket whose requirements when got challenged says "it's mentioned here so you have to do it and you don't have to challenge it". I lost it and I said, "everything needs to be challenged, we are not just going to follow it like a machine". I did apologize to him for my tone. But it bothered me so much.

Software is seen as a necessary evil in Germany, not as the main focus for profit. You can directly see this in most medium to large companies which sell ERP or management software (like Scheer) pay their sales reps a lot more than their developers, even though the latter produce their value.

I worked for a software company in Aachen for a while that supplied software for local manufacturing and this is necessarily "meh" and largely consists of doing as your told and building to specification because that's what industry-adjacent work is like. Doesn't mean it's not good software.

Microsoft has a suite of ERP software – Microsoft Dynamics. They got it by acquiring a bunch of companies – Great Plains, Navision, Solomon, Axapta. Originally on-premise, now they encourage SaaS but some of it is still available on-premise for those who prefer that. Generally focuses on the small-to-medium enterprise sector, although they've been trying to make inroads on larger enterprises; but large enterprises are still dominated by SAP, Oracle, Salesforce, etc.

We implemented relatively simple income tax reform a few decade ago in small EU jurisdiction. But law makers were very vague in some important details, and there were about 8 different interpretations. We had to implement, run and support all 8 versions for couple of years, until they decided on final interpretation. Non compliance would be fine of couple of million euro.

And that was tiny country of 5 million people with clean newly written laws. Not babylon with 300 years of baggage like US.

That's true but TBH, even those that are wildly successful aren't actually that great. I've implemented Workday as a replacement for the user-facing portions of SAP's HR and while it looks good, it's nowhere near as flexible. There's a lot of stuff I would expect to be available in Workday and just isn't. That surprised me as Workday is pretty much the HR market leader.

TLDR; Opportunities are there for new companies to do ERP better. It's not easy though...

SF started with CRM and has been expanding to ERP, SAP is the other way around. Both are mainly Cloud/Platform-based offerings today, both feature multi-month certifications, high rates for contractors and lots of effort administering/configuring/customizing.

I expect in a couple of years they either turn out exactly the same or swallow each other.

The developer experience is terrible, simple template changes need a your modules to be "upgraded" which means every change takes several seconds at least.

The quality of the app ecosystem is so bad you almost can't install any non-core apps if you want to be able to maintain your project. And apps are incredibly expensive (250€ for a GDPR compliant cookie banner). Most apps have quite few downloads so you don't know if you get what you're paying for.

The documentation is partially non-existing and you're supposed to read odoo's code to know how things works - which is true, but quite time consuming.

If you google technical questions you find odoo forum entries (which could be ok) that often contain just links to youtube videos or simply bad and out-of-date answers.

Here's a link to a forum post (full disclaimer - of me) about some of the things that kept me from getting things done with odoo: https://www.odoo.com/de_DE/forum/hilfe-1/rant-developing-wit...

These issues are just the tip of the iceberg. I honestly wonder how people working on/with odoo deal with this. Things literally take multiples of the time they should and the whole process is a PITA.

Funny sidenote: If you google odoo developer experience and try to find what others have to say about this, you get their conferences since they're called "odoo developer experience".

Do you know of a QuickBooks-scale accounting system that does EDI easily?

I used to think this, but then I started interacting with actual end users (normal, non-engineering people). There are 2 main problems with exposing more barebones stuff to non-engineers:

1) Problem solving (thinking about how to compose the raw primitives) takes a lot of creativity. Most normal people only know what end outcome they want, not how to engineer their way there*. The reason wizards are so common is because they address this exact need. Wizards try to figure out what you want to do via a series of questions (and then do it for you) rather than have you come up with how to do it yourself. They are so common because when designed correctly they work very well!

2) Understanding errors is also very hard. Just because something didn't fail doesn't mean it worked correctly. Sure, anyone can file a transaction into a database, but they can just as easily file an incorrect one either by mistake or due to inadequate understanding. The complexity of the systems are their to catch problems before they become problems.

Sure, sometimes there will be corner cases that aren't accounted for by the existing system. And these will be frustrating. But taking away both the end users' guide and also removing their guardrails just so they can maybe solve the problem themselves is not generally a great idea.

*: This is not meant to disparage the normal users, but different people just have different interests and goals. Not everyone should be forced to know exactly how a machine works just to operate it.

I left a number of years ago and I'm certain things have evolved since, but the cost/benefit calculus is similar to any make vs buy decision.

In my opinion the primary benefit of an in-house developed ERP system (or any purpose-built system) is that it does only what it needs to do and nothing else. Thus, some types of accidental complexity are reduced, business user cognitive load can be lower, and performance and scalability can potentially be higher. Also of course there is no application licensing cost and hence user count is constrained only by infrastructure and code quality.

Now the difficult part: you spread the cost and risk of development over one customer, and ERP software is not a simple matter to build: essential complexity inherent in modeling business processes in software remains unchanged. You also have challenges finding subject matter experts as most of the folks who understand the internals of ERP systems are already working for one of the commercial vendors and will scoff at your audacity.

To be successful it requires leadership with vision, commitment, and patience; as well as a team of talented analysts and engineers.