Dan Baker Blog RSS

Tribold: Delivering a 'True Enterprise Catalog'

By Dan Baker Comments
Print

Dan BakerFor years, telecoms have put central product catalog projects on the back burner, but the explosion in service components in enterprise, cloud, and mobile sectors has turned the catalog into an urgent issue, especially at large telecoms.

On the surface, the causes of product bloat are many: time-to-market pressure, telecom mergers, internal politics and tight budgets. In reality, these causes are just excuses for a careless or fundamental disregard of enterprise data-management principles.

Dozens of books have been written about data management, but perhaps there’s no more qualified expert than Hoosein Eslambolchi, the ex-CIO and CTO who led a massive transformation of AT&T in the years before it was acquired by SBC Communications. Hoosein gave TRI a wonderful interview a few years ago where he explained his technique.

This isn‘t a matter of confessing for past sins: Telcos pay a high price – every day – for their lack of product integration as they constantly reinvent product wheels, lose customer intelligence, and waste time on provisioning. Sure, systems integrators like Amdocs and Accenture have provided project-oriented integrations, but most of the silos still exist.

The founders of Tribold figured it was high time to develop a commercial software solution to smooth the transition to central catalogs and save telco customers a boatload of money.

Tribold's Simon MuderackAnd one of those founders, Simon Muderack, Tribold’s CEO, is here to explain the urgency of product catalogs and the successes that his firm is having helping telcos reduce their ongoing billing and provisioning costs, improve intelligence and make enterprise customer operations far more efficient.

Dan Baker: Simon, it would great if you could first restate the advantages of a central product catalog and the kind of carrier who needs one.

Simon Muderack: Sure, Dan. Central product catalogs are especially needed at telecoms [that] create service bundles from tens of thousands of components.

To create a new bundled service requires you to figure out what’s in dozens of underlying B/OSS systems. And as we all know, lots of downstream problems are caused by inaccurate information being passed across siloed system[s].

There are many uses for product catalogs. For example, [they] can insulate your billing system from change. A business-view mapping of the underlying product maze allows the billing system to crank out another 10 million invoices without altering the billing database or structure.

The tie-in to analytics is also key. For example, a catalog can help you track customer churn by product offering. If there’s a spike in customer churn, you can go back into the catalog and see whether the churn coincided with the end of a promotion or a major price change.

DB: What do you consider the biggest growth area for central product catalogs?

SM: Perhaps its biggest potential is in supporting enterprise customers and the business cloud. Enterprise products require extraordinary customization and creative bundling. At one large U.S. carrier, nine of 10 enterprise product requests go into an exception process. The contracts are all different: different terms, prices and regional needs. So the challenge is getting some commonality in the back end.

If a telco has 500 large enterprise customers, the product catalog is usually customer-specific and lives in 500 spreadsheets. Those silos would be fine if nothing changed, but enterprises regularly ask for tweaks and sales team[s] always want to sell the enterprise more products.

But if nine of 10 enterprise product requests go into an exception process because there’s poor integration in the back end, that’s a very costly exercise for telecoms.

Enterprise customers want to believe they are getting a bespoke or custom offering from their carrier. But a telco can‘t make money in the enterprise market unless the vast majority of components are re-used across enterprise clients. Truth is, 90 percent of change requests are fairly straightforward and simple if a central repository of product components is available. One Tribold client, for instance, has 55,000 components in the catalog and mashes them together to make new services.

DB: In what other areas will central catalogs be attractive?

SM: Well, in cloud and M2M services, it's advantageous to have lots of product components under a single catalog. And it’s here where competitors like Amazon and Rackspace are at an advantage because they are unencumbered by the decades-old legacy that telcos must live with.

A central product catalog helps a telecom compete by delivering a common and consistent view of the business rules around products, making it far easier to maintain rules for unique channels or industries. For instance, a telco can extract and manage a subset of components unique to health-care industry customers.

DB: How does your solution differ from other approaches to product catalogs?

SM: Tribold’s approach is unique, I think, because we come at the problem with a clean slate and no pre-disposition to support any particular vendor’s products. We’re the United Nations – all countries are treated equally – CRM, billing, inventory, order management systems, and any other system you have.

An Amdocs or Openet will build its catalog from a billing angle. A Telcordia or Netcracker will skew it in the inventory or order-management direction. And in both cases, the catalog is built for internal consumption and doesn‘t easily adapt to Web services or the needs of an outside integrator.

DB: What’s implementation like? What does Tribold do to facilitate the transition to an enterprise product catalog?

SM: Used to be programs like this required a lot of integration, but today customers are gaining value quickly through limited integration. Plus Web services and SaaS are smoothing the transition. Domain expertise is still critical to optimizing the catalog design, however.

The infrastructure we supply is very hierarchical and structured. The first thing we do is normalize the data: Create a big flat file or XML structure.

A lot of the work Tribold does is to support order capture and order entry, quoting front ends. We find that focusing on the ordering side is easier and cleaner than replacing billing systems.

We helped [a] Tier 1 customer catalog the products in [its] enterprise customer group. The project began with a group [of] 20 users in a single line of business. A new strategic product model was developed and the client set how granular the products would be defined ... Within 90 days, we brought an additional 20 users onboard, bringing another set of products – both BSS and OSS components – into the system. Today that company has 200 users. And the product will support 37 new product launches in 2012.

Tackling the enterprise customer area is hard because the enterprise contracts are all unique, supporting their terms and prices; however, the cost savings that come from streamlining operations generally have a faster payback.

Today, the carrier people who access the application are so-called “product engineers": guys who used to sit between IT and the business. Before, their biggest [task] was to decode big Word documents and translate the terms of contracts into Excel spreadsheets. With Tribold, that translation no longer doesn‘t need to occur. Instead, they are entering products in a central system made up of SLA, price, description and underlying service components.

More recently, the solution is now supporting Salesforce as a sale order-capture tool which interfaces directly with our tool, providing guided selling functionality.

DB: What are some of the other “bells and whistles" that make a product catalog solution robust?

SM: I think one of the benefits of our approach is it enforces a consistent view of products and the business rules that surround them. It’s flexible too. For instance, you can decide to have different rules for each channel. So a certain promotion or discount may be available to one channel, but not to another.

Another nice thing is that you can “retire" a product but keep it in your history. This allows you to track indefinitely, say, the customer churn associated with a product. If you have a spike in customer churn, you can go back into the catalog and see what changes [were] made on a particular date. And you’ll see things like “promotion ended" or “price went up."

Finally, we built complete accountability and tracking of changes into the product. All [of[ the users have security profiles. There are a limited number of power users who can do everything, but most users are limited in their ability to make changes.

DB: Thanks for the nice insights, Simon. To close, I wonder if you could address the issue of other solution companies who have product catalogs in their product. For instance, IBM sells an e-commerce order management solution (former Sterling Commerce). So I’m curious how that type of solution differs from your own.

SM: It’s true, many B/OSS applications have some form of product catalog. I think the issue boils down to whether you want to solve the catalog issue for one system or solve it for the whole enterprise.

If you need a catalog for an e-commerce solution, then a Sterling solution would work, but all [of] the other back-office systems would not be supported. And I would contend that you don‘t get the sophisticated product life-cycle management process like Tribold supplies.

I’m well familiar with the money that’s made sticking product catalogs into CRMs or other systems. For 10 years I made a good living working for a systems integrator who brought those solutions into carriers. But even though those solutions generated a positive ROI, they don‘t solve the larger issue of delivering a true enterprise catalog. That’s what Tribold is about.

Simon Muderack is the CEO of Tribold. Prior to co-founding Tribold, Simon partnered closely with global wireline, wireless, wholesale and cable operators in structuring complex IT transformation programs during 10 years with Accenture. Contact him at simon.muderack@tribold.com.

Dan Baker is research director of Technology Research Institute (TRI) and has been a B/OSS market synthesizer since 1994. He is also editor of the Black Swan Telecom Journal .

Comments

comments powered by Disqus