Service providers would rather face Wall Street analysts than replace their current billing systems. Unwilling to write off what is typically a multimillion-dollar asset, they rig the current systems, add adjunct systems or delay offering competitive new services.
When internally designed bandages stop working and maintenance costs continue to peak, service providers are forced to consider upgrading their billing systems. "To the outside world, carriers claim they want to add functionality and to offer more competitive rate plans. What's really driving the purchase, though, is maintenance costs," says Jim Anthony, executive vice president for worldwide operations at UshaComm. "The main billing system is usually okay, but the cost of maintaining the adjunct systems is killing them."
Whatever the reason for upgrading, the purchase decision forces carriers to examine their business processes, reengineer operations and overhaul current systems. The months-long, multiphase migration project causes frustration for everyone involved if it is not managed effectively by systems integrators (SIs) and the billing company's professional services team ("Billing Companies Try On the SI Hat", describes how the migration partners co-exist).
Defining the Project Phases
When facing a migration project, service providers are likely to begin with a plan to move all subscribers over to the new system in one big bang. This approach can save dollars and limit the confusion introduced from overlaying multiple systems, but the project often gets derailed when the scope looms larger than expected. In such cases, carriers convert these big bangs to phased migrations by business unit, customer segment or region.
Whether the migration occurs all at once or in segments, the project should proceed according to certain stages. By following the same project roadmap for either case, the migration team can easily accommodate changes in approach.
Migration stages include:
o Defining a functional design
o Outlining how the legacy data will be converted
o Developing a strategy for the systems and people involved in the cutover
o Mapping the data
o Testing and cleaning the data
o Loading the data.
During the functional design phase, the team identifies the target system and the functionality requirements, including system specification, formats and elements, as well as future functionalities. This process can take six to eight weeks as the project team tries to uncover the service provider's requirements and not replicate sins of the past.
"Sometimes our interactions with clients appear ruthless, because we must make sure that what they are requesting is tangible, measurable and has interim benefits," says Graham Carey, director of corporate marketing for Amdocs in Europe. "As we near the close of the project, we don't want to discover that we're missing some important aspect that someone forgot to tell us about."
The second phase consists of outlining how the current data will be converted for the target system's required format. The team must discover what data is available from the source and if there is a problem getting the information from the source to the target system. They identify data from the legacy system that is unnecessary, invalid or missing. The missing data, which could be information related to new services that didn't exist in the old system or an upcoming marketing program, must undergo additional rules during the mapping phase to augment the data for the target system. This four- to eight-week phase also defines how data will be pulled from other systems, such as the financial package, customer care, provisioning, inventory, contract information, general ledger, account receivables, account payables, and so on.
Cutover plans, the third phase, determine the operational and technical strategy for the systems, data and people involved in the migration. This phase encompasses many areas. The team discusses concerns about the call center and network operations center and creates a strategy that will disrupt these centers the least.
Archiving and storage restraints are also outlined at this point. Service providers' first preference is to keep all stored data. But when they learn the costs of a complete archive, they tend to find expendable data. Data for cancelled customers can be eliminated; histories of active customers may be limited to 3, 6 or 12 months; service change histories can be cut. The data could even be confined to invoices and service history.
"Carriers should only store what makes sense," says David Love, vice president of operations in Logica's telecom division. "The cost of hardware and disk space plus the time to load the data usually limits the carrier to five years of archived data and three to nine months of stored data."
During this phase, the team also defines target interfaces for integrated downstream and upstream systems, such as order management, data mediation, payment processing, general ledger, and so on. Lastly, it develops a cleanup strategy.
"We have to create a plan for handling data that wasn't migrated effectively," says Darren Walsh, senior vice president of professional services at CSG Systems. "This data could be usage events from the network that might be in error. The events may be held in a suspense file that
couldn't be rated appropriately, and we design a strategy to recover the files and rate them for the proper accounts. We also define how payment systems will be updated in the new systems."
The fourth phase includes the critical mapping of the old data to the new fields in the target system. Each field's attributes are defined, and new rules for additional functionality and data are applied. This stage is usually the most time-consuming unless the design and analysis stages are sidetracked by lack of knowledge about the data or difficulty gaining the information from the service provider (see "Braving Customer Intervention," for the less technical, more human challenges tackled during a migration project).
The business rules and mappings are then tested during the fifth phase. Here, mapping errors and exceptions are identified. The data is scrubbed based on the found errors and tested again until the errors and exceptions are corrected.
Loading the clean data into the target system is the sixth and final phase, which can take anywhere from 24 hours to four or five days. Each billing company has internally developed loading tools that ease and speed this process. These tools are usually basic Oracle scripts that load flat files into the billing system's database. The tools' robustness depends on how well the billing companies have incorporated their past migration experiences and knowledge into the software.
Dealing With the Data
The migration team faces no easy fixes during the project's early stages, but the final steps, data scrubbing and migration to the target system, make-or break-the project.
"Half the battle is cleaning the data," says Jim Thompson, a project manager for Sentori. "The project's scope is not just moving the data, it's converting it, cleansing it, and developing automated processes that speed the process."
Identifying what data to move from the legacy system depends on the target system's data fields. Only the data needed for the new system will be captured from the old system and converted. Data not available from the legacy system will have to be created or transferred from other systems. Incorrect, incomplete, missing or inaccessible data-all the messy data, in general-keep this step from progressing quickly.
The migration team deals with dirty data in any number of forms. "The process for cleaning the data is a mix of tedious manual labor and some automation," says Becky Dancy, executive director of business development at Abiliti. "Maybe about 60 percent can be automated, but if the service provider has gone through multiple mergers and acquisitions, the project will require much more manual work to migrate the data from multiple billing systems."
During the cleansing, the team searches and deletes dead accounts and irrelevant data, such as changes of address or contact details that are no longer accurate. They also identify data that is missing, such as customer addresses, or data that must be adjusted. In one legacy database the field may only allow six characters, another legacy database may have eight characters. This data is mapped to reflect the same number of characters in the new database.
Another example of adjustment is subdividing a single field in the older system into multiple fields for the new system. In the legacy system, for example, a single field may represent the entire customer name; in the new system, the customer name may require three fields, for first name, middle initial and last name. A simple algorithm is designed to extract three pieces of data from one.
Much of the clutter is a direct result of the legacy system's inflexibility. The old system may have misidentified fields, due to an earlier "fix" in which the IT staff forced the older system to satisfy new requirements. The staff might have squeezed information into an unpopulated field. The customer number field, for example, may have been unused, so the IT staff designated that field for the purchase order number. Such mislabeling can cause confusion for the migration team, because they might assume the field labeled "Customer Number" is the customer number, when in fact it represents the purchase order.
Customer deposits are another area known for missing data. Jim Flynn, projects director at Logica, explains, "Providers often want a business rule that all customers must maintain a deposit. When we review the legacy data, though, we find lots of accounts that don't have deposits. The [provider] has two options: correct the legacy data or load the data as is. Most want to correct the data before the upload. They will try to find out if it's a data entry error, or they may have to call the customers and get a deposit.
"If time restraints prevent the provider from correcting the data, we can automate the process by uploading the data. We create an algorithm of 'if no deposit, add comma, load and set field to 0.' With this option the customer can add deposit information after the new billing system is in place."
Reducing the number of rate plans also requires data scrubbing. Legacy systems may be supporting up to 200 or more rate plans. Once the service provider has defined a smaller set of rate plans, the customer data must be cleaned according to the new plans' data parameters. Some customers may transfer easily to the current plans, but many will require outbound calls from CSRs to convert them to the appropriate topical plans. During this conversion, the project team will also attempt to correct inaccurate data. They will examine employee rate plans, for example, to identify old hires who are no longer at the company. These subscribers may still be receiving discounted employee rates and will need to be converted to a more appropriate rate plan.
These data cleansing sessions can also uncover missing revenue. A miscommunicated field in the legacy system can alert the project team to service features implemented on switches that haven't been billed for in years. The service provider may have to physically go to the switch and define which services are running through it, but this work will locate lost revenue.
Each of these data errors, as well as hundreds more, appears in exception reports. The errors can be any number of things, as the project team produces hundreds of thousands of exception reports during the testing phase. These reports may reveal that although 5,000 accounts were converted, only 2,000 accounts are on the new system.
"The exceptions may be due to a mapping error," says Julie Mendenhall, senior project manager at Convergys. "A particular account may have not been mapped. That's a simple fix. Or it could take a lot of investigation. We have had accounts with no services, or services with no accounts. The service provider might have to go back to the switch and define exactly what services are on the switch."
Once the exception reports have been significantly reduced, the clean data will be further tested through an audit. "A key to a successful migration is defining a parallel set of functions and processes for an audit trail," says UshaComm's Anthony. "You need clear reports that show what came out when the 20 million accounts were unloaded and reloaded in the new system."
The customer and project team will review the clean data by testing a sample, possibly as low as 5 percent, through both systems. The team will review the outputs from each system, screen by screen, catching errors along the way. A campaign or package may have been mapped improperly, resulting in a bill amount for John Doe in the legacy system not equaling the bill in the new system. For this type of error, the mapping must be corrected and the conversion run again.
When all critical exceptions are fixed, the data is uploaded to the target system, and the cutover begins.
The Hard Decision: Time to Market vs. Costs
Invariably, migration projects don't exactly meet the terms of the original scope. Instead, cutover dates are pushed back, the data cleansing is not as comprehensive as first planned, or the complete range of functionalities first proposed is not available.
"Customers have grandiose plans to clean up discounts and make sure the customer base is exactly right," says Abiliti's Dancy. "They may start the project with 10 must-haves. As the project closes, when they are racing the clock, those must-haves are scaled back to three or four critical items."
The migration team works closely with customers to salvage projects when they veer off course. C-level executives, who were involved in the early project stages, make the critical decisions about which items get the green light and which are put on hold. "We assign a strong executive oversight committee, made up of the CIO, executives from the provider's business community, executives from our organization and execs from any other group on the project. This committee thoroughly understands the business drivers and handles all decisions affecting timing and costs," says CSG's Walsh.
The billing companies are unwilling to give a lot of details about the give and take that occurs as customers go through the decision-making process, but UshaComm's Anthony says time-to-market concerns are always heavily weighed. When cutover dates near, the carrier will opt for less than spotless data or will migrate smaller slices of the customer base over to the new system so that it can meet deadlines and bring a new service to market. The unfinished aspects of the project will be phased in after the initial, partial migration.
Defining what pieces of the project are the must-haves, or core to business success, is a carefully choreographed dance between the migration teams and their clients-where the billing companies try to lead without treading on toes. "We don't just sit back and say to the client, 'Yes, you're absolutely right.' We try to help them understand the business aspects and the critical success factors of the migration," says Amdocs' Carey. "We define the necessary constraints, and we clearly explain the risks and consequences of not doing something."
But when it's time for a judgment call, as Dancy says, "the final decision is in the customer's hands."
Service providers have consistently relied on systems integrators to take the lead in customer migration projects. The SIs are usually responsible for the overall business mission of the project, and the billing companies support the aspects that relate to their product. The tighter economy, however, is forcing a few billing companies to venture into projects that were previously out of their scope. “When the billing developers are selling well, we don’t compete with them,” says David Love, vice president of operations in Logica’s telecom division. “They want us to do the configuration and migration. But now they are eating into our space a bit, because they have people on payroll that need to keep busy.” More and more, the larger billing companies are talking about delivering business solutions and defining business processes, but not all agree that the shift is a good strategy.
“The changes are due to the economic times. Now that players can’t get licensing revenue, they have to morph themselves into something else,” says John Vu, vice president for new business at Sentori. “We want to stick with what makes sense to our business and what we know. We want to maintain the software’s quality rather than expand into areas we may not be able to handle. This strategy is better than trying to get into a business that competes with our partners. Too many companies fail when they attempt that.” But CSG’s Darren Walsh, senior vice president of professional services, says there are solid arguments for relying only on the billing companies. “We can usually complete the projects more quickly, because we know our systems better,” he says. “Our ramp-up time to do conversions is minimal, but it could take some time for the SI to come up to speed.”
Amdocs’ Graham Carey, director of corporate marketing in Europe, agrees that product knowledge helps their case. “SIs have a tendency to work more at the business planning level. They are looking at the big picture and handling the planning and task management,” he says. “When it comes to the actual work, though, we are best suited for the intricate details. We have the greatest amount of knowledge about our product.” The billing companies do know their product best in some cases—but not in all cases, says Jim Flynn, projects director at Logica. “In North America,” he explains, “many billing companies’ engineering staff and software developers are located overseas. We often have more experience with the product because the local group doesn’t know anything about the software.”
For the most part, the smaller billing companies steer clear of large migration projects. Jim Anthony, executive vice president for worldwide operations at UshaComm, says his group can handle migrations of up to 1 million accounts, but he counts on an SI for anything larger. “We would rather be known as a product company. We will always offer some degree of professional services, but for a full-scale integration, you better know what you’re doing, and we rely on an SI.”
The SIs agree that the billing companies have an integral role in the migration projects, but they point out that the developers aren’t equipped to handle it alone. “Product vendors focus on what is necessary to get the product to function properly,” says George Bordo, vice president of service provider solutions at Danet. “Integrators focus on the business mission of the customer. The billing companies may believe that moving data into a new format is the slam dunk, but migrations involve a lot more than reformatting data.”
Migration teams face a major challenge in scrubbing data and transferring it from the legacy system to the new one, but what often stymies them is the human interaction.
“Trying to pick the customer’s brain is extremely labor-intensive,” says Jim Thompson, a project manager for Sentori. “We’re very experienced and efficient at coding, configuring and writing scripts. The humans introduce errors, and correcting those errors requires multiple interviews and testing to ensure we understand what they are telling us.”
Much of the cross-examination concerns the data. Most carrier customers don’t understand the relationships among their data. If the customer can’t explain how one field relates to another, the migration team must go through a thorough discovery process to create the proper mapping. “Expecting a customer to know their data is at times a large assumption,” says Becky Dancy, executive director of business development at Abiliti. “We ask what seems to be standard questions about their data, but they don’t have answers. They know nothing about how the data is stored in multiple systems.”
Another challenging and time-consuming task is creating a workflow chart that reflects planned business activity and that in turn can be translated to business rules applied to the new data for the target system. “It sounds simple, but understanding the business requirements and identifying all the parameters you need to configure the database should not be underestimated,” says Julie Mendenhall, senior project manager at Convergys. “Developing these definitions plays a big part in how painful—or painless—the conversion will be.”
Nailing down these workflows requires a thorough knowledge of the business, and because the process requires people to break down each business step for analysis, companies often discover inefficiencies and end up making organizational changes as a result. Extracting the current business workflow, redesigning the progressive steps for efficiencies, and tailoring the rules for the specific business unit cannot be replicated. While data loading and cleansing can follow many of the same standard, repeatable actions, each customer has unique business function requirements and specifications.
Yet another major trial of human behavior for the project team is convincing carriers to take advantage of all the new software’s functionality. Carriers tend to balk at implementing some proposed efficiencies for fear of disrupting familiar workflow activity. “Sometimes it’s difficult to convince customers to use all the power available from the new system,” says Jim Anthony, executive vice president for worldwide operations at UshaComm. “Instead of taking advantage of real-time collection of usage, they will continue with their nightly runs. The typical telco doesn’t like change, and they tend to fall back into their old ways.”
Extensive internal education and training on the new system, he adds, can guide staff away from familiar patterns and toward the new efficiencies and capabilities enabled by the new billing system.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article