Treasury System Selection

Treasury System SelectionTreasury System Selection

The implementation of a Treasury System is a non-trivial exercise requiring management of requirements from a broad range of stake holders.  While particular areas may look forward to improved efficiency from a new system, it is critical that all requirements are treated according to an agreed weighting.  When approaching Treasury System Selection, most organizations now avoid the burdensome and expensive RFI/RFP approach. A disciplined approach to understanding and documenting key requirements is still essential as is the management and documentation of workshops allowing the selection of chosen vendors to present their function.

Outcome: Agreed Treasury System to automate identified Treasury processes and improve efficiency

Objective: Review and compare available systems in light of process automation and reporting needs.

Description: The selection of a Treasury system can be broken down into 10 specific steps. While certain activities in the system selection process may be deemed optional, all steps should be considered to ensure the final implemented outcome meets all stake holder requirements.

1. Define Roles of IT, procurement and other departments

It is unusual for Treasury departments to implement systems without the input and resources from other departments. It is important to agree and document the roles that each stakeholder will play. For example, IT involvement may be necessary to ensure ongoing IT support post live, or procurement may be able to assist during the later contract negotiation phase.

2. Assess existing and critical processes.

Treasury needs to first understand existing and desired processes prior to seeking automation as well as considering cross functional area requirements. Understanding processes and workflows in the existing environment will allow for the identification of potential improvements. In reviewing existing procedures it is important to remain open to changing and even eliminating unnecessary tasks. Once documented, a level of importance should be assigned to help facilitate the selection and assessment process.

3. Identify System vendors.

At this stage it is important to have input from IT in order to agree an SAS versus installed solution approach. This approach will then help reduce the number of possible vendors. Desired vendors may include best of breed comprehensive solutions through to functional specific offerings.

4. Develop Request for Proposal (RFP)

It is important to provide the vendors with as much information about your company, treasury, IT and other requirements. It can be helpful to involve procurement at this stage as they may have standard language that must be incorporated. Spending time up front on the RFP will minimise time spent down the track on Vendor questions. The RFP stage can be replaced with a more hands on and well documented system presentation and Proof of Concept stage.

5. Analyse RFP

The analysis of RFP responses should be undertaken by all stakeholders, Treasury, Accounting, IT, procurement and not simply the project team. A degree of rigour is required in this analysis in the form of a scorecard or similar quantitative approach. A scorecard helps to distinguish system offerings.

6. Vendor Demonstrations

Vendors can now be scheduled to attend your offices and present their systems. This forum provides much greater insight into system capabilities and allows for a Q&A session prompted by demonstrated functions. Vendors should be expected to follow standard scripts provided by Treasury to ensure all vendors touch on key points of the requirements. Buyers may also decide to provide key data in order to ensure all vendors are shown on a level playing field. Each demonstration should be conducted over a half day period with never more than one demonstration per day. It is useful however to have all demonstrations conducted on consecutive days.

7. Short listed Vendor Selection

Following the demonstration and RFP analysis stages, buyers should be able to reduce their list of vendors down to two or three providers. While Treasury will be the key driver in this short list, the final decision will be a compromise among all stakeholders.

8. Conduct Reference checks

The Vendor response to the RFP will have included a section on client references that have agreed to talk to potential buyers. While these are useful a vendor would never choose a dissatisfied client for a reference, it is therefore useful to use other contacts to undertake informal reference checks. It is also best to have a script prepared for these reference calls with open questions to facilitate the greatest insight into their vendor experience. Ultimately, if it can be arranged, on site visits will yield the best results.  We have a number of clients using all the major treasury systems on offer and would be happy to organise independent reference calls.

9. Proof of concept (PoC)

Considering the investment that may be required, a more detailed and hands on test in a buyers own environment may be called for. These more detailed demonstrations may be followed over two days to allow detailed analysis of proposed workflows and available reports. It may be necessary to conduct this testing within an agreed consulting agreement with the vendor and for a small fee. Conducting this exercise with two vendors will provide negotiation leverage.

10. Contract negotiation

Negotiation of final price and contract may fall within the responsibility of procurement however Treasury must remain involved throughout the process to ensure ultimate business objectives are maintained. Various aspects of the contract may have greater importance for one vendor versus another so understanding the type of company your chosen vendor is will help facilitate this negotiation.