The Definition of OSS and BSS

What is OSS and BSS? Getting back-to-basics can be a challenge at times. How to explain what OSS and BSS mean? Concisely. Accurately. There’s always been debate and opinion on their respective roles. And people can’t even agree what OSS stands for. OSS Line shines a light on this thorny but fundamental topic…

OSS is either Operational Support Systems or Operations Support Systems.

You have too much time on your hands if you want to argue over which is the ‘correct’ definition. Historically, I have used Operational, but I acknowledge that Operations sort of makes more sense when you think about it…

BSS stands for Business Support Systems. Simple. No debate.

What are Operational Support Systems?

Software (occasionally hardware) applications that support back-office activities which operate a telco’s network, provision and maintain customer services.

OSS is traditionally used by network planners, service designers, operations, architects, support, and engineering teams in the service provider. Increasingly product managers and senior staff under the CTO or COO may also use or rely on OSS to some extent.

What are Business Support Systems?

Software applications that support customer-facing activities. Billing, order management, customer relationship management, call centre automation, are all BSS applications.

BSS may also encompass the customer-facing veneer of OSS applications such as trouble-ticketing and service assurance – these are back-office activities but initiated directly by contact with the customer.

This basic relationship between OSS and BSS, where OSS is passed service orders and supplies service assurance information to the BSS layer is often referred to as ‘Orders Down, Faults Up’.

Is the integration between OSS and BSS clear?

In the past, OSS/BSS had a clearer separation. A common job like capturing a customer order and provisioning it required a simple BSS-to-OSS interface. “Deliver product X to customer Y”. BSS would capture the order, set-up the billing and pass the order to OSS for fulfillment.

Now, networks and services are more complicated, more flexible, and telcos offer a range of differentiated products. OSS and BSS must liaise over what could be ordered by the customer, based on what service they already had, based on the network they would use, based on current available resources, based on how far they were from the telephone exchange… and so on. Offering a customer a service is now a negotiation between the commercial products managed by BSS and the ability of OSS (and the local network) to deliver certain products.

As a result, a number of systems now straddle OSS/BSS:

Service Assurance systems are now integrated across OSS/BSS in order to track service performance and ensure customer service-level agreements (SLA) are met. Service Assurance may also pro-actively identify network failures, initiating resolution action and notifying high-priority customers.
Service Catalogs (a.k.a. Product Catalogs) give the telco one place to list products offered to customers and define what network resources can be used to deliver the service. Service Catalogs offer product managers a tool that joins-up the service offering and fulfillment processes across BSS and OSS.
Service Management applications allow greater interaction between OSS and BSS processes when the service order and fulfillment process is complex. If a service order comprises multiple technical resources, which are delivered by multiple OSS systems, Service Management is responsible for orchestrating the fulfilment process and keeping the customer-facing team informed about progress, changes or deliver issues.

There’s now less debate about what these cross-OSS/BSS systems do, but still plenty of uncertainty about who’s budget the implementation project comes out of…