The usual re-engineering structure6 consists of the BPR leader, process owner, re-engineering teams and other employees involved in the re-engineering process and are displayed in Figure 12.3.
1. BPR Leader
A BPR leader is a person who holds one of the top positions in the re-engineering process. The outcome of the BPR experiment depends greatly on the quality of leadership. Although, ideally, the Chief Executive Officer (CEO) seems to be the right choice, he or she may not be in a position to devote enough time to a major initiative like BPR due to his or her preoccupation with several other crucial activities. Many of these are concerned with external people and institutions. The CEO may be the BPR leader in a medium-sized or small re-engineering process. Box 12.4 discusses the leadership provided by the top management of CEAT for BPR implementation.
In a large re-engineering process that comprises several divisions involved in different types of businesses, the head of the strategic business unit (SBU) may also be a BPR leader because of his full control over different departments of the division. However, he can re-engineer only those processes that are confined to his SBU. The success of one SBU may generate interest among other SBU heads who then take the initiative to introduce BPR in their own divisions. Eventually, the re-engineering process, as a whole, may succeed in developing a process-oriented culture.
BPR is essentially teamwork. The leader alone cannot carry it out. The leader appoints process owners and each is given the charge of re-engineering a process.
2. Process Owners
The objectives to be achieved by the re-engineering processes should be fixed by the leader in consultation with the process owners. In addition to technical aspects, the process owners need to display behavioural aspects such as leadership, communication, teamwork, attitude, resistance to change, re-engineered culture, etc. and they should also feature in the training programmes. The process owners should; however, be prepared for setbacks, which may be both technical and behavioural and may occur due to several reasons. Just as the BPR leader is expected to support and encourage the process owners when things are not working so well, it is the responsibility of the process owners as team leaders to work with the members and resolve the problems faced by them during implementation.
The first job of the process owners while conducting meetings with the team members is to explain the objective of the meeting and ensure the involvement of all. In consultation with the members, the process owner should explore the viability of the ideas thrown up in the meeting through brainstorming or otherwise and, as far as possible, quantify the benefits derived from them. Each process owner works with a re-engineering team for process implementation.
3. Re-engineering Teams
The re-engineering team members represent a cross-functional group with expertise in different parts of the process. The objective of the team is to integrate the fragmented tasks or sub-processes into a complete process that brings about radical improvements.
The concerned departments should be prepared to spare their best performing employees to join the team. Any attempt to re-engineer a process with process owners and team members of mediocre calibre will result in a mediocre outcome. Their efforts may improve the process, but the improvement is most likely to be marginal.
Before the initiation of BPR, it is possible that many of these high performers may have brilliant ideas that could not be implemented due to task-oriented and functional constraints. Once BPR succeeds in removing these barriers by creating a process-oriented culture, they can avail of the opportunity to communicate their ideas. As high performers, they are already seen to be performing their tasks well. However, BPR broadens their horizons and offers greater challenges that they are prepared to face.
4. Other Employees Involved in the Re-engineering Process
Process owners and team members need the assistance of other employees for the successful implementation of a re-engineering process. Adequate training should be given to the employees for the successful implementation of a re-engineering process. In order to successfully implement the re-engineering process, there is a need for co-operation and active involvement of other employees to perform the tasks assigned to them.
The other employees involved in the re-engineered process support the process owners. They are not members of the BPR teams. Apart from them, some middle management level or junior level managers may also act as “catalysts” and initiate re-engineering projects.
In some re-engineering processes, the need for BPR is first felt not by the top management but by a person who plays the role of a “catalyst” and tries to initiate the endeavor. A catalyst is normally a manager who holds a relatively junior position and is close to the place of action. The catalyst, however, undertakes a detailed study of the process to convince the top management about its shortcomings and the benefits of re-engineering it. Unless his diagnosis is supported by hard facts and figures and detailed analysis, the top management may not attach due importance to it.
However, a catalyst due to his or her relatively junior position will not be chosen as the BPR leader. He or she will not have control over tasks performed in other departments. The leadership is always at the level of the top management. If the top management decides to re-engineer a process analysed by the catalyst, then the catalyst is also quite likely to be involved in it and eventually in other processes.
5. BPR Teams in Project Management
BPR team roles should be identified early in project management to help ensure timely delivery. Some individuals may be called on to play a variety of roles in different projects and occasionally even on the same project. Many re-engineering processes may have standards applicable to defining team roles. Typical team roles may include, but not be limited to the following:
Executive sponsor: The executive sponsor has the overall responsibility for the project at the management level including funding, go/no go decision making and providing resource support. Often the executive sponsor also will function as the project “champion” within the organization.
Business analyst: The business analyst elicits, analyses, documents and reviews the requirements for accuracy and presents them to project stakeholders for review and approval.
Project manager: The project manager manages the day-to-day activities of the project ensuring that tasks are delivered on time and within the budget and scope. The project manager must ensure that proper stakeholder approval of the requirements is obtained before progressing forward with project delivery.
Developer: Developers are the technical resources assigned to a project and may include many technical roles within a project team, e.g. the technical lead oversees the design, code, and test activities for the technical members of the project team. Developers also plan the application’s transition to the user community, often working directly with the business analyst and trainers.
Quality assurance analyst: The quality assurance analyst is responsible for ensuring that quality standards are adhered to by the project team.
Trainer: The trainer is responsible for developing user training curriculum materials and delivering training to end-user personnel. These materials are based on the functional requirements.
Application architect: The application architect defines the architectural approach and high-level design for a project solution. The application architect is responsible for determining the technical direction of the project and the overall structure of the solution.
Database analyst (DBA): The database analyst is responsible for all technical aspects related to designing, creating and maintaining project databases.
Infrastructure analyst: The infrastructure analyst designs the overall hardware and software infrastructure and environment needed to meet the application development and operational requirements.
Information architect: The information architect is responsible for assessing the overall data requirements of an information system project. Information architects identify reusable data assets and resolve enterprise data modeling issues.
Solution owner: The solution owner is responsible for defining and approving the project scope and ensuring that it aligns with the business strategy. Approving project scope changes and defining the project success criteria and measurement are also part of the responsibility of the solution owner.
End user: The end user represents the group of people in the organization (and is often external to it) who will actually interact directly with the software application.
Subject matter expert (SME): The subject matter expert (SME) provides expertise in a particular business’s functional area. SME responsibilities are closely related to defining, approving and using the functional requirements for the project. SMEs, typically, work very closely with business analysts in identifying and managing the requirements.
Stakeholders: Stakeholders are people or entities materially affected by the outcome of the project. Stakeholders are often a prime source of information when planning and managing requirements.
Source: Poornima M. Charantimath (2017), Total Quality Management, Pearson; 3rd edition.
Nearly all of the things you say is supprisingly appropriate and that makes me ponder the reason why I had not looked at this with this light previously. This particular piece truly did turn the light on for me personally as far as this subject goes. But there is actually one point I am not really too comfy with so whilst I make an effort to reconcile that with the core idea of the position, allow me observe just what the rest of the visitors have to point out.Nicely done.
Exactly what I was looking for, thankyou for posting.