Universities are pretty challenging places for IT managers. There are lots of technically adept users who sometimes use their knowledge to do things they really shouldn’t.
It was in just such an interesting environment, Wellington’s Victoria University, that Mark Hewitson, the university’s financial advice manager, upgraded the university’s business intelligence (BI) system, with security in mind.
The university needed to exert better control of any changes made in the BI environment by users, and track those changes to their source. This need was one of the drivers behind the university’s decision to upgrade to version 8 of the Cognos BI suite.
“In early 2001, when I arrived, the university was doing its budgeting using spreadsheets,” says Hewitson.
The problems with this approach are well known and include “error potential” and “version inconsistency”. In addition, academics tend to have IT skills and so find it quite easy to penetrate the password protection of a spreadsheet and tinker with the calculations.
So, an important element of the new Cognos BI will be improved security, workflow monitoring and audit trails — so any changes can be traced to source.
If someone says, “Those aren’t the figures we gave you” it will be transparent where the changes have emanated from, says Hewitson.
Since 2002, the university has managed its budget using Adaytum, which has since been incorporated into Cognos’ BI suite as Cognos Enterprise Planning. The suite has since, between 2002 and 2005, been extended to take in revenue forecasting, the analysis of surplus and expense data, and to track variances between forecast and actual data.
Victoria has also experimented with Cognos’ multi-faceted ReportNet, which is included in Version 8 of Cognos’ BI suite. ReportNet should allow more advanced intelligence work, such as the building of data “cubes”, for multivariate analysis; and dashboards, for real-time monitoring and drilling down to find the source of anomalies.Before choosing Cognos Planning, the university canvassed its users extensively regarding their needs. This approach is also being used for its BI implementation. This may sound like an obvious thing to do, but a lot of organisations don’t do it thoroughly enough, says Hewitson.
“One of the major reasons for BI failure is not listening to the needs of people across the whole organisation. One group decides to create an ‘amazing’ system then it says to others, ‘We’ve built this; come and use it’. You must make sure you build something with strong organisational relevance for everyone, and that means consulting widely.”
Part of this consultation process involves prioritising requests and making absolutely sure those put on the list of requirements are really needed, he says. This ensures every possible need has been reviewed for cost-benefit and helps guard against future scope-creep.
One thing that has emerged is that the BI system should have a straightforward user interface. It sits over the university’s various databases so should allow information to be viewed separately — from any part of the organisation — but it should also consolidate it efficiently, too, says Hewitson.
It is vital to clean-up the data that goes into any BI system — not only to ensure the system works properly, but also to inspire confidence.
“If the information is not precise and consistent; if there are contradictions — that’s bad for credibility.”
This means the implementation team must be good communicators, as well as having technical and business skills.
There are risks in implementation and they need to be communicated up-front. “You should not sell BI as a magic panacea,” says Hewitson.
The team will have to answer the question: “What has BI got to do with us? We’re here to teach and to do research.
“We need to show [users] how BI will help that process; how it will remove some of the hurdles in the way of what they need to do.”