The first part in this series of three blogs covered the drivers and models around a debt collections and recoveries (CnR) Application support function. This second part outlines a number of important points to take into consideration when designing the support function.
Composition/size of team
This will depend on the model adopted (see part 1) and how the various responsibilities are divided up between the CnR business and IT functions. It will also depend on the installation client size – not directly in terms of customer/account volumes but on the complexity of the solution, i.e. the variety of products and the range of processes which the CnR Application encompasses.
The CnR Application support team should have personnel with a logical, methodical and rigorous mind set; ability to problem solve; energy; and commitment to quality.
Roles and Responsibilities
Again this will depend on the model, but where there is more than one party involved (commonly CnR business and IT functions), it is crucial to ensure that required activities do not get missed or duplicated.
Ideally there should, within the organisation, be one single point of contact. This is not only to cover interactions with the software provider (e.g. contractual aspects; hotfixes; upgrades) but also to ensure all aspects of the CnR Application ‘world’ are being properly catered for across the organisation – and not just with IT; requirements could come from different departments (e.g. Credit Risk and Operations) and thus require collective and collaborative progression; changes could result in adjustments required to documented processes and procedures which are likely to be the responsibility of another group; further training or some form of communications may be required.
A consistent approach to the configuration can also be hugely advantageous – coding and naming conventions for example. This requires some sort of Design Authority function coupled with a documented source of such instances.
System activities/requirements
If the solution comprises an overnight batch (and this is likely to be the case), there is then a need to ensure the right automated monitoring routines are in place to detect any issues and that the right on-call resource arrangements exist to investigate and progress any such issues. It is likely an IT Helpdesk function will need to be involved for automated routines and have the right processes and procedures for handling issues which arise. The issues themselves may be hardware/software related as much as an issues with the CnR Application (including the configuration). Care needs to be taken with regards to addressing overnight problems; for instance, it might seem simple to simply bypass a particular step in order to complete the batch but this missed step may have important ramifications so the impact of such a decision needs to be properly assessed before execution Ideally scenarios will have been identified and best options established during batch design. Business communication routes will also need to be established where there may be missed SLAs.
It is also worth considering what automated post batch summary level reporting would add value and ensuring this is in place and utilised accordingly.
- Exceptions – Inbound interface
There may well exist the possibility that at various points on the journey from source to the CnR Application, new accounts, financial transactions or updates will not be successful. If the relevant interfaces have been correctly constructed, there should be exception reports to highlight such instances. These need to be investigated, code issues resolved and data rectified. This means that responsibilities between business and IT are likely to be identified and established.
- Exceptions – Outbound interface
The same may apply for interfaces out of the CnR Application.
- Exceptions – Within the CnR Application
There are likely to be exception reports to identify particular anticipated scenarios; again, these need to be methodically reviewed and actioned as required.
Potentially if there is a batch element as part of the solution, there may be a need to track running times on a regular basis to understand patterns and when the batch window/SLAs may start to come under threat.
It may be that personnel supporting the CnR Application should have read only access plus the relevant tools and knowledge in order to query the database (or copies of it) for problem investigation and resolution purposes.
Ensure that key project documentation has been retained and is maintained and updated thereafter. Important examples include Data Mapping; Technical designs. If possible, seek to trap and record ‘why’ things are the way they are – the design especially – not just the ‘what’. In addition, identify whether there is any documentation which does not exist but would be of value and address accordingly.
Documented procedures should be established for promoting configuration from one environment to the next and especially up to production. This is a critical responsibility especially at times of peak activity (such as immediately post go live). It is important for a point of contact to be responsible for controlling what code is promoted, where it is promoted to and ensuring the right code control mechanisms are utilised.
This covers the actual tools/mechanisms to be utilised in moving configuration from one environment to the next. They may differ between non production and production environments. Depending on the automated tools at the client’s disposal, consideration should be given to a horse for courses pragmatic approach; change can be influenced by (a) the nature of the change itself and (b) the business sensitivity of the area the change affects. But ensure this is clearly documented and agreed and that there is clear control and auditability.
Provision and support for appropriate development and testing environments will need to be in place, along with relevant code control and code promotion processes/procedures. Have a clear promotion/testing path from development to production. With regards to testing, have clear agreed risk-based procedures here e.g. unit testing only with business review/sign off of scripts? Unit testing and user testing? Don’t forget regression testing or performance testing where appropriate. Prepare to be pragmatic, especially as the level of comfort increases around understanding and using the CnR Application.
As already noted with regards to code control, it is vital to have a clear agreed, signed off and widely understood governance framework around change, be it a fix for fail or an enhancement. This must be adhered to so that progress is made in a demonstrably controlled manner. This provides assurance for risk and audit functions and helps give wider confidence across the organisation.
The third part, which will be out in two weeks’ time, will explore the impact of changes over time and the importance of taking advantage of the project which implements the new CnR Application in the first place.
Michael Haskell, Lead Consultant