April 15

"Re-engineering" was a bust. Loyalty is gone. Nothing was achieved.

When newsletter ideas occur to me, I write a few cryptic notes for later development. The notes above were committed to disk six months ago, and as I sit down to expound on the topic, it strikes me that those ten words pretty succinctly sum it up. Nevertheless, it's worth exploring.

For those who missed it, "business process re-engineering" was a craze of the 90's, sparked largely by Hammer and Champy's book "Re-Engineering the Company". The book was indeed inspiring, with case histories of process times slashed, costs drastically cut, etc., etc. Who wouldn't pay attention? What followed was widespread layoffs as companies "re-engineered", meaning "downsized". Why didn't any re-engineering cause "upsizing"? Surely if you want to rebuild something, you remove parts that don't work. But not all business goals translate into cutting costs. Why weren't there case histories of restructuring to gain strength?

In truth, I was never a fan of that kind of "re-engineering", so I'll put my bias on the table. Partly it was because I was a partner in a business promoting work and family balance, and a core value was recognizing the value of individuals. But that's only part of the reason. Deep down, I'm an engineer, and my main objection was because that kind of "re-engineering" wasn't engineering.

What is engineering? It's the practice of applying knowledge to build something (pick your medium), and it has well-recognized and tested principles and measurable design guidelines. It can be taught. It's reproducible. Smarts and creativity help an engineer do better, but smarts and creativity are not engineering.

Furthermore, good engineering stands the test of time. So, did "re-engineering" stand the test of time? By the late 90's, reports abounded, with statistics citing failures in re-engineering initiatives ranging from (in my memory) 75% to 95%. The anecdotes: Many old hands were fired to cut costs and use younger blood more efficiently, and soon enough, companies realized that experience and long-term memory were gone. Much had to be re-learned, and some things never were. Other effects? People working longer hours in fear that they would be next. Burnout. Lack of loyalty to employers, since there was no loyalty to employees. Anyone who studied the work of Jay Forrester and Peter Senge and who understood system dynamics understood that many effects have time delays; sure the cost drops now, but the bad news comes later.

Process Engineering
There are three planes on which to consider process engineering - why, what, and how. For the moment, let's take the business process to be the "what". A business process is a set of activities inter-connected by the information they share. Why is a given business process in place? To achieve some business goal. Change the goal, and the process should change.

How do you implement a business process? There are many ways, all variations and combinations of humans, organizations, organizational procedures for humans, computers, computer applications, communications devices and methods (mail, fax, email), and so forth. Picking your implementation requires knowing more than the process - you have to know the requirements for process reliability, resilience, workload, security, cost, and more, and you have to trade off competing requirements before settling on the best organizational design, the best computer systems and applications, and the best mix of the two.

So, firing one person and moving the work to someone else merely changes the implementation and loads the implementing individual more highly. Might as well cut off your ring finger...there are three other fingers opposing the thumb, after all, and with the same span, they should be able to do the job. It shouldn't affect your golf game much.

This may be oversimplifying, but by how much?

The Power of People
The opposite perspective is that the "how" is the enabler. The best process can't be executed well by unreliable systems, unusable systems, people who don't care, or people who are not well trained. People can make a bad process work when it has to, and they can recover and adapt when other mechanisms fail. Further, they can step back and change the process if it's broken.

And that's where "re-engineering" failed. The importance of people as enablers was lost in the shuffle.

Suggestions
The economy is improving, hiring is up, and competition is as stiff as ever.

• If you need to become more competitive (who doesn't), first think about your process in the abstract - not who does it, what the organizational structure is, or what applications you should buy. Can you throw away activities that contribute no value to meeting the goal? (This reduces cost.) Can you make unnecessarily serial activities parallel? (This reduces time to market or time to delivery.)
• If you want to keep getting more competitive, think about measurement. Does your process measure itself? Pick business-based metrics (like average customer satisfaction), not "how" based metrics (like average call duration).
• If you want to enable your process to do better, enable the mechanisms that implement it. Train your employees and motivate them. Get them the best tools you can (i.e., the best systems you can).

Our Services
Is your organization suffering from lack of technological support, or worse, from technology that obstructs more than it enables? If so, we can help.

Stephen E. Lipka, PhD
slipka@AvatarSP.com
(978) 440-8440