Achieving the Full Benefits of a New TMS

So you have purchased a treasury management system (TMS). Now what? Implementing new software successfully, on time, and within budget requires the coordination of four critical areas: resource allocation, project planning, integration, and execution. Implementation is the most important process of the TMS lifecycle. If it is not done correctly, the full benefits of the system will not be reached and users may feel resentful that ‘what they bought’ is not ‘what they got’. It requires a strong, consolidated effort between the vendor and the customer teams.

Resource Allocation Phase

Assigning the proper resources is essential to the success of the programme. The chosen vendor should have high-level knowledge of client requirements from the buying and decision process. As implementations vary in size, depending on the functionality purchased, the type of system (i.e. software-as-a-service (SaaS) or installed), and the scope of requirements; the core customer team should consist of a project manager, the decision maker, the subject matter experts for the existing functionality that is being replaced, and additional resources, such as IT, for back office interfaces.

The vendor will assign a primary relationship manager (project manager), along with a secondary resource. Back up contacts/project leads should be established on both sides to ensure that processes continue to move forward in the event of an absence. Additional resources will be assigned by the vendor as needed to import static data, help the client understand the system’s functionality, and to assist in the fine-tuning of specific modules. The implementation requires strong communication and a cohesive relationship between the client and the vendor project managers, who serve as the primary contacts within their respective organisations. They are the main drivers ensuring that the project is moving forward, meeting project milestones and achieving the desired results that had been established by management.

Pre-implementation and Project Planning Phase

Once the internal implementation teams are assigned, planning must begin immediately. A pre-implementation package will be sent to the customer for review. It will contain a high-level project plan and templates for entering static data (e.g. the customer’s bank and account information, general ledger chart of accounts). The next step is to conduct an implementation kick-off and planning meeting that includes all involved parties. It should address, answer, and document the following guidelines for the project:

  • Who are the participants and what are their responsibilities?
  • What are the strategic objectives and goals?
  • What procedures and policies will be followed?
  • Which modules, functions, and options will be included in the project?
  • In what order will the modules implemented?
  • How many environments (e.g. development, test, production) does the customer require to test the system?
  • When does the customer need to/want to be in production?

The answers to these questions are essential to the project plan and set the stage for the next step – the requirements survey. The vendor should spend two to three days at the client’s location, meeting with each interested group (e.g. treasury, finance, accounts payable (A/P)), answering questions about the software, gaining a detailed understanding of their current process flows, and coming to an agreement about what the TMS will be able to do for them.

Armed with this information, the vendor and customer project managers are now in a position to put together the detailed project plan, which will include administrative, environmental, general system maintenance, specific modules, training, testing, and documentation sections. It will identify resources, duration, and scheduled completion of each task within each section. Typically, the vendor will make the first pass, and then go back and forth with the customer project manager until both teams are comfortable, and the customer has signed off on the plan.

Moving from a manual and Excel-based system to a TMS can present challenges for staff who are accustomed to working with personally-designed templates. Adjustments to the new dynamic environment and data views can pose a learning curve that should be carefully considered when determining training allocations. Training and daily use of the new system should run concurrently so that users, particularly those with no automation experience, ‘learn by doing’ throughout their daily processes.

There is an inbuilt danger at this point though: as the users become comfortable with the system, there is the potential that they will request additional functionality to be added to the scope of the project. This ‘scope creep’ will interfere with the initial timelines determined. It is important that the project managers on both sides communicate consistently to determine, document, and adjust timelines where needed. Weekly status meetings that address progress, issues, questions and answers are essential.

Integration Phase

The integration phase begins with the initial setup of static data, communication with banks, and the gathering of back-office file requirements. Before the TMS starts interfacing with banks, static data, including operator information, bank and fiscal calendars, currencies, bank account structures, accounts, rate types, general ledger (GL) chart of accounts, etc., must be loaded into the customer’s database. Most importantly, user security rights and user access must be finalised before live bank data is pulled into the system. The TMS should provide granular capabilities for security rights. For example, users should have access to specific accounts, transaction types, modules, financial instruments, companies, and hierarchies. Once all the fundamental data is entered, it is time to start connecting front and back office applications.

Bank and back office connectivity are critical elements. Fortunately, a multitude of connectivity options for banks are available in the marketplace today. The TMS vendor should offer a variety of bank polling and payment options including direct file transfer protocol (FTP) pull/push of balance and transaction information, SWIFT connectivity, and/or web-scripting. For those companies with global multinational banking structures, SWIFT may be the faster and more economical methodology to gain visibility into those accounts.

SWIFT offers SWIFTNet and Alliance Lite options, and service bureaus that can be leveraged with your workstation. Automated web-scripting, in lieu of setting up new services with each bank, allows you to use your current bank web-sites as portals to download or upload information, which can be an enormous time and money saver. Services for bank reporting and payment protocols should be discussed with your banks and the TMS vendor as early in the process as possible. File feeds to and from banks must be tested and certified in accordance with each banking service prior to migration to production. It should be noted that this process often causes timelines to be extended. Also, ‘standard’ does not necessarily mean ‘standard’. While the Bank Administrative Institute (BAI) format is fairly standard across banks, other formats, such as Electronic Data Interchange (EDI) or EDIFact, etc, are not and may require additional implementation time.

Establishing interfaces with critical back office applications such as GL is key. The TMS vendor should be able to modify their file feeds to meet your internal requirements, relieving the burden of custom formatting on the client’s end and therefore minimising technical resource allocation. Besides interfacing with your back-office, a trend in today’s TMS systems is to connect to a multitude of automated third party systems to obtain information and cash flows to leverage best of breed technologies to achieve a customised suite of functionality for each client’s unique business requirements, such as trading, rate platforms (foreign exchange (FX) rates as well as interest rates), risk management systems, and money market portals.

Testing and Execution Phase

Before any TMS functionality is brought into a live environment, it must be successfully tested, the results reviewed, and a parallel or concurrent cycle executed to be compared against current production processes. Testing for system results will include regression analysis of each module, each function, and live feeds into and out of the system. Before a TMS is officially designated as a ‘live’ environment, it is recommended that one full accounting period, inclusive of month-end processing, be concluded in a parallel environment.

During the ‘parallel’ phase, manual or current treasury processes are compared with TMS processes to ensure that the new TMS configuration is performing and achieving the desired results. Modifications can be made throughout this period if inconsistencies are found. New automated processes and procedures should be documented during the parallel phase. Once all adjustments are made, the documentation is completed, and the results compared successfully, the system is ready to go live. In a live environment, the TMS serves as the sole system for treasury functions.

Phasing in functionality by priority is recommended. The first phase of the go-live should include the critical elements or high return on investment (ROI) items for the customer. This varies across treasury departments. Other ‘nice-to-have’ features can be implemented in later phases of the project. For example, basic and critical reports should be configured and setup prior to go-live. Customised and new reports can be created as users become more experienced and familiar with leveraging the new functionality.

Current Trends in Treasury Technology Implementations

It is no surprise that in today’s marketplace, the SaaS solution is the preferred technology, as it offers a lower-cost environment, little to no draw on internal IT resources, and active monitoring on behalf of the vendor. In the SaaS world, the vendor is responsible for housing and maintaining all data and the system can be accessed any time, anywhere by the end user over the Internet. The vendor will manage the data, hardware, performance, security, disaster recovery, and, in many cases, actively monitor all inputs and outputs to the system as part of the service. This greatly eliminates the burden of managing technology on the client side. Internal IT resources are only required to help establish the initial connections and feeds to and from client in-house systems during the integration phase. There is no internal IT resource requirement once production has begun.

This, in turn, creates a faster timeline for meeting the implementation goals of most treasury departments today: Lower investment – but faster results. Traditionally in the TMS market, installed software had been deemed as more ‘customisable’ to each environment. This is no longer the case. Your TMS should be just as flexible whether it is a SaaS or an on-site decision.

The remaining 10%, on-site installations, is still in demand by customers who require their data to be maintained in-house, such as government agencies, or companies that have large IT infrastructures to support the project, or because of company policy. Due to the increased involvement of internal IT for hardware configuration, connectivity, environment preparation, and maintenance, these implementations tend to take longer.

Key Success Factors

Implementing a TMS certainly involves a time commitment; however, the end results will improve treasury processes throughout the organisation. Key success factors include strong communication between vendor, client, and banks, commitment to the project plan, actively monitoring milestone progress, documenting, and thoroughly testing each element of the implementation lifecycle. The value achieved through this implementation methodology will bring greater visibility into cash, streamlined processes, and improved audit controls.


Related reading