Log In   |  Register Free Newsletter Subscription
Skip navigation
Zibb
Subscribe to Manufacturing Business Technology
FirstLight 
Email
Print
Reprints/License
RSS

Acquire without abandon

World's largest steelmaker must balance benefits of standardization with need for pragmatism

By Malcolm Wheatley, senior contributing editor -- Manufacturing Business Technology, 2/1/2006 12:00:00 AM

With a growth curve that began spiraling skywards in 1995, Mittal Steel rose from humble origins in Calcutta, India, to become the world's largest steel producer. Headquartered in London, the company reached the top after taking over U.S.-based International Steel Group (ISG)—parent company of the Bethlehem, LTV, and Acme steel businesses—in late 2005. According to Forbes magazine, the move made Chairman and CEO Lakshmi Mittal the world's third-richest man.

Best known for its high-profile acquisitions of unwanted steel mills in the former Soviet bloc, Mittal operates mills in almost 20 countries, including France, Algeria, Germany, South Africa, China, Mexico, Canada, and the U.S.—where the ISG acquisition complements Mittal's 1998 purchase of Inland Steel. The pace of growth, which saw 100,000 employees added to Mittal's headcount in just two years, is breathtaking.

In 2004, the year before buying ISG, Mittal acquired four major steelworks and more than 100 companies, involving 30,000 employees in Poland, a factory each in Bosnia and Macedonia, and four plants in South Africa with a headcount of 11,000.

Mittal's business model is uncompromising: buy the business, parachute in seasoned troubleshooters, invest in efficiency improvements, cut costs, raise quality, and make the grades of steel that customers actually want—instead of, in the case of companies from formerly communist countries, grades that most easily meet government-mandated production targets.

This model does raise some awkward IT questions. To name just a few: Can such a sprawling—yet fast-growing—business empire create a unifying enterprise application infrastructure? How can such an ambition be reconciled with keeping a tight rein on costs? If such a single infrastructure is neither affordable nor desirable, what can be done to avoid the chaos of an IT Tower of Babel?

Pragmatism rules

Answering these questions forced Leon V. Schumacher, Mittal's CIO, to adopt a fiercely pragmatic stance. He recognizes, for example, that the goal of a single companywide enterprise system is unlikely to be met any time soon. "As long as the company continues to make acquisitions as it has been doing, we will never be in a position to have a single system," he says.

The issue isn't so much keeping up with the pace of acquisitions as the nature of the acquisitions themselves. Moving into Algeria, for example, involved taking over a business that didn't have reliable electricity, whose workers hadn't been paid for months, and where levels of literacy and computer skills were low.

Even in more advanced economies, the challenges can be considerable. "Poland was the most bureaucratic environment I've ever seen," says Schumacher. "There were pieces of paper everywhere: it was incredibly cumbersome." IT systems existed, all right—the trouble was there were more than 50 of them, loosely connected, addressing different issues, and with manual processes in the gaps between. Mittal's Romanian operation had no fewer than three e-mail systems, each intended for different layers of its hierarchy.

Schumacher says Mittal's approach to enterprisewide integration looks something like this: "First, have as few systems as possible. Second, replace existing systems only if there's a business case for doing so. Third, standardize, centralize—and then, maybe, outsource."

From the infrastructure perspective, the goal of having as few systems as possible is nonnegotiable. Mittal has a single e-mail system—Microsoft Exchange—with one central active directory and a single enterprisewide login. "Everyone has the same firewalls, and everyone has the same servers," says Schumacher. "There's a standard, and everyone sticks to it."

But it's a standard built on pragmatism, stresses Schumacher. The adoption of Microsoft Exchange, for example, was predicated upon it being already the most widely deployed system at the time the decision was made. "If I'd found that 60 percent of the systems were Lotus Notes, then today we'd probably have Lotus Notes," he says.

SAP has been selected as the enterprise application backbone for equally prosaic reasons. Not only do about half the companies within Mittal already run SAP in some form, notes Schumacher, but for a company of the steelmaker's size, "If you need an ERP system, you're pretty much going to pick SAP."

However, plants are not forced to abandon legacy or non-SAP ERP systems without careful thought. "We introduce SAP where it makes sense to do so," explains Schumacher. "There has to be a business case for the change—and if a company is managing perfectly well with its existing system, there likely won't be one."

When Chicago's Inland Steel was acquired, for example, the systems were judged adequate. On the other hand, if a new acquisition's systems are plainly wanting, or if integration with the rest of Mittal is problematic—especially with respect to financial accounting—then SAP becomes the order of the day.

But which SAP? It's a question that tests to the limit the second and third tenets of Schumacher's strategy—replacing systems only if there's a business case, and then standardizing and centralizing them.

While a substantial portion of the company does run SAP applications, the software in question ranges from release 3.1H to release 4.6C—a factor that "doesn't exactly make for simple interface connections," notes Schumacher wryly. Worse still is the number of instances of that software: the company's South African operations, for example, has five. "When you have that many instances, getting it back to just one is not an easy undertaking," he adds.

Three-pronged strategy

But the Mittal approach to the problem isn't to kick off an expensive upgrade process to bring plants onto a common release. The lack of a business case precludes this option, says Schumacher: in other words, if it ain't broke, there's no ROI in fixing it. Instead, he explains, the way forward is by means of a three-pronged strategy.

First, work is under way across the company to harmonize data structures and definitions. "We want at least to reach the point where our systems are as similar as possible, so that we can fully exploit the benefits of integration," says Schumacher.

For example, if account views and material definitions have the same structure across the company, not only is it easier to make comparisons and generate reports, but having a standard template makes it easier to roll out applications across the group. Ultimately, he says, the goal is one data structure and one system of reporting.

Second, new rollouts of SAP within Mittal seek to further leverage this standardization through centralization. "We're aiming for as few systems and instances as possible," says Schumacher. For example, a coke plant will soon be added to the system underpinning the company's four mills in Poland, followed by two Czech and three Romanian mills—all running on a single instance of SAP.

Mittal's commercial business model calls for handling international sales through hubs. For example, a few years ago, the company's Dubai operation was a small sales outlet. Now it is a major sales hub, handling the lion's share of the region's export business.

A single instance of a trading system links Dubai and Mittal plants in Romania and Kazakhstan, enabling Mittal staff in Dubai to receive a request-for-quote, submit a quotation, receive the order, and send it to a plant, where it is dispatched. Ultimately, says Schumacher, a similar hub will be located in North America, linking mills in the U.S. and Western Europe to a trading system that will sell their output.

The final prong of the "standardize-and-centralize" strategy rests upon standardizing new instances of SAP on a single release—mySAP Business Suite. This includes SAP's core modules—financials, materials management, sales & distribution, quality management, warehouse management, and production planning—Schumacher explains. In addition—either due to special circumstances, or decisions made prior to acquisition—Mittal operations in some countries have deployed SAP's human resources or planning modules.

No SAP MES

What Mittal has not deployed, stresses Schumacher, is SAP's manufacturing execution system (MES) capability—about which he says, "A lot of people have gotten a bloody nose trying to get SAP to do MES and scheduling—and it isn't a functionality that SAP really has." Nor will SAP's Advanced Planning & Optimization module—in use in the company's German operations—make the cut in Schumacher's book. "It's planning, not execution. We need genuine MES with execution," he says.

For many years, the perception was that SAP had little or no interest in making serious inroads on shop floors—although observers note its more recent acquisition of manufacturing intelligence vendor Lighthammer and its MES-oriented partnership with Siemens, announced in August 2005.

"MES means different things to different people," says Sudipta Bhattacharya, SAP's senior VP of manufacturing and product life-cycle management. "We don't claim to offer a solution for every customer in every industry. Instead, we leave it to customers to be the best judge of what they need. They must decide for themselves what MES functionality they want to get from SAP, and what should come from other partners." In Mittal's case, the partner in question is Broner Metals Solutions, selected by Mittal in August 2005 after what Schumacher characterizes as "an extensive review of the marketplace." Functionality from Aspen Technology may also, in due course, form part of the solution. "We'll review, pilot, and ultimately make a recommendation," says Schumacher.

It's not difficult to pin down the cause of Schumacher's apparent concern over the MES issue. "The interface between the MES layer and the ERP layer is not a trivial one," he stresses.

Yet ironically, the biggest barrier to the standardized enterprisewide application structure that might ease tackling the issue remains firmly outside Schumacher's control. When is the breathtaking pace of acquisition going to slow, giving IT a chance to seriously tackle some of these plumbing questions?

"I've no idea," says Schumacher, grinning. "You'll have to ask Mr. Mittal."

Email
Print
Reprints/License
RSS
Talkback
Reed Business Information Resource Center

Featured Company


Related Resources

Advertisement

Related Microsite Content

Related Links

More Content
  • Blogs
  • Webcasts
  • Podcasts

Sorry, no blogs are active for this topic.

VIEW ALL BLOGS RSS
  • Enterprise PLM


    Is your company ready for Enterprise PLM?

    Enterprise product life-cycle management (PLM) encompasses nine business processes—among them the much-embraced Design for Supply and Cost. This podcast sets up the relationship between PLM software and Enterprise PLM processes in basic terms, including the bonuses found in time-to-market and product quality.

    Sarvesh Jagannivas
    Speaker: Sarvesh Jagannivas
    Vice President of Marketing for Oracle’s Agile PLM software group
    Sidney Hill
    Moderator: Sidney Hill
    Executive Editor of Manufacturing Business Technology
    Hear It Now

Advertisement
Wonderware
NEWSLETTERS
Mid-Day Report
Innovation Strategies
Intelligent Manufacturing
Lean Enterprise



Please read our Privacy Policy

About Us   |   Advertising Info   |   Site Map   |   Contact Us   |   FREE Subscription   |   Affiliate Links   |   RSS
© 2009 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy
Please visit these other Reed Business sites