When the Cloud is a “Consequence” and Not a Cause

Bert Odinet is the Global CIO at Freeport-McMoRan Copper & Gold. A Fortune 500 company, Freeport has operations in the North America, South America, Europe, Asia and Africa. Freeport is the world’s largest publicly traded producer of copper and molybdenum. And it’s the single largest taxpayer in Indonesia, where it owns the world’s largest copper and gold mine in terms of recoverable reserves.

I cite these statistics to show the scope, scale, and complexity of Freeport’s operations.  In 2007, Freeport acquired copper producer Phelps Dodge. Major acquisitions almost always involve major integration efforts, and Bert’s role as CIO made him a key player in the process.

In this case, the timing of the acquisition and the subsequent need for an enterprise-wide integration process, led the company to make what I believe were some truly inspired choices. Here’s the story in Bert’s own words:

Both companies were wide spread geographically. The combined business had operations on every major continent. We knew that we had to globalize our processes.  As we thought about how to do that, we started looking at all of our core back office systems.

When we looked down the silos of the business processes — whether it was HR, commercial or supply chain — they didn’t necessarily fit very well.  We didn’t have one solution that would scale for everyone.

A new ERP system seemed like the wisest choice but there were other factors, such as legacy infrastructure and applications.

Our hardware platform was way late in its life cycle, especially on the server side. The chip set was getting old. We knew we had to port the core operating system and the applications. It was the equivalent of replacing the engine and the transmission in an old car. At some point, it makes more sense to buy a new car.

We also wanted to get out of the data center business, which meant doing a data center migration. When we looked at everything we needed to do – implement an ERP, develop a new hosting platform, and migrate the data center – it all seemed like too much to accomplish using traditional approaches.

Now the story gets really interesting. Instead of doing it the old-fashioned way, Bert and his team decided to host the new system in a private cloud. In addition to saving money and avoiding the headaches of buying new hardware, their cloud strategy would greatly accelerate the pace of the projects. Bert’s previous experience with mainframe-to-client/server conversions back in the 1990s gave him the confidence and the knowledge he needed to move forward with the cloud option.

The guiding principles are the same. If you can quickly provision an environment, then you have a lot more options.  You can have multiple versions running at once. Each developer and each testing group can run different versions.  So the planning and scheduling of a giant integrated project becomes much simpler.

In a typical ERP project, you might be limited by sheer physical resources to seven or eight environments; if one group is testing something and they want to take a checkpoint and go back to the data as it existed two days before, then everyone else has to take that checkpoint, too.  That requires an immense amount of forward planning.

Creating multiple environments in the cloud takes coordination, but it also gives you a lot of freedom, which then allows you to accomplish things you couldn’t ordinarily do.

A perfect example was in our conversion testing.  We had three environments running in parallel, with the same data.  Environment A was the first run; environment B followed it by several hours and environment C followed that one by a few more hours.  The team would run the conversion program for a few hours in environment A and when we found we had problems, we could fix it in environment B before it ran into those problems.  In the old model, you used to have to take a checkpoint, fix your problems, restore the data, you lose a day or so getting back to that point.  Then you have to re-run those jobs all over again — only to find out that you had another problem!

The goal, says Bert, is eliminating the interdependencies.

As these projects scale up, they become more and more complicated.  The larger the system is, the more modules and the more people involved — it gets exponentially more complicated and more expensive.

In an ERP implementation, you might have 300 people on the project team. If you need to keep all of them in sync, you will need to do a lot of upfront planning. But if everyone is free to do their own thing, you can do a lot less overall planning, and the project will go a lot faster.

This will give you the time to do more testing and really make sure the data is clean. Remember, this isn’t just about the project schedule – it’s also about what happens after you cut over to the new system. There’s a huge difference between being 99.99% ready and being 98% ready. With 99.99% you have a smooth stable system. With 98%, you have a mess that rapidly becomes very difficult to manage.

From Bert’s perspective, the cloud was “a consequence” – a means to an end, not an end in itself.

The ERP system doesn’t even know that it’s running in the cloud. For us, the cloud enabled an important business process transformation that, in turn, enabled the company to move forward more quickly. The cloud doesn’t drive our business decisions – but it’s helping us achieve our business goals, faster and more economically.