The Novopay Technical Review
Ben Gracewood does a dummies guide to the Novopay Technical Review:
1. In some areas system functionality does not adequately support the business processes.
The system, as built, does not do what it was meant to do. This could be because the requirements were poorly documented from the outset (probably), but also because the system is an “off the shelf” system that has been “customised” to meet the requirements.
At some point, a decision would have been made that the “off the shelf” software was an 80% (or 70% or 90%) fit for requirements, and the rest could be built as customisations. Hold that thought and read on.
The moment I read that, I understood where all the subsequent problems probably came from.
A custom built system would, in my opinion, be far more flexible and what is needed. It will be very interesting to see in the full review on what basis the decision was made to go with an off the shelf solution.
2. Usability issues and lack of data input validations contribute to processing errors.
To me, this is the most egregious finding. As I understand it, the entire purpose (or at least a key selling point) of Novopay was to reduce costs by moving from Datacom’s human-intensive workflow to a system whereby schools do all the data entry, and the “system” just needs to calculate pay.
For a system like this to work, a massive amount of time and focus has to go into usability of the front-end system. Later on in the review there are comments about tab keys not working properly, and links between pages of the same input form not working. This is fundamental stuff, and points to Talent2 and ALESCO not giving a flying shit about end-users.
This, while fairly typical of an “enterprise” system build on Oracle Forms, is completely unacceptable if it’s so utterly important that data is entered correctly and quickly. It is an absolute core failure of a system intended to be user-driven.
Yep. It all started to go wrong when schools would not enter in casual staff details and had to fax them off for manual processing.
6. A high degree of customisation in high-impact areas has made on-going development more difficult.
This is another one that really sets my alarm bells ringing. Talent 2 sold Novopay to the government as an ALESCO system with some customisation (see point 1). This is the dirty not-so-secret of any “out of box” enterprise software installation: the base system is next to useless without massive amount of customisation.
More often than not, when you add up the cost of an “out of box” solution PLUS the required “customisation”, a greenfield development fine-tuned to your own requirements becomes a much more comparable solution.
I agree.
Like I said on Twitter: Novopay appears to be the wrong solution sold by people with a poor understanding of the problem, implemented with the typically lax approach of enterprise software development.
In other words, pretty much business as usual for Enterprise IT.
If you think this thing has run its course, you’re kidding yourself. I’ve seen Oracle systems quoted as costing $6m run up $30m of cost before being completely scrapped – as in yes, uninstalled and reverted to the system they were meant to be replacing, completely wiped away.
It will be interesting to see if they deem Novopay fixable.