IT Service Management Consulting: Service Commitments That Hold in Daily Operations

What services does IT provide, for whom, and to what standard—and who within the organization is responsible for them? Capturing services from the transaction history and application directory, grouping them into services that a functional area can also name, assigning service responsibility, and distinguishing between business services and technical sub-services. The result is a directory suitable for prioritization, billing, and requests for proposals—not just for archiving.

The process for handling an incident, from reporting to resolution: receipt, classification based on impact and urgency, assignment of responsibility without consultation, and escalation with designated roles. For serious incidents, there is also a well-rehearsed command structure with one person leading and another handling communications. And the link back to the root cause: which incidents develop into a problem that requires tracing the cause.

Changes are the most common cause of self-inflicted outages. Key topics include a change management process with a tiered level of review instead of a uniform committee requirement, an impact assessment that accounts for dependencies, an approval process for standard changes, and a well-maintained inventory of equipment. The benefits are reflected in two figures: fewer malfunctions following changes and shorter approval processes for non-critical interventions.

Commitments that align with the company’s capabilities, and metrics that reflect the users’ perspective. This includes definitions that are not open to debate (when does the clock start, what counts as restored), a distinction between internal targets and contractual commitments, a report that triggers decisions rather than just filling pages, and user feedback as a separate metric alongside system metrics.

The point of entry determines the workload that follows. Topics include a documented catalog of requests with approval workflows, the consolidation of similar requests, self-service for cases where it is feasible, a knowledge base that is built into the process rather than alongside it, and the question of which processes actually require human intervention. Expansions into other functional areas are evaluated but are not automatically implemented.

Selecting and implementing an ITSM tool, replacing an ad-hoc solution, and consolidating multiple systems following an acquisition. And here’s the tricky part: data quality in assets, applications, and responsibilities—without which any tool will simply provide incorrect information more quickly. In the case of service transitions, the service description, the measurement points, and the interfaces between the service provider and the in-house team.

Starting Point: IT clearly delivers value, but no one can articulate what that value is. The approach that works: First, consolidate the transaction history and the application directory; then bundle them into services that a functional area can understand; and finally, define responsibility and commitments for each service—at a level that the organization can currently maintain. Progress is measured by the percentage of services with a designated person in charge and an agreed-upon commitment.

Starting Point: The operation is running at full capacity, yet satisfaction is still declining. Analyzing the backlog by root cause rather than by queue, grouping recurring issues, establishing a defined process for turning recurring issues into improvements, and designating a role to track the root cause across team boundaries. Control is based on the proportion of recurring issues relative to the total volume—the figure that truly reflects the reduction in workload.

Starting Point: Changes cause disruptions, yet the process is considered too slow. Both issues stem from the same cause—a uniform level of scrutiny applied to all changes. A risk-based, tiered approach; an impact assessment that accounts for dependencies; standard changes with prior approval; and a well-maintained inventory of equipment. The process is controlled based on the proportion of changes that result in a disruption.

Starting point: A system has evolved over time, been modified multiple times, and is now virtually impossible to change—or, following an acquisition, two systems are running in parallel. Procedure: Clarify commitments and workflows, then clean up the data, then configure, then implement. Changes to the standard are justified on a case-by-case basis, not treated as a collective list. Progress is measured by the proportion of processes that take place within the tool rather than outside of it—proof that the workflows have been adopted in day-to-day operations.