With the introduction into the collections and recoveries (CnR) systems market place of Debt Manager 9 (DM9), an accompanying consideration which prospective or newly signed up clients will need to take on board is with regards to migrating across Customer and Account data from existing C&R system(s).
Migrations come in all shapes and sizes, and while there are invariably a range of specific local dimensions, there are also a number of common aspects which can influence the approach. Some primary ones include:
• Complexity of migration i.e. just one existing CnR system or multiple CnR systems; IT or End User Computing (EUC) solutions
• Volumes (not just a Customer/Account count, but also depth of data)
• Quality of data residing on existing CnR system(s)
• Alignment of Customer/Account data structure between existing CnR system(s) and DM9
• Potential utilisation of new BAU interface into DM9 for migration purposes
• Cost of undertaking migration against leaving portfolio to naturally run down on existing CnR system(s)
• Strategic business goals and project objectives
• Budgetary and time constraints
In most cases, the aspects noted above drive the migration solution down an automated path and very often a tailored ‘single use only’ Extract, Transform and Load (ETL) process. This tends to follow a ‘traditional’ IT development – requirements, design, build and test. In other words, data to be extracted and the relevant transformation rules needing to be applied have to be identified. The code is then developed and thoroughly tested (including dress rehearsals). The Pervasive tool which comes with DM9 can be utilised as part of this overarching migration solution.
Three further points of note to bear in mind:
Firstly, where EUC C&R solutions are involved, one of the most significant challenges can be data quality. A considerable amount of effort may need to be expended in identifying relevant scenarios, rectifying the data and putting in place processes to ensure the data stays in the right format/arrangement up until the migration date.
Second is State to State mapping – the need to place or position the Customer or Account at the same (or equivalent) point within DM9 strategies as it had been on the existing C&R system(s). The complexity of this step may vary depending on whether a like for like approach has been taken with regards to the strategies or whether a ‘blank sheet of paper’ approach to re-express business strategies has been adopted instead. Note that the state to state mapping should always have a ‘catch all’ end point step. This does require the final DM9 solution to be reasonably stable in order to successfully undertake this step, so some thought is required around timings and project plans.
Finally, but by no means least, is reconciliation. This is extremely important though the depth and extent of this can vary depending on the nature of the migration taking place.
Over the last couple of years, we have worked with a major UK bank and a major UK utility company implementing DM9 and needing to travel the migration path. As some of our experiences and pointers outlined above hopefully illustrate, there is much to take into consideration when undertaking a migration to DM9; detailed and thoughtful analysis, planning and execution will reap many rewards.
Michael Haskell, Lead Consultant