So tell me if you heard this one: an ERP deployment goes horribly over budget...
Then over-promises, under-delivers, and users revolt... So what terrible Indian outsource shop/slave market did they use?
Invoices worth AU$540m were paid late after a finance and supply chain system built on SAP S/4HANA went live at Australia's Queensland Health. A report by the Queensland Audit Office [PDF] shows that the ministerial department responsible for operating the state's public health services experienced a troubled launch of the new …
So what terrible Indian outsource shop/slave market did they use?
Doesn't need an Indian outsourcer - sometimes an internal team can do just as badly. When I was at a certain bat-winged supplier of cellular base stations in the late 90's, we had a project to deploy what was called a "factory management suite" - it did component ordering, build tracking, inventory levels, order and shipping tracking etc etc rather than relying on paperwork and people.
To say that it was badly done is an understatement. Each of the modules was late and, when 'finally' implemented, we could ship anything for several weeks - until they (reluctantly) paid for external consultants to actually fix the problems.
The project manager got a handsome promotion out of it even though the project ended up successful (despite being way over time and budget) depite the PM rather than because of the PM..
Outsourcing just makes failure more likely..
The thing is with SAP, you are not buying software, you are buying Business Processes, and this almost always turns out to be the stumbling block, because no matter how big - or how good - your army of Highly Paid Consultants is, the core of the system is opinionated and in most cases what you hoped would be your 100% custom implementation ends up ceding ground to those unmovable core constraints.
Thus your staff, who have years and years of practice with your current processes, have to now learn a new process. And what's worse - it's often not entirely a brand new set of processes, it's more like Franken-Processes where it *looks* like the old one but has just enough subtle differences to trip up the unwary.
When SAP started selling it's Business One suite in the UK and Ireland, our #1 ask from our customers was the ability to register a partial payment for an invoice. At the start, SAP literally couldn't understand how this was even a thing, as far as they were concerned one paid an invoice or one didn't. Good luck customising around that particular limitation of the system! In fairness - they did put it in a couple of releases later i.e. 2 years, which is light speed as far as SAP is concerned!
Partial invoices - About 15 years ago the customer using our SQL Server based system that we had written for them as a franchiser (and including local systems for their franchisees) "suddenly remembered", just as I was leaving for lunch on Friday, that they needed partial invoicing and the ability to accept a single (partial) payment that could be applied to several invoices. As I recall, it needed a new field in one table and three in another, an extra pick box that also showed the relevant invoices sorted by date descending with Yes/No boxes, a check that all of the payment had been allocated, and that any invoice that was fully/partially paid was receipted with the relevant outstanding balances, a couple of triggers, and a new report. I had it working and tested on dummy data by Monday evening and implemented by Tuesday lunchtime. Two weeks later, they asked if they could roll back some of the paid/partially paid invoices so that they could reallocate the payments to new invoices - That only took another day, as I suspected that they might need it, and had set up the fields to accept a rollback. I’m probably not a genius, and the franchiser's turnover was "only" about $70 million a year, but...
No - They didn’t pay me for it as they had a service contract that I reallocated, but their MD did take me out for a nice lunch.
Less than a year late, less than 30% over budget, and the system was actually implemented and "worked" (for some definition of worked). That sounds like a successful ERP project to me! I'm guessing this puts it into the top 1/3 rd of all ERP projects using SAP.
Hell, just getting the system implemented and it not immediately falling over probably puts it into the top 1/3 rd.
"Hell, just getting the system implemented and it not immediately falling over probably puts it into the top 1/3rd."
Not putting the organisation out of business or only able to limp along until it's acquired puts it in the top 2/3's.
I suspect the middle third is abandoning the upgrade and limping along for another 5 years until there is a new CIO prepared to take the shotgun barrel between his teeth and pull the trigger. At least I think that's how that saying goes.
This is the same Department that failed miserably 7 years ago at implementing a workable computerised pay system (in collaboration with the OTHER "leading" TLA at the time).
https://www.couriermail.com.au/news/queensland/queensland-health8217s-12-billion-payroll-debacle-described-as-8216great-failure-in-public-administration8217-but-premier-vows-8216action8217/news-story/a3a47242d6215029c8aee536b1534440
https://www.couriermail.com.au/news/opinion/payroll-debacle-can-happen-again-if-government-does-not-change-its-ways/news-story/21c9b4d8f85f8de23296ecda83ed8671
Appears they learned nothing.
The update at the end of the article reminded me of a CIO article which reported a sharp increase in percentage of companies that rated their ERP project a success. Key reason for miraculous rise of the figure from 58% in 2015 to 88% in 2019: Companies define sucess as "whatever they get" in order to avoid reputational damage arising out of failure.