Reengineering IT: Revisiting Reengineering the Corporation

By Jeff Gainer

 (Author’s note: This article was originally published in the January 1998 edition of the itmWEB Report.)

Recently I had the opportunity to re-read Michael Hammer & James Champy’s seminal business text Reengineering the Corporation. Even today, nearly five years after its initial publication, the ideas in this book are astounding.

For those who have not read the book, you should do so immediately. I don't mean to simply read about reengineering, but recommend that you read the original text. There has been so much written about reengineering that without reading the primary source, it is virtually impossible to understand just what reengineering is and isn't. Hammer and Champy define reengineering as "the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service and speed."

As important to defining what reengineering is, it is equally important to define what it is not. Reengineering is not synonymous with downsizing, and most significantly to members of the IT community, reengineering is not merely about creating new IT systems.

Hammer and Champy have a special caution for IT professionals: "The fundamental error that most companies commit when they look at technology is to view it through the lens of their existing processes."

IT is too often seen as a panacea for business. Speed up the information flow, give everyone access to more information, etc., and thus, the company is reengineered.

Unfortunately, when a company decides to reengineer by throwing information technology at a problem, the company still ends up with the same problems. Sometimes the problems are processed faster, but that’s all. It is still the same old inefficient ways of doing business, the same old processes with a flashy new interface.

Before undertaking any radical new IT project, business managers should first radically reexamine their business processes. Unfortunately, this doesn’t always happen. We, the representatives of IT, are called upon to "reengineer" the business, as if new software, a new database, or a new network topology will magically solve all the business’s problems.

Before designing any new system, we need to realize that perhaps the client’s hidden (and possibly unknown) agenda is actually reengineering the business. It is our responsibility to ask the forbidden question: WHY? Why do you do this? Why do you do it this way?

Unfortunately, even when we model business processes, we tend to quickly move from the abstract processes and focus on the tasks, the minutiae of operations. This tendency is only natural. The purpose in modeling is to bring the abstract into the concrete, to model business processes to a level of detail that can be translated into measurable, testable requirements.

Nevertheless, we must begin by fully defining the abstract principals underlying the business. It is too easy to map the concrete immediately, particularly when you’re sitting in a roomful of workers and middle managers who are accustomed to thinking in anything but abstract terms. It is at this early stage that we can help create the essential culture of breakthrough thinking necessary to reengineer their business processes.

Otherwise, we’re just speeding up the same old inefficient business. The old Garbage In-Garbage Out maxim still applies to the same old broken processes with a flashy new interface.