A Master Product Catalog is now a barrier for telcos

Written by on February 4, 2016 in Billing & Payments, Guest Blog with 2 Comments

Master Product CatalogA Master Product Catalog (MPC) …really? have we not gotten past the idea that if we just put all the data in one place that our business and technical problems will go away?  I’d argue that the first problem in MPC is the word “Master”, whereas the real  business problem is the word “Product”.  I believe that we first must simplify our offer of products.  How many duplicate products do you think the average carrier has, represented across hundreds of product catalogs, billing systems, fulfillment systems etc. The answer is unknown but I guarantee you that it is a very large number. Each duplicate brings with it the cost and complexity of management, test, systems support, data management, people, processes, etc.

Most carrier products are closely related to one another, so you have to ask…Why are they there?  The short answer is history and the unwillingness to cull offers. The reasons for this reticence are many but stem from a lack of clarity in product management and the fragility of the systems that support the carriers portfolio.

By focussing on determining a list of commercially viable and profitable products we can DECIDE what we need to sell and sell well in the future. The systems that support the billing, charging, fulfilment assurance, planning etc can be fewer and much more specialized in nature. Instead of requiring an external system to master their data or business processes they can expose a catalog of exposed APIs  to support the innovation of current and future products.

So why would we create a Master in this world? I’d argue that we would not need or even want to do so. Instead we would want each of the remaining product stacks to have a clear definition of the products in its domain and that these offers can be ordered via REST web services APIs. From the top level you can have an offer to the market that encapsulates a number of constituent products that are ordered from the product specific OSS and BSS via APIs. Those offers must be able to defer the billing and charging to a “higher level”  but that should be about it as far as coupling. This is a standard SOA loose coupling architecture and it still holds true in this case even though the coupling is between business systems.

So while I agree that we need to know what the carrier is selling based on the set of offers they can fulfill and manage, I reject the need for an all encompassing master data catalog approach to carry it out.

For more information and ideas check out Virtualized World.

Tags:

Adan K Pope

About the Author

About the Author: Adan is a highly energetic and experienced business and technology leader in Communications, Enterprise Software, Operations Support, Business Support, Media Delivery and related fields of study. He has worked as a senior executive, CTO, industry expert and thought leader, product manager, VP of Engineering and software engineer. Adan is also also a technical contributor to VirtualizedWorld.com .

Subscribe

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

Subscribe via RSS Feed

2 Reader Comments

Trackback URL Comments RSS Feed

  1. Avatar Michah Himmelman says:

    For an incumbent telecom, to go through the huge investment of designing towards unifying the Product Catalog from all its aspects and variations onto a single platform and then build backwards the gateways and interconnects to have other platforms “simply” read those products, i.e. more changes and bugs, would be an enormous job and would pretty much not get them any ROI, unless their perspective is really very far down the road. Not the case with most management and board rooms. I don’t believe a solid business case can support such an effort. I think the procurement dept. would be very brave to put such a product/platform forward in today’s market.

  2. Francis Haysom Francis Haysom says:

    The challenge is whether management know what they really are committing to. An MPC system rarely starts life as a fully costed or scoped project. To your point, if it did the ROI would be disappointing.

    MPC is actively promoted by major product vendors in OSS/BSS and is backed by the principles of the TMForum SID model. Superficially the idea of centrally mastering the existing ‘chaos’ appeals to operators who need to solve the challenges of improving innovation time across multiple legacy platforms.

    The focus on MPC blinds us to the real need to encapsulate/abstract what existing systems do and thus better manage innovation. Recognising that there are 50 billing plans or fulfilment processes that do roughly the same thing and can be rationalised/abstracted is the real step that allows innovation.

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: