When you select or implement software, it is unbelievably important to have at least a basic understanding of what is going on behind the scenes. You don’t need a degree in IT from Stanford for this. Systems are based on databases, and databases are more 3D than 2D, like Excel lists are. Just being able to occasionally throw in a few buzzwords isn’t enough. Everyone who knows their way around a bit, notices (and plans for) where you’re heading within a few seconds.
Data is vital
We are confronted with all possible types of data every day in Treasury. They are simply there, we love them, where they come from and how they are generated only plays a minor role. You could of course say “with a smartphone, I also don’t know why I can make calls and access emails on it”, but a TMS is not a smartphone.
A TMS that you select and implement today is a system based on a database and one which is going to be in use over a longer period of time, perhaps for ten years or more. In simple terms, a database consists of tables which communicate with each other. Every new feature and every new function means that the database is going to get bigger. Either through the addition of new tables or new fields in existing tables. The number of tables which are generated over the years can easily go into the thousands. These tables and their headers are often assigned technical names based on a logic that developers decided on back in the mists of time. This is where the first possible conflict can arise: Developers tick differently. Developers regard their creations as their own property that no one except them should understand. Otherwise, the developers are at risk of making themselves redundant, something that they don’t want to do for obvious reasons. On the contrary. I admit, I am exaggerating a little, but there are a few stories I could tell you about this issue. Developers live in their own world that you shouldn’t even try and understand. Developers are interested in code, not in business. That sounds cruel, but it isn’t meant that way. The best software companies are those that manage the tight-rope walk between the code and the user, and back again. But that’s going a little too far. In reality, you’re never going to meet a TMS developer. On the other hand, you would be well advised to at least understand how software is usually developed. And this is where what the user sees at the end of the day often plays only a minor role.
The central issue
But let’s get back to the central issue: data. Have you ever heard of calculated properties or metadata layers? If not, then this is a good opportunity because you’d be amazed what isn’t included in a database table and therefore can’t simply integrated be into the report of your dreams by means of drag & drop. For example, and this really is a very simple example, consider the balance of a bank account in a foreign currency, translated into your home currency on any given date. Do you think that this is going to be in the database somewhere? Really? Well, in most cases it won’t be. You’ll generally have a table with the account transactions, one with the FX translation rates, one with the currency codes, and one with the company names. There is still the question open as to which date the balance should be translated on and which exchange rate is applicable on this date. And now you are certainly asking yourself where the problem lies. The translated balance is certain to be in the system somewhere, isn’t it? Yes, it will be, because the system has been appropriately programmed and this information is displayed on the user interface. But that doesn’t mean that you will automatically see this information in a report.
Imagine your CFO immediately (and I mean immediately, since, let’s face it, they approved a six-digit amount for the new system) wants a report that compares the financial status of your group today with that of the comparable month in the prior year. If you are lucky, the group structure won’t have changed in the last 12 months, although I just mention that in passing, but the exchange rates will certainly have changed. You certainly won’t have the appropriate report at your fingertips and the hotline of the provider is probably going to tell you that they will need to look into it and someone will get back to you in around two weeks. The only option you will have is to manually copy the relevant data from the system and enter these into a spreadsheet.
I could elaborate further on the basis of this simple example, but I think the point is clear. Not everything that you can see in a system can be analyzed in a report at the press of a button. At least, not unless the relevant data are already located in the metadata layer I mentioned; then everything will be OK. That still leaves the questions “How?” and, in particular, “When?” open, but at least the problem is technically solvable. How you going to explain to your CFO that something they can see on the screen can’t be integrated into a report is of course another, and I admit difficult, question to answer. Nonetheless, you still have the option of manually copying the figures from the system into a spreadsheet. Why? Because you don’t want to have to explain why existing data can be compared in the system but that modifying an existing report is going to cost several thousand euros, and possibly support fees on top.
Query these aspects
So, what is the key issue here? In order to be able to assess whether reporting requirements can even be implemented in a system at all, you at least need to be able to carefully query these aspects. Don’t simply assume that what you can see in your system can therefore also be processed in a report with no further effort involved. An optimistic “Yes, we should be able to do that” is not an adequate substitute for a well-prepared and understandable example from the provider based on real data. Your preferred provider is probably not going to be delighted by such a request but, on the other hand, are you interested in buying a system that satisfies you or your provider? And always remember, this needs to be done before you sign the contract, not while the project is already ongoing. It is better to pay in advance to see an example than to pull your hair out later.
Wrapping up, I would like to stand up for the employees of system providers since you might have got the impression that I want to lay into them. That is not my intention. I have also worked for system providers and trained their employees. The best output of these training sessions was the fact that the employees exchanged information with each other. Information which they of course could also have been given, but these people are often on the road for much of the year, spending four to five days a week on site at customers like you. So, if someone says to you that something is not possible, that doesn’t automatically mean this is the case.
The end game
Conclusion: If you have read this far, you might be asking yourself what you can do now or what you can do better next time. That’s basically an easy question to answer. Just ask (more) questions and your most of the way there. And simply apply the methods you know from the area of risk management: How high is the risk that I won’t actually get the outcome I want at the end of the day? And no, you don’t need to understand everything in detail, but you should ask the right questions and be able to evaluate the answers.
Successful TMS launches – part 1: Ready, fire, aim?
Requirements specification = rocket science?
Successful TMS launches - part 2: Taking the reins
The second article in this series looks in more depth at overcoming the challenges of project management and documentation
Without forecasting, you are certain to be “precisely wrong”
Cash flow forecasting – A few random thoughts and why ‘no’ is not an option