Comment by endymi0n | Hacker News Reader

Comment by endymi0n | Hacker News Reader

Parent Full thread

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.

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

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

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.

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

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.

The key insight in what you wrote here, "(biggest client just saw our tooling stack and told us we're 10 years ahead of the ad agencies working in the same space)", is the word client.

If you are going to build your own ERP software, make sure that is the product your company is selling. The same goes for building a new 'web framework' for your web company. Never build a complex product from scratch if that isn't going to be your business. It never works out, because when you have to choose between revenue and improving something in your framework, you'll going to have to chose the former.

Years later, your company, if it is successful in doing what its supposed to do, is going to be paying big $ to retool and replace what you have built. The 2010s were the decade of teams replacing the custom shit they built in the 00s.

Well, Django is a success and was done by a newspaper.

And how many dead and moribund frameworks are out there for each Django? I'd say probably something between 10 000 and 100 000...

Full ERP? For what size organisation? I expect the finance team are using a 'real' ERP behind the scenes and posting the values from the custom system manually every month, copying and pasting from it almost as if it was an old fashioned day-book.

> I expect the finance team are using a 'real' ERP behind the scenes and posting the values from the custom system manually every month

Exactly this.

At a prior startup years ago, I noticed that the accounting & finance team was always in the office late along with the engineers. I would ask them to show me the spreadsheets/models/forecasts they were working on and how it all worked because it seemed so important to the CEO & CFO.

I casually commented I could build this more effectively in code, and a half dozen people laughed at my joke. They then sat me down and showed me things like journal entries, how deferred revenue is managed or annual subscriptions are recognized. There were dozens of examples of scenarios that were completely unique from each other and required tools to allow them to capture these things and roll them up into a consistent P&L and income statement, balance sheet, and cash flow statements all adding up nicely.

And you realize that it's completely impossible for a company to capture all of this correctly "in flight", and things are going to be messy and wrong. ERP's have decades of experience capturing the nightmare that is actually managing a business and it's not sexy, but it works better than most alternatives.

> it's not sexy

which is easily made up for how condescending you get to be about it.

Reply on news.ycombinator.com