Yeah, 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.
The problem is if you knew enough about your business logic to plan out an ERP system beforehand, you wouldn't need an ERP system to begin with. The main benefit of either buying or building an ERP system is that it forces you to actually find out (or decide) what the flow of information in your organization is. It's a management consulting process that happens to play out in software.
> To do it in-house succesfully requires a level of healthy functioning [...] that few organizations have
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 mean, not only is it politically difficult, it's probably not appropriate for a City Government to organize itself primarily as a "software organization" -- that's not actually it's mission.
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".
I don't live in a country where it's called a "Council" and operates like a UK local Council, so my units of city government and their roles/functions might not be the same, and that may be a misconnect in this conversation.
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).
And over time that custom software would inevitably expand to be as large and complex as Oracle ERP, but lower quality. As bad as some vendors are, organizations that lack a core competency in software development are even worse.
Given 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.
Come 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.
And 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.
Hm, your direction of comparison between "100K" and "a team of 5 SWE's" seems off. Also, you're going to need some non-SWE staff involved there, some combination of people providing product management, project management, UX design, and user research/contact.
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.