Best Practices for Designing Your Treasury Management System

While treasury departments are typically aware of the advantages that a treasury management system (TMS) provides for cash and liquidity management, they are often less clear on what is required to achieve the full benefits.

In this ebook, you will learn the steps needed to design and plan for a TMS, including best practices for how to:

• Define future state processes
• Build a prioritized roadmap
• Design a system.

Download this ebook to learn how you can prepare your team for a successful implementation and achieve the most value from your TMS.

Holistic System Design Methodology

While treasury departments are typically aware of the advantages of using a treasury management system (TMS), they are often less clear on the steps required to achieve the full benefits. It is difficult to get where you’re going if you do not have detailed directions on how to get there, so planning well in advance and establishing measurable objectives better positions organizations to reap rewards when implementing or enhancing a TMS.

Not only will clients minimize additional costs and project delays but most importantly, they will also achieve the full set of benefits sought from a TMS in the first place.

The first step in positioning a TMS project for success is to follow what is referred to as a holistic system design methodology: confirming the scope and objectives of the project, defining the future state processes of your TMS, creating a roadmap and planning the system design.

Confirm the Scope and Objectives of the Project

When defining the scope and objectives of a TMS project, treasury professionals should focus on four specific areas:

• Out of Box API Integration
• Faster time-to-market
• No upfront costs to enable real-time payments
• Improved certainty in cash flows

Obtain Clarity on Current State

It is difficult to clearly define your scope if you do not have a solid understanding of your point of departure. Depending on whether the treasury function is more centralized, decentralized or if certain functions have been outsourced, you may have a better grasp on how all the daily processes function and who is responsible for which activities. Having a strong foundational knowledge and understanding of the current processes is critical when designing any new solution. To help lay this groundwork, detailed process flow diagrams should be created that include all areas being considered for TMS implementation.

The focus should be on:

• How data flows between people and systems
• Roles and responsibilities of various constituent groups throughout the process
• Hand-offs between groups
• Defining whether the process is systematic or manual
• Systems and reports beings utilized
• Key controls needed

In gathering all the elements noted above, you will not only help establish a clear point of departure for the implementation, but will also capture a number of data points that are critical for future steps of the implementation.

Define Scope and Priorities

In order to determine an accurate budget, resource needs and a timeline of a clear scope are required. This includes analyzing all requirements, including those in scope, out of scope or deferred to a future phase of the project. Additionally, throughout implementation, decisions will need to be made regarding where to focus resources and how to sequence tasks. As such, it is extremely beneficial to have clearly defined and prioritized requirements and project scope that have been agreed upon by all constituents. This will assist in providing direction to the project team and help ward off any deviation from the key priorities. The requirements must be at a fairly granular level of detail in order to facilitate these decisions. For example, it is best practice to list out all the reports and determine which functions are a “must have” and what is simply “nice to have” to ensure resources are spent wisely.

Set Measurable Objectives

The best way to determine the project’s success is by measuring it against a set of predefined objectives. These can be categorized by type including improved financial performance, risk mitigation or enhanced operational efficiencies.

Some examples for each category include:

Improved financial performance – Reduce bank fees by 20 percent through validating fees charged and renegotiating agreements based on cross bank fee analyses

Risk mitigation – Centralize 95 percent of payment approval workflow, release and confirmations

Enhanced operational efficiencies – Reduce time required to compile daily liquidity across all accounts by one hour per day

The objectives should be incorporated into the project status reporting to ensure the team does not lose sight of them and to ensure that they are achieved as part of the implementation.

Ensure Leadership Support and Alignment

In a project as significant as a TMS implementation, it is critical to obtain leadership support and ensure alignment and commitment from all key stakeholders. Reach out not only to internal stakeholders but also to external ones including vendors and implementation partners. The project will impact and require involvement across multiple departments, including accounting, accounts payable, FP&A, tax, information technology and treasury. However, prior to engaging these teams you must be prepared to clearly communicate the following:

• Project vision and importance to the company
• Specific benefits achievable by each function
• Anticipated level of effort and resources required
• Timeline and roll-out strategy
• Impact to existing processes and potential changes in roles and responsibilities

There will be a number of project dependencies on these groups, so ensuring they are committed and have allocated sufficient resources to meet the project timelines is vital to its success. Aligning the project team’s incentive compensation structure with achieving the defined objectives is another effective method to ensure commitment across all levels.

Define Future State Processes

As part of a TMS implementation, existing processes, roles and responsibilities should be analyzed with a goal to optimize, as well as take advantage of best practices delivered with the system.

It is worth noting that taking existing processes and lifting and shifting them to a new TMS is often not the best approach. Legacy processes and roles transform over time. As organizations evolve and grow, the circumstances change, but usually the processes do not. The future state should be designed to improve processes to make the organization more efficient, productive and strategic. Therefore, it’s critical to define what that future state will look like. In order to achieve the ideal future state, a defined set of steps should be followed to optimize the design of the system, realize new efficiencies and to fully benefit from the TMS’ capabilities.

Once the scope of the project is defined, the next order of business is to identify the future state processes:

1. Document functional and technical requirements to drive implementation decisions.
2. Draft process flow diagrams of the future state that reflect ownership and hand-offs, and define ideal processes and data workflows.
3. Create a system architecture diagram and identify opportunities to redesign and streamline processes. The architecture might include multiple versions to coincide with roadmap phases.
4. Refine roles and responsibilities to take advantage of treasury’s ideal future state, including defining staffing skill requirements and determining which processes and resources need to be realigned.
5. Analyze the impact of change management on the organization and assess the organization’s ability to absorb this level of change.

Developing a Process Flow Diagram

Creating a future state process flow diagram lets organizations identify opportunities to redesign and streamline processes and determine how functions will be performed in the TMS. This diagram will help treasury define:

• Processes or data flows that are manual versus those that facilitate straight-through processing
• Systems utilized and how data flows between them as well as manual movements
• Interdependencies between groups, data flow and processes
• Cross-functional responsibilities and flow of data between internal and external groups
• Key controls (both systematic and manual) to ensure they are being maintained, if not strengthened

Below is an example of a payment process flow diagram showing task cross-departmental ownership:

Creating a System Architecture Design

In addition to defining the functional process flows, a system architecture diagram should also be created. It will serve as a high-level view of all the integration points coming into and out of the TMS, detail the TMS functionality in scope and identify any third-party dependencies. If the plan is to deploy the functionality in phases, the items can be color-coded to identify which items will be implemented in each phase. When discussing the project with management, key stakeholders or third-party vendors, this illustration is very helpful to convey the desired end state.

The Importance of Documenting Change Management

As part of the future state definition, it is important to identify changes in processes and how they impact individuals’ daily functions, as well as any potential changes in ownership. The proposed changes must be well documented, and include the rational and perceived benefits, and it must be approved by the heads of each department. If at any point the groups cannot reach a consensus, any open items should be escalated to the steering committee or additional members of senior management if applicable. It is important to confirm and communicate the changes to everyone as early as possible to avoid confusion and disruption when the change is enacted.

Build a Prioritized Roadmap

The implementation or enhancement process will likely go through many phases before reaching completion. Therefore, it is critical to create a well-defined roadmap that includes a realistic project plan, outlines budgetary and personnel needs, and measures progress.

To develop the roadmap, treasury will want to:

• Clearly outline objectives and designate tasks and priorities for action in the short-, medium- and long-term.
• Create an impact assessment to weigh the benefits against the cost and time required to achieve the desired outcome.
• Indicate the timeline, resources and budget required to achieve the stated objectives and prepare a business case.
• Define metrics and milestones to allow regular tracking of progress.

Developing a Process Flow Diagram

The project roadmap should be driven by a combination of factors including:

• Level of effort to accomplish
• Prioritization of requirement
• Impact to the organization
• Key dependencies
• Centrally managed functions versus decentralized functions
• Global nature of the business and level of involvement and impact to each region
• Ability to address significant control deficiencies or risks
• Expiration of software licenses or sunsetting of existing products
• Budgetary or resource constraints

Treasury will also need to weigh the impact of the roadmap on the organization. Typical approaches to phase the implementation involve either deploying the system by grouping modules, such as cash management and forecasting, bank account management, payments, etc., or deploying by region. For more global organizations, the deployment may be phased by both a set of modules and by region. The roadmap and resource requirements of other groups must be discussed and their feedback incorporated into the plan. The plan should be realistic and, ideally, also build in some opportunities for early wins to gain momentum and confidence in the project. Identifying these opportunities for early wins will avoid having a project that fails to live up to the state objectives or exceeds the budget.

Why You Should Assess Project Impact

To create a realistic timeline, treasury will want to weigh the benefits of the project against the cost and time required to achieve the desired outcome. The best way to do that is to rate each impact as low, medium or high. Then, plot the impacts on the y-axis of a graph and the time and resource commitment (or level of effort) on the x-axis.

This practice can help identify low impact, low effort commitments that are good to start with as a first step to achieve a quick win.

Defining Metrics and Milestones

Defining metrics and key milestones allows treasury to monitor progress and keep everyone on track.

Each time the organization achieves a milestone, share the news and related metrics at stakeholder meetings and in key management conversations. Always communicate positive wins. This will help build confidence in the TMS initiative and demonstrate immediate value to the organization.

Designing a System

Once there is a solid foundation and clear plan, it’s time to design the system. The focus should be on determining how to best configure the TMS to meet the defined requirements and processes while taking into account industry best practices. The most successful system design projects occur when there is a holistic understanding of both the business requirements and TMS capabilities by all participants in the project, including business and technology stakeholders, as well as third-party vendors involved in the implementation.

When designing the system, be sure to:

1. Conduct knowledge transfer sessions with third-party vendors to ensure they fully comprehend the business requirements and objectives.
2. Conduct TMS training sessions to educate stakeholders on the TMS functionality.
3. Confirm with all stakeholders impacted by the implementation that they understand and agree with how the system will accommodate their requirements.
4. Define how the TMS will integrate with other systems, including:
   • Connection method
   • Frequency of data transmission
   • Volume of data being transmitted
   • Whether data transformation is required
   • If it is an automated or manual integration
   • The project phase and priority for each systems integration
5. Incorporate industry best practices into the overall design.
6. Conduct proof of concept scenarios where the implementation team models client-specific examples in the system and provides output for review and validation.
7. Structure a plan to validate output early on to help identify potential system limitations at the outset.

Garnering Different Perspectives

It is important to understand the perspective, areas of expertise and objectives of all internal and external stakeholders. Most businesses are intimately familiar with their current way of conducting business and the desired future state; however, they typically have limited experience with system implementations or knowing how treasury management systems function. While the vendors are experts on the capabilities of the TMS, they do not have the intimate knowledge of a business’ specific operational treasury activities. In order to increase the knowledge of both parties, time must be allocated at the outset of the project to conduct knowledge sharing sessions. Too often, teams dive directly into the implementation activity without ensuring proper alignment and understanding. The most common cause is due to a failure of both parties to fully appreciate the others’ needs and capabilities before proceeding with the system configuration. In order to help avoid this disconnect, utilize the checklist below and confirm each is adequately addressed prior to the system configuration.

Capturing Data Elements

An important aspect of every TMS implementation is determining what data elements must be captured in the system to best achieve the desired output. This can be challenging as you are typically compiling this information at the inception of the project, prior to having a true appreciation for how the data will be used and displayed throughout the system. It is important to ask sufficient questions to understand the downstream implications of how static data, reference data and user-defined fields will be utilized in the user interface and reports. One way to achieve this is through a proof of concept.

Treasury should keep these high-level best practices in mind with regard to data elements:

• Key elements: Ensure crucial data elements are included and captured in the appropriate location to facilitate the required system displays or output.
• Integration: Consider how data elements will interact and integrate with upstream and downstream systems. Be sure to address requirements for ERP(s), market data, trading portals, etc.
• Terminology: Determine a standardized, global naming convention that’s consistent, recognizable and understood across the organization. Treasury may want to consider terminology that users are familiar with, such as leveraging the same naming conventions as their ERP system.
• ERP structure: Look at the ERP structure by region or business unit. Each one provides data elements that treasury can capture at the entity level and facilitate utilization, grouping and reporting of the data downstream.

Determining Essential Reports

Treasury must confirm which reports and specific data elements are required, which ones are still in use and what their limitations are in order to produce the reporting output. It’s also important to understand the system’s out-of-the-box reporting views and capabilities. It is recommended to perform a reporting rationalization to validate and consolidate the reporting requirements and determine a list of must-have reports.

To ensure they have access to the reports they need from the new system while reducing the effort to develop these reports, treasury will need to:

• Identify opportunities to consolidate like reports with numerous overlapping data elements. Often, report requests are added over time without evaluating already available alternatives.
• Compare the consolidated set of reports needed with vendor capabilities. Utilizing existing, out-of-the-box reporting from the system generally minimizes costs and project risk. There will likely be some level of custom report development, but fight the urge to try to replicate the existing report package and instead only customize views where they are absolutely necessary.
• The data element design may need to be supplemented to address areas where limitations are identified. Sometimes there are free form or user-defined fields available that can be utilized to meet unique requirements not addressed by out of the box functionality, so these should be considered when limitations are discovered.

Communicating Unique Requirements

Some requirements don’t fit neatly into a box or align with the typical system utilization but still need to be included. To decide whether to add them to the list of requirements, treasury should fully examine their merits, communicate clearly so that everyone understands why they are necessary and provide tangible examples. The treasury team and the vendor should work together to identify solutions that can leverage existing capabilities and be open to alternatives that may not exactly mirror the current process. You want to avoid falling into the trap of spending excessive time on an isolated area to the detriment of the overall project timeline or budget.

Setting Up System Controls

Another key element in the design is analyzing how the system manages controls, assigns user permissions and administers these controls on a go-forward basis. A good starting point is pulling the existing SOX controls in place for each department involved in the project and highlighting which of them are applicable to the TMS. While this will provide a starting point to the level of system access granularity in the TMS, applying these controls can be daunting. Obtaining assistance from both internal resources and the vendor is advisable.

To identify key control considerations and figure out how those are addressed in the system, be sure to consider the following:

• System security: Understand how to manage user access and regional access rights, and dual-review controls in the system. Sometimes the set-up exists in multiple locations, so be sure to obtain a holistic understanding of where security is managed in the application.
• Existing controls and SOX key controls: Identify how existing controls can be strengthened and how they will change as the process migrates to the TMS.
• Systematic-based controls: Find opportunities to switch to more automated and systematic controls. For clients migrating from offline processes, hard copies are often utilized as evidence that the control step was taken. However, as you migrate to a TMS, evidence of the control step can often be captured systematically via report or system audit log. Seek to design the system to take advantage of these controls and audit evidence. Additionally, ensure it is clear where to access the audit logs and that they are deemed sufficient by your internal audit group. One example of this is transitioning from paper copy sign-off on payments based on defined dollar limits to a system audit log for which user-approved payments and security rights limit access to individuals based on dollar thresholds.
• User groups: Determine how to build user groups to achieve control objectives. For example, payment approvers that have the same approval rights can be grouped together. Grouping users will minimize future system administration.

Leveraging Proofs of Concept

Leveraging proof of concept (PoC) scenarios to validate the system design early in the implementation process is an effective method to minimize project risks and ensure alignment between all stakeholders. A proof of concept also helps identify system limitations at the onset of the project and enables treasury and the vendor to factor them into the overall project plan from the very beginning. A PoC utilizes a specific set of data from a defined period, attempts to flow it through the end-to-end system design and produces an output demonstrating the operational steps, specific calculations and reporting views. It provides the users an opportunity to visualize the system processes and validate the output while there is still time to modify it with minimal rework or impact to the project.

The following steps should be taken to create a robust set of PoC scenarios:

1. Key stakeholders should identify proof of concept scenarios (client responsible)
2. Develop input data required to produce scenarios (client responsible)
3. Model scenarios in the system and provide results including screen shots, calculations and reporting views (vendor responsible)
4. Review and provide feedback on output provided by the vendor (client responsible)
5. Identify design changes or potential system limitations (vendor responsible)
6. Validate task priorities, workaround options and development needs (both parties responsible)?

The Recipe for a Successful TMS Implementation

Depending on the scope and stakeholder groups involved, TMS implementations can be complex projects with multiple moving parts. The organizations that have the most successful implementations and achieve the most value tend to:

• Perform proper planning and alignment from the onset
• Spend sufficient time ensuring all stakeholders have a deep understanding of both the business needs and TMS capabilities prior to diving into the implementation
• Validate the system design leveraging proof of concept scenarios before building out the system holistically
• Proactively track and measure project objectives against accomplishments and ensure clear communication is provided across all stakeholder groups

These items focus on two key points—active engagement with all parties and regular communication. Additionally, planning and system design validation play an important role in every successful TMS implementation.

By keeping this recipe in mind throughout the implementation process, treasury is well positioned to deliver on its objectives and ensure the company it supports is better positioned to realize its goals.