Kathy Gibson reports from SAPInsider in Vienna – Using business intelligence has helped ArcelorMittal improve its financial performance, while saving it both time and money.
ArcelorMittal is the world’s largest steel producer, with an industrial presence in 20 countries. Arcelor and Mittal merged in August 2006 – and both of them were the result of many mergers.
As a consequence, the IT landscape was very heterogeneous while the reporting and consolidation tools were varied.
ArcelorMittal’s Patrick Tanson says the company decided to standardise the group on SAP BusinessObjects Financial Consolidation, and went live with reporting just a few months later.
Since the group is listed on the New York Stock Exchange, there are a number of regulatory issues and external reporting requirements, Tanson says. There are also significant internal needs.
Required reports, for external and internal users, include actuals, actuals and predictive, and predictive.
In 2007, the group kept most of its data in diverse tools like Excel, but over the years it has replaced these sources with a single solution.
“Today, almost all data required for the many reports – both internal and external – is collected via SAP BusinessObjects Financial Consolidation,” Tanson says.
“The result has been continuous improvement rather than a ‘big bang’.”
The path to success rests on six pillars: central teams, the stakeholders; the group reporting calendar, the actuals reporting structure, key reporting principles; and a business process management (BPM) collaboration portal.
Central teams allows for flat reporting direct from all the entities to corporate for all figures. This includes actuals, budgets and forecasts.
Stakeholder buy-in means that the same reported information – a single version of the truth – is required and used by all corporate functions and external bodies.
The group reporting calendar dictates the organisation of the daily work for many people in the company. Knowing when there will be peak days allows the team to extend support when required.
The actuals reporting structure – the monthly actuals reporting at entity level is scheduled to its due date. This can take either less or more time, depending on what month it is; while a dry run for year-end closing in December helps to eliminate problems and makes year-end much more efficient.
Key reporting principles have been put in place, allowing entities to report in local currency, although reporting in functional currency might be required in some instances. Group accounting standards are IFRS and reporting data must be entered in IFRS. In some cases, local entities may also report in GAAP, but it must be IFRS at group-level.
The BPM collaboration portal and group reporting calendar acts as a communication forum to the finance user community with everything they need to do their work, Tanson says.
Over the last eight years the group has progressively expanded the scope of data collected in the systems.
It implemented 24 different collections over the time and increased from five categories in 2007 to 24 in 2016. All of the new categories have been built in-house. About half of these categories have replaced the old Excel spreadsheets that were used previously.
“This is all we need for reporting to be successful,” Tanson says.
The journey was based on “pull not push” strategy, where the team first built a solid foundation with the first categories, and then encouraged users to make use of the tool.
Initially, it spent considerable effort on training and set up a network of key users.
Feedback from end users was also collected and translated into action. The team also encouraged users to expand their use of the system and so generated a snowball effect.
“The more data there was in the same space, the more attractive it became to add additional data categories,” Tanson says.
“That is largely how we got the support from users to roll out the 24 data categories.”
Implementing a new data collection process had to be done carefully, Tanson says. There was a lot an analysing to determine exactly what users wanted from their reports, and then how the data needed to be collected.
“There was a thorough analysis of the existing solutions and way of working (WoW) before starting the design and implementation of a new Wow,” he explains.
An important step in the implementation was designing a process for data collection that would ensure the correct data was collected, and to ensure acceptance by end users. “This ensured that we had good buy-n from the end users.”
Migrating from existing tools that were nearing end of life necessitated that a new tool be deployed. The original group cost benchmarking was developed on Cartesis Planning which had no direct successor. So Arcelor Mittal replaced it in two parts: transferring reporting and computations to the GCB Cube; then moving the data collection across to SAP BusinessObjects Financial Consolidation.
“The changeover was so seamless that the data entry platform was changed without any impact on the reporting side,” Tanson says.
In order to convince users to make the moves, though, the team made sure that exact same layout was maintained so users could simply paste or link data to exactly the same cell range. Other tools were developed to make it easy to migrate data.
Replacing the Excel spreadsheets had to be done within a short deadline. There were 130 spreadsheets, which were difficult to manage and track – “a nightmare”, as Tanson describes it.
The first step in migrating these involved identifying synergies, and creating clean databases in Excel.
Once a tool was selected for the migration, users had to then be convinced to migrate. But in the end the implementation took just two weeks over one December.
ArcelorMittal deployed SAP BusinessObjects Financial Consolidation with a SQL-based data warehouse and cubes, allowing users to combine data from different sources. This also ensures that there is one version of truth that is shared by all users.
Power users can design their own cubes, or other users can use cubes designed by the BusinessObjects team.
The project consolidated five geo segments, one business segment, 30 sub-segments and about 140 business units. These included 620 reporting entities or actuals.
In the main consolidation, there were about 530 packages, of which 130 were technical packages for splitting entities with activities in several business units.
There are approximately 1 500 users of the consolidated package, and about 400 consumers of the consolidated data.
The implementation has resulted in a reduced number of working days required for closing. It also results in flat consolidation for legal reporting; and the production by corporate of segmentation consolidation to segment business and user needs.
There are a number of non-transparent sub-consolidations, currently consisting of five pages, with the largest holding 90 entities.
Inter-company reconciliation can be done in-house based solely on SAP BusinessObjects Financial Consolidation for balance sheet, profit & loss, closing days, margins in stock (inventories) and dividends at account balance level.
The team has also started a pilot project for SAP BusinessObjects Intercompany with invoice-based reconciliation.
A number of consolidation rules are written into the main set – more than 550 rules cover a lot of special business cases and managerial treatments beside the standard rules.
There are between 6,5-million and 13-million lines in the consolidation depending on the period – and the number of lines increase during the year due to periodic translation.
The duration of actuals consolidation is now 25 to 30 minutes depending on the period, Tanson says, with the product using all the dimensions except for two.
There are about 1 200 accounts in the chart of accounts for actuals, and close to 50 controls in the package.
The system can interface with local ERP systems, with flat file upload starting from basic closing flows to complete balance sheet and profit & loss flows.
Although most of the local organisations have SAP ERP, they are often different versions so the generation of flat files is done in SAP under the responsibility of the operating unit. Data upload is also still done with Excel links.
When it comes to reporting, extraction of finance data can be done in CubeDesigner. Users can also build reports using BOXI, while Microsoft OLAP cubes can be built on top of the corporate data warehouse. There are also various add-ins available for OLAP cubes, Tanson says.
The infrastructure to run this system is sized for at least 500 concurrent sessions, with six parallel runs of large consolidations.
This is enabled with a large Citrix farm, providing virtual machines for application servers. There are also Web servers, physical database servers, and a SAN with failover to a disaster recovery centre with full storage consolidation.
There are WAN and Internet connections for 1 500 users spread over all continents, so it’s important to ensure performance, particularly during peak periods. User activity is monitored within SAP BusinessObjects Financial Consolidation, and there is also a SCOM monitoring tool located at different sites to measure the overall response or different scenarios. A DCRUM from Dynatrace measures real traffic and isolates fault domains.
A monthly service meeting is held with corporate to ensure that service levels are maintained.
The bottom line, says Tanson, is the SAP BusinessObjects Financial Consolidation can be used to collect not only finance, but a wealth of operational data as well.
He stresses that it’s important to progressively expand the scope of data collected rather than try to do it all at once.
The implementation team must complete a thorough analysis of existing WoW before starting to design of a new WoW, he adds.
Once implementation begins, it will be more successful if the team can lock segments and key users into the design process in order to ensure acceptance by end users.
The team should also be careful to correctly size the project so it can guarantee response times and not slip on its own deadlines.
Once the new system is deployed, Tanson says, the user experience can be optimised by isolating consolidation runs on a separate application server and, if Finance Excel Add-ins are used, these should have their own server as well.
