We all remember as children getting our end of the year reports. Some were positive, some were showing signs of failure and occasionally some were read by us and our parents as pure disaster. Reports could lift you up or bring you down. That is how we perceived their importance, as good news or bad news. However, there is a very important aspect to a report that might have eluded us back than: reviewing a report in order to identify where things got wrong and to help you determine if you are on the right track or if you need to make changes.
In ITAM, reports are a way for ITAM managers to demonstrate value to an organization. They contain hard data that can reveal how your teams are performing and how that impacts your customers, both within IT and beyond into the non-IT business units.
Good reports must be relevant to your organisation and what you are trying to communicate. The following strategies allow you to create a good report:
- Be clear about what the recipient of the report needs to know and why. Senior managers don’t want detail, they want summary reports, whereas operational teams need plenty of detail to allow them to analyse what might be going wrong so they can fix it.
- Your reports are only as accurate as the underlying data AND the skill with which a report is designed. Look at your report results with a critical eye – is the output within the realms of credibility? Is it internally consistent and is it consistent with other reports that are run using similar data? If not, the report and any conclusions you draw from it may be an illusion because the data is wrong or the report itself is poorly designed, producing misleading results.
- Carefully choose the correct reporting tools. A right tool is one that helps you to create meaningful reports. If the reporting tool is difficult to use, keep looking for the right one.
- Regularly cross reference your findings against similar data. This not only helps you pick up data and report design errors, but it helps you to identify genuine issues on your estate – for instance a database or server that has been theoretically decommissioned, but which is showing up as requiring a license in your discovery reports.
- Meaningful dashboards are great – a simple image can convey an awful lot of information very quickly; however, don’t overdo it. Avoid using animation or unnecessary graphics. Too much information makes an ugly dashboard that is hard to comprehend in a single glance.
The primary objective of the reporting process is to accommodate the production of scheduled and ad-hoc reports. When creating the reports, we should always remember how important it is to ensure that only appropriate personnel have access to data produced within the reports and to regularly review them and ensure they are still relevant and triggering actions.
To ensure your reports are well designed, we suggest creating a reporting schema for each report. This document should consider things like:
- What each report is trying to achieve
- Expected actions off the back of each report
- The frequency of each report
- The confidentiality requirements for each report
- Who receives each report
- How frequently the report should be reviewed to ensure it remains relevant
Consider also the requirements of your information security policies and your document management plan when building the reporting schemas.
We cannot stress enough how important it is to regularly review your reports to ensure they remain relevant to their recipients, continue to meet our reporting goals and align to our reporting policy.
We also need to ensure there is a path through which people can request ad hoc reports – we suggest turning to the Request Fulfilment Process to allow people to raise requests for reports through the same process as any other request. The plethora of business analysis tools out there mean it is also tempting to make data freely available to other teams to allow them to pull their own reports – this is a great idea, as long as you bear in mind any confidentiality issues surrounding the data and that you are confident the report builders understand and can interpret the data they are seeing correctly.
The Reporting process’ most significant output is that we may decide we want to adjust the SAM plan because of the regular report reviews. The reports we create as a result of this process also play an important role in both the SAM QA process and the Software Asset Data Verification process, so we have included outputs to these processes to reflect this.
All reports should be reviewed on a minimum yearly basis to assess whether the reports are still required and, again, most importantly, to confirm that the reports are still triggering an action. We cannot stress enough – if no one does anything as a result of the reports you are running, stop running them!!!!
Finally, best-in-class SAM/ ITAM would follow up on those triggered actions to determine whether or not those changes could be classed as improvements.
