ITSM, ITOM and ITAM: The Three Pillars
Last updated 13 Oct 2026
At a glance
Service assurance keeps the promises Lead-to-Cash made. It starts at service activation, when the SLA clock starts, and runs through three disciplines: ITSM manages the services, ITOM operates the technology, ITAM governs the assets. All three depend on inventory and CMDB data that fulfilment writes.
The picture
Lead-to-Cash activates the service: the SLA clock starts and ownership moves to operations.
- Restore service when incidents occur
- Fulfil requests and control changes
- Measure and report service levels
“Is the service delivering the experience and outcome that was agreed?”
Sections
- Discover infrastructure and dependencies
- Observe events, faults and performance
- Correlate, automate and resolve issues
“Is the underlying technology healthy and operating as expected?”
Sections
- Track hardware, software and cloud
- Control licences, contracts and compliance
- Optimise cost, use and retirement
“Are technology assets controlled, compliant and cost-effective?”
Sections
Connected informationWritten mostly by fulfilment and discovery, shared by all three
ITSM, ITOM and ITAM are IT-industry disciplines (ITIL and the ITSM platform market), not TM Forum terms; each popup gives the nearest eTOM processes.
How it works
Three disciplines, one question each
| In one line | The question it answers | |
|---|---|---|
| ITSM: IT Service Management | How services are managed | Is the service delivering the experience and outcome that was agreed? |
| ITOM: IT Operations Management | How technology is operated | Is the underlying technology healthy and operating as expected? |
| ITAM: IT Asset Management | How assets are governed | Are technology assets controlled, compliant and cost-effective? |
ITSM owns the ticket, the SLA clock and the record of who is affected: incident, problem, request, change and service level management. ITOM is where faults are detected before anyone raises a ticket: discovery, event and alarm correlation, performance monitoring and automated remediation. ITAM owns the financial and contractual view of each asset across its lifecycle: hardware, software licences, cloud spend, support contracts and retirement.
These are IT-industry terms (ITIL 4 and the ITSM platform market), not TM Forum ones. ITSM maps to eTOM Customer Problem Handling, Service Quality Management and Service Problem Management; ITOM to Resource Trouble and Resource Performance Management; ITAM to Enterprise Management (Financial & Asset Management), outside Assurance.
Where it starts: service activation
Assurance takes over when fulfilment finishes. At activation and acceptance the SLA clock starts, the subscription becomes billable, and ownership moves from COM, SOM and ROM to operations. Before that point a late order is a fulfilment problem, measured against delivery dates and jeopardy rules; after it, a failure is an incident. Getting the boundary wrong double-counts: orders still in an activation queue reported as SLA breaches, or live faults tracked as order exceptions.
Monitoring, SLAs and incidents sit inside the pillars
Assurance is often described as proactive monitoring, SLA management and incident management. Those activities remain: monitoring is ITOM; SLA and incident management (T2R) are ITSM. What that older split left out is ITAM: nothing in it asked whether the equipment was supported, licensed or due for retirement.
In a telco, ITOM is split
The IT estate is operated with ITOM tools. The network is operated by OSS fault and performance management in the NOC, fed by the EMS/NMS, controllers and telemetry. Both halves must land in the same ITSM incident when a customer service fails, which only happens if they share identifiers with service and resource inventory.
The handover is data
- SLM / product inventory: what each customer has and its SLA terms. ITSM uses it for impact and SLA measurement.
- Service and resource inventory: CFS, RFS and resources with topology. ITOM correlates against it; ITSM turns a failed resource into affected services.
- CMDB: configuration items and dependencies, read by all three pillars.
- Asset register: what is owned, leased or licensed, reconciled with ERP fixed assets.
One router can appear three times: as a resource (what it is assigned to), a CI (what depends on it) and an asset (what it cost, when support ends). Unless the three share an identifier and are reconciled, they drift. If activation does not write the inventories at all, the SLA clock starts on a service none of the pillars can see.
How this module is organised
- ITSM: 12.2 The L2C–Assurance Bridge; 12.3 SLM–CMDB Integration
- ITOM: 12.4 Fault Management Pipeline
- ITAM: 12.5 IT & Network Asset Management
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Subscription / product instance and its SLA terms | SLM / product inventory | — | ITSM platform, SLA management | TMF637. Where SLA terms live only in a contract document, there is no machine-readable record to measure against. |
| CFS, RFS and resource instances, with topology | Service and resource inventory | — | Fault management (ITOM), ITSM | TMF638, TMF639 |
| Configuration items and dependencies | CMDB | ITSM change and incident forms | ITOM, ITAM | Must be linked to resource inventory, or it becomes a second record of the network. |
| Alarms and performance data | Fault and performance management (ITOM) | NOC consoles | ITSM | TMF642, TMF628 |
| Incidents, problems and changes | ITSM platform | Service desk, CRM agent desktop | — | TMF621 for trouble tickets |
| Owned, leased and licensed assets | Asset register (ITAM) | — | ERP fixed assets, CMDB | Cost, contract, warranty and lifecycle state |
In practice
ITSM platform vendors sell all three pillars on one data model, which is why the CMDB usually lives in the ITSM platform. Network-heavy operators rarely run network ITOM there: NOC fault and performance stays in OSS assurance products, integrated into ITSM through TMF642 alarms and TMF621 tickets. The integration, not any one product, decides whether a fault becomes a customer-impact statement.
Maturity is uneven. ITSM is almost always in place, because customers call. ITOM for the network is usually mature in the NOC but poorly linked to service inventory. ITAM is often a spreadsheet or an ERP extract for network equipment, which is why support contracts outlive the kit they cover.
Programmes that treat assurance as something to add after the order stack is live find the data it needs was never written. Retrofitting that linkage for the installed base is a migration project in its own right.
The trade-off
What it solves
Organising assurance into ITSM, ITOM and ITAM gives each concern a clear owner and question, and makes the shared records between them explicit.
What it does not solve
- It does not repair inventory for services provisioned before the catalog-driven stack existed.
- It does not make the asset register, the CMDB and resource inventory agree; they diverge unless reconciled.
- Buying all three pillars from one ITSM vendor does not, by itself, connect them to network OSS.
What it adds
- Three teams and often three tools read the same equipment through different records, and need shared identifiers.
- The boundary between network ITOM in OSS and IT ITOM in the ITSM platform has to be designed, not assumed.
- Activation must write product inventory, service and resource inventory and the CMDB consistently, and changes and cessations must keep them consistent.
Architecture decision
Run network ITOM inside the ITSM platform, or keep it in OSS assurance and integrate?
Inside the ITSM platform
Choose when The network is small or mostly IT-like (enterprise, MVNO, cloud-heavy), and one data model matters more than telco-specific correlation
OSS assurance, integrated
Choose when A large multi-domain network with high alarm volume, where topology-aware correlation and NOC tooling are already in place
Breaks if The two estates never share identifiers with resource inventory: alarms then reach ITSM as tickets without impact, whichever side owns ITOM.
Takeaways
Key Takeaways
- Service assurance runs through three disciplines: ITSM manages services, ITOM operates the technology, ITAM governs the assets.
- They are IT-industry terms; ITSM and ITOM map onto eTOM Assurance, ITAM onto Enterprise Management.
- The domain starts at service activation: the SLA clock starts and ownership moves from the order stack to operations.
- Monitoring is ITOM; SLA and incident management (T2R) are ITSM; ITAM adds the cost, licence and lifecycle view.
- The pillars share records. If fulfilment does not write them, or they are not reconciled, none of the three can see the service.
Check yourself
A router has failed. Which pillar detects it, which tells the customer, and which knows whether it is still under support?Show answerHide
ITOM detects and correlates the fault (in a telco, usually OSS fault management in the NOC). ITSM raises the incident, works out the affected customers and SLAs, and communicates. ITAM holds the support contract, warranty and end-of-support date.
An order has been stuck in activation for three days and the customer complains. Is that an SLA breach handled by ITSM?Show answerHide
No. Before activation it is a fulfilment problem, measured against delivery dates and jeopardy rules. The availability SLA clock has not started; reporting it as an SLA breach double-counts.
Put this to work