Does ERP really need customisation? That seems to be a big cost driver as well as causing lock-in.
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.
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.
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.
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.
I think it actually requires the organization to morph into being a tech company first. In order to have good software to run a City Council, it effectively requires the Council to become "a software-making organization that delivers council services". In order to have good software to run a bank, it requires the bank to become "a software-making organization that delivers banking services".
Unfortunately, it's both politically difficult (nobody goes into any type of non-IT activity because they want to work with software) and really challenging: not even IT organizations have figured out the best way to address problems like technical debt, language churn, documentation etc, and non-IT organizations face them just as much.
I don't actually want my city government to be a "software-making organization that delivers government services".
Every organization needs an ERP (maybe?), but not every organization that needs an ERP is or should be a software organization. Saying that in order to get a good ERP every organization has to transform itself into a software-centered organization... seems a bit much.
Its mission is to deliver council services, but if the best way to do that is through efficient IT (and in this day and age that's pretty undoubtedly the case, since most communications are pushed via websites, payments are made via automated systems, etc etc), then the organization should definitely pack the necessary skills and organizational tools to achieve efficient IT first and foremost.
> I don't actually want my city government to be a "software-making organization that delivers government services".
Let me understand this.
You want your city government to overcharge you on Council Tax because they didn't see the form you filed two months ago about being a single occupant.
You want your city government to miss your bin because they actually performed the collection one day earlier than usual and didn't alert you in some way.
You want your city government to be at the mercy of unfaithful civil servants who abscond with money by applying dodgy accounting.
You want your city government to dig themselves into massive financial holes because their planning and forecasting software is subpar.
You want your city government to be unable to analize expenses and contracts to identify where they're getting gouged.
You want your city government to ignore complaints about this or that item, since they can conveniently forget to file them when people call.
These (and more) are not hypotheticals - this is what goes on in many (most?) local authorities, today like yesterday, and it's all stuff that can be fixed with software by organizations with the right skills and attitudes; but they require putting software (and people who know how to make software) at the heart of "how we go about doing things".
But services provided by IT are only one part of what I expect my local municipal government to be able to do competently, and not necessarily the great part. While I would like the services provided by IT to be done competently (ideally beyond competently), it does not necessarily follow that they should be focused on to the exclusion or de-prioritization of things that are not IT, which it seems to me would be the consequence of the local municipal government reorganizing itself and considering itself as fundamentally and mainly a software engineering organization (or an IT organization in general, which is not necessarily the same thing either).
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.
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.
You can run your business / org exactly as the ERP designers envisioned, but that means you'll have to adapt to your ERP, which is wrong-headed and certainly much more expensive in a large org.
Even the most vanilla implementation for a small business will have a degree of customization.
Bingo. I'm not going to tell my CEO to change how they run the business just to conform to how the lowest-bidder ERP decides I should do things.
Unless it's ServiceNow, for some reason.
Yes, for a number of reasons:
1. An ERP system consists of thousands of modules, out of which a smaller subset is needed by the customer. One typically pays by module so you want your number of modules to be as small as possible.
2. A customer this size has already implemented a number of business processes that they are not willing to sacrifice, even though an ERP provider will do their best to have them import "their" way of doing things.
3. Customers want to acquire an edge, not be on the same level playing field as the competition. "Kill you darlings" - eh, no.
4. If a municipality buys an ERP system tailored to manufacturing/trading, well then you have substantial customization ahead.
Birmingham City Council doesn't have competition.
But they may have specific municipal / local / state / national rules to comply with in ways that commercial entities do not.
These differences imply customizations.