Download to read offline
![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 Group’s 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
28
EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101”
2nd edition](https://image.slidesharecdn.com/equipmentfinanceprojectsguide101-201009043705/75/Equipment-finance-projects-guide-101-28-2048.jpg)
More Related Content
Similar to Equipment finance projects guide "101"
![Validating conversions[5]](https://cdn.slidesharecdn.com/ss_thumbnails/validatingconversions5-200915065857-thumbnail.jpg?width=640&height=640&fit=bounds)
Equipment finance projects guide "101"
- 1. System evaluation, selection,initiation and implementation for the equipment finance and leasing industry Richmond Group richmondgrp.com Equipment finance systems project guide “101” 2nd edition
- 2. richmondgrp.com SECTION CONTENTS Systems evaluationand selection 3 Project initiation 10 Data migration and cutover 16 Testing 22 Business change and Target Operating Model 28 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition 2
- 3. SYSTEMS EVALUATION ANDSELECTION richmondgrp.com How do you know when it is time to change or upgrade your current systems? When you do upgrade, how should you go about it? What are the success factors of a robust system selection process? How should we close gaps? In this section, we look at 10 reasons to upgrade, give some pointers on how to select a new system and share our experience of what success looks like. 3 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 4. 10 REASONS TOUPGRADE YOUR SYSTEM richmondgrp.com Yes / No10 REASONS Outdated technology Your technology and software systems have not kept pace with current Fintech capabilities or with your technology strategy ❑ Inflexibility Your systems do not offer the flexibility to accommodate new financial products, markets or sales channels. If you do want change you need to ask your software vendor for code changes instead of being able to configure straightforward changes with in-house staff ❑ Poor customer experience Partners (customers, dealers, brokers, manufacturers) are not being provided with the seamless experience they have come to expect: a great online journey, flexible agreements and products, and speed ❑ Servitisation Your current system is an end-to-end ERP with components and modules better performed by specialist software and you want to move to a servitisation landscape ❑ Compliance standards Your current platform is failing the security, reliability or regulatory compliance standards that you need ❑ Cannot scale Your systems cannot scale to meet your business growth plans ❑ Too many manual processes Current processes and workflows are too manual, and this is preventing you moving the dials on your productivity and headcount ratios ❑ Lack of analytics Your systems are not providing sufficient, relevant data analytics and service-level metrics ❑ Need better integration capabilities Your systems are not integrated sufficiently enough to provide frictionless processing ❑ Baked-in custom coding Current systems have been heavily customised, making upgrades expensive projects in their own right &/or systems costs are escalating ❑10 1 2 3 4 5 6 7 8 9 4 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 5. THE RFP ("REQUESTFOR PROPOSAL ") PROCESS The request for proposal (RFP) process is there to provide the best chance of selecting a software system that will be a good fit for your business by: • Allowing suppliers to understand the business requirements and propose a solution Lessons learned • Be clear about what success looks like & do not treat the new system as a cure for all ex- isting business challenges • Resist the temptation for requirements to replicate the legacy system • Accept that requirements may be met in a different way than with the existing provider • Hold detailed demos at the supplier premises to learn more than just how their product works • Ensure suppliers demonstrate the same version and environment you are expecting to use • If possible give suppliers real world scenarios so that they can demonstrate proof of concept • Initial RFIs can be sent to a list of identified suppliers, both established and challengers. Detailed RFPs should be kept to a manageable number (3 is often realistic) • Be clear about where the gaps are and how you will meet them • Assess the relative costs of total ownership over the expected system life, not just the headline costs richmondgrp.com € Capture requirements Plan the work Mobilise teams Hold facilitated workshops for each functional area Document requirements and decide scoring & weighting schemes Prepare RFI, RFP docu- ments Obtain document sign offs Send Requests for Information (RFIs) Research suppliers Send RFIs to selected suppliers Collate replies, update RFP + 1st round supplier elimination Send Requests for Proposals & evaluate suppliers Send RFPs to shortlisted suppliers Collate replies, record scores Supplier demos to validate RFP responses + update scores Reference site visits Hold Gap closing sessions Final costs w/customisations + Assess Total Cost of Owner- ship of system over its life Contract negotiations and supplier selected 5 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 6. Lessons learned • Agreewhat success looks like Take the time to decide what success looks like and let everyone know. Being clear about the benefits you expect versus the costs you will need to incur helps keep everyone (staff, software companies and project teams) focussed on why the change is being made and what you are looking for from your replacement systems • Facilitated collaborative workshops led by a neutral facilitator improves the quality of the RFP • Stakeholder support is key • Stakeholders to own the requirements. Avoid having project team members write requirements on behalf of the project, as well as construct the RFP, and score the suppliers • Clear requirements. Be clear in articulating your needs or risk suppliers inadvertently interpreting needs that validates the use of their product • There is no panacea. Avoid expecting the new system to be a cure for all existing business challenges richmondgrp.com RFP SUCCESS FACTORS - A CLOSER LOOK Supplier partnership Clear RFP structure and Support of stakeholders and management Good quality business requirements • Look to create a partnership with the software vendor • Create a mutual vested interest in success • Value the supplier as a resource with experience of the industry and the knowledge of what their software can do • Ensure the RFP is clear and complete • Ensure sponsorship and management support for: • Budget and schedule approvals • Finalising contracts • Resolving disputes and ensuring momentum • Clear & completely defined needs • Consider facilitated workshops led by a neutral facilitator • Stakeholders to own the requirements • Consider using collaborative requirements gathering Goals To provide requirements that are complete, clear, and achievable ... so that software suppliers have understood your needs ... so that they can then validate that the desired solution and technology is available ... which will give the best chance of commencing a project that realises the desired benefits within the expected budget and timescale 6 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 7. richmondgrp.com ANATOMY OF ANRFP EXAMPLE RFP CONTENTS ❑ Project overview and administrative information • Problem statement/business case/issues/ opportunities • RFP timeline & process ❑ Business requirements • Functional “what” type questions (Single needs statements (not long descriptions containing multiple needs) ❑ Supplier qualifications / references • Structure • Support arrangements • Stability, certifications, validations ❑ Non-functional requirements • Reliability, security, performance • Testing & training • Documentation requirements • Implementation support expectations ❑ Technology requirements ❑ Prices / total cost of ownership • One-off costs • Recurring costs • Total cost of ownership over expected life of system ❑ Contracts and licenses • Timescales • Contractual terms • Deliverables ❑ Appendices • Additional background information • System landscape etc Business requirements are used to frame the RFP questions 7 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 8. richmondgrp.com SUPPLIER RESPONSES ANDSCORING - A CLOSER LOOK Capture requirements + decide ranking, weighting & scoring schemes Agree priorities Rank each requirement according to priority e.g. using a 1 to 3 scale range such as High/Medium/Low, with priority informed by factors such as: ❑ Need (e.g. Essential/Opportunity/Market standard or Essential/Desirable/ Nice to have etc) ❑ Core/Non core (useful if > 1 department or country is involved) Agree weighting scheme - it is usually useful to weight: • Each requirement within its logical category (function and sub -function) Key lesson learned • Decide ranking, weighting and scoring schemes at the outset Agree scoring scheme Rather than a simple Yes/No score it is usually better to use a combined scoring and weighting scheme to reflect closeness of fit and relative importance of each requirement. Scoring should be structured and simple. Two examples: 1 2 • Weight by area e.g. 50% software functionality, 20% technology,10% security etc 3 Agree requirements 4 Percentage of points available for each requirement from exceptional (100%) to unacceptable (0%), with percentages in between Score supplier responses according to schemes agreed in advance ..with a score assigned to each Example 1 Example 2 Scored supplier responses Site visit reports 8 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 9. richmondgrp.com GAP CLOSING SESSIONS- A CLOSER LOOK Lessons learned • Gaps are inevitable between your requirements and the system capabilities that you will see during the RFP process. If gaps are discovered during the implementation phase these can cause delays, increase costs and at worst lead to project abandonment • Validate software availability: software vendor capability ("we can do that") is not the same as available functionality ("we have that") • Processes might need to change Accept that process requirements will be supported differently than in the legacy system. Your Target Operating Model might need to change • Try to avoid code changes Closing gaps by commissioning and testing code enhancements can materially affect timelines, budget and the total cost of ownership. Especially: • Do not underestimate customisation costs. They include not only code enhancements but also unit, functional and regression testing • Beware the risk of creating so many bespoke enhancements that future version upgrades become difficult to manage • Approve all gap closing decisions The project Steering Committee should authorise the gap closing decisions and estimated costs Fit-gap analysis is critical for identifying how well the new system will fit, or not fit, the organisation. The cost of meeting gaps are often the source of cost overruns, and so rewards close attention. ❑ ***Involve the supplier, the stakeholders, and ideally have a neutral facilitator*** ❑ Challenge all gaps: re-challenge the requirement, look for alternative ways of meeting the requirement, avoid customisations ❑ Document clearly the cost and benefit of meeting the gaps and how they will be met ❑ If the number of gaps becomes too great, focus on whether a Minimum Viable Product ("MVP") can be delivered on Day 1 with temporary workarounds until a later code delivery Facilitator Stakeholders and SMEs System supplier Documentation landscape High level requirements document with updated, scored supplier responses High level system configuration requirements High level system customisation requirements Site visit reports Gap closing documents High level process changes / Target Operating Model proposals The gap closing sessions Total costs of ownership assessments Supplier contract 9 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 10. PROJECT INITIATION richmondgrp.com You areabout to start an asset finance systems implementation project What do you need to consider at the start of the project to give yourself the best chance of success? In this section Richmond Group looks at our top 10 tips to get your implementation project off to a solid start 10 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 11. Project initiation -our top 10 tips to get your project off to a solid start richmondgrp.com 10 TIPS Know what success looks like Keep the reasons you are implementing your new system front and centre. Everyone on the project - stakeholders, project teams, software vendor - should know what you are trying to achieve. Know what success will look like. Obtain buy-in from the people involved and impacted ❑ Engage an authoritative Sponsor(s) and supportive Steering Committee Things will not always go to plan. Having strong sponsors and a supportive Steering Committee will help clear roadblocks and see the project through to delivery ❑ Use experienced people with asset finance and leasing domain expertise Implementations rarely fail solely due to lack of software or technical expertise. Engage competent project managers, analysts, leaders and staff with asset finance business experience ❑ Agree how the project will be managed Work methodically. Select an appropriate methodology ❑ Agree the Project Initiation Document (PID) Time doing this will be time well spent. Do not make this a “tick box” exercise ❑ Commit to delivering robust documentation Well documented requirements, if executed properly, are a force multiplier that will aid mutual understanding, and can form the basis for testing, training and user guides. ❑ Clarify the link between business benefits you want and the functionality that will deliver it If this is not clear at the initiation stage, make a commitment to establish this early on during project delivery phase ❑ Avoid gold-plating the requirements Agree the functionalities that represent the Minimum Viable Product (“MVP”) that you can live with. Recognize that: • Delivering MVP early is usually more valuable, less risky and simpler than over-reaching, and then having to accept delays to deliver everything in one big bang. Use the 80:20 rule to move functionality to future iterations/releases. • Priorities can change, agility is expected By the time go-live is imminent, a new initiative might arise that is more valuable than delivering that last 20% ❑ Plan for business change and changes to your Target Operating Model (TOM) Engage the Change Management leaders early and work with stakeholders address the business process changes that will result from the implementation ❑ Partnership and collaboration From the outset value your software suppliers and advisors as partners, ideally with a vested mutual benefit in project success ❑ 1 2 3 4 5 6 7 8 9 10 11 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 12. richmondgrp.com The Project InitiationDocument - a formal baseline for the project Lessons learned • Business case and mandate for change • Project objectives • Project benefits • Financial products in scope • Financial product matrix • Functional scope • Business change management • Data migration • Assumptions • Risks and issues management • Quality assurance • Testing and training • Project change controls and management • Communication plan • Project reporting requirements • Reviews and audit Project management Project plan and budget - high level • Phasing and key tasks • High level timeline • High level milestones • Budget • Steering committee • Project roles • Project approach and methodology Project governance The Project Initiation Document (PID) deserves a lot of attention as it forms the contract, and common understanding, between the project management team and the Steering Committee or Sponsor. It answers these questions: • Why are we undertaking the project? Background, motivation and benefits • What are we delivering? In-scope items, success criteria, ideally using of illustrations and charts to show boundaries of delivery (Minimum Viable Product MVP vs. full scope), and how changes will be handled • Who is responsible? Project structure: Project Manager, Steering Committee, Stakeholders, Supplier etc • How will the project be delivered? Methodology to use (agile, waterfall), communications, how QA / testing will be handled • When will the project be delivered? Milestone plan and main project phases • What are the risks, issues and constraints? The risks identified up front, and how they and future risks will be managed • What is the financial impact? Cost estimates and budget constraints and their review frequency. Cost vs. benefit over life of system TYPICAL PID CONTENTS (SUMMARY) Project description Scope • A well thought out PID provides a project baseline & roadmap to reference throughout the project. • Engage, authoritative stakeholders and a supportive Steering committee to clear roadblocks. • Unforeseen risks can derail projects. Get the risks out in the open at the outset • Decide how to deliver the project. Select a methodology that will work for you • Set up good change controls at the outset • Use the right people for the project and address resource shortfalls early • Plan for cross functional teams comprising software vendor staff + Subject Matter Experts + Project facilitators • There will be competing priorities—e.g. global vs local needs. It can help to focus on what the Minimum Viable Product (MVP) will look like and plan for subsequent phases; also to control the Quality Triangle of: Budget/Total cost of ownership vs. Scope/Quality vs. Time • Plan for the business and Target Operating Model (TOM) change • Plan to co-locate teams if possible 12 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 13. richmondgrp.com Implementation methodology -a closer look Having a structured approach to delivering your new system will significantly improve your chances of project suc- cess. The methodology and framework you use will sometimes be mandated by your organization, but where there is a choice, there are three 3 approaches you could adopt: (1) Waterfall (2) Agile or (3) a hybrid approach. Project Management Body of Knowledge (PMBOK) Prince 2 Issued by the Project Manage- ment Institute, PMBOK guidelines represent generally accepted best practice processes for most pro- jects most of the time. Recognized as a set of standards by both ANSI and the IEEE. PMBOK Comprises 5 main process groups and 10 knowledge areas. Aimed at maintaining organization and control of projects through processes and stages with seven guiding principles: • Continued business justification • Learn from experience • Defined roles and responsibili- ties • Manage by stages • Manage by exception • Focus on products • Tailor to suit the environment Scrum Kanban • Kanban is an agile method- ology but without iterative steps, or fixed length sprints • Teams pull tasks from a prioritized backlog of tasks • Releases are made continu- ously or whenever deploya- ble product is created (2) Agile Agile project management is an iterative development methodology that values human communication and feed- back, adapting to change, and producing working results. There are many Agile frameworks, two popular ones being Scrum and Kanban: • Work is done in time- boxed sprints, of c. 4 weeks, selected from a product backlog of re- quirements • Product is released for deployment to a cadence determined by the sprints • Strong focus on cross- functional teams, with no set team roles • Team members can specialize • Focus is on continuous improvement of process, but does not prescribe the formal meeting rituals of Scrum (1) Waterfall and similar structured methodologies The waterfall methodology has been around since the 1970’s and will be familiar to most. It has utility from software devel- opment through to packaged software implementations as well as areas outside of IT. Other non-agile methodologies have been developed which have defined stages, principles and themes. Two examples are: • Key artefacts: sprint kickoffs, daily stand-ups, sprint reviews, sprint retrospectives • Requirements are decided up-front • No scope for change • “Single project” view • Build then test • Highly structured • Values comprehensive documentation • High stakeholder engage- ment during requirements and acceptance testing • Allows requirements to evolve • Change is expected and em- braced • “Multiple project” iteration approach • Build and test concurrently • Self-organizing • Values delivery over docu- mentation • Almost continuous stakeholder engagement (3) Waterfall vs agile? Waterfall Agile Or can you take the best from both? 13 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 14. richmondgrp.com Implementation methodology -can you use waterfall and agile methods? Implementing packaged software usually involves some development-like elements Talking points: • These example “Design & Build” components lend themselves to Agile delivery approaches, even if the overall project delivery is water- fall • But the need to satisfy any sequential Requirements/Design/Build/ Test project tollgates, mandated by your organization, might need to be negotiated Some Agile techniques to consider Here are some Agile techniques that can be useful in projects, irrespective of your overall methodology Used by both Kanban and Scrum projects USE CASE DOCUMENTATION • Kanban has crossed over to IT pro- jects • Their visual appeal is compelling • A strong motivator to see progress at a glance THE DAILY TEAM STANDUP MEETING USER STORIES KANBAN CHARTS A powerful way to document requirements and de- sign. Executed well these can form the basis of user documentation, test cases, and training material. (SCRUM) BURN DOWN LISTS / CHARTS • Used extensively in Scrum projects, the “Burndown chart” is another way to illustrate team delivery progress • Scrum focus is on delivery, but “work remaining” is also a great metric to measure progress Lessons learned 14 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition • Execute your project methodically • All methodologies stress collaboration. They differ in how to collaborate, in project roles and the timing of stakeholder involvement • Use appropriate software tools to assist - collaboration tools, project management software etc
- 15. A closer lookat Use Cases - a requirements documentation technique richmondgrp.com Use Cases are a means for documenting requirements and design details and are equally suitable for agile and waterfall-based projects. Their use (or an alternative) can be mandated at the project initiation stage. Benefits: • They help to capture the detailed functional requirements of a system, expanding on requirements gathered at the software evaluation stage • They can serve as the basis for the estimating, scheduling, and validating effort. • Use cases can evolve at each iteration from a method of capturing requirements, to development guidelines to the software supplier (or programmers) or , to a test case and finally into user docu- mentation. • Alternative paths can be captured that can improve system robustness. • They are easily understandable by business users, and have proven to be an excellent bridge be- tween technical staff and users. Lessons learned TYPICAL USE CASE CONTENTS (SUMMARY, EXAMPLE) Actors and context Pre-conditions & triggers Business process (scenarios and extensions) User interface details State model Non functional requirements Functional requirements Post-conditions & results Business object model 15 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition • Consider mandating the use of collaborative software to generate and control the generation of Use Cases, especially where multiple teams are working on delivering requirements and design, and changes are being made • Richmond has invested in customising Use Cases for use of asset finance company clients, has a robust set of example template Use Cases, and uses collaborative software to adapt / produce them
- 16. DATA MIGRATION ANDCUTOVER richmondgrp.com You have started your asset finance systems implementation project What are the typical pain points in the road ahead? In the next few sections Richmond 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 16 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 17. DATA MIGRATION ANDCUTOVER - 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 17 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 18. richmondgrp.com Planning and businessinput • 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 • “Load & explode”: unit testing often fails to disclose data errors. The first indication of data issues is often when the first full data load is performed with time-consuming re-design & build needed. 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% • Conduct full data profiling before commencing design & build so that data is well understood. Then initiate data cleansing as soon as possible • 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 Compliance early. Any internal or external auditor involvement should be early, instead of after the fact 18 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 19. richmondgrp.com PREPARATION DRESS REHEARSALS& CUTOVER POST-IMPLEMENTATION Setup, configuration or customisation changes Consider and document whether: • Any posting rules will be amended and whether re-posting or GL mappings will be necessary as a result • Income recognition values will change as a result of the migration, whether these will require accounting adjustments and whether internal &/or external auditors should be engaged to review • New control account reconciliation processes will need to be adopted and how this will be handled at cutover • Any change in process &/or process ownership should be adopted and how to transition this Finance reconciliation clean-up Prior to cutover a concerted effort will be needed to resolve and clear any existing GL to CMS reconciliation items, or consider whether more recent items fall within the scope of cutover handling. Resolving reconciliation items after go-live will be considerably more difficult than doing so beforehand Cutover validation work Finance will need to be able to set up validation routines (reconciliations, processes etc) to quickly validate that the migration and cutover has succeeded. Documentation: clear documented processes will need to be in place to handle the reconciliation, matching and clearance of the items above, and then execute them at cutover. In-flight transactions: efforts will need to be made to minimise the impact of in-flight transactions by either accelerating normal processing times or deferring items for post-implementation processing. Examples are: • Contract activations and terminations • Invoices/billing raised in advance • Banking transactions, such as direct debits, initiated in Confirm “unwinding” of cutover transactions After go-live a number of items will need attention including completing the cutover reconciliations, ensuring that cutover items have unwound correctly, and making any accounts adjustments arising as a result of the migration. Additional support Consider engaging software and project teams to help the business, including Finance, walk-through daily processes and the first month-end close. Introduction The case for involving Finance in implementing a new Contract Management System (“CMS”) should be readily apparent. However CMS finance functionalities such as the following can be different in the legacy and new system and so will have a significant impact on migration, cutover, and post-implementation phases: TEST Tips: The impact on Finance of implementing and migrating data for a new CMS must not be underestimated. Consider seconding Finance staff to the project or bringing onboard specialist equipment finance assistance. • General ledger control account handling: • control accounts for items where the CMS is acting as a sub-ledger (e.g. for arrears) • transit accounts that trap timing differences for in-flight transactions &/or processing error items, • other accounts where the detail resides in the CMS The project time pressures that squeeze Finance teams The migration design & build is dependent upon finalising the new system set up & configuration. Delays in the latter can squeeze the migration part of the project into delivering the migration to reduced timescales. Finance will inevitably be asked to help decide whether the migration has been successful so that the new system can go live. Finance will need to have enough information to make this confirmation and practised that they will have sufficient time can make this assessment using dress rehearsals. Key points for Finance teams Technical balances Agree how these will be validated and how to deal with differences esp. income recognition balances (treatment will usually depend on whether differences are due to a change of accounting basis or not). See the next slide for guidance on this Test GL interfaces Although strictly part of application testing, GL interface testing will provide valuable input as to how Finance will deal with the change from legacy to target processing at cutover. GL information in the CMS Some CMS’s allow for GL balances to be captured inside the CMS itself. If this is to be adopted, consider how to load “opening” (I.e. cutover date) balances into the CMS and test this. Apart from dealing with cutover-related items and any accounts postings arising from the migration, the first month-end after migration is usually when any faults in system set-up, configuration, migration or cutover will begin to surface. Some processes are being run for the first time adding to the pressure to Finance teams These can add to project squeeze on Finance: • Migration design & build needs to be completed so that migration test data can be provided to the application test teams. Delays here can delay the overall project • Initial attempts at full migration tests + failed application tests using migration test data often result in the need for re- build of the migration programs and project delay • Accounts posting rules, date handling, and general ledger interface design • Income recognition bases and handling even if intended to achieve the same result as the legacy system • Period handling and closing • Unapplied cash and suspense accounting 19 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 20. richmondgrp.com 20 Migration dressrehearsals provide the opportunity to test finance reconciliations and validations and also to update the cutover plan with realistic timings. Finance will normally be responsible for validating, at a minimum: • Arrears values • Future rentals and instalments • Technical balances such as the unearned income and expense balances. There will be differences. Reconciling the technical balances Significant finance effort is frequently given to validating the technical income recognition balances (e.g. unearned interest). These are normally calculated balances rather than migrated values. Here are just two examples (there are others) of how these can be validated: 1. The forecast values approach In the months prior to go-live use the fact that future rentals and technical balances are known over a contract’s life to predict the expected migration date balances, ideally for the legacy and for the new system. Some of these contracts might terminate early, and so can be ignored. Reconciliation then becomes an exercise in comparing predicted versus actual values, and this can be automated. Migration dress rehearsals 2. Richmond Group’s LeaseValidator application This achieves the same outcome as (1) by using contract parameters to validate both the legacy and target system values as well as predict the balances at forward dates Contract parameters are used as an input. The application’s rules engine is configured with product rules (legacy and target) and outputs both legacy and target expected values which are then cf. actual values EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 21. richmondgrp.com 21 Lessons learned Conversioncutover 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 decision • Advancing normal processing times to minimise the extent of transactions in transit &/or requiring re-entry to the new system • Staffing for the cutover dates and arranging out-of-hours system and building accesses EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition • 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, • 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
- 22. TESTING richmondgrp.com 22 EQUIPMENT FINANCESYSTEMS PROJECT GUIDE “101” 2nd edition
- 23. TESTING - ourtop 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 23 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 24. richmondgrp.com Types of testingand 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. 24 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 25. richmondgrp.com The need formigration 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 25 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 26. • Involve testersearly 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 soft- ware 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. 26 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 27. BUSINESS CHANGE AND TARGET OPERATINGMODEL richmondgrp.com 27 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 28. BUSINESS CHANGE ANDTARGET 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 Group’s 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 28 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 29. richmondgrp.com Final comments This hasnecessarily been a brief and high level look at some of the pain points that frequently occur when selecting an asset finance system , initiating a project to implement it and some of the pain points in the implementation itself. 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 29 EQUIPMENT FINANCE SYSTEMS PROJECT GUIDE “101” 2nd edition
- 30. Contacts www.richmondgrp.com Richmond Group isa leading business transformation practice dedicated exclusively to the equipment finance and leasing industry since 2000 Equipment finance and leasing expertise Deep understanding of equipment finance International Delivering projects in Europe, the Americas and Asia Practical and pragmatic Experienced, knowledgeable, safe David Pedreno T: +44 7802 446137 E: dpedreno@richmondgrp.com David Harmer T:+41 78 808 01 99 E: dharmer@richmondgrp.com Business transformation Systems implementation Data quality and reporting Richmond Consulting Group Ltd 22a St James Square, London SW1Y 4JH, United Kingdom