The ERP Dilemma

The reactions range from dismay to

bewilderment. Why is the ERP roll-out taking so long? Why the huge cost over runs? And

when we're done, what will we have? Part of the confusion is that ERP and reengineering

are only loosely related. It is the chemical industry which has bound them inextricably

together. The reengineering project grew out of chemical executives' desire to gain

control over the ever-more complex management of a global business through standard

business practices and shared information.

The ERP system was brought into the

equation as the vehicle for forcing all sites to conform to common practices and to

simplify the data sharing. The result? ERP implementations are taking 'forever' to

complete. Why? Because reengineering is a complex and time-consuming problem to tackle.

And, for some, the ERP tool does not provide the ideal functional fit for the operational

side of the business. However, the problem is a little more grave than this. All

industries these days must recognize that time is of the essence. Changes in the markets,

products, competition and technology-all must be detected early in their cycles, and the

corporation must move to leverage any and all changes to its advantage. The reengineering

focus should not be to 'finally get it right' but to recognize that it will continue to

change over time-most likely before they finish their reengineering projects and the

so-called ERP roll-out.

Which one is the question?

"ERP or reengineering? Which

comes first?" My first reaction is, "What a nonsensical question." The two

ideas-the two projects-have very little to do with one another and yet seem to be

inextricably intertwined. Reengineering should be a project which assesses the corporate

strategies, determines the proper tactics and transforms the corporate business processes

to align all parts of the enterprise in a new direction. ERP is a software system which

provides information in support of these business processes. By looking at the history, in

generalities granted, of how these two projects came to be looked almost as one, we will

see how we got off the track-and may be some ways to get back.

ERP and reengineering have become

inter-woven together because of the chemical industry's strategies and tactics in trying

to solve another problem. But it won't surprise you to know that I don't think the problem

was, in the beginning, either ERP or reengineering. The problem the chemical industry was

trying to solve was: how do we gain control over a global business which is growing more

and more complex with each turn of the wheel? That is certainly a problem which must be

wrestled to the ground, and the sooner the better. But many elements have come into play

here to get us to the point where ERP and reengineering are being used, in some instances,

almost synonymously.

A struggle for control

Where does control at the executive

level come from? The answer seems fairly universal-access to timely and accurate

information. What kind of information? Financial information first and foremost. But,

financial data is summarized data, symbolic of all the detailed information of the total

operations from PLC data stored with data historians to production schedule history and

shipping records. As pressures mounted each week to take difficult decisions faster and

faster, the need for more concrete data-in reality for the assurances that the symbolic

data was completely accurate-drove most chemical companies to question their information

systems. Were they getting all the information they needed from their vast, global

operations?

The 'timeliness and accuracy' mantra

was quickly taken up by ERP vendors who saw this as a wonderful opportunity to spread the

'gospel of integration.' Without integration, their story went, how would the executive

ever have quick access to the information which they required? The vision was appealing to

many. One CFO even used the example of 'drilling down' into purchasing records in remote

locations when specific accounts in the corporate divisions exceeded their budgets. The

fact that no CFO has (or should have) the time to do this level of detailed checking

seemed to be lost on him. Most CFOs would simply pick up the phone or nowadays send an

email and ask the local controller what was going on.

Nevertheless, the integration gospel

spread. I should state here that I am not against integration if by that we mean,

"the easy access to and sharing of information throughout the enterprise." But I

am more ardent about the usefulness of this information. Is it accurate? Does it reflect

the realities or the operation? What I am against is, the belief that in order to have

this easy access to and sharing of information, there is a need for a software from the

same ERP vendor every where, for everything, for everybody.

Once it was decided to have the same

software everywhere for everything for everybody, other problems began to surface which

seemed to block the path to easy access to information. Different sites had different part

numbers for the same products, different formulations for the same end-items and different

allocation methods for calculating product costs.

First of all, at the data level, how

would information ever be consolidated? How would users ever understand the information

they were looking at, if all of a sudden they were in another computer system and the part

numbers were different? Secondly, the executives were beginning to understand that

inconsistencies in business practices were thwarting efforts to compare performance

between sites.

Reengineering introduced-but off

target

So suddenly, reengineering projects

started defining consistent business practices throughout the enterprise. The vision from

management was that 'world-class' business practices would be defined and agreed to. Every

site would adopt them. The business would jump ahead of the competition because each and

every site would be performing each and every function with 'best in class' precision.

Sounds good, but it's off the mark.

The vision and the resultant

reengineering project is founded upon a false assumption: that there is a final answer.

There is no final answer. These are the very best answers of the moment. But in the next

moment, the business climate changes, the customer's demand changes, and the best answer

of yesterday needs to evolve to meet the new challenge.

Transformations of any scope are

difficult and these reengineering projects-taking on the redefinition of the whole

enterprise-are mammoth tasks which seemingly take forever. The dilemma is that by the time

you define the 'best practices' of the moment and drive the total reengineering project,

the world will have changed and your 'best practices' now implemented as the final answer

could already be obsolete.

Reengineering is a very good idea in

this world of fierce global competition. However, the reengineering project should be

reshaped. The driving force must be changed. The goal must be shifted. The hard work of

all employees to transform the business must be redirected. The objective must be to

transform the organization into a change embracing enterprise, working as a

cross-functional, cross-geography team for the common goal of 'best for the day,

everyday-no matter what.' The irony of this kind of a reengineering project is that it has

little, if anything, to do with software.

ERP? Off target, too

There is no doubt that you will need

an ERP system. People do need information with which to manage the global business. But,

first things first. Until the organization determines how it will shape itself, what will

be its business practices and what it will take to adapt to changes, how else will it know

what kind of information system it requires?

We know some things already.

Information must be shared throughout the whole enterprise-both vertically and

horizontally. We know that the organization will need software which acts as a mirror not

a monarch- reflecting the way they choose to manage the business, not forcing them to

conform to restrictions already built into the software. We know that the organization

will never get to 'end of game.' There will always be a new acquisition, a new joint

venture, a new competitor and a new way of doing business.

We know that integration, the easy

access to and the sharing of information throughout the enterprise, is a fundamental

requirement for the peace of mind of the corporate executive who is struggling with

difficult decisions which require complex and comprehensive information. Since we also

know that the next month, quarter, or year will introduce into your organization a new

sister plant or operation, the idea of the same software 'everywhere for everything for

everybody' is not practical. In the complex world of merging two new organizations ripping

out an information system for the sake of complying with the new owner's corporate

standard is not good economics, and certainly not a method of winning friends.

Finding the right software tools for

this emerging, complex, amoebae-like organization will require a serious look at the tools

already in place in the organization. It is time for that 'necessary stop' to determine if

we need to change directions.

There are choices...

Some organizations will find that

they have already chosen the right software tools. The choice of the financial software

coincidentally provided, from the same supplier as the operational software which meets

the needs of the other parts of the enterprise like customer service, maintenance

management, distribution and plant operations. Others will find that the financial

software is an excellent fit-best in class-but that the fit for other parts of the

organization rates only a 'good' or a 'poor' rating. This is when the operations personnel

at the plants must make their voice heard in the corporate halls. Why should the plant

level tool work less well for operations personnel than the tools which the financial

planners have at their disposal? Is operations being forced to use the wrong tool for the

right job?

I know the counter argument. There

are costs to tying two different systems together. The integration is never seamless.

There are always holes or overlaps which have to be managed. Who will support the programs

written to exchange the information? The answer here is "it all depends". There

are obvious places where the integration points have very little overlap and the sharing

of the information is-because the systems are on separate computers anyway-acceptably

shared in batch mode where the updates can occur as often as you wish.

Financial data and operational data

from remote sites is just one example. The overlapping information are the customer master

records, the vendor master records, the account numbers form the ledgers. The need to

share information has to do with credit ratings of customers, authorized pricing from

vendor quotations, updates to ledgers because of the movement of inventory into, out of,

and through the operation.

What about different part numbers,

different currencies, different legal entities? Real problems all, I grant you. However, a

single vendor solution throughout the world will not necessarily solve these problems

either. There will always be different part numbers, I'm sorry to say. Because when you

buy that competitor's operation in far-flung part of the world, I can guarantee you that

their part numbering schema will not match yours.

Can't it be simpler?

Your management tools can not be

simplistic. Though they can be simple to use. But your software tool under the covers must

be as robust, as sophisticated, as intricate as your business operations. In some ways the

technology is the easy part. And is getting the organization to change directions and

allow each part of the operation to choose the right tool. The hard part is finding the

balance between robust functionality and the simpler world of a single software supplier.

I can start the debate. I can provide facts and ideas. You must carry on the debate until

you find for your organization, the right answer.