Published: May 01, 2010
In his last two articles for TMI, Peter van Rood, Group Treasurer of AkzoNobel, introduced the treasury transformation project that he has spearheaded, and outlined the approach that the company has taken of defining treasury policies, including exploring how the company obtained financing during the climatic period of late 2008 and early 2009. In this article, Peter and Treasury Controller Johan talk about the new treasury technology infrastructure that was put in place to support the new and evolving needs of the business.
As we had inherited treasury technology from both the AkzoNobel and former ICI businesses, it was important to put in place a new solution that satisfied the needs of the newly combined treasury function and businesses. We used Wall Street Systems’ Wallstreet Suite (formerly Trema) which had been implemented relatively recently, but this was surrounded by a plethora of legacy systems, including a mainframe system that we used to support our in-house banking and payment factory requirements. This mainframe system was based on obsolete technology and created operational risk in two key ways: firstly, maintaining the system was becoming increasingly difficult and costly; secondly, it was not sufficiently robust to handle the transaction volume and complexity that we required. In addition, we had a variety of other systems in place, including Misys for confirmation matching and SAP FI (financial accounting). These systems were not completely integrated, leading to process inefficiencies and manual processes with the increased risk of errors and requiring significant resourcing.
Essentially therefore, with a variety of fragmented systems, some of which had outlived their usefulness, we knew that our IT portfolio would not support the treasury transformation that we intended to roll out. Implementing a new treasury infrastructure was therefore an important element of our overall project.
The objectives for our treasury technology project were aligned with our overall transformation initiative, as opposed to setting standalone objectives. Therefore, we were seeking to achieve 1st quartile treasury performance to enable the full operational and strategic potential of treasury to be realised. To enable resourcing to be allocated to more value-added activities, we needed access to a full range of functionality and a high degree of automation and efficiency in our treasury processes. In addition, we wanted to reduce our IT costs, which had become very substantial as we were the only user of our mainframe system, and reduce our dependence on our banks.
We considered our functional needs in the context of our business environment. For example, we have a group-wide strategy to implement SAP, so each department is mandated to implement SAP unless there are compelling business reasons otherwise. As a treasury function, we have kept our deal execution requirements relatively straightforward, so we did not need a highly complex solution, but we needed the ability to process large volumes of transactions. In addition, one of our greatest technology challenges was to achieve effective integration between the systems of group treasury and our subsidiaries. Based on these key factors, we made the decision to implement SAP in treasury, although we also considered third-party treasury systems that would also have supported our requirements.[[[PAGE]]]
In order to achieve our 1st quartile ranking in treasury performance, we sought to implement the latest developments in SAP, such as SAP PI (Process Integration) and SAP BCM (Bank Communication Manager) which was critical to being able to deliver centralised payments across the group. Other systems that we decided to implement were SAP Payment Factory, SAP In House Cash, SAP Treasury Risk Management, SAP Cash and Liquidity Management, SAP Financial Accounting, SwiftNet and FXAll, the currency trading platform.
Pictured (left to right): Paul Waldenmaier, Project Manager, Judith van Paassen, Partner Zanders Treasury & Finance Solutions, Peter van Rood, Corporate Director Treasury, Johan van der Westhuizen, Treasury controller
One of the first decisions we needed to make was whether to implement the different modules of the SAP Treasury solution sequentially or in parallel. There were advantages and disadvantages to both approaches. For example, a sequential implementation would deliver value later, but would create less project management complexity, while a parallel approach would require more focus on aligning different elements of the project, whilst delivering value more quickly and for (potentially) less resources. We opted to implement all SAP modules in parallel, so that we could maintain project momentum during a condensed project timescale, as well as avoiding the issue of maintaining version control.
Re-engineering the entire treasury IT infrastructure provided a major advantage over implementing individual elements on a piecemeal basis, as we could implement wholesale change without having to work within the limitations of individual legacy systems. In order to reduce cost, risk and project timescales, we decided to adapt our processes to ‘standard’ processes where possible in the most recent version of SAP and to minimise bespoke developments. Some of the tools we implemented were still new, which in theory could have added to our project risk, but in reality, being an early adopter meant that we received excellent customer support and issues were resolved quickly, enabling us to work within our timescales.
We had a rigorous, disciplined approach to project management, including reference groups and a steering committee which were critical to our success. The key project milestones were as follows:
Phase I. During this initial phase, which took around one month, we made the decision for the SAP solution, developed our business case and obtained Board of Management approval.
Phase II. We then issued a request for proposal (RFP) for an implementation partner. We considered a number of consultants, taking into account their experience, cost, track record, capacity to deliver and their fit with our project team. Based on these criteria, we selected Zanders, who have proved experts in their field and instrumental to our project.[[[PAGE]]]
Implementing a new treasury infrastructure was an important element of our overall project.
Phase III. During the third phase of around four months, we defined the business requirements and converted these into over 80 technical blueprints, each element of which was then reviewed and signed off. With hindsight, it might have been useful to have allocated more time to this stage in order to review the totality of changes holistically and then close off the blueprint stage. This is definitely a recommendation for those that aim to pursue a similar project. It will ensure that from an IT and control perspective the implications of the changes have been considered from a total process perspective.
Phase IV. We then took four months to realise the solution, including configuring the system with our data and structures, defining and documenting key processes and updating our control framework.
Phase V. We spent between three and four months on detailed testing, initially by module and then testing across the entire workflow. Our partner bank, ING, was very supportive throughout this process and helped with testing of straight-through processing, statement retrieval, reconciliation etc.
Phase VI. On April 1 2010 we went live on SAP, which was ambitious but ultimately achievable. It was essential to meet the predefined go-live criteria that ensured we went live in a controlled fashion.
In addition to completing the project steps, we had adopted a very stringent quality assurance process throughout, using a specialist from Ernst & Young, and internal and external audit. These teams reviewed our activities and raised queries as necessary; this added to workload associated with the project and added pressure on our go-live date, but ultimately ensured a better quality product and stronger control environment.
In the past, we had multiple electronic banking systems to which we needed to interface. We recognised that even with an efficient internal technology infrastructure, we would add complexity and weaken automation and control if we maintained multiple interfaces. Our bank connectivity goal was to introduce simplified, standardised processes, rationalise the number of interfaces required and demonstrate industry best practice in straight-through processing. Consequently, we decided to implement SWIFT Corporate Access, so we could access multiple banking partners through a single connection, and maintain a high degree of bank independence should our banking requirements change in the future. We now use SWIFT for making payments, retrieving statements and matching confirmations.
We connect to SWIFT through a service bureau, minimising the amount of technical support and specialist skills required in-house. We have also worked closely with our primary banking partner, ING, throughout the project to perform the extensive, rigorous testing that was required before going live on the SWIFT connection. One of the key elements to the integration between SAP and SWIFT is SAP PI and the SAP middleware tool, BCM. As an early adopter of BCM, it has been essential in achieving the degree of seamless integration and electronic banking functionality that we were seeking.
Now that we have a standard banking communication platform in place, we are able to roll this technology out to access other banks and regions, such as SEB for the Nordics, and (future) banking partners in the United States, Asia and Latin America. [[[PAGE]]]
Before we started the project we ensured we had a firm mandate from the Board of Management. Subsequently the project was implemented from the top down, whilst ensuring support across the businesses through intensive engagement sessions. We have 19 business units, each of which has a different technology infrastructure and degree of centralisation. For example, one business unit has 40 ERP systems, while others have rationalised their systems portfolio. Consequently we had to prepare the businesses for the changed processes they would have to execute, whilst dealing with the integration complexity involved when dealing with disparate internal partners.
Having used the system in a live environment for a month, there are still some minor adjustments that need to be made, but these are relatively immaterial bearing in mind the scale of the project. The solution has fulfilled our expectations and we have now achieved considerable process automation and straight-through processing. Our operating expenses have already reduced dramatically, and we have been able to re-deploy resources to tasks that add greater value to the business. After some initial start-up challenges we have now realised a high level of automation in the communication with subsidiaries and a secure, scalable channel to our banks that can be rolled out across the business, including supporting multiple entities. Our new infrastructure is also scalable, enabling us to add further capabilities in the future. For example, we have already implemented an electronic trading platform (FXAll) with automatic deal logging in SAP.
We connect to SWIFT through a service bureau, minimising the amount of technical support and specialist skills required in-house.
We have learnt a variety of lessons along the way, and inevitably had some surprises. A disciplined approach to project management is essential, but there needs to be sufficient flexibility to deal with unexpected events quickly, to avoid delays that could jeopardise the overall project timeline. For us, the decisions firstly to keep our business processes within the parameters of our chosen solution, and to implement different modules in parallel, were important to maintain project momentum and reduce costs. Key business partners: ING, Zanders, SAP and BBP, our SWIFT service bureau, were instrumental to our success, and it was important to co-operate closely throughout the project. The amount of work that a banking partner needs to put into a project of this type should not be underestimated, so they need to be receptive and willing to commit the necessary resources. We were very fortunate that ING has taken our project as seriously as they have. This has been a crucial element in the timely delivery of the project and the degree of integration we have achieved.
We will undoubtedly undertake a second project phase, during which we will implement some additional system features, such as workflow management for intragroup funding. We may also implement an automated solution for cash allocation. We are already able to make payments from central treasury accounts on behalf of other entities, reducing the number of external bank accounts that we need to maintain. A solution we are also exploring is to achieve the same for collections, by receiving all cash flows into our central accounts, and allocating funds automatically to the right entity, enabling further rationalisation of accounts.
How Thought Leadership Can Reduce the Cost of Sales by Patrik Havander, Havander & Partners A focused attention on the costs incurred by the global sales and marketing processes is becoming increasingly important for corporate banks and their transaction banking departments. While the client/bank relationship remains vital, research has shown that in fact relationship selling […]
