Do You Really Need to Change Your Current Solution?

I now return to my recent theme of ‘making the most of your treasury technology’, and will explore the particular case of organisations which have mature treasury management system (TMS) installations they are no longer satisfied with.

The causes of such dissatisfaction usually resolve into problems with service quality and with the functional completeness and efficiency of the solution. Neither issue is, necessarily, as simple as it may look initially.

The resolution of open service issues is usually escalated in accordance with the service level agreement (SLA) in the contract; if a number of unresolved issues have accumulated over time, action is indicated. First, it’s important to differentiate between legitimate service issues – bugs, and recurrent technical problems – and enhancement requests. If the vendor’s support team remains unresponsive to the escalation of legitimate issues, it’s time to meet with your relationship manager.

If you don’t know who that individual is, or if you haven’t been contacted by them for some time, say six months, this is evidence of a serious relationship failure. Such failures often happen if you have not been in the market for software or services for some time, which is of course not necessarily a problem for you. But it may have taken you out of your vendor’s focus of interest. Nonetheless, a frank review of the relationship may reveal that the responsibility is by no means one-sided.

One common example of increasing service problems occurs with organisations which have not upgraded their technology installations for several years. This means that their support issues are being dealt with by support consultants who may not be properly familiar with the version of the software they are using. This may require installation by the vendor’s support team before they can review the problem.

A further possible problem issue from running with an outdated software version is that it may not even be formally supported under the contract, and so treasury is exposed to serious levels of operational risk. Upgrading, which will provide a series of bug fixes in addition to more effective support, really can resolve a range of problems. It may be cost effective to avoid upgrading, but it is also, ultimately, a risky form of economy. In passing, we should note that this issue is neatly by-passed by software-as-a-service (SaaS) technology, as SaaS clients have no option to decline upgrades.

The value returned by technology implementations can decline over time for further reasons that are ultimately in the users’ control, and which should emerge at a frank and professional relationship meeting with the vendor. Staff changes in treasury are a common cause of this deterioration, usually because of the inadequate training of new staff. Unstructured, on-the-job training is notoriously inefficient, and experienced staff members often carry much of their practical knowledge of the system away with them when they move on. Additionally, system documentation tends to be infrequently updated, unless this is an automated feature of the technology being used.

The remedy may well be straightforward, in the form of sending staff on formal training courses and encouraging them to assume an appropriate level of ownership of the system solution. The availability, cost and level of your vendor’s training facilities is a valuable yardstick to evaluate their quality.

Perceived functional deficiencies of the current solution should be explicitly confirmed with the vendor. If communications with the vendor have been poor, you might just be unaware that the system you already have can in fact (perhaps with an upgrade) do what you now require. Such occurrences are annoying, but there might just be a low-cost route to fulfilling your business objectives that offers you the best solution alternative, at least in the short term.

A less obvious technology risk relates to using a system based on an archaic programming language or database management system. The risk is not readily apparent, if you are basically happy with the functionality of the system, and if your business requirements are in a steady state. However, it materialises when the need for change is imposed from outside, perhaps by regulatory changes or by a mandate to implement a more robust audit environment. The problem is then manifested by the lack of developers sufficiently skilled in the required technology; the brightest and best technologists do not want to base their careers on yesterday’s tools. So it may be a difficult, expensive and time-consuming exercise to get the necessary changes made.

Arguably, the most significant source of technology dissatisfaction is the failure of the current system to adapt to significantly changed business requirements. These may stem from many different causes, including structural changes resulting from mergers and acquisitions (M&As), accounting and hedge accounting demands, new instrument and strategy requirements, different management reporting imperatives, and many more. Again, it is a necessary first step to see if your current solution can in fact be modified to fulfil the changed requirements. If it can, the remedy may be as radical as a re-implementation, if the coding structure and other configuration settings are simply not compatible with what is needed. Re-implementation may in fact offer the most cost effective and lowest risk way forward, provided that the system in fact has the necessary functional capability.

We now come to the point where you’re running out of options, and patience, with your current solution and vendor. You want a change, and you should perhaps verify this provisional conclusion with a few trusted peers, and maybe also with expert external consultants, before taking the plunge. My next blog will look at some key aspects of what might happen next.



Related reading