Building an ITSM operating model that turns service data into action

An ITSM tool can record activity without creating operational control. Tickets close, dashboards refresh, and weekly reports circulate, yet the same failure can still return because the processes are not connected to ownership and learning.

At PepsiCo GCC, I established an end-to-end ITSM operating model across incident, request, problem, change, release, knowledge, service-level management, and governance. In parallel, I embedded SRE practices including observability, SLOs, error budgets, health checks, and operational readiness. The value came from treating these as one service system rather than two competing methodologies.

Begin with a service, not a queue

A queue-centered model optimizes assignment. A service-centered model optimizes outcomes. I start by defining the service boundary, users, critical journeys, owners, dependencies, support tiers, service commitments, and business calendar.

That context makes operational data meaningful. An incident count by itself says little. The same count mapped to a critical journey, a recent release, a recurring component, or a service objective can identify where leadership attention is required.

Connect the management processes

The operating model should make one process the input to another. Otherwise, each team can meet its local target while the service continues to degrade.

• Incident to problemRecurring symptoms, major incidents, and avoidable escalations should create a structured path to root-cause ownership and corrective action.
• Change to reliabilityChange outcomes, failed deployments, rollbacks, and post-release incidents should inform release controls and engineering priorities.
• Knowledge to first-contact resolutionUseful knowledge must be discoverable, current, owned, and measured through actual support behavior.
• Service levels to improvementSLA and SLO trends should trigger a conversation about system conditions, not simply an explanation for a missed number.
• Observability to responseAlerts and telemetry must connect to a responder, diagnostic path, escalation model, and service priority.

Design governance around decisions

I use different governance rhythms for immediate operations, recurring improvement, and leadership oversight. Daily or near-real-time control focuses on restoration and active risk. Weekly service review focuses on patterns, problem progress, change quality, SLA risk, and knowledge gaps. Portfolio reviews focus on material trends, cross-service dependencies, investment, and capability.

Every forum needs a decision purpose. If a review merely reads a dashboard, it is consuming the time that should be spent removing constraints. I expect each material item to end with an owner, action, due date, and the evidence that will show improvement.

Use a balanced measurement system

Metrics such as MTTR, SLA breaches, FCR, incident trends, problem aging, change outcomes, and service availability can guide action. I balance lagging outcomes with leading signals: alert quality, health-check coverage, release readiness, known-error currency, runbook effectiveness, and closure of corrective actions.

I also avoid treating a single metric as a performance grade. A faster MTTR can be positive, but not if teams are repeatedly restoring the same failure. A high change-success rate can be misleading if teams avoid necessary change. The leadership task is to read the system, not worship the number.

Bring SRE and ITSM together

SRE contributes engineering mechanisms: observable services, measurable objectives, error-budget thinking, automation, and learning from failure. ITSM contributes enterprise coordination: defined processes, service ownership, communication, auditability, and cross-team governance.

I connect them through shared service objectives and shared evidence. An SLO becomes relevant to incident priority and investment. A problem record becomes part of the engineering backlog. A release gate includes operational readiness. An error budget informs the conversation between feature flow and reliability work.

Service management becomes a leadership capability when every operational signal has a path to ownership, decision, and learning.

Closing perspective

The objective is not perfect process compliance. It is a reliable service organization that detects meaningful signals, responds with clarity, learns from recurrence, and makes improvement visible.

My ITSM operating model was built around that flow. Tools and metrics provide the evidence; roles and cadences create accountability; engineering practices change the system. When those elements work together, service data stops being a report and starts becoming an operating advantage.

Professional note: This article reflects my leadership experience and personal perspective. Examples are intentionally generalized and do not disclose confidential company information.