IT organizations often purchase numerous tools and tool packages. It’s not uncommon to see an organization have multiple tools for monitoring, multiple tools for reporting, and multiple other tools to perform various common activities in an IT organization.
This is inefficient for many reasons. First, the cost is a misuse of limited funds in terms of both the initial investment and any maintenance costs. Second, the organization rarely fully exploits the capabilities of one tool when multiple tools are in place and provide basically the same set of functions.
This abundance of tools happens for numerous reasons. Often, individual departments have significant enough budgetary influence to purchase tools that, while they may be an exact fit for that specific group, do not necessarily align with the needs of the overall enterprise.
Time for Tools Governance
Tools governance is the act of controlling which tools an organization uses and how it uses them, as well as how new tools are added to the mix and old tools are retired. Tools governance saves time, money, and makes the organization more efficient by enabling employees to become more skilled with a limited set of tools over time.
Many years ago I was working with an organization that was having a severe problem around reporting. This was a large organization, and we had one of every reporting tool available on the market. Fundamentally, this occurred because each department had the ability to use their budgets to buy and implement whatever tools they wanted.
The manifestation of this problem occurred in many ways, but one of the most notable was in how reporting was used to underpin presentations to management. Basically, we had several cases where individuals from different parts of the organization made presentations to management using the same underlying data but somehow coming up with completely different results and recommendations. Management literally said, “We want one version of the truth.”
This initially led to a data quality project that sought to investigate and improve the overall reliability of the data that the organization used. Quickly, we found that it wasn’t necessarily the underlying data that was at fault; rather, it was how we used that data. Because so many reporting packages were in use, there were unclear rules, procedures, and policies around the data and its use. These unclear rules were very rarely enforced.
Our data quality project led to a tools governance project, which among other things resulted in defining a finite set of reporting tools, defining specific and clear policies and procedures on their use, and establishing a standard catalog of reports. Ultimately, our issue with having multiple versions of the truth subsided.
Related Courses
ITIL® Service Lifecycle: Service Strategy
ITIL® Service Lifecycle: Continual Service Improvement
ITIL®: Managing Across the Lifecycle