W6 - Basics of BPR(2)

Source / Reference:
1)  "A BPR case study at Honeywell" by David J. Paper, James A. Rodger, Parag C. Pendharkar (2001)
http://www.bus.iastate.edu/nilakant/MIS538/Readings/BPR%20Case%20Honeywell.pdf
2) Total Quality Management 
http://en.wikipedia.org/wiki/Total_quality_management


Subject:
In Lect 6 - Basics of BPR(2)
======================================================================
Response:
In Lecture 6, BPR evolution and a case study were given, as well as Business Process Management (BPM). In this blog post, I am going to compare TQM with BPR in different aspects and share something I've learned from the reviewed paper.

Part 1 : TQM v.s. BPR

Following is the comparison of TQM and BPR, which is based on what I have learned from the lecture and other resources on the internet.

Total Quality Mangement (TQM)
― A management approach for an organization that focuses on customer satisfaction in terms of continual improvement of the quality of its products and services.

-- J. Edwards Deming (Father of TQM)

Similarity: 

• Customer-oriented : aim at improving customer satisfaction
• Outside-in : think from customers' viewpoint
• Process-oriented : target to alter processes
• Teamwork : work on team

Difference:

•  Execution approach
• TQM : bottom-up
• BPR : top-down
• Assumption
• TQM : assumes that the existing system are principally right and useful
• BPR : assumes the existing system is useless and need to be take over

• Targeted improvement
• TQM : aims on smoothly and incremental improvements
• BPR : aims on dramatic improvements

• Duration
• TQM : Continuously absorbed in daily operation
• BPR : one-shot project

• IT involved
• TQM : non-IT based
• BPR : IT based

Summary:
TQM is a consolidation approach for the organizations to maintain continuously improvements.
BPR is suitable for firms in deep trouble or facing great challenges.
They are not mutually exclusive. Instead, a firm can adopt both approaches based on the situations. 

Part 2 :  Brief description and reflection on the reviewed paper:

This paper aims at uncovering how firms achieve success through exploring one organization's experiences with radical change which is called Honeywell. Different aspects in the firm's BPR are examined such as process mapping, execution and teamwork. At the end, ten lessons learned from the case study are given. 

 Reflection:
Among the ten lesson learned mentioned at the last part of the paper, I'd like to comment on the following points.


Lesson three: people need a systematic methodology to map processes

Process mapping is really important as it allows one to see how the process actually works across functional boundaries. In other work, it produces the "big picture" of the process. This creates a common language for dealing with changes to business processes.

However, in reality, it is common that most workers only know what their sections are doing but know nothing about how the previous steps are finished or what the next section would do. All they know is how the fulfill their duties. This is quite inefficient and affects changes. If all people involved in a process know all about the process, not only their own part but also the others, it will be easier to identify opportunities for improvement and becomes more efficient. Thus, it is important to development a systematic methodology to model the process and get everybody understand the whole process.

Lesson six: bottom-up or empowered implementation

One common reasons for BPR to fail is that the design process only involves top management. That is, the process and plan are designed by top management who may only have theoretical knowledge or even do not really know all about the process. This may inevitably lead to poor design. Instead, they should adopt bottom-up approach and empower workers at the bottom who actually do the work. Those workers at the front line may not good at planning and management, but they are skillful, experienced and have knowledge about how to do and implement the work as they are the one who actually do this. Involvement of lower workers in the design and planning process can help to produce a more suitable and efficient design.

Another thing I want to share about this article is the fail-safing mechanism.

Fail-safing is a method to identify a defect, analyze it to understand its root cause and then develop a solution that will prevent that defect from occurring again. It follows a PDCA cycle as shown below.

 

After process mapping, there would be a diagrams showing the entire flow of  a business process, however, no one can guarantee that it is defect-free. Thus, fail-safing is introduced to diagnose a defect within the process. One key feature of fail-safing is that it is a continuous process. After acting on the results, the team should ask itself what can be improved and then begins the cycle again. This happens again and again and generates continual improvement on the process. However, in reality, it is quiet hard to achieve as it is time-demanding.

Conclusion:
Although it is not easy to apply some theories or theoretical practices into the reality, a firm should try to achieve as much as possible. Because those are still useful and helpful even though you cannot apply all at the same time. The key point is to choose the most suitable one and modify it if necessary to make it yours.