Pipeline Publishing, Volume 5, Issue 7
This Month's Issue:
Product Lifecycle Management
download article in pdf format
last page next page

Product, by Product, by Product:
An OSS/BSS Transformation Strategy

back to cover

article page | 1 | 2 | 3 | 4 |

getting started in a stand alone mode and then integrating into the OSS/BSS environment based on well defined and measurable business goals. Billing specialists like MetraTech offer a flexible combination of Service Definition and Dynamic Business Modeling to get at a balance of rapid time to market and controlled evolution. Still more solution options exist from companies like Progress, whose DataXtend makes it possible for carriers to implement their own TMForum Shared Information Database (SID)-driven solution to serve the data demands of the entire carrier organization.

It is now possible to choose one of several ways forward that each can lead to success. Getting a firm grip on your current products and services, rationalizing the Service Definition process while you organize your thousands of product components and pricing combinations appears to be a solid place to start, yielding some highly-visible, quick wins. Quick wins are always a great way to defuse that other alligator lurking in the swamp that kills projects: resistance to change. Involving people in bringing themselves new tools that actually help them do their jobs will set the stage for a much more successful Transformation program.

If carriers cannot dedicate their own subject matter experts to the task, then they must engage subject matter experts who are contracted specifically to enable the carrier's success.


.

Catalog would yield tangible benefits to each of them. They all agreed that those benefits would grow as the Catalog gradually was integrated into the end-to-end OSS/BSS environment. Benefits already quantified include:

  • Higher profit margins because fewer enterprise customer contracts would be labor intensive "one offs."
  • Lower cost of Billing, because bill close would be cleaner, with far fewer held accounts and re-rates.
  • Improved customer satisfaction as they build and order their own packages with no order rejections.
  • Reduced frustration across the organization as everyone worked from the same, up-to-date view of what was possible to order, implement, and bill.

For carriers like Telstra and Telekom Austria, a decision to proceed with a Product Catalog-centric Transformation is already yielding benefits. Yet, let's be clear: this is not magic. Much hard work is required to get the product data into a format that can be used to build the Product Catalog and drive the transformation. It took years to create the chaos; we have to realistically expect it to take a few months to unwind and rebuild.

"How many Day Jobs can one person have?" was the question posed in a recent interview with a Director of IT for the Enterprise Services group of a major carrier. Her question lies at the heart of why so many well-reasoned, and even well-funded, Transformation programs are just not getting done. We were talking specifically about how to begin reaping the benefits of a stand alone Product Catalog as the first step in the Transformation when you simply don't have the people to assign to the project.

There was absolutely no doubt in the IT Director's mind that one single application managing one consistent view of the information needed by Marketing, Sales, Customer Care, and Billing would begin delivering benefits from its first day in production. She already had the agreement of the Product Managers, the Customer Care team and the Billing group that even in its initial implementation, simply pushing data to other systems, the centralized Product


That strong business case had been sufficient to gain executive approval, and project funding, even in these difficult financial times. But every person on her team was more than fully occupied already, so just how was this project to be initiated? "Turn Key" contracts from the vendor rarely work out as planned, so that was not an option she was willing to consider. Similarly, Systems Integrators usually lack the carrier business operations and Marketing expertise to rationalize the product portfolio, business processes, and policies, so that isn't a viable option for her either.

Another leap of faith is therefore required to get started: if carriers cannot dedicate their own subject matter experts to the task, then they must engage subject matter experts who are contracted specifically to enable the carrier's success. Having a small team of highly experienced consultants who have "been there before" and can drive both the carrier and the vendor towards the goal is a comfortable, logical, and very cost-effective way forward. Cost-effective? How can that be when you're talking about adding several more people to the project? The answer is rather straightforward: with OSS/BSS projects failing much more often than they succeed, the cost of SME "insurance" is small, indeed. With well-crafted contract terms expressed in measurable outcomes, the SME team knows exactly what is required for success and has the expertise required to get it done.

article page | 1 | 2 | 3 | 4 |
last page back to top of page next page
 

© 2006, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding
the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law.