Case Study - Hanson PLC
Hanson plc (formerly Hanson Trust plc) was a British based international building materials company, headquartered in London. Traded on the London Stock Exchange and a constituent of the FTSE 100 Index for many years, the company was acquired by German rival Heidelberg Cement in August 2007. It was the world’s largest producer of aggregates and one of the largest producers of concrete products, clay bricks and ready-mixed concrete. It had operations in North America, the UK, Australia, Asia Pacific and Continental Europe and employed 24,000 people in 14 countries. It was listed on the London, New York and Australian stock markets and was Sarbanes Oxley compliant from December 2004
Need to think strategically about systems
The business driver for the project was the discontinuity between the information held in the divisions' management information systems, notable Hyperion Essbase, Cognos and SAP BI, and the information held in the Group's reporting system, Hyperion Enterprise. As Hanson increasingly became a focused building materials group it required increased analysis of the divisional operations and the disconnect between the systems, both in data and in business process, hampered effective reporting and analysis.
Expecting to choose Hyperion Financial Management as the common tool, Hanson nevertheless undertook a strategic review of what it wanted from the group's reporting systems and where it wanted them to be in 5 years time. This systems roadmap guided the requirement for a unified, centralised, flexible and intuitive system and led to the selection of Outlooksoft Everest, making Hanson only the second FTSE100 to implement Outlooksoft
Why SAP BPC?
The selection of SAP BPC (or Outlooksoft as it was) was made by a panel of potential users from the head office group functions - consolidation, tax, treasury and management reporting departments - as well as representatives from the divisions. The selection included a detailed Request for Proposal and a 2 day Conference Room Pilot presentation of a demo system specified to address Hanson's key requirements. Although Hyperion and Cartesis offered slightly more functionality in the area of statutory consolidation, the panel were surprised by how much consolidation functionality was available in Outlooksoft's unified solution - certainly as much as Hanson needed - and were won over by the power and ease-of-use of the Excel front-end, the unified model, and the flexibility to deploy the system in to other areas of the business that desperately needed information systems.
Phase I - First 6 Months
The initial design was to fully replace the existing Hyperion Enterprise group consolidation system but extending the use in to monthly management and operational reporting. This included increasing the granularity of the chart of accounts as well as bringing in additional analysis along product and regional dimensions.
On the operational and management reporting side it required submission of volumes in either imperial or metric measures and copied/converted it to both for reporting purposes. It collected volume measures for key cost lines too and collected or calculated the main KPI's.
There were 4 applications used in phase I and included an application for weekly reporting of sales volumes. The MAIN application used 10 dimensions some of them large and with multiple hierarchies. However, because 7 of the dimensions were secured it kept the end user very focused on only the dimension members they needed and made the system intuitive to use.
The system made use of the process flow menus and work status to control reporting. It was not possible to change the work status to submitted or approved unless the validation account - itself fed by many separate data validations - was zero and hence correct. A detailed report allowed easy identification of invalid data and easy navigation to the input schedule to make corrections. Finally the company or divisional FD had to complete an electronic sign off and monthly report as supporting documents to the data submitted through the system.
For those companies that had made acquisitions or disposals an additional requirement was to report data for those by acquisition. This allowed the system to then calculate organic growth, like-for-like comparatives and the discontinued segments for IFRS reporting as well as tracking acquisition performance.
As well as the standard currency translation and currency translation adjustments calculations, Hanson made use of the excellent SAP BPC functionality to set up different currency scenarios such as constant currency reporting to eliminated group performance from currency exchange rate fluctuations.
From a statutory reporting perspective the system had a full Income Statement - the system was being put in for Hanson to report under IFRS for the first time - Balance Sheet and Cash Flow. It used the DataSrc dimension to allow reporting under UKGAAP and USGAAP as well as IFRS. Any balance sheet account that required a note in the annual accounts was set up to collect the required movements and other analysis on a monthly basis. In addition the system required all acquisitions (and disposals) to report the acquisition balance sheet and post acquisition adjustments by acquisition in order to calculate the goodwill (or profit on disposal). These calculations (with extensive use of SAP BPC's own TSQL script logic) then all fed in to producing a European-style balance sheet movements matrix that then automatically calculated the cash flow statement.
The system made use of the journal module including the journal validation rules and journal member exclusion features. The system used the comments functionality to collect local descriptions of some disclosure items such at exceptional items. For JVs and associates the data was put in at 100% and the system allowed data at group level to be reported on with JV's shown in three different ways - on an equity basis, a proportional basis or on a 100% basis with minority and other elimination postings calculated automatically.
For intercompany reporting a separate application was used. This allowed companies to report their detailed P&L, balance sheet and cash flow intercompany balances in transactional and local currency against the detailed counterparty. Once the balances had been submitted it was then the responsibility of each companies to run their own mismatch report which showed all matched and unmatched balances in transactional and group currency. This mismatch report had details of counterparts' name, phone number and email address which was to be used to resolve the mismatches directly with each other. Then all that was left for group to do was "police" that this process had indeed been done. The final step was that these detailed intercompany balances were automatically transferred to a summary balance on the MAIN application and with data validations check s on both apps so that they could not get out of step.
After unit testing and UAT, CopperMan then put together a 130 slide end-user training PowerPoint and helped deliver it at sites around the world. The system went live 7 months after installation with Budget collection, ran parallel for actual data for 2 months and then was exclusively used for Q1 reporting in March 2006, 10 months after the project had begun.
Five of CopperMan consultants were involved at various times in the Hanson project. The roles undertaken included system selection, project management, design, build, report and schedule building, data migration, testing and training
CopperMan were approached for the Hanson project on the strength of their involvement in, and recommendation by, the first FTSE 100 implementation of Outlooksoft at GUS plc. In particular, it was the mix of accounting and technical skills that provides the best results. As accountants who have used systems like SAP BPC in budgeting, reporting and consolidation environments before, our consultants are able to understand the business requirements and translate that requirement in to the optimal system design. As BPC experts we also have the detailed technical knowledge to be able to optimise database performance, script complex calculation logic and handle all aspects of system delivery. CopperMan consultants offers an end-to-end service - from understanding the requirement to delivering it back to the user. And that can really shorten the delivery timescale.
Hanson initially struggled with the success of phase I. The usefulness of the system led to greater demands which, in turn, placed stress on availability (it was less than 24 hours after Israel, who worked on Saturday, logged off before Australia were logging on for their Monday morning) and performance. In addition other functions and departments whose requirements were not met in phase I such as Tax, Treasury, Risk Management, HR, Health, Safety and Environmental Reporting were eager for the system to be extended.
On the one hand, the CopperMan team worked to add more reporting functionality with new applications being added to the Application Set on average every 6 weeks (see below). On the other hand, the team focussed on ways to improve the performance of this expanding system so that the end user experience was not compromised.
Firstly a separate Economic Value Added application was added. Hanson was run on EVA evaluation and this app automatically took key P&L data and working capital balances from MAIN, applied weighted average cost of capital and notional tax rates from RATE and calculated the EVA by entity.
Next another app, DAILYRATES, automated the load of daily exchange rates from a Reuters feed, calculated weekly and monthly average rates and a year-to-date average exchange rate and fed all the relevant rates to the RATE app.
Further apps were set up to collect all the additional year end disclosure: YEAREND for items such as lease commitments for items that it was only sensible to report on an annual basis; IFRS7 for all treasury type disclosures relating to mark-to-market; SITEINFO for collecting an analysis of the type and location of all 1500 Hanson sites; MINERAL_RESERVES for analysing the tonnes of aggregate by type or reserve, by ownership etc. For MINERAL_RESERVES the tonnes of reserve was then translated in to the number of years this would serve the company at current usage levels and it was disclosure of information from this last app that was said to have alerted HeidelbergCement to Hanson's attractiveness as an acquisition target.
SITEINFO is a good example of how quickly a business process can be systemised once the initial phase has been completed. Previously the site info had been collected by someone in the centre preparing a template that was emailed to all divisions and then on to businesses. These spreadsheets were completed and, no doubt, changed. Someone at division would receive their companies spreadsheets back and would manually aggregate it in to another workbook that was then emailed to head office. More rekeying then gave the group position, which would then have to be analysed three ways and then be rekeyed in to the year end format.
It took 4 weeks from receiving the request to systemise this process before the system went live. The existing spreadsheet template was retained as it made it quicker to develop and easier for the end users to understand and it was just set up so that the input cells fed a send command to the system database. Users in the companies were then able to log on to SAP BPC to input the data and divisions were simply able to review it before approving it for head office. The system used multiple dimensions so that, when all the data had been submitted, the head office user could review and simply output the different reports required for the annual report and accounts document. A real case of less time processing the numbers leaving more time for reviewing and understanding them.
Non financial areas of the business also engaged with the CopperMan team. There was a global HR team but no global HR systems. A 10 dimensional application was developed that was fed by the countries local HR systems that gave Hanson Group sight of average ages, sex, length of service, job grade etc. and gave country managers better reporting from their existing systems. A similar approach was taken by the company secretarial department in addressing the information and reporting requirements around environmental reporting and health and safety reporting.
An application called TAXCONSOL was developed for tax planning and compliance. Each country completed a standard tax pack and when this was received by head office it could be loaded to the application where translations and adjustments could be made, along with audit trail, to output the group tax numbers
On the performance side many aspects were identified and applied that gave rise to different aspects of system performance and stability. Among these were:
- Reducing the number and depth of hierarchies
moving resource hungry EVA calculations to a separate application
- Optimal Clustered Indexing strategy on FACT tables
- Optimal light and full optimise with compress strategy
- Optimal Analysis Services partitioning strategy
use of virtual rollups with STORE_ORG
efficient use of T-SQL script with tighter data segment definition, more efficient code with fewer commits
- Use of EVDRE and multiple EVDREs to give optimal schedule and report performance
- Increasing use of Citrix connections/reducing use of https connections
Once the initial performance issues were solved, the project was regarded as a great success within Hanson. Being able to adopt a common group system had a unifying effect on the culture of Hanson. It brought the divisions closer to group and brought departments and functions working more closely with each other. Users related well to the excel interface, the rich functionality and the increased time for analysis. Indeed, at the time that Hanson was acquired, the Hanson divisions were fighting to be first to implement BPC as the replacement divisional MIS in a project that would have added another 2000 users and a new application set for each of seven divisions.