6.112 min read

eTOM Framework Overview

What Is eTOM?

The enhanced Telecom Operations Map (eTOM) is the most widely adopted business process framework in the telecommunications industry. Published by TM Forum as GB921, eTOM provides a standardised vocabulary and hierarchical structure for describing every process a communications service provider (CSP) performs — from strategic planning to network fault resolution.

Think of eTOM as the blueprint for how a telco operates. It does not prescribe implementation details or specific technologies. Instead, it defines what processes exist, how they relate to each other, and where boundaries should fall between different operational domains.

eTOM — enhanced Telecom Operations Map

A comprehensive, industry-standard business process framework (TM Forum GB921) that defines all the enterprise processes required by a communications service provider. eTOM is part of the TM Forum Frameworx suite alongside SID (data model) and TAM (application model).

TM Forum Frameworx Triad

eTOM is one of three core TM Forum frameworks: eTOM (processes — what you do), SID (information — what data you manage), and TAM/ODA (applications — what systems you build). Together they form a complete architectural reference for any CSP transformation.

eTOM matters because it solves one of the biggest challenges in telco IT: everyone uses different names for the same things. When a CRM vendor says "order management," they may mean something very different from what an OSS vendor means. eTOM provides the shared language that eliminates this ambiguity.

The eTOM Framework Structure

eTOM is organised as a hierarchical decomposition of processes, starting from the broadest categories and drilling down to individual process activities. This hierarchy has five defined levels:

eTOM Decomposition Levels

Level	Name	Description	Example
Level 0	Process Areas	Three top-level groupings that divide all CSP activity	Operations
Level 1	Process Groupings	Major functional groupings within each area	Fulfilment
Level 2	Process Flows	End-to-end processes that deliver specific outcomes	Order Handling
Level 3	Process Tasks	Individual tasks within a process flow	Validate Order
Level 4	Process Steps	Detailed steps within a task (often implementation-specific)	Check Credit Limit

Most architectural discussions and vendor evaluations focus on Level 2 processes, as these represent the actionable process capabilities that can be mapped to systems. Levels 3 and 4 are typically defined during implementation and vary by organisation.

eTOM Framework — Level 0 and Level 1 Process Areas

Figure 6.1 — The eTOM Framework at Level 0 and Level 1, showing the three major process areas and their primary process groupings

The Three Major Process Areas (Level 0)

At the highest level, eTOM divides all CSP activity into three process areas. These are not just categories — they represent fundamentally different modes of operation with different timescales, governance models, and stakeholders.

Intermediate

Strategy, Infrastructure & Product (SIP)

Covers long-term planning, product lifecycle management, and infrastructure development. These are "build" processes — they define what the CSP will offer and how it will deliver.

SIP includes processes like Market Strategy, Product Lifecycle Management, Service Development, Resource Development, and Supply Chain Management. SIP processes run on a weeks-to-months cadence and typically involve product managers, network planners, and strategists.

Beginner

Operations (OPS)

Covers the day-to-day processes of selling, delivering, and maintaining services. These are "run" processes — they execute what SIP has defined.

Operations is the heart of eTOM for BSS/OSS architecture. It includes all customer-facing processes (marketing, selling, ordering, billing) and all operational processes (fulfilment, assurance, billing). Most BSS/OSS systems map primarily to Operations processes.

Intermediate

Enterprise Management (EM)

Covers corporate-level processes that support the entire organisation: HR, finance, legal, IT management, and stakeholder relations.

Enterprise Management processes are not telco-specific. They represent standard corporate functions that any large enterprise needs. While important, they are typically served by standard ERP and corporate IT systems rather than specialised BSS/OSS platforms.

Focus on Operations

For BSS/OSS training, the Operations area is where you will spend 80% of your time. SIP processes are important for understanding how products and services are designed, but Operations is where those designs are executed every day.

Operations: The Vertical Process Groupings

The Operations area is structured as a matrix of vertical process groupings (what you are doing) crossed with horizontal functional layers (where you are doing it). The three vertical process groupings represent the major operational outcomes a CSP must deliver:

Fulfilment

Fulfilment processes handle delivering what the customer ordered. This spans from receiving a validated order through to activating the service and confirming delivery. In eTOM, fulfilment is the chain of processes that turns a commercial intent into a working service.

Order Handling — receiving, validating, and tracking orders
Service Configuration & Activation — configuring and activating CFS/RFS instances
Resource Provisioning — allocating and configuring network resources
Service/Resource Testing — verifying that delivered services meet specifications

Assurance

Assurance processes handle making sure what was delivered keeps working. This includes proactive monitoring, reactive fault management, and performance optimisation. Assurance is the "trouble-to-resolve" domain.

Problem Handling — managing customer-reported issues
Service Quality Management — monitoring and maintaining service SLAs
Resource Trouble Management — detecting and resolving network faults
Performance Management — collecting and analysing performance data

Billing

Billing processes handle charging the customer for what was delivered. This covers usage collection, rating, invoicing, payment processing, and revenue assurance.

Billing & Collections Management — generating invoices and collecting payment
Charging — rating usage events and applying pricing rules
Revenue Assurance — ensuring no revenue leakage
Balance Management — managing prepaid and postpaid balances

Verticals in Action

When a customer orders broadband: Fulfilment activates the service, Assurance monitors the connection quality and handles any faults, and Billing charges the customer the monthly fee. All three verticals operate on the same service instance but from different perspectives.

Operations: The Horizontal Functional Layers

Crossing the vertical groupings are four horizontal functional layers. These represent the different operational perspectives through which processes execute. Each horizontal layer maps naturally to different system domains:

eTOM Horizontal Functional Layers

Layer	Focus	Key Concern	BSS/OSS Domain
Customer Relationship Management (CRM)	Customer-facing interactions	What does the customer need/want?	BSS — CRM, Self-Service, Contact Centre
Service Management & Operations (SM&O)	Service-level management	What CFS instances are involved?	OSS — SOM, Service Inventory, Service Quality
Resource Management & Operations (RM&O)	Resource-level management	What network resources are involved?	OSS — ROM, Resource Inventory, NMS/EMS
Supplier/Partner Management	Third-party interactions	What external parties are involved?	BSS/OSS — Partner Management, Interconnect

The matrix of verticals (Fulfilment, Assurance, Billing) against horizontals (CRM, SM&O, RM&O, S/PM) creates the eTOM Level 2 process grid — the most commonly referenced view of the framework. Each cell in this grid represents a specific process area, such as "Service Configuration & Activation" (Fulfilment x SM&O) or "Resource Trouble Management" (Assurance x RM&O).

Imagine a restaurant: Fulfilment is taking orders and preparing food. Assurance is checking that the food is good and handling complaints. Billing is presenting the bill and taking payment. The horizontals are like different staff: the waiter (CRM), the chef (SM&O), and the kitchen equipment (RM&O).

Each cell in the eTOM grid maps to one or more system capabilities. For example, "Order Handling" at the CRM layer maps to the Commercial Order Management (COM) system. "Service Configuration & Activation" at the SM&O layer maps to the Service Order Management (SOM) system. This grid is the foundation for process-to-system mapping.

The horizontal layers also correspond to TM Forum SID domains: CRM maps to Party/Customer SID entities, SM&O maps to Service SID entities, and RM&O maps to Resource SID entities.

In TM Forum ODA (Open Digital Architecture), each eTOM Level 2 process maps to an ODA functional block. The COM functional block implements CRM-layer fulfilment processes. The SOM functional block implements SM&O-layer fulfilment processes. This mapping is formalised in the ODA Component Inventory (TMF-ODA-CI).

ODA Canvas deployment maps eTOM Level 2 processes to specific microservices or components, each exposing TM Forum Open APIs. This is how eTOM translates from a process framework into an implementable architecture.

Why eTOM Matters for BSS/OSS Architecture

eTOM is not just an academic exercise. It is a practical tool that solves real problems in BSS/OSS architecture, vendor evaluation, and transformation programmes. Here is why it matters:

When a BSS vendor says "order management" and an OSS vendor says "order management," they often mean very different things. eTOM provides precise definitions: Order Handling (eTOM 1.1.1.6) at the CRM layer is commercial order capture. Service Configuration & Activation (eTOM 1.1.2.1) at the SM&O layer is service-level orchestration. Without eTOM, you are comparing apples to oranges.

eTOM and the SID Connection

eTOM defines what you do (processes). SID defines what data you manage (information entities). The two frameworks are tightly coupled: every eTOM process consumes, produces, or transforms SID entities.

eTOM Process to SID Entity Mapping

eTOM Process	Key SID Entities	Direction
Order Handling	ProductOrder, Customer, ProductOffering	Consumes ProductOffering, Creates ProductOrder
Service Configuration & Activation	ServiceOrder, CustomerFacingService	Consumes ProductOrder, Creates ServiceOrder
Resource Provisioning	ResourceOrder, LogicalResource, PhysicalResource	Consumes ServiceOrder, Creates ResourceOrder
Problem Handling	TroubleTicket, Customer, Service	Creates TroubleTicket, References Service
Billing & Collections	CustomerBill, AppliedCustomerBillingRate	Consumes usage, Creates CustomerBill

Process-Data Alignment

When designing integrations, always check both the eTOM process flow AND the SID data model. If a process crosses a system boundary, the data it passes should align with the relevant SID entities and be exposed via the corresponding TM Forum Open API.

eTOM Versioning and Industry Adoption

eTOM has evolved significantly since its first publication. The current version (as part of TM Forum Frameworx Release 22 and later) includes over 1,700 Level 3 process elements. However, no CSP implements all of them — the framework is a reference model, not a mandate.

Tier 1 CSPs (large incumbents) typically map 60-80% of eTOM Level 2 processes to their systems
Tier 2/3 CSPs (smaller operators, MVNOs) may focus on 30-50% of the framework
Vendors use eTOM to position their products and identify addressable market
System integrators use eTOM for gap analysis and solution architecture

eTOM Is a Reference, Not a Mandate

No organisation should try to implement all 1,700+ eTOM processes. The framework is a reference model. Pick the processes relevant to your business, map them to your systems, and use the framework to identify gaps — not to create unnecessary complexity.

eTOM in the Context of ODA

TM Forum Open Digital Architecture (ODA) represents the evolution of Frameworx into a cloud-native, component-based architecture. In ODA, eTOM processes are packaged into ODA Components — self-contained functional blocks that expose TM Forum Open APIs.

Each ODA Component is defined by the eTOM processes it implements, the SID entities it manages, and the TMF Open APIs it exposes. This creates a direct traceability from business process (eTOM) to data model (SID) to API contract (TMF Open APIs) to deployable component (ODA).

From eTOM Process to ODA Component

Identify eTOM Process

eTOM Framework

Select the Level 2 process you need to implement (e.g., Order Handling)

Map SID Entities

SID Framework

Identify which SID entities the process creates, reads, updates, or deletes

Select TMF Open APIs

TMF Open API Suite

Choose the TM Forum APIs that expose the required SID entities

Define ODA Component

ODA Canvas

Package the process, data, and APIs into a deployable ODA Component

Common Mistakes with eTOM

Mistake: Treating eTOM as an Org Chart

eTOM defines processes, not organisational departments. Multiple departments may participate in a single eTOM process, and a single department may contribute to multiple eTOM processes. Do not use eTOM to design your org structure.

Mistake: 1:1 Process-to-System Mapping

A single eTOM Level 2 process does not always map to a single system. A CRM platform might cover multiple eTOM processes across the CRM horizontal layer. Conversely, a single eTOM process like "Order Handling" might span COM and Product Inventory systems.

Mistake: Ignoring SIP Processes

Many architects focus exclusively on Operations processes and ignore Strategy, Infrastructure & Product. But SIP processes like "Service Development" and "Product Lifecycle Management" define WHAT gets sold and HOW it gets delivered. Without SIP, Operations has nothing to operate.

eTOM Framework Overview — Key Points

eTOM (GB921) is the industry-standard process framework for telecommunications, providing a shared language for BSS/OSS processes
It is organised hierarchically across Levels 0-4, with Level 2 being the most architecturally relevant
Three process areas: Strategy/Infrastructure/Product (build), Operations (run), Enterprise Management (corporate)
Operations is structured as a matrix: verticals (Fulfilment, Assurance, Billing) crossed with horizontals (CRM, SM&O, RM&O, S/PM)
eTOM processes map to SID entities and TMF Open APIs, forming a traceable architecture chain
Use eTOM for vendor evaluation, integration design, and transformation planning — not as an implementation mandate
In ODA, eTOM processes are packaged into deployable Components with defined API contracts