Business process reengineering. Three of the most terrifying words in the modern manager's vocabulary.
Business process improvement. Not quite as scary, but still enough to cause chills to dance up and down the spines of beleaguered workers everywhere.
Any mention of either BPR or BPI in many organizations will start rumors flying and cause the anxiety level to rise. The only people who don't get nervous are usually the ones who aren't familiar with the terms.
Add in office automation, and you can inspire full-scale panic.
Why do BPR and BPI have such frightening reputations in certain circles? We're only trying to make things better. We need better processes to gain greater control over our environment. We need new technology to stay competitive. We need to bring in new knowledge and techniques.
Resistance is futile. You will be assimilated.
Oops, I got a little carried away there. Yes, I am a fan of BPR and BPI in principle, as they can be of great benefit, but I'm also wary. If we're careless in our implementation, we can do great harm.
Think of it this way: Let's say we all cut wood for a living. We've used axes and hand saws all our lives. Then someone hands us a chainsaw, telling us that this new technology will let us cut four times as much wood in half the time.
Are we more likely to cut more wood, or severely injure ourselves? Some people will read the instructions, take the proper precautions and training and realize some kind of productivity gain.
Others may fear this new toy, as it involves leaving familiar, comfortable ways of doing business. They'll just let it sit in the corner and continue working as they always have. At least until the early successful implementers take all their business because they can fill orders faster.
And then, there will be those like Zippy's granddad, who finally admitted last summer at age 71 that he just wasn't up to cutting 16 cords of wood by hand. Zippy bought him a new chainsaw, which the elderly gent brought back the next day, mangled beyond belief. Granddad wasn't afraid to try a new tool, but he just kept chopping and hacking at the wood the only way he knew. When Zippy got him a second one, gassed it up and pulled the cord, poor Granddad almost had a heart attack.
As with any new technology, what you get out of it depends on how you handle it.
"The fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical measures of performance (cost, quality, capital, service and speed)."
There are three key words in the definition:
Process: A collection of activities that create value. Process is not structure, people and tasks. Processes involve either transformation or transaction.
Transformational processes take inputs and turn them into outputs, hopefully increasing the value of whatever you're working with. Assembling a car is a transformational process. You take your inputs, unassembled parts, and transform them into a single vehicle. An air strike is also a transformational process. Your input is a munition of some type, which transforms something that was bothering you into something that isn't bothering you any more.
Transactional processes exchange inputs for outputs. With cars, this involves the exchange of money for parts on one hand and the exchange of a complete car for money on the other. If your transformation added value, you will take in more money than you spent to acquire the parts and build the car. With the air strike, everyone who contributed to the operation is compensated in some way, usually through a combination of personal satisfaction for a job well done, payment of some kind and maybe even personal survival. Not all transactions involve money.
Radical: BPR is a rip it out by the roots process. You don't do as-is modeling with BPR, because you really don't care what your current process is. Start from scratch. If your business didn't exist today, how would you create it?
Dramatic: We want a quantum leap, not incremental improvement. BPR involves considerable storm and stress. You may find that you have to redesign the entire business from the ground up, fire everyone and then see who's still qualified when you rehire. With that kind of organizational stress, a 10 percent return on investment isn't worth it.
Fire everyone? "But wait!" some say. "I have all these people with all these skills in all these offices doing all these jobs on all this equipment. I can't just abandon all that!"
In BPR, nothing is sacred. According to Hammer, one of the hallmarks of BPR is a focus on business processes, not artifacts (including people or equipment) or organizational boundaries. With BPR, we're looking for dramatic results: 80 percent reductions in costs or a tenfold increase in productivity, for example, and preferably both at once. If you want those types of improvements, Hammer maintains that you must be willing to identify and recast fundamental assumptions and associated beliefs.
In short, if you really want to reengineer your processes, don't hesitate to shoot some sacred cows. This is why most people really don't do BPR. It's really one of those jump or die processes, like the guy who leapt from a North Sea oil rig during a fire about 10 years ago. When interviewed afterward, he was asked if he knew how cold the water was and that he'd only live 10 minutes, at most, in the bone-chilling cold of the North Sea.
"Yes," he replied. "But if I'd stayed on the rig, I'd have been dead for sure."
And that sums up for me why we might decide to try BPR: if we don't, our organizations will literally die. Whether we see the fatal blow coming in 10 minutes or 10 years, the organizational stress involved in true BPR should make it a means of last resort for most of us. It is a high risk endeavor that can generate a correspondingly high return. However, if we don't do it correctly, we can wipe ourselves out that much faster.
Hammer estimates that over 70 percent of all projects undertaken as BPRs have failed. There are a few common reasons for the majority of the failures:
Lack of support from top management is probably the number one killer of BPR. Start the project, hand it off to a team, and go back to executive concerns. Certain death for anything remotely controversial. In some cases, management seems to be following an approach to BPR lampooned by Scott Adams in the popular Dilbert comic strip. They put in charge of the project the people most likely to be displaced if the project succeeds. This guarantees no substantive change, despite whatever lip service anyone pays.
A method more likely to succeed is to make the project team responsible for operating the new process once they've finished. People who have to live with the results of their own work are more likely to turn out a good product. Change all the reporting officials so the project manager becomes the new division chief. Back them from the executive level so they can extract and collect, forcibly if necessary, all the threads of their particular process from the various nooks and crannies in the organization. Yes, it may make some people mad. But what would be worse, a few bruised egos or the death of your organization?
A second way to commit suicide by BPR is to pick the wrong process. Some people loathe tinkering with anything critical, so they squander precious resources on a peripheral project that doesn't threaten anyone powerful or have any significant impact on the organizational bottom line. This simply drains productivity from more important areas and hastens whatever collapse was already coming.
A third problem is uninformed optimism. Many people, at least over the past 10 years of rapid growth in computing, have clung to the childlike belief that if we buy enough technology we can solve any problem.
Unfortunately, computers and modeling techniques only act as extensions of our own, often imperfect understanding. If we can't accurately diagram a process using a pencil and paper, a computer modeling program won't help. In fact, computer modeling will allow us to make even more mistakes as our models can become infinitely more intricate at the push of a button.
Finally, don't let the techies hijack the BPR. BPR is a business operation first, a technical implementation second. Just because a project involves an infusion of computer technology doesn't mean the programmers should be making business decisions. If I'm trying to reengineer my business, the last thing I want to be told by the network administrator is that he understands what I need better than I do.
Business process improvement is the gentler of the two methodologies. It involves small, incremental improvements to existing processes over time that may result in a significant overall improvement.
With BPI, you will need both an as-is and a to-be model of the process. The trick is to then map a route from one to the other. BPI makes evolutionary, rather than revolutionary, changes to processes. However, the goal is the same as with BPR. The end result should still be a revolutionary improvement in product.
There are two levels of implementation with BPI: focused and institutional. With a focused approach, you apply BPI to processes selectively and as needed. It's not something you try to do every day. You conserve your resources by focusing them on only the most pressing problems or areas of greatest opportunity. You have greater control over the amount of change in the organization; if your plate is full, you may choose not to add new projects.
Institutionalizing BPI, on the other hand, is more complex. When everyone in the organization practices process improvement every day, your organization goes into a continuous improvement mode. This has both advantages and disadvantages.
An organization that continually improves will never be caught by a competitor trying to copy them. By the time a competitor has copied your style, product, process, or any other aspect of your business, you've already improved beyond that point.
Another advantage is that if the change mentality is now ingrained in your organization, you will suffer a lot less change related dysfunction. People will not only expect change, they may even look forward to instigating it.
This attitude doesn't work for everyone, though. Many people prefer more traditional approaches to dealing with change, including periods of relative stability where they have a chance to recover. People can only assimilate so much change at one time. Once you exceed that limit, additional attempts to change things will usually fail simply because people just don't have any more capacity.
An estimate that I've heard, and have generally observed to be true, states that for any major, organization-wide change to become part of organizational culture will take a number of years equal to the number of levels in the organization's hierarchy from top to bottom. By this yardstick, most military services should expect a 10-12 year cycle for full assimilation of properly managed process change.
This is, of course, a rough estimate that will vary depending on the degree of change, the amount of resistance and numerous other factors. Did we plan for this length of time when we first tried implementing TQM or TQL? When we tried changing the Air Force uniform in controversial ways? How successful were those first attempts? Did they happen quickly or easily? Or at all?
And, more importantly from our standpoint, did we have any kind of business process improvement/reengineering plan when we started tinkering with PCs and networks?
The telegraph was the first big breakthrough in communications, followed shortly by the telephone. Both shrunk the world of business. Did these emerging technologies simply enable better business communications, or did the desire for better ways to communicate inspire their inventors to respond to the need? My bet is on the latter.
The radio was next. World-wide voice communications without wires. Then came the ability to project both pictures and sound via television. However, the only way to store audio and video was on tape or film, both fairly fixed, static media. All these means of communication, but little potential for other integration.
Enter the computer. Over time, computers have evolved to the point where they can facilitate the communications of all the previous media simultaneously: sound, pictures, video, text, numbers. In addition, computers give us new abilities to share, integrate, correlate, manipulate, replicate and disseminate data on a scale we've never known before.
Computers could, today, take the place of telephones, fax machines, calculators, televisions and most of the other electronic devices we use to communicate. They can be connected through land lines, satellite transmission, radio waves and any other conduits we use for electronic communication.
The question is: Why haven't we all done this yet?
The answer is that change takes time and effort, even though all the tools are already here. We've already installed much of the technology we need. However, what really must change are our work habits. Given that we in DoD first got semi-useful PCs in the early '90s, I expect the full impact of the technology won't be felt in our organizations until the next century.
Projects driven by information systems departments tend to have a high technology focus. And systems people tend to be perennial optimists with an eye firmly on the technology of the future. The danger is that a technology-driven BRP/I will tend to ignore the people impacts of systems changes and the impacts on the interfaces between systems and the world outside the front door of the business.
Business people, on the other hand, have in many cases held uneducated and unimaginative views of the use of technology, and usually view people issues from the context of the current corporate climate or one they have experienced in a previous place of employment.
Fortunately, the two communities have been moving close together over the last few years. Business people have been exposed to more sophisticated levels of technology and are starting to get more comfortable with it. Technical experts, particularly in the commercial world, are starting to specialize in supporting particular lines of business, and are building a better sense of the overall business operation in addition to their understanding of technology.
These are good first steps. In addition, there are three things you must have to effect successful process change:
1. Commitment to change from the very top. Any lower and results will not achieve full capability.
2. A team of champions and leaders who have the skills and knowledge in the areas of people, process and technology management to identify, direct and implement changes.
3. A vision of the business that is understood by everyone affected by the proposed changes. Without this vision there is no direction or goal. Without goals there is indecision. With indecision comes uncertainty and with uncertainty comes fear and BANG! Your project is dead before is gets started.
BPR-L tries to facilitate the development of a human network consisting of members with shared interests and skills in the field. Its purpose is to promote a constructive dialogue about BPR, both theory and practice, and to provide the opportunity for sharing all kinds of useful, BPR-related information.
BPR-L is an electronic mail group which can serve as a communication channel for researchers AND practitioners in the field of BPR. It can serve as an electronic device for meeting other people who are working on this topic.
The principle of BPR-L is simple: each message sent to BPR-L is automatically distributed to the mail addresses of all other BPR-L members. Types of messages that can be sent are:
SUB BPR-L Yourfirstname Yourlastname
After confirming your subscription, you will start receiving BPR-L messages through e-mail. I strongly suggest you activate the digest option at the earliest opportunity. That way, you will only receive one message from the list per day containing a collection of messages instead of all the individual messages as they are posted. On busy days for the list, this will save you a lot of lines in your incoming e-mail box.
Hammer says, "If it ain't broke, you've still got time to fix it." I tend to agree. Waiting for something to break puts you in crisis mode. I prefer a more deliberate approach when I'm tinkering with anything really important. Be proactive.
A gentleman by the name of Ian E. Wilson offered this thought: "No amount of sophistication is going to allay the fact that all your knowledge is about the past and all your decisions are about the future." This is particularly relevant to BPR/I, given our penchant for reinventing the wheel every few years. Don't be afraid to try something no one's ever done before, but be careful when you do it.
And finally, a quote from almost 2,000 years ago that confirms my belief that some things never change. In the first century A.D., Gaius Petronius Arbiter made the following observation about change:
"I was to learn later in life that we tend to meet any new situation by reorganizing. And what a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency and demoralization."
He must have been a government employee. ;-)
About the Author: Major Dale Long, USAF