Niklas Bergentoft: I see two key take-aways from this survey. First, more treasurers today are able to get sufficient budgets to execute projects in the right way. They're approaching these projects as transformations, and they're spending a sufficient amount of money to get them done right. That's happening more frequently than just a few years ago.

And second, they tend to select systems based on the best fit. They're looking at what technology would support their business and processes in the best way; that's much more important than the cost around it. Most companies have one or two main treasury technology platforms—either a treasury module of an ERP or a treasury management system—but there's still a need for specialized software to support peripheral processes such as exposure gathering, integrated forecasting, trade execution, and bank connectivity.

T&R: If companies are now viewing treasury system implementations as transformation projects, are they taking a different approach to decisions around which treasury solutions they are going to deploy?

Kesavan Thuppil: Yes, definitely. One thing I've been observing, this year in particular, is that our clients are doing a lot of benchmarking, and they're connecting with a lot of their peers in the industry, trying to get other corporate treasurers' opinions and perspectives to find out what's working, what's not working, and what challenges they should anticipate. They're going the extra mile in their decision-making process.

Another trend is that companies have become a lot more open-minded in terms of which products they choose. A couple of years back, if a company was an SAP customer, they would start from a default position of exploring the SAP Treasury module to see if it would work. The attitude was 'Why not SAP?' But this year and last year, quite a few companies I've worked with want to make sure they're being comprehensive in their decisions. They will definitely consider SAP Treasury, but they also want to explore the other applications that are out there.

T&R: What's driving this change?

NB: I think it has to do with the fact that treasurers have been gaining a stronger position within their organizations over the past few years. When the approach was 'Why not SAP?' we tended to see the IT function driving the decision-making process, and treasury would have to go through that exercise first. As the treasurer's role has been elevated, the treasury function has become better able to drive the decision-making process based on their needs. And they have the strength to say, 'We're going to pick what's the best fit for our needs, whether it's the treasury module of our ERP system or another treasury management system.'

KT: That's a very good point. From IT's perspective, system rationalization is a significant objective, so when any group in the organization is choosing a software package that could be handled by a module in the ERP system, IT tends to want to leverage that main platform which they're already using and are familiar with. But given the changing responsibilities of the treasury organization, the treasurer is increasingly able to stand up and say, 'This is my portfolio; I should make the call here.'

I was recently dealing with a large consumer products company, which is using SAP as its global ERP. They purchased licenses for SAP Treasury and were preparing to implement it when a new treasurer was hired into the organization. He was coming from an altogether different industry where he had been using a treasury management system, and he was not sold on SAP Treasury. When he questioned whether treasury should continue moving forward with the ERP module, the first response from IT was that the decision had already been made. But the treasurer said, 'No, I am the treasurer. I call the shots now.' So the company re-evaluated its options to make sure it was selecting the technology that would be the best fit for the treasury organization under the new treasurer's leadership. In the end, SAP was able to meet the business case and was implemented after all.

T&R: One data point from your survey that I found interesting, if not alarming, was that 40 percent of respondents said one of their key challenges is an inadequate treasury system infrastructure. Similarly, 40 percent also said that visibility into global operations, cash, and financial risks is a key challenge. Why are so many treasury teams relying on problematic technologies?

KT: The main reason is that any system that was implemented eight or 10 years ago is unlikely to meet the company's needs today as well as it did back then. That isn't necessarily a result of poor design or poor implementation. Most businesses have undergone major changes over time, including mergers, acquisitions, and expansion. They may be operating in different geographic regions and different currencies. All of these changes can lead to complexities in consolidation and may also change the needs of the treasury team, as well as their expectations around the technology that supports them. As such, what was implemented 10 years back is just not compatible to the treasury business as it exists today. So companies are forced to reconsider their options in the marketplace.

NB: Treasury has changed, and systems have evolved too. So if you haven't kept your system up with the evolution, it's going to be suboptimal today. It is also true that the purpose of treasury technology has changed at many companies. In the past, these projects were more about automating, whereas now they're more about transforming and optimizing the treasury function. A lot of organizations, especially organizations between $2 billion and $20 billion in annual revenue, are currently out there looking to replace a treasury systems infrastructure that they implemented five or more years ago. And they didn't take the same approach during the implementation back then—the transformative view which requires really tailoring the system to your processes and your processes to the system for the best possible set.

T&R: In your survey, 64 percent of respondents said their company's treasury management system connects to more than one ERP system. That seems like a good example of a suboptimal infrastructure.

NB: Yes, it's a challenge. Most large organizations run on more than one instance of their ERP. One company I've seen used 52 ERP systems. I think that's the worst I've seen. That impacts treasury in terms of exposure gathering, balance sheet forecasts, cash flow forecasts, and bank connectivity. To solve for this challenge, companies are implementing a standard middleware solution that extracts data from the ERPs, transforms the data and imports it into other systems using one standard. It's hard for treasury to effect change around this, but the treasurer can partner with controllership and IT to sponsor an ERP centralization effort.

KT: Yes, this is primarily a problem in very large global corporations. Some have gone through a consolidation effort to reduce the number of ERP systems, but other companies are very decentralized in their global operations and treasury has to integrate with many different ERP instances. And when treasury has to source the data for exposures, for cash forecasting, and for their accounting from different ERP instances, it's very challenging to get data that is consistent and reliable. It's easy to establish interfaces or establish a process wherein people send you data on a monthly basis. But that doesn't mean the data quality is such that you should be relying on this data for decision-making purposes.

T&R: Is this usually a problem for companies that have engaged in a lot of M&A transactions?

NB: To a large extent. An acquisitive company that faces pressure to integrate acquired entities in a short time frame sometimes has to move forward without transitioning the acquired company to the corporate ERP. It's also intentional strategy in some companies. They may want regional instances of the ERP system, or different instances for other particular purposes. For companies with a smaller ERP system, it may just be that the technology isn't scalable enough to support the whole company on one instance.

T&R: Are there any other reasons you see that would explain why such a large percentage [40 percent] of treasury functions believe their treasury systems are inadequate?

NB: I think the most important reason is that treasury and IT departments alike tend to overlook support for the infrastructure they have implemented. These systems will deteriorate pretty quickly if you don't support them right. The treasury management system requires regular updates to evolve with changes in business needs. These systems also have interfaces to other financial applications, such as the ERP system, as well as to peripheral systems like the trading portal and investment portal. Maintenance of this infrastructure requires dedicated support.

Many companies fail to dedicate people in treasury and IT to monitor business-as-usual activity and to support system and infrastructure maintenance. They may not have people in either function who are knowledgeable enough to understand the full picture and know how to keep the infrastructure performing optimally. So over time, these systems stop functioning as well as they did in the beginning.

T&R: What's the solution?

NB: Most of the problems tie back to either not having dedicated people or not having enough training for the people who are there. And that's really a direct effect of not identifying who's going to support the systems early enough in the implementation project. Because the bigger the system, the longer it takes to learn. Some companies tend to create roles that are focused only on system support, and those roles may not attract their top talent. That can translate into a suboptimal skill set supporting these systems.

I would suggest companies should be creative about how they're defining the system-support roles. They can create a position where system support is one piece of the job, but the job also offers career development opportunities to attract the right people. A solution may be to create a group that's responsible for supporting and evolving your treasury management systems, but you combine that with strategic initiatives—looking at what's the next improvement treasury should undertake. System support needs are going to ebb and flow, and during downtime from system support, these individuals could be looking at continuous business improvement for treasury, driving the treasury function toward leading practices from a process and technology perspective. That would make system support a more interesting role and attract people interested in driving change to the organization. If you also included this position in a job-rotation program within treasury, then you would position it as an important element in your overall talent management strategy.

T&R: Your survey also revealed that a significant proportion of respondents use homegrown systems in each of the functionality areas you asked about: cash management and treasury accounting, bank administration and relationship management, investments and debt management, FX and interest rate risk management, and commodity price risk management. (See Figure 1 on page 4.) Does this gibe with what you see among your clients? Are a lot of companies operating on systems built in-house?

KT: Yes, but understand that what people tend to call 'homegrown systems,' for the most part, are Excel-on-steroids types of applications. Typically a homegrown treasury system started as an Excel spreadsheet, then down the road it was connected to a database, and maybe they've set up some basic automated queries to import data and run reports in Excel. I see a lot of systems like this. And many of them were developed 20 years ago, when the type of treasury management systems we have today were just not available.

In a lot of cases, the systems are still working reasonably well, but the maintenance of a homegrown system tends to be very intense. These systems also create a lot of dependency on internal experts who can maintain them.

T&R: You would say that maintenance requirements are usually higher for a homegrown system than for packaged software, in terms of keeping it functioning properly and connected properly?

NB: Yes, that tends to be true. And, as Kesavan pointed out, you have 'key man' risk. I have one client right now that is working on a divestiture, and they need to replicate their homegrown treasury system for the divested company. Both the parent and the divested company have staff who know how to use the system day to day, but nobody knows how it works on the back end. The person who developed the system has retired, so they're stuck.

T&R: So, when you work with a client that is shopping for a new treasury management solution, what does the selection process look like?

KT: It depends to a large degree on the maturity level of the treasury department, the type of operating model they have, the size of their team, and the volume of activity they have around all the different treasury functionalities. Cash management is obviously the backbone. They need to know at any point in time whether they have enough liquidity to pay their vendors, and whether they have excess cash to invest out in the marketplace.

Beyond cash management, companies are often looking to have their treasury infrastructure automate areas such as bank relationship management; investment and debt management; and FX, interest rate, and commodity risk management. Because cash management is unavoidable, they start with that but then often stretch their system requirements to include other treasury functions.

T&R: What would you advise companies to make their key considerations be in selection and implementation of treasury systems?

NB: First, they need to make sure their vision for the project is really clear at the outset. And by 'vision,' I mean: What are treasury's objectives, and how do those serve the organization? This vision needs to be aligned with the finance leadership, starting with the CFO.

When you've nailed down treasury's objectives, you can start looking at how you will achieve those objectives in your organization. What will your operating model look like when the project is finished; how do you want the treasury function to evolve from both a process and a technology support perspective? And what skill sets will you need, in your staff or in external expertise, to meet those objectives? Then make sure you spend a sufficient amount of time evaluating the technology. You don't have to run a slow selection process, but you need to spend enough time to validate the capabilities you're looking for.

You also need to take a very structured approach to implementation. Do not take shortcuts as you're going through the system design; the design needs to precisely reflect your requirements. Do not take shortcuts, either, in testing and in validating that the solution will work well and will meet your needs. And it's important to be open to tweaking your processes so that they best fit the system you select. This is not about compromising on how you want to run your business, but it's about making sure the treasury function works very well without having to do much customizing of the selected technology. If you use the systems in a way they were not intended to be used, they're not going to work well for you.

Finally, as I mentioned earlier, make sure that everyone who's going to use the system is adequately trained, not only on the technology, but also on your new processes and on their new roles, if applicable. Likewise, provide adequate training for the support organization. Sometimes evolving the support team requires hard decisions, but don't shy away from making sure the right people are in place to ensure that the system continues functioning properly well into the future.

KT: Over the past few years, I've had around a dozen clients that have taken this journey. And I'd say 80 percent of them underestimated the effort they needed to put into evolving skill sets, both in terms of support of the technology and in terms of how the treasury function would operate after implementation. Investing in training and hiring is critical for a company to operate efficiently and to achieve its objectives in a treasury transformation project.