3 ms·
I think that's the right question that gets at the heart of the ERP mess, but it doens't have a great answer. In theory, you should be able to have your softwa
by jrochkind1 3y ago
I think that's the right question that gets at the heart of the ERP mess, but it doens't have a great answer.
In theory, you should be able to have your software support the workflow that works for your specific organization, business, and context. Rather than having to change your workflow to what the machine demands as universal. The latter seems really inhumane.
In practice, it never seems to work out very well. Does _anyone_ like their ERP and it's implementation?
These products are designed around being customizable -- if they gave that up, they'd be much simpler products, which means they'd probably work a lot better (for what they are designed for, which may not be what you need, which is the problem), and be a lot cheaper (which is not necessarily in the interests of the companies that sell them -- the complexity is fine with them, as long as they can keep charging for it, including with their consultants).
It almost makes me wish yo ucould do things without software at all -- but that's a disaster too, this isn't 1970 and pretending it is doesn't work.
There's really no way out. We've built a society where you can't do this without software but the software that would be _good_ takes more skill and resources than society can possibly afford.
- kodah 3y agoThe alternative is to build purpose built software, but that would require this municipality to pay SWEs (among other folks) directly. An interesting case study would be if it were actually cheaper in the end to just employ some software engineers and write something catered to themselves.
- jrochkind1 3y agoYeah, I don't think it would be any cheaper, or any likely to meet success. Succesful software development is hard, whether you hire a consultancy or are a non-software company trying to create an in-house department. Software around workflow (an ERP) is one of the most challenging areas. Because it is hard to shoe-horn it into a universal pattern, or figure out what a given organization actually needs (not always what they say they need). To do it in-house succesfully requires a level of healthy functioning in the organization as a whole (to be able to figure out and decide functional requirements, to prioritize, to give engineering the environment where they can be succesful, etc) that few organizations have. And with current software engineer salaries (and UX designer, product manager, etc), even if all your cards are in order for success (very rare), few could afford it. It am confident it would not be cheaper than the big ERPs; you'd hope it would at least reliably end up better/less bad than the big ERPs for the cost, but I'm not confident of that either.
- candiodari 3y agoGiven that Oracle ERP licences start at 100k per year for small-to-medium companies, NOT including hardware or let's say 2 years of consultancy to get it installed in the first place. Big enterprises pay a lot more and will have to maintain all sorts of operations folks anyway, so I'm pretty sure you could have a team of, say, 5 SWEs for less than and ERP system. Especially for less than Oracle. Also there are at this point plenty of open source ERPs you could start from.
- nradov 3y agoCome on. Paying SWE salaries is only a tiny fraction of the cost of building, implementing, and maintaining a custom ERP application. The complete lifecycle costs are enormous even if you use an open source product as a starting point.
- candiodari 3y agoAnd yet ... every ERP installation I've EVER seen is a custom ERP application, with maybe a standard "big" database at the center (not in the case of Odoo, or MS Dynamics that use standard non-ERP databases, or at least databases that don't usually work in ERP systems, so ERP without a big database in the middle exists). These were developed by teams of consultants and maintained by multiple teams of sysadmins, SWEs, DB admins, ... The supposed extra features are usually 20-year-old disasters. For example, one thing they all have and are very proud of is a standard UI system. That means the "same form" works on Windows, on the web, on phones (these days), with a centralized auth provider, ... Except to say that ABAP GUI sucks is like saying first hammering a spike into your own skull and then having it pulled back out by a bull is a suboptimal experience. The question that joke screams "why would you do it like that" is one you'll be asking a lot when using these ERP systems. In case there's any doubt: their UI most definitely does not really work on mobile without extensive changes ... also known as "development". And yes it's been improved and is better. Which is to say at one point I believe Oracle had a "mobile UI" which was an android "RDP client" (sending screens pixel by pixel) connecting to a windows server which ran the windows binary of their UI. Even required per-user windows licences. I don't know how they did it, but it actually had windows 3.1 style scrollbars on the phone display. These are improvements in the sense that HIV is a big experience improvement over gonnorhea. And you might think "surely that means the form is going to be very responsive !". Heh. These installations require DB admins, require SWEs, require managers, oncall, ..., require colocation/dedicated/cloud costs (may God help you if you're paying cloud prices for your DB, and whilst I agree admin is easier it's not so much easier that you don't need a DB team). Oh and I've never seen a SAP ABAP installation go 6 months without a consultant getting hired to solve some issue the company couldn't solve. Just about the only really unique thing about ERP software is that the code for the "applications" lives in the database itself (MS access, or Dbase used to do that too). This is also just about the worst thing about them, as it means you don't get integration testing, or standard version control, or files, or ... Yes, I know, somehow Oracle has convinced every MBA to do this rather than pay 5 SWEs to just make them PHP apps. And no, I don't mean those PHP apps will be worse, they'll be way better. It's standard so you can get consultants to attempt to fix the worst disasters.
- jsty 3y agoBuilding internal replacements for the subset of functionality you use would be less than half the battle. Convincing your auditors that those systems were representing your financial position correctly would be hell on earth. Like them or not, auditors know SAP, Oracle and the like - and have well-defined processes & experts to certify them. There's large amounts of risk and cost on both sides of the equation.
- rhaway84773 3y agoIf you built a team that was good enough to build a custom ERP for your municipality, you’ve built an ERP company. At that point you’d might as well compete with the likes of Oracle/SAP yourself, or the employees themselves will probably start their own startup to do so.