Rooted Deep Within, Product Catalogs Can Cause Nuisances for Providers

Product catalogs have deep roots when it comes to a provider’s systems. As a provider’s offerings grow, so too do its product catalogs. Left unmanaged, product catalogs can uproot simple operations before a telco even realizes the cause.

Product catalogs are systems that house information about the products and services a provider offers, generally supporting order entry, provisioning and billing operations. Poorly managed product catalogs can and will impact revenue, however, today’s providers see them as more of a nuisance that affects customer service.

Problems caused by product catalogs appear in many irritating ways, notes Mark Hayward, chief technology officer at BusinessEdge Solutions. “Customers order products that don’t get provisioned, because the provisioning system doesn’t know about them; or the provider is able to provision it, but when it gets to the bill, the billing system doesn’t know how to bill it, or it misinterprets the rules and people get billed inaccurately,” he says.

Other mishaps include orders taking longer to fulfill because a provider must manually work around the systems to provision a service. Operational inefficiencies internally and the amount of time an organization spends addressing product catalog synchronization issues also inflict a cost upon providers.

Sheer Numbers

Perhaps the biggest reason these problems occur is the sheer number of product catalogs that seemingly multiply overnight within a provider’s domain. Arvind Sathi, managing director of the services solution group at KPMG’s Communications and Content Practice, says that providers can have 20 or more catalogs.

This happens because catalogs are built in many ways. Some grow up around a specific technology, such as long distance, wireless, DSL or an IP VPN. Still others are centered on a regional product offering. For those that are technology-based, the number of products within a catalog can easily grow out of hand when a provider starts offering converged products and bundling various offerings.

“It manifests itself in the most gruesome way when you’re dealing with converged products,” Sathi says. He explains that when a company offers an IP product, it inherently becomes a converged product that must incorporate administration fees, access fees and the network allocation. “If you’re offering [IP], you are probably going to touch at least 15 product catalogs to offer a product.”

Hayward says, “It’s not atypical in some of the larger companies to find that they have literally thousands of products in their product catalog, whereas intuitively you’d think they would have 10.”

Joel M. Halpern, co-founder and chief executive officer at Longitude Systems, agrees. “At one major provider with lots of customers—business customers—we found out in talking with them that their product catalog had more entries than their number of customers,” he says.

Mergers and acquisitions add to the product catalog nightmare as well. “A lot of [providers] have acquired different companies at different points in their growth strategy. If they really look at the scale of those systems, they might as well still be operating in sort of a silo fashion. It’s just really hard to reposition those things,” Hayward points out. To deal with this situation, providers generally adopt a strategy of gradual consolidation. In a conversion effort, migration occurs incrementally and often one product line at a time. “You slowly migrate and you slowly decommission the systems until they die on the vine,” says Hayward.

The Beginning: Product Launch

Another dilemma that impacts the product catalog is the process for rolling out products. “A product launch happens in an ad hoc fashion, and that results in different organizations updating different disparate product catalogs in an unsynchronized way,” Hayward says. These departments update and alter their product catalog as they deem it accurate and necessary. This inevitably causes inconsistencies and inaccuracies among catalogs.

Hayward recommends defining the product launch processes from the point when sales and marketing dream up a new product or a new bundle. This would involve a series of business processes with potentially some automation or work flow behind it as well. “Departments would have to go through a series of gates and approvals so that everybody—engineering, sales and marketing, IT—-would understand the information that would be coming and understand the implications, and make sure that all the rules and structures are captured uniformly.”

Semantics and the Product Life Cycle

Sathi explains that it is critical to give a clear picture of what the product actually is. “What I may call product, you may not call product,” he says.

After the product definition is delineated across multiple systems, another issue that must be addressed is the product life cycle once it hits production.

“We track the customer life cycle from the time we get them to the time they go away, but another kind of undefined concept is from the time a product is born to the time it dies and goes away,” notes KPMG’s Dick LaRue, who is serving as chief architect on a a major product catalog overhaul at one provider overseas. “They just seem to willow away, and nobody officially kills them or moves them over to something else.”

Not having a clear picture of the product life cycle makes updating or combining product catalogs difficult. “What does it mean to run its course?” LaRue asks. “We sell it to this group, and then does that product fade away and become a dead product? If we don’t use it anymore, when do we dispose of it? When is it replaced by another product?”

There is also the legal issue of grandfathered products. “Legally you’re not allowed to take it out because, unlike a routine product in a service world, as long as you have a customer using a product, you cannot take it out of the service world. You can stop selling it, but you can’t stop servicing it,” Sathi says.

Another hurdle in defining products lies in the systems available today. “The technical catalogs that you have available are kind of inadequate for the more complex telecom products,” LaRue asserts. “Most of the product catalogs and configurators were made for retail or maybe even manufacturing. Typically, the available software that you have to represent telecom products is really lacking, so you have to make some compromises on products to denormalize their definitions. It limits the reusable modules that you can express in the applications systems. By the time you take those two things together, this is really a hard problem.”

The Silo Mentality

For product catalogs, the old silo mentality dominates, Sathi notes. Whether it’s billing, CRM or provisioning, each system uses a different description of the service and is involved with different parts of the service.

In an order entry or CRM system, the product catalog is mainly concerned with pricing, dependencies of different products and how to present the order entry flow, as well as how a customer service representative would go from one screen to another. The provisioning system is much more concerned with the individual services, because from a provisioning point of view, those are separate products, they have separate work flows associated with them, and they have separate parameters. The provisioning system needs to understand the rules associated with it. Provisioning requires information about the services that make up that product, such as what is included in a particular product bundle.

Billing has still other uses of the product catalog, for pricing and taxation purposes, and also to understand how the information is presented on the bills.

“While we use the term ‘product catalog’ and all these things are related, they are not necessarily the same thing,” Hayward says.

And it is almost universally true that commercial off-the-shelf vendors view themselves as the owner of the product catalog, he adds. “It would be exceptional to find somebody that thought there was another product catalog. I can’t think of anybody that’s said, ‘I’ll work with another product catalog.’ They all expect to use their own product catalog, and there are strong reasons for that,” Hayward notes. “In many ways the product catalog is almost like the brain of these systems, and they build a lot of these systems around that core. To expect somebody else to provide that functionality is like saying you’re going to trust somebody to be your brain.”

Automating the Process

If too many catalogs complicate the process, a provider must organize its catalogs in some manner.

“It’s not like you could really put all these rules in the same place. … It would be a very sophisticated and complicated application that could capture all the rules you would need for all the systems that would use that product catalog,” Hayward says.

Halpern at Longitude Systems believes the product catalog should not own the business process. “It’s very hard for it to understand what needs to be shared, and it’s much easier if it can serve as a resource rather than try to be an active pusher of information,” he says. “If the product catalog’s job is to coordinate data, then you’ve backed yourself into the corner where every system is responsible for coordinating its data with everyone else, and is responsible for understanding how everyone else looks at this data.”

If a provider keeps more than one catalog, anytime a change is made in one place, it must be duplicated elsewhere. And Halpern notes, “Anytime you have to change something in two places, you probably got it wrong in one of them.”

This is where automated synchronization comes in. “If you don’t automate it, you’ll always have hamster ware,” Sathi says.

Hayward says the current issue is that many of the vendors today do not provide a way through APIs to update the product catalog externally, so there really is no way to modify the product catalog other than through the standard user interface. This complicates updating the product catalog.

In an automated world, however, a provider could enter the same information it would have done manually through an API, so that instead of having to type the data in through various input screens it could capture the data some other place and push it electronically into that system.

Sathi believes the first products to address this issue will likely create some sort of product between, say, Portal, Siebel and MetaSolv catalogs that creates a product catalog that works with those three. But, he says, if a provider is looking for a product to do that right now, there are none.

A Catalog of Catalogs?

Sathi comments that one concept floating in the industry, which he attributes to Qwest, is the idea of a metacatalog, or a catalog of catalogs. This catalog would be a virtual catalog, in a sense, that would sit above the existing back-office catalogs, no matter how many. This metacatalog would be synchronized to all the catalogs that are providing real data and connecting to the billing and provisioning systems. The metacatalog would have all the data that the customer would like to see. It would not necessarily need to be complete, but just house enough information to give customers what they need.

Another idea, Sathi explains, could involve the catalog as a marketing and sales description of the product. Associated with the product, however, would be the configuration that corresponds to the product the provider is trying to sell. It would tell the provider that in order to provision the product it would require specific network components. Product configurators would manage the process; workflow engines or a provisioning or order management engine would connect to the product configurator, which would connect to the product catalog. So the catalog would be able to sell the product, the configurator would know which components to use, and then it would customize the workflow engines or pick the workflow elements needed to provision the product to make it work.

Yet, Sathi admits, “no one has that kind of automation. Everyone wants it, but no one has it as of today.”