The industry consensus is that the best way to select a treasury management system is by analysing the 'Requests for Proposals' criteria. But is it? Does this lead to the best solution? If you adopt this methodology will you have a TMS that meets your operational needs?
Most articles on the topic of TMS selection are written by consultants offering their take on the ‘Dos’ and ‘Don’ts’ of process. Then you have articles offering the experience of corporate treasurers. These insights can be very useful if you are a corporate treasurer looking to select a successful TMS.
However, as a vendor, we see all ends of the spectrum when it comes to Requests for Information (RFIs) or Requests for Proposals (RFPs). We see RFIs and RFPs and other variations that are concise, relevant and very utilitarian and we see documents that are rambling, ambiguous, contradictory and ineffective in terms of assessing the vendor and the system.
The most common approach in an RFP is to break the process down into segments and to score these. Typical criteria include:
a ) Has appropriate instrument coverage
b) Has relevant functionality
c) Offers seamless integration with other systems
d) Provides proper security and controls
e) Encompasses dynamic, variable and rich reporting capabilities
f) Is cost effective
g) Is future proofed
The above criteria are used to evaluate the system. The consensus is that this is the best way to make a selection. But is it? Does this lead to the best solution? If you adopt this methodology will you have a TMS that meets your operational needs? We believe this methodology has its merits, but it also has its flaws and these are often overlooked. The merits are relatively easy to identify and therefore this selection method has general consensus. However, the flaws are not so obvious and if you overlook them then you do so at the risk of making a bad decision. So, what are the negative aspects of this method?
a) The biggest and most fundamental flaw is that no matter what, if the system you select does not have the capability to meet your requirements, then you can score any submission any way you want, but you will not have a successful outcome to your implementation.
b) RFPs should ideally only contain questions that are relevant to the operation. RFPs regularly have a series of questions relating to financial instruments that clients don’t trade and functionality that clients don’t need. There are two problems with this one, it requires unnecessary evaluation and two, the scoring associated with it invalidates the results.
c) The scoring mechanism itself. Have you ever questioned the scoring mechanism and why certain scores are allocated to certain criteria? After a TMS selection process, both successful and unsuccessful, we are regularly advised that …”you scored well in this section, but less so in another section…” We are never told what the scores are or why we scored as we did. More fundamentally, we never know what the scoring mechanism was. So, scores are allocated, accumulated and totted up and the highest get shortlisted. But beware – this is no guarantee that the shortlist includes the best solutions for your organisation.
d) The primary users of the system, i.e. those In the treasury department should have the biggest influence on selection. Why? Because it is primarily their needs that should be met. However, in many cases we see disproportionate influence into the decision, from IT, purchasing, legal and other departments based on the assumption that all the systems are pretty much the same and the differentiating factors are the non-treasury ones.
e) Vendors are regularly asked to demonstrate the merits of their systems with data provided by the client that is not real data. Often there are mistakes, inconsistencies, omissions and other problems associated with dummy data. A vendor cannot show the qualities of the system when the numbers simply don’t add up and the corollary to that is that the client therefore cannot evaluate it properly. If you want real answers, then pose real questions. Use real data to establish the merits of a system.
f) Many workshops are focused on data input. Data input and its sources are important. Data can be manually inputted or it can be imported through integration with other systems such as trading platforms, ERP systems, rates vendors, banking systems etc. But don’t forget the output. Getting data out of a system is a much more difficult task. The reason for this is that it will be required in an almost infinite variety of layouts, formats, files etc. and rarely are two clients going to want to look at data in the same way. Consider the challenge of putting FX trades, debt, derivatives, exposures, limits etc. all on a single output dashboard. Great flexibility in the reporting capability is required to achieve this and is often taken for granted in presentations and workshops.
g) Another aspect of the output, especially reports, is the ability to automate them. Automation isn’t always triggered by time. Automation can be triggered by an event or a sequence of events each dependent on the previous one. Compound that with the distribution of the output to different personnel based on their role and data requirements. If you want the CFO to have the information he or she wants on a daily basis, in the format required, then make sure the ability to achieve this is evaluated.
There are many aspects to the selection of a successful TMS. The above considerations are by no means exhaustive, but hopefully you found something in them that will help you decide the right system for your requirements. The final arbiter of success is: “Does the system operate as I expected it to?” and “Does it provide me with the information I need in the manner I need it?” If the answer to those questions is yes, then you have made a wise decision.