
What's SAP? - dvdhsu
https://retool.com/blog/erp-for-engineers/
======
mr_gibbins
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.

~~~
tomnipotent
> 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).

~~~
endymi0n
The correct answer here is "it depends".

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

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

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

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

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

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

~~~
tomnipotent
> 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.

~~~
zamalek
> 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.

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

[https://documentlibrary.qad.com/documents/2370665/2368142/Da...](https://documentlibrary.qad.com/documents/2370665/2368142/DatabaseDefinitions_TR_v2012_1EE.pdf)

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.

~~~
ants_a
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.

~~~
mmcgaha
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.

------
OldGuyInTheClub
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.

~~~
kumarvvr
> 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.

~~~
mbesto
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.

~~~
BlobRunner
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 ?

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

Strip only handle a tiny fraction of what banks do.

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

------
fefe23
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.

~~~
shrimpx
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...

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

~~~
quietbritishjim
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.

~~~
vasco
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).

------
npace12
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.

~~~
cptaj
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

~~~
neves
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.

~~~
bock
There is [https://open.sap.com/](https://open.sap.com/) Free courses directly
from SAP without expensive consulting firms in-between.

For parent maybe this would be interesting:
[https://open.sap.com/courses/cp7](https://open.sap.com/courses/cp7)

------
new_here
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.

~~~
orbifold
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.

~~~
schnevets
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).

~~~
erikpukinskis
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?

------
theshrike79
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.

All failures are the opposite.

~~~
carstenhag
A perfect example for a failure for this is Lidl's Elwis, they invested 500
million € into it and in 2018 they aborted the entire project.

English article: [https://www.handelsblatt.com/today/companies/programmed-
for-...](https://www.handelsblatt.com/today/companies/programmed-for-disaster-
lidl-software-disaster-another-example-of-germanys-digital-
failure/23582902.html?ticket=ST-1784344-eCkejiV7igUviBx35ZI9-ap2)

Key quote:

>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.

~~~
thdrdt
But I still think this is a failure of SAP.

What if the business model of Lidl is way better than the standard? Then Lidl
is very wise not to follow how SAP works.

~~~
cc81
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.

------
patja
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.

~~~
solarkraft
Thanks for sharing that! Do you happen to know how MS feels about that
implementation nowadays?

~~~
patja
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.

------
lewisjoe
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.

~~~
asc_jiji
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

~~~
strictnein
Worked at SAP. We had to use SAPUI5. Felt like it was created by a cadre of
bitter enterprise Java (yes, Java, not JS) devs.

------
dvdhsu
Hi! (I'm one of the editors of this post.) When I was researching SAP, I found
a fact sheet:
[https://www.sap.com/docs/download/2017/04/4666ecdd-b67c-0010...](https://www.sap.com/docs/download/2017/04/4666ecdd-b67c-0010-82c7-eda71af511fa.pdf),
that has quite a few interesting facts:

* "[SAP] customers distribute 78% of the world’s food and 82% of the world’s medical devices"

* "[SAP] customers include 98% of the 100 most valued brands"

* "77% of the world’s transaction revenue touches an SAP system"

Wow!

~~~
john_minsk
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...

~~~
fogetti
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.

~~~
mrich
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.

~~~
golergka
Event Microsoft does it ([https://www.erpsoftwareblog.com/2012/11/why-does-
microsoft-h...](https://www.erpsoftwareblog.com/2012/11/why-does-microsoft-hq-
use-sap-instead-of-microsoft-dynamics-erp/)), despite the fact that they have
their own ERP product (Dynamics).

------
zebrafish
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.

~~~
aneutron
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.

------
kthejoker2
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.

~~~
kradroy
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.

------
greatartiste
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.

~~~
OldGuyInTheClub
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.

~~~
hef19898
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 _purely_ SAPs fault so.

~~~
benhurmarcel
> 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.

------
eftpotrm
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.

------
olavgg
Tesla decided a few years ago to replace SAP with something they built
themself [https://www.mendix.com/blog/tesla-cio-builds-erp-
house-4-mon...](https://www.mendix.com/blog/tesla-cio-builds-erp-
house-4-months-says-time-erp-upgrades/)

I love this story, it really isn't that hard to replace SAP once you know the
requirements.

~~~
kamaal
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.

~~~
modo_mario
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.

------
mitjam
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.

~~~
Aeolun
But any integrated system would do this. It isn’t unique to SAP.

------
JackPoach
That's actually a very well written article. I never imagined an article about
SAP or ERP would be interesting to read.

~~~
oaiey
The last paragraph is not good. Is it only me or does it leave a conclusion
lurking around without saying it aloud?

~~~
halfnormalform
It doesn’t match the quality of the rest of the article and would really
benefit from some fleshing out.

~~~
toyg
I bet there were extra paragraphs but an editor went “too many words already
for a webpage” or “let’s not criticise them too much”.

~~~
oaiey
I also think that. They skipped making a statement about today's SAP position.

------
Tomte
ERP software is a monster.

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...](https://www.consultancy.uk/news/18243/lidl-cancels-sap-introduction-
having-sunk-500-million-into-it)

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.

------
monkeynotes
SAP implementation basically sunk Target's huge investment into operations in
Canada

[https://www.canadianbusiness.com/the-last-days-of-target-
can...](https://www.canadianbusiness.com/the-last-days-of-target-canada/)

Seems to me SAP is ripe for disruption, but it would be a very challenging
throne to unseat.

~~~
delfinom
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.

~~~
jerf
"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 ...".

~~~
pmart123
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.

~~~
hyperpape
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](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.

~~~
jandrese
And now you see people trying to make JSON schemas and validation and all of
the associated headaches that made XML such a pain.

------
lucasverra
Can please a decision maker regarding SAP buying/implementing tell us how on
earth SAP is that mainstream (in corporate) ?

I've had to use it at EU big corp, and it to this day the worst experience I
had.

I've seen at techcrunch Berlin 2019 that there is something called SAP.io,
somewhat opening its plateform ?

~~~
deelly
Can you name good alternative that supports all SAP features?

~~~
ProstetnicJeltz
'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.

~~~
julienfr112
I know of a French Organic retailer that took that road ( postgres / java /
angular). The story ends well. May be an exception. Or not.

~~~
mbesto
Amazon is mostly bespoke and from what I've been told, its basically hell.

~~~
hef19898
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.

------
ksahin
"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."

Wow, really?

~~~
cromulent
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.

~~~
1propionyl
What's the breakdown of those configuration tables? I'd imagine (perhaps
incorrectly) that most are just integer/enum/bool fields?

If so, how many of those tables just exist to define enumeration cases?

~~~
72deluxe
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.

------
diminish
Some consultant had told "Adopting an ERP (SAP, Oracle or other) is a stronger
bond than marriage". So those valuations could be strong and long term.

~~~
probably_wrong
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.

~~~
72deluxe
Do users just accept this "feature" garbage? I get the feeling they do.

~~~
benhurmarcel
They don't have a choice. You're not going to resign because the software to
submit hours has a terrible interface.

------
greatartiste
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 !

------
widforss
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.

~~~
jedberg
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. :)

~~~
widforss
We had a giant garbage bin beside the table, everything was tossed.

~~~
jedberg
All those poor trees...

~~~
ars
Think of it as carbon sequestering.

------
tonyedgecombe
_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.

~~~
zxienin
what does this competitor run its business on?

~~~
swarnie_
Could well be SAP just deployed by a different consultancy team, in fact it
wouldn't surprise me.

------
cognaitiv
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.

[1] [https://www.qlik.com/us/sap-analytics/sap-data-
replication](https://www.qlik.com/us/sap-analytics/sap-data-replication)

~~~
kthejoker2
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)

~~~
cognaitiv
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.

------
usui
Thank you for this link. It is highly informative for someone who is not
familiar with SAP or enterprise management.

I searched on Google, "What is SAP?" Here are the top three links as of today:

1) [https://www.sap.com](https://www.sap.com) 2) [https://www.guru99.com/what-
is-sap-definition-of-sap-erp-sof...](https://www.guru99.com/what-is-sap-
definition-of-sap-erp-software.html) 3)
[https://en.wikipedia.org/wiki/SAP_ERP](https://en.wikipedia.org/wiki/SAP_ERP)

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.

------
wuschel
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!

(Disclaimer: I have no affiliation to SAP etc).

~~~
unnouinceput
"<...although some PR...">

Some? It's 100% PR. Nothing else. 1st ad I see this year, courtesy of HN,
cause otherwise uBlock Origin would've stop it.

------
kriro
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.

They just can't/won't roll out new things.

~~~
dr_dshiv
Yeah, what is that about? Do you have more insights on this?

~~~
somesortofsystm
Academia is easily bought, especially in Germany.

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.

:wq

~~~
epr
:x

------
lizknope
I worked in the IT department in 1996. Every other day I would hear a bunch of
people say "SAP is down!" and scramble to fix it.

I started working as an engineer in 1997. Every other day I would receive an
email saying "SAP is down, IT is working to resolve the issue."

This continued at my job in 2005.

Last week I got an email from IT saying "SAP is down."

I still don't know what it does or really care but it sure is down a lot.

------
shrimpx
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?

~~~
kokey
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.

~~~
blattimwind
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".

------
danzig13
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).

~~~
danzig13
I will say, even with all the problems, even our ERP is capable of quite a few
things, and I couldn't fathom rolling my own.

They just don't want you to plug anything of your own into it.

------
davidw
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:

[https://www.google.com/maps/place/49%C2%B018'00.0%22N+8%C2%B...](https://www.google.com/maps/place/49%C2%B018'00.0%22N+8%C2%B039'00.0%22E/@49.2981602,8.6427025,2955m/data=!3m1!1e3!4m5!3m4!1s0x0:0x0!8m2!3d49.3!4d8.65?hl=en)

------
72deluxe
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.

------
pinky07
My company is doing an open source alternative to SAP (and replace several SAP
implementations already): [https://www.odoo.com](https://www.odoo.com)

~~~
zxienin
> and replace several SAP implementations already

Can you clear up on „several“? Are these SME or LEs? Names?

~~~
pinky07
We do both SMEs, and large corporate, with 5.5M users in total.

I would say we sign a 1000+ employee corporationn every month. Example, in
Portugal we replaced 150 legacy proprietary software in 3 years:
[https://joinup.ec.europa.eu/collection/open-source-
observato...](https://joinup.ec.europa.eu/collection/open-source-observatory-
osor/news/portugals-annual-school-teac)

More case studies here:

------
bitcuration
>>"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.

------
dcolkitt
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.

~~~
lorenzfx
Most of them are, as you can easily find out by putting SAP in their careers
search, e.g.,
[https://careers.google.com/jobs/results/?company=Google&comp...](https://careers.google.com/jobs/results/?company=Google&company=Google%20Fiber&company=YouTube&employment_type=FULL_TIME&hl=en_US&jlo=en_US&q=SAP&sort_by=relevance)

------
ericalexander3
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.

------
nateburke
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.

------
leto_ii
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).

~~~
swarnie_
I can answer number 2.

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.

~~~
leto_ii
> The closer you stick to "out the box" ERP the more chance you actually have
> of moving off of it in the future.

Interesting. But it still limits you to moving from ERP to another I guess.

------
ubermonkey
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!)

------
hanniabu
SAP wouldn't be that disheartening to use if it weren't so damn slow and if
UI/UX wasn't from the 90s.

~~~
spectramax
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](https://twitter.com/tuomassalo/status/978717292023500805)

It is dense, extremely clear and consice. I agree with the slowness though.

~~~
meddlepal
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.

~~~
cm2187
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.

~~~
reportgunner
I agree with your comment except Visual Studio part. Everytime I use Visual
Studio it feels like I'm using a big pile of hacks of varying age.

~~~
72deluxe
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).

~~~
reportgunner
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.

~~~
72deluxe
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!

------
kabes
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.

~~~
tastroder
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.

------
rbosinger
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!

~~~
Noumenon72
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.

------
pferde
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. :) )

~~~
indemnity
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.

------
codingdave
> ...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.

------
Angostura
I really, really like this style of article. What a fantastic introduction

------
CameronBarre
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 :).

[1]
[https://bitbucket.org/cjbarre/jsoft.json/src/master/](https://bitbucket.org/cjbarre/jsoft.json/src/master/)

------
brnt
SAP is how Lucifer interacts with our world.

------
nrclark
SAP is Germany's revenge for WWII.

------
tibbydudeza
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.

------
adeel_siddiqui
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.

~~~
Mandatum
Billing is the #1 growing package YoY here in Australia for our consulting
firm. Nobody knows what they're doing. It's great.

------
jboggan
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.

------
tarsinge
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.

------
kdeldycke
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.

~~~
commoner
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.

~~~
kdeldycke
Good point, and thanks for demonstrating how compromise needs to be pondered
at the executive level too.

------
godelmachine
Warning - very very vague question

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)

Let me know if I am too vague

~~~
john_minsk
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.

------
totololo
Do "high innovation velocity" companies like Tesla or SpaceX use any ERP? If
so, do they develop in house? Use a modern equivalent to SAP?

~~~
zxienin
Tesla built their ERP. Unclear, to what extent. I hope an (ex) insider can
share facts.

~~~
totololo
Interesting, thanks. Amazon is known for having built an API for all
departments to share information right?

------
bilekas
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.

------
lowdose
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.

------
lonelappde
As hinted in the article, SAP is bad because anyone who could do it better
would dominate their industry and not sell it to the public.

------
RobertRoberts
I have a company that runs Filemaker Pro databases for managing some parts.
And they have considered using SAP recently.

How much product/inventory/sales/etc... processes is required before you
should move from FMP to something like SAP?

Is it number of users, client accounts, employees, products? What is the break
point for needing ERP (Enterprise Resource Planning) software?

------
trollied
SAP is shocking.

I'm so glad that I now work with NetSuite!

~~~
zxienin
what did you find better in NetSuite?

------
ab_testing
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.

------
throwaway8291
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.

------
cr0sh
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.

------
floppiplopp
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.

------
littlejohnny
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?

------
nojvek
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)

------
belinder
> 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.

Hard to imagine even getting to that point

------
mdip
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.

------
unixhero
ERP and SAP is a goldmine if you know how to provide consulting for it.

------
pcmoore
One early forerunner was LEO
[https://en.wikipedia.org/wiki/LEO_(computer)](https://en.wikipedia.org/wiki/LEO_\(computer\))

------
gadders
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.

------
gbasin
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

------
eranation
What’s the main reason we don’t see many startups trying to disrupt that
field? Is it the long sales cycle? The upfront investment? Lack of awareness?

------
thomasedwards
One implementation of SAP I’ve used marked items requiring attention in green,
and completed/finished items as yellow/red.

------
znpy
I can't wait to see this article commented on a certain website that doesn't
want to be named.

------
chid
Did anyone see the news around extension of ECC6 support? To me it seemed like
the logical decision.

------
bass3l
A side question, anyone knows how the illustrations on Retool homepage are
made? The animated ones

~~~
syogi
They're made with react-spring

------
anvarik
> 77% of the world’s transaction revenue touches an SAP system

wonder how they have calculated that

------
asmosoinio
Should have (2019) in the title?

Couldn't fine a date in the post, but it does say:

> It’s 2019, and SAP is ...

------
fnord77
SAP demonstrates the power of sales relationships and corruption over utility.

------
andyjpb
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.

------
iso1210
It's a program built to prevent corporations from spending money

------
arendtio
Does someone know a good place to start learning SAP CAR?

------
vangelis
What isn't SAP?

------
zxienin
Why not develop your own ERP if SAP forces one to change its processes?

AFAIK, Tesla is the only company I've heard to have done it. Would be useful
to hear their experiences on this road.

------
wackget
> Article is titled "What’s SAP?"

> Doesn't actually tell you what SAP is, or stands for, until halfway through
> the article.

------
sparker72678
This thread is depressing.

------
buzzkillington
I wanted to be angry at it. But I couldn't. It's so bad it's reached
greatness.

A piece of software that plays (at least) one sound on every user action, and
the sounds are completely arbitrary and 8bit _at best_.

Where you have to press 5 buttons in a row to do the one thing it's meant to
do.

Where you have an angry fruit salad in a time sheet.

A piece of software that takes 30 minutes to enter your worksheet time. And
lets you enter a special opex code for using it.

I felt the anger and hate of the man who coded it and every Friday I felt I
knew that man better than anyone else I have ever known.

~~~
froindt
>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?

~~~
dfox
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.

------
0xff00ffee
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.

------
marta_morena
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.

------
pojntfx
SAP is the worst software I've ever used in my entire life; they literally
have to publish paid books on how to use it, that's how bad it is.

~~~
galacticaactual
There are "paid books" about everything from Python to Go to Swift to
whatever. That is quite frankly a bad heuristic.

~~~
mcv
Yeah, I'm not exactly surprised that modeling complex business processes is
not a trivial task.

------
mac_was
SAP is the ultimate B2B and turning into saas, should be the wet dream of
every dev who wants to build his own saas.

~~~
oaiey
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).

~~~
mschuster91
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.

~~~
oaiey
open source implies license. It is "source open".

------
sdan
Nicely written article, but I don’t see what the use of an ERP is? Can’t it
just be replicated with some excel spreadsheets?

~~~
roel_v
Peak HN right here.

~~~
zxienin
in what way?

~~~
mopsi
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.

~~~
PleaseLoveMe
I think you'd be surprised how much is still done in Excel at even really big
international companies

