Secrets of implementing a successful Treasury Management System

As a corporate treasurer, do you have a TMS?

When did you implement it?

Was it a success?

Were you happy with the outcome?

Are you still happy with your choice?

Will it serve you into the future?

Did it cost you more than you expected and above the original quotation?

After implementation, are you still using spreadsheets for some aspects of your treasury management function?

So many questions and the above are but a few that need to be asked after implementing a TMS. Any provider of a TMS must be judged by these questions and only consider implementation a success when there is a positive response from clients to the above

In the course of implementing TMS’s in multinational billion dollar corporations over three decades, Salmon Software has developed a number of principles, sometimes radical, to ensure successful deployment.

These include three key elements:

1. The system must have the instrument coverage and functionality to meet your requirements.

2. The personnel implementing it must be capable of doing so. That means that on the provider’s side, the client services team must understand treasury in general and your requirements in particular.

3. On your side, the implementation team must know what you want from the TMS.

The above sounds like obvious common sense statements and they are. But common sense is often not so common and is frequently sacrificed at the altar of accepted practice, procedure and conflicting interests.

More often than not you have internal contributors, other department personnel, advisors, consultants and others all offering their own particular take on the process. Some good, some not so good (and some just to justify a fee). While you have to engage all stakeholders, they must be managed properly. This means engaging them through one person internally and limiting their influence in proportion to their interest in the project. Without that, it will only lead to meeting after meeting, review documents, Gantt charts and timelines, process flows, milestones etc. Lots of talk, heat and documents generated, but not much in the way of implementation. Everybody is “talking “and “documenting” and nobody is “doing”.

How do you avoid this common dilemma? Actually, it’s not too difficult and the key is to cut out the middlemen. What I mean by that is that you work to the principle of “knowledge is power”. Knowledge falls into two fundamental areas:

1. Knowledge of the system and

2. Knowledge of the data.

The system provider has the knowledge about the system. The people who are responsible for the data and need the information required from inputting and processing that data, have knowledge of it. The key to a successful implementation is for those two groups, best led by one person, to talk extensively to each other and to bring convergence to those two disciplines.

In all implementations that we engage in, the tendency for everybody is to start at the beginning and work their way to the end and all documentation prepared as part of the implementation, reflects this. We are often presented with already prepared implementation plans, sequencing, expected timelines and deadlines – all the things you want or seem to want, but often without due regard to who is responsible for what and how the dependencies influence the outcome.

For example, a large part of a TMS implementation involves importing data from 3rd party systems such as, banking systems, ERPs, rates providers, trading platforms etc. So control and responsibility for delivery of these items lies outside your Treasury team. Putting timelines on these is useful for the purposes of focusing the minds of those responsible, but more often than not, in our experience, they take much longer than expected. So a bit like bus timetables, they are quite useful for telling you how late the bus is running, but not much good for telling you when it will arrive. However, if you build dependencies around these for other parts of the implementation, then they have an additional knock on effect of delaying those also.

While this article is not a panacea for making these things happen quicker, if you adopt a more radical approach to implementing your TMS, then you can mitigate the impact.  Our more radical approach is not to start at the beginning, rather, start at the end.

We ask new clients the following question: “If you had a TMS installed right now, what information would it provide to make your life easier?” Most Treasurers know the answer to this question and are not only very willing to answer, they display extraordinary clarity. They know the reports they need.  They know the controls they want in place. They know the data and the information they want to pass up the line and across to other departments. They will wax lyrical on the manual processes they want to eliminate. And so on.

As a provider, armed with that information, you can analyse that into a few key elements:

1. What data is required to be recorded to achieve that?

2. How is that data going to get into the system – manually or automated input?

3. Where is that data coming from and who controls it?

4. The answers to (iii) above will tell you the interfaces required.

5. Where do you start recording data from?

• Opening positions on open trades.
• Do you need to include historical data for verification purposes and for record keeping?

6. What validation is required to ensure data purity?

7. How does it need to be recorded to produce the output the way the users want it? That includes factors like:

• Ensuring that static data elements are using correct naming conventions.
• Qualified naming conventions and proper authorisation ensures that static data duplication is avoided.
• What data characteristics are required? Most data have natural characteristics such as dates, currency, counterparties, business entity, bank account etc. But if you want more sophisticated reporting you may need additional data characteristics included such as:
  • Business Unit
  • Geographical Region
  • Product Code
  • Cost Centre
  • Country
  • Fund
  • Portfolio
  • GL Code
  • Specific industry codes such as MSN Number (if you are in the airline business) etc.

The list is long if you examine all business sectors, but if you want data analysed properly and information presented to you in a meaningful way, then you really need to consider these aspects.

This list is not exhaustive. But when you see, know and analyse it, you can view more clearly what the final picture is supposed to be.  It’s akin to having all the pieces of a jigsaw on the table and the picture on the box telling you what it should look like when completed.

By starting at the end, you will establish these requirements and then when you are looking at the 3rd party data deliverables, you will be able to determine the following:

1. Are they able to give you the data with the appropriate codes and

2. If not, then how do you enrich the data at input time with the appropriate codes?

If you don’t do this, then you will wind up with data provided to you that’s incomplete for your purposes and no means to “complete” it in order to meet your output requirements. If the data is not in the system enriched with the appropriate characteristics, then no amount of processing will deliver the output the way you want it.

Remember, Treasury is somewhat unique in data terms because typically, not always, but typically, the data is high in value and low in volume and lends itself particularly well to this type of analysis.

At the end of the day, a more radical approach to implementation will avoid pitfalls down the line.

• Read more under:
• BankingTech
• Data Protection