What is ITSM?
IT service management (ITSM) is the discipline of planning, delivering, supporting and improving the IT services an organization provides to its users and customers. It treats IT as a set of services with agreed outcomes, so work such as fixing an outage, approving a change or provisioning an account follows defined processes with owners, priorities and records. ITIL, published by AXELOS, is the most common ITSM framework, and its current version, ITIL 4, organizes guidance into practices. ISO/IEC 20000-1 specifies requirements for a service management system that an organization can be certified against.
Core ITSM practices
Most ITSM programs start with a small group of practices that handle day-to-day work. Each has its own goal, record type and metrics, and they hand work to each other. A recurring incident becomes a problem record, and the fix for that problem is delivered through a change. Strategy, financial and supplier practices usually follow once these basics run reliably.
- Incident management: restore normal service as quickly as possible
- Problem management: find and remove the underlying causes of incidents
- Change management: assess, approve and schedule changes to reduce risk
- Service request management: handle routine requests such as access or equipment
- Service level management: agree targets with the business and report against them
- Knowledge management: capture fixes and procedures so they can be reused
ITSM vs ITOM
ITSM and IT operations management (ITOM) are often confused because they meet at the same point. ITOM covers the technical work of running infrastructure: monitoring, event management, discovery, automation and capacity planning. ITSM covers how work is requested, prioritized, approved, tracked and reported. A disk failure alert raised by a monitoring tool is ITOM. The incident record created from that alert, with its priority, assignment and SLA clock, is ITSM. Both rely on the CMDB, which tells the monitoring tool what a device is and tells the service desk which service it supports.
Worked example: an incident from alert to closure
An application monitor detects that checkout response time on an e-commerce site has risen from 300 ms to 4 seconds. An incident is opened with high impact and high urgency, which under this organization's priority matrix means Priority 1, a 15-minute response target and a 4-hour resolution target. The service desk assigns it to the application team, who find an exhausted database connection pool after a configuration change. They roll the change back and restore service in 50 minutes. Because a change caused the outage, a problem record is opened to close the gap in change review, and the fix is added to the knowledge base.
Define the priority matrix (impact by urgency) and its response targets before configuring any tool, since every SLA report depends on it.
Measuring ITSM
ITSM metrics should show whether services meet the targets agreed with the business. Common measures include mean time to resolve incidents, SLA attainment by priority, first contact resolution at the service desk, change success rate and the backlog of open problems. Trends tell you more than single values. A falling count of repeat incidents is a stronger sign of improvement than a fast average resolution time, which can hide many quick fixes to the same recurring fault.
Common implementation mistakes
Many ITSM rollouts copy every process from a framework before the team needs it, then struggle with forms nobody fills in. Others run the service desk on a tool with no link to monitoring or configuration data, so engineers retype alert details and search other systems to find the affected service. Start with incident, request and change management, connect alerts and CI data to tickets, and add practices when each one has a clear owner and a measurable goal.
How CloudSino approaches ITSM
CloudSino's iDCOS platform provides ITSM workflow management covering incidents, problems, changes, requests and tasks, along with a knowledge base and service quality analysis. Organizations can configure workflows, forms, approvals, priorities, processing rules, notification methods and SLA metrics to match their own structure. iDCOS follows ITIL practices and associates alerts with resources, configuration items, responsible parties and work orders. Alarms from third-party monitoring systems can arrive through API, SDK, SNMP trap, email or syslog and be converted into work orders, so tickets carry resource and configuration context from the start.
Frequently asked questions
Is ITIL the same as ITSM?
No. ITSM is the discipline of managing IT as services, and ITIL is a body of guidance for doing it. Organizations can practice ITSM using ITIL, ISO/IEC 20000 or their own processes, and many adopt only the parts of ITIL that fit their size and needs.
What is the difference between an incident and a service request?
An incident is an unplanned interruption or degradation of a service, such as an application error or a failed disk. A service request is a planned, routine ask, such as a new account, a password reset or a laptop. The two follow different workflows, priorities and targets.
Do small IT teams need ITSM?
Yes, in a lighter form. Even a team of five benefits from logging incidents and changes in one place, agreeing priorities and keeping a short knowledge base. Match the overhead to the risk: a simple approval for routine changes and a full review only for changes that can affect critical services.
What should an ITSM tool integrate with?
At minimum, monitoring and alerting tools so incidents open automatically, the CMDB so tickets show the affected service, and email or chat systems for notifications and approvals. Integration with automation tools lets standard requests and known fixes run without manual steps.