Reporting
Better information for key decision makers and better access to information are often major drivers behind implementing a new system. Most users derive that information from system reports yet reporting is one of the implementation areas most fraught with difficulty.
Repeatedly, institutions have chosen not to address their management and business information reporting requirements until after the conventional functionality of the software has been implemented, intending instead to deal with those needs at a later date. There is nothing wrong with this strategy in principle but, all too often, the early implementation exhausts the institution's resources and its personnel and reporting is put in the 'too hard' basket and there it remains.
This is such a pity because improved management reporting is often one of the reasons for acquiring a new system in the first place, and a common complaint from the wider user community with regard to newly implemented systems is that 'it has not delivered the management information as promised'. It is usually the case that many issues surround management reporting (e.g. conflicts between users' reporting rights and normal access rights and responsibilities) and, whilst it may be advantageous to defer the delivery of some reports, these must not be forgotten and early preparation and communication of a plan to improve management reporting will go a long way to dispelling those types of criticism.
Standard or Customised Reports
There are likely to be many standard reports offered by the system, but many of these are likely to be viewed as not meeting specific organisational requirements or being in an impractical format. In truth, it is often the case that many of the user demands for changes are simply requests for the same information to be displayed in a slightly different format to that of the equivalent standard report.
Changes to the format and/or content of standard reports require the development of customised reports and the production of so many customised reports raises two major concerns. Firstly, all customised software has to be identified, documented, reviewed and compared with the functionality contained within newer versions of the system whenever an upgrade is released and the whole upgrade process is simplified greatly by minimising the number and complexity of customised software developments. Secondly, software developers require detailed knowledge of the relevant report writing tools, the system's data structures and the organisation's functional reporting needs. Harnessing this combination of skills is not easy and often delays the production of new customised reports.
Of course, an organisation has the option of acquiring an ad hoc reporting tool (e.g. Discoverer, Crystal Reports, Business Objects, Brio, Impromptu) and implementing this for use across the institution. However, introducing and supporting any one of these tools across a large organisation will undoubtedly be costly and the exercise of implementing an ad hoc reporting tool and a business intelligence reporting strategy has all the traits, complexities and risks of a traditional system implementation in its own right. Further, the use of any such tool by a large number of potentially inexperienced users to write and run many untried and untested reports can cause huge performance problems for the rest of the system.
Therefore, every effort should be made to highlight the advantages to be gained and persuade users to use as many standard reports as possible by producing a Reporting user guide and establishing Reporting training courses.
