Reporting is a big part of any software. It is used internally within organisations, and more stylised reports are submitted to clients. As well as physical reports, there will also be requirements for data to be supplied to other systems by data transfer methods, e-mail etc. So, when we talk about reports we are essentially talking about “Output”.
A good system will have an efficient means of capturing data, a well-structured database and importantly, as this is often the part of an organisation that clients see, an attractive and flexible means of output.
The old (and I believe dated) view of reporting, is that it is typically the last element added to any software development via a suite of business reports accessed through a menu structure. This is often complicated by the fact that many people wish to view, essentially, the same data in different ways. An obvious example of this in the Asset Management industry is the number of “Fund Valuation” reports that will exist in a single system. The alternative is to build a single report and insist that this is the only option available.
Reporting has always been an IT issue. Typically, the way this works is that users will produce a ‘Report Specification’ stating what is required for a report(s). Some organisations will have a semi-technical person who will translate this document into something that the technicians can work with. A ‘Technical Specification’ will then be given to the users to sign off before work begins.
This long drawn out affair often results in dissatisfaction as the two parties often speak ‘different languages’ (hence the need for the semi-technical translator), with more complex reports often going through several iterations of this process. Software suppliers will often charge clients for new reports, when essentially, they are taking an existing one and changing the format and maybe adding a few elements. By the time a system reaches maturity, clients will have asked for most forms of output, so this can become a healthy revenue stream for vendors for very little effort.
Counter this with the situation around Microsoft products like Excel, Word etc. IT departments carry little expertise around these products with, predominantly, the knowledge residing within the user community. Where holes exist in what is available in the main software with regards to output, these gaps are often filled by users utilising office-based products. This process can be inefficient and prone to error.
This had been the Status Quo for many years. In about 1995, I came across a product called ‘Business Objects’. At that point, I would have referred to this software as a Report Writer. My IT department did not like the software; I loved it.
All the reporting issues and frustrations I had disappeared overnight. I knew the software; I knew the data that existed in the software but the reports I wanted were not available to me. Business Objects gave me the ability to build my own reports. IT technicians still had a role to play in building what I referred to as a ‘Bridge’ between the user and the database. Tables within the database were complex and often had names that made no sense to anyone other than the people who put the structure together.
In Business Objects these ‘Bridges’ were referred to as ‘Universes’. Once the ‘Universes’ had been created we never asked our technical team for another report. Business Objects allowed me to use my knowledge of how Excel and Word worked in building reports. Once the data was extracted it was possible to use this data in calculations in much the same way as a user would in Excel. So what Business Objects gave me was
- direct access to the database
- a tool that someone with no programming knowledge could use to design and build reports
- a reduction in the list of work that my IT department needed to carry out (we called them FCR’s or
Functional Change Requests), allowing them to concentrate on other areas. - once reports were written they could be re-run using different parameters like, fund, date etc.
without having to start again (in Business Objects this involved using what they termed User
Prompts
I used Business Objects when I started a Third-Party Administration company in 1998. We built our own software, but once we had put our ‘Universes’ together, we no longer had to get our programmers to write any reports. It was my opinion then, as it is now, that IT staff have better things to do than format data they don’t understand, into reports that make no sense to them.
Since then more products have come to market. Some of them have elements of workflow built into them. They are now termed ‘Business Intelligence’ tools. Since 1995, there have been marked improvements in the graphics available to users and reports can combine elements from your own database with other sources to produce comprehensive reporting packages. As well as Business Objects, I have now had a chance to see other products such as ‘Looker’ and ‘Tableau’. There are some very good articles on this market comparing the different products. The products vary in scope and cost. However, the key points from my perspective are:
1) reporting should be the domain of the users, who understand the data, the requirement and the end client.
2) technicians should be freed up to concentrate on the core systems
3) these tools allow users knowledge of products such as Excel to be used in building reports as they employ many of the same techniques
4) quality reporting is often the end client’s view of the service you offer and utilising these tools bespoke reporting can be provided with very little effort.
I have written before about what the system of the future should look like. Utilising the Cloud, having a rules-based approach and making use of the latest technology are all part of this. Another important component is having the right Business Intelligence tool that the end users can utilise to produce the reports needed by management and the end client.