Treasury management systems (TMS) have evolved greatly in the past 25 years, but careful planning is still required to maximise their potential.
Corporate cash management hasn’t changed much in the past 25 years or so. There have been lots of new instruments to borrow or invest in, but otherwise the foundation remains the same. The only significant change is that treasury has been taking on more analytical activity such as financial risk management, scenario analysis, etc. as the treasurer has moved from a back to front office position. However, the opposite is true for treasury management systems (TMS). The functionality has grown in response to the need for increased analytical capabilities, the technology has changed with the increased demand for web-based services, and the way the systems are implemented has changed in response to the technology changes and to market pressure to decrease project time and costs. This article will focus on how the technology changes have impacted the implementation project, as well as best practice approaches for corporations facing a treasury automation project.
The Evolution of Treasury Technology
Over the years, there have been tremendous changes in the way we communicate with our banks. In the early days we were using phones, faxes and dumb terminals to retrieve bank reports or transmit wire instructions. Then along came PCs that could use scripting programs such as Xtalk or Smartcom to emulate a dumb terminal. The amount of maintenance required to keep these scripts working was a full time job in some companies. Finally, a more secure communication protocol was developed using the Internet, called file transfer protocol (FTP). This secure, encrypted methodology is now the common automated bank communications protocol in North America while European protocols include Ebics, Editran, FTAM, etc. SWIFTNet is gaining traction as well, with over 700 corporates using it for direct bank communications of statements, payments, and treasury confirmations. Connectivity as a service, whether through SWIFT or a data consolidator, is on the rise.
A similar change occurred with the hardware/software used by TMS. Some of the original TMS vendors licensed their systems for use on a Dec MicroVAX or similar hardware and operating system before PCs became powerful enough to develop a TMS on. Next, corporations wanted to run the TMS on an internal network, so the vendors started providing server-based installations. In the late 1980s and early 1990s, most corporations vowed never to conduct banking business over the internet or consider an application service provider (ASP). Treasury data had to remain in-house and on-premises. That story has changed considerably with many companies now choosing an ASP or software-as-a-service (SaaS) provider instead of an installed solution, sometimes as a matter of corporate policy. At the very least, even with an installed solution many companies are now demanding web-based access for remote users.
A new trend in the TMS space, ‘best of breed’, refers to SaaS providers who are delivering a single product specialising in one area such as cash management, risk, accounting, reconciliation etc. Data is easily shared with the other systems so that treasury can select the best solutions for their needs, rather than buying an all-in-one solution that may be deficient in certain functional aspects.
The Evolution of Treasury Implementations
The impact of all of the technology changes has had a correspondingly large impact on implementation projects. Project size started off relatively small when it was on a single PC and it expanded considerably when it included servers and multiple locations and users. But then with the evolution of the SaaS model, project size retracted.
The longest projects will always be for the installed software solutions because they require multiple phases, including installing the hardware, operating system, database, and finally the software before the actual implementation project can begin. Similarly, a hosted ASP project involves all of the same stages as in an installed solution project, but the hardware, database, and software installations are all performed by the service provider at their designated hosting site, and, therefore, should be completed more efficiently than at the client site. With SaaS delivery, the hardware, database, and software installation phases are eliminated. There are no PC requirements other than an internet connection, which allows the implementation project to begin without delay.
Technology has also helped some of the basic implementation tasks get done more efficiently. With the internet, vendors can have remote access to your system and can do a great deal of the work remotely. Training can be accomplished using online audio/video (AV) tools such as WebEx or Flash video recordings. Most TMS also provide for uploading of static data (banks, accounts, general ledger (GL) codes, etc.) as well as transaction history, which can save significant time in data entry.
Although bank communication protocols have greatly improved over the old manual methods, there hasn’t been much improvement in the amount of time it takes to implement bank communications. If anything, it may have increased over the years. The reason for this is largely based on the increased bank security that has been put into place. In the days of dumb terminals and terminal emulation, scripts were created in a live, production environment on both the client and bank ends. As long as the ID and password were valid you could connect and retrieve your reports. Nowadays, that is not sufficient. Banks require that a test project be created and that all testing be done in a test environment. This means that a strict window of time is in place for testing and extending the testing window can lead to overruns. The other difficulty is with the parsing of the bank reported data from BAI format (in the US) into whatever format is required by the TMS. This is not a new problem but a continual one. Although BAI is supposed to be the US bank standard, there are differences from bank to bank with an extra comma here or a unique code there which can throw off any attempts to parse the data uniformly. SWIFT touts its format as the bank standard as well, but unique differences from bank to bank can also impact parsing. So there is no avoiding the issue of testing and retesting bank communications. It is a necessary evil and must be built into every project plan.
Best Practices for On-time/On-budget Implementations
The more prepared you are before the project begins, the better. Assess your current situation first in terms of your people, processes, technology, information and security. Define your organisation’s needs and wants, which should have dictated which vendor solution you chose, and map out your current and future information needs and process flows. What data is needed? Where is that data? What format is it in? How often and when is it needed? With a clear roadmap of your desired future state you can clearly assess and measure the success of your project. Without that vision your project could fizzle out at an early stage, or ramble on indefinitely, and you risk not fully taking advantage of the value of a TMS.
Keep in mind that one of the main purposes of treasury automation is to reduce transaction processing and give you more time to focus on other activities. Don’t go into the project with the hopes of replicating your job exactly as it is done today. Treasury automation is only part of the solution to building a more efficient treasury - your processes and workflows need to change as well.
Create a project team
Make sure you know what your vendor of choice expects your resource availability to be. If they are expecting your company to put in 20 hours per week, you will need to line up your resources. You don’t have to wait until the vendor agreement is signed before putting your project in motion. You can create your internal project team in advance. Consider how you will continue current business activity levels during the project. Should you use full- or part-time resources? Should you outsource part of the project to consultants? Can the vendor provide any additional resources?
Although some of these resources might overlap, someone needs to be assigned to the following roles:
- Project manager: The client project manager is jointly responsible for successful delivery of the project. This will be the main point of contact for the vendor and should have sufficient authority within the company to influence the team members and get things done. The importance of having a project manager on the client side can’t be emphasised enough. Someone has to make sure your resources are fulfilling the client side tasks on time and on budget just as the vendor is doing. This can also be outsourced to the vendor, but it’s critical that this person is involved in setting realistic targets and dates, ensuring accountability for results, time and budget, and communicating internally and externally with the vendor.
- Business analyst: This resource should have a good understanding of the current treasury processes, know what the goals and objectives are for the project, and will help refine the current business processes to fit the new software solution.
- Technical coordinator: This may be an IT resource that can deliver the required company legacy system interfaces to the TMS, provide specifications for any file exports from the TMS and resolve any technical issues that may arise.
- Project team members: These resources will help set up the TMS with the required parameters, be trained on its use, and then test the company’s new business processes to ensure its business needs are met.
Holding Down Costs
Your vendor can help you determine the best ways to keep costs down. Some of these might include having the vendor provide as much service remotely as possible, e.g. holding training or work sessions over the internet via WebEx or a similar tool. The more resources you provide the less resources needed by the vendor, so that may help as well. If you plan on rationalising your banks and accounts, do it before the automation project begins so that you don’t double the work effort unnecessarily.
Prepare static data
You can also start gathering your static or referential data in advance. Each vendor will have different requirements for the format the data should be in and can provide those details in advance. You will be gathering information such as bank contacts and signatories, accounts, cash flow types, GL codes, portfolio data, etc.
Schedule regular reviews
After the project kicks off with the vendor, schedule weekly project meetings so you can review what’s working, what’s not working, and readjust the resources, tasks, or timeline appropriately. If you are outsourcing project management to the vendor, make sure you have set up a good communications & feedback loop. Don’t wait until each milestone date to find out the status - stay connected and involved. Review the budget frequently so there are no surprises.
Remember the documentation you prepared at the beginning of the project that outlined your current and desired future state? Make sure you measure your improvements along the way so the full impact of the automation project can be shared and valued. Did you achieve the cost/benefit you were expecting? What unexpected costs or benefits were achieved? How did it help fulfill your mission? What risks have been mitigated or avoided?
While the basic tenets of cash management have not changed much over the years, the technology has fast forwarded considerably. These rapid advances have helped to shorten the amount of time implementations are taking, thanks in large part to the internet. But these projects are still a large undertaking and careful planning is essential. A detailed consideration of your current and desired state will help ensure a successful outcome.