Asset finance systems implementation

You have started your asset finance systems implementation project
What are the typical pain points in the road ahead?
In this third of three articles Richmond Consulting Group looks at three areas that
will need attention if the journey is to be a smooth one:
 Data migration and cutover
 Testing
 Business change
ASSET FINANCE SYSTEMS: PROJECT IMPLEMENTATION "101"
richmondgrp.com
#3 of a series of 3 articles on system selection
and implementation for the asset finance and
leasing industry
Richmond Consulting Group

ASSET FINANCE SYSTEMS: PROJECT IMPLEMENTATION “101”
richmondgrp.com
Introduction
This is the third article of three covering systems selection, initiation and execution for
companies in the asset finance and leasing sector.
Article 1 - Asset Finance Systems Evaluation “101”
In this article, Richmond Consulting Group looked at 10 reasons to upgrade, gave some pointers
on how to select a new system and shared our experience of what success looks like.
Article 2 - Project initiation
In this article, Richmond Consulting Group looked at our top 10 tips to get your project off to a
solid start, took a look at baselining the project with a Project Initiation Document, outlined some
methodologies to adopt, and offered an approach to gathering business requirements.
Article 3 - Asset Finance Systems Execution “101”
In the this article Richmond Consulting Group will be looking at some areas that
are often pain points for projects, offering some tips and advice to make the journey ahead
smoother:
 Migration and cutover
 Testing
 Business change
To view the Article 1 please click here:
https://www.slideshare.net/DavidPedreno/asset-finance-system-evaluation-101-richmond-consulting-group
To view the Article 2 please click here:
https://www.slideshare.net/DavidPedreno/asset-finance-systems-project-initiation-101-199442668
You are here

DATA MIGRATION AND CUTOVER
richmondgrp.com

DATA MIGRATION AND CUTOVER - our top 10 tips
richmondgrp.com
10 TIPS FOR A SUCCESSFUL MIGRATION
Senior level stakeholder support is key
The main application implementation is often seen as the main focus of the project with data
migration treated as a necessary technical task. This would be a mistake - data migration is
never easy so engage senior stakeholder support to remove roadblocks

Do not treat migration as an IT-only responsibility
Engage the business in the migration at the outset, and ideally have them lead this stream of
work. They will have invaluable insights into the data, its quality, the need (or not) to migrate
specific data items, alternative data sources and mapping rules

Engage Finance teams early
Finance teams have an important role in ensuring that the new system remains reconciled to the
general ledger and in validating finance balances, including technical income recognition
balances

Conduct detailed data profiling before attempting to create ETL mappings
Do not rely on meta data descriptions to reflect data content. Similarly, ad hoc queries do not
always uncover full data content. Effort here will be rewarded with higher quality ETL mappings,
earlier data quality cleansing opportunities and avoidance of “Load and explode” syndrome
(where data quality and mapping issues are only uncovered late in the project when the first full
data load is achieved)

Minimize the amount of data to be migrated
It is tempting to migrate “all” data. Business teams will be well placed to assess whether data
items are needed in the new system. Minimising the amount of data to be migrated will save
unnecessary effort and cost

Start data cleansing early
Start early but carefully assess the risks versus benefits of where to cleanse data:
 Manually fix in the legacy system vs
 Automate data cleansing as part of the ETL transformation step vs fixing data in the new
system (the general rule is to avoid this)
Risks include risk of updating a live system vs risks of automating as part of the transformation.

Use a data repository that emulates the target system
This avoids impacting live systems, facilitates testing on a static system, and aids data cleansing
tasks

Mitigate the dependency of the migration system build on completion of the
main system build
Delays in the main system build will likely impact delivery of a final migration build. (1) Maintain
good project disciplines and (2) mitigate where possible by segmenting the data into
manageable parts - e.g. by addressing master data components first (business parties, contracts,
assets, banks etc) and then more dynamic data later

Build a detailed cutover plan and IT run book
These should be started early and be refined during, ideally, a minimum of three conversion
dress rehearsals

Loaded data is not necessarily good data
The main implementation teams will need to test that new system processes will work with
migrated data as well as any manually created test data. Delivery of migration data to the
implementation team should be planned to happen as soon as possible

1
2
3
4
5
6
7
8
9
10

richmondgrp.com
Planning and business input
 There is often limited planning
 IT teams are typically given a brief to move data to the new system, and without guidance
from the business make assumptions about what data is to be moved and its quality
Data profiling and cleansing
 Data migration is often meta data driven NOT content
driven (i.e. the working assumption is that the data
description accurately describes the content and is
consistent across all departments)
 Formal data profiling - analysing data content - is often
omitted until data issues are revealed at the test stage.
Instead ad hoc analysis is often performed in an attempt to
identify data content
 Data in the legacy system may have built up over time and
might not be needed in the new system.
 Data might be needed in the new system that does not
exist in the legacy system, resulting in the need to find
sources for the required data, using mapping rules, or by
the business creating the values
 Data will likely need cleansing and can usually be
automated once the rules are known - e.g. by de-
duplication, correcting invalid names and addresses,
cleaning formats, and standardising addresses
Design
 Migration teams often work with limited knowledge or
documentation of the source system, the new system, or both
 The configuration settings of the new system are performed (or
changed) as the implementation progresses leading to late
migration design updates
Challenges of a typical data migration
Project start
 Data migration is often treated as a mainly technical task with limited business input
 The existence of data quality issues is often not anticipated or the extent is under-estimated
 Teams sometimes have insufficient access to the target system until relatively late in the project
Lessons learned
 Obtain senior stakeholder support for the migration project
 Treat the project as a business project not an IT project - engage business teams who understand the
data, can make decisions. Involve legacy system experts + target system business experts
+ target system technical experts + the data migration team
 Base ETL mapping rules on a thorough understanding of data, not assumptions. This will materially reduce the cost
associated with amending code by up to 75%
 Resource data cleansing so that it can be active throughout the project. Do not leave this task until it is too late
 Data cleansing can happen in the source system, either manually or by some systems means. Automated cleansing
is usually more efficient and will capture new cases once the rules are in place
 Avoid attempts to migrate data to the new system for cleansing, although there are sometimes exceptions to this
 Anticipate data mapping to be iterative and continuous throughout the project. Document the mappings.
 Do not base ETL rules on small data samples using ad hoc queries and do not rely on metadata descriptions. This
will likely result in unplanned data cleansing and/or ETL design re-work late in the project
 Consider the use of a dedicated ETL software instead of a custom ETL build
 Consider implementing a dedicated data repository. This will improve the testing and error discovery efforts with-
out impacting active systems, allow testing and re-testing on a static data set.
 Decide how to de-commission the existing system (e.g. maintain an archive version). Budget for the costs of this
 Involve the Compliance team early. Any internal or external auditor involvement should be early, instead of after
the fact

richmondgrp.com
Data cleansing
Income recognition
Cutover planning
The RCG calc tool for conversions
Migration project test and validation pressures
The pressures that can cause a migration project to exceed its budget and deadlines:
# Item Example mitigation strategies
The need for the migration team to wait until the
new system is configured often results in full
migration testing being squeezed to the end of the
implementation timetable
Segment the data so that, for example, master
data can be validated before dynamic data.
Notwithstanding the risks of relying in unit tests,
attempt walkthroughs of small data sets to prove
migration concept
The new system will require migrated data to be
available to complete application testing (it cannot
be assumed that a loaded record is a good record).
Any delays to providing a valid migration to the
application test teams will risk impacting the overall
timetable
Ensure strong project management discipline,
engage stakeholders with authority to remove
roadblocks, and ensure the migration team
comprises the right mix of business and IT
“Load and explode”: unit testing often fails to
disclose data errors. The first indication that there
are data issues is often when the first full data
migration is performed with failed tests leading to
time-consuming re-design and build work
Conduct full data profiling before commencing the
migration design and build so that data is properly
understood. Then initiate data cleansing as soon as
possible
Ensure business teams have challenged whether
data needs to be migrated at all.
Validation of income recognition balances is often
under-estimated. This activity usually poses the
challenge of dealing with (re-)calculated values
rather than migrated values. Differences will always
arise.
For contract management (“CMS”) migrations, the
task of reconciling the various CMS finance balances
with the General Ledger, pre- and post-conversion,
is often necessarily undertaken in full only after the
main contract balances are successfully migrated.
Any delays to that happening will squeeze the
finance reconciliation activities.
Engage business and finance teams early to
address the income recognition and GL
reconciliation challenges, and to identify, explain
and document line item differences.
Use predictive tools, such as the Richmond
Consulting toolkit, to validate income recognition
balance differences
1
2
3
4

richmondgrp.com
Conversion cutover
In addition to the complexities of migrating data is added the challenges involved in managing the actual cutover
itself.
What is cutover?
 Bringing live a non-production system to a production (live) environment
 Moving data from legacy and other data sources to the new system
 Managing transactions in transit and timing differences (e.g. for bank and billing transactions initiated immediately
prior to the cutover date)
 Technical IT task to facilitate the above - e.g. possible hardware, operating system or database changes, replication
handling, disaster recovery handling amongst others
What is needed to manage cutover?
 A detailed cutover plan and run book covering all the steps and dependencies to achieve cutover, including
planned timings and decision points for moving from one critical stage to the next
 Approval hierarchy up to CEO/COO/CFO level to confirm moving through the cutover stages to a Go/No go live
decision (or rollback to legacy)
 Reconciliation and validation processes that will be used to support a Go/No go deci-
sion
 Advancing normal processing times to minimise the extent of transactions in transit
&/or requiring re-entry to the new system
Lessons learned

 Plan early and involve all parties in the cutover plan - business, IT, software vendors, project teams
and other service provides - right down to who will provide the pizzas
 Undertake full Conversion Dress Rehearsals to establish, and then refine, timings and to confirm that
all steps can be completed in the available time. We normally recommend at least three rehearsals,
minimum
 Refine and automate validation and reconciliations - these need to be comprehensive enough to support a Go/No
go decision yet be achieved within a usually tight timeslot
 Ensure staff and all affected external organisations are aware of the change timetable and will be available for the
cutover dates
Finance validation and reconciliation - a closer look at one area
Significant finance effort is frequently given to validating the technical income recognition balances (e.g. unearned
interest). There will always be differences, even for ostensibly the same calculation bases in the legacy and target
system. There are many approaches to validating the balances; here are just two examples (there are other ap-
proaches too) which meet the “automate reconciliations” advice from the previous section:
In this example a validation tool is used to recalculate the
balances once the detailed calculation rules in the legacy
and new system are understood
In this example a “predicted balance”
approach is used

TESTING
richmondgrp.com

TESTING - our top 10 tips
richmondgrp.com
10 TIPS FOR A SUCCESSFUL MIGRATION
Senior level stakeholder support is key
Ensure stakeholders are involved and informed in the testing phase. Their support will be
needed to remove roadblocks, free business staff to support testing teams as well as undertake
User Acceptance Testing. Finally, stakeholders will need to affirm the critical go-live decisions
based upon test results and workarounds for any non-critical defects at go live

Have a realistic test plan and work methodically
Have a signed off test plan that sets out what is to be tested, by whom and when. Work
methodically using recognised test standards, and use test and defect management tools that
are available to you

Resource test teams carefully
Use testers with credible understanding and experience of the business. This might mean
seconding people from the business &/or using external expertise. External testers will need the
support of the business to work efficiently, so plan for this

Respect the different testing roles, responsibilities and goals
Software vendors are responsible for delivering working software.
System testing exists to ensure the software is fit for the purpose for which you will use it.
User acceptance testing is to validate that the software will be acceptable for acceptance into
the business. It is not an extra opportunity to perform functional testing or bug hunting

Accept that you will go live with defects
There is no such thing as zero risk and there is a cost to delaying a project to address every last
defect. It is the responsibility of the project and stakeholders to balance the cost of delay with
the risk of implementing non-critical workarounds and a defect resolution plan.
Establishing trusted relationship with the software vendor will be important.

Treat testing as an investment not an unavoidable cost
Look to re-use testing artefacts (plans, scripts etc) for use when the new system transitions to
your support teams.
Consider investing in test automation not only to support the implementation but to reduce the
cost and increase the efficiency of future release and upgrade deployments

Plan for the testing pressure points
Plan and look for ways to mitigate the pressure on down stream application processes (a failure
in one process preventing other processes from performing and therefore being tested).
Look for ways of moving migration data into the test systems as early as possible so that
processes can be tested against “real” data, not just manually generated test data

Partner with the software vendor
They will usually have good experience of testing their systems. Leverage their experience. 
Don’t forget to test…..
Do not forget to plan for the other types of testing that will usually be necessary: security and
penetration testing, performance tests, disaster recovery proving, operational readiness testing
and similar.

Involve test teams early
There might be a cost to this but the benefits can be big. Testers can be drafting test cases and
scenarios and hit the ground running when the time to test begins.

1
2
3
4
5
6
7
8
9
10

richmondgrp.com
Types of testing and responsible parties
Testing as an investment
View testing as an investment in your company’s ability to test future releases and upgrades rather than an
unavoidable project-only cost.
To do this, make it a priority to plan and execute the test plan so that opportunities are taken to re-purpose system
tests for later use. Also to be considered: automating tests for use over the life of the system.
Unit testing is performed by the software company developers responsible for delivering working software that has
undergone documented unit testing. Any customisations, interface builds and any system configuration should be
unit tested before delivery. Ensure:
 Acceptance criteria are agreed for taking code releases from the vendor
 The vendor has strong release and code change disciplines
Integration testing is performed to expose any defects in the interfaces and interactions between systems. In
practice this testing will often be performed by test teams and IT staff alongside the software vendor.
System testing tests the whole system, but here we use this term to also encompass functional testing of all parts of
the system as well as regression testing (testing that previously working parts of the system continues to work after
new code is released). System testing should focus on ensuring the software is fit for the purpose it will be used for.
The goal is not to find defects for circumstances that are unlikely to arise in practice
Resourcing the test team is covered below, but is usually one of, or a combination of: internal test teams, co-opted
business users, third-party testers.
User Acceptance Testing, undertaken by business users, is the final stage validation that the software can be
accepted into production once the software has passed the system testing stage. It should not be seen a last minute
attempt by users to find functional defects.
Who should be in the test team?
All industries are special in their own way, but the leasing sector (and the testing of leasing applications) really does
need specialist knowledge and experience in some key areas (for example payment calculations, commission
calculations, income recognition, accounting etc. Testing will make material demands on business users and project
teams to provide this knowledge.
Recognising the need for a testing team with the right mix of leasing domain knowledge and testing experience, an
effective test team will generally be resourced from a combination of:
 Specialist internal company test teams
 Secondment of business users to the project
 Outsourced, third-party testers
… with support from the software vendor.

richmondgrp.com
The need for migration data
Ensure testing is performed using migrated data as well as test data generated for specific Use Cases - refer also to
the data migration section on this.
The software testing lifecycle
The stages Example
Artefacts
Testing requirements
The Use Cases (or business requirements) have been documented, ideally
with test team involvement. Testers can now start analysing the business
requirements to help to identify the scope of the testing. Although this
stage is often omitted, we recommend not doing so.
Planning
Create and sign off a test plan clearly identifying the activities and
resources needed, including any test and defect management software to
be used, the tracking metrics to be used, an assessment of the risks (and
mitigations) and any company testing standards to be followed.
Analysis
Decide “what” is to be tested, with traceability from the requirements.
Test conditions should be clear and follow directly from the Use Cases, if
used (or requirements if not).
Design
Decide “how” to test by covering, inter alia: the test conditions , test data
preparation, test environment, and test metrics.
Implementation
Create the detailed test cases
Identify which test cases will form the regression test suite
Identify candidates test cases for automation
Script the test cases (manual &/or automated)
Test execution
Execute the test cases, log defects, and track their resolution.
Expect and plan for re-executing the test suite as code fixes are deployed
Conclusion
Agree exit criteria and reporting to stakeholders and others
CommentaryExample
Artefacts
Defect management
Key points:
 Use a defect management tool and ensure everyone is trained to use it
 Work with the software vendor to coordinate how the recording and
management of defects will be coordinated with their internal defect
management systems and reporting
 Agree severity and priority definitions
 Different defect fixes will have different timescales and resource implications
for the software vendor. Close cooperation and compromises might be
needed to maintain momentum
 Demand clear, well-written defect report narrative to give the software
vendor the best opportunity to fix the problem, and for other staff to follow
the issue, or create workarounds if necessary

 Involve testers early in the project, ideally at the requirements gathering stage
 Projects where business requirements have been allowed to evolve throughout the implementation
will face the challenge of testing a moving target. The importance of well-documented requirements
at the outset bears re-stating.
 Using specialist test management software will help efficiently manage the recording and execution of tests, the
recording and resolution of test defects, and aid collaboration and communication between testers, users, the
software vendor and other project teams members.
 Keep in mind that data privacy and protection rules will need to be respected with test data. This will often mean
obfuscating data so that client confidential data is not exposed to 3rd parties (software vendors, external testers
etc). Address this issue as part of the test planning process
 Ensure users are trained in the use of the software, and have training documentation developed for this purpose.
This needs to happen before they are asked to undertake user acceptance testing (“UAT”).
richmondgrp.com
The test dependency risk
Be aware of the linked dependencies in testing typical contract management systems and how this squeezes tests of
back end processes where upstream functions are failing. Finance testing is particularly vulnerable here. Recognise
the risk and adapt where possible.
Time to go live - negotiation will be needed
It is likely that you will go live with defects, although not the critical ones.
There is a cost to delaying a project until every last defect is fixed and this cost needs to be measured against the
cost and risk of implementing defect workarounds. Focus on delivering the minimum viable product into production
to realise benefits of the new system as soon as possible.
There might be strong demands to fix everything before going live. Every effort should be made to fix the higher
priority items without jeopardising timescales or the business. Strong realistic stakeholder leadership will be
required at this critical point, informed by a trusted relationship with the software vendor.
Caveat
This has been a necessarily brief introduction to testing for asset finance implementations. For the sake of brevity
much has been excluded, including:
 Security / penetration tests
 Performance, volume/load testing
 Usability testing
 Operational readiness tests
 Disaster recovery testing
 Development of smoke tests
 Migration validation testing, although touched upon in the migration & cutover section
Lessons learned
Whether and when to consider test automation
Automation requires some investment. However it brings agility to testing by allowing changes and re-tests to be
executed repeatedly and faster than a human could achieve. Well designed automation scripts allow for an increase
in scope/coverage of testing that would not be practical with manual testing.
Post go-live support staff will appreciate the ability to deploy releases and upgrades with a reduced need for
organising a large test campaign. It will facilitate a move to a continuous software delivery model with more
frequent code deployments than might otherwise be contemplated.
Bear in mind that it is not necessary to automate all testing. Focus on those items that test functionality that is likely
to be stable, and that can be repeated. Start small and extend the scope of automation as experience increases.
Tests that are only needed a few times should remain as manual tests executed by professional test staff.

BUSINESS CHANGE AND TARGET OPERATING MODEL
richmondgrp.com

BUSINESS CHANGE AND TARGET OPERATING MODEL (“TOM”)
richmondgrp.com
Why the need for business change?
Implementing a new system invariably impacts the business’s processes, people, and organisation, but it provides an
opportunity to re-engineer out inefficiencies, and move to a new Target Operating Model.
Benefits realisation
The need, and opportunities for, business change is often under-appreciated. However, it holds the promise of fully
realising the benefits of a major systems change, such as:
 Better customer and employee experience
 Reduced operating costs
 Re-focus on value-added tasks
A structured approach to managing the business change
The business change needs to happen in parallel with the systems change and should be managed in a structured
way. As an example. Richmond Consulting Groups preferred method is to use templates covering the following:
 Change definition and audience identification
[Change name -> Definition -> Audience impacted -> # of people impacted]
 Impact assessment
[Change name -> Roles impacted -> Process impacted -> Systems impacted -> Perceived effect -> Timing]
 Adoption strategy
[Goals and objectives -> Challenges -> Key messages -> Approach]
 Communication tactics
[Tactics -> Audience -> Goal -> Delivery channel -> Timing -> Responsible party]
 Training tactics
[Initiative -> Audience -> Purpose -> Method-> Timing -> Responsible party]
 Organisational changes
[Change name -> Team impacted -> Purpose -> Activities-> Timing -> Responsible party]
Lessons learned
 Appoint a business change management leader at the outset
 Engage senior stakeholder support for the business change initiatives
 Update the change management control documents/templates and then:
 Liaise and communicate promptly with affected business teams, hold them to account and obtain
sign-off for the changes
Example TOM control
summary

ASSET FINANCE SYSTEMS: PROJECT IMPLEMENTA-
richmondgrp.com
This has necessarily been a brief and high level look at some of the pain
points that frequently occur in asset finance systems implementations.
It is, of course, not meant to be exhaustive - there are many project
topics that we could have covered - and is much summarised to give you
the key points.
We welcome comments and would be happy to help you get your
projects off to a good start, or recover one that is slipping.
A selection of our customers

Richmond Consulting Group is a leading business transformation practice
dedicated to the asset finance and leasing industry
Practical and pragmatic
Experienced,
knowledgeable, safe
Global reach - local execution
Delivering projects in Europe,
America and Asia
Asset Finance expertise
Serving our clients for over
20 years
Business
transformation
System
implementation
Data quality &
reporting
Business
continuity
Contacts
David Pedreno: +44 7802 446137
David Harmer: +41 78 808 01 99
www.richmondgrp.com
Richmond Consulting Group
22a St James Square
London
SW1Y 4JH
United Kingdom

Asset finance systems implementation

More Related Content

What's hot

Similar to Asset finance systems implementation

More from David Pedreno

Recently uploaded

Asset finance systems implementation