Hacker News Reader

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

> developed on a system that isn't designed to intuitively express the degree of logic required

The poor souls are such because they usually fundamentally do not have the knowledge required across the broad spectrum of responsibilities an ERP does and how that all ties into managing a business.

> I predict that millennials, who increasingly refuse to interact with anything below "app quality,"

This makes no sense. What do millennials have to do with anything? I fail to see how a generation label makes any difference to how ERPs are involved in business management and how accounting and finance in general work. How supply chains are managed isn't going to change because of a bunch of woke millennials.

> everyone will build their own faulty but usable ERP systems.

Always said by people that do not understand what an ERP does and the complexities involved in managing a business. I used to think this way myself, until I actually had to deal with these issues in a senior management position with investors breathing down my neck. My naivety was amusing in hindsight.

> How supply chains are managed isn't going to change because of a bunch of woke millennials.

Parent's point was that systems require trained and capable people.

If the job entails dealing with something arcane, and you can't pay more (because cost center), then at some point you face a labor gap.

I can't see this happening any more than mechanics influencing how engines are designed. It sounds nice to rah-rah-rah the revolution, but ERPs are the dark underbelly of business are not going away any time soon while we depend on the 3 statement model.

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

This is a product designed for small to medium sized businesses so it is not as comprehensive as a SAP. Take a serious look at the schema and imagine if you just had to write CRUD, it would take hundreds of man years. But it is not a CRUD app because there is business logic behind ever module.

Now imagine that there is also a whole ecosystem of vendors that sit under the QAD tree to provide niche solutions for the various use cases not covered by QAD. So not only do you have to write the ERP, but you have to write the pieces picked up by the other vendors in this ecosystem.

Is this supposed to pass as documentation? Looking at that document the first reaction is that I would rather spend a decade implementing my own ERP than go anywhere near that mess.

I get that a list of tables and fields is not great documentation by itself, but QAD also provides ERD diagrams, implementation guides, user guides, administrative guides, and other documents. The overall quality of their documentation is outstanding. I worked in a QAD shop for over ten years, and their documentation is complete, accurate, well organized, and easy to understand.

This looks ... terrible. I bet it works and delivers value or something, but that doesn't mean it's something to be proud of or to defend how it's designed.

I mean surely there is a better way than thousands of database tables ... with separate business logic.

Do I understand correctly that for a "small to medium" business, they would only use a fraction of the functionality / database tables, but in order to support all potential "small to medium" businesses, it needs to be this convoluted mess?

Well, "app quality", you mean those shiny UIs with abysmal usability. Because usability is more about the behavior of a syste m then removal of button edges. ERP and SAP is definetely neither sexy nor hipp nor woke nor does it have an even acceptable usability, but it doesn't have to. It has to help making money. And that's a business, as tough as they come.

> I hear this all the time, and it's almost always wrong. Engineers and businesses are always convinced they're special and don't fit the mold. That's rarely the case, and the money used on these initiatives was probably better spent elsewhere.

That seems like big statement given you have no context about the person making it.

I also work on a team that has built large potions of this intentionally and willingly. And the results have been great.

The reason is we don't hand off our business to a black box part way through our business process. We own it. Top to bottom.

This means when we change the products we sell, how we sell them and how we support them, we know the impact on our back office, reporting, invoicing and accounting systems. And vice versa

Yes owning the whole stack is expensive. But we also have parts of our company that rely on ERPs and other similar products.

I can tell you very clearly that our ability to develop products is an order of magnitude faster and cheaper than those relying on an ERP.

And for those who wonder how hard can it be to understand those accounting standards, this is what a typical accounting standard book looks like:

https://www.pbookshop.com/media/catalog/product/cache/1/imag...

This thing will definitely hurt your foot if you drop it.

So your point is basically that everybody should keep using badly complicated software forever because they're not that special and what they really want anyway, is beyond their mortal comprehension.

Seriously though, how do you envision a future where a leaner, better coded alternative appears?

Also honestly, why are you being so defensive about it.