A request for proposal (RFP) is your first and best opportunity to keep a technology project on track, whether it is a treasury management system (TMS) installation or other treasury technology upgrade. A systematic process leading to an RFP that incorporates everyone’s expectations and requirements will prevent mission creep and avoid compromises on expectations. Both the process of gathering requirements and the finished document are key to ensuring the project is, and remains, fully accountable and on track.
The first decisions are typically made before the document is even finalised, but it is important to get the process right. At a fundamental level the RFP and the long list will have ‘built in’ some sort of decision as to the scope and shape of the eventual solution. For example, it’s often a fair assumption for multinational corporations (MNCs), given the limitations of incumbent spreadsheets, duplicated tasks and incomplete visibility of cash and risk, that a TMS is the only realistic solution. Others may confine the envisaged solutions to encompass enterprise resource planning (ERP) only models, but the decision should be explicit and accountable, taking into consideration all other options.
For example, it may be that budgetary and technical requirements permit, or dictate, a smaller additional system. The incumbent treasury solution may in fact be generally satisfactory for current purposes, eighty or ninety percent of the time. However, the issuer of an RFP for a broad spectrum treasury solution might sometimes legitimately be directed to more specialist modules to address specific pain points, such as electronic bank account management (eBAM), foreign exchange (FX) exposure management or non-treasury payments management. The question is did the pre-RFP process provide an opportunity to consider a leaner, alternative solution?
Tell Vendors What is Required
With everyone’s views on board, and the long list identified, it is critical to articulate a precise vision and to tell the whole story to the document’s recipients. A thorough introduction from the commissioning treasury is essential, giving expert providers plenty of treasury, business and technology context. Vendors have significant consultative experience, a resource that can be tapped to save money and ensure success. The introduction should therefore explain in some detail:
- The current treasury business and organisational situation.
- The challenges that need to be addressed.
- Describe and clearly explain the end result aspired to.
An experienced sales consultant will in turn, deliver a full response – identifying your assumptions and taking the opportunity to devise a more compelling, better value solution than would otherwise be achievable.
Answer Real Life Process Requirements, Not Just Checklists
The apparent rigour of listed ‘tick box’ functional checklists can obscure the existence of considerable opportunity for the issuer of the RFP. Fundamentally the RFP process is about enabling the better support of real life processes, needed to fulfil specific objectives, typically including workflow efficiency and eliminating duplication data entry, control, auditability, and improved reporting. Consequently, the very best RFPs ask more sophisticated ‘how’ and ‘describe’ questions. Even if a vendor can ‘tick’ the required deal types, does a proposed system solution actually answer fundamental process and governance requirements?
So here’s another way to capitalise on what is available. Rather than simply specifying the functional requirement, for example ‘does the system support derivative X?’, give providers an opportunity to add a concise description of ‘how’ key processes are supported. Beyond the confines of the RFP process, consider partnering with vendors at an early stage to identify potential opportunities to engineer in process improvements and best practices. The opportunity to make improvements to operational workflows within a corporate treasury is typically very considerable.
Avoid IT Buzzwords
IT policy and business requirements are often more subtle and flexible than is appreciated, and maximum freedom of choice is a valuable asset to the treasurer issuing of an RFP. Freed from the presumption that an application service provider (ASP), for example is required, savings could be made by allowing respondents to the RFP to propose other options for shared hardware, for example hybrid or total cloud solutions.
Again, best practice begins before the RFP is even written, with a review of the most fundamental technology requirements, starting with security and licensing. A good starting point is to interrogate both business and technology policy, in partnership with IT management. If the requirement is to minimise capital layout or to spread the costs of ownership, you may well be asking for a solution that exists wholly or in part in the cloud, on a selected third party’s shared hardware. And if you’re not, should you still be open to the possibility? Many of the traditional objectives to such a model are changing. For example, an MNC might have ruled itself out of the public cloud because of the unattractiveness of shared databases and forced upgrades, yet neither is any longer a necessarily characteristic component of public cloud solutions.
In a fast moving field, assumed preferences about technical models can be an expensive option to write into the RFP. Solutions should be assessed for compatibility with fundamental technical and business requirements. Don’t fall into the trap of using potentially misleading technology industry buzzwords, like ASP or software-as-a-service (SaaS) to restrict the options available to the respondents to an RFP. Instead, take the opportunity to secure maximum freedom of choice as to technical model, a valuable asset to the issuer of any RFP.
Keep it Up-to-date
While imprecise buzzwords are to be avoided it’s important to ensure that the RFP and the envisioned solutions are up-to-date. Treasury technology is developing rapidly, and a good RFP will take account of this fact, broadening the scope of savings and capabilities on offer to the issuer to accommodate any future developments.
One approach to identifying and securing these opportunities is to make sure that key mainstream trends in the public cloud, concerning mobility, connectivity, key performance indicators (KPIs) and banking, are written into the RFP in precise terms. Take time to distinguish the buzzwords from the underlying trends. Draw on the best available independent analyst thinking. Key reports in the space are developed, for example, by Aite Group, as well as by specialist publishers, for example see gtnews’ TMS Buyers’ Guide.
Take the opportunity, in formulating the RFP, to minimise the need for additional technology investment during the solution’s lifecycle. For example, many commentators and experts anticipate using eBAM and tablet devices during the immediate lifetime of a new treasury system. For senior management, the ability to extract reports instantly on a tablet is already a given. The question to ask during the compilation of the RFP is ‘will the technology specified provide a satisfactory working solution throughout the system lifetime’? Should you, for example, still be tied to a desktop workstation or office internet connection in three years’ time?
Deriving precise questions about support for specific areas of technology development can help de-risk and future proof your technology procurement. It amounts to a form of technological arbitrage, if the alternative is buying additional technology in future. You can also secure a powerful indication of a vendor’s commitment to the technology and to continued innovation.
Related to the key issue of vendor and system viability and commitment to specific treasury technology is the question: ‘will the proposed system be sufficiently well supported to keep delivering the solution that I need’? Specifically, RFP questions should be aimed at objectively understanding the merits of support offerings. How many support staff and what resources are exclusively devoted to a proposed TMS? Who is your dedicated point of contact? Do I, for example, get support fee credits for a supplier not meeting the service level agreement (SLA)?
Equally, being left high and dry by changes in vendors’ product portfolio commitment is a significant potential procurement pitfall. It is important to get an objective picture of vendor’s long term appetite for continued investment in the product. Key questions include, for example, what percentage of the vendor’s total research and development (R&D) commitment still relates to the proposed system? What percentage of revenues are invested in R&D? How strong is the client user group, and how are clients’ requirements incorporated systematically into the on-going development of the solution? Full answers, or otherwise, will tell you all you need to know.
Breadth of Vision
While just one part of a best practice procurement exercise, an RFP presents a considerable opportunity to a treasurer to harness the experience, technical knowledge and commercial acumen of dedicated teams of treasury and technology experts. At the same time, there are easy wins to be secured by the RFP issuer, avoiding unwanted surprises and costly technical limitations. Box ticking is to be avoided: an RFP combining precision with breadth of vision will enable the treasury to secure maximum commercial, technical and treasury business benefit from a competitive tender process.
When Mark Cuban declared that "Data is the new gold" he highlighted why information is possibly the most valuable asset a business has. APIs are the unsung heroes that make it possible to extract that value.
How treasury stands to benefit from blockchain: Ripple’s goal to revolutionise cross-border transactions
Imagine a world where cross-border transactions can occur in real-time, at a few cents per transaction, to and from any bank, in any ... read more
Europe’s opening banking regulation is finally here. After months of preparation across the continent, the Revised Payment Services Directive comes into effect on January 13.
A 'digital treasury ecosystem', where the CFO or treasurer makes real-time financial decisions on their tablets, is not far beyond the reach of currently available technology. In such an ecosystem, there is no direct reliance on banking partners or the company’s broader organisation - just an executive and an interactive dashboard powered by interconnected digital technologies, writes Eric Cohen, PwC.