Consolidated view offers hope for CSPs amid service frenzy
The other part of the challenge is that the CSPs have to deliver new services and some of these are completely unsupported by the existing (OSS and BSS) systems.
How is ConceptWave aiming to help operators transform their business delivery? And how does this differ from your competitors?
ConceptWave’s software can be completely configured. We don’t have a fixed model that we follow, the software is built so that we can configure any new services or products. This way, we are flexible and can handle with minimal effort the creation of completely new services, or provisioning and ordering of new services. This is not the classic approach, in which you build software with certain types of service in mind. Our approach has always been that eventually we will encounter a situation when we don’t know what the future service is. We have to configure our software to allow us to support these new types of service.
There’s fierce competition out there. Coupled with today’s economic environment, it has changed the way that CSPs do business. There is a transformation in being able to turn around product offers in a multi-plane environment, where it’s about turning up and turning on services and product offers not within months but literally within days, or even hours. One of our customers used our software for precisely that reason, because the fact is that – even after a product bundle is put out on the market – in the CSP environment today (particularly in wireless) you’re going to get competitors who come up with another offer within days if not hours.
From Day One this was the main concept of our software, that it should be flexible, and able on the back end to order or orchestrate the service. The marketing departments of our CSPs are very competent at launching new products and services, but then on the operations side they can execute the complete offer.
What are the advantages of a unified product and service catalogue?
Service providers are saying there are services they would like to change, enhance, evolve. If they can do that in a descriptive way (if they have a way to define the service that they want to sell) without thinking too much about what is needed in order to do that, that will be a great advantage for the speed and the quality of the service.
So our idea was, if we build a catalogue which we give to the marketing department, and then we provide powerful mechanisms by which this definition of the services is linked to the provisioning processes this will allow CSPs to considerably reduce the time needed to introduce new services. Secondly, it will allow them to create more and more rich services without the need to re-work the OSS and BSS systems. So that’s one of the biggest advantages of our approach, by puttingthe services catalogue at the heart of the system we can both increase the quality of the services and reduce significantly the time needed to implement them.
How much it reduces the time by depends on the type of services and the systems that the customer has in operation, but we are speaking about between 30% faster time to market and up to five or six times faster. Once you define what your service is then it should be extremely quick to attach the necessary business processes for provisioning systems, and attaching the corresponding network elements should be a simple and straight-forward job. The major effort will be to define what you want to sell, not how you provision this.
That’s quite a change for operators. Are they ready for that?
As with any new approach it takes some time to be accepted. But the benefit is there in reducing time to market. The ability to create a bundle and almost instantaneously know that the new bundle can be order fulfilled doesn’t exist today. Typically, the organisations are separated; marketing and operations. And secondly, there’s no application on the market doing that, either focusing on the product catalogue side or giving you the ability flexibly to compose the product. It’s not linked to order orchestration and then you’ve got order orchestration or management systems that are not linked to product catalogues.
A few years ago the industry was full of talk – especially among Tier 1s – of massive back office transformation programmes. Has this changed simply for budgetary reasons?
Budget is one of the major factors. But in the last few years there appears to have been a discrepancy between the speed with which new services can be introduced and the speed at which they are requested by customers.
We’ve been able to demonstrate to our customers some huge reductions in training time and therefore labour as well as cost. When I say huge I mean from months down to days and that obviously has an RoI component to it as well which we’ve been able to measure.
At one of our cable customers, it took them on average about 6 weeks to train their CSRs. Now, factor in that on a yearly basis they would have about 50% staff turnover as CSRs come and go. The cost of that is substantial. We were able to bring that training down to 5-7 business days.
The software has to fully implement the requirements of the software users. Not like in many cases, where the users have to adjust themselves to the software. We’ve provided an integrated view of the whole system which the CSRs can work with. So, they don’t need to learn and manipulate different systems, they have one universal workstation where they can do everything they want without being concerned about the systems behind it.
You’ve said in the past that there’s an opportunity for smaller, more discrete and focused initiatives. Can these address the full scale of CSPs’ back office problems?
Our approach is a consolidated view, we’re not just talking about the marketing or the service side. By having one consolidated view ConceptWave has a huge advantage right down to the CSR level where they can look at what the offer is to the customer and provide better customer service. So, advantage number 2 is an increase in customer service. Basically, the CSR no longer becomes an ‘order taker’ or troubleshooter, they get more concentrated on up-sell or cross-sell opportunities.
The third advantage is rapid changes. Having a catalogue that’s centralised in terms of the view, you can make changes quickly and effectively – dare I say, even once the product bundle is delivered changes can be made due to competing market pressures.
The other thing that we’ve found concerns revenue leakage. When systems don’t have this consolidated view, you may find pockets in different parts of the organisation, particularly on the operations side, where there’s a repetition of tasks, data entry, and basically the workflow is just not smooth; there’s a lot of inefficiency. We’ve been able to go in and correct that by an end-to-end customer experience management (CEM) approach.
Getting to your question, I don’t think smaller, more discrete focus initiatives can address the full scale (of challenges). No. But you have to have systems such as ConceptWave’s where the systems are small, agile, but they have a complete end-to-end view of the product.
Are there any other features that CSPs should look for in a service fulfilment system?
Yes, if there is an easy way to customise their repository of services then it allows them to be competitive, to provision services quickly. But only having a repository of definitions of these services is not enough. These repositories have to connect with many other systems and then there are important aspects like how they communicate, and the standards used. All new products have to adopt the standards established in the last several years and that’s what our products do, following the standards of the service oriented architecture (SOA) so they can communicate easily with other systems from a different source.
We have customers that have millions of orders a month and these put huge stress on the systems which process these orders. The stability and the performance of the new systems become very important. And there are many different channels by which the services can be sold. On the other hand the systems that support these services should not be multiplied to support these channels.
We have to have a way to define these services once, and provision them through different channels without the need to develop separate silos for each channel. This way the integrity of the service is maintained; it’s defined in one place, it can be verified in one place, and then the channels are merely different business processes or user interfaces.
One more important part of our approach is that all systems and processes we’re speaking about are de factoworkflows. So it’s important to have not only a catalogue but a catalogue which is able to support and define business processes. And these business processes are two-track, one is the business process that maintains the information of the catalogue itself, and the other business processes are those needed to negotiate, sell and provision services.
All these business processes, and the ability to define them, to customise them, should be an integral part of the catalogue.
Can you give any other examples of how network operators have benefited from this approach?
In one multi-play service provider offering wireless broadband services content, on the first day of production we dropped the error rate from 40% to 0%. The cost saving of that was US$25 million over three months. The second point is that we implemented a single point of application for this provider, in a way that aided selling. So that when the order is being taken (based on the eligibility of the package) it recommends to the customer a bundle and accessories. Over the same three months the increased upsell was 125%. This is a fairly sizeable provider with 1.6 million subscribers. With this set of capabilities, the providers that we are now entertaining in the 5 – 15 million subscriber range are making savings and increasing revenue to a much larger extent.
category: Talking Heads