Imagine this, a CEO of a large German petro-chemical business is facing opposition and skepticism on delivering his plan for building ‘one business, one team’. 

It’s not surprising, as the company in question was highly complex, with over 60 locations worldwide and seven different SAP systems, with every region and even location doing things their own way. Each was effectively a little kingdom with their own financial controllers, local CEOs and data driven power houses. Any kind of change poses some risk and after the Bhopal disaster, petro-chemical companies leadership teams had to take personal responsibility for their decisions, actions and safety in general. 

Therefore, no one wanted or was willing to change. Besides, they didn’t see any need. The business was extremely profitable, year in year out, and consistently delivered a very welcome financial contribution to its holding company.

When day to day working became almost impossible, I was brought in.

As time went by and the reality of the program was beginning to hit home, the CIO encountered a big problem. He had decided to roll out the new SAP system into the US first, with the idea of gradually working his way around the world. The first roll out day was less than a year away and his US roll out team were pushing back so hard on his central IT team that day to day working had become almost impossible. Each team’s leader being as inflexible as the other. It was at this point that I was brought in. 

When two children start to fight, a sensible cause of action is to re-focus their attention on to a new challenge, one where working together would be easier and beneficial.  What worried me the most was not so much the two fighting leaders and their teams but how could we ever know when the new system would be ready for implementation?  

The IT teams said that all the business needed to do was to trust them. The business teams said that the IT teams had no clue about what really happens in the business, and they should never be trusted. A new way forward was needed.

Introducing ‘Organizational Readiness’.

In one of my previous assignments, I had started to develop a self-certifying system of change and transformation readiness. It had worked rather well, albeit only on a small scale. My distraction therefore was focused around one question: “Forget about everyone else, how will you know when you and your people and your technology will be ready to implement a planned change?” 

This went way beyond IT’s existing change control processes. It shifted the emphasis away from IT to the end-user. If the end user felt confident that their data was clean and that they could work on the new systems, in the new way, and if the IT team was confident that their systems were stable and ready – then what could possibly go wrong?

The new ‘OR’ methodology, as it became to be known, was adopted at the very highest level of the business, with each member of the board of directors taking the necessary responsibility and asking the question to their leadership teams, who in turn trickled it down through the entire organization to the administration and factory floor employees. After all, if a site had electronic locks for entry to the plant, how would we know if the new badges would work and let them in on go-live day? 

Making a difference

By working backwards from this question, while managing all the program’s communications and building trust, the organization found their own solutions to the challenge. These amazing employees were now using their creativity, knowledge, and skills to come up with well documented and tested, self-certifying systems that gave confidence not only to their bosses but also to each other.

Over a period of five years, phase by phase, the entire organization moved on to one single SAP system. Finance was moved to a single location and the CEO finally had his ‘one business, one team’.