Most providers have not moved to upgrade their product catalogs in the past because they can’t seem to link catalog projects to a solid return on investment.
About 18 months ago, ADC began exploring why product catalogs plague providers. Two recurring themes came up: high operating expenses and slow time to market. The key problems the company identified were product catalogs that are too complex and costly to change and maintain; a dependency on consultants to make changes; too many proprietary formats; and difficulty exchanging information across an organization in a timely fashion.
Verizon, for example, was originally challenged to find the ROI for trimming down its product catalog. “These were always very expensive projects to kick off,” says Armin Kittel, Verizon’s executive director for advanced billing services and product and reference data repositories. “A lot of [projects] never went beyond the concept stage.”
As a result of the merger activity over the years, Verizon added more catalogs, each structured differently even down to a regional or state-focused level. Sharon Ballard, an analyst with Yankee Group, says geographically-based catalogs are a common problem. “You don’t often get consistency from all the product catalogs… because the product catalogs are all kept regionally.”
At Verizon, each catalog contained different flavors of similar products, but often required vastly different methods to update or add product definitions than their counterpart systems in different regions. With the merged companies, visibility into the catalogs was poor, while visibility across the multiple catalogs was almost non-existent.
In addition, the product information in systems on the East Coast, or former Bell Atlantic side of the house, had been embedded in code. Verizon’s CIO, Shaygan Kheradpir, sought to address the product catalog issues among these merged companies by taking the best practices from the West and applying them to the East, while at the same time bringing in newer technology across the board.
Moreover, recognizing the length of time it took Verizon to release a new product and remain competitive is one of the main reasons Kheradpir championed the company’s product catalog initiative.
Catalog Complications
Hafia El-Ashkar, an ADC product and program manager, says most catalog structures are very rigid and force-fit a company to comply with the business model that is inherent in the catalog versus allowing the providers’ business processes to be supported by the catalog. In addition, access mechanisms into catalogs are somewhat limited, decreasing visibility into the product catalog within the organization by people such as product or marketing managers. El-Ashkar adds that there is often “no real bi-directional understanding” or communication of the information between systems where product information is broadcast out to systems and replicated across the enterprise as well as information in other systems sent back to the master catalog. “The catalog should be the master of input, but it can also receive information from a master application [such as billing or CRM],” El-Ashkar explains.
To manage this information exchange, vendors are outfitting their product catalogs with XML capabilities to communicate product information between systems. Arvind Sathi, managing director at BearingPoint, believes the push in the last three years for
flow-through provisioning has been a driver. The first phase of supporting communications between systems, he says, was to use middleware such as Vitria and Tibco, but the evolution of this has involved these EAI vendors moving toward XML to communicate. Because a lot of product catalog information often resides in a legacy environment, creating a front end to the catalog to access this information internally and between service partners is important, Sathi says.
Who Owns the Catalog?
Many systems within a provider, such as CRM, order management, billing and provisioning, need to draw from the product catalog, but which one should serve as the main point of reference?
“I think part of the problem is there are parts of the organization that have different parts of the catalog,” Ballard says. “These catalogs aren’t often synched together.”
CSG’s Darla Thompson, vice president of product management, says the age-old war between marketing and IT remains. More vendors are adding in wizards to allow employees on the business side of the house to create new products; however, the IT folks often beg vendors not to reveal this functionality to marketing should they decide to use it. CSG’s Jennifer Davis-Martin, Kenan product manager, says there is definitely a need to provide a tool for marketing to be able to implement new products more easily; yet, while they might own the decision, it is not implemented without the assistance of or rigorous testing and checking from the IT department.
BearingPoint Director Dick LaRue says there is a need for a central repository that houses product catalog information. “That process of organizing [product] information needs to be done by an organization that doesn’t exist today,” LaRue says. In addition, he believes there is a need for a common data standard for a product definition. With this, he contends, individual systems could read into this standardized definition and take from it what they need to perform their
task. Each system might have to have its own product catalog, LaRue notes, but they can translate this information out of a central repository. That would be beneficial when calling on product information from across company divisions or when communicating externally with other providers to deliver services, for example, if a provider is selling services through another company, such as Sprint selling wireless services through Qwest, or Cingular through BellSouth.
BearingPoint’s Sathi says it is only recently that the industry has begun to see product catalogs housed outside specific systems. In the past, this data mainly resided in the billing system. He contends that now the only way to effectively organize the product catalog is to give ownership of the catalog to the ecosystem as a whole because the catalog by its nature cannot belong to merely one system. Product information and changes, Sathi says, need to belong to product managers and not to the billing systems.
Sathi also believes more attention is being placed on creating a workflow around how to change a product. “They [providers] are seeing incorrect pricing floating all over,” he says, which often results when a campaign price is not yet in another system and cannot be billed for.
Sathi suggests that after creating a standard way of representing the product information, and synchronizing that data between systems, they then need to cleanse the data to clear up any discrepancies. Clearing up the discrepancies tends to be a fairly manual process in which most providers focus their attention on 20 to 30 of their most profitable products to scrub the data. “You can’t do them all because there are too many [products], and there’s no real automated way to do the scrubbing.”
Verizon’s efforts include placing data in large repositories, such as for customer service records, billing records and for reference data and product repositories. Two years ago, when the company started its product catalog initiative, it began by pulling together reference data tables between billing and ordering applications under a common management structure.
While Verizon’s CIO championed the product catalog initiative, the IT department took on ownership of the project to create the single repository called the Verizon Product Factory. The IT department originally reached out to the business departments within Verizon to obtain their input, but those departments largely left this up the to IT staff. Now a year and a half into the implementation, Verizon will complete the first import of a product catalog into a central repository.
Product Overload
Verizon’s Kittel estimates that between voice and data services there are tens of thousands of products in Verizon’s product catalog. Yet, he says that about 80 of these products are dormant with little-to-no activity or revenue generation amongst them. Sometimes products remain in a catalog for regulatory reasons that mandate that companies cannot get rid of them even if only one customer is using the product.
Verizon had multiple initiatives in the past to trim down the number of products in its catalog. These efforts were mainly driven by taxation issues that involved tedious product audits or the complexity of regression testing required during new product implementation to ensure everything works.
According to CSG, even cable companies face significant product catalog challenges. An operator might have 250 channels, each a separate product that could be sold and each that might fit into a different premium package. “You can hurt yourself if you have too many choices,” CSG’s Thompson explains, because the consumer may say this is too much.
“You also have to be able to manage those and to provision them,” she adds, such as in the case of pay-per-view. This requires that products be defined by when they will air, or for how many weeks and at what time. “Right away, you see that explode,” she says. “In video or cable, you’re going to see more content … that makes it more complex”. And, cable operators have to be able to work with partners to send the right information to the provisioning interface to allocate the service.
Money and Man Hours
In Verizon’s product catalog project alone, about 200 staff members from the IT department were involved on both the old and new product catalogs. About one third of that team was working to move toward the new capabilities alone. On the business side, about 10 to 20 people were involved, which is more than would normally be involved on a project like this.
In the first year of the project, the company allocated $3 million, and the total cost of the project as it neared its second year was around $5 million.
Verizon consolidated its product catalog internally, yet, CSG’s Thompson comments about consolidation projects in which systems integrators may be called upon to create a custom catalog that integrates the various disparate systems. “It is very complex, and it is very expensive. It is something that is difficult to maintain and it is costly.”
Visibility
Providers often find it difficult to find the information they needed to update and change.
At Verizon, just seeing into the catalog to view existing products within the system had been difficult or impossible. This would sometimes cause product managers to add in similar or duplicate products to ones that already existed in the system, further adding to the proliferation of the number of products in the catalog. In addition, the complexity of multiple separate and distinct catalogs further exacerbated the visibility problem in that product managers could only view into the products in their own geographically based catalog. Sometimes this geography encompassed a region, sometimes merely a state. But, Kittel notes of Verizon, “We’re steadily moving toward a more national view of our products.”
ADC’s El-Ashkar notes, there is a need for two readable views of a product—both business and technical—to support users, as well as a need to have those products represented in a way that clearly represents their hierarchies.
Backward Compatible
With its product catalog effort, Verizon is working on a backward compatibility mode. The company’s goal was to develop a single repository for product information first and then to put that information into back-end systems. One of its two former billing systems, Express, used to serve as the source for product information in the Mid-Atlantic region. The company will first push product information into the product factory but will then go back and pull that information from the product factory and run it back into Express. Express will no longer serve as the master for the product catalog, but it will instead continue to be fed this information from the product factory. Currently, Verizon has to send this information into Express using the original format in which the system accepts the data. Eventually, Verizon will begin adding data back into the older systems in a newer format.
Because Verizon’s goal has been to create a central repository, the company now thinks about product creation differently. In the future, the company will develop baseline products with packages and promotions layered on top of those baseline offerings. This will eliminate the need to create similar baseline products for each individual variation. Now, with the information all in one place, the provider can adjust for nuances of the local public utilities commissions for how to tariff products. “The hope is that now that we have everything in one place, we’re going to start reengineering the back-end systems, particularly in the East,” Kittel says.
Verizon is consolidating all of its different accounts to create two nationwide billing systems—one for residential and one for enterprise customers. The company will also have two order processing systems, however the company will have only one data repository for products.
Supporting Bundles
Supporting bundles is perhaps one of the biggest challenges providers face today. Providers’ product catalogs must be flexible enough to allow multiple combinations and discounts, but LaRue notes that products within a bundle are not always the same in the billing system as they are marketed to be. “Today I would describe it as ad hoc,” he says. Product managers get people together internally, they try to obtain an end-to-end view, but they do not always succeed and instead products are often born in silos. “This entire process worked well when products were not changing that much,” he explains. But today, LaRue says, providers need to seriously consider workflow and how the introduction of a campaign ripples throughout an organization.
While the first goal of Verizon’s catalog project has been to develop a central repository for product information, the second goal is clearly to focus on using that repository to build bundles.
A significant Verizon initiative is to consider lifestyle bundles, or those that target customers’ specific usage behaviors based on their demographics.
In the next phase of development, Verizon will build out management consoles to allow product managers to have a single view of products. The product managers will use the new architecture of a central repository to build out bundles. Today, the company just bundles products and determines a discount for that bundle, according to Kittel. However, with the new view, Verizon will be able to employ a more sophisticated algorithm to determine pricing. This may involve, for example, rating with an inherent discount if downloads for a particular service exceed a certain threshold. Kittel maintains that it should then be easier to phase out old products, but he says, the success of this project “remains to be seen.”
Time To Market
Consolidating product catalogs is key if service providers want to respond faster to today’s market challenges.
Verizon’s Kittel explains that if there is a need for an “emergency release” of a product, such as a new long distance release because the company just received approval from a PUC, Verizon may be able to accelerate the product introduction process to between 30 to 60 days. However, he says there is a typical 6-month window to introduce a new product. This involves systems integration testing and user acceptance testing with between 4- to 6-week test cycles on average. In addition, there are billing tests prior to releasing the product. Then, the product would be entered into a queue to be part of a regular software release, which occurs every two months. The company would later go back and fix any bugs associated with the release.
ADC’s El-Ashkar says that most providers are in a similar boat as Verizon, with it taking months to introduce a product. She says more mature organizations can release new products within 1 to 3 months and less mature operations may take between 9 to 12 months. She adds, however, that the length of time it takes to roll out a product is correlated to whether similar products already exist within the catalog.
Overall, the effort to consolidate the product catalog was also one to move toward more modern technology in which information could be stored in tables versus embedded in code that required exhausting changes and ultimately impacted time to market.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article