Editor's Note: This article is a follow-on perspective to the June 2005 feature story "The Case for an Adjunct Product Catalog" by Matthew Lucas and Michelle Nowak. The original article can be found online in the Billing World archive at www.billingworld.com.
Many persuasive factors argue for an adjunct or centralized product catalog—a focal point for all product information. Such a catalog would allow easy creation of complex yet compelling bundles, by eliminating much of the ad hoc integration otherwise required to support such offers. It would enable service providers to deliver a broad range of well-targeted offers—encompassing a slew of next-generation services—to market both rapidly and reliably.
Yet achieving this vision is not without its difficulties. The proliferation of disparate product catalogs is one of telecom's perennial problems that many providers almost accept as a fact of life. OSS history is already littered with stories of centralized catalog project failures, and the challenges that caused them are indeed many—but not insurmountable. For successful implementation, however, the industry may have to do some serious rethinking.
Centralizing Product Data: Flexibility is Key
Integration is the number one cause of death of adjunct catalogs. The sheer number and diversity of product catalogs found in a typical large telco makes for an enormous integration challenge. The different origins (home-grown or vendor specific) and focus (CRM, billing, provisioning, etc.) of each product catalog means that each one employs vastly different data structures to hold product information. Centralizing this information in a single repository, therefore, becomes very problematic.
When faced with problems of disparate data structures, conventional integration wisdom dictates that one should define a 'canonical' or 'common structure' into which all data will be transformed for the purposes of central storage. When dealing with product data, however, this approach can be fatal. Even product catalogs from within the same domain (e.g. billing), but from different systems, can have such different structures that defining a single model to adequately represent all products, regardless of which system they come from, is near impossible.
Such an approach usually results in forcing square pegs in round holes, which leads to synchronization problems, and ultimately project failure. Even if such a model could be defined at one point in time, there is no guarantee that it will be able to cope with new product catalogs that will inevitably emerge over time elsewhere in the enterprise.
Employing industry standard models such as the New Generation OSS Shared Information/Data (NGOSS SID) will eventually alleviate this problem, but not until the models mature and all application vendors comply with them. Additionally, there are the legions of legacy applications that were put into production before the advent of the SID that will live on for some time to come. Therefore, the disparate catalog structure problem must be dealt with in another manner.
The alternative is to embrace this diversity. At the heart of the adjunct catalog should lie a flexible "product hub," into which all product data can be centralized and stored using the native product structure of the edge systems. Since this hub would store the product information using the structures of the native systems, synchronization would be far simpler. Additionally, providing a number of bi-directional synchronization mechanisms (manual, on-line or batch) to suit the different architectures and system capabilities would ensure minimal disruption of the architecture and guarantee synchronicity of product data at all times (see Figure). A GUI built on top of the hub would then allow visibility and management of all product data throughout the enterprise from a single, central point.
Cross-Catalog Mapping and Bundling
Centralization of product data alone is not enough. A complete understanding of product data can only be achieved if the relationships between the various pieces within the product catalogs are also well-defined and understood. This is achieved through cross-catalog mapping. Cross-catalog mapping is also at the heart of a service provider's bundling capability such as in the following example where the "My Time 100" offer in the CRM catalog at a provider is made up of basic technical elements (GSM, GPRS and SMS) from the provisioning catalog; '20 MP3 downloads' from the third-party catalog, a free DVD from the ERP catalog and is priced using 'Price Plan 100' from the billing catalog.
Due to the diversity of the product data and sophistication of the bundles, cross-catalog mapping rules can get extremely complex. Nevertheless, if this complexity can be supported and be effectively hidden behind graphical drag-and-drop style interfaces, rich cross-catalog mapping capability can give a provider the ability to combine elements from the various back-end systems almost arbitrarily to construct compelling convergent offers with little or no support from IT.
Bundling and Decomposition
In order for this vision to be fully achieved, the adjunct product catalog must be more than a tool to merely model product configurations and cross-catalog mappings; it must also help realize those models. Part of the responsibilities of the adjunct product catalog must also be to participate in the fulfilment chain to help ensure the proper fulfilment of modelled bundles.
This can be achieved by exposing the cross-catalog mapping rules to an order management system through an API or Web Services. The order management system can then call the service to accurately decompose any ordered bundle into its constituent technical and billing elements before proceeding with the relevant fulfilment steps.
The benefits of this decomposition engine cannot be overstated. The complexity of decomposition is such that on many of today's fulfilment platforms it has yet to be fully automated, or where it has, it is a significant source of billing errors (from erroneous CRM to billing transformations) and order fall-out (from incorrect CRM to provisioning transformations). In contrast, a decomposition engine exposed by the adjunct catalog would encapsulate the complexity away from the order management platform which would previously have had to perform this function through inflexible look-up tables and error-prone custom coding.
In addition, it would guarantee the accuracy of the decomposition, thus eliminating a major source of billing errors and fall-out.
More Than Just a Technical Problem
Most discussions about adjunct catalogs tend to focus on a centralized point of configuration for product data. To be truly effective however, the adjunct catalog must not only be a focal point for product configuration activities but for all other information and activities involving the entire product introduction process as well.
The creation of a new product from initial concept to eventual deployment involves multi-disciplinary teams and lengthy processes. The idea has to be documented, business cases have to be developed, and approvals have to be sought out even before configuration of the product can begin. Even the product configuration phase requires coordinating the efforts of several people, testing and possible refinement.
Each of these steps is an opportunity for miscommunication and delay and impacts time-to-market. Notions of workflow, roles and responsibilities, and approval have to be well integrated and supported within the adjunct catalog. It must help enforce and expedite standard product introduction and maintenance processes from end to end, yet be flexible enough to accommodate each provider's particularities. It must also act as the repository for any documents relating to products, such as pricing sheets, marketing materials and contracts, if it is truly to be a central repository for product information.
Such functionality pushes the adjunct catalog into the realm of product lifecycle management applications that are more commonplace in other industries such as manufacturing. By broadening its scope, the adjunct catalog will be able to support the business more effectively. As the number, variety and complexity of products grows within a provider's environment, so too must the maturity of their product management capabilities. The same types of tools, which have helped other industries cope with their product management woes for years, must be brought to bear in a telco setting.
Summary
Telcos' search for a solution to their product catalog management and integration problems has been long and hard and in most instances ended in failure. Taking lessons from the past points to the following characteristics as being essential to a successful adjunct product catalog solution:
• Hub based product synchronisation, flexible enough to integrate today's products and the ones yet to be defined tomorrow.
• Cross-catalog mapping capability simple enough to be used by business users, yet powerful and flexible enough to provide the freedom to assemble the complex bundles the market demands without help from IT.
• Robust run-time platform capable of accurate decomposition of the modelled bundles during fulfilment to eliminate the revenue leakage and order fall-out.
• Management of products through their entire lifecycle, from conception to retirement aided by notions of workflow, roles and responsibilities and central document storage.
With industry trends such as triple-play and mobile content services set to bring yet more volume and complexity to product catalogs, today's disjointed product management tools and processes will impose an excessive burden on service providers. The time of the adjunct product catalog may well have arrived.
Ian Houvet is co-founder and Managing Director of boxfusion, a software provider with a singular focus on transforming and simplifying product management for communications service providers. He can be reached at ihouvet@boxfusion.com
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article