Oracle partner gets multimillion top-up after Edinburgh Uni disaster Scotland's University of Edinburgh has awarded systems integrator and support company Inoapps an additional £3.6 million ($4.5 million) contract fee for "changes in requirements and additional work" following a troubled implementation of Oracle that left staff and suppliers paid late. The additional contractual fee takes the …
"It appears as though the new system, Oracle ERP Cloud and Oracle HCM Cloud, is taking a bit of time to bed in"
That seems to be a very polite way of saying that everything is still in Oracle clusterfuck mode. I hope that other universities across the planet take note of what is going on at Edinburgh University.
Well, I did my time there and can luckily say it was all fine when I left! Thankfully I was out before the issues and the bloodletting/blamestorming started, but I'd guess it was a combination of:
- Not following "Adopt, not Adapt"
UoE, like every other ERP customer I've ever met, are a unique special flower, whose internal processes can't possibly follow the industry-leading defaults supplied by Oracle, Workday, SAP, etc. or the advice of their chosen SI, who do actually have their best interests at heart. They say they're going to adopt, but then when you get down to it, they want every process changed in a myriad of ways, all of which add config time, development, testing and risk.
- Not planning their Data Migration properly
Generally, ERP customers don't allow enough time to develop their migration routines, so they require a system to be built in a certain way, using certain data, but then can't supply that data, or in that format. Customers often keep ownership of the DM part of the project. The SI builds what they've asked for and keeps asking if they're on track with DM. The client keeps saying yes, but it's only when UAT or Prod cutover goes pear-shaped that the client admits they never passed testing, or had to truncate it, & didn't have enough staff/time to sort it properly. By then, they're tied into go-live timelines with major implications and the SI helps them crowbar it in, knowing it'll probably be a nightmare. Added to which, HE legacy systems are always disparate aging bits of kit held together by bits of string and a single overworked person owning critical pieces, who can't/won't delivery what's needed in time.
- Academics treat being a manager like it's a waste of their time
Every HE institution has a Corporate Admin function that is under-resourced and under-appreciated, trying to run the place like a viable enterprise, while the academic departments and senior management are all led by professors who would rather be doing research and treat submitting & approving timesheets, expense claims, leave requests, performance reviews, etc. as a damned embuggerance that someone else should do for them, or should just magically happen. Head of Dept posts are generally done on a buggins' turn system by each dept's senior lecturers as a secondary role to teaching/research and a stepping stone to a more senior academic role. Actually being an effective administrator or decision-maker is not a qualification for the role. Try designing a system where there is a rigid hierarchy that must be followed at all costs, but most layers of management refuse to check their emails or log in to a system more than once a month, if you're lucky and willfully avoid learning how to do something basic, as their precious academic knowledge might be diluted in some way by the effort.
Bitter? no, not me...
(Anon as they'd recognise my name and I might have to go back!)
Yeah we have a "wonderful" new Oracle system we have to use. Hit back button - get an error. Try to "open in new tab" - get an error. Spend ages getting a list of "things" (i.e. setting the filter), drill down to look at one of those things, remember, no "open in new tab"), hit the back button (the application one, not the browser one) and end up not where you started from (either the filter is reset, or you aren't even in the same part of the application).
Yeah, "not at all" impressed with our Oracle application. And everyone keep going on about how much better it is - it's not. The old system which was a web UI grafted onto an old text based (and custom) application was clunky and needed a certain amount of learning how to use - but it was quick, didn't block "open in new tab", worked if you hit the browser back button, and actually was easier to see as it didn't go out of it's way to make the UI "pretty but poor in function".
Agree 50%. I have witnessed exactly the same with two other companies. They simply do not grasp that they will have to make major changes to their existing business processes first before they can implement Oracle. I have though also seen the absolute horror on the faces of HR and Finance the evening before "go-live" when their last task is to upload the spreadsheet with all the employee ID's only to find that Fusion couldn't handle different formats (employees from one country had 9 number's, another country had 4 letters and 2 numbers etc) and the system couldn't handle this. Given that employee ID is the best unique identifier as opposed to email address which can change when married, divorced etc and can end up with john.smith, john.smith1, John.smith2 pretty quickly in a large company it was quite a shock. Even better when it turned out none of the current format of id's for any country was compatible. The work to align this, agree on one new format for all countries and to then be able to "switch" over without anyone not getting paid with so many people joining and leaving globally at any one time was quite the interesting challenge and one of course the SI could only help with if we regarded this is a change request.
The question of course was asked why, when employee ID was so critical, had the SI not mentioned this in the very first meeting! No one on our end had asked as it was assumed that of course if our old systems could handle multiple formats then Oracle would have no problem. This is so basic but highlighted to me the role of the SI is to make money and not to ell you anything that makes you realise just how much work you have to do it eternally to make these integrations work but the SI will take 90% of your budget for 10% of the actual implementation work and leave you with only 10% with much to some how manage the remaining 90% of the work.
Write down all your current business processes, map the full end to end workflows, remove data duplication in entry and processing, clean up all your misaligned data..... The list goes on and on and all this is manual work which has to be undertaken by staff, not the consultants as they have zero knowledge of your internal processes and ways of working. Then you end up having to redo a lot of your job descriptions, find out some staff no longer have work and in other areas you don't have enough etc etc etc. It's years of work with no additional resource to do it, so I disagree that the SI should be saying they told the client to do it and the client didn't do it in time and that's why the implementation missed it's go live or why it went live but with bugs. SI should be handling these two distinct phases separately and making no commitment to Oracle until the first phase is complete and the new process and way of working has bedded in (the reason their are so many training issues, not the system but the new process itself). They know though that in many cases this would then remove the business reason for blowing £30 mil on Oracle in the first place (we need to to improve our business processes, remove duplication, improve data processing etc). Best thing all round is that any company looking to spend that kind of money simply takes a minute on LinkedIn and hires someone onto staff who has actually been through a full end to end implementation so they can advise of all the issues (and benefits) upfront, otherwise the power is all in the hands of those on the other side of the table.
> Every HE institution has a Corporate Admin function that is under-resourced and under-appreciated...
I beg to differ. HE institutions typically have a Corporate Admin function that is bloated, not focused on core operation (HE...the clues in the name!), and regard it as essential to create as many PHBs as possible.
From personal experience.
I mean, seriously? They bought a system from a company whose name is a truncation of "I no apps"?
Wow! That's like giving all your money to someone called 'Bank Man fried' or 'Made Off'.
Oh.
And now they complain that they have engineered themselves into a 'well this is such a specific system that only this one company can operate and knows how it works, so we really can't go with anyone else' situation. Jut wondering whether anyone with an MBA was involved in the design or implementation. The FT (paywall, sorry, I bought the print version on Monday) recently published an article about 'peak MBA' noting that companies in the FTSE run by managers with an MBA perform worse in the long term than ones with people who understand the business they are in. MBAs tend to emphasise extracting* money over long term stability and often do rather better financially than the companies they manage.
* (initially a typo autocorrected to "extra sting", not sure which I prefer.)
No doubt there'll be a bit of Oracle kicking but maybe one ought to look at the client.
According to the article the changes are "necessary and largely a result of additional requirements and internal requirements changes,"
As a now retired Oracle implementation consultant I still remember trying to establish what the client actually needed as opposed to what the requirements asked for. All too often those doing the job aren't involved in defining the requirements.
The result was often me trying to convince the client that, because they didn't understand what they needed, they would have to stump up more cash. Obviously the client might think I'm just trying to increase our revenue.
Sometimes they would agree and raise the necessary change requests, other times it was "Implement per requirements!" only for that to cause more problems later on.
Of course Oracle ERP isn't the right option for every organisation (although I implemented Oracle ERP at one public sector client back in 1998 and they are still using it). Sometimes it's the client that causes problems. And sometimes it's the implementor, especially when trying to keep costs low.
Bugger I miss work sometimes
"another contractor would not have access to the Inoapps proprietary methodology for design and implementation" and that "disclosure of the methodology or technical products from that approach to a third party would be a breach of confidentiality"
And there lies your root cause. Welcome to the world of outsourced price gouging.
"Oh you wanted a 3m power cable not the standard 2m. Well that's an additional charge of £100 per item. No, you can't get your own, that's a breach of contract"
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
