A Strategic Approach to Treasury Technology
Treasury technology has come a long way since the 1980’s when vendors demonstrated systems to clients from a 5 ¼ inch floppy disk and connectivity often involved an acoustic coupler. Technology has directly enabled treasurers to send a mixed file of payment instructions to their banks for straight-through processing (STP) in multiple real time gross settlement (RTGS) systems. It has indirectly encouraged the use of physical pooling through the ability to automate the booking of the required intercompany loans and the zero-balancing of accounts. It has also presented treasurers with multiple ways by which to accomplish various treasury tasks, often with an accompaniment of confusion.
Take, for example, the humble payment which can originate from an enterprise resource planning (ERP), a treasury management system (TMS) or a bank’s proprietary system. Travelling in NACHA, idoc or EDIFACT format (to name a few), the payment passes through a value-added network (VAN) or public Internet connection to a bank processing gateway using HTTPS, SMTP or IP protocol with the benefit of a digital certificate or proprietary security – also to name a few. All this occurs before the bank releases the payment into the requested payment system for the ultimate beneficiary. The technology behind each element in the payment’s path has complexity, and corresponding strengths and weaknesses, which together challenge the most sophisticated technology user.
Fundamentally, whether initiated from a 1980’s era standalone PC or from a multi-platform, multi-protocol payments engine, the outcome is still the same. The company’s account is debited and the beneficiary is credited. This article proposes that a strategic view of technology is necessary to successfully integrate the simplicity of the objective with the complexity of the means used to accomplish it. The following timeline represents one view of this strategy.
A strategic approach begins with a clear understanding of the current situation, business requirements and technology options. It also includes a well-defined view of the future state, or how the treasury will look once new technology has been deployed. Based on these elements, it is possible to develop a business case that proves the financial benefit of a particular approach and then conduct a search for vendors to deliver the required solution. This approach is different from system selection, as illustrated below.
Selection should occur when the strategic approach has been validated technically and financially. Even when experience and best practice suggest that a TMS is required and a selection project is indicated, the discipline of a strategic approach provides a framework that will endure longer than the typical vendor upgrade cycle.
A treasurer needs to start with a clear definition of the current state of technology and business process within the treasury. Development of the current state is a good opportunity to carefully examine old assumptions and understandings. Do not simply inventory the systems and how they are used – take this opportunity to find out why they are used. Was a client/server architecture stipulated by an autocratic former CIO who could not be bothered assessing the security of a hosted solution? Were the systems used installed in preparation for Y2K, the last time there was technology budget for the treasury? Old assumptions die hard, but this process can accelerate the demise of the bad ones and free up the treasury. The sunlight of a good current state analysis is an excellent disinfectant.
Take stock of what people like and do not like about the current technology. Getting and keeping people on-side is an important part of any successful project – particularly in technology where there are multiple stakeholders.
Understand the costs, which include the full costs of people downloading pdf files, printing them and then re-keying information into a spreadsheet on a shared drive instead of downloading directly into the spreadsheet. Build a simple and clear one-page diagram in Visio or PowerPoint to show how everything fits together. This will prove very useful when developing the business case.
There are three critical items to deal with when developing a set of business requirements. The first is a survey of stakeholders to identify requirements that are ‘must have’, such as the ability to consolidate all bank positions into a single global position, and ‘nice to have’, which reflect a department’s preferences. This is also the time to think about the second item, including the stakeholder. Treasury, IT and accounting are commonly included but there are also good reasons for including tax, legal and revenue management teams. A quick test on whether a function should be considered a stakeholder is the possibility of hearing the negative “we were never consulted” when a result is not to someone’s liking.
The final item is a brief gap analysis documenting the gap between what is required and what is available on the market. Package this work in a document or spreadsheet that can be circulated – and updated – frequently.
At this point a treasurer knows where they are (the current state) and has a complete set of what users require (business requirements). Examining technology options is a first look outside the organisation. The kinds of systems and architectures available to meet a treasury’s requirements fall into three categories: leading edge, bleeding edge and legacy.
Leading edge systems are innovative but have been proven in the field and are reliable. This is in contrast to bleeding edge systems – innovative but with the need to put in lots of fixes to accommodate something not entirely proven and developed. The third category, legacy systems, describes systems that are still viable but becoming superseded in terms of technology. New features for legacy systems are not being developed, or can not be developed and at some point a legacy system must be retired.
Financial viability is another part of the technology option and refers to the stability of the vendor. A treasurer does not want to build a mission critical enterprise application supported by a company that may outrun its venture funding, be acquired or undergo a change negatively affecting customers. There is no hard and fast set of rules for determining financial viability, although the current business slowdown will be helpful in culling weaker vendors.
In addition to financial viability, make sure to identify any enterprise constraints on technology use. For example, if IT bans hosted applications, then there are some major problems to work through. If a treasurer is uncomfortable with hosted applications, then there is still some work to do but it is an objection that can be overcome with help from vendors and IT.
Finally, consider the availability of technical support. It is obvious that applications prefer to fail at the most inconvenient moment. Therefore, having clear and working support tools and escalation rules is important.
The future state describes the technology in terms of approach and benefits across a number of dimensions that typically include:
It is a good idea to summarise the future state with a diagram supported by text describing the dimensions considered and how they were evaluated.
So, now, a treasurer knows what they have, what is possible and what they want. Building the business case is the part of the strategy process that helps them to get it. Get the data relevant to the strategy and structure, which includes license fees, maintenance fees, support fees, hardware costs, implementation costs and the cost of outside assistance if extra hands are needed for a period of time.
It is now time to refer back to the current state part of this exercise that shows the costs and deficiencies of current practices. Comparing these with the benefits and costs of the new approach, a treasurer is now in an excellent position to calculate the benefits of this new approach and demonstrate their impact on the bottom line.
Do not lose site of the objectives and be open to compromise. If the numbers do not work or something else is in the way of a good business case, be willing do drop some features or functionality for the sake of overall progress. Although perfect consensus may not be achieved, compromise can help to avoid many slings and arrows.
With all of the preparatory work in hand, it is time to embark on a system selection project, perhaps following the methodology outlined at the beginning of this article. Selection is a tactical exercise where the primary mission is to preserve the strategy in the face of dazzling demonstrations and eloquent sales presentations. There are many excellent papers on the subject of system selection and the request for proposal (RFP) process, but this concludes the examination of a strategic approach to treasury technology.
In summary, it is worthwhile to follow the carpenter’s maxim of ‘measure twice, cut once’. By doing this, the strategy will win acceptance and help the treasury get the technology tools it requires.