Contact us

Our clients tell us that we are open, honest and approachable. Please do not hesitate to contact us, we will respond to all enquiries.

Collections and Recoveries Applications Post Go Live Support – Part 1 Introduction, Drivers and Models 16 JUNE 2016

Collections and Recoveries Applications Post Go Live Support – Part 1 Introduction, Drivers and Models

This will be the first of three parts covering various aspects around post go live support for a Collection and Recoveries Application. This first one will touch upon drivers and models.

Many Collections and Recoveries (CnR) Applications – for example Debt Manager, Tallyman, CACS – have the ability from a configuration perspective for clients to be largely self-sufficient. But often the opportunity to build up and equip with the requisite knowledge and experience an in-house CnR Application support team which is presented by the project implementing the new system is lost; the focus frequently is around simply getting to go live and the immediate aftermath, but not always with regards to life beyond.

At best this lost opportunity can adversely affect the client’s ability to maximise their ROI. At worse it can adversely affect the business itself; one Arum consultant has come across an (admittedly extreme) case in which one client ended up with just a single resource fulfilling the CnR Application support function making configuration changes directly into production, on one particular occasion the day before they went on holiday which promptly resulted in a batch failure which no-one knew how to resolve.

Whilst it is highly desirable to consider CnR Application support right from the very earliest days of the project, it is still possible to address this aspect further down the track; in the example just cited, the client did just that – identifying what was required and then executing accordingly – in this particular case clarifying roles and responsibilities and then bringing in and training up further resources.

Drivers for Support

Most clients will require – and will want to have – the in-house ability to adjust the configuration of their CnR Application which will enable them to:

  • Resolve issues (fix for fails).
    However it needs to be borne in mind that some issues may extend beyond the in-house team’s ability i.e. could be a third party interface or a problem with the CnR Application itself.
  • Undertake enhancements.
    Regulatory changes are an important element here, but also responding to changing business goals and objectives. The client organisation needs to establish what can be regarded as an enhancement that should be a ‘BAU’ responsibility of a CnR Application support team and what should progress through more formal budget/project routes.

Support Model Options

Whilst there are a lot of commonalities, there is no single template for what a CnR Application support model might be, but there are a number of options to consider.
The ideal is for as many aspects as possible to be the responsibility of one multi-discipline team (comprised of both business and IT). This ‘one stop shop’ can mean more robust resolutions and best resource utilisation, but it is rare for this model to be viable due to an organisational divisions between and within business and IT departments and the CnR Application itself may incline to a different approach.

A more common support model is one where most elements of the configuration are the responsibility of an Application support team within the CnR business function (or within a more general business support function), whilst the more technical elements (such as batch and interfaces) reside with IT. Note that if the implementation project has been executed thoroughly, there should be less of a need to change IT components on a regular basis, though this itself can present a future challenge and highlights the importance of documenting not just the ‘what’ but also the ‘why’.

A third option that potentially some smaller clients (for instance, those who might take a pre-configured offering) or those in other parts of the world might have an appetite for a different modus operandi for ongoing change; one arrangement could be with the software provider or with a relevant third party managed service provider / outsourcer for undertaking change when required -a draw down number of days each year for instance.

In two weeks’ time the second part of the series will air a number of points which might need to be taken under consideration when deciding upon a support model, whilst the last one will explore how this can change over time (an often forgotten dimension) and the importance of taking advantage of the project which implements the new CnR Application.

Michael Haskell, Lead Systems Consultant

Request a Callback