The Mysterious Sector 4 in a Telco IT Stack

When it comes to driving efficiency and profitability in a service provider’s business, I feel there are three key pillars to consider (aside from strategic factors of course), as follows:

1. The IT stack, led by the OSS/BSS
2. The networks and
3. The field services 

The networks are vital. They are effectively each organisation’s product because connectivity across the network is what customers are paying for. They must be operating effectively to attract and retain paying customers.

The field services are vital. They build and maintain the networks, ensuring there is a product to sell to customers.

The OSS/BSS are arguably even more vital. Some may argue that they only provide a support role (the middle S in OSS and in BSS would even suggest so!). They’re more than that. OSS/BSS are the Profit Engine of a service provider. 

But let’s take a closer look at the implications of effectiveness and profitability in the overlapping sectors in the Venn diagram above and why OSS/BSS are so important.

Sector 1. OSS / BSS <-> Networks

The OSS/BSS connects customers with the product (buyers with sellers). Even if we remove this powerful factor, OSS and BSS have other key roles to perform. They connect and coordinate. They hold the key to efficiency and utilisation and, in turn, profitability.

Sectors 2&3. OSS / BSS <-> Field Workforce and Network

The OSS/BSS manages the field workforce, assigning what to do and when. But before that, our OSS/BSS provide the tools to decide why the work needs doing. They identify:

• What needs to be built (network designs)
• What capacity is required (by identifying performance gaps now or in the future)
• What customers need to be connected, where and how
• What are the root problems that need to be fixed to ensure customers are well served

That covers sector 2. But sector 3 appears to be separated from the OSS/BSS. It is, the field workers work directly on the network. However, they generally only do so after direction from the OSS/BSS (eg via work orders, trouble tickets, etc). Hence, they’re merged here.

Summary – Efficiency and The Profit Engine

You might be wondering why I missed sector 4. You might also be wondering whether the last sentence above, with the OSS/BSS pulling the strings of field work on networks, represents sector 4. Well, yes, but be patient and we’ll come back to sector 4, but with a slightly different (and potentially more powerful) perspective than that.

From the two previous sections, you would have noticed just how important OSS and BSS are to a network service provider. They directly influence:

• Taking sales orders
• Processing orders to ensure they’re activated
• The time to market, of new services, of new product offerings, build of support infrastructure, reactivation of damaged infrastructure or warrantied equipment and more
• Identification of problems and what needs to be done to fix them
• Preventative maintenance to minimise the degradations / outages occurring 
• Allocation of resources and their lifecycle management
• Optimising the capital in the network by balancing capacity (available resources vs utilisation)
• Managing revenues (preparation of invoices, issuing bills, collections, etc)
• Combining the many people, skills and their availability with assets, materials, certifications, etc to ensure work is prioritised and coordinated through to completion
• The speed of getting people to site and on to the next after finishing a job
• The scalability / repeatability of the factors above and more
• The identification of repeatable actions that are then worthy of automation and/or improvement
• Logging and visualising the performance of people, processes and technologies (in real-time and over longer trend-lines), providing the benchmarks and levers to manage any of those factors if they’re going outside control bounds
• The list goes on!!!

When you consider the daily volumes of each of those factors at large telcos, you’ll understand how a 5% improvement or deterioration in any will have a significant implication on profitability. The profitability of an organisation is massively helped, or hindered, by OSS/BSS, though few people seem to realise it.

The Elusive Sector 4. Combining OSS/BSS, Network and Field Services.

I promised to come back to sector number 4 in the Venn diagram above and give a different perspective. There’s an opportunity that exists here that few are capitalising on yet.

But first a recap. Sector 1 is best characterised by the tools used by a NOC (Network Operations Centre) and SOC (Service Operations Centre), as well as their various metrics like time to repair, up-time / availability, etc.

Sectors 2 and 3 are best characterised by the tools used by a WOC (Workforce Operations Centre) and metrics like number of truck rolls, jobs completed, etc.

The analytics that are available at sector 4 are profound, but rarely used. Let me describe via a scenario:

• There is an outage in region A identified in the NOC. They create a ticket for copper cable #1 to be replaced
• The WOC picks up the ticket and a worker is sent to repair copper cable #1
• This repeats over the next few weeks. Copper cables # 2, 3, 4, 5 and more are also repaired in region A
• It’s clear from my description that a systematic problem exists in region A, but the NOC and WOC are both more transactional in nature and have SLAs to meet so they’re not looking for endemic issues
• And how does that tie in with longer-term capacity planning and traffic engineering

The OSS/BSS has the ability to provide the role as an overseer, observing not just the transaction metrics, but also considering effectiveness and profitability. It is able to consider:

• Each outage is having an impact on availability, potentially costing money via rebates and is damaging the brand
• Each outage is introducing costs of repair teams as well as replacement material costs
• The copper network doesn’t provide as much head-room for higher-speed offerings to customers, which represents an opportunity cost
• The reliability and availability uplift of an optical node versus a copper node in region A
• The long-term cost profile of a new fibre network versus a deteriorating copper network
• The costs of inserting a new optical node and removal of the copper node (and associated cables, connectors, network termination devices, etc)
• The customer profiles connected to the network that are likely to take higher speed services if made available
• The overall CAPEX and OPEX allocation of spend on the network (in terms of assets, resources, workforce effort expended, etc)
• The long-term planning / engineering that considers new technologies, growth / change in network footprint, change in demand profiles, etc
• etc

With all of this knowledge at the fingertips of the OSS/BSS, it could decide to inject a new work order into the work queue, starting with a network design (possibly automated), acquisition of assets / materials (possibly automated), notification to customers of network uplift (resulting in outage notifications, but also better performance and higher-speed offerings – possibly automated), creation / scheduling / dispatch of jobs to deconstruct / construct / commission infrastructure in region A, then notify customers of availability of service.

The metrics that matter at sector 4 are less about transactions and more about higher-order objectives like effectiveness and profitability. It also has the potential to take a longer-term view to align short-term decisions with long-term objectives (eg technology objectives such as “fibre deeper” [ie fibre being extended closer to end-users to facilitate higher bandwidth services], CAPEX/OPEX optimisation for ROI, network footprint changes, etc).

In many cases, network operators don’t have these near-real-time decision support tools at hand. If network uplift is to be performed, it’s decided across an entire service area by capacity planning teams rather than in more granular regions.

This is only one scenario for what could be achieved at sector 4. I’m sure we can imagine more if we start building the tools here.

Also consider the different speeds that the OSS/BSS need to cater for and optimally allocate as part of end-to-end workflows:

• Some activities are fast – virtualised networks have the ability to self-manage / self-optimise so changes are occurring in this part of the network dynamically and automatically
• Some activities are medium-speed – logical changes in networks such as configuration updates or logical connectivity, are performed with only a short turnaround and are pushed to the network
• Other activities are slow – physical infrastructure builds such as new sites, cables, new technologies, etc can often take months of planning and build activities (with many sub-activities to manage). The overlay of demographic data with geographic data provides valuable sales/marketing prospecting insights (eg how much unmet demand is within 215m of an existing fibre node, where you’ve previously determined that customers that are less than 215m away is the breakeven point where build costs are less than revenue / profitability targets)