UK's Cheshire Police tenders for whole new ERP system after Oracle Fusion went live with 'significant deficiency' The police force for England's northern county of Cheshire is seeking a new ERP system in a deal worth up to £190m after a troubled launch of Oracle Fusion. The contract notice from Cheshire Constabulary, on behalf of the Police and Crime Commissioner for Cheshire, is the latest instalment in a saga that could see the force …
What is it with all these major vendors that botch project after project ? It's at least the third time this year.
I cannot believe that there are so many incompetent project managers getting these high-profile projects. When you have a multi-million dollar (or pound/euro/whatever) project you put someone of experience in charge. The programmers don't necessarily need to be the best, but the project manager does.
Yes, there are clients that don't know what they want, or have internal politics that are murkier than a toilet after beer and tacos night, but that does not explain all these high-level failures coming from companies that have the experience to do better.
I hate to defend Oracle, but there isn't anything wrong with their offerings. They are more than likely poorly implemented with unclear or no requirements often by external consultancies staffed by people who have little or no experience delivering the solution.
Now I need to go and scrub the Ellison off of me.
PS. Workday is better than Oracle.
Is a one size Payroll, Purchasing, Finance, HR etc ‘one size fits all’ perhaps the problem as opposed to the solution??
Best of breed products and interfaces between them (whether simple files or perhaps something more sophisticated like Biztalk).
Contain your systems/processes/access as appropriate and chuck data between them. They will also be less traumatic to implement too.
The problem I see over and over in that approach is the "chuck data between them" part. That is a constant source of nightmares, costs and integrity problems. The only advantage of a "best of breed" set of disparate solutions over an integrated one is that it buys you time until you reach the data integration wall and the politics of each discrete solution are restricted to a single domain.
No. Please not 'best of breed'. Integration is a nightmare. Build your own system before that.
In fact given Oracle buys up any product that looks like becoming best of breed and sews it into Fusion that's not very different than what is happening, just with Oracle at least owning source code on all the bits.
Really, you just haven't seen the mess government makes of commissioning.
The notable part here is that the police signed a ten year contract in 2013, and then arsed around changing the spec and overcomplicating things; the migration to the 'new' system didn't happen until 70% of the way through its intended lifespan.
It's one thing to have a client demand something insane like the world's tallest house of cards, but if they're going to come along and joggle your elbow every half hour, you just take the money and don't bother trying.
"...external auditor had explained that this "significant deficiency" is a "standard feature on all Oracle systems which is not ideal but very common".
So, if it's a "standard feature" why did they buy into a contract *knowing* it would not be suitable?
"Hello Oracle support, this product doesn't work."
"We know."
"But it doesn't do what I want it to do."
"Thankyou for your positive feedback, the Significant deficiency module is a standard feature supplied by Oracle which you paid a premium for."
With that kind of audit, misuse of public funds must have been whispered somewhere ...
Well, it's good to see some long term planning going on, but £190mn over 20 years is roughly £10mn per annum.
Quick back of fag pack calculation, and I reckon you could employ about 200 clerical workers for that kind of sum. Just buy them some pens and paper and why bother with all these expensive and complicated computer things? Before computers were invented I'm sure they had 200 clerical workers doing all that work quite efficiently. Not to mention putting those wages back into the local economy.
Cheshire police total budget for 19/20: £214.7m (https://www.cheshire.police.uk/SysSiteAssets/media/downloads/force-content/cheshire/careers/we-care-strategic-plan.pdf)
Constables: 2053 (https://en.wikipedia.org/wiki/Cheshire_Constabulary)
Civilian support staff: 1296 (2018 figure - https://www.cheshire-live.co.uk/news/chester-cheshire-news/cheshire-lost-more-police-officers-15754250)
That means an average total cost of ~£64k per head across the entire force.
Even if we assume that these hypothetical clerical workers would cost the same (hard to believe, IMO), £10m/yr would pay for 156.
If you have better, or more relevant numbers than this, please share them.
I understand that IT and software isn't LEA's main competency, but let me just state for the record that it's vastly more desirable to develop your own custom software instead of buying some off-the-shelf ERP package. Very little functionality in Oracle's ERP is suited for police forces, requiring extensive and expensive customization in any case.
And don't skimp on contractor wages either. A rock star developer or architect is worth their weight in gold. The real trick is finding them.
imagine you are a sales person for a reseller and you need to make targets.
what you do is persuade those with the money that they need to spend that money with you and your organisation. what you do is persuade them that this shiny product from big multi national will do everything you need today and be able to deliver what you don't know about tomorrow.
once sold you move on to the next proposal and sell what you know etc etc etc.
Thats why big multi national software vendors work with integrators etc to sell their competent product to those who don't need them.
The one way to absolutely guarantee that you'll spend more money than buying off the shelf HR, payroll, finance and procurement tools is trying to build it yourself.
Not only is it massively complex, there are numerous legislative and regulatory requirements for payroll along. You then have the vast ongoing costs of support, maintenance and keeping it thing updated with annual regulatory changes. And trust me, every year there are regulatory changes.
Despite every company I have ever consulted for thinking they are unique, I can assume you, they're not.
My company were looking to refresh a public sector customer's system, an internal (to them) architect decided that as someone he knew had had a bad experience with what we and another company had proposed he'd have it rejected, after the contracts had been signed!
They've now had to go back out to tender and sort out the existing contracts.
I've been involved around the edges of various projects, some IT related.
And I've read up on a few failures too, because of these.
An abiding impression is that all the parties actively involved seem to be well intentioned. But that they don't seem to be even close to speaking the same language. The vendors/builders etc. want to put together a package that the users say they want, but all seem to come to the table with a preconceived idea of what that is, which is not matched to the reality. For the contractors/vendors these are apparently based on previous contracts that they think are the same, because they belong in the same line of work ( as far as they can see). The layer that are buying the project are impressed by this "experience" and use it to justify employing that contractor, but themselves seem to talk in terms of corporate visions and how the bits of the project will fit the current priorities. But don't actually focus on what the people working in/with the resulting construction actually do and will actually need. Again usually assuming that this project is just the same as the last one.
And the poor bloody workers are left saying "We need to be able to do X. Will we be able to do X?" to which both the others say "Don't worry about that, we'll make sure there's lots of X capability.
When the project is almost completed there still won't be any sign of X.
The workers will be saying, "Where's the X?" And get told, "Don't worry. X is in the next stage".
The day they move in the worker's will find that the X functionality will have been bolted on (if they're lucky) in some Byzantine way that makes it bloody obvious that it was an afterthought. It won't work the way it needs to. It'll take twice as long to use as it used to before and will be completely unreliable.
But there will be a cycle route (corporate priority #1 access to cycling.) There will be passive cooling (Corporate priority #2) and so on. If it's an IT project there will be lots of reports that can be produced that no one wants but that the design teams thought that there should be and the corporate team agreed enthusiastically because they thought that these made things more "accountable". It's just that there won't be the one that the staff need to do the day to day job. And so on.
Just thought of a good example of this. Not an office or an IT project, but a good example none the less. It was a park. A design team had been appointed. A lot of money had been allocated to play areas that the public had requested and a water feature, that they hadn't.
There was a play area for the under 5s.
There was an activity space for the 11+ with hoops and balancing things.
And nothing for the primary school aged kids 5-11. The ones that needed it most. The ones that most of the residents had said was needed the most. But there was that bloody expensive fountain. That never worked, because the water pressure was too low or something. And no one ever saw anyway, because it was right in the middle of the park, surrounded by bushes, roughly mid way between the big and little play areas, where the 5-11 area should have been.
.
Excellent points - fully agree. We've just engaged Cognizant and they're doing the same thing to us. It's hard to hold the line with them even as someone who knows exactly what they're talking about (and when it's nonsense) - I can't imagine what nontechnical people experience.
Watch out for the vague reassurances that X will be included. That's the killer. Getting an actual specification and a time line. Because you'll be working against your own side too. They will see the ordinary, essential work-a-day stuff as unimportant compared to the solar powered security barriers and the special soft tread carpeting in the corridors. So in the design meetings the stuff that you actually need will always be number 31 of a 30 point agenda just before lunch.
>For a moment I thought you were referring to two US Presidents.
That was a short running American TV show.
Two ex-presidents, fight crime. One wants to build houses for the poor disadvantageous criminals from broken homes but the other one always calls in an air strike by the end of the show.
Had a lengthly discussion with a big four IT auditor years ago when thay raised the issue of DB privileged accounts, explaining them that there is a DBA role where a single person *has* to have the ability to view and change *anything* on a database and that is simply unavoidable. He seemed very concerned about that and the cascade implied policy violations, and started to lecture me on separation of duties, etc, until I asked him *who* should set up all these duties and roles and then the "root" level role appeared as a natural necessity.
No sympathy to Oracle, but these auditors seem to be utterly confused about what an IT support role does. Confusion that is also applicable to management roles that read these audit reports and don't fact check their findings.
Just because your SQL Server installation needs to have a root "sa" account, it doesn't mean that the application that sits on top of it needs to allow you to access the DB as "sa"...
It is perfectly possible to design a system where an administrator user has permissions to do "admin" things such as creating and administering users, but does not have the rights to do the things that the users they create can do. To prevent the situation where the admin creates a user account for themselves, and accesses $protected_functionality, you have this thing called auditing. I'm pretty certain high levels of auditing (i.e. full access and change tracking) is mandated for police systems (I know it is for medical systems, which is how they convicted Harold Shipman).
Of course, that sort of thing wouldn't stop an admin doing something they are not supposed to do, but it would prove they had done it, and with proper policies in place (i.e. someone reviewing account creations and permission changes), they would get caught. It is not unheard of for police officers and staff to get caught accessing things they should not, such as officers looking up details of their partner's ex, and they don't get off lightly when they do get caught.
<<Just because your SQL Server installation needs to have a root "sa" account, it doesn't mean that the application that sits on top of it needs to allow you to access the DB as "sa"...>>
It is very hard, if possible at all, to completely get rid of root level accounts at all levels. The lower the layer (OS->Database->app server->front end) the harder it is. And doing so carries its own set of risks, such as completely losing access to your data with no possible recovery, and is costly: each role has to be carried out by different individuals, with their own set of controls and with the added process overhead of communications and change control. So even if you can do it, very few implementations will remove all root level accounts on the grounds of risk/security benefits. And I know of a few ten-thousand user systems that keep these root credentials around, with some security measures added to prevent its misuse. But I don't know of anyone who actually deletes those root level accounts once all the roles accounts are created.
Bear in mind that tightly securing at the app level does nothing if there are holes in the lower layers, such as database root level accounts or server root accounts.
I concede that police systems may be one of these use cases, that may be debatable but let's assume it. If that's the case, the problem lies in whoever selected the package as Oracle Fusion was not created with those levels of security in mind (a separate discussion is what concrete purpose Oracle Fusion was created for, but that's another topic)
These are basic audit checks surely you do these before going live?
Having access to whole areas of systems is not impossible, its having non logged usage of systems for Admins in my experience.
As mentioned a DBA in smallish shop probably needs access to the whole database server but probably needs to use elevated accounts that are logged when they go off the standard work.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
