The service management marketspace is populated with hundreds of tools, nearly all of which resemble each other more than they are distinct. Fundamentally, they are a place to log tickets of various types, to push those tickets to various roles for their updating, to document the structures upon which the handling of those tickets depends and to analyze and report of the performance of the processes supported by those tools. In some cases, the use of the tools is extended to users. In other cases, various types of knowledge management functionality is also included. The tools are designed to be integrated into the existing management environment either using out of the box connectors, or using documented APIs, or by generic accesses to the underlying database(s).
And yet, it is frequently the case that IT technicians and engineers object to the introduction of such tools. They complain that the tools require double data entry, entail significant administrative overhead and do little to support the work of second or third line of support personnel.
When one analyzes how these tools are really used, as opposed to how their designers may have intended for them to be used, they are hardly any better than the simple desktop database applications that any enlightened person could design and implement in one or two days.
The tools available today tend to support the elusive goal of replacing highly qualified knowledge workers with less skilled and – most importantly – less expensive personnel. The tools appeal to managers who know how to cut costs but not how to increasevalue. And the users of services suffer the consequences of being treated, themselves, as automata rather than as flesh and blood; forced to respond to long, irrelevant and mindless questions asked by unqualified personnel who understand neither those questions, nor the users’ responses, nor the true goals of the services provided.
It is time to review and revise the architecture of the tools used to support the management of IT services and find solutions that provide genuine value to all their stakeholders. It is time to listen to all the specialists who use these tools, respect their views and their needs and provide corresponding solutions.
The work of managing IT services consists of two main categories of activities. First, there is true knowledge work. This is the work that requires the experience, the talent, the imagination, the creativity and the zeal of the people who manage services. Second, there is all other work that can, and should, be automated.
Examples of true knowledge work include:
- work whose most effective and efficient approach evolves and appears in the course of performing that work
- identification of patterns that brute force analysis is too inefficient to detect, if it can detect them at all
- issues where the algorithms needed to resolve them cannot be determined in advance.
Example of work that should be automated include:
- recording the states of components
- performing activities that follow patterns known in advance
- documenting other automated, or automatable, activities
In order to achieve the goals of
- managing services for value
- understanding, respecting and fulfilling the needs of the knowledge workers
- becoming more efficient and effective
- documenting accurately and effectively the work done to manage services
we espouse the following principles:
- existing application and infrastructure management tools should be leveraged, rather than adding a second layer of service management tools
- open plugin architectures should be used to provide service management functionality to existing management tools
- these plugins should combine automation, where possible, with knowledge support, where needed
- open communication protocols should be used to facilitate the communication among management tools
- open and extensible data models based on standard ontologies should be used to capture, process, communicate and store relevant service management data.
The goal of providing a single, unified product line to manage all aspects of IT services cannot be achieved. Rather than developing exclusive, proprietary solutions, we urge service management tool developers to provide value in the context of an open, flexible architecture that provides value to all service management stakeholders.
From a technical perspective, there would probably need to be a configurable broker to route data from one tool to another, especially when data needs to be exchanged among independent organizations.