C2M, L2C and T2R: The Three Clocks

The three end-to-end value streams a transformation typically addresses, what each one produces, and why each can only ever be as good as the one before it.

C2M, L2C and T2R are the three end-to-end value streams a telecom BSS/OSS transformation should typically address. Concept-to-Market (C2M) turns an idea into a sellable product. Lead-to-Cash (L2C) turns an opportunity into revenue. Trouble-to-Resolve (T2R) takes a problem through to resolution.

The three streams and the stages inside each. Grouped rather than exhaustive — the point is the shape of each scope, and where one ends and the next begins.

They are the three main pillars, not the complete set. TM Forum enumerates its end-to-end streams slightly differently across publications, but the recognised set also includes Usage-to-Cash (drawn in some material as Order-to-Payment), Request-to-Answer for customer interactions that are neither an order nor a fault, Termination-to-Confirmation for cease and churn, and Onboard-to-Operate for partner and wholesale. An operator with a significant MVNO or wholesale business has a major transformation stream the triad does not name, and cease is where a great deal of installed-base pain actually lives. The work that most often sinks a programme — data migration, integration architecture, operating model and governance — cuts across all of them rather than belonging to any one.

Almost every architecture diagram draws them side by side, as though they were three departments doing three jobs. They are not parallel: they are dependent, they run on different clocks, and the order matters more than the boxes.

Three processes, three clocks

The distinction that matters most is not what each process does but when it runs. Design-time work is versioned and released; runtime work is executed and logged. Treating one as the other is the root of a whole class of transformation failure.

Three processes, three clocks. Durations vary by operator and by product, so what matters is not the number but the character: one pillar is governed and versioned, the other two execute and log, and each leaves behind the thing the next one depends on.

Read each pillar from its base. A process is judged by the artefact it leaves behind, not by the activity it performs. C2M has not finished when a concept is approved; it has finished when a catalog entity is published and readable by the systems that will execute against it. L2C has not finished when a service works; it has finished when the installed base records what the customer has and which catalog entity it came from. T2R has not finished when an alarm clears; it has finished when the reason it left is recorded against something the next design cycle can find.

The Chain Constraint

L2C can only execute what C2M defined. T2R can only assure what L2C instantiated.

Both halves of that sentence are limits on capability, not advice. An order cannot be captured for an offer that was never modelled — the capture system has no entity to attach it to, no price to apply, and no decomposition to hand to fulfilment. A fault cannot be correlated to a customer whose service was never written to inventory — the correlation is a lookup, and the row is not there.

This is why "we will fix it in operations later" fails. It sounds like sequencing — do the modelling after go-live, when there is time. It is not. Operations can add data; it cannot add semantics. A hand-keyed inventory row asserts that something exists without recording how it came to exist: no link to the order that created it, no link to the catalog entity it instantiates, no way to rebuild it if it is lost. Impact analysis, MACD, revenue assurance and SLA attribution all need the second question — what is this, and what is it part of? — and that answer has to be created at design-time, before the order is ever taken.

The dependency runs the other way as a constraint too. A commercial catalog implemented with no runtime consumers — no COM decomposing against it, no SOM reading its CFS definitions — is a design-time artefact that never becomes a constraint on anything. It looks like progress on a programme plan and changes nothing about how orders are actually fulfilled.

The chain closes: chronic-fault patterns and take-up data from T2R are the only honest inputs to the next C2M cycle.

Three Processes Are Not Three Programmes

Drawn as parallel lanes, the chain suggests three workstreams that can be funded, sourced and delivered independently. They cannot. A catalog programme delivered without runtime consumers publishes entities nothing reads. An order management programme delivered against the old catalog model inherits every limit that model had. An ITSM programme delivered without a trustworthy installed base delivers ticket workflow and calls it assurance. Each is defensible on its own business case, and each fails on the dependency it did not own.

The three handoff artefacts

The chain is easier to reason about if you ignore the process names for a moment and look only at what crosses each boundary. Three artefacts do all the work.

A published catalog

The output of C2M is a versioned, effective-dated set of catalog entities: what can be sold, what each offer decomposes into, what it costs and who is eligible. Published is the load-bearing word. An entity that exists in a design tool but has not been released to the systems that execute against it has not been handed over — it is work in progress that looks like a deliverable.

An installed base

The output of L2C is the runtime record of what each customer actually has — subscription, service instances, assigned resources — each linked to the next and back to the catalog entity it came from. Section 5.6 treats this as a domain in its own right; here it matters only as the artefact T2R needs in order to have anything to work with.

Most brownfield estates hold a partial version of this rather than a total one, which is harder to see and harder to fix. Services activated before the current model existed, or migrated under a clean-up-later strategy, sit linked to network truth but not to any catalog entity — or the reverse. They are correlatable in one direction only, and nobody knows which records those are until an incident proves it.

A restored service

The output of T2R is the service returned to its committed state, plus the record of why it left. The second half is the part usually lost. A ticket closed against a symptom and a resolving team tells the next design cycle nothing; one closed against the service instance, the catalog entity behind it and a cause tells it a great deal. Most ITSM classification schemes are built for the first, because they were designed for IT services rather than a product portfolio.

The damage is not the symptom, it is the workaround: each break produces something improvised, and the improvisation is what makes the cost permanent. Note the third row — its immediate symptom is nothing at all, which is why it is the break that persists.

The chain is a cycle, not a line

Chronic faults, take-up and cost-to-serve are the only inputs describing what this estate actually did. Benchmarking tells you what to want, not what you can deliver at the price you are about to publish.

The loop is badly matched. T2R produces evidence continuously, C2M absorbs it per release, and no standard tooling bridges the gap — so the return path is an escalation or a quarterly review, not a data flow. It is the weakest link in the chain.

What the Cycle Does Not Fix

Closing the loop improves the next cycle. It does nothing for the installed base already in the ground, which stays on the model it was sold under until migrated or ceased. That is a migration problem, not a design one.

Where this academy sits in the chain

Every module belongs to one phase — the index and sidebar are banded accordingly, and each phase has its own page. Foundations is orientation; TM Forum, architecture and vendor modules are reference.

The next section decomposes the middle link: L2C is itself L2O, O2A and O2C, and their boundary is where the BSS/OSS split is crossed.

Section 1.4 Key Takeaways

C2M, L2C and T2R are dependent, not parallel — each is bounded by what the one before it produced
C2M is design-time and runs per product; L2C and T2R are runtime and run per order and per incident
L2C can only execute what C2M defined; T2R can only assure what L2C instantiated
The handoff artefacts are concrete: a published catalog, an installed base, a restored service
The chain is a cycle — T2R's chronic-fault and take-up data is the only honest input to the next C2M cycle
"We will fix it in operations later" fails because operations cannot add semantics that design-time never created