Verizon Business in 2006 set out to reach a $550 million target in merger synergies, which included migrating network traffic and streamlining BSS/OSS.
Twenty-four months later, the company has grown to $21.2 billion in revenue while managing to migrate more than 80 percent of its voice traffic from the legacy Verizon Global Network Services network and 68 percent of all IP traffic on the Verizon Business network.
The migration has continued into 2008, and by third quarter of this year, Verizon Business will have completed its goal of reducing 35 billing systems to four, as well as reducing hundreds of OSSs to more manageable numbers. Consequently, the company expects a 15 percent reduction in billing errors this year.
Verizon Business’ Alan Mott and David Landry |
Consolidation is driven by its Billing Transformation and Single-Stack initiatives, which include streamlining the fulfillment and assurance components tied to each product catalog. The intent of the initiatives is to reduce complexity and foster re-use of services. These initiatives will improve the delivery of services to enterprise business customers and enable salespeople to bundle and unbundle services without spawning new OSSs. That will help Verizon Business accommodate new and evolving feature sets while reducing operating costs.
Verizon Business’ Billing Transformation and Single-Stack initiatives have fueled related initiatives to streamline data, processes and systems in order to reduce the number of product catalogs and system silos used for ordering, provisioning and billing.
Employing SOA principles and Web Services interfaces, the company is fostering a mindset of re-use for systems supporting multiple product suites.
By rationalizing product catalogs and normalizing data crossing different functional areas, Verizon Business is creating more consistency across product sets that span a growing customer base in the North American, APAC and EMEA regions.
Billing & OSS World Contributing Editor Susana Schwartz spoke with two members of the Verizon Business organization that worked in tandem to execute on these goals: David Landry, executive director of sales support and billing systems, and Alan Mott, director of systems planning and architecture. Both are building a road map that will serve enterprise business customers across the globe.
Billing World:
What drove the two of you to work together, as opposed to independently?Landry:
We knew we needed to infuse cross-discipline expertise into each of our respective delivery teams if we were going to foster global consistency — whether billing, provisioning, service assurance or ordering. We wanted to be able to re-use network elements, OSS components and billing systems so they could support many products. We didn’t want to continue to create new product stacks to order, provision, bill and monitor products on the network.To succeed, we had to combine our enterprise architecture vision and strategy with the working knowledge of each functional area. My team quickly developed a fully articulated billing systems plan called Billing Transformation. Alan, as the director of systems planning and architecture, had the expertise to help integrate and coordinate our plans. Eventually, he became an integral part of my team.
Mott:
About two years after the merger, we started to seriously explore how consolidation of systems and product catalogs could actually enable more choice, as opposed to limiting it.We both believed in SOA, and we both believed in pursuing a ‘workbench approach’ to projects using Web Services and burgeoning standards like [shared information data (SID) models], which were coming together to help us consolidate thousands of products comprised of many different equipment types from multitudes of equipment vendors. The ability to easily create interfaces among underlying network components would help feed the necessary data to the OSS/BSS through which services would be quickly bundled or separated. Increasingly, customers and marketers were using the company’s Web portal to utilize and manipulate sophisticated pricing plans and feature sets, so we needed to be able to fold services on the fly so they could be grouped or bought independently according to demand.
By streamlining redundancies, we thought we could have a clearer picture of what features and capabilities would be standard in our products, and which features could be offered up as extras, without creating entirely new product silos.
Billing World:
Was your approach a phased initiative or a multiprong approach where many things were happening simultaneously?Landry:
We ended up doing several things at once, because we started to see how one initiative could affect another. We first set out to reduce the number of provisioning and repair systems in our Single-Stack Program so that ordering, provisioning, billing and monitoring products on the network would not require more silos. The goal was to break away from individual product stacks — each of which possessed its own systems. In looking at doing that, we agreed that rationalizing and normalizing data would greatly benefit the effort to consolidate product catalogs. If we could reduce the number of product catalogs, we knew we could also reduce the number of billing and OSSs we needed.Mott:
We had 35 billers that we wanted to get down to about four, and we have hundreds of OSSs that we will significantly reduce by Q3 2008.In the billing consolidation effort, we continue to determine which product-specific billing systems from legacy companies should be allowed to rust away, based on the level of difficulty to manage or migrate them.
Ironically, convergence has also meant we have to, in some ways, expand to consolidate. After defining our new billing support landscape, we had to reevaluate our wholesale system, a large-scale LEC system used as a local billing engine. We also had to look closer at the long-distance (non LEC) voice and data engine. Because we had an older system for wholesale and LD voice and data, we decided to do a one-into-two conversion, so that the charges would be separated out into two bills.
In instances where we were accepting products as they were for the new billing system, we conducted a normalization exercise, as well as propagation of products from old to new. Simultaneous to the normalization and propagation, there was a pointed effort to communicate with customers proactively about why a single bill would be turning into two. We wanted to define the differences in format and the different billing products that would now be available.
Landry:
We didn’t want customers to be confused by the systems migration and evolution, so we prepared call centers to answer questions from customers. There was also an external communication plan that proactively explained the changes to our customers.Because Verizon Business and Verizon Wireless share many of the same large business customers, we have begun to enhance the Verizon Business Customer Center (VBCC) portal to offer a common experience for voice, data, IP and wireless services. Ultimately, we want customers to have options to integrate services from each arm a la carte in a zero-touch, portal-based environment
Mott:
In order to offer the common experience, we chose to collapse systems as opposed to embarking on a larger task of designing target systems that would support all customized flavors of products.We needed a consolidated view at the top of the stack in order to streamline and to create a flow-through environment in which customers and sales and marketing could manipulate products through different views to the same data.
To achieve that, we had to identify the common data elements and processes that were shared among customers and product sets. As it was, the data was distributed among far-flung systems and there was little understanding of the interrelationships among different product catalogs across the Verizon organization — wireless, wireline and managed services.
Billing World:
How did you break down the processes and the data paths in order to determine what to keep and what to collapse?Mott:
One by one, we went through product suites to see what we were offering, and how we were structuring the products. From an architecture point-of-view, the task of automating processes from time-of-sale to provisioning was complex. We had to evaluate the paths data took based on the product stack, and evaluate the ease of implementation of equipment to create more optimal paths. We had to consider the labor needed to provision orders, and weigh that against the volume and profitability of the product.It was noble that in the past companies customized their products over and over again to accommodate the customer, no matter what the cost. But now it’s about time-to-market and flexibility. You have to run efficiently so that the ordering, provisioning and everything from sales down to activation isn’t marred by an inability to deploy and decommission products quickly. There has to be a balance between customization and the ability to act quickly.
Portfolio rationalization has thus become a mission for us. We look at products and anything that could be considered sister products. If we have frame relay and ATM products, we consider how they are similar, and then decide which one is better suited to be migrated to the other. We base that decision on what will take the least effort to migrate to the other platform.
Portfolio rationalization also means comparing what the market says is hot as compared to what customers are actually using. For example, you can have an IP product with hundreds of different spinoff products offering a very large range of capacity and speed parameters. By going to marketing and asking them to break down the embedded base, we discovered that only a small percentage of customers actually considered different parameters for speeds in IP services as a differentiator. So we went back and rationalized, using the 80:20 rule. We took the speed the majority used and made it part of our standard options, and then we sloughed off what turned out to be scores, and sometimes hundreds, of extraneous parameters that were rarely used in a profitable way.
For product suites that engendered particularly large-scale billing systems, we put together an aggressive convergence strategy. Those customers that had odd product configurations were the first we tried to convert to newer, more strategic products. It was just more difficult to get hierarchies to synch up enough to improve delivery, so we coordinated with sales and marketing teams to get them to upsell to those customers. Subsequently, we ended up doing mass conversions of five customers and we have another six that we will be doing the same for in upcoming months.
With those we were converting, we had to make sure to consider how the downstream embedded base using grandfathered products would be effected if we migrated them, as they were using parts of our network that we had inherited with the merger. We didn’t want to disrupt their service by not realizing they were using legacy elements. It became obvious that each stack was dependent on its history, as previous iterations of product catalogs were sometimes created to offer feature sets that could not be added to the legacy systems involved in delivering those products.
Landry:
The integrity of the product catalog is so critical to ordering and provisioning, so we knew we couldn’t just turn off legacy systems and replace them with some sort of all-encompassing product catalog that encompassed new bundles.Instead, we narrowed down the configurations to those that we thought were optimal and were most likely to provide a seamless ordering process for future products.
Billing World:
Why might this overhaul make Verizon Business unique?Landry:
We knew many competitors were avoiding the pains of consolidation and convergence, and we knew that rationalizing the billing landscape should be a business driver, as opposed to an afterthought. We knew if we could streamline and automate to improve billing accuracy, and create flexibility in how products could be bundled, we’d improve marketing’s ability to satisfy customer demands for choice, as well as mitigate errors and revenue leakage. We will see an additional 15 percent reduction in billing errors this year as a result of our efforts.Billing World:
How did you attack the challenge of changing products out on the network side and consolidating billing without disrupting the service?Landry:
There is no free lunch. We did it through careful planning and partnering with our finance, marketing and service organizations to thoroughly test each migration. We coordinated our efforts at all levels of the organization through an Executive Steering Committee that oversees billing transformation and cross-functional working teams that ensure the delivery of every individual initiative.Mott:
The process involved working with marketing and sales, and with regulatory people because of the ramifications to multinationals, which have to work with different rules around ordering products and how they are contracted country to country. We had to make a subprogram to ensure we could optimize by leveraging the IT architecture.Landry:
We had to accommodate differences country by country, but avoid building out separate product catalogs for EMEA, APAC and domestic U.S.That meant we had had to really dig in and understand the process and the legal ramifications of how we had to work with each country’s telecom governing body.
Billing World:
What were the most important factors in succeeding in these initiatives?Landry:
Critical was the development of frameworks for analyzing systems before going down a path of execution. For example, one of the major capabilities we needed was the ability to import third-party equipment catalog entries into our catalog so we could offer customers around the globe a consistent Verizon Business experience.Customers turn to us for solutions (e.g., managed networks, call centers, data centers, etc.) that consist of professional services, voice and data services, and products from third parties. So we have to build interfaces to other parties’ equipment all the time. Every manufacturer has its own catalog — each of which comprises tens of thousands, if not hundreds of thousands, of parts. We had to know what subset of components would have to be synchronized among manufacturers of equipment so there could be consistency in how services were experienced anywhere in the world. The frameworks enable us to analyze the source catalog and map it to our target catalog more efficiently.
Mott:
That’s why another key enabler is Web Services, which has helped us to update product catalogs among different equipment manufacturers. Typically, we get Web Services and XML structures that we have to customize for each manufacturer, each of which has its proprietary way of publishing catalogs.There is now a movement to fold out SID language as a standard to describe data structures in products. There isn’t yet wide-scale adoption by suppliers, but ultimately that will help us further the effectiveness of how we build interfaces.
Links |
Verizon Business www.verizonbusiness.com |
