Big BSS transformations fail and they take too long to fail

Written by on July 13, 2016 in Billing & Payments, Guest Blog with 1 Comment

I'm strong enough to do itTelcos are increasingly being squeezed by the declining revenue from traditional voice/SMS whilst increasingly becoming dumb pipes for nimbler OTT services. In response many have and continue to embrace BSS transformation programs to rationalise their BSS systems and prepare for promised new Digital transformation products. The bad news is that these big BSS transformations fail and they take too long to fail.

Telcos should ask the following questions before considering an IT focused BSS transformation:

  • Is having one billing/charging system really going to change anything?
  • Is investing in and largely replicating the existing billing and charging plans held in the legacy systems really going to change anything?
  • Is investing in a BSS which is still primarily focused at the Telco direct subscriber business really going to change anything?

Let’s face it charging and billing for Telcos has been solved. Telcos bill and charge their direct subscribers very well. What Telcos are bad at is inserting themselves into any other value chains with other people’s direct customers or users. The phenomenon of OTT could be better explained as an inability of a Telco to add any particular value to another party apart from bandwidth. Simply replicating what the customer does today on a newer shinier systems does not change anything about the dynamics of the business.

Telcos should be asking different questions about their existing BSS:

  • Are the 10 billing systems your real problem or is it the 1000s of legacy billing plans/products created for an earlier age?
  • Are there a set of subscribers that are of no value to proactively move to another system?
  • Are my existing systems really legacy or could they provide valuable services  immediately to new products?
  • Would unbundling the existing BSS into its valuable services more rapidly allow engagement in indirect and multiple relationships with my OTT partners?

However, solving these questions requires collaboration beyond the scope of the CIO. Rationalising products needs the CMO involved. Opening up new business models with partners needs the CFO involved. With that kind of agreement so hard it’s easy to fall back on IT only transformation as it can be started and it demonstrates that something is being done. Hopefully the initiator of the transformation can have moved on before the inevitable failure to deliver happens.

An alternative approach is possible, one where existing investment and business can continue whilst new services are innovated at the edge leveraging the unbundled capabilities of existing systems. We see the following key enablers of this approach:

  • Enable adjunct systems for new services. Choose a new or existing system that best enables these new systems, particularly an open API that supports independent use of functions.
  • Create common service patterns in these new services that enable their independent service reuse. Avoid repeating the one product one billing configuration of the past.
  • Focus on services that support novel business models rather than existing solved direct subscriber model.
  • Encapsulate existing charging systems and billing systems so they can provide common services, such as subscriber identification, for new services.
  • Federate common service capabilities so that the system where a subscriber is managed does not matter.
  • Iteratively move subscribers to new systems as they move to use new services. Move based on need.
  • Rationalise existing billing products and align to the new data focused age but decouple this from system transformation.

Tags: , ,

Francis Haysom

About the Author

About the Author: Francis is responsible for the technical vision and direction of Virtualized World. He has 25 years of experience in telecoms BSS and OSS software. Previously he was responsible for innovation and strategy in Ericsson’s software solutions business and in Telcordia. Within this role he set and reviewed the strategic direction of both product and customer program delivery. Before Telcordia he was VP – OSS Architecture at Cramer Systems. He was one of the original employees of Cramer and was responsible for the development of its professional services organization and its strategic deployment architecture. He has also led BSS development teams at BT and Convergys. Dr. Haysom received his PhD from the University of Bath and a BSc in Engineering Science from the University of Exeter. .

Subscribe

If you enjoyed this article, subscribe now to receive more just like it.

Subscribe via RSS Feed

1 Reader Comment

Trackback URL Comments RSS Feed

  1. Michael Elling says:

    Major disruptions have occurred throughout history. We can and should learn from them. More often than not we don’t; not because we don’t try, rather our analysis and conclusions are wrong. While the “buggy whip” is an often used metaphor for technological obsolescence, the more important, and disruptive, element to focus on, and therefore lesson to be learned, is the evolution of the lowly ball bearing. Invented in 1794 by a Welshman, it’s design was perfected due to material improvements in 1869 by a Parisian. The radial style ball bearing was promptly fitted to a bicycle and the French started racing that year. A timely story with the current Tour dominated by a bunch of English cyclists!
    Fast forward 30-40 years to witness bicycle makers leaving the most important mark on transportation in the 20th century, to wit Henry Ford and the Wright Brothers. Take the above story and replace packets for ball bearings, internet companies for bicycle makers, telcos for horse driven carriages and “legacy” BSS/OSS for buggy whips and one has a better understanding of where we are and where we’re heading in the world of information (transportation) networks.
    I agree with the author that there will be a role for BSS/OSS, but in different form. Functionally the buggy whip was replaced by the throttle pedal. It’s the interface that clears demand (driver) and supply (the engine/horse). But defining the throttle pedal is almost impossible as the precise shape and form of service providers is unknown. That said, what took 50-60 years to transition in the late 1800s to early 1900s, will likely only take 20-30 years. Given that packet networks started scaling in the mid to late 1990s, we’re less than 10 years from when the horse-drawn carriage disappears and is replaced by something new. In network service provider terms (or edge access service providers) this probably means horizontal and confederated.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Top
%d bloggers like this: