Flipping the Billing Switch

ALLTEL recently won a major victory: a successful flash-cut conversion of approximately 400,000 wireless customers in Alabama, Arkansas and Oklahoma to its new, state-of-the-art client/server customer-care and billing system. But the victory was not just in the results. It was in the realization that months of hard work paid off in dividends. "Billing system cutover" is an ugly phrase in any industry. Forget the appealing benefits and conveniences of a new customer-care and billing system. The mere thought of shutting off one system and transferring important files and data to another system is reason enough for many carriers to shy away from the needed transition. But there is hope.

ALLTEL completed a flash cut to the Virtuoso II (V-II) system over Labor Day weekend. During the conversion, ALLTEL transferred more than 400,000 customer accounts to the V-II system almost instantaneously. It was not a piece-by-piece transfer. The team implemented an all-encompassing cutover with a high success rate in terms of data conversion.

For carriers that are interested in, but afraid of, a billing system conversion, here are some examples of what worked and what didn't work for ALLTEL. Use these experiences as a guideline of what to look for as you move forward with the cutover process.

Assembling the Team The first step was to assemble a project team. We divided our team into several committees, including training, network, development and data conversion. Each committee had a sub-plan leader responsible for defining all activities and meeting deadlines. We recruited 99% of our conversion team internally with support from all areas of the company -- marketing, accounting, operations, customer service, collections and technicians.

This internal support was invaluable to productivity because our team members' knowledge of the business allowed them to understand the impact of this conversion and the requirements necessary to make it work. They realized that this would not simply be a change in our billing system, but a reconstruction of all third-party interfaces as well.

After the project team was created, the team performed a gap analysis. This involved analyzing the existing system and the proposed system, and identifying functional gaps between the two. What did the new system lack? Were there functionality differences that created voids in certain areas with the new system? If so, we determined how to fill in those gaps. Our options were either to adjust the software by developing enhancements to fit our needs, or to find new ways of doing business that eliminated the original needs.

When considering a new billing system, never assume that the product works just as it is presented to you. Testing the new system is critical. ALLTEL spent several months testing V-II to validate the product. This step is crucial not only to verify that the system will perform as the vendor says it will, but more importantly to make sure that your specific business practices do not invalidate its functionality. Often a carrier needs to use the system differently from the way it was designed, so you must test the company-specific core functionality of the system.

Once the gap analysis and acceptance testing was complete, we defined the scope of the conversion. We determined that we needed enhancements for future service offerings, wrote conversion programs for the exchange of data, developed the network plan, determined equipment purchasing needs and constructed the network configuration. When you address these issues, look at the needs from a user standpoint as well. How many servers are necessary for the number of users? Do you need to replace their workstations? Do they need equipment upgrades? Also determine training needs. How many users must be trained? What is the best method to train them?

When the scope definition is complete, more testing should follow. In fact, our system testing consumed the majority of the conversion time line. Test the conversion programs, enhancements, and batch-processing and on-line performance. During on-line performance testing, simulate the same number of users simultaneously that actually will be using the system. Otherwise, you won't get an accurate reading of the system's capabilities. Remember that the system will perform differently in terms of response time and stability with one user than it will with 1,000.

This exhaustive testing will pinpoint several issues you will need to address. For example, we encountered some data-conversion problems. In fact, we modified the conversion programs numerous times in order to ensure an accurate exchange of data. Many of our enhancements were modified as well. On-line testing revealed that we needed more servers to support the number of simultaneous users.

Building a Time Line The next step for the project team was to develop a conversion time line. It is important that the time line be a cooperative effort because each piece of the plan is dependent on the needs of some groups and the capabilities of others. The team leaders held many sessions to define what expectations were feasible and to develop a common time line that met the needs of each group as well as the overall conversion objective.

Once complete, it was time to put the time line into action. The training team developed training programs, the network team ordered equipment, the development team designed enhancements, and the conversion team mapped data to support the upcoming transfer of systems. The sub-plan leaders continued weekly tracking meetings to monitor risk, late deliverables and potential problems. They also identified necessary hardware configurations, which involved planning ahead -- the system not only must handle the current number of customers, but also additional customers in the future.

The weekend before the live conversion, we conducted a mock conversion. In this trial, make every effort to create an identical atmosphere to the upcoming live conversion. Use the same time frame, data, processes, resources and implementation plan that you will be using during the actual cutover.

When it is time for the live conversion, have a contingency plan. This backup plan will give you and your customers additional reassurance.

Above all, a successful conversion requires carrier involvement. Vendors don't know each carrier's individual business practices and can't make all of the decisions on the carrier's behalf.

Similarly, the whole company must be on board, not only in support, but in participation and input as well. For example, the marketing department should communicate its upcoming promotions that will be dependent on the new system's capabilities. Each department can contribute vital information that will improve the long-term success of the new system.

In the midst of the conversion plans, we implemented the convergence of our wireless and wireline companies and introduced a new bundle of service offerings including long distance, Internet, PCS and CLEC. Because our internal departments were communicating, ALLTEL was prepared to support these additional services with V-II.

So, is all the hard work and planning worth the effort? It depends on the system, and what that system will do. Define your own needs, research the options, and make a decision. If you do decide to convert, careful preparation and cooperation will ensure you are as pleased with the product as we are.

ALLTEL's conversion of 400,000 wireless customer accounts was the result of months of hard work and planning. ALLTEL executives share some tips that can help ensure your cutover is just as successful.

* Identify and fill in the gaps. Conduct a full functional review of the new system in relation to the old system and to future needs. Respond to any gaps through development or business changes.

* Control changing business needs. Develop a reasonable scope up-front and stick to it. Any changes absolutely necessary to the project plan should be subject to justification and strict change-control processes.

* Be prepared to freeze development in the old system. As conversion to a new system draws near, discontinuing development in the old system will help avoid dual development efforts and resource waste as well as help to keep the old system static for testing purposes.

* Develop a solid plan. A plan should be built that encompasses all functions of the conversion effort (such as development, training and testing). Each function or sub-plan should have an owner and track to a master plan.

* Implement processes that work. At the start of the conversion, define and implement proven management methods that will include planning, tracking, communication, risk mitigation and escalation.

* Consider customer impact of conversion. You should evaluate bill format changes, rating differences and changes in customer service response. You may want to notify customers in advance of any visible changes.

* Don't forget about third-party interfaces. Often, billing system conversions also affect ancillary systems such as point-of-sale and commission systems. You must evaluate all interfaces to or direct feeds from the billing system. The conversion scope will need to include rewrites, modification or elimination of existing interfaces.

* Test, test, test. Test conversion programs (mock conversions), any enhancements, performance testing (including on-line and batch performance) and all core functionality. Don't assume that all core functionality works as represented.

* A mock conversion should be as close to the real thing as possible. It should have the same time line, same resources and same plan. Problems that crop up in the mock conversion will indicate problems with the live conversion plan.

* Don't train users too soon. Ideally, user training should occur no more than six weeks before conversion. If the conversion date is delayed, be prepared to retrain or to give refresher courses to users.

* Bring the entire company on board with the conversion plan. All areas of the company should be cognizant of the conversion. Lack of awareness of the impending conversion will result in unwelcome surprises to the conversion plan. Also, user involvement will improve acceptance and responsiveness to the new system.

* Knowledge of the carrier business is essential to managing a successful conversion. A conversion is much more than the technical "bits and bytes" work. The conversion team must consist of users and customers. These people should be responsible for evaluation/revision of business practices, training, user support and business impacting conversion decisions.

* Hope for the best, and plan for the worst. Conversions are ugly, even at best, and major problems can arise. Make sure contingency plans are detailed, and define acceptance criteria for all modules of the system. Also, define overall back-out plans in case there is a need to revert back to the old system.