You own a good car but a flat tire or a simple engine failure forces you to buy a new one. What a headache, right? But this is not only a problem for the consumer. The manufacturer wants to launch a new version of the same car, with a better engine. However, it takes them two years, because making even a small change means they have to redesign the car from scratch. It really is a pain.
The same thing is happening today with the product catalogs of communication service providers around the world. Rates, charges and bundles are created and defined in online charging and billing systems while other components of the BSS and OSS stacks such as order capture, order management and provisioning systems have their own embedded catalog database that needs to be updated so they can start selling new offers or update existing ones. This makes launching new offers and making simple updates to, for example, pricing plans, an extremely slow and complex process.
Existing challenges
Throughout the years service providers have faced different challenges. With every network evolution, they’ve had to adapt to manage different customer requirements. Each solution in their BSS ecosystems also had to be updated or swapped according to their own timelines. For example, when data allowances were rolled out it meant that online charging systems had to support new real-time protocols – or more recently – the expansion of customer touch points required order capture and management solutions to support new omnichannel flows. But what about their product catalog? Slow time-to-market, high configuration and testing efforts, low business agility and reduced operational excellence were usually the drivers behind updates.
Fifteen or twenty years ago, many operators described their products using a variety of spreadsheets, presentations and documents before converting these products into rate codes for their various billing systems. This spreadsheet approach evolved into a database approach, where each of the OSS/BSS components in the stack had their own embedded catalog. Many providers are still in this stage today, while others are evolving to an enterprise-wide catalog that is the master of all the other catalogs where they create their product definition and offers. Gradual integration to the other embedded catalogs occurs over time, and results in some of the product information being automatically distributed to the embedded catalogs. This comes at a fairly high integration cost, as integrations must be maintained as the various systems go through upgrades and changes. The current trend is to rely on online rating and spending limit control more and more, and the problem continues to get worse.
Today´s main challenges can be summarized as follows:
- There is no mechanism to reuse THE existing business configuration in online charging systems which results in having to re-invent the wheel all the time
- There’s no intuitive user interface for configuring offerings in a centralized way
- There’s no clear view of utilized online charging system offers, resources, relations and their connections
- It’s hard to track changes and revisions of business configurations throughout the BSS and OSS ecosystems
- It’s difficult to track product performance information and use it to create new offers or updates
- Synchronization is missing between various systems that need updated products information
As we can see, there is a strong need for an architecture that owns a single repository of online charging system resources and has the capabilities to allow them to be re-used and exposed to external systems to consume the catalog information as needed. It is called catalog-driven charging.
Catalog-driven charging architecture comes to the rescue
A catalog-driven charging architecture allows templates that are built into the online charging system – including resources and customer-facing services – to be re-used among different products, offers and bundles with their specific configuration and price specifications. Going back to our automotive example, it means that the customer would be able to replace a flat tire, or the manufacturer could quickly launch a new version of the car with a newly built engine. It is simple and obvious for them, but not quite as straightforward for telecom businesses. On top of this, the so called “Lego block” components reuse other benefits of this architecture including the centralization of product definition and deployment, the exposure of product catalog information through real-time APIs to an external commercial catalog or other external system, and the capacity to manage the entire product lifecycles in one place. All these enhancements combined unlock unprecedented business agility in product design, configuration, testing and launch – and improved operational excellence with reduced charging errors and issues resolution time.
At Ericsson, we’ve been deploying this type of catalog-driven charging architecture for several service providers around the world and can see the difference it makes in their lives (and in their KPIs). Some of the cases worth highlighting are:
- A tier 1 service provider in the Middle East reached 90 percent re-usability of templates and reduced 60 percent of the testing time duration before a new product launch
- A Latin American mobile operator reduced the number of offers and templates in their catalogs from 1.167 to 197 – an 83 percent re-usability rate
- An African mobile operator reduced the number of offers and templates in the catalog from 700 to 99 – a 86 percent decrease.
You can hear more from these customers in this case study.
And it helps also during network evolutions and challenging times
The benefits of the catalog-driven charging architecture in terms of increased business agility, operational excellence and efforts in the whole product lifecycle are evident, but there are two other benefits that gained a lot of relevance recently and are worth mentioning.
The first one is that 5G monetization requires offers and business models to be created, launched and updated in an agile fashion so service providers can experiment with new types of products, check their feasibility and performance in real-time, throw away what didn´t work and re-launch updated products based on the feedback. This is only possible if the BSS ecosystem is running a complete catalog-driven charging architecture, which 5G plans and offers will benefit from.
Lastly, but most importantly, is the ability to change and update offers and prices during emergencies and crises such as the one we are living through now. In many countries, service providers decided to zero-rate specific data traffic, increase voice and data allowances or delay recurrence charges so people can keep using all types of communication – which is considered an essential service. The faster service providers can react and update their existing offers, the more people can benefit from the changes. In this case, a catalog-driven architecture can help during a national response to a crisis.
Find out how service providers believe 5G will impact their BSS environment. Download the MIT Insights Research report: The 5G operator: Platforms, partnerships, and IT strategies for monetizing 5G:
Related reading
Ericsson eBrief, What is the 5G Charging Function?
Ericsson Technology Review: 5G BSS: Evolving BSS to fit the 5G economy
