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.
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.
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.
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.
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?
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.
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.
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.
https://www.pbookshop.com/media/catalog/product/cache/1/imag...
This thing will definitely hurt your foot if you drop it.
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.
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.
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.
which is easily made up for how condescending you get to be about it.
Here is the interesting excerpt on Google decision to buy Oracle instead of building their own ERP.
"__ How did you convince them that you needed to do this? __
Well, it was actually very interesting. Larry and Sergey suggested that we should build our own, because most of the existing accounting systems weren't any good. And I said, "I'm sure that's true, but you'll never get it audited," And I thought that was a pretty clever argument. The auditors would never pass financials (generated out of software) that we built ourselves. And Larry and Sergey today will complain about the Oracle system, but they'll also say "We had to get one that was auditable.""
It's the other way around. It's totally irrelevant to re-invent the wheel and do something in a non-standard way.
> I’d rather my auditors had to hail their dreaded IT departments
That's not how auditing works. The point of GAAP is that things are done a certain way, and if you do things differently you need to provide that it isn't bullshit. Otherwise Enron & WorldCom all over again.
This is exactly expected and a desired outcome in a vast majority of scenarios. These jobs/roles are not snowflakes.
It's not a desired outcome at all.
The "not snowflakes" good people leave, and the ossified ones who really just keep their head above water and need the job, are what you have to deal with. And they have the exact same attitude to succumb to the system or else you're SOL.
I really truly think you do not understand.
It's rare but I know from first hand experience that it can be different.
Totally. My clearly poorly researched comment and seemingly lack of knowledge on the subject clearly reveals me as a fraud. You got me.
You've been sending replies to my old comments for the past THREE DAYS, and then editing and deleting them. I got "HN Replies" enabled so they do end up in my mailbox even if you edit or delete them shortly after. So I do get to see EVERY TIME you wrote me in the past couple of days that you believe I am "not qualified to have an opinion. full stop". No discussion, no arguments, not even trying to engage what I said, just attacks telling me over and over how much better you understand SAP. Just attacks or stating your credentials. Which is no discussion but I don't care any more, I want you to knock it off, now.
At this point I honestly don't care what your opinion is on ERP, that you're the Queen of SAP, or whether you think I get to have an opinion or not. You deleted that remark, but it was the straw. I just want to cease communicating with you, which I did from my end already nearly a week ago.
Now I understand when sometimes people post while in a bad mood, causing them to post things they regret. And if you delete those messages, then that is fine with me. But what I'm a little bit worried about, is that I got to wake up to a new reply from you, telling me how stupid I am and that I don't deserve to have an opinion, for the past THREE DAYS. That's not a bad mood. And I don't care what it is. Just let it go, alright?
Please don't reply to this comment with anything less than an apology.
Hate to break it to you, but there’s other countries and other regimens out there.
> Hate to break it to you, but there’s other countries and other regimens out there.
Which country are you from that it doesn't have Generally Accepted Accounting Principles? Are you saying that in your country every company can make up what they want and the authorities are OK with that?
This was my hardest lesson to learn. Code is only as good as the domain knowledge going into it. I love games because the domain is more often than not in the realm of fellow programmers and erudites like mathematicians and 3D animators that capture their domain knowledge in physics, sound effects, motion capture, fluid dynamics, FSM AI, or combining geometric and linear algebra to improve gimbal lock.
An ERP on the other hand captures the domain of accounting, finance, procurement, manufacturing (bills of material), order management, taxes, product lifecycle management, and other considerably less sexy but equally important subjects.
let me guess, they did not captured/predicted the domain knowledge required to run the following business huh: - search engine (google) - marketplace for arranging or offering lodging ( airbnb ) - ride sharing ( uber ) - social networks (twitter/facebook)
if all businesses does everything the same way (because some german company thinks it is), all end-products will look all the same. The same way if all chefs is following the same recipe.
IMHO the tools/choices to send invoice, manage orders, product lifecycle can also be a differentiator for your business.
It's more like chefs using the same kitchen appliances, pots, pans and equipment as everyone else. And they do. You use a Salamander Broiler because it does the job.
Tesla makes hell of a great cars.
“excellent corporate governance” could be rather irrelevant.
I don't know what many of the terms mean you name, and I severely doubt that every business (or most) does. Doesn't mean they're not important, but most definitely just firing off a bunch of random terms fully expecting people not to understand most of them, is a weak way to prove a point.
I have seen however on the consumer side what happens when businesses "changes the business" to fit a particular piece of business planning software that is "Hideous. hideous". You're working with nice people, well-meaning people, doing their best for you the customer. And it everything well for a while and you place your trust in them. But then walls appear. And appointments get rescheduled. And they want to help you but they can't. Some people leave, a particular kind of person stays. Communication between peers grinds to a halt. If something goes wrong, they can't pick it up so it falls on you the customer to deal with or reschedule (or other inconvenience), every time. You want to get angry at the people, but you also see they are so very much doing their best, but something is holding them back. A particular kind of person is particularly good at merely keeping their head above water and not suffer the burnout many of their ex-colleagues did.
I'm not saying that it can't work well. I bet it's great when it works well. But when it doesn't it's a silent killer.
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).