A treasury management system (TMS) enables treasurers to improve productivity, visibility and controls across the entire treasury operation. However, in order to deliver promised value, treasury technology must be well implemented.

If a TMS is implemented poorly it not only means an inefficient use of the organization’s resources it also likely means that the system will not provide the desired benefits.

The following best practices can help ensure the project is a complete success.

BEFORE YOU BUY A TMS

Preparation is essential to a successful implementation – and this begins before the system has even been purchased. Completing a thorough business case before buying treasury software documents the value and ROI to be delivered by each system capability, which translates to the priorities the treasury team can build an implementation project around.

Without an effective business case to clearly illustrate the potential value to the organization, implementation project planning tends to focus on processes that are the most manual, overemphasizing the value delivered by productivity alone.

Aligning implementation priorities with organizational value ensures that the right objectives are emphasized at the outset of the project – and provides a benchmark for post-implementation evaluation.

PROJECT PLANNING

Once a system has been selected, a more detailed plan is needed, establishing what is required from the vendor and how the implementation will progress in-house. This should include three different components:

  • Statement of work. A robust scope of work (SOW) should be completed pre-sale and clearly articulate what is to be delivered in terms of modules, features, and capabilities. A SOW should be very detailed so the treasury team has documentation of exactly what they purchased. If it is not in the SOW, it shouldn’t be in the project.
  • Blueprint. While a SOW details what will be delivered, the blueprint – completed as part of the project kick-off following purchase – prescribes how the features and capabilities will be implemented. The blueprint is the most important document and drives the entire implementation. It also gives the opportunity to revalidate existing processes and confirm the treasury team’s detailed requirements.
  • Project plan. The final significant document, the project plan, describes when the project will be implemented, organizing capabilities and tasks into milestones. In addition to assigning functionality to dates, the project plan’s other role is to ensure availability to complete the project. By agreeing upon responsibilities, the TMS vendor and treasury team together can ensure that the project is optimally staffed on both sides.

Top Project Risks

Resourcing – Unexpected delays are often caused by not factoring in unavailability (e.g. vacations and sick days) and the risk of personnel changes. Personnel commitments should be reasonable given that the treasury team all have day jobs.

Blackout periods – Many organizations have IT freezes at year-end, which can impact TMS-to-ERP integration, in addition to blackout periods for banks

Testing – The most underestimated task is testing, especially for system integrations such as transmitting payments to banks. Often banks offer ‘testing windows’, which means that if a test fails the first time, the next opportunity may not be for a week or two.

Dependence on internal teams – A TMS often requires some inter-departmental tasks and treasury needs to take into account that those teams have their own priorities and projects.

IMPLEMENTATION STRATEGY

Choosing the right implementation strategy is critical to project success. At the opposite ends of the spectrum, treasurers can opt for a turnkey implementation – or they can pursue more of a self-implementation with the vendor teaching and giving homework. In practice, most treasurers opt for a hybrid approach falling somewhere between these two options.

When making a decision about the implementation approach, it can be tempting to focus solely on cost. Cost is important, but it should not be the only deciding variable. This again emphasizes the importance of a proper business case which should alleviate some of the cost pressures.

When deciding on the right implementation strategy, the team’s availability to complete their responsibilities and preferred learning styles of the team members are key variables. This knowledge will determine for the TMS provider the right balance of teaching vs. taking on configuration responsibilities is right for the various team members for each functional milestone.

The ultimate objective, of course, is to efficiently set up the system and ensure that a) both power and light users know how to use the TMS and b) capabilities deliver promised value. The path to get there will be different for organizations based on their resources, abilities, and compelling events (such as a system replacement or regulatory deadline).

REPLICATING VS. TRANSFORMING

A key decision point when implementing a TMS is whether to automate/replicate existing processes and workflows or to initiate new ways of doing things. Implementation of new treasury technology is an opportunity to improve treasury processes and design more efficient workflows. In many cases, existing processes were setup because of the technology and its limitations. Often – but not always – new technology eliminates the constraints the treasury team was under and offers better opportunities.

To support this decision making, the treasury team must share not only what they do but why they do it. This enables the vendor’s implementation team to identify where the TMS offers improved workflows, better controls, or more insightful analysis. Change for the sake of change is unnecessary, of course, but missing out on transformation of inefficient processes because “that’s the way we’ve always done it” is a lost opportunity for the team and for the organization.

THE PROJECT TEAM

The vendor will have an implementation team working on the project – but it’s also crucial for the project sponsor (CFO or Treasurer) to formally assign a project team. That project team should include the following roles:

  • Project manager. Coordinates resources and oversees the project plan. The project manager has a direct escalation path to the project sponsor (CFO or treasurer) so that bureaucracy does not impede project success.
  • Power users. If you expect to use a TMS for most of every day, you are a power user. Power users are learning how to use the system and completing the configurations. In some cases, power users will train lighter users of the TMS.
  • System administrators. Admins may be in treasury, within the CIO’s team, or a hybrid of the two. Admins will be empowered to setup the TMS, becoming experts in system controls, audit reporting, and (hopefully not too often) password reset procedures.
  • Subject matter expert (SME). Subject experts may be in treasury, but in many cases will be outside the treasury team. An SME may be a part-time user of the system (e.g. payment initiation within shared services), a consumer of TMS reporting (e.g. in the collections team), or an owner of key data (such as ERP data that is needed for cash forecasting).

Successful project planning means that each of these roles are properly defined with responsibilities and accountabilities well understood and agreed upon. This not only ensures the project team is aligned, but also reinforces the proper escalation path to clear organizational hurdles.

Overall, this collection of best practices will lead to a successful system implementation and a TMS that meets all of your team’s expectations for years to come.