Success factors in TMS system selection

When it comes to the system selection and implementation of a new Treasury Management Systems (TMS), corporates face the following challenges: the available resources tend to be limited. Hence, such projects are usually fraught with (i) time constraints, (ii) lean staffing levels and (iii) a pre-set budget.

For this reason, decision maker and project manager do not want to waste these limited resources during the system selection phase. Therefore, it is the aim to focus primarily on the “essentials” while de-prioritizing any “non-essentials”. As someone responsible for a project, you may ponder questions such as:

• Have I fully understood all the current and future requirements?
• How many vendors should I consider, and specifically which ones?
• How can I avoid getting lost amid all the requirements on the one hand and the advertised software features on the other, thereby wasting valuable resources?
• For which processes and sub-processes can I do a less detailed analysis (conscious de-prioritization) and as a result save resources? And where, in contrast, are the weaknesses of the competing systems that could prove to be most problematic for our company, in which case a merely cursory analysis during system selection may have long-term negative effects.

This article discusses these conflicting priorities and shows how these can be resolved with the right project approach. The objective is to balance the need for using available resources efficiently with the need to perform a reliable software evaluation that includes all relevant aspects.

In selection projects, the underlying idea is to focus more on end-to-end processes and critical use cases rather than on analyzing individual requirements. Therefore, it is essential to draw up a complete process overview (ideally also with the corresponding sub-processes). Also, a visual or descriptive target image of the final IT infrastructure, taking into consideration the applications linked to the TMS, can be very helpful.

Specifically, this process overview can for example consist of the following higher-level main processes and the corresponding sub-processes (the following items are an example for a mid-tier financial organization with moderate complexity):

• Cash management
  • reconcile cash flows
  • identify currently pending cash transactions
  • prepare a daily cash forecast
  • determine available funds
• Liquidity planning
  • prepare a group-wide financial status outlook
  • draw up a liquidity forecast
• generate an overview of banking and payment transactions
  • manage bank accounts and signatory powers
  • operate cash pools
  • process account statements and payments
• Risk management
  • determine exposure
  • decide on hedging and if necessary, execute a risk-mitigating transaction on the market
  • ensure backoffice and trade control

As mentioned in the beginning, the required time frame, resources and costs play an important role in any software implementation. The key to an efficient system selection is for the project teams to focus on the essentials. Therefore, the core question is:

• Which processes, sub-processes or use cases should be looked at in-depth in the selection phase and which ones can be dealt with on a cursory level?
• So, how can we separate the proverbial wheat (should be focused on) from the chaff (can be handled cursorily)?

To answer this question, we compare the most commonly used providers especially regarding their respective development paths over the last 15-20 years. In doing so, it becomes evident that these established providers have developed largely uniformly in their core functions and are able to name some good, representative reference clients that could be interviewed. Thanks to their many years of experience and ongoing requests for bug fixes and further development from both regular and potential clients, the established TMS providers can ensure that the modules, workflows and reporting capabilities they offer are in line with the typical requirements of an industrial company. This prerequisite (several established systems that have reached a solid level in recent years) allows for a resource-saving selection procedure in which project teams are actually able to analyze especially those items in which the vendor solutions differ from the predefined requirements. And as soon as there are critical use cases in which significant performance differences occur between the vendor solutions under consideration, you have found “the essential” on which the selection project needs to focus on in detail.

The following is the standard sequence for the main activities of a system selection and evaluation in 10 consecutive steps should be mentioned, so that we can pinpoint even more precisely which critical use cases identified above should be evaluated in-depth:

1. Requirement analysis
2. define the target image (professional-operational as well as technological)
3. populate a list with basically adequate vendor solutions (long list and/or short list)
4. tender an RfP with all the necessary documents (T&C, NDA, etc.)
5. Analysis of returned RfPs 
6. define critical use cases
7. ask the respective vendors to demonstrate the system functionality for the critical use cases in a live system 
8. evaluate the vendor solutions under consideration (in terms of quality, quantity and price)
9. Pre-selection and contract negotiations
10. Final decision

In essence, identifying the critical use cases for system selection (mentioned in step 6) is the core task of a selection project. If the preparatory activities (1) requirements analysis and (2) target image definition are thoroughly and thoughtfully carried out, this is a significant plus for identifying the critical use cases. Because at that point, a sound and robust qualitative analysis of the processes and sub-processes as described in the vendors’ s returned RfPs becomes possible. The processes and sub-processes can then be divided into different evaluation categories to assess how the respective software solution performs, for example:

a. process can be mapped in its entirety
b. process can only partially be mapped using a workaround
c. process can only partially be mapped using an add-on
d. process cannot be mapped

This result will then be linked to the process priority assigned in the selection process. Critical use cases are therefore “must haves”, less critical use cases are typically categorized with lower priority (“should have“, “could have“ or even “not relevant“).

The established system solutions for the mid-market (small and medium-sized companies) distinguish themselves by the fact that the system workflows for the treasury core functions are efficiently and effectively (pre-)implemented, thus eliminating the need for basis customizing and time-consuming configuration as part of the software rollout. Up to a certain point, even standard system solutions can be customized. For this reason, such standard software is often employed by mid-market companies, as it already has all the classic functionalities for managing and the processing traditional treasury transactions pre-installed.

In other words, by focusing on end-to-end processes and critical use cases, a TMS selection project can both conserve valuable resources and make a substantiated and transparent system decision at the same time.

Source: KPMG Corporate Treasury News, Edition 125, September 2022
Authors:
Michael Gerhards, Partner, Finance and Treasury Management, Corporate Treasury Advisory, KPMG AG
Cornelius Bonz, Manager, Finance and Treasury Management, Corporate Treasury Advisory, KPMG AG