Four common situations when replacing billing system software

Summary

Businesses replacing their existing IT systems will encounter four common situations that reoccur with each replacement, are similar between different business functions, and have relevance across different industries. From the perspective of a billing system replacement, these four situations translate into:

Migrating legacy customer data from the existing billing system to its replacement
Guiding network transactions to the correct billing system
Transforming transactions and files (interfaces) between incompatible formats
Supporting ongoing customer maintenance

These situations are common across industries and a brief example using the replacement of a retail banking platform is included at the end of this column.

Migrate legacy customer data to the replacement billing system

Existing customer data residing on legacy billing systems must be moved across to a billing system's replacement since it reflects the current customer relationship, the customer's historical purchases (spending patterns / levels), and supports the biller's financial records (revenue, debt). The customer's data must be carefully extracted, validated, reformatted, supplemented, relocated (moved) and loaded into the replacement billing system.

The replacement billing system software may store its customer data with slightly different relationships and field values, may be on a different platform (mid-range not mainframe), encode data differently (ASCII versus EBCDIC), and require defaulted values in fields nor present in the existing billing systems' databases.

Specialised software may be employed to identify customer names and addresses for correction or 'cleansing' to a uniform quality before it is populated into the replacement billing system's databases. Part of this data cleansing may include the 'matching' of multiple instances of the same customer's details currently stored in the legacy billing system. This data matching and cleansing process allows the biller to consolidate their customer knowledge, and avoid dragging historical data errors into the 'brand new' billing system.

The process of data cleansing and matching can be performed ahead of the data migration allowing the biller's staff to review reports and update the customer data where it is appropriate. Care must be taken that more common customer names such as 'Stephen Jones' are not consolidated automatically, and that similar names that could be data entry errors, such as 'Stephen Jones' and 'Steven Jones' are considered carefully before being corrected.

Some slowly changing customer data can be pre-migrated to the replacement billing system to reduce the processing load during a migration event. This needs to be managed carefully to address situations when a migration is canceled before it commences or must be rolled-back due to excessive errors or system failures.

Guide transactions to the correct billing system

Migrations can either be performed as a one time event ('big bang') or staged over two or more events distributed over weeks or months. Smaller billers may migrate in one event, but most larger or more complex billing environments will require multiple migration events and the concurrent operation of both legacy and replacement billing systems.

Transactions from the biller's network (e.g. phone calls, tollway journeys) or from external organisations (e.g. third party content, international roaming) must be guided to the appropriate billing system based on where the customer's data currently resides. Transactions also include database inquiries and updates from external systems (e.g. CRM / Customer Care applications) which may require additional guiding on their return journey.

Transactions may be received and processed in batched files or in real-time. Batched files can be split into two 'new' files and sent on to the separate billing systems with record counts and totals suitably updated. Real-time transactions must be examined quickly and forwarded promptly to the appropriate billing systems for processing. Complexity (and costs) occurs when 'part' of a transaction must be addressed by one billing system, and the remainder by the other - these circumstances must be a factor when the biller decides how to divide their customer base into multiple migration events.

Transform transactions and files between formats

Each interface to the legacy billing system software, both upstream and downstream, must be evaluated to determine whether it must be integrated with the replacement billing system. Some interfaces will be specific to products sold only on the legacy billing system and not carried across to its replacement. Other interfaces will be specific to the operations of the legacy billing software (e.g. sources of reference information).

Most interfaces will require integration to the new billing system, and the formats of the existing interfaces and the new billing software are unlikely to connect without modification. The systems upstream / downstream of billing could change the formats of the files / transactions they produce / receive, but this approach would adversely affect the legacy billing system's ability to receive / produce these same transactions. Most billers try to minimise the level of development / enhancement in a billing system once they have decided to replace it. The replacement billing application could be changed to accommodate the existing formats, but some billers enforce a strategic choice and avoid such changes.

The alternative is to place a data transformation layer between billing and its upstream / downstream interfacing systems minimising any interface changes required. Each billing and upstream / downstream system uses the formats they would like to, with the transformation layer acting as interface 'glue'.

When the migration to the replacement billing system is complete, the upstream and/or downstream interfacing systems can be updated to generate / receive the standard formats of the replacement billing system (assuming the billing business owners have the political / strategic / technological / financial clout to enforce such a change). If the data transformation layer is retained indefinitely to avoid changes in 'vanilla' upstream or downstream vendor software, the legacy formats can be removed and the transformations optimised to perform only the (contemporary) processing required.

This transformation processing is straightforward when only the billing system software is being replaced and existing interfaces remain unchanged. Processing becomes more complex when upstream and/or downstream systems are also being replaced. For example, the (downstream) corporate financial applications may be replaced at the same time as the (upstream) network mediation system(s) are replaced requiring changes to the formats both upstream and downstream at the same time. Each combination of processing paths a transaction might follow must be worked through to confirm required data's availability and avoid unintended restrictions on regular processing or migrations.

Support ongoing customer maintenance

During the migration to the replacement billing system, new customers will continue to connect to the biller's network, existing customers will purchase additional products, modifications will be performed on previously purchased products, and customers will terminate their relationships with the biller. Each of these circumstances must be addressed in as seamless a manner as possible.

During the period of customer data migration, some customer maintenance may be performed manually using an exception process, or only allowed once the customer's data has migrated to the replacement billing system. The frequency and impact of these exceptions must be managed carefully to avoid excessive manual workloads, and to reduce the impact to the customer (and biller) if a customer-requested action cannot be performed (yet).

Accurate details of each customer's network services are required to support the guiding of transactions to the appropriate billing system. At the beginning of the migration process, a one-time extract from the legacy billing system provides a starting list of where all (network) services are located. This will remain accurate whilst all changes are reflected into the 'guiding' database and no customer data is migrated to the replacement billing system.

As customer data migrations are performed, the accurate ongoing maintenance of the 'guiding' database is crucial to ensuring that transactions are sent to the correct billing system. Billers must decide the billing system within which 'new' connections will be placed, reflecting the details not only in the appropriate billing system, but also in the guiding database.

As part of a migration event, mass changes are required to reflect the now migrated customers' new billing location. This customer maintenance is performed at high-volume and in a short period of time, rather than the gradual workload of regular maintenance. The time to perform this peak-processing load must be considered when migration events are planned.

Example: Replacing a retail banking platform

The four situations outlined above with a billing focus also occur in other industries. For example, the replacement of a retail banking platform must consider the same issues and complexities to be successful The concepts and functional domains may be different, but variations on the same situations must still be addressed.

Migrate legacy customer data: Financial transactions stored against customers' savings, cheque (checking) and credit card accounts must be moved from the legacy platform to its replacement quickly and accurately. Since banking is now a 24x7 function, the ability to perform (some) customer transactions whilst the migration is underway must also be considered. Pre-paid billing must also address service continuity and financial balances (real-time balance management (RTBM)) during the migration of its services. Most post-paid billing situation are less complex since the short-term removal of the billing platform does not affect the completion of network transactions.

Guide ongoing transactions: Transactions from ATM networks and the banks own retail branches must be guided to the appropriate banking platform for approval / completion. The location of individual banking accounts will change as customer data migrations are performed, and during a migration event special processing rules may apply to support 24x7 operations.

Transform transactions and files: Formats for external networks (ATM, credit card) are fixed and are unlikely to change to suit an individual retail bank. The retail bank may require format or encoding changes to interface these networks with their new banking platform, or industry 'standards' may drive banking software vendors to modify their solutions' interfaces to connect with each country's dominant local and international banking networks.

Support ongoing customer maintenance: The bank's customers will continue to establish and close accounts and modify the details associated with each. If the bank has a centralised 'customer' (rather than bank account) database then changes must be reflected to both the legacy banking application and its replacement. New banking products may need to be established and supported on both banking platforms for customers to purchase / choose.

Tags: Billing, Transaction Guiding, Customer Maintenance, Data Transformation, Data Migration