Until recently the University of Otago was depending on a 15-year-old accounts package called Counterbalance, which ran on minicomputers under the VMS operating system. Unsurprisingly, Mike Harte, director of Information Technology Services, says the legacy system was well past its use-by date. “It was still a good, reliable engine room, but it was very difficult to use and lacked functionality. It was time to look at other things. We wanted something that was easier to use, had better reporting capability and all the things that you would expect in a modern financial information system.”
The university put out an RFI and after the responses came in, Harte picked a shortlist of likely candidates that were invited to tender. Harte says the evaluation of shortlisted systems was a highly consultative process. As well as a core project team of six IT and finance experts, Harte enlisted a sizeable cross section of users, more than 50 people, to assess the competing packages.
The user panel helped Harte to obtain user “buy-in” at a very early stage. This was an especially important consideration as a number of what Harte describes as “feral” financial systems had sprung up at some departments and outlying sites. These systems had been brought in to overcome the limitations of the old system, but Harte wanted a centralised system for better information flow and to reduce overheads and costs.
“It was very important to involve these stakeholders, because we needed to get back to one corporate system.”
Fortunately for Harte, the user panel was unanimous in choosing a package from the shortlist. The successful bidder was Technology One with a package called Finance One. “I was pleasantly surprised. Normally you don’t get that degree of consensus with these sorts of projects.”
Harte says the program met the overwhelming majority of the university’s requirements and while it was not a Tier 1 product, Harte says Finance One suited the university’s scale.
“It comes down to the culture of the organisation. With a lot of Tier 1 products you have to re-engineer the business. We didn’t want to be driven by the product — we wanted the product to fit in with our culture.”
When negotiating with suppliers, Harte says it is a good idea to agree which supplier personnel will be involved with the project.
“Suppliers in general are out to make a sale and they can put some really good people in front of you at the demo stage, but they tend to disappear later on. For this reason a contract should include named resources. We insisted that the key critical people should be named in the contract as being assigned to the implementation and if they were moved, it had to be by agreement. I’m pleased to say that the suppliers we were dealing with were ready to play ball on this.”
The university signed the contract with Technology One in October last year with a view to going live by July 2007. Harte says this was quite a short implementation period as the software would be running on a completely different platform. The university had conducted a separate hardware tender process, selecting IBM servers running Windows.
The university divided the implementation into two phases. Phase one, which went live at the beginning of July, included the core financial functions of general ledger, accounts payable and receivable, cash and project management and reporting. Phase Two, which is expected to be implemented towards the end of this year, will include procurement, budgeting, inventory, asset management and further reporting capability.
According to Harte the first phase of the implementation went relatively smoothly, thanks largely to the efforts of the mixed-discipline core project team. “The financial people understood the business, while the IT people worked on the background interfaces, the conversion of data and the hardware.”
Harte says the core team worked full-time on the project during the implementation phase, with their normal duties being covered by stand-in staff. Other personnel, from the academic branch for example, were also brought in on an ad hoc basis.
The university paid particular attention to change management and went as far as appointing a change manager to handle the wider effects on the organisation. For example, because the “feral” financial systems were being replaced by a central system this meant some finance staff roles would be changed.
“In an installation like this, most of the problems are around people rather than the application software,” says Harte.
The project team also included an external project manager who had a track record in implementing financial systems. “The decision to do that was worth its weight in gold,” says Harte. “He knew all the pitfalls and how to avoid them.”
The new system will be used by around 250 concurrent users, but Harte estimates that as many as 2000 users will log in to Finance One from time to time. Training began with the core financial staff to ensure they could pay bills and process invoices, before moving on to train the staff who will be using the system to make enquiries only. Harte says full use was made of the university’s educational facilities during this period. “Sometimes we would pull 100 people into a lecture hall to give them a presentation on how to sign-off purchase orders for example,” he says.
One of the technical challenges facing the project was that the users’ desktop computers included Macintoshes as well as PCs. Harte says Citrix thin-client technology was used to deliver an identical user experience to enquiry-only users, while the “power users” were provided with fat clients. The latter did involve a few technical problems as the installation procedures on Macintoshes were different to PCs.
With the benefit of hindsight, Harte says one area of the project he would have handled differently was the operational responsibility when the system went live.
“You have to decide who’s going to handle the day-to-day interaction with users. Is it the financial people or is it IT? We could have done a bit more work in that area.”
Harte says the university paid a lot of attention to risk management in the planning stages of the project, though thankfully this turned out to be a hypothetical exercise.
“We asked a series of what ifs. What if a supplier goes under, or we lose some key people, or we have a hardware failure? We developed mitigation strategies for each, but fortunately no significant risks reared their ugly heads at any stage of the project.”
Once the second phase of the project goes live, Harte says some further work will be done in the financial modelling area. “It’s all about accessing the information and modelling the data. The old system was great at storing and processing, but getting data out and analysing it was difficult. With the new system we’ll be able to suck data out and manipulate it and various things will evolve out of that. But at the end of the day it’s just a FMIS — just one part of our corporate system.”
© CIO New Zealand Business Software Guide 2007
Fairfax Business Media
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.