Implementing a TMS for Cash Optimisation
by Kurt Briggs, Manager, Cash Management, WellPoint, Inc.
WellPoint operates a centralised group treasury, divided into different functional areas. As the company is the result of several mergers, however, our business organisation and processes are complex, with over 100 operating companies, some of which were state-regulated and some unregulated. At the time of the merger between WellPoint and Anthem, we had two separate cash management functions, we had disparate account structures and ways of managing cash, and we wanted to integrate these into a single cash desk. Although we had a single treasury management system (TMS) in place, this was an old system that no longer supported the evolving needs of the firm; furthermore, the system was no longer supported by the original vendor. We did not consider it feasible to build our own replacement TMS; however, we needed to find a way to manage our business objectives and produce the large number of automated reports on which we relied.
We were seeking a vendor who could flex the system according to our needs and a strong customer support team who would help us optimise our use of the system.
Consequently, we took the decision to implement a new TMS that would help us to achieve greater cohesion across our treasury and cash management activities. The system needed to be capable of handling our data volumes, both now and in the future, and have the necessary sophistication to manage our cash management requirements, whilst remaining within our budgetary objectives. In addition, we were seeking a vendor who could flex the system according to our needs as they change over time, and a strong customer support team who would help us optimise our use of the system.
We went through a structured selection process for a new system. The first task was to outline our requirements by mapping our current processes. This formed the basis of a Request for Information/ Request for Proposal (RFP) which we sent to the well-known vendors providing TMS solutions. We scored the RFP according to weightings we had determined internally and on the basis of these results, we invited three suppliers to demonstrate their products. We set additional criteria for these demonstrations, and pursued reference checks before making a final selection.
Selecting a vendor
Our decision was ultimately based on the TMS’ functional suitability and its ability to establish cohesive business processes, the supplier’s ability to support and maintain the system in the future and the strength of the reference checks. In addition, we opted for an ASP (application service provider) solution due to a scarcity in internal IT resources. We engaged our procurement department as part of the short-listing, selection and negotiation phases of the project to ensure that we complied with company guidelines on IT procurement. Once a vendor had been chosen, negotiation of price and contractual terms was undertaken directly by procurement, supported by treasury to ensure that the business requirements were satisfied.
While the pricing and contractual negotiations were under way, we were able to put together our data tables, coding structures etc. in preparation for the implementation. Consequently, we were well-prepared by the time we started to implement the new TMS. Having implemented other TMS solutions in previous roles, we had some experience of this type of project, and we implemented the new system in around nine months.
Even with advanced preparation, there were some challenges and manual workarounds. These have since been addressed and subsequently our use of the system has become more efficient. For example, there were some functional deficiencies in the TMS. What was apparent to us was that it is not necessarily straightforward to implement a system designed for the European market into a site in the United States, and vice versa. For example, in Europe, there is no concept of float, so a system designed for European customers needs to be adapted to support US cash management needs; similarly, a US-based system needs the capability to back-date transactions when implemented in Europe. Furthermore, we found that a system that builds balances by aggregating transactions has some problems in the United States: there needs to be a fixed take-on balance for take-on of a new system.
We have been successful in achieving our project objectives, and we have automated the integration of relevant information both into and out of the TMS, such as bank statement reporting, payments, debt/investment forecasting etc. We invest surplus cash through a portal, which we were also able to integrate with the TMS, and an interface is in place between the TMS and our general ledger system.
Since implementing the system a year ago, we have been able to change our concentration account structure so we now have a single concentration bank for cash management, which has led to savings for payment file transfers, and a greater ability to transfer funds between group entities as book entries rather than wire transfers. We now have a single cash desk that manages the group’s cash in a consistent fashion, so we are better able to focus on optimising our investment strategy as opposed to managing cash flow.