Part 1 introduced ITIL health check activities, uncovered aspects of inaccurately implemented reporting and offered recommended solutions. In this second and final instalment, Jason continues to look at the different aspects of the ITIL Reporting Suite; how to identify any discrepancies within those areas along with discussion on how to make the most of the results.
In this second and final instalment, we are going to continue looking at the different aspects of the ITIL Reporting Suite and how to identify any discrepancies within those areas. This will be followed by a discussion on how to make the most of the results.
This Health Check is one of the trickier ones to quantify, despite seeming definitive at face value. ITIL software should lock its users into the agreed process and kerb any attempts at deviation or incorrect data input. There will always be human error, but a good ITIL Management System enforces correct behaviour as much as possible. Unfortunately, not all ITIL software is equal and there is a good chance that it is limiting in some ways or, which is arguably worse, is too free in others. What this means for the ITIL Reporting Suite is that each report is likely to have been designed to a specification that was based on a logic process that has since become outdated due to the software forcing/enabling another series of behaviours.
Actively seeking out software flaws as a discrete task would be time consuming and unlikely to reap encompassing results. These software flaws will appear organically during the other Health Checks, so no specific investigation is required.
Login to continue reading or register now to download the ebook.