SAP = Stupid As Phuck
A billion dollars... Crikey.
Australia has called for system integrators capable of replacing an ancient mainframe payments system with SAP, and doing so for under a billion dollars. Dubbed the Welfare Payment Infrastructure Transformation (WPIT) Programme, the task at hand is enormous: Australia has for decades used Computer Corporation of America's IBM- …
Given the history of government SAP projects, no one expects the proposed solution to actually work. SAP, in a political context, is not a system for building solutions but a system for testing opponents. Does the next government pull the plug and become responsible for the total loss of $B's or do they stiffen up, push on and risk accusations of incompetence for what was always going to be a total failure. Occasionally things go wrong, as in NSW where it has taken a little longer for the public to wake up to how truly terrible the state government is. The LNP were returned to office to face their own trap - the student management system. Property developers will do well out of that one and that was always the end game.
At the federal level It is unlikely the current government will still be in power in three years let alone six. But in a few years time and from the safety of the opposition benches the LNP will be able to point to ongoing mismanagement and cost blowouts as evidence of Labor's [insert inadequacy here].
It is of order a thousand dollars per recipient.
You could process all the payments by hand for that. Perhaps with a very simple fund transfer system and a few spreadsheets.
It is interesting that the Tax office consumes roughly 1% of GDP, which is exactly what it consumed back in the 1950s before any computerization.
The bigger the project, the less likely it is to succeed. A billion dollar project has no chance at all.
I think that stability in cost post-computerisation is likely due to the ever more complicated rules politicians put around the system as they forever attempt to buy votes. More rules, more code, more chance for error, less chance of understanding the mess that results.
What can go wrong?
I presume the Aus govt will take the view that its a A$Bn so only the very big boys can tender, despite it being more like A$150m a year.
They'd better make sure they've really well mapped that database Schema. WTF is a "204" database anyway? IIRC IBM are known for mainframe IDBMS and DB/2 for the big apps.
The fail is strong in this one....
I went anonymous on this as I worked on these systems back in the '70s & '80s. When the system was designed the capabilities of other databases on the 370 based platforms had some limits that could not be matched to the requirements, ADABAS was also another contender but Model204 had greater capabilities and were demonstrably able to meet some of the other requirements. Model204 had a number of other large govt departments in the US and UK who provided some feedback which may have influenced the decision also but I can only say that from an interested observer perspective.
With regard to the scheme being documented, last time I looked the schema specification had it's own life support system, was documented, catalogued, etc. Of course I cannot comment on the last 30 years or so.
I'm not aware of any software project for a government to come in on budget. They better be planning to have at least $5 billion in the budget for it and a couple extra years for the implementation.
The Register has reported on a few projects in Europe with EDS/HP that never went as planned.
maybe what odds on the existing system _still_ running in 8 years. Like a few systems I know of in ... and ........... departments that have outlived their "replacements". One of them was close to $10^9. (not Defence, altho fan fouling stage there has yet to make the news)
It seems issuers of tender still believe in that formulae for massive fail, multiple suppliers, with subcontractors and consultants. All I expect to hear is experts galore stuffing up at great cost while unnecessary things like health and education are cut.
Anon because everything is a state secret now.
...if only I could get me some of that pie! I promise I'd only overcharge by 100%.
Y'know, I reckon we have enough competence in the El Reg readership to get that integrator gig. And we'd do a damn sight better than The Usual Suspects. If only there was a way... (looking for Blue Sky icon)
Anyone there been told about Queensland Health Authority? I actually read the report from the inquiry, all 500 + pages and I could have written about half of them just knowing it was a government project, SAP & IBM. 1.2 billion AUD down the tubes.
Now I hate SAP with a passion; worked on a couple of implementations, so I know exactly what kind of shit can hit the fan. It's a bitch to implement, a swine to manage, a pig to train people on and it can become the worst nightmare when things go wrong. It's bloody expensive, inflexible, out dated, and an absolute bastard to work with.
But it can be made to work.
To do that, you HAVE to follow SAP's own guidelines. You MUSTN'T change requirements part way through. There HAS to be a project champion high enough up to kick backsides when people start drifting off plan (which they will). The Project Manager MUST be able to keep track of what's going on, and organise things to happen at the right time. And the business units HAVE GOT to be involved all the way through, in their own process, but also for several complete end to end tests of all processes. And the system should ONLY go live once those tests have been completed successfully without any hiccups.
I'd be willing to have a crack at it; not that I'll get the chance. But only if they signed up to follow the above, otherwise I wouldn't even contemplate the idea.
The first rules of running larger SAP and EBS integration programmes and projects is always :
1. Front load and finance the programme with a proper requirements and transition mapping stage.
2. Do not allow any SI to write those requirements on your behalf.
3. Don't give the contract to IBM or WIPRO.
4. Or Accenture.
5. Or, err... CSC.
Okay, so that's five rules... and I'm available at short notice if you need me at an almost reasonable day rate.
Bonkers! But that's government for you.
For those of you wondering about Model 204. First. the article is wrong: it's not an IBM product. It never was an IBM product. It just happens to run on mainframes. Actually, back around 1990 it was pretty cool. It was the first database to use bit-mapped indexes, more that a decade before they were implemented in Sybase IQ (I had to correct a Sybase spokesperson who claimed that IQ was the first database using bit maps). Model 204 was originally developed by CCA and is now owned by Rocket Software. Rocket, incidentally, owns and supports lots of moribund products. It vows never to cease supporting a product until the last user turns it off.
Ah, what's known in the industry as the "Computer Associates" strategy.
Buy up lots of little mainframe products with steady user bases.
Send a "contract re-negotiator" around to discuss how their support contract prices are going up.
It used to be said CA staff were recognized by their corporate dress code. Sharkskin Grey.
I was asked to undertake a formal evaluation of SAP v Oracle v IBM for, I think, this very same project (all cloak and dagger at the time to avoid identifying the real recipient ... it involved administration of welfare for a large government).
I ran the likely contenders through the mill (formal evaluation, complete with custom categories and scoring, etc) and my conclusions on SAP were ... pretty much as as was pointed out above:
"... It's a bitch to implement, a swine to manage, a pig to train people on and it can become the worst nightmare when things go wrong. It's bloody expensive, inflexible, out dated, and an absolute bastard to work with."
... (although I didnt use those words ... and I stopped a little short of saying I hated it).
Ultimately, the end recipient of the research rejected the report because it placed SAP last rather than first. My reading of it all was that the decision had already made and changing course would involve a certain degree of "egg on face". Instead of rethinking, those who sponsored the research sought to discredit it and make it safe to ignore.
Ultimately - agree with the likely outcome discussed above. The end winners - lawyers, SIs, SAP, SAP contractors, etc. The end losers - the Australian People.
For that kind of money you could establish your own Development department driven by a strong C level manager and would increase the likelihood of project success 1000 fold.
I've said it before - the only way to make large projects work is to have a very strong person in the drivers seat. Someone knowledgeable enough to make final decisions and strong enough to force the various people that will ultimately use this into compliance. By spreading it across multiple vendors they've already opened up the likelihood of finger pointing and wasted time.
Personally I don't think projects should have more than about 30 people involved in the actual development cycle, with most of them in smaller groups of about 5 people with clear lines of responsibility. Beyond that you need too many middle managers who will be empire building and quietly sabotaging rivals until the whole thing goes down in flames.
When you have multiple companies involved it just gets worse as each vendor is vying to get additional responsibility (ie: cash) by pointing out how bad the others are.
They're doomed -- doomed I tell you.
To do what?
The observation that programs like this one are doomed to failure is spot on.
Many years ago I had a small consulting contract with a firm whose top level management had decided to convert their entire information management infrastructure to SAP. Their operational and technical managers were terrified. The statement I heard was that they had never heard of a SAP program that came in on time and didn't overrun significantly. From the comments on this article that apparently has not changed much.
Customers and the vendor are equally at fault. The customer for the brain dead presumption that IT can deliver a system that will do what they want it to do without real specifications as to what that might be. . . The vendors for perpetuating the myth that IT can do it regardless of what "it" is.
The Music Man had it right. "You gotta know the territory."
And an unrelated but pertinent observation. The appearance of the word "Transformation" in any title is a clear and unambiguous indicator that it is an exercise in pissing up a rope.
Will SAP exceed the transaction rate of 204?
Any proof of this - or did someone say only the big known players get invites?
It used to be said SAP implementation costs FOUR times the quoted price, but in the end works.
But as SAP said they want the 'cloud model' - one wants to know if the data is going overseas.
One also expects SAP will not cope online with the existing data models and thus will have less functionality.
SAP was predetermined by the contractors who scoped the replacement system two years ago. All they did was rock up and proceeded to sell it to the DHS SES. It is supposed to replace the Model 204 based Centrelink system as well as the IBM mainframe based Child Support System. It has been touted as the answer to all things. They truly believe they will be able to wrangle it into a complex case management system (think managing and investigating child support non-payers as well as Centrelink fraud), client contact system and ultrareliable daily payment system all at once.
Needless to say they drank from the corporate trough muchly and will believe anything consultants say when they are paying them lots of money. Personally they requirements are so specific they would be better to design and build the system in-house but that is totally at odds with the current public service ideology.
Biting the hand that feeds IT © 1998–2019