Business process reengineering

The short answer is "It depends". BPR can generate improvements that will improve productivity, provided that the "problem" or situation of the business is accurately diagnosed and the solution is agreed upon. There are a number of questions that should be examined before determining that BPR is the appropriate solution. One such preliminary step is to assess the organizational culture (see Schneider, The Reengineering Alternative) to assess what and how internal strengths can be utilized. Other questions will relate to whether the root cause of the problem is process-related, personnel-related, or strategy-related. If there is any lack of clarity about strategy or its implementation, this issue should be addressed first. Improving processes that are not adequately aligned with strategic direction will not likely yield the desired results, and engaging in a exercise that raises expectations but does not deliver results can have detrimental impacts on morale. Similarly, if the human resources are not adequately directed, or insufficiently qualified, or simply not motivated, the BPR exercise may not be the solution, and may in fact be predestined for failure.
However, if the BPR is undertaken in a thoughtful manner, with the recognition that the ultimate management action may not be to implement new processes, then the pitfalls could be avoided. Using BPR tools as a means of analysis can be an effective way to isolate questions or concerns that relate to strategy, personnel or processes.

First of all, nothing in technology is absolute, so we can't say "always."

I've been an analyst for over 20 years, and my experience is that customers will generally be willing to work with you to re-engineer a process. This may be true for several reasons:
> Business requirements have changed significantly since the process was last modeled,
> The technical system supporting the process is old,
> The resident expert retired and no one knows the overall picture any more, etc.The first step in re-engineering is to define the current process. This requires getting the experts in the process together and try to define what is really done. Always remember two things:
1. No judgements are to be made during this phase. You want to find out how the end is actually achieved. Judging alienates people, which causes them, either consciously or unconsciously, to withhold information.
2. You're not looking at the current system to define the process. There are many steps beyond what the system will do that need to be discovered and documented.

Once defining the current process is done, management needs to make a decision as to whether or not the existing process meets the organization's needs. Once the manager has a complete understanding of what the process is doing, (s)he may decide that you need not go any further or decide that a review is in order to determine whether or not newer technology will be able to improve the process and if the costs would be worth the benefit. That's where the analyst's experience is called upon.

From my experience, I would say that at least this portion of Process Re-Engineering is generally useful (nearly always) if for no other reason than to define the process, which is also a requirement for ISO 9000 certification, so that new employees can be moved into the process, even after all the experts have retired.

Both of the previous answers were excellent, and I just have a few minor points to add.

In my experience, a business usually undertakes BPR for one of two reasons - someone thinks something is broken, and they believe BPR is a way to fix it, orsomething else is triggering a change (buying a new software product, for instance) and the existing process has to be re-engineering in order to use the new product.

To some, this might seem like the same reason (i.e., the reason they bought the new tool is because the old one is "broken" or someone doesn't like it anymore or it does something that a manager was really impressed with when the salesperson showed it to them.) The truth is that in an ideal world, the BPR analysis would takeplace first, and that would be the reason for the new tool. But in reality, someone decides they want a new tool, and that is often the trigger for initiating BPR - to rework the the business process in order to use the tool.

This is a classicreason for the failure of BPR in some organizations - it is done as a justification for a management decision which was already made, not because someone was trying to improve an existing process.

Since sponsorship and expectation are critical tothe success of BPR, doing it for the wrong reason is a really good way to ensure that it will fail!

Like previously mentioned, nothing is absolute BUT....

In my experience (I've been with IT in County Government for 18 years) we did very little process analysis for many years, and "paved the cow path" as our CIO likes to call it. Adapting systems and applications to fit business processes that were inefficent, bloated with cost, redundant, and more times than not, horrible.

We now have a PQI office (Process Quality Improvement) that completely analyzes the processes before we implement an IT solution. They work hand in hand with our IT/Project Managers to develop a project plan that handles the business and technical needs of the end user.

One issue though... No one in the organization was ready for the time, effort, or analysisinvolved in doing this properly, not our user base, IT professionals, project managers, or developers! Business managers had a real problem with the PQI team "sticking their noses" into their business.

Jim

This question was closed by the author