

Ask HN: Are ERP's overpriced databases? - itsathrowaway

I have some limited exposure to SAP, which is an ERP. From my experience SAP is nothing but a database with a GUI. I haven&#x27;t seen how SAP can do anything that any database (mysql, postgre) with a webframework (django, rails, etc.) couldn&#x27;t do. Am I missing something here? I don&#x27;t see why anyone would go with these vastly expensive ERP systems rather than hiring a few programers and using something like django or rails. ERP&#x27;s seem like outdated over-priced nightmares to me.
======
tumba
The promise of ERP that drove people from best-of-breed application portfolios
to monolithic systems was primarily the efficiency of integration. That is,
your payables, treasury, etc. would automatically post to the general ledger
and utilize unified master data (customers, products, vendors).

Ironically, in large scale (SAP-class) enterprises today, the integration
problems are often relate to the fact that they are running multiple ERPs they
picked up through acquisition and run customized business rules that cannot be
cost effectively moved. Look at large scale master data management tools to
get a sense of this type of problem.

Much of my work involves mid-market ERP from Microsoft, Sage, Infor, etc.
These vendors can give a smaller company an entire integrated suite of tools,
with great support, an ecosystem of ISVs fully implemented for $200-300k,
including consulting. That remains a compelling value proposition and less
risky than hiring programmers, who these companies have no idea how to manage.

One company to watch is Infor. Their strategy involves traditional ERP
(usually products tailored for a vertical) at the core, with ancillary
products integrated through standard middleware or APIs and delivered through
Amazon cloud services.

------
brd
I'm an SAP guy. I've been a developer, architect, and now a manager of sorts.
I'm not necessarily a fan of SAP but SAP has certainly earned my respect.

ERP provides stability through support.

ERP provides common ground so you can speak with other companies, partner with
3rd parties, and easily hire people with knowledge of your system.

ERP provides standard interfaces for slapping together more ERP tools.

ERP provides security models, governance models, and provides the means for
meeting industry specific compliance requirements.

SAP in particular (and all ERPs to some extent) provide a shockingly massive
amount of business logic. They facilitate a vast array of industries, business
processes, and provide a robust system for tracking your business data in a
semi-stable/rational way.

Where SAP in particular has gone wrong is that they're entrenched in their own
proprietary technology. They're victims of their own highly successful code
base and cannot easily get out from under it. They'll lose eventually but
whether it takes them 10, 20, or 100 years to lose remains to be seen.

I'm a developer at heart and I can say, with confidence, that I would rather
spend money on SAP than build a home grown system knowing full well the mess
that SAP is. With the right team (i.e. damn good developers with industry
experience) I could probably build something better and I've talked to a few
people about it in the past but you are talking a true uphill battle from both
a technology and a sales perspective.

Having said that, if anyone feels the need to take on the ERP space, feel free
to contact me as I'm certainly not adverse to the idea. I've thought about it
plenty and there are definitely attack vectors available.

------
teddyc
I work on an ERP system in the higher education industry. Also, when I got my
MBA, they taught us a lot about the ERP systems from an executive point-of-
view.

The 'E' stands for Enterprise, which means this is a big installation. I think
2 big reasons to choose an ERP over an in-house solution are:

1\. They want support. They want to be able to hire people or pay consultants
that already have experience with the ERP system. Building a system that your
enterprise entirely depends upon introduces a level of risk. Having a big
company like SAP there to support you reduces that risk.

2\. They want something built for their industry. ERP systems are typically
designed around the generic business processes for a given industry. The
technical type of people that can write code might not know how to design a
system to properly match the business processes of the company.

\-----

Yes, at the heart of an ERP is a database, but there is more to it than that.
There is access/control concerns as well as audit log concerns. There are
various industry/government mandates (like HIPPA or FERPA) that need to be
adhered to. There are all the interconnections under the hood to make
everything work. ERP systems are so complex that usually no single person
understands the entire thing. You might understand a module or a component,
but it typically takes a group of experts to have a working knowledge of
everything.

And yes, ERP systems are really expensive. You have to buy annual licenses and
support contracts. The hourly rates for support are expensive too.

~~~
mjn
On #2, a colleague of mine has a hypothesis that that's a primary reason a lot
of smaller enterprises (on the threshold of enterprisey) buy ERPs: it tells
them what they should be keeping track of and how, along with providing the
tool to do it. When small companies grow large quickly they often end up being
very unsure of how to structure their processes and accounting, and having a
built-in solution for "this is how companies in field X do things" is
appealing. So it's not only that they worry about the risk of building an in-
house solution, but they also worry they wouldn't even know what should go in
the solution! Buying SAP not only gives them the software, but a template for
how to structure their business's processes.

In a way it's a little like adopting git and a particular git workflow.
Adopting the workflow can be the really valuable part, especially if you had
no idea how to structure a workflow in the company previously. The tool is
secondary, and just helps structure the workflow. Seen that way, implementing
SAP is sort of like buying a default-business-process template, along with
some enabling software. (On the other hand, it does run the risk of producing
some cargo-cult business practices. If businesses structure their processes to
fit SAP, rather than vice-versa, it's not necessarily the case that anyone is
checking whether these processes still make sense.)

------
dragonwriter
> From my experience SAP is nothing but a database with a GUI.

Yeah, its a database with a GUI.

> I haven't seen how SAP can do anything that any database (mysql, postgre)
> with a webframework (django, rails, etc.) couldn't do.

Sure, the difference is that the ERP has already had a lot of resources
investing in (1) researching what large enterprises users are likely to need
it to do, and (2) implementing the specific code to do that.

And lots of money marketing that investment to enterprise decision makers.

> Am I missing something here?

Probably.

> I don't see why anyone would go with these vastly expensive ERP systems
> rather than hiring a few programers and using something like django or
> rails.

Convenience record, perception of a proven track record (though ERP
implementations aren't exactly historically problem-free), having an stable
institution committed to support when inevitably things _do_ go wrong, and
likely a combination of you underestimating and purchasers overestimating the
amount of programmer time and cost that would go into implementing the
functionality any individual purchaser needs from scratch rather than starting
with the canned modules of the ERP and doing any needed customization.

Both rational and irrational factors are involved.

> ERP's seem like outdated over-priced nightmares to me.

They are designed for the massive enterprise market which has a different
preference for the degree and _types_ of risks that purchasers are willing to
take on, and the price they are willing to pay to mitigate them, than many
other markets, and where the decision-makers are usually pretty far removed
from the details of technology.

------
arethuza
What I would say you are missing is the amount of business logic there is in a
large ERP system. Consider all of the modules of an ERP system:

Finance (GL, Fixed Assets, AR, AP, consolidated reporting)

Product management

Production control

Planning

CRM

HR

Payroll

... a long list of other things

Take all of these features then add an appropriate security model, then add
the need to support localized business logic for each country (which you
_must_ have to meet local legal requirements) and spice up a bit with business
specific customizations.

Do ERP systems have problems? Absolutely. However, like pretty much any
developer when I've encountered a lot of systems I've thought "I could design
something better than this" \- in the case of a large ERP system (mind you,
not SAP) I did realise that it was a few orders of magnitude more complex then
any small team could really handle.

NB I do think there is a huge opportunity for someone to do for ERPs what
Salesforce did for CRM systems.

------
randomITperson
Yes they are. I worked at a place where I had to build some web based
reporting/BI apps around the data from an overpriced, proprietary ERP system
designed for manufacturing. The Windows based client could have just as easily
been a web interface and everything was stored in MSSQL DB's. Granted, there
was a crap ton of tables, but nothing that complicated. Once I dug through it
all, there really wasn't much to it. Most of the calculations it was doing
were straight forward arithmetic. The complex part was just understanding the
processes and workflows involved and how they related to the business side of
things (ordering, manufacturing, invoicing, purchasing, inventory, accounting,
shipping etc, etc.). But technically speaking, it's not that involved. My take
away from this experience is, if you want to build a successful ERP app, it's
all about usability.

------
benologist
Most of the internet is interfaces over databases, or "CRUD apps" because they
Create, Read, Update, Delete from a database.

People choose to use existing ones instead of making their own because it's
usually a lot faster and cheaper.

[http://en.wikipedia.org/wiki/Create,_read,_update_and_delete...](http://en.wikipedia.org/wiki/Create,_read,_update_and_delete#Database_applications)

------
walterbell
SuiteCRM (OSS fork of SugarCRM) will soon be raising money to create a non-
profit foundation,
[https://suitecrm.com/index.php?option=com_content&view=artic...](https://suitecrm.com/index.php?option=com_content&view=article&layout=edit&id=181)

There is also Oodo (formerly OpenERP),
[https://www.odoo.com](https://www.odoo.com)

Either of these is better than starting from scratch, due to the existing
apps/templates.

------
chris_wot
The amount of business and industry logic tied up with ERPs is what makes it
so expensive.

------
hmahncke
You should act on this thought and build a billion dollar business disrupting
SAP.

