With each day, the complexity of telecommunication operators' market offerings grows in scope. It is therefore vital to present the individual offers to end customers in an attractive, simple and understandable manner. Together with meeting target profits and other financial measures, this is the principal goal of Marketing Departments for all communication service providers.
Within the OSS/BSS environment, forming clear and understandable Market Offerings is equally important for business as the factors described above. There is a huge difference between maintaining all key information about Market Offerings through various GUIs and different applications, and having it instantly at your fingertips in an organized manner. The latter option saves time and reduces the probability of human error, which makes a significant difference in both the length of time-to-market and the accuracy of the offering, ordering and charging processes experienced by the end customer.
What is a Market Offering?
Market Offerings have the following principal aspects that are usually defined during the offer design process:
- General idea (defining the scope of the offer)
- Target market segment
- Selection of applicable sales channels
- Definition of services and their packaging
- Definition of pricing
- Definition of ordering specifics
- Definition of the order fulfilment process
- Marketing Communication (from the first advertising campaign to communication at points of sale or scripts prepared for call centre agents)
It is apparent that Market Offerings aren't static objects at all; on the contrary, they are very dynamic entities and most of a communication provider's OSS/BSS departments have some stake in its success.
This leads directly to the key question: "Which environment can support a Market Offering and enable unified and cooperative access to it by appropriate teams during the proper phases of its lifecycle?"
The environment that addresses all of the above-mentioned aspects must be materialized in the form of some information system or application, if it is to be put into real existence.
Putting Clarity into Practice
The closest match to the requirements described above is an OSS/BSS building block called Product Catalogue.
Product Catalogue is usually represented by the following three aspects:
- A unified GUI that enables all key operations for managing a Market Offering during its lifecycle
- Back-end business logic and a configuration repository
- Integration with key OSS/BSS systems
Product Catalogue supports, with one exception, all aspects of the total Market Offering:
General idea - This enables the capture of the general idea, the keystone of the arch to be built.
Target market segment - This enables rule based definitions for the target market segment that shall be addressed by the Market Offering. It should enable changes or further specifications to this segment in conjunction with the information system that is used for market segmentation purposes.
Selection of applicable sales channels - Together with the Ordering system or systems, Product Catalogue should enable the specification of eligible sales channels for the Market Offering.
Other eligibility rules - In regards to the first two forms of eligibility (segmentation and affinity to the channel) additional rules should ideally be definable.
Definition of services and their packaging - As the name ‘Product Catalogue' suggests, products, which are productized services in principle, are the central elements of it. Products are packaged or bundled using Product Catalogue together with other parts of the usual Market Offering, such as Allowances (free units, etc.), Friends & Family or Closed User Group settings, VPN settings (for corporate segment), etc.
Definition of pricing - Another key function of Product Catalogue is defining price models related to the Market Offering in general or to its parts. Price models can be quite complex and require well-defined/productised underlying services, if they should be applied with a certain level of simplicity and convenience.
Definition of ordering specifics - In the individual screens of an Ordering application's GUI, Offer/Order Templates are usually defined using an ‘Ordering Catalogue', which may or may not be part of the overall Product Catalogue. There are pros and cons to having an integrated or separated Ordering Catalogue, but this is out of the scope of this article because the basic offer structure and its parameters with applicable/default values should come from Product Catalogue by design.
Definition of order fulfilment process - Similar to Ordering, Product Catalogue isn't usually the place where detailed Order Fulfilment and the subsequent Provisioning processes are defined. There is a variety of specialized systems for this on the market, each having its own unique configuration, and so it is impossible to cover all options by a single Product Catalogue application. On the other hand, Product Catalogue should enable the storage of some key ‘hints' that provide these systems a general method of determining what shall be done when the Market Offering is ordered. This should be materialized in the form of ICT environment configuration.
Marketing Communication - Only this function is clearly out of the scope of Product Catalogue. So far, there are enough specialized Campaign Management tools and applications on the market; designed from bottom-to-top specifically to support MARCOM operations.
An Aspect of Integration
Functions supported by an ideal Product Catalogue also define OSS/BSS systems that should be integrated with it, namely: Market Segmentation System (could be some BI or Analytical CRM), Ordering, Order Fulfilment, Provisioning, Charging & Billing and CRM. All these systems should either provide some data to Product Catalogue or use it as the master source of the data related to Market Offerings.
The necessity of integration in general is unquestionable; the only remaining issue is determining how the integration will be done and what will be the overall cost. Deciding which type of integration will take place depends on a number of factors, discussed below.
The Principle Dilemma
There are three principal options for positioning Product Catalogue within the OSS/BSS environment. Product Catalogue can be deployed:
- As a standalone application
- As part of a CRM system
- As part of a Charging & Billing system
Product Catalogue as a Standalone Application
This option appears tempting at first because: "Who can have better Product Catalogue than a company exclusively specializing in its development?" However, many unseen factors tend to surface later on regardless of the shining chain of GUI screens that are often presented.
Does the telecommunications operator really have intelligent Charging & Billing processes in place or smart customizations built on top of it? If a standalone Product Catalogue is deployed, the operator can forget about utilizing these special differentiating features unless they are willing to start never-ending investment into customizations without clear TCO or ROI. It would also be unusual for a Charging & Billing vendor to be willing to provide detailed information about defining price models and the other mechanisms to a 3rd party vendor, as they are often the key selling points of their Charging & Billing product.
Another disadvantage of this approach is that there is not one fixed point of integration for a standalone Product Catalogue. No vendor of the surrounding OSS/BSS systems would guarantee compatibility with it. Once again, a never-ending integration project is a risky disadvantage of this choice.
In the end, it can be said that a standalone Product Catalogue would be a state-of-the-art application that will not provide the telecommunications operator with anything useful without extensive integration. Even assuming that this integration does succeed and results in a few months of perfect operation, shortly afterward a new set of features - vital for the telecommunication service provider's survival on the market - will certainly require implementation. This will probably affect either the Charging & Billing side (the most common case) and/or the CRM & Ordering side. It could also be that the most charming features of a standalone Product Catalogue will not be possible to use because of a lack of support by the surrounding OSS/BSS systems.
Product Catalogue as part of a CRM system
This is without a doubt a better option than the first choice because at least one side of the integration is guaranteed-if Ordering is part of the overall CRM system, then two sides are in the safe zone.
The only disadvantage of such an approach is that the pricing logic richness of a CRM system's Product Catalogue is quite low, if any. Subsequently, there is no principal gain in implementing a unified Product Catalogue as long as the definition of the price model and some additional key settings remain on the Charging & Billing system side. Such a setup is quite far from the ‘Unified Environment' described at the beginning of this article.
Product Catalogue as part of a Charging & Billing system
Service/Product bundling is usually tightly coupled with price model definition logic and the level of flexibility is in many cases, if not all, one of the cornerstones of the telecommunication operator's differentiating market offer.
Complex price modelling is the "holy grail" of profitability in every price-sensitive market. Even when there is an inexpensive almost flat rate applied to basic communication services (e.g. as in Austria), there is also the richness of value-added services (some of which can be priced using quite challenging logic), which raises the profit of telecommunications operators.
Another point of view is related to the effort necessary to implement complex Market Offerings. Implementation on the side of Charging & Billing is quite often the most challenging when compared to Ordering or CRM, for example. Order Fulfilment can also be quite a challenge, especially when considering the example of introducing complex, fixed-mobile convergent packages for the corporate segment; however, Product Catalogue itself has no major effect on its simplification. We can say that out-of-the box compatibility between Product Catalogue and Charging & Billing significantly decreases the OPEX of a service provider as well as markedly shortens time-to-market for the introduction of new Market Offerings and the modification of existing ones.
It should be said that most of the top Charging & Billing systems provide Product Catalogue either as part of their latest releases or as an optional extension. Independent of words like ‘Unified' or ‘Enterprise' and others like this, the covered functional areas are quite similar and show a difference only in the degree of support for the above-mentioned individual aspects of the Market Offering. This level of support naturally increases with each new release of the component, and so changing the Billing system due to a better Product Catalogue component is an investment with quite uncertain returns. This is because the overall functional richness and the most important level of flexibility in the areas of pricing and convergence are really the key features of Charging & Billing systems nowadays.
Product Catalogue as a financial asset in the general OSS/BSS environment
Each of the three possible approaches described above would very likely lead to different results for CAPEX and OPEX. Independently of the selection undertaken, the implementation of Product Catalogue should be justifiable by a clear gain on the service provider's side.
Business Benefits Coming from the Introduction of Product Catalogue
There is variety of direct and indirect benefits linked to implementation of Product Catalogue into the OSS/BSS environment. All of them are related to three qualities that accompany any successful introduction of Product Catalogue - clarity, accessibility and systematization.
Managing Market Offering lifecycles is supported by Product Catalogue's design. This brings to all involved parties within the telecommunication operator a better understanding of related subjects, the level of their involvement and their role within the process. This decreases the level of confusion, which is experienced again and again regardless of how well-described the processes exist in paper form.
All Market Offerings are accessible and visible within a single environment, including the history of their changes and the Market Offering's sub-elements. Anyone, according to their access rights, can view the sections of Product Catalogue applicable to their role.
There is no risk of discrepancies between Market Offering related data in various systems provided that the Product Catalogue repository is the master data source as stated above. Accessibility to correct data is an important aspect of information accessibility in general.
Product Catalogue not only enforces a certain level of systematization of Market Offering creation and maintenance processes, but also stores and presents all related business entities in a systematic manner, by default taking their integrity enforced by business logic into account.
All three qualities - clarity, accessibility and systematization - can be translated into two key terms - time and money. A successful implementation of Product Catalogue brings significant savings on the telecommunication operator's side as well as guarantees a considerable shortening of time-to-market for introducing new Market Offerings. If these two goals are not accomplished by implementing Product Catalogue, such a project must be considered a failure.
SITRONICS Telecom Solutions is a leading vendor of convergent charging and billing solutions in Central & Eastern Europe, Russia and the CIS with a growing footprint in Africa and Asia. www.sitronicsts.com
See Directory for further company information: http://www.eurocomms.com/directory