Choosing a treasury management system (TMS) is often a fraught exercise. Most claim to be market leaders. They all cover all your needs. They all guarantee a pain-free implementation. Then you have to contend with often conflicting priorities from your colleagues in IT and procurement. Our treasury insider explains a few techniques that will go a long way to reduce the risk of expensive failure.

Contact details:

[email protected]

Website:www.acarate.com

Spoilt for choice

In many ways, we are spoilt for choice. Despite active consolidation by private equity funds, there are still several well-established old school TMSs on the market based on 20-year-old client server technology that has evolved over time. Post crisis, a gaggle of newer internet stack and Software-as-a-Service (SaaS) products have gained traction and are going global. Meanwhile, though most treasurers still feel they are a bit behind the cutting edge, the ERP vendors continue to develop their TMS offerings.

Even though they all claim to do everything, most TMSs come from specific histories, and this impacts their current functionality and style. For example, some started out as front office dealing systems, while others started in the back office. Some TMSs reflect the needs of the customer segment for whom they were first developed. Knowing this can help in understanding the system better.

BPR or customise?

Implementing a TMS can at one extreme be an exercise in business process reengineering (BPR) or at the other extreme it can be an exercise in software customisation.

The BPR scenario is that the buyer adapts its processes to the functionality of the TMS. The epitome of this school of thought is the view that SAP reflects process best practice, so it is better to adapt your processes to SAP rather than adapt SAP to your processes (In any case, you need very deep pockets for the latter!).

The customise scenario is that the buyer pays to have the software customised to fit exactly to existing processes. This sounds attractive but initial customisation is always expensive and often disappointing; then you are left with a maintenance nightmare – I know companies who run ten year old versions of their TMS because upgrading the TMS – and the customisations – is just too frightening.

Treasurers moving from Excel spreadsheet and paper treasury to their first TMS will probably benefit from taking the BPR approach. You do not want to replicate inefficient and dangerous manual processes into your new TMS, and you likely have little experience of the automated and straight through processing (STP) world of TMS.

Most treasurers will have something in between. So how do you decide which processes can be reengineered and which are immutable? One rule of thumb is to map the requirements in terms of external processes in your business. The logic here is that, as treasurer, you can easily change internal processes within treasury; but you may struggle to change wider order-to cash (O2C) and procure to pay (P2P) processes across your company. (This does depend of course on the remit of treasury, and whether the TMS is pure treasury or a CFO level decision.)

For this analysis, I would include external financial and market interfaces as being open to reengineering. For example, if the TMS has SWIFT connectivity built in, treasury can choose to go multi-bank without disrupting the rest of the company, likewise for eFX and confirmation platforms and market data feeds. Regulatory constraints may create exceptions – for example, Chinese multinationals will require regulatory compliance and appropriate market practice from their TMS.

Treasurers moving from Excel spreadsheet and paper treasury to their first TMS will probably benefit from taking the BPR approach.

Mapping treasury boundaries

The simplest way to describe immutable processes is to start with the inputs and outputs and then add the actions that have to happen within treasury in minimal terms. Do not forget to include your internal control requirements – if your company likes to have eight eyes reviewing FX exposures before hedging, then a TMS that only handles four eyes will not work for you. An example description:

Notice what is not covered in this description:

• We do not describe processes within treasury because we are willing and able to change them.
• We do not provide samples of the Excel sheets we currently use (because we want to free ourselves from spreadsheet purgatory).
• We do not describe our current insanity of calling banks by phone to ask prices (because we are open to eFX as an escape from operational risk and ‘rip-off’ phone pricing).
• We do not provide samples of the FX confirmations that we currently type up manually in Word and fax to banks (because we are open to the joys of electronic confirmation).

This rigour is especially important when you are migrating from manual/Excel to TMS, because you simply do not know what TMS can do, so it makes much more sense to ask the vendors to show you. Even if you are moving from an existing TMS, you do not know what your new solution might offer so it is best to describe requirements as openly as possible – firstly you will learn more and secondly you will be better able to differentiate between the TMSs.

Demonstrations

Once you have described your immutable processes, select the ones that are the least ordinary and ask you vendors to demonstrate how they will cover your needs in their TMS. Since a live demonstration of an unusual process may be a lot of work for the vendor to set up, select only the processes that are most unusual and critical for you.

The demonstration can really set vendors apart. The worst ones will try to get away with demonstration by PowerPoint, which is not a demonstration at all – it is more like promises which may or may not be fulfilled, and at what cost.

The better ones will demonstrate the functionality you need on their live TMS. This should highlight any gaps and allow you to realistically assess the TMS’ suitability to your organisation.

There will also be differentiation between the live demonstrations. Some may stick to the minimal requested functionality. This has the merit of keeping the demonstration simple. Others may try to share what they observe as best practice. This can be a benefit, especially for treasury organisations moving from Excel to TMS.

Putting it all together

The techniques I have described are not used in isolation. What works well is a two-phase approach. Start with an RFI (request for information) exercise based on requirements lists. Invite the vendors who seem to meet your requirements to give a generic demo which gives you a chance to see the system and ask follow up questions.

On the basis of the RFI results, you will be able to shortlist the vendors who appear to best meet your basic requirements. ‘Scanning’ an extensive part of the TMS market; but to not waste your own, nor the vendors’ time.

With the shortlisted vendors, you share the immutable process descriptions described above and ask them to demonstrate how they can cover your needs with their TMS. You can evaluate whether they cover your needs and also how much added-value their TMS brings to the process for you.

The views and opinions expressed in this article are those of the authors.