Ask HN: Are ERP's overpriced databases? | Hacker News Reader

Ask HN: Are ERP's overpriced databases?

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't seen how SAP can do anything that any database (mysql, postgre) with a webframework (django, rails, etc.) couldn't do. Am I missing something here? 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. ERP's seem like outdated over-priced nightmares to me.

View on HN

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.

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.

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

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.

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

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

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.

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

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.

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

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

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

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

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

Reply on news.ycombinator.com