2 IT Mergers, 1 Standard Approach

Stefan Horstmann, Vaillant GmbH's group supply chain director (Photo: Horstmann)

SAP.info: A series of mergers and restructurings have led to significant growth at Vaillant in recent years. What impact has this had on IT?

Stefan Horstmann, Vaillant GmbH: There have been two major events in our company’s recent history that have posed a particular challenge for IT.  In 2001, we took over and merged with the British Hepworth Group. Our workforce and our revenues doubled, and the number of IT systems increased twenty-fold. Instead of one brand, we suddenly had eight. That means a massive increase in complexity. Since then, we’ve extended our production capacity, acquired former competitors, increased our market share, and expanded our product portfolio.

In 2006, Vaillant merged with a Turkish manufacturer, which had a significant impact on the ERP environment in terms of its size and degree of complexity. We also gained an additional production location through the merger. At the same time, we were continuing to set up and acquire companies, all of which we needed to integrate onto our existing ERP platform.

What was the impact on the SAP system?

At the start of the 2001 merger, we concentrated on purchasing and development rather than on IT.  Then, in 2003, we decided that it was time to consolidate our IT setup and to start rolling out the systems deployed at headquarters to the other locations.  To do this, we devised guidelines that focused on the organizational structures and the processes.

In the first wave, which lasted three years, we migrated the larger locations onto the system. This was followed by an adjustment phase in which we investigated what improvements we needed to make. From the technical viewpoint, we used a Combined Upgrade and Unicode Conversion (CUUC) to migrate to an SAP ERP 6.0 environment and get ourselves fit for the future.

The second wave focused on migrating a number of smaller subsidiaries and the Turkish parts of the business to SAP. Due to the extensive process landscape, complexity, and size involved, this project was one of our toughest challenges. We’re currently in an intermediate phase in which we are preparing to approaching the third roll-out wave to the remaining subsidiaries.

You invented the “standardization of standardization” concept, which you call SAPLIGHT. Can you explain the idea behind it?

You have to see the entire product, not just the system. SAPLIGHT is a pre-prepared, consolidated system in which the processes are already mapped ­– including documentation, the administrative background and management methods, tools, and templates. The success of the product lies in the fact that it only needs to be localized. A ready-to-use kick-off presentation, along with all the documents, process descriptions, and system-setting descriptions, is available on a DVD. We chose this approach deliberately, because it gave people something that they could – quite literally – touch and lent the migration process a kind of product-like character. We will continue to develop this topic and add more features as we go. We’re planning, for example, to map our training materials via e-learning methods and to include additional modules such as SAP WM (SAP Warehouse Management) to the SAPLIGHT kit.

Next page: Blessing and a curse

Would you recommend this approach to others?

Enterprises that want to grow continuously over time should certainly take a look at our approach. We set out by asking ourselves how we could find a standardized way of integrating newly acquired or merged companies into the existing environment. It’s important to take the time to plan out the entire scenario in advance so that you can gather momentum and speed when you come to execute your project.

During your presentation, you spoke of a blessing and a curse. Could you explain what you meant?

I was referring to the single client system. Because we operate jointly on a single core in our process landscape, we enjoy the blessing of not having to worry about harmonizing things like material numbers. 4711 is 4711 in every location. End-to-end processes can be mapped more easily. And many functions that are used within our production network are only possible because we have a single client system. That’s a very positive thing and that’s why it’s a blessing.

The curse, or challenge, lies in the fact that, when changes take place, we have to make sure that we can all continue to exist and work on this single core.  We need robust change management processes in order to ensure that we take a structured approach and achieve a high level of quality in implementing changes.

How does that work in your specific case?

Change management is one of the most challenging topics. The world of IT and business processes has developed at break-neck speed in recent years and we’re definitely still on a learning curve in that respect. But one thing has not changed much at all: and that’s the anxiety and, in some cases, the fear that people have about change. The idea of changing the way they already do something makes people feel uncomfortable and insecure. You can only change this situation by communicating and by addressing the balancing act between standardization and individuality.

How did you proceed?

We kept to a step-by-step approach and documented each step as proof. We take this proof with us to the next country, to the next rollout.

Another essential point to bear in mind is that you can’t make a proper assessment until the system and the processes have had time to reach a stable state after the rollout. The go-live phase must be followed by what I call a “running-in” phase. In the same way that a piston ring needs to “settle” into the cylinder wall in a new engine, new processes need time to fit snuggly into the SAP system. The organization is like the piston settling into the cylinder so that the entire engine, or system, can run smoothly and efficiently. And don’t forget that an engine can’t run without a lubricant. The lubricant in this scenario is communication.

Once the system is up and running, you need to go back to the location to gather feedback.  This feedback loop is often left out. But it is a vital element in assessing the success of a project and forms part of the communication strategy for the next project. I would recommend everyone who is planning an SAP roll-out program or is still in the middle of one to include the feedback step.