Local governments aren't businesses – so why are they force-fed business software? Fill in the blank: "_______ project fails, costing millions." Five points if you chose "Government IT," five points for "Oracle," and a gold star if you had both. That Oracle's local government ERP project for Birmingham City Council is now in nine-digit overrun and doesn't work is news because of its size and contribution to …
Shouldn't the contract state, that if vendor is unable to provide the goods/services, vendor will not be paid, and op top of that will have to pay compensation for wasting everyone's time?
What are all the lawyers for, when this sort of thing isn't handled properly?
Quite often the issue with cloud services from the big ERP providers is that they do provide the goods and the services but they are just not fit for purpose. Then the wrangling gets into whether that was required by contract anyway. At its most simple you might specify that there is a payroll module that can process payroll for a large organisation to the satisfaction of UK law and the needs of the business. However, there will be lots of wrinkles in the reality of this in the public sector, eg hourly paid staff who aren't on contract, volunteers who need expenses, etc etc. This is a simple example, but what happens is that the the product does payroll, the service delivers the capability, but it doesn't meet the needs and that is for litigation. However, when you are a (say) a local government organisation or a university (which have similar experiences with ERPs - take a look at Edinburgh, Nottingham and Manchester) you dont have global networks of lawyers at your disposal and you dont have a hundred of thousands in cash to fight the case, even if you do its taxpayers money which taxpayers dont like being spent on anything that doesn't directly benefit them. Oracle or SAP on the other hand, do have the money and lots of specialists in this area. so they nearly always win.
We all wish it could be that simple. Most likely, Oracle provided exactly what was defined in the contract, and the problem is that what was defined in the contract is not what the customer actually needed.
The problem here, in turn, is that the customer is unlikely to be proficient at defining requirements, while the people who are actually good at that are (1) not proficient in the customer's domain, and, worse, (2) on the side of the seller.
This is a recipe for disaster. There is ample room for miscommunication, and that room is basically an enemy killbox. The contractual requirements will be too vague or outright bullshit, providing little grip for the customer's lawyers; the marketing people will reassure the customer - verbally and informally - that everything is exactly what they want; and there is nobody on the customer's side who has the skills to sniff the bullshit.
I'm not sure how this could be prevented. An idea could be for the customer to hire a third party whose job is specifically to do requirements analysis. This would be a consultant who is good at figuring out what customers actually want and turn that into requirements, at explaining that to the seller in such a way that they actually understand the requirements, and at expressing requirements in a contractually binding fashion.
None of those skills are actually easy, so this would be expensive. Though nowhere near as expensive as finding out a whole slew of additional requirements only after deployment. You would be able to know that such a figure is good if the sales team suddenly goes quiet and starts sweating when the consultant enters the room.
"The problem here, in turn, is that the customer is unlikely to be proficient at defining requirements, while the people who are actually good at that are (1) not proficient in the customer's domain, and, worse, (2) on the side of the seller."
One solution might be a rather old-fashioned one: stage the contract with different deliverables, the first being to analyse the customer's needs. There's a risk of the specification being gold-plated but the advantage being that if the specification turns out to be inadequate the supplier will only have themselves to blame.
"...the first being to analyse the customer's needs..."
That would be helpful, but as mentioned briefly in OA, the needs for local authorities are dynamic.
The reporting requirements will certainly change as national government policy changes, and as other upstream local authorities change their demands.
And those reporting requirements are much more detailed and cover many more aspects of the corporation than for a purely commercial entity of comparable budget size.
The problem is that the client isn't very good at knowing their requirements. It's not just defining them properly or not, though that can also be a problem. I've experienced this a number of times when someone made a request to add something to code I manage. They aren't great at specifying what it is they need, but even when I ask them questions, they only supply some of the details I'm going to need before I can make this thing. The reaction to this varies. In some cases, I know enough about what they're doing that I can guess what they need to fill in the blanks and it comes out close enough to what they're thinking that modifications are slight and mostly cosmetic. In other cases, I'm told to do exactly what they said, whether I think it's a good idea or not, which often leads to the system being subpar for most of their needs, in some cases so misaligned that they don't bother using it or they use it in a very different way than it was originally proposed.
Keep in mind that these are, in most cases, stories of people working at the same company I am who have asked for something and who can ask for code changes by sending an email, and it still ends up like this. Governments are in the worse situation of specifying their needs to some other company, not the developers directly. The developers won't be given the option to guess at any ambiguous parts of the system because it would make it harder to prove that the supplier had completed the contract, and it wouldn't help if they had that flexibility because those developers don't understand what local government really needs. Meanwhile, local governments generally don't have the resources to bring in the dev team and let them work alongside all the workers for enough time to gain an understanding of the needs because that would effectively cost as much as putting each of the engineers through training for every job they have. It's no surprise to me that they specify some database and set of forms they think they need and get exactly what they said, but find that what they said has gaps and isn't very flexible when their requirements change. Asking the supplier to write the spec is likely to mean that the supplier has some meetings with a few managers, writes down what they say, and writes a spec with those forms instead. The product will look different, but the quality will be similar.
Won't work. The customer will have to sign off the analysis report in order to complete the first stage, thus taking responsibility if the requirements are wrong. And they will be, because of what I mentioned above.
Just saying, but I've just had one of my customers explicitly tell me "remove all of the following recipes from the database", to which I asked, "are you sure? You're no longer using them?", to which they answered, "yup, they are obsolete", and, a couple of days later, call me with "why can't I find this recipe?"
It was the same person, even. It turns out that by "remove" they meant "replace with another that has the same ingredients, but a different name". How could I possibly understand that? I can fix it, mitigate it, and I do (in this case, recipes are never actually deleted, just hidden from the GUI), but I really don't see any way I could prevent that situation from arising in the first place.
The only way would have been to have someone in the middle who has enough knowledge of the customer's domain and procedures to understand what they actually mean, and enough knowledge of how computers work to be able to express requirements in a way that I can understand them.
In this particular case, having a position like that would be disproportionally expensive, compared to the project at hand. It's easier to just accept that this kind of things will happen; personally, I just factor in my initial quotation the assumption that a bit of this is going to happen, and then I don't charge the customer for it when it does. I have a reputation for high quotations in my field, but somehow people are always very happy with me in the end.
But for multi-million contracts? Bring in the requirements engineer. He'll charge a pretty penny, but you'll save money in the long run.
@Filippo
Quote: "...the customer is unlikely to be proficient at defining requirements..."
So...so...so....twentieth century!! Did you not know that no one does "requirements" any more? Too much work, too much paper.....no....today we do "user stories".....walls full of yellow sticky notes.....
..."Agile"......iterative development.....two week scrums......a "Product Manager" to "represent" the "customer"..................and so on......see the so-called "Agile Manifesto"..............
..................for how things REALLY NEED TO BE DONE.................
Oh...and about the obsolete idea of "requirements"..........the agile folk forgot to tell you that...yes....."requirements" are hard to do.......but at least you end up with something to test against!!!!!!!!
The snag with all that is that public sector procurement is just not set up that way. Its still predicated on a full and complete specification and going to market through a tender process. Its pants, but its law.
The snag with all that is that public sector procurement is just not set up that way. Its still predicated on a full and complete specification and going to market through a tender process. Its pants, but its law.
Makes more sense to build up a team of internal resources shared between multiple local governments. They've comprehensively proven that going to market isn't yielding the best outcome.
Absolutely.
However, there are two major problems:
1. Every country has at least one major political party who is ideologically opposed to the concept of a skilled and expert civil service, often even the very concept of a neutral civil service.
The moment that party comes into power, they start to break up that team by various techniques, such as cross-promoting or even spinning off entire departments as separate private entities, destroying any capability that had been built up during the previous administration.
2. Private companies will try to poach those skilled workers, and will succeed often enough to ensure a "brain drain" within said civil service.
The only way out of this mess is going to be some kind of Open Source ERP, but it'll take a very brave set of councillors with "safe seats" to start that ball rolling.
The methodology is totally irrelevant. ERP projects can almost never be properly specified in advance and are often sold as "customisable", which means implementation will run and run. As will the billing.
A bigger problem is forcing these projects to be put out to tender for everything at once. The way this is done means that the procurement department is essentially sidelined by politics and forced to deal with the fallout once the deal has been signed. So, even if the department is, say, perfectly able to cope with the building of new school or traffic light system, it won't be involved in the planning. In addition, financing these projects is generally more difficult than many imagine because council funding is largely dependent upon central government, which can and does adjust grants at whim. The contractors know this is and make sure the contracts are written to make sure they get their cut whatever.
And then there are the councils such as Woking (and Krefeld*) that decide moonshots are the only way forward and borrow excessively to pay for whatever their friends in the utopia and whalesong development agency suggests, because jobs.
* https://surfpark-krefeld.com/ - in German but the KPI is the proposed charge of "around" € 50 an hour… But the Congress Centre in Bonn and the serial failures at the Nürburgring and Hahn airport spring to mind to show that this not limited to the UK. And, yes, procurement of IT systems is just as shit.
>So...so...so....twentieth century!!
Ah, the twentieth century! That magical period when we had computers, but we didn't have much of an Internet, and therefore you could not push endless updates every half an hour, and therefore your stuff had to at least mostly work upon deployment. Good times.
Systems like this are the one case where I have some sympathy with the Agile people. I have never seen a specification for a system like this that was close to meeting the requirements. A lot of this is because they're still often making monolithic requirements documents when looking for suppliers. Their requirements documents list a bunch of things that are needed, but nothing more advanced than that, and they end up getting exactly what they asked for. If their requirements said that they needed a web form to collect a certain set of information, they'll get it. The supplier won't care that nobody really knows where the form is except by bookmarking an address, that that one input has an annoying JavaScript validity checker that requires you to have a very specific format for something whereas another has no validity checking at all, and that nothing very useful happens with the form after they click submit because the person who focused on the system wrote about the part you see and didn't think very much about the part you don't.
When it comes to requirements checking, they'll be able to tick every box. Does it have the following forms? Yes, it does. Does it accept all the valid input examples? Yes. Does it reject the invalid ones it was told to? Yes. Does it store the completed forms in a retrieval area for the government workers? Yes, using a table which is effectively the raw output of "select * from" reformatted for HTML. Does it let those workers delete old forms, add comments to ones in progress, and send them to other groups and people by address? Yes. Does it take the forms and automatically figure out which office they need to go to, which follow-up step is required, automatically send that to the requester and notify the specific handler afterward, features that would save the government hours of administrative work? Well the requirements document didn't say that, so of course nobody wrote that in. Does it use a standardized format for these documents which allow someone to easily script such a process later? No, because the requirements only listed a bunch of activities that were needed and allowing each engineer to define whatever data structure they liked for the bit they were working on made development faster and completely broke any ability to interoperate.
Problem is (as others have alreeady stated in other comments) that while Agile might actually work and deliver (or at least do a better job of trying), the public sector is hamstrung by a legally mandated procurement process that all but prohibits it. Procurement process is often so long and complex that central govt. will often have changed colour and changed what local govt. is legally required to deliver before the project can even start.
A requirement of: displays report with metric X (defined as sum of records Y) and ability to filter by a, b, c
vs
User works in department D, and is responsible for providing reports on constituents, for example existing reports are {blah blah}.
To me, a user story is an overview of business requirements. Much better than technical requirements. Give me business requirements, I’ll give you a technical spec I think will cover it and an estimate. We can then prioritize and work on technical features.
Why the fuck should users define requirements, it’s utterly bizarre. Working with people like this is like working with a bunch of Vogons
Sorry @Filippo, but I really disagree. At least in he US, Oracle is selling big into healthcare delivery networks. I might or might not have some first hand knowledge of this.
Anyway, I believe that Oracle is fully aware that their product is seriously lacking many of the features needed by healthcare delivery supply chain (again, may or may not know a thing about this too). This is evidenced by the rudimentary functionality requests, and Oracle's often clueless responses, that you will find on their Community "Ideas" portal.
I think Oracle sells a reasonably solid HCM system, but they also know they've got to sell the other two legs of the stool: Finance and Supply Chain. The trouble is, SCM (and more than a few of my peers in FIN) would argue that these two "pillars" are decades behind their best of breed competitor solutions (i.e. the "primitive" solutions that we have to rip out so that we can make way for a "cloud based digital transformation").
Oracle knows they are selling many of their customers a time machine to the past, under the guide of a spaceship to the future, and they are absolutely not going to come clean in meaningful ways about this.
This is the sort of thing that agile methods are supposed to address. You do a little bit, get very quick feedback from the client and repeat until the client runs out of things to ask for. Wonderful in theory...
The problem with agile though is that whilst its great for brand new application areas its very hard to apply to large existing systems. You really need the little fragments of new code to run alongside the old stuff whilst you migrate. This potentially takes forever because there are always a few niche bits of functionality left that are needed once in a blue moon that you never get to. You either need two backends that you reconcile frequently and import/export between them (nightmare), or more realistically all you do is migrate your presentation tier. This is why banks and airlines still run on ancient platforms but have sort of shiny, modern interfaces.
What we have here, a platform migration, is a world of pain on a whole different level. Its a leap of faith into the unknown.
And what a lot of organisations don't get is that there is really no commercial benefit in a platform migration (realise this article is about the opposite of that non-commercial enterprieses). You can't exactly rock up to your customers and say, hey we implemented a new platform, you should pay us more. If the platform facilitates stuff you couldn't do previously then that's something you can sell, but the platform in and of itself is not the product. And *always* the new platform will start off *less* functional than the old one because you'll miss stuff and it will take time to shake-down and mature, on top of the months and years you have basically been treading water waiting for it to arrive. So you fall behind and then actually have less value to sell for a period of time, sometimes indefinitely.
Platform migrations are a terrible idea. You should really just find a way to fix what you already have.
-- This would be a consultant who is good at figuring out what customers actually want and turn that into requirements, at explaining that to the seller in such a way that they actually understand the requirements, and at expressing requirements in a contractually binding fashion. --
Would you like to buy some unicorn droppings? A CONSULTANT!
Having worked with central and local government (UK and Europe) I'd say that they aren't more complex than private enterprises but they are a lot less well organised. Fixing that feels like running through treacle and while there is opposition from some of the workforce the majority of the "treacle" comes from politicians, either through constant meddling or wild swings in requirements, or lack of budgets (things abandoned partly finished)... the list goes on.
Installing any software against that background is a recipe for failure... but I would also add that I've seen many projects fail when software has been bought and the "business" insist on working as they always have and make IT create a spaghetti of customisations. In my opinion, you either accept that you're going to have to work the way the software expects with minimal customisation or you're better off writing your own software to do exactly what the business wants.
There's also attacks from certain members of the public on how DARE you spend money on bloodsucking public sector workers. We regularly see one person in our area harping on that most of the council's budget is spent on wages. WELL DUH! The person who cuts the grass costs more than the lawn mower, what do you ****ing expect?
> What are all the lawyers for
Employed by the businesses to either
a) make sure that exactly such passages never make it into the contracts in the first place
b) weasel the corpos out on the off chance that they do
c) ensure that the requirements are written in such a way that the contractual obligation is somehow fulfilled even if the product is non-functional
Oracle et al is what they do when they need better commission rates.
+ local govs and their ilk have a really bad habit of "kitchen sinking" their specs, much to the aforementioned sales wallah's glee as it lets obfuscation and misinterpretation flourish like weeds on a path.
Grease a few palms and legislators will do whatever you want.
Public money should yield public code, but it rarely does. And no, "public code" (by which I mean Free Software) does not in any way prevent a private company from making a profit writing, hosting and/or supporting it.
We all know how hammers and pliars work, yet we will still hire a plumber/sparks/whatever. There skills beyond the tools.
To me “public code” is where the source is available to all with no access qualifying precondition - remember the issue with RedHat and “free software” is that the licensing model only requires distribution of source to customers ie. Public code is freely open source not just “free software”.
I live in Brum. In the enterprise space they aren't doing anything that needs the nation-supporting grunt that Oracle claim to be.
But they managed to spunk £10 million on a bespoke CMS system that a team of 10 could have delivered from any number of FOSS options.
But what would you expect from a bunch of cowboys who send out both parts of their "2 part secret code" in the same letter ? Every year I raise this, and ever year for the past 10 years I have been told "no one has ever mentioned it before".
a team of 10 could have delivered from any number of FOSS options
I suspect you are probably right, and maybe a script-kiddie in their bedroom could do better than what often is achieved.
But who's going to risk that when no one else does, when the usual suspects who ultimately get to do it have a vested interest in insisting it will be too complicated for anyone but themselves, that only they can and will deliver, when everyone else falls for their bullshit.
The false logic that they couldn't possibly fail given the eye watering sums they are charging, that anything else is too risky, usually wins the argument.
I'm no fan of Oracle, but I don't see why a council's needs for an ERP system differ hugely from those of a commercial enterprise. Brum's needs don't differ from those of a chain store more than those of a chain store differ from a construction contractor. Because accountancy rules are the same for all (debits still go in the column nearest the window).
Large commercial organisations are equally capable of screwing things up, but the difference is that when they do, heads (OK deputy heads) will roll. This never happens in government.
Like many things the real problem is they overcomplicate things. WHy spend $20M and now 5x or 10x that amount when you coul dhave had some staff work from home ? Theres almost always a simple, less fancy solution that works significantly better than taking a risk and spending tens of millions.
Reminds me of stories where the public service gave someone a job to manage the hand out of pencils and pens. Sure they are saving money on those stationary items but they are paying 100x more on a new useful staff member.
Unfortunaely the council will have no choice but to spend £10,000 a year monitoring the pencil distribution. Because otherwise the Daily Fail will be running a story that StixBorough Councill is wasting hundres of pounds every year due to poor pencil distribution control.
Local Government cannot be run like a commercial enterprise, as demonstrated by attempts to do so for over 30 years. TFA describes the only possible outcome.
To solve this problem, a bespoke platform is needed with literally NO involvement from the likes of Oracle, SAP, ICL, etc. Source: 20+ years in a Local Authority trying to run like a commercial enterprise. In all that time, the ONLY software that did what we needed, we wrote ourselves.
Local Authorities follow the Code of Practive on Local Authority Accounting issued by the Institute of Public Finance Accounting.
Yes the debits and credits are the same, but there are a lot of additional requirements that don't apply to regular commercial companies.
Things like how to deal with restricted funds, how to deal with assets purchased using restricted funds.
For example, if you were to get funding to replace crumbly school roofs, you can only spend it on school roofs, not on anything else. There will be a time limit on how long you have to spend the money, or you have to send it back. Then if you were to sell the school building in the future, its value might have increased as a result of it having a non-crumbly roof and there will almost certainly be rules that state it must be used to buy or build another school building.
Re this comment "But freed of commercial secrecy and competitive distrust, state agencies are free to talk to each other and build ideas together – in fact, that's essential. ", there is a precedent for that. National Statistics organisations (such as the ONS in the UK) tend to have unique requirements looked at nationally, but a lot of commonality with each other internationally. So there is a lot of collaboration on standards setting and sharing of open source material.
The challenge for local government is finding ways to promote that collaboration and turn it into implemented solutions in what is frankly a very cash constrained environment.
Local councils can be seen exactly as businesses. Their Chief Execs are the landed gentry or factory owners and their raw materials are the electorate, the work done my employer labour or outsourced to the cheapest or most convenient friend, and they make a lovely return from their estates for their personal aggrandisement. The forecasts and other financials are worked out much the same on a spreadsheet as for any other business.
Do even the council departments who contract for these systems realise how far they are from a standard business?
A local authority's central staff- in my experience- seem to think that all their employees are in a place of work, on a regular pay scale, doing a job at a desk or some equivalent. In reality, they may be working irregular hours in irregular places on a whole range of pay and conditions (teachers, social workers, peripatetic music instructors, care staff all sorts). With legal requirements for dozens of different professions. Teachers have to do different statutory training from health care. And so on.The LAs seemed to struggle to understand that a small team of peripatetic teachers might have different print, photocopy and network needs to a small team of admin staff, for example.
Sigh, working in this area right now - who knows. The majority of what we've been able to prise out of the business is "it's too complicated and you wouldn't understand" but to be frank the more we dig the more it begins to look like "it's too complicated and we don't know how it works but if we don't touch it we'll be fine" (cross fingers and sacrifice chicken).
I think you are right, the biggest challenge for software is not AI/ML or that other nonsense, the biggest challenge is
"POORLY UNDERSTOOD SYSTEMS".
The answer seems to this seems to be emulate the operating system and transfer the whole thing onto a VM.
We have come to a time when we just don't understand what we work with anymore.
That's terrifying from a risk point of view, something vital breaks you just go out of business.
I wonder is it arrogance of the intellectual/philosophical sort, "I know all that there can be known" sort of thing.
There seem to be two distinct groups here, one parasitic on the other.
There are the prime contractors, of course, and then the consultants and other intermediaries who have not only the initial job of "tailoring" the system to the client's needs but who will in reality have wrested from the client any possibility of making any future changes themselves and between them they effectively have the client hostage.
I once worked at a public sector organisation that had been using a popular ERP system for several years. Even at that stage it wasn't possible to submit a timesheet because noone knew how to update the cost codes to which work had to be billed. Every week we'd get an email reminding us our timesheets were overdue and every week they were rejected. Fixing it was somewhere on the backlog of thousands of higher-priority changes over which the external consultants were dragging the heels of their Italian loafers. Even the error messages were still in their original language.
But these procurement decisions are not made by people who understand the business of the organisations they work for or who are even remotely curious about it. That's, in the end, by far a bigger problem.
This isn't all the vendor's/ERP's fault - there's a lot of responsibility incumbent on the government client, who regularly and consistently fail in their due diligence to engage with a contractor and spend public moneys wisely.
Ensuring governments at all levels have adequately skilled and trained public servants (or at least a "significant project" review by a national agency tasked with ensuring local government projects have a chance of success) would go a long way to avoiding these nightmare implementations.
This post has been deleted by its author
"Local governments are never that model enterprise. In fact, they rarely resemble each other. They have to provide a huge range of services without much control over revenue, their metrics of success are as varied as the communities they serve, and they have the huge pudding of legal responsibilities that comes from spending public money."
I wonder. The legal responsibilities are defined. Admittedly we have a strange way of slicing up the responsibilities between tiers in different ways in different parts of the UK and the devolved governments will have come up with their own ideas for additional responsibilities. Nevertheless the statutory duties have to be performed at some level.
It ought to be possible to write a function to implement each of those responsibilities. The different structures could just mean that the top tier here runs the function that's handled by the bottom tier there. Providing that the software is structured so that the total functionality can be allocated as required it ought not to be a problem provided it's designed that way.
It should be possible to have one or preferably two companies providing a modular applications suite for the core local government functions and central government mandate that they use one of them.
I'm sure one of the problems is individuals building their own little empires - Bob always handles street repairs but Alice is responsible for utility permits to dig up dig up roads except for gas because Fred's department inherited that from the municipal gasworks. It may well be that the a lot of the customisation requirements arise from just that sort of internal slicing. A mandated application suite might sort out a lot of that - optimise the responsibilities to fit properly structured software rather than pay to have the software customised to fit the egos of the departmental viceroys.
And handling those one-off huge capital projects? Well, do they expose taxpayers' money to excessive risks? Are they really things local government should be doing? That's a matter for which software support is a secondary consideration.
"I'm sure one of the problems is individuals building their own little empires"
Gawd. In a previous life I've had: Education renting out council housing because the houses used to be school caretaker's houses; parks run by housing because they demolished some houses to make the park; roads maintained by parks & leisure because the road cuts across the park. This grass verse is cut by highways, but this grass verge is cut by parks, but this one by education, this one by housing, and this one by somebody else. Any attempt to tidy it up is stymied because each department won't let go of its responibility without being paid to let go of it.
Any attempt to tidy it up is stymied because each department won't let go of its responsibility without being paid to let go of it. budget
Partly because somehow budget changes always seem to involve taking away more cash from one department than the function required. And giving less cash to the other department than they need. In other words, Department A will lose £1000 in costs but have its budget cut by £1500 because of some supposed additional savings that no one has ever been able to identify. Department B will only be transferred £700 in extra budget because of a new evaluation by Finance that no one has ever seen broken down. £800 will be added to the budget of some totally different department, that happens to be in favour with the higher ups.
This is in line with the underspend/overspend paradox that used to get me so angry ( actually still does and I've been retired from there for years). Manager A will carefully plan a budget so that there is enough money to last until the next financial year. Manager B will simply have no budget controls at all and run out of money two or three months early. (B is rarely running a frontline service, by the way).
Two months before the end of the financial year manager A will be told, "You still have money left, obviously you don't need it. But department (of) B does". And the money will be clawed back. If manager A is really lucky he'll get a 10% reduction in the next year's budget too, because "Oh you didn't spend all yours last year".
This is anonymous as I am working for an organisation that makes increasingly heavy use of an Oracle cloud based system, and is increasingly integrating all admin functions into the one system. And, apart from this system, I really quite like my job, and wouldn't want to be penalised for saying the wrong thing on line.
We bought in an Oracle based system a couple of years ago. Initially for HR. It was incredibly slow, often taken 2 or 3 minutes to switch to a new page (this is on a gigabit wired network, and a network connection that is considerably faster and on a recent core-i7 based machine. In short, the delay was not on our end.
They did sort that out, when they started integrating other functions into the system, such as procurement..
Now, the system is reasonably fast, but missing an awful lot of functionality that was built into the systems it replaced. Maybe that will be replaced? I don't know. Doubtful, as the feature set of the system hasn't really changed in a last year or so, so I suspect it's relatively stable now..
Same Anonmymous Coward here..
A couple of years ago, I was talking to a friend. It wasn't about this specific system, but I raised concerns about our increasing use of cloud, and how the way we were operating we were putting all our eggs in one basket. I was shushed, and told we don't talk about that..
So this is the whole cloud vs on prem thing, in the same way cleaners etc have been outsourced for years. Essentially it’s screwing more money out of the customer by selling XaaS. Our cleaners etc just change t-shirts every supplier change. It takes a year to tender, for what? A senior manager was fired for daring to suggest outsourcing has has its day and is hindering rather than helping. Same with cloud; no real uptime assurance, no real backup guarantees (I’ve recently realised that with OneDrive and it scares the woollies out of me), and the supplier can and does just change the product as it likes. Capitalism at its worst; sell you snake oil then know you won’t take them to court when it all goes wrong.
All companies get to a certain size and then decide: "Of the thousands of CRM systems on the market, our business is so unique that *none* of them are suitable. However, this one from [insert CRM/ERP vendor here], does most of what we need. In fact, they have assured us that, with some minor customisation, it will do *exactly* what we want."
Software companies are even worse because they say: "We have all these highly paid developers, just sitting there, doing nothing. Why don't we get them to do it? It's just 'software'. How hard can it be?"
Unless your core business is being a CRM vendor, you're better off changing your business to suit one of the many CRM systems. It'll be cheaper, quicker and less hassle.
I have a strong belief that if you are buying a product from a company, you should not pay them to customise it. You should buy a product where you have every API documented, how to use any plugin architecture and you evaluate those, pay for the product and then create an in-house team to maintain it who are loyal to you, so you retain source code and knowledge. I can this the "no salesman will call" philosophy. If I can't enter a credit card on a website I don't want to buy it.
I've done projects with Dynamics and we didn't have to get Microsoft to do anything. We could create custom types, we had custom menus, we had a we service feeding data in. That's how all 3rd party software should be treated. As an off-the-shelf black box that you can also use as a component.
We went through this recently at a university I work for. It worked out in the end, but a lot of damage was done in the process of trying to hammer academic payroll requirements into an Oracle Peoplesoft-shaped hole.
I knew of another uni that moved their payroll off a 1970s IBM mainframe. Just figuring out all the subtle business rules embedded in all that undocumented COBOL code took a long time.
> We went through this recently at a university I work for. It worked out in the end, but a lot of damage was done in the process of trying to hammer academic payroll requirements into an Oracle Peoplesoft-shaped hole.
I knew of another uni that moved their payroll off a 1970s IBM mainframe. Just figuring out all the subtle business rules embedded in all that undocumented COBOL code took a long time.
I remember when my paycheck was a Hollerith punch-card. I will venture to say it wasn't as new as COBOL. Payroll switched to 3-part form printer but the school library was punching cards even longer. (A library does not need a computer so much as a card-sorter, good fit.)
At the turn of the century they finally started trying to rationalize the badly bound-up and non-transparent purchasing system. What a frikking 5-year nightmare. Among other things the user console was some dialect of MS IE so I had to set-up IE in a very specific way for each clerk. Any minor update in either The System or in IE would mean days of blank forms and lost work.
I feel your pain. We only recently got rid of our last mainframe-based systems -- by the end we were literally in a situation where all the data was accessible by web but people needed a 3270 terminal emulator to change their password. I got to remove MochSoft TN3270 from my software distribution system just least year.
" - so why are they force-fed business software?"
Oh, I hadn't realised that the public sector had absolutely no choice in what software they had to implement! Certainly when I was an Oracle functional consultant we were always involved in competitive bids with other implementers (and yes, sometimes some of the competition were also bidding Oracle). I guess much has changed over the last decade.
Having implemented Oracle ERP for several large public sector clients, I admit that standard Oracle wasn't necessarily always suitable for public sector clients; mind you, I could say the same about some of the private sectors clients I worked on. Obviously the core functionality is exactly the same regardless of type of organisation. They buy stuff and have to pay for it; they "sell" stuff/services and have to collect the cash; they have to create income statements and balance sheets; they have staff that need paying. So far, so standard. However, they did all seem to have specific processes and requirements that often required some, or a lot of, custom code to satisfy.
So why did Oracle or SAP win do many public sector projects? Maybe because the client already had some experience of one of the big two. Or perhaps they felt that the alternative applications weren't up to the job. Don't forget, some public sector clients, with their huge budgets, are the equivalent of large companies with complex requirements so genuinely needed large, complicated software. Or maybe they simply believed they were so big and complex that only SAP or Oracle applications would be capable of handling their needs. Or possibly none of the smaller, potentially more suitable, suppliers even made a bid. FWIW I was once part of the pre-sale team on a bid for a university. Initially there were three organisations bidding but the other two withdrew and we ended up as sole bidders. I subsequently implemented Oracle ERP there and they are still using Oracle, albeit having gone through a number of version upgrades, more than 20 years later. So maybe not all Oracle public sector implementations are total disasters.
One big difference:
If I pay a private company to do something, I agree the price, and make sure I get what I paid for. It doesn't matter to me that every penny I paid them was used to deliver what I ordered.
If I give a council funding to replace crumbly school roofs, they must use that money to replace crumbly school roofs, they can't divert it to other budgets. This is something that a standard accounting ledger can't deal with.
Have to admit it's many years since I last played with Oracle but I seem to recall that, while one couldn't necessarily prevent someone spending "crumbly roof" money on something else (subject to a number of unless ... or except if ...) what one could do would be to define multiple budgets in the General Ledger. Hence the account for "crumbly roof repairs" would be allocated a budget, as would all specific funding expenditure types. Implement budget control in Purchasing and folk could only spend the funds allocated. Should it be agreed that money from fund A could be used to spend on something else, the organisation would make a virement to transfer the cash, i.e. a budget journal.
As I said, it's all a long time ago but the mush that was once my brain suggests that I designed a system to do exactly that, except the Purchasing manager decided at the last minute that the various departments had to have the ability to use purchasing cards to satisfy an urgent need or to take advantage of a special price or do whatever they liked as the Purchasing Manager didn't think they could stop them anyway!
Out of interest, are you aware of any accounting system that would prevent the "crumbly roof" money from being spent elsewhere? Even further back in time I was a company accountant and I never came across software that would have prevented the situation, other than by the use of budgetary control.
There are a lot of concepts in academia that just don't exist in private sector payroll systems, is the tricky bit. People in the private sector don't go on sabbaticals, they don't have their positions routinely terminated and then re-instated four months later, they don't have pay rates that vary with credit load, they don't get paid partially out of grant funds and partially out of general funds, etc. You can make that stuff work (we have), but only at the cost of a lot more busy work on the part of the people managing payroll. You end up with people whose only job is to manually shove changes into PeopleSoft that it can't track on its own. Our hiring process has actually gotten slower and more complicated in order to accommodate the software.
But Oracle always gets the nod because they're seen as the "safe" choice. "No one ever got fired for buying IBM" has become "no one ever got fired for giving a contract to Oracle."
"People in the private sector don't..."
Yes, we do. Sabatticals, termination and re-hire (thanks IR-35), variable pay rates, pay from multiple sources...
As contractor scum working for many businesses over the years, I've come to learn that every organisation believes they are a unique snowflake, with unique compications that make them special. At some point, someone will always sidle across to me and say:
"I bet you've never seen it as bad as this"
Yes. Yes I have. Half of the complexity of organisation is that most people in organisations keep that complexity in their heads - as learned procedures, exceptions, people to talk to when needed, habits, rules and anecdotes of how odd situations were delt with five years ago. When you boil it down to what they are actually doing, it's far more mundane than they believe (read this comments section for the pretty unsurprising list of things people are having to deal with), but the belief that we are all special snowflakes persists, and most software houses perpetuate that by being extremely poor at asking simple questions and occasionally pointing out the blindingly obvious.
Of course Oracle and SAP take full advantage of that. You are paid big money for doing complicated things at the customers' request - not for helping them transform their practises, not for simplifying things, and certainly not for pointing out that the guy who obstinately tells you that only they understand the system is far from unique and certainly not any more special than their equivalent in a million other organisations around the globe.
Said it before, and I'll say it again, governments both national and local need a common data standard that'll let software vendors write compatible software. Coupled with a common processing langauge that'll let data be transformed and move around.
Whether it's health records, HR notes, social worker's case notes, police records etc. People designing software rarely have the relevant experience to write good structured data. Thus the structure needs to come from the people who do know.
Even that might not be enough, but it would help.
We, in a previous job, had to use custom built child protection information sharing software that had been built in consultation with the Social Worker's manager. It made perfect sense to them. And absolutely no sense to any education/medical/social justice/etc. colleagues. Even down to the amount of space or the methods of submission allowed for some items - because for example, what the social workers thought was a two line "assessment" saying what they thought should happen for the child was a two page report about the child's development from the teachers, a three page assessment report from speech therapists, a four page health, development and growth report from the paediatrician and so on. So we had all these professionals who needed to submit information sharing evaluations of a child at risk being unable to add them to the record and not being able to adopt the system.
We also had a commercial Business Continuity database to replace our individual managers' plans, that was so f****ing complicated that Town Hall staff had specially trained people just to operate it. Front line services, of course, had neither the staffing nor the depth of training to make sense of it.
Tried that in one Canadian Department; overruled the the money people, who had already made deals to have MS Dynamics as the preferred solution no matter the problem. A prototype showing how the data from the current umpteen systems could be migrated into or could feed the "national" system was not allowed to proceed and "everyone" was diverted into several data migration to MS Dynamics.
"Local governments aren't businesses – so why are they force-fed business software?" Is a click-bait headline, which has worked since you are here!
The great majority of business processes in finance, controlling, human resources, purchasing, asset management and customer service are the same as any business enterprise. The law is the same so all enterprises have to operate in compliance. Yes there are exceptions specific to a council but the great majority is in common so that a fit to standard processes approach will deliver the core solution and leave time & money to deal with the exceptions.
That was true when the SAP solution was built and is still true now so should have been leveraged for its replacement with another software package.
This looks like the package implementation partners didn't enable the council with the correct approach for success.
A sad waste of public funds and stress on council employees that could have been avoided..
The “why” from my experience would seem to be because of politicians…
In the early 90s many local government systems came due for renewal, for various reasons: changing business demands, changing legislation and obsolete hardware. Because local government was a small market the cost of systems development were a big component of the price ticket. The politicians were obsessed with public sector: overspend, over specification, spend of delivery/change, and decided if COTS products could deliver to business then as local government were effectively businesses they could use COTS products rather than the bespoke systems used previously…
Not quite correct there..
Lot's of people will lose their jobs. All the services that can't be paid for will go. Or reduced to a skeleton.
Libraries will close. Sports centres will close. Parks won't be maintained.. Admin support for front line staff will vanish ( but the case loads will get bigger and the time to do the work will be reduced because the admin still has to be done). Repairs will be delayed.. And so on.
The author of this article seems to be ignoring some history. Let's set aside this particular example (government ERP and huge software systems which have to be seemingly-endlessly customized, and still ending up a poor fit) for a moment.
How many attempts been made over the decades -- and failed -- to create a high-quality, "universal" set of subroutines, access methods, APIs, objects, frameworks, etc. for even more-limited problem domains?
Many failures of systems analysis -- for even simple, manual systems -- stem from the people running them not even agreeing among themselves how the existing manual system currently works, and the analyst not being able to resolve the conflicts (determine the truth).
A simple example of this: in a workshop/factory, one department pulls parts and makes up kits (based on order/spec sheets), puts them on carts, and wheels the carts down to the department which assembles the kits into products. Sometimes there are "hot" jobs, so marked with a large red "H" on the order/spec sheets. These carts are to be sent to the head of the cart-line in the assembly department. The entire mangement chain schedules things, prepares reports, and makes promises to customers, based on this simple manual system. Yet one of the assemblers told me, "Ehhh, we [the assemblers] don't worry about which cart is in front of another. We just pull out whichever order we want to work on. They all get done."
If the programmers don't truly know how the system works, how can they possibly create a program which implements it correctly?
I'm reasonably sure the actual underlying problem is that the "big two" are both totally unusable by anyone at all, as standard and by design.
Is there a single SAP or Oracle installation that is not being continually customised by external consultants, regardless of age? Even excluding regulatory-driven changes?
Is there a single installation where the customer is actually happy with their system?
I think not.
All IT systems I've ever seen are basically transactional. "A" sends a message to "B", and then has a very clearly defined expectation of what "B" will do with it, and what sort of response it can expect.
That's an incredibly poor match for how most human beings work. Organisations are composed of people, connected by an intricate and ever-changing web of relationships, dependencies and obligations. One person may react quite differently to two identical messages from different people, even if both the senders are theoretically in the same role.
The solution isn't to rebuild Oracle or SAP from the ground up. A new system built on the same lines is going to have the same drawbacks. You need a more flexible structure entirely.
Speaking as someone who occasionally has to support SITS, an IT system based on your particular sector's needs can easily be just as horrible as some eldritch creation produced by SAP. I believe a few Universities have tried to move away from SITS, but they're all running it somewhere in some form.
The answer is that in the UK for the last ~40 years has been politically dominated, supported by a vast majority of the media, by a group that ideologically sees *everything* as a business and are fully paid-up members in the cult of manageritis.
This influences not just IT procurement, it is systematic.
As the saying goes, if the only tool you have is a hammer, every problem looks like a nail.
It's not just local authorities but all public services that are victim to this mindeset. For example, the NHS. Griffiths, wo used to run a supermarket, was shocked at the lack of obvious authority figures in hospitals ("who is in charge?"), though obviously hospitals had been running fine prior to 1983. So he stuffed the NHS full of managers, because businesses need managers. We in IT know how useful managers generally are, it's a core theme of the BOFH series for example.
I worked in the fiscal office of a large county when the county welfare department "tried" to install Oracle to manage its fiscal operations and caseloads. When I retired a few years later the implementation was still ongoing, it still could not "talk" to our fiscal software without special interfaces that had to be hand coded for each connection, and had become a branch of Oracle University with all the programmers who came in, got trained, and then left for other jobs. This "failure to communicate" was quite a pleasant experience for the people in that department when payday came around.
"Build an equivalent stack as a conceptual framework for local government needs and processes, and the things they all have in common will create a huge market for sustainable services despite no two organizations being the same."
So here's the problem: Nice idea, but to escape lock-in to the supplier's business it has to be F/LOSS. No local council is going to contribute to its development because: a) that costs money and b) anything they offer must legally be Crown Copyright, and even the Open Government License does not allow giving code, etc. away to another copyright owner. Nor is there any mechanism to purchase software support as a standalone thing. Instead they will want to buy (i.e. license) the finished stack and tag support onto the end. But you can't buy a F/LOSS stack as such. The only hope is to contract an honest third party with a heart of gold to provide software as a service; you don't care how they create or support it, as long as that happens. Oh, wait....
They are supposed to provide the SAME services a bit McDonald’s like.
SO WHY THE HELL IS THERE NOT A SINGLE SYSTEM.
They have been doing this since the 70’s it is a disgrace and a total waste of money.
LA spend money like there is no tomorrow why BECAUSE IT IS NOT THEIRS.
At the other end of this link is a long list in Excel (220 rows) of the obligations of local authorities https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/7542/18927821.xls
Including the clear, but possibly open-ended, "Make provision for chemical, biological, radiological or nuclear emergency and urban search and rescue." and the potentially ever-changing "Have regard to such guidance as the Secretary of State may issue (e.g. guidance on investments)."
There probably can never be a single system that works for more than a short time before the goalposts shift again.
That is frankly bullshit.No two local authorities are the same, though there will be some broad groupings like " rural".
The authorities do not spend money needlessly. On the contrary every bloody penny has to be justified and almost every LA service is significantly underresourced. Or haven't you noticed the potholes, the poorly maintained schools, the closed libraries, the loss of arts and museum spaces, the vanishing sports centres.Maybe you are too young to remember when the kids could go to youth clubs instead of hanging round on street corners. I'm sure you have heard of care homes closing down because the local authority can't afford to pay the true cost of using them.Or of Trading Standards offices that haven't the staff to investigate shops selling vapes to kids.
Stuff of nightmares.
Won't even let Java near mine. Rather return technologically to the 1960s than let Larry &co near my PC.
I have a nasty feeling we are seeing a world that is very close to that hypothetical dystopia.
If Larry were offering a "spaceship to the future" it would be the Golgafrincham 'B' ark reassembled with a coat of whitewash slapped the cracks.
Did anyone in the "Government" have a Business Model for what they were supposed to be doing? Before they went on the hunt for a Solution? And did anyone map the functionality of the Solution to what was needed? No need to blame Vendors (and their supporting cast of thousands) when the Buyer has no clue as to what is required and those that might know are not part of the selection process.
In my experience, the people that are often tasked with writing the requirements and performing the user testing are the people that aren't vital to day-to-day operations. Getting some competent business analysts on board would pay dividends, rather than buying something off the shelf and hoping it automagically does everything, including all the hundreds of requirements your busy users didn't have time to spec upfront!
"..your busy users didn't have time to spec upfront". Or didn't realise needed to be included, or thought too obvious to mention, or forgot that it still needed to be done because it already just happens, or thought that this bit was someone else's job to explain, or explained it poorly because it's something they just do, but don't really know why, or just don't even think about it until <date>......
All of which I'm sure is not unique to a public body. But I'd suspect that they are more the rule than an exception in a public body.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
