Definition of Current-State Processes

The first step is to obtain a clear understanding of all current processes touching the treasury function. A typical approach entails creating cross-functional process flow diagrams and documenting key controls across the various tasks related to treasury responsibilities. Typical processes to document include those surrounding liquidity management, cash forecasting (potentially different processes for the short term vs. the long term), treasury payment execution, funding (typically divided between various funding vehicles utilized), investment management, risk management hedging (typically one for each risk type being managed), and treasury accounting.

These are the most commonly documented processes, but it is important to consider other processes that may not come to mind at first thought. Other processes to consider include netting, in-house banking structures, risk management compliance, financial reporting, and bank account and cash reconciliation. Components of these processes can be highly nuanced and cumbersome to maintain. As such, having a clear understanding of the current state will greatly aid in understanding opportunities to enhance these processes in a future-state design.

When gathering the information required to create the process flow diagrams, the project team should take care to capture the following:

• A list of all highly manual processes;
• The amount of time required to execute each task in each of these processes;
• The tool or application currently used to perform the task;
• Gaps or deficiencies between desired processes and the current capabilities of systems and services utilized to manage the processes being documented;
• Potential control weaknesses—such as inadequate segregation of duties, incomplete audit trail, or limited financial analytics;
• Data hand-offs within treasury teams and between treasury and other functions throughout the company; and
• Examples of key reports, such as cost of capital analysis, daily liquidity, FX exposure management, and financial disclosures.

The analysis should span all regions in which the company does business. Moreover, participation in the process redesign initiative shouldn't be limited to members of the treasury function, but should encompass every internal group that either provides input into a particular treasury process or consumes data coming out of the treasury function. A number of groups outside the core treasury team might meet these criteria; some likely candidates include accounting, accounts payable, accounts receivable and cash application, financial reporting, financial planning and analysis, sales, tax, and IT.

Failing to include groups outside the core treasury team in an effort to redesign a company's treasury technology infrastructure limits the degree of transformation the technology implementation can realize. The benefits of including a broader group of business functions can be substantial. For example, a centralized treasury platform that has tight integration with both banks and internal groups outside of treasury can serve as one source of the truth for all financial activity. The accounting team, for one, will benefit if a new treasury management system begins automatically collecting bank data, assigning proper general ledger coding, and then creating balanced entries that post directly to the accounting system.

Involving people from across the company also helps the treasury team create a compelling business case when attempting to obtain funding for the project, as it broadens the perceived benefit to the overall organization. The more stakeholders who are vested in and sold on the benefits of the initiative, the easier gaining final approvals will be, not to mention getting resources allocated to the project.

There are potential challenges inherent in engaging groups outside of treasury, and a change initiative is easier to manage if it focuses on areas within the project leader's control. But groups outside treasury will likely be receptive to the change initiative if potential benefits are communicated to them clearly and collaboratively. Treasury is often the center of many cross-functional processes, and optimizing treasury functions can greatly strengthen the overall finance team.

Thus, the team should develop current-state process flow diagrams demonstrating how treasury-related processes currently work throughout the entire organization. They should be sure to point out any inconsistencies in how processes are performed across regions or subsidiaries. Highlighting these differences lays an important foundation upon which to build the optimal future-state design. It's also important to keep in mind that manual processes have a tendency to be highly customized, which creates difficulty when translating local processes into a systematic approach that is standardized across the organization.

Asking questions with a focus on weeding out unnecessary steps and keeping an open mind to change is critical to the success of the future-state plan. 

Future-State Design

Once the project team has a clear understanding of the current state of the company's treasury processes, they can initiate discussions regarding the future-state vision of the organization and the associated processes. They should start by defining the project's guiding principles, key objectives, and scope.

The guiding principles should align with the key initiatives of the overall corporation. An example is: "To optimize our capital structure so as to support future acquisitions." When considering the most appropriate guiding principles, the team should consult with senior management, including the CFO, CTO, and division leads, if applicable. It is important to ensure the project's strategy and approach are conducive to achieving key corporate objectives. For example, if the company is acquisitive, then forecasting future cash flows and optimizing the corporate capital structure may be the paramount goals.

Although the guiding principles will not necessarily drive day-to-day decisions, they should be considered when making key design decisions, and they should serve as a constant reminder of the bigger-picture objective this initiative is helping achieve.

The key objectives are the outcomes the company wants to achieve through the project. Some examples of typical objectives include:

• Standardizing processes globally;
• Centralizing specific functions;
• Creating a straight-through processing environment, from transaction request to consummation to accounting and financial reporting;
• Providing a single source of the truth for financial data;
• Reducing by 30 percent the proportion of employees' time spent on manual processes; and
• Optimizing liquidity management, in order to reduce the cash reserve the company must maintain and to enhance investment yields.

The objectives should be set prior to the software selection, and the key stakeholders from each function should work together jointly to define them. Factors to consider when establishing the objectives are organizational goals or key performance metrics, analysis and benchmarking against best-in-class organizations, and opportunities to elevate the analytical capabilities and focus within the company. The objectives should be aspirational and stretch goals, so aim high.

With that said, the project needs a champion with sufficient position, who has fully bought into the objectives, to help ensure those objectives are achieved. During the course of the project, certain objectives will inevitably be questioned, or the team will lose focus on them, so having senior leadership championing the objectives is critical.

Additionally, if the metrics showing progress toward the key objectives are included in the project progress updates sent to senior management, they will stay front-of-mind and ingrained into key decisions.

The project scope should be established based on the project's guiding principles and key objectives, but at a much more granular level. As such, it is typically drafted by the project team members and reviewed and signed off on by the key project stakeholders.The project scope should define the features and functionality of a treasury management system that are must-haves for the company, and prioritize other features that would be nice to have but aren't business-critical. The scope should include technology considerations such as the deployment methods available and integration with other applications key to the company's operations and accounting. This step of the planning process is crucial, both for ensuring the company selects the appropriate technology solution and for guiding tough decisions that will need to be made throughout the implementation.

Future-state process flows. Once the project team has established the guiding principles, key objectives, and scope of the technology implementation, they should spell out the future state they would like to achieve in every process that affects the treasury function. It is advisable to keep these future-state plans at a higher level and more objective-based than the current-state process flows the team already developed.

For example, the current-state FX exposure management process may include details on how the data is compiled, reviewed, and consolidated in a series of Excel spreadsheets, and then the processes for executing and capturing the exposures and corresponding hedges in another Excel spreadsheet. In this example, the future-state process flow may illustrate a set of exposures being captured by a treasury management system, an exposure report being generated, and then hedges being executed via a third-party trading portal. The goal should be to define the desired flow, including opportunities to streamline and automate processes while leaving flexibility to make modifications based on the capabilities and best practices of the system selected.

To the extent a company details its future-state processes before it fully understands the capabilities of the treasury management system it will ultimately implement, it may need to revisit its future-state design after making the software-selection decision so that its proposed processes align with the tool's functionality and recommended workflows.

The process of defining the desired future state of the treasury function also presents an ideal time for benchmarking one's organization vis-à-vis its peers in the same industry, as well as vis-à-vis companies recognized as having best-in-class treasury functions. Activities to consider for benchmarking include size and organizational structure of treasury group, such as existence of a shared-service model; bank fee analysis; utilization of and overall spend on treasury technology; and the extent to which they leverage more complex structures, such as a payment factory, netting, an in-house bank, and hedging. The data required to perform a proper benchmarking analysis can be obtained from industry sources such as the Association for Financial Professionals (AFP) or from the company's banks. Another alternative is to leverage a consulting firm specializing in this analysis.

Obtaining this information may take some effort and require peer networking, but it's a worthwhile exercise. Stepping back and evaluating one's organization against others is an excellent opportunity to inject new ideas into treasury processes and to ensure a more robust future state. Networking events, conferences, webinars, and online discussion groups are great settings for information sharing.

Prioritized Roadmap

The implementation of a new treasury management system, or a substantial upgrade to systems a company already uses, will likely require a number of steps and may span an extended period of time. This means it is crucial to create a well-defined roadmap that measures progress and ensures the organization maintains focus.

For each task that is integral to successful deployment of the treasury management system, the roadmap should take into account its priority, key dependencies with other tasks, impact to the organization, and the level of effort required to complete it. Other potential factors to consider may include expiring contract licenses of existing vendors, budget or resource constraints, and key control deficiencies.

If the company has never previously undertaken a comparable initiative, preparing realistic timelines and resource requirements may be challenging. In such situations, reaching out to internal technology teams is a good idea, as those groups should be used to executing projects and would likely be able to provide key input. The company might also have internal processes or standards that must be adhered to, which could impact the project team's assumptions. For example, some organizations have a robust set of project implementation procedures and documentation that must to adhered to, including a formal project charter, project scope, risk management analysis, change management impact, testing plans, and potentially numerous others. Many of these documents can be helpful in getting organized and thinking through all the potential impacts and risks. However, they can also add significant overhead to the project, which the project team may not have anticipated. So even if similar projects have been executed in the past, it may still be important to engage the technology team in roadmap discussions.

Additionally, all stakeholders in the project—including functions outside treasury—should be engaged in planning the project roadmap. Engagement in the planning process is critical to creating a sense of ownership. The project will need the support of these groups throughout its lifecycle, so obtaining their input and buy-in from the outset is an absolute necessity.

When the future-state design and the project roadmap are complete, the project team is ready to select the ideal technology solution to help the company move forward toward achieving its desired future state. While the technology selection and implementation effort will contain their own set of unique challenges, to the extent the project team have performed proper planning, they will be well prepared for the road that lies ahead.

See also:

• Evaluating Treasury Management Systems

—————————————

Chad Wekelo is the founder and principal at Actualize Consulting, where he leads the Capital Markets & Treasury practice group and specializes in treasury operations, liquidity management, accounting, and risk management. Specifically, Wekelo has detailed knowledge across all treasury products, including debt, derivatives, and investments, as well as cash management and payments.