TMS Transformation at STMicroelectronics

Published: September 01, 2008

Giuseppe Amodio
Head of Financial Risk Management, STMicroelectronics

by Giuseppe Amodio, Head of Financial Risk Management, STMicroelectronics

The treasury activities of STMicroelectronics (ST) are centralised at its headquarters in Geneva, Switzerland under the responsibility of the Corporate Treasurer. Regional Treasury centres are located in Singapore (which covers the entire Asia Pacific and Greater China operations), France, Italy and United States.

As a result of its global activities, STMicroelectronics is exposed to financial risks, the most major of which are foreign exchange exposures and interest rate mismatches. ST’s revenues are mainly in USD (the primary currency in the semiconductor industry) with 40% of costs in EUR. Due to its industrial and marketing activities, ST also has some limited exposures to other currencies, especially SGD and CNY.

In anticipation of evolving treasury needs, we looked for a TMS with sufficient 'headroom' to accommodate our potential future requirements.

ST’s interest rate risk exposure arises from the mismatch between its cash investments, which is invested in floating rate instruments, and its fixed financial liabilities. The main fixed interest rate liability is the outstanding 1.50% 2016 convertible bond. ST has also floating rate liabilities in USD (mainly European Investment Bank’s 8 year amortising R&D loans) and EUR (mainly the 2013 Floating Rate Note). Part of the fixed interest liabilities have also been swapped to floating rate and hedged with fixed assets to further reduce the assets and liabilities mismatch.

ST generated a net operating cash flow of $840m in 2007 with $3.5bn gross liquidity and a net positive financial position of $1.2bn as at 31 December. In 2008, the gross cash position has decreased because of M&A activities and a share buy-back program.

Before the implementation of the new Treasury Management System (TMS), treasury activities were supported by SAP Treasury module, which is ST’s ERP and internally created spreadsheets used to complement SAP due to the complexity of some financial instruments. Spreadsheets were also used for cash management and cash forecasting.

Documentation such as payment orders and deal confirmations were produced in hard copy and authorised with physical signatures. Confirmations were sent to counterparties via fax and payments transmitted to our banks using the relevant formats for each country, eg. IBG in Singapore, CCD in USA and MT100 in Switzerland.

TMS transformation

ST acknowledged its treasury resources were not being deployed as efficiently as they could be and that improvements could be achieved in the automation, control and visibility of our processes. Consequently the decision was taken to review our treasury processes and the technology used to support them.

Our aim was to connect each task seamlessly (Straight Through Processing - STP) as well as automating the transaction workflow. ST decided to extend the degree of treasury centralisation by implementing an in-house bank model and replace our local banking solutions with a single connection to SWIFT. The most important element in achieving these ultimate targets was to select and implement a specialist TMS which would be used globally. ST’s decision process was driven by needs of the front office and risk management users since these two areas would have the benefit of the most immediate improvements. [[[PAGE]]]

Furthermore, in anticipation of evolving treasury needs, ST looked for a TMS with sufficient ‘headroom’ to accommodate our potential future requirements. We were keen to reap the benefits as quickly as possible, so we set ambitious objectives for completing the implementation of our new treasury processes and technology.

We identified the investment in a TMS as a core business priority and therefore the budget was allocated accordingly. One of the major constraints was to dedicate resources since, other than a ST IT project leader, we did not have other ST employees deployed full-time on the project. With little automation in our existing processes, however, and broad recognition of the potential benefits of a new system and structure, there was great enthusiasm which helped to build momentum in driving the project forward and achieving project milestones.

Selection process

ST embarked on a TMS selection process independently, without the assistance of an external advisor. We first reviewed the various TMS solutions available, which are offered by a limited number of specialist providers (mergers which occurred after the start of the project further reduced the number of suppliers).

The steering committee played a vital role in ensuring that decisions were made on a timely basis and the scope of the project did not extend beyond our original plans.

We did not find major differences between the front-office capabilities offered by the best TMS providers, whose vendors were focused on providing a solution with fully integrated capabilities across all the various treasury activities and delivering a high quality, successful implementation. Ultimately, having shortlisted two of the major providers, we made our final decision according to a set of key criteria: in particular, the solution needed to provide powerful risk management tools and a high level of integration. We also needed to be assured of other successful projects with clients with comparable treasury requirements to ST, and a rapid implementation project. Based on these criteria, we chose to implement WallStreet Suite provided by WallStreet Systems.

Solution advantages

We saw a number of advantages in this solution. All ST’s treasury activities would have been combined in a single database, resulting in a highly integrated system. The supplier provided a standardised approach to the system setup (so-called Factory Approach), which might otherwise have been time-consuming. This enabled us to speed up the implementation with confidence in a committed delivery deadline. As the solution was structured in a modular way, we could also structure the implementation into a series of project phases, allowing us to take rapid advantage of each module of the system. The TMS had standard interfaces with our key external applications, namely Reuters Dealing 3000, SWIFT and SAP, and the reporting and confirmation modules were particularly user friendly. We had received positive feedback from other major corporates which had adopted a similar solution, but as ST was a pioneer of the Factory Approach, we could not, of course, gain any insights into this particular means of implementation.

Implementation approach

ST structured the implementation process into the series of inter-related elements shown in Fig.1 with an emphasis on ST’s specific implementation requirements:

Project scoping

A major decision was to split the project into two phases, the first of which would incorporate deal processing, collation of static data, risk management, chart of accounts and accounting rules definition and integration with Reuters Dealing 3000 and SAP. The second phase would include cash management, in-house banking (IHB), and the connection to SWIFT.

[[[PAGE]]]

We scheduled five months for the first phase, including the definitions and static data which would be required for phase two so we could move quickly to it as soon as the first phase had been completed. In fact, we were live on the core treasury risk management module on a standalone basis after two months in our Geneva and Singapore treasury centres (covering the majority of ST’s front-office activities). In order to be able to replicate the implementation easily in all the remaining local treasuries, we put in place quite straightforward treasury processes and kept our structures as standardised as possible.

Critical to the success and timely delivery of this project was the involvement of all users in defining the system processes, which gave them the opportunity to become familiar with the system, and ease the transition as the system was moved into live operation. Furthermore, the steering committee played a vital role in ensuring that decisions were made on a timely basis and the scope of the project did not extend beyond our original plans, therefore avoiding any material impact on our timescales.

Risk assessment

A project of this type, which includes the transformation of our business processes as well as implementation of a new system, carries a variety of risks, not least the amount of resources required and the timescales. We tried to assess in detail the amount and type of resources required at each step of the project, and we highlighted as a key factor the importance of IT resources and assistance both during the system implementation and beyond our ‘go live’ date.

By collecting the information required for phase two while phase one was still in progress, we could ensure that the second phase followed on seamlessly.

Another aspect of our risk assessment was to focus on internal controls. When processes are manual, control mechanisms are fairly straightforward, despite their obvious limitations. However, when automating our treasury processes, we needed to consider in more detail where the potential weaknesses existed.

Information collection was another key activity, and by ensuring that all the necessary information we needed for the new system was available, we could more accurately tailor each stage of the project and allocate the appropriate resources. For example, by collecting the information required for phase two while phase one was still in progress, we could ensure that the second phase followed on seamlessly with the right resourcing already allocated.

Establish controls

Having conducted the risk assessment, we were able to establish a framework of controls to support our process automation. This included controls on a variety of levels. For example, in a highly automated process where the Front Office dealer inputs a deal which then automatically generates accounting entries, user rights were defined to control the level of access appropriate for each type of user including authorised approvers. We set up a Standard Settlement Instruction (SSI) system both to standardise our payment instructions, with rules to route payments to these bank accounts and to automate the posting for financial payments to reduce the risk of errors. We also set up controls over the data which is passed automatically between WallStreet Suite and SAP.

Another element of control related to the management of our external risks, such as counterparty risk. We implemented system controls in this area, taking advantage of the powerful and automatic tool which would allow us to be compliant with ST Treasury policies. [[[PAGE]]]

Establish revised procedures

Another important consideration during our TMS project was to define clearly our new procedures for treasury processing and the way in which the system would be managed in the future. With an integrated system impacting on Front Office, Back Office and Accounting, we set up stricter processes for amending or updating our static data, including settlement instructions and business structures, set up a change control process to manage the way our procedures develop in the future and also periodic reporting to ensure data consistency in the system.

Testing and ‘what if’ analysis

The testing period before the system was used in live operation was a critical one both in checking the integrity of the system and scrutinising the validity of our processes. As well as reconciling financial results, we also ‘stress tested’ the system to determine what would happen if certain events occurred. For example, we looked at the outcome of incorrect deal input or limit breach. We looked at potential weaknesses, and the integrity of the processes and system controls surrounding these risks. We also looked at IT testing, such as working through the impact of an IT crash scenario and established recovery and back up procedures in the case of system or interface failure.

Achievements and challenges

We completed phase one of our project with no material delay, and in order to ‘go live’ promptly on the new system, we decided to include only ST’s major treasury centres, which cover more than 90% of the Group’s financial activities. This approach allowed us to take earlier advantage of the system for some elements of functionality, so we were able to identify benefits within two months of the start of the project.

Processes are now highly automated, resulting in a massive reduction in manual input.

The combination of a new system and revised processes has resulted in material benefits to ST’s treasury activities. We now have far greater visibility of our treasury operations and with a diversified and multinational presence, it has been valuable to establish real-time visibility and control over ST’s treasury activities with the aim to extend this shortly to 100% of ST treasury activities. Processes are now highly automated, resulting in a massive reduction in manual input. Our external and internal controls have greatly improved and we are now able to measure and manage the performance of financial risk more effectively.

A project of this scale and complexity will inevitably bring some challenges. We have found the implementation of SWIFT very time-consuming and complex so we are not yet able to use WallStreet Suite for payments. Furthermore some processes still need analysis, such as: automated bank account reconciliation, cash management for certain Far East countries where standard communication formats are not available, and in- house banking where we have not yet determined how to interface our current SAP module with the newer one. Compared with our overall achievements however, the project strengths have outweighed the outstanding challenges.

We would group our primary achievements into a number of key areas:

  • Standardisation - We have established a rapid deployment strategy for extending the use of WallStreet Suite to all the remaining ST legal entities and, in a diversified and complex organisation, we are now confident in managing ST’s frequent organisational changes, such as developments in entity structures, mergers and acquisitions etc
  • Static data - We have achieved significant integrity in the set up of our static data and cash management structures, and the SWIFT incoming interface (e.g. for importing bank statements in MT940 format) is now operational.
  • Real time control - We have extensive visibility over group figures, including ST’s liquidity position, FX position etc. On top of this, we now have the tools to measure and manage our financial risks more effectively, including counterparty limits.
  • Straight Through Processing - We have already been rewarded with significant time savings, allowing resources to be dedicated to the second phase of the project. We have implemented partial functionality in cash management, such as FX netting and intercompany lending. There is also the perception amongst users that the efficiency of ST’s processes has been greatly improved.
  • Accounting - This was a critical area for us on which we are now live. Going forward, the accounting structures should require limited maintenance since common accounting rules are already defined for all the subsidiaries and the bank account rules can be replicated easily across entities.

Sign up for free to read the full article

Article Last Updated: May 07, 2024

Related Content