• Skip to main content
  • Skip to primary sidebar

This view of service management...

On the origin and the descent of managing services. We put meat on the bones.

  • Kanban Software
  • Services
    • Kanban Software Solutions
    • Consulting & Coaching
    • Training and Seminars
  • Posts
  • Events
    • Events – Agenda View
    • Events – Calendar View
  • Publications
    • Our Publications
    • Notable Publications
    • Quotes
  • About us

Manifesto for Service Management Tools

17 June 2014 by Robert Falkowitz 4 Comments

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.

 

Summary
Article Name
Manifesto for Service Management Tools
Description
A set of principles to respect for a new architecture of ITSM tools.
Author
Robert S. Falkowitz
Publisher Name
Concentric Circle Consulting
Publisher Logo
Concentric Circle Consulting

Filed Under: Service Management Tools Tagged With: 2nd line of support, 3rd line of support, manifesto, ontology, plugins, tools

Subscribe to our mailing list

Click here to be the first to learn of our events and publications
  • Email
  • Facebook
  • LinkedIn
  • Phone
  • Twitter
  • xing
  • YouTube

Reader Interactions

Comments

  1. Robert FalkowitzRobert Falkowitz says

    14 October 2014 at 08:50

    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.

    Reply

Trackbacks

  1. Do we really need service desks? | This view of service management...This view of service management… says:
    29 December 2014 at 14:59

    […] have argued elsewhere (e.g., A New Architecture for IT Service Management Tools, A Manifesto for Service Management Tools) that the commonly used architecture of service management support tools is primitive, at best, and […]

    Reply
  2. BPMN & service management | This view of service management...This view of service management… says:
    13 March 2016 at 11:58

    […] have argued elsewhere that the typical service management tools in use today might be suitable for service desk agents, […]

    Reply
  3. Do we really need service desks? | This view of service management... says:
    23 December 2017 at 14:24

    […] have argued elsewhere (e.g., A New Architecture for IT Service Management Tools, A Manifesto for Service Management Tools) that the commonly used architecture of service management support tools is primitive, at best, and […]

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Kanban eLearning

Kanban training online

Recent Posts

  • Verbs, nouns and kanban board structure
  • The role of the problem manager
  • The Three Indicators

Tag Cloud

process metrics service request kanban training kanban flow process lean bias resource liquidity service manager ITSM ITIL process definition rigidity knowledge management agile risk Incident Management knowledge work waste flow efficiency impact change management cause value stream manifesto for software development leadership priority context switching automation service management tools lean management Cost of Delay manifesto histogram kanban board incident incident management tools tools problem
  • Kanban Software
  • Services
  • Posts
  • Events
  • Publications
  • Subscribe
  • Rights & Duties
  • Personal Data

© 2014–2023 Concentric Circle Consulting · All Rights Reserved.
Concentric Circle Consulting Address
Log in

Manage Cookie Consent
We use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage vendors Read more about these purposes
View preferences
{title} {title} {title}