Drago Topalovic Service Reporting is important. I will not step through various requirements and recommendations from ISO 20000-1 or ITIL; you are free to explore them in the original material. In this post, I decided to provide a few bits of experience and things I find important considering Service Reporting.
For important metrics used in Service Reporting, please have a look at the Measurements article.
Why reporting?
Reporting in Service management is often seen as a boring and tedious task, especially by the people assigned to create reports. On the other side, business representatives on the receiving side are often discouraged by the large volume of Service management data, or by the lack of their meaningful presentation.
In ITIL and ISO 20000, reporting is recognized as one of the most important interfaces of IT and business. During reporting, IT has the opportunity to present all crucial aspects of Service management to a customer. Reporting activities enables IT and the business to bring the communication to a new level, to address the important issues and to finely tune performance, rolling the Deming’s circle up the hill.
A few facts: ISO 20000 defines reporting from the 2005 version pretty consistently. There were no revolutionary changes in 6.2 Service Reporting in the 2011 edition. In ITIL, Service reporting emerged in V3 as a process in 5. Continual Service Improvement (CSI). In ITIL 2011, it was demoted to a method instead of a process, which was justified by the fact that reporting is too important in all lifecycle stages to be defined merely as a CSI process.
Reporting audience
A vast amount of data can be collected during professional IT Service Management cycles. The purpose of reporting is to present the data to respected stakeholders in a way they need and understand them, timely and accurately.
Internal IT reports to different managers responsible for various processes can differ significantly. Since some of these people have a stronger influence in our IT organization, they sometimes tend to bypass the agreed reporting procedures and communicate directly to report developers in order to get what they want. This should be avoided. Best practice is to schedule internal meetings to analyze existing reports and discuss the new report requirements, from which other departments can benefit too.
External reports to businesses usually differ even more due to the nature of customers’ business processes and their respective SLAs.
If services are provided to a single business organization, requirements of reporting to Sales and Finance can look very different if they are derived bottom-up from their particular business needs. Nevertheless, IT should do its best to present common issues in order to standardize reports and create reusable reporting modules. This will reduce the load to reporting development and enable easier report maintenance.
If services are managed for external customers, the initial Service Level Management meetings should do the same on a larger scale: offer the standard reporting to the customer and discuss their specific needs. Every new customer can bring a fresh view on conventional processes and maybe provide ideas on how to bring new value to other customers.
Creating standardized reports will enable efficient usage of reporting development and assigned employees who create these reports periodically or on demand.
If the IT organization can implement some kind of automated reporting, all the better.
Types of reports
Basically, reports are created periodically and on demand. Usually, we call them proactiveand reactive reports.
Examples of periodic reports:
- Monthly or weekly reports to a customer, reflecting trends, outages, SLA breaches, improvement recommendations, etc.
- Quarterly reports to higher business management with a stronger focus on trends and analytics.
- Annual reports that can serve as SLA renewal or ISO management report.
- Daily reports to mid and higher management about significant events during the previous day, considering major incidents, releases and changes. These serve to provide heads-up info to management in case of complaints or other interactions with the customer.
An example of an on-demand (reactive) report would be a Major incident report or Root cause analysis report after a major problem. A second one would be an after-change report. Also, if the event management system is deployed, every significant error notification can be sent to management as a reactive report.
Who is responsible?
Most Service management reporting should be performed or controlled by the Service Desk manager. Reports concerning specific Service management processes can be assigned to managers of these processes, who may then delegate their creation to subordinates.
One thing that I found very important here is the organization-level knowledge on who, when, whom and what. A simple table where we maintain the information about:
- Who is responsible for a report
- What customer is it for
- To whom he/she delivers it
- When (monthly, weekly)
- What (where is the report defined and how is it created)
Having this info defined and maintained can appear boring and overhead-intensive, but in practice, during vacations and sick leaves of assigned people this table can be a real life saver.
Another thing we should have in mind is the ISO 20000 requirement from 6.2 that “The description of each service report, including its identity, purpose, audience, frequency and details of the data source(s), shall be documented and agreed by the service provider and interested parties.” Some auditors can give you a hard time about every word of this requirement, and rightly so. Some of it can appear unreasonable or too demanding, but it is not. Be prepared.
To see an example of a report, download a free preview of our Service Report template.
