6.515 min read

Process-to-System Mapping

Why Map Processes to Systems?

One of the most powerful uses of the eTOM framework is mapping eTOM processes to BSS/OSS systems. This mapping reveals which systems own which processes, where gaps exist, where overlaps create confusion, and how well your architecture covers the operational needs of the business.

Without this mapping, architects are flying blind. They cannot answer basic questions like: "Which system handles service configuration?" or "Do we have a gap in our resource trouble management capability?" The process-to-system map is the single most useful artifact in any BSS/OSS architecture review.

The practice of systematically mapping eTOM Level 2 processes to the BSS/OSS systems that implement them. This creates a traceability matrix showing process ownership, system coverage, gaps, and overlaps across the enterprise architecture.

The Mapping Approach

Process-to-system mapping is done by taking the eTOM Level 2 process grid (verticals x horizontals) and, for each cell, identifying which system(s) implement that process. The result is a coverage matrix that shows the entire architectural landscape at a glance.

How to Create a Process-to-System Map

Select Relevant eTOM Processes

eTOM Framework

Not all 1,700+ eTOM processes are relevant. Select the Level 2 processes that matter for your business. Focus on the Operations area (Fulfilment, Assurance, Billing) across CRM, SM&O, and RM&O layers.

Inventory Your Systems

Enterprise Architecture

List all BSS/OSS systems in your landscape: CRM, Product Catalog, CPQ, COM, SOM, ROM, Billing, Service Inventory, Resource Inventory, Fault Management, etc.

Map Each Process to System(s)

Architecture Review

For each eTOM L2 process, identify which system(s) implement it. Mark the ownership type: Primary (owns the process), Contributing (supports the process), or None (gap).

Identify Gaps and Overlaps

Gap Analysis

Analyse the completed matrix for gaps (processes with no system coverage), overlaps (processes covered by multiple systems), and misalignments (systems covering processes they should not own).

Define Target State

Target Architecture

Based on the gap analysis, define the target architecture: which system should own each process, where new systems are needed, and where consolidation should occur.

The eTOM-to-System Coverage Matrix

The following matrix shows a typical mapping of eTOM Level 2 Operations processes to BSS/OSS systems. This is a reference pattern — actual mappings vary by organisation, vendor selection, and architecture decisions.

Process-to-System Mapping Matrix — eTOM L2 Operations processes mapped to BSS/OSS systems

Figure 6.5 — Process-to-System mapping matrix showing eTOM L2 processes across the Operations area mapped to typical BSS/OSS systems

Fulfilment Process Mapping

Fulfilment Processes — System Ownership

eTOM L2 Process	Layer	Primary System	Contributing Systems	TMF API
Marketing Fulfilment Response	CRM	Marketing Platform	Product Catalog, CRM	TMF691
Selling	CRM	CRM	CPQ, Product Catalog	TMF629
Order Handling	CRM	COM	CRM, Product Catalog, CPQ	TMF622
Service Configuration & Activation	SM&O	SOM	Service Inventory, Service Catalog	TMF641
Service Testing	SM&O	Test Management	SOM, Service Inventory	TMF653
Resource Provisioning	RM&O	ROM	Resource Inventory, Activation, EMS	TMF652
Resource Testing	RM&O	ROM / EMS	Resource Inventory, NMS	TMF653
S/P Requisition Management	S/PM	Partner Management	COM, SOM	TMF648

Assurance Process Mapping

Assurance Processes — System Ownership

eTOM L2 Process	Layer	Primary System	Contributing Systems	TMF API
Problem Handling	CRM	Trouble Ticket System	CRM, Service Desk	TMF621
Customer QoS/SLA Management	CRM	SLA Management	CRM, Service Quality	TMF623
Service Quality Management	SM&O	Service Quality Mgmt	Service Inventory, SOM	TMF656
Service Problem Management	SM&O	Fault Management	Service Inventory, SOM	TMF656
Resource Trouble Management	RM&O	NMS / Fault Mgmt	Resource Inventory, EMS	TMF642
Resource Performance Management	RM&O	Performance Mgmt	NMS, Analytics	TMF642
Resource Data Collection	RM&O	Mediation / NMS	EMS, Analytics	N/A

Billing Process Mapping

Billing Processes — System Ownership

eTOM L2 Process	Layer	Primary System	Contributing Systems	TMF API
Billing & Collections	Billing	Billing System	CRM, Revenue Assurance	TMF678
Charging	Billing	Charging Engine	Rating Engine, Mediation	TMF654
Revenue Assurance	Billing	Revenue Assurance	Billing, Mediation	N/A
Balance Management	Billing	Balance Mgmt	Charging Engine, Self-Service	TMF654

Gap Analysis Patterns

Once the process-to-system map is complete, several common patterns emerge. Recognising these patterns helps prioritise architecture improvements:

A process gap exists when an eTOM process has no system coverage. This means the process is either not being performed, is being done manually (spreadsheets, email), or is handled by a system not designed for the purpose.

Common gap: Service Quality Management — Many telcos have resource monitoring (NMS) but no service-level quality management
Common gap: Partner/Supplier Management — Often handled manually or via email/spreadsheets
Common gap: Product Lifecycle Management — Catalog updates done ad-hoc without formal lifecycle processes
Common gap: Revenue Assurance — Especially in smaller operators

Not Every Gap Needs Filling

A process gap is not automatically a problem. If your business does not require a process (e.g., a small MVNO may not need complex partner management), the gap is acceptable. Only invest in filling gaps that have real business impact.

Using eTOM for Vendor Evaluation

The process-to-system map becomes an incredibly powerful tool for vendor evaluation. By mapping each vendor's capabilities to eTOM Level 2 processes, you create an objective, standardised comparison that cuts through marketing noise.

eTOM-Based Vendor Evaluation Process

Define Scope

Requirements

Identify which eTOM L2 processes are in scope for the vendor selection. For a BSS replacement, focus on CRM-layer processes. For an OSS replacement, focus on SM&O and RM&O layers.

Create Evaluation Matrix

Evaluation Framework

Build a matrix with eTOM L2 processes as rows and candidate vendors as columns. Add a column for the current system as baseline.

Vendor Self-Assessment

Vendor Response

Ask each vendor to map their product capabilities to the eTOM processes in scope. Use a rating scale: Full, Partial, Planned, Not Covered.

Independent Validation

Architecture Review

Validate vendor claims through demos, reference checks, and proof-of-concept exercises. Vendors often overstate coverage.

Gap/Fit Analysis

Decision Support

Compare validated vendor coverage against your requirements. Identify gaps that require customisation, integration, or complementary systems.

Vendor Coverage Claims

Be sceptical of vendor claims of "full eTOM coverage." No single vendor covers all eTOM processes. Most BSS vendors cover 15-25 eTOM L2 processes well, with partial coverage of another 10-15. The key is whether the vendor covers YOUR priority processes, not the total count.

Think of eTOM as a shopping checklist. Each eTOM process is an item on the list. When evaluating a vendor, check off which items their product covers. Compare vendors by how many items they check and, more importantly, which specific items match your priorities.

Beyond simple coverage, evaluate the depth and quality of each vendor's process implementation. A vendor may claim "Order Handling" capability, but does it support complex bundles? In-flight modification? Multi-step orchestration? TMF622 compliance? The eTOM process name is the starting point; the Level 3/4 decomposition reveals the depth.

TM Forum offers Open API Conformance certification for vendors. A vendor certified for TMF622 has demonstrated that their Product Ordering API conforms to the standard payload structure and lifecycle. Use TM Forum conformance as an objective validation alongside your own testing. Check the TM Forum Open API Conformance directory for certified products.

Source of Record by Process Domain

The process-to-system map also clarifies Source of Record (SoR) ownership. Each eTOM process domain has clear data ownership boundaries that must be respected in integration design:

Source of Record Across eTOM Process Domains

Entity	System of Record	System of Engagement	System of Reference	Notes
Customer / Account	CRM	Self-Service / Retail / Contact Centre	CRM	Single customer master across all processes
Product Offering / Catalog	Product Catalog	CPQ / Self-Service	Product Catalog	Commercial product definitions
Product Order	COM	CRM / Self-Service	Product Catalog	Commercial order lifecycle
Product Instance	Product Inventory	CRM / Self-Service	Product Catalog	What the customer currently has
Service Order	SOM	SOM Dashboard	Service Catalog	Service-level fulfilment orchestration
CFS Instance	Service Inventory	SOM / Assurance Tools	Service Catalog	Active customer-facing service instances
Resource Order	ROM	ROM Dashboard	Resource Catalog	Resource-level provisioning orchestration
Resource Instance	Resource Inventory	NMS / ROM	Resource Catalog	Active network resources and topology
Trouble Ticket	Trouble Ticket System	Service Desk / Self-Service	—	Assurance process tracking
Invoice / Bill	Billing System	CRM / Self-Service	—	Customer billing records

Real-World Architecture Patterns

In practice, telco architectures fall into several common patterns based on how they map eTOM processes to systems. Understanding these patterns helps you recognise your own architecture and plan improvements.

A single vendor's integrated suite covers most eTOM processes across BSS and OSS. This maximises out-of-the-box integration but creates vendor lock-in and limits best-of-breed selection.

One vendor covers 70%+ of eTOM L2 processes
Internal integrations are pre-built
Customisation options may be limited
Common with Amdocs, Netcracker, Ericsson full-stack deployments
Risk: total dependency on single vendor roadmap

Building Your Own Process-to-System Map

To create a process-to-system map for your organisation, follow this practical methodology:

Start with the eTOM Level 2 grid — download the TM Forum eTOM poster or use the Frameworx tool. Focus on the Operations area.
Interview system owners — for each BSS/OSS system, ask its owner which eTOM processes it supports. Use the eTOM vocabulary to avoid ambiguity.
Cross-reference with vendor documentation — most vendors publish eTOM mapping documents. Use these as a starting point but validate with your actual deployment.
Mark ownership types — for each cell in the matrix, indicate: Primary Owner, Contributing System, or Gap.
Identify shadow systems — ask operational teams about spreadsheets, scripts, and workarounds. These indicate unmapped gaps.
Document integration points — for each process that spans multiple systems, document the integration mechanism (API, file transfer, manual).
Present to stakeholders — the completed map is an incredibly effective communication tool for showing the current state and making the case for investment.

Start Small, Iterate

Do not try to map all 1,700+ eTOM processes in your first attempt. Start with the 20-30 most critical Level 2 processes in the Operations area. Get those mapped accurately, validated, and socialised. Then expand to SIP processes and more detailed Level 3 decomposition.

Process-to-System Mapping Anti-Patterns

Anti-Pattern: The Capabilities Graveyard

Vendor systems often have more capabilities than are actually deployed and used. Do not map a process to a system just because the system could theoretically support it. Map based on what is actually deployed, configured, and in use today.

Anti-Pattern: Ignoring Human Processes

Some eTOM processes are implemented by people, not systems. A "Service Problem Management" process might be executed by NOC engineers using their expertise plus basic tools. Mapping this as "no system coverage" is accurate but the process still exists — document it as a manual process requiring system support.

Anti-Pattern: Confusing Capability with Ownership

A system may participate in a process without owning it. For example, CRM participates in Order Handling by providing customer data, but COM owns the Order Handling process. Distinguish between "this system contributes to the process" and "this system owns the process."

Process-to-System Mapping — Key Points

Process-to-system mapping creates a traceability matrix from eTOM L2 processes to BSS/OSS systems
The coverage matrix reveals gaps (no system), overlaps (multiple systems), and misalignments (wrong system)
Common gaps: Service Quality Management, Partner Management, Product Lifecycle Management
Common overlaps: Order Management, Product Catalog, Trouble Ticketing
The mapping is the most powerful tool for vendor evaluation — compare vendors against standardised eTOM criteria
Source of Record must be clearly assigned for each entity produced by each process
Real-world architectures follow patterns: monolithic, best-of-breed, hybrid, or ODA component-based
Start small (20-30 key L2 processes), validate with system owners, and iterate to build your map