In January we described the process required for choosing a TMS. Having selected a preferred vendor and system, what are the next steps in installing the system?

The key objective of the implementation phase is to have the new system running and performing the required functions as quickly and efficiently as possible and within budget. In general, the core stages in a TMS installation will be the same, regardless of the type of system chosen. So while application-service-provider (ASP) and Software-as-a-Service (SaaS) products may reduce the time taken to implement a system and will affect the upfront cost, contract structure and level of customisation available, they do not fundamentally alter the basic steps that ensure a smooth implementation.

Successful implementation relies on a comprehensive project scoping exercise, and the development of a detailed project plan. Key milestones are identified and progress is regularly monitored during the implementation, to ensure that the process remains on track.

The strategic objective is to deliver the solution that yields the set of business benefits that justifies the organisation’s TMS project investment. The project also provides the opportunity to put in place new, best practice treasury workflows. Implementing a new cash management solution should result in more invested cash and better processes.

Break down the process into stages

Implementation is broken down into a large number of discrete steps that can be grouped together under several umbrella headings.

“A typical implementation for us is divided into approximately 20 discrete high-level steps. The specific milestones for an actual project can be identified after completion of a detailed project scoping exercise. Each of these stages will be included as milestones in the project plan, which will include the applicable resource assignments (vendor management, consultant and technical, client management, treasury/accounting executive responsible, technical), progress indicator, completion targets and actual completion dates,” explains Patrick Coleman, Regional General Manager, IT2 Treasury Solutions Limited.

Create a project team

The first step is to build a project implementation team. This will include the senior implementation consultant from the vendor, a specialist external treasury consultant if one has been hired, a project manager from the buyer, a business analyst who understands the current treasury processes and an IT co-ordinator to deal with legacy system issues.

External consultants can help at several levels. They can advise and support the detailed scoping exercise, and the preparation of the project plan. Implementing a new system is an opportunity to implement best practice treasury operations, and consultants can re-engineer treasury workflows that reflect the latest thinking. It is these workflows that the treasury/vendor team will implement in detail.

Paul Bramwell, Senior Vice President, Treasury Solutions, SunGard’s AvantGard says, “Once a project approaches the 60 to 70 day implementation level, where you may have a treasury department with four to five people in the project, you are getting to the stage where you need an external consultant. It brings discipline to the project and is especially helpful when it comes to change requests.”

A steering committee can also be formed that will include the most senior person involved respectively from the supplier and the company (the project sponsor) and the project manager. This group is responsible for agreeing major changes to the project plan and to resolve any problems or disputes.

“Larger projects especially benefit from supervision by a steering committee to oversee the project’s progress against the plan, and works to ensure that the project fulfils its strategic objectives,” says Coleman.

Project planning

With the team in place, the next task is to rigorously define and document the objectives of the project and the deliverables expected of the vendor. The vendor is instrumental in this process and the result of the process should be an agreed statement of work (SOW). This document describes the purpose of the project, the scope of work, the timetable, deliverables, acceptance criteria and payment schedules. It is crucial at this stage to define implementation responsibilities clearly, especially how these are shared between suppliers and the buyer.

In the context of a TMS, this means making a complete analysis of all the treasury business processes to be implemented and planning the system configuration. To ensure that the system delivers the core functionality quickly, treasury priorities need to be clearly mapped – for example, connectivity and cash positioning for primary operating banks or general ledger posting for corporate headquarters.

Only when this statement of work has been exhaustively checked and approved can the next stage in the process begin.

“The detailed plan will contain several tasks (including training as applicable) which together comprise the activities needed to complete the milestone. Many of the intermediate tasks can be performed in parallel, enabling the project to be accelerated – if there are sufficient resources available to do so,” explains Coleman.

Source: Lillie Associates

Bramwell adds, “An important function of the planning phase is to inject realism into the process. Treasurers are often optimistic about the time it takes to implement what are, after all, complex pieces of software that are being used within very complex processes.”

“There is also often a need to reset of thinking in terms of functionality. Often TMS systems are being introduced to replace spreadsheets. But spreadsheets are among the most flexible software tools ever created and while treasurers welcome the standardisation and other benefits that TMSs introduce, they have to accept that they have to compromise.”

Technical environment set-up

As hosted solutions become more common, this is becoming less of an issue. However, if an in-house solution has been chosen then there is a significant amount of work for the buyer in terms of hardware, software, data connectivity and other external interfacing. “If a hosted or ASP solution has been chosen, then we as vendor can control all of that and offer much more besides. For example, we are a member concentrator of SWIFT and we are a SWIFT service,” says Bramwell. “It is quicker for us if we control the hardware and software environments and don’t have to wait for the company’s IT department.”

Integrations (such as bank reporting, market data, ERP system)

A key step in the process is integration with core systems. The most important connection the new system has to make is with existing banks. It must be able to access prior, current and intra-day files and set up file transfers to new banks; interfacing the banking and treasury systems to achieve straight-through processing will improve daily cash management and forecasting; and there will likely be interfaces to other treasury software such as market information systems, multi-bank dealing portals, ERP systems and confirmation matching systems.

The TMS may also be required to interface into specialist risk management software or an existing cash management solution. Teams frequently underestimate the necessity for and time taken in assembling accurate interface specifications, especially for bank balance and transaction reporting, payments exports and ERP system integrations. Reporting requirements should also be fully specified, given that the improvement of the quality of operational and management reporting is often a primary business driver for implementing a new TMS.

Static data management

Treasury should work with the selected vendor at an early stage to plan the static data element of the project in full detail, and then commit the necessary resources to complete the necessary tasks effectively and within the required timeframe. Each vendor will have different requirements for the format the data should be in and can provide those details in advance.

“Treasury teams often underestimate the effort needed to collect, review, complete and organise the static data needed to operate the new system effectively, especially, as is usually the case, when the new TMS offers greater power in the breadth and depth of available solution,” says Coleman.

Functional application implementation

As well as the core bank interfacing, every asset class and definable functionality block has to be implemented. This can include foreign exchange, interest rates, commodities, risk management, cash management and cash forecasting.

Bramwell explains, “We map out all the asset classes and processes – cash management, cash forecasting, risk management and so on. For each of these areas we would develop a rigorous process for achieving the desired objectives and metrics to judge success in achieving them.”

Regular reviews

It is crucial throughout the project to conduct regular reviews of progress against milestones and the budget. In this way, most problems and disputes can be headed off before they become serious.

“In the course of the project, it is important to monitor that all tasks are progressing and completing on or ahead of schedule, so that any unexpected issues are identified and rectified before they have a material impact. This implies that there should be a change management contingency built into project planning,” says IT2’s Coleman.

User testing, training, parallel run, go live

Once the system has been installed, the end-user treasury staff must be familiarised with the system and trained in its functionality. Their feedback must be incorporated into the final implementation. Consideration should be given to staff outside the core treasury function too.

For example, the accounting department will need to be satisfied that the correct entries are being passed into the general ledger and that the interface works well; business units may be given direct access to the system, to provide data to the centre and to use the system analytics for their own planning. Senior management may be given direct access to the system too. All these staff will need to be trained.

External auditors may also have to be consulted to ensure that they are satisfied that the TMS carries out its various calculations and position reporting functions accurately. At this stage the system should be tested both with dummy transactions and also in a full parallel run with existing systems to ensure accuracy.

System optimisation

Best practice suggests that between six months to a year after implementation, treasuries that have bought a TMS should go back to the vendor to review their usage of the features and functionality. The vendors have typically installed many tens of systems and have a much broader knowledge of how similar users are making best use of the systems’ features. However most companies do not take advantage of this knowledge and do not use their vendors as post-implementation advisors or trainers. This deprives them of significant additional ROI.

Common problems

The commonest problems companies experience when implementing a treasury management system arise when the opportunity is not taken to analyse and re-design treasury workflows to take full advantage of the TMS’s facilities. Simply re-implementing the current processes risks reproducing the shortcomings that justified the investment in a new TMS.

More prosaically, staffing issues cause the most headaches. Says Bramwell, “The commonest problem is staff turnover. The most problematic implementations are those when there is high staff turnover and the new people are unfamiliar with the project and do not have the same level of buy-in as the individuals who initiated it. This is a key project risk that needs to be evaluated ahead of time and contingency-planned for.”

An extension of the staffing issue is simply a lack of sufficient qualified resourcing in the treasury implementation team. This can lead to errors and omissions, and so delays and budget overruns. Bramwell adds, “Lack of dedicated project management is often a problem. We can provide that but it is often lacking on the client side.”

Finally, alterations to the scope of the project commonly cause significant delays in implementation. This usually occurs as the treasury team identifies improved solutions as they learn in depth about the new TMS’s capabilities. This should not happen if the selection project was sufficiently thorough, but is common because of the business pressures under which system selection projects are often performed. It is possible to manage changes of this type smoothly, provided that effective change management processes are built into the project structure.

As Bramwell puts it, “Changing the fundamental scope of the project mid-way does create problems and we recommend the creation of both a steering group (that meets weekly or bi-weekly) and a management group that includes more senior executives not involved in the day-to-day implementation that meets monthly.”

Most pitfalls can be avoided by accurate planning and project management and by staffing the project team with an adequate number of appropriately qualified personnel. And, as Coleman points out, “At a high level, a successful project needs the appropriate level of buy-in by the management and teams of all interested departments, including finance, audit, procurement, legal and the business structure.”