Business Process Reengineering:Analysis and Recommendations

If you have ever waited in line at the grocery store, you can appreciate the need for process improvement. In this case, the "process" is called the check-out process, and the purpose of the process is to pay for and bag your groceries. The process begins with you stepping into line, and ends with you receiving your receipt and leaving the store. You are the customer (you have the money and you have come to buy food), and the store is the supplier.

The process steps are the activities that you and the store personnel do to complete the transaction. In this simple example, I have described a business process. Imagine other business processes: ordering clothes from mail order companies, requesting new telephone service from your telephone company, developing new products, administering the social security process, building a new home, etc...

All these process do happen, But what happens when these process go wrong? What can be done? The answer is BPR..

BPR relies on a different school of thought than continuous process improvement. In the extreme, reengineering assumes the current process is irrelevant - it doesn't work, it's broke, forget it. Start over. Such a clean slate perspective enables the designers of business processes to disassociate themselves from today's process, and focus on a new process. In a manner of speaking, it is like projecting yourself into the future and asking yourself: what should the process look like? What do my customers want it to look like? What do other employees want it to look like? How do best-in-class companies do it? What might we be able to do with new technology?

So what recommendations can be given?? Re engineering recommendations are...

• BPR must be accompanied by strategic planning, which addresses leveraging IT as a competitive tool.

• Place the customer at the center of the reengineering effort -- concentrate on reengineering fragmented processes that lead to delays or other negative impacts on customer service.

• BPR must be "owned" throughout the organization, not driven by a group of outside consultants.

• Case teams must be comprised of both managers as well as those will actually do the work.

• The IT group should be an integral part of the reengineering team from the start.

• BPR must be sponsored by top executives, who are not about to leave or retire.

• BPR projects must have a timetable, ideally between three to six months, so that the organization is not in a state of "limbo".

• BPR must not ignore corporate culture and must emphasize constant communication and feedback.

One of the hazards of BPR is that the company becomes so wrapped up in "fighting its own demons" that it fails to keep up with its competitors in offering new products or services. But why are so many companies still eager to experiment with reengineering, even when they have experienced previous failures themselves?

It seems that experience, more than the possession of the right approach or methodology, is the key to reengineering triumph. Given the definition of the "to be" state, you can then create a plan of action based on the gap between your current processes, technologies and structures, and where you want to go. It is then a matter of implementing your solution...........