In The Frameworx Suite, eTOM was the construction sequence: the How. This post is the grid itself.
You do not need SID or the Open API posts yet. You do need a shared answer to a boring question that kills programmes: when two teams say “order management,” are they talking about the same work?
At a Glance
- eTOM is the Business Process Framework — a hierarchical catalogue of operator processes, not a workflow engine you install.
- Level 0 is three process areas: Strategy, Infrastructure & Product; Operations; and Enterprise Management. Operations’ customer-facing heartbeat is FAB: Fulfillment, Assurance, Billing.
- Public eTOM is strongest through Level 3. Level 4 is often the operator’s own procedure. One named flow — order-to-activation — is worth more than a poster of the whole map.
Why a process map
Frameworx gives you four drawings of the same operator. This article is only the first: the sequence of work. SID will name the objects. TAM and the Functional Framework will name where software sits. Open APIs will move the objects. None of that helps if “fulfillment” means three different swimlanes in three different rooms.
That is the problem eTOM was built to shrink. A company in London and a company in Tokyo can describe the same order-to-cash path with the same words. Vendors can map a bid to a process, not to a local nickname. Transformation workstreams can be named after work, not after systems.
It is still a reference model. You align to eTOM. You do not “go live on eTOM.” No operator runs the poster as a literal workflow. The value is a common language so you can argue about how well you fulfill, instead of arguing about whether order management means capture, credit check, or activation.
Industry reality: The grid on the war-room wall is not the operating model. A decomposed flow is. Wallpaper is not a transformation.
Level 0 — three process areas
The Business Process Framework (eTOM) — Enhanced Telecom Operations Map, if you still use the old expansion — starts as three bands.
Strategy, Infrastructure & Product (SIP) is the long game. What will we sell? What network and IT will we build or retire? Which partners do we need? If you only staff Operations, you get very efficient at delivering last year’s products.
Operations is the heartbeat. Take the order, keep the service running, get paid. This is where most “why is this taking 18 months?” stories actually live — not because strategy is easy, but because every customer request collides with fulfillment, assurance, and billing at once.
Enterprise Management is the company that makes the other two possible: finance, HR, IT, risk, knowledge. Telco architecture conversations skip this band and then rediscover it when a process needs a legal hold, a supplier contract, or an identity from corporate IT.
Cut across those bands and you get the horizontal views eTOM uses so a process is never only “the billing team’s problem”:
- Customer — the relationship and the request
- Service — what is actually delivered
- Resource — the network and IT that deliver it
- Supplier / Partner — who you buy from or sell with
A mobile order that never mentions resource or partner is a slide, not a design. The horizontals are how eTOM stops you from drawing a happy customer path that ignores the radio network and the MVNO.
For Strategy: Level 0 is an operating-model sketch. Use it to name workstreams and owners. Do not use it as a 200-box RFP.
For Developers: You will not code “SIP.” You will see these names in architecture docs when someone maps a TMF API to a process. The API is not the process. The process is why the API exists.
FAB — the operations heartbeat
Inside Operations, the vocabulary that still shows up in vendor workshops and SI programmes is FAB.
Fulfillment is everything from “the customer wants this” to “the service is on.” Capture, qualify, design, assign, activate, hand over. If you cannot name the fulfillment path, you do not have an order-to-cash process. You have a ticket pile.
Assurance starts when the service is supposed to be live. Monitor, detect, restore, prevent. A drop in throughput, a failed cell, a customer “it’s slow” — that is not a new order. It is assurance. Mixing assurance into fulfillment is how you get “the order is still open because the site was down.”
Billing and revenue management is charge, collect, adjust, and explain. It is not “the billing system.” It is the work of turning a live service into money without inventing a second customer. When fulfillment forgets to tell billing the service is live, you get free data and an angry finance team. When billing runs without a true inventory, you get bills for services that were never activated.
There is a fourth operations grouping you will meet in the full framework: Operations Support & Readiness (OSR) — the backstage that makes FAB possible (workforce, spare capacity, catalogs kept current). FAB is the customer-facing heartbeat. OSR is why the heartbeat has a floor to stand on. For this series, remember OSR exists; we will keep using FAB as the teaching core.
FAB is also why two “order management” vendors are not interchangeable. One may be strong in capture (fulfillment) and empty in assurance. The map lets you say that in a meeting without a three-hour glossary.
Decomposition: Level 0 to Level 3
eTOM is a hierarchy. Each level is a finer grain of the same process, not a new framework.
Level 0 is the three process areas.
Level 1 is the grouping inside an area — Fulfillment, Assurance, Billing; or Product Lifecycle Management in SIP.
Level 2 is a core process you can put on an operating-model page: Order Handling, Service Configuration & Activation, Problem Handling, Billing Events.
Level 3 is the design grain: tasks you can own, staff, and measure. Issue Service Order. Track and Manage Customer Order. Report Service Problem. This is where RACI charts stop being fiction.
Level 4 is where many decks go wrong. Teams treat “L4+” as if TM Forum shipped a complete work-instruction library. A lot of Level 4 is enterprise-specific: the click-path in your order manager, the local check with your credit bureau, the script in your NOC. Align the L3 names. Write L4 as your own procedure. That is not a failure of the standard. That is what reference models are for.
For Developers: eTOM process IDs show up next to API mappings (“this TMF622 call supports Order Handling”). They are not REST resources. You cannot GET /etom/1.2.3. You implement the interface that carries the work the process names.
The practical rule: decompose until you can assign an owner and a measure. If the next box is a system screen, you have probably left the public framework and entered your estate.
Use case: order-to-activation
Posters do not ship service. A flow does. Take a familiar path: a customer orders a mobile plan, and we need it live.
- Request. The customer (or a shop, or a partner) asks for a plan. Horizontal view: Customer. Process area: Operations. FAB: Fulfillment.
- Qualify. Can we sell this offer here, to this customer, on this network? Still fulfillment. This is where “the catalog said yes and the radio said no” should be a named step, not a surprise at activation.
- Order. Capture and validate. What was requested becomes a customer order with a state machine, not a chat message.
- Assign. The service to be delivered and the resources that will carry it are designed and reserved. Customer, service, and resource views all show up. If you skip resource, you have sold a slide.
- Activate. The network and IT are told to make it so. Handover: the service is live.
- Bill. Charging starts; what the customer holds matches inventory. You have crossed from fulfillment into billing. Finance is now on the path, not copied later in an email.
If the site fails next Tuesday, you have left this path. That is assurance — restore the service you already fulfilled. Do not reopen the original order as if the customer ordered a outage.
Two teases, then we stop:
The objects on this path — product offering, customer, service, resource — are SID. That is the next post. The calls that will execute it in software — Product Order (TMF622), Service Order (TMF641) — are Open APIs. Those come when we leave the process map and enter the mortar.
A London team and a Tokyo team can now argue about step 4 (assign) using the same words. That is the whole point of the grid.
How teams actually use eTOM
Used well, eTOM is a naming system for work:
- Operating model. Who owns fulfillment versus assurance? The map is the agenda, not the answer.
- Transformation. Workstreams named after processes survive vendor changes. Workstreams named after systems do not.
- RFPs. Ask vendors to map to FAB (and to the L2/L3 you actually care about). You will see the gaps before year two.
- Audit and assurance of the programme itself. “Show me order-to-activation” is a better request than “show me the eTOM certificate on the wall.”
The failure mode is the opposite: print Level 0 at A0, hang it behind the steering committee, and never decompose a real flow. Then every vendor is “eTOM-aligned,” and none of them share a process.
3 questions for your team
- When we say “order management,” which FAB band and which Level 2 process do we mean — and do the other rooms agree?
- Can we walk one order-to-activation path to Level 3 with named owners, or only to a poster?
- Where does our Level 4 start — and have we mistaken our own procedures for the standard?
Key takeaways
- eTOM is the shared process language. FAB is the operations core; SIP is the long game; Enterprise Management is not optional scenery.
- Decompose to Level 3 for design. Treat Level 4 as local procedure unless you have a good reason not to.
- One named flow beats the whole grid. Order-to-activation is how you prove the map is for work, not for wallpaper.
Next in this series: the Information Framework (SID) — the What. We will put product, service, resource, and the Party vs Customer distinction on the same order you just walked.
Leave a Reply