In today's increasingly competitive marketplace, many organizations are looking for opportunities to differentiate themselves. This differentiation is sought with the goal of maximizing corporate profitability and, ultimately, shareholder wealth. One of the many ways organizations are approaching these goals is through the use of a concept called business process reengineering (BPR).

In their book "Reengineering the Corporation," Michael Hammer and James Champy formally define BPR is as "the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service, and speed."[2] The authors of "the Bible" of BPR, Hammer and Champy, expand on this definition by focusing on four important words in this definition: fundamental, radical, dramatic, and processes. The two most important words with regards to the analysis of the underlying systems are fundamental and processes.

First, fundamental refers to the most basic aspects of a business and it's underlying processes. When undertaking a BPR initiative, the reengineering team must understand the fundamental assumptions underlying the current business process and ensure that these critical assumptions are disregarded throughout the BPR process. Hammer and Champy further state that BPR must begin with no assumptions.[2] Thus, a thorough analysis must be performed to identify these critical assumptions so that they will not impede the reengineering process.

Second, process refers to the actual processes involved in the BPR initiative. Hammer and Champy state, "most businesspeople are not process-oriented."[2] In order for a BPR initiative to be successful, the reengineering team must first identify the specific parts of the process and how they're interrelated. Then, they must analyze the relationship of the process to the overall goals of the organization. Hammer and Champy suggest that a paradigm shift from task-oriented thinking to process-oriented thinking is crucial for successful BPR.

Information systems analysis is a crucial component of BPR. Systems analysis and it's relationship to the overall BPR process will be further examined. Furthermore, to illustrate this concept, a case study will be presented. However, to fully understand the concept, we must first study the history of BPR.

Return To Top

Although many people consider BPR a recently invented concept, its origins actually can be traced back to the late 1800s. Those who study BPR believe an engineer by the name of Frederick Taylor is truly the father of the concept. In the 1880s, Taylor asserted that "managers should use process reengineering methods to discover the best process for performing work, and that processes be reengineered to optimize productivity."[3]

As organizations began practicing Taylor's ideas, they noticed an increase in productivity. This apparent discovery of a new concept led another engineer to take the idea one step further. In the early 1900s Henri Fayol, also a French organizational theorist, believed this concept could be applied to the organization as a whole.[3] These two individuals began a century long organizational concept about which much has been written and many more individuals have attempted to evolve the idea.

However, it was not until the early 1990s that the concept received a much-needed injection of popularity. The revival of the concept was highlighted by Hammer and Champy's book. At the time of the first edition's publication (1993), the American economy was stagnant. Profit margins were being squeezed and companies were searching for ways to survive. Thus, Hammer and Champy's pioneering book was well timed. However, since the late-1990s and after some successes and many failures, the concept has lost some of its popularity.

Return To Top

BPR is an integrated, multi-phase process which can carry many costs, especially that of monetary and time. Thus, it is very important to select the team participants wisely, as well as choosing a sound methodology. Reengineering groups can vary from project to project. However, they all should contain a couple common characteristics. First, every BPR team should contain members of varied backgrounds and experiences. Team members should not only be IT professionals or only business professionals. Second, while there is no set size for a group, it is imperative to have the proper number of individuals for the task at hand. This is however, easier in theory than in practice.

Furthermore, to facilitate a smooth BPR process, a team must select a methodology that is appropriate for the project. Many methodologies have been developed to help guide the process successfully towards the organization's goal. Although a myriad of BPR methodologies exist, almost all of them contain the same basic steps. For example, on their website, ProSci posts their seven-phase methodology:[4]

Conversely, in his book, William Band postulates his five-phase idea of a BPR methodology:[5]

In phase one, the reengineering team must identify the core processes critical to the ongoing survival of the organization. It is important at this point to differentiate between core processes, or those processes which help to differentiate the organization from it's competitors, and non-core processes. Examples of core processes may include research & development, customer service, and human resources. Conversely, a non-core process typically serves no differentiation purpose such as the payroll function.

In an effort to compile and analyze an organization's core processes, that organization may utilize data flow diagrams (DFD) and entity-relationship diagrams (ERD). DFDs show the flow of data throughout an organization's system. More specifically, DFDs show a system's data sources, destinations, flows, stores, and processes.[6] The level of the DFD directly illustrates the detail of the process illustrated in the diagram. For example, the context level DFD simply shows the inputs and outputs of an organization's system as well as it's external entities. It does not incorporate how the output was generated only what output was generated. However, as the levels of the diagram increase, the detail of the systems correspondingly increases. Therefore, the mid- and high-level DFDs can be very helpful in assisting the reengineering team to determine core processes.

Furthermore, ERDs illustrate the entities in a process and their relationships to each other. These diagrams specifically show the entities, relationships, and the cardinality of those relationships within a particular system.[7] This tool can help the team identify dependencies amongst the entities within the system. A deep understanding of the entity-relationship can be helpful in identifying participants and stakeholders and ultimately, focusing the scope of the project.[8]

Accurately representing an organization's systems and processes via data flow diagrams and entity-relationship diagrams is the crucial first step in the analysis of a reengineering project. Again, it is important to stress that the team must differentiate between core and non-core processes. Careful preparation and analysis of these diagrams should provide helpful insight into this critical area for reengineering teams.

Phase two of Band's methodology mandates the establishment of performance requirements. This is primarily done through a process known as benchmarking. On their website, ProSci defines benchmarking as "the search for the best practices that yields the benchmark performance."[9] This can be accomplished by simply understanding the organization's current situation and further analyzing where the organization should be. To accomplish this, an organization may compare some statistical information to another organization within the industry (often an industry-leading organization).

The benchmarking procedure though has its limitations. There have been numerous documented case studies in which organizations have overlooked their core competencies during the benchmarking process, thus producing a failed BPR project. For example, in their paper, Arunachalam and Subramanian present a failed BPR initiative of United Parcel Service (UPS). The organization attempted a new service that would ensure next day delivery by 10:30 AM. Everything was reengineered, including restructuring of the delivery organization, retraining of drivers, rescheduling of routes, and even redesigning the doors on the delivery trucks. After these initiatives had been implemented, UPS soon discovered that their customers were more concerned about the services they provide than with the promptness of delivery. By implementing this initiative, UPS lost one of its core processes, advertising (by drivers), and also experienced poor labor relations. Since this discovery UPS has since returned its operations to more closely resemble the pre-reengineering effort.[10] Benchmarking is another important element in the BPR process, however, teams must ensure to not ignore certain core processes as UPS has illustrated in the previous example

Phase three provides for mapping and evaluating the process performance. This phase actually incorporates the information gathered in phases one and two and enables the team to "pinpoint problems and diagnose the causes of performance gaps."[5] A performance gap exists when the actual performance of a process/system under-performs the benchmark set for that process/system.

There are primarily four ways to evaluate the performance of a process. These measures are cost, time, quality, and efficiency.[11] The first three measures listed are easy to assess as they are typically accessible simply from an organization's existing statistical data. Efficiency, however, is not so easily measured. In spite of its ambiguity, efficiency often is a combination of other performance measures including cost, time, and quality. Each organization must define efficiency in terms of their respective processes and then attempt to measure it based on their definition.

For example, in his book Band presents a BPR initiative undertaken by the IBM Credit Corporation. This unit of IBM provides financing for customer purchases. While researching their loan approval process, IBM found the complete loan process to take approximately six days to complete. Furthermore, IBM found that during this six day period customers were able to "shop around" for a better deal for their financing needs. Since the reengineering process had been completed, IBM has cut the personnel involved in the process to one per loan request. This person processes the loan from origination to closing using a new computer system developed by this initiative. The results of this energetic project were a substantial reduction in the complete loan process time from six days to four hours as well as a reduction in the workforce required to support this function.[5] This case illustrates the importance of accurate analysis of the term efficiency within the context of the specific organization. In IBM's case, they determined the time aspect of performance was affecting the overall efficiency of the business unit.

Building on the previous three phases, phase four develops a vision for the reengineered process. Additionally, during this phase, the team must also develop a set of specific change initiatives. These change initiatives should be established according to the objectives and goals of the project, which can be in terms of performance improvement dimensions, such as the duration of operation, cost of running the process, variety service options, product or service quality, etc.[12]

Many BPR initiatives involve, to various extents, the IT function of an organization. IT is seen by many as an enabler of BPR. In fact, Bustard and He suggest in their article that the business and IT functions are interrelated to the point that any attempt to change one function should correspondingly include a change to the other.[13] A perfect example of this interrelationship is the IBM Credit Corporation project presented in the previous phase. IBM reengineered the loan process to shorten the total time required for the process. Correspondingly, IBM implemented a new computer system to assist the employee working on the loan. This BPR initiative would not have been possible without the implementation of a new computer system. Therefore, IT must, to some extent, be a part of every BPR project's vision.

These four phases of Band's methodology provide a solid basis for the analysis of a BPR project. The final phase incorporates implementation of the changes and is fairly irrelevant to our topic. While ProSci and Band's methodologies may not be representative of the entire population of BPR methodologies, one important aspect can be derived from both of them. Although they each differ in the phase titles and the number of phases, they both encompass the same critical tasks required for a successful BPR initiative.

Return To Top

According to Michael Covert, approximately 70% of all BPR initiatives fail.[14] Oftentimes this failure is due to high expectations that are not met. An analysis of a real-world example of successes and failures may help to identify guidelines an organization can follow to help minimize the chance of project failure. A well-documented case of various BPR initiatives is that of CIGNA insurance company.

CIGNA is an international insurance provider with over 125 years of experience.[15] The company is based in Philadelphia, PA and provides products such as financial services, group insurance (disability, life and accident), health care insurance, and retirement & investment services. The company has segregated these four areas into separate functional areas. There is also a fifth area that encompasses CIGNA's international operations.[16]

In response to falling revenues, in 1999 the new CIO of CIGNA established a group specifically to undertake BPR initiatives. This group was called the CIGNA Reengineering Group. Ten individuals with various backgrounds and experiences initially staffed the group. These individuals were envisioned to remain in the group for approximately 12-18 months. This process would serve two purposes. First, the individuals leaving the team would return to their respective positions with the newly acquired reengineering knowledge that could be applied on a continuous basis. Second, it would provide a revolving door for new individuals to acquire the reengineering skills and experience so that once their project is completed, they too can return to their positions with a new knowledge base from which to work. This is an example of CIGNA's first lesson learned from BPR, diffuse and leverage learning from one project to another.[17]

One of the initial BPR projects undertaken by the company was that of its reinsurance area (CIGNA Re). From the strategic planning process and various benchmarking studies, the senior management of this area decided that the information systems they utilized were inadequate, including the support for systems development. Furthermore, they concluded that administrative expenses, product prices, and staff counts were excessive. As part of the BPR, CIGNA Re implemented new work processes and customer service teams and a new team-based compensation incentive.[17]

This effect of this effort was ultimately a success. CIGNA Re cut operating costs by 40%, reduced its work force by 40%, condensed a two-week underwriting process into 15 minutes, and the number of applications required by workers was reduced from 17 to 5. Despite the apparent success of this project, there were some minor failures. CIGNA Re engaged different consultants at each stage of the process. Each consultant bringing different ideas to the project, thus confusing those involved and causing the effort to progressively lose momentum. CIGNA had learned another important lesson, learn from failures.[17]

The success of CIGNA Re's project provided proof to the organization of the benefits of BPR. In fact, the chairman actually challenged the other divisions to match that success. This challenge then trickled-down through the management ranks to almost everyone in the organization. This top-down approach to BPR is imperative to the success of any project. Additionally, the bottom-up and horizontal approaches are also a critical success factor. Thus, CIGNA had learned its third lesson, foster commitment and ownership at all levels.[17]

Then, CIGNA turned its focus towards its international division. Due to regulatory changes in the United Kingdom, CIGNA began a project to reengineer its unit in that region. Within two years, the reengineering accomplished changes in almost every aspect of the organization. They redesigned the organization structure, roles and responsibilities, work flows, IT, and the culture. Furthermore, functions were consolidated, the functional hierarchy was flattened and all goals were met or exceeded. This crucial project provided a basis for other CIGNA International projects and, more importantly, provided the fourth lesson learned, exploit "clean slate" opportunities.[17]

Due to the successful outcome of the U.K. initiative, CIGNA project managers began to explore opportunities in other countries. However, they quickly found that what worked in the U.K., may not necessarily work in other countries. All countries have inherently different cultures. Thus, it became importantly evident that for a BPR project to succeed, the project must be tailored to its environment. CIGNA's fifth lesson learned was tailor reengineering to the characteristics of the environment.[17]

By the early 1990s, interest in CIGNA's BPR projects began to dwindle. So, to re-energize the program, CIGNA decided to hire a new reengineering director. This director brought with him the concept of migrating BPR from cost cutting projects towards creating new business strategies and new businesses. This second wave to BPR taught CIGNA ascend to "higher forms" of reengineering over time.[17]

In 1993, CIGNA's Property & Casualty group (P&C) began a project to completely redesign their business unit. From 1989 to 1993, P&C lost $1 billion and needed to quickly "stop the bleeding." So, the group initiated the first phase of the project where they involved all employees in the analysis of the problem. This phase coincidentally only took 10 months. Then, the implementation phase began in January of 1994 and took 12-24 months. The success of this initiative was rooted in the quick, decisive action the senior management took in this project. Thus CIGNA learned move with lightning speed.[17]

Throughout P&C's effort, management was vigilant in keeping everyone affected by the process informed. The dissemination of information took the forms of monthly newsletters, e-mail, faxes, telephone calls, and, most importantly, employee involvement. Thus, CIGNA's eighth lesson learned was communicate truthfully, broadly, and via multiple forms.[17]

Due to the popularity of BPR with all the functional areas of CIGNA, the company's IT department faced their owned problems. They too, were being pressured to reengineer their processes. However, the company did not have any procedures in place for the development of teams for this area. So, in July 1993, a new organizational structure was announced. All candidates, including management, had to apply for these team positions. The managerial applicants were actually interviewed by a third party consultant. This process ensured only the most qualified individuals would be working on these projects. Cigna's ninth lesson learned, select the right people.[17]

The new team of IT professionals and leadership thus decided to focus on three key processes: processing, communication services, and the customer service hotline. The entire team was then split into sub-teams, one for each process. Additionally, two more teams were established, one to change the environment (values, culture, structure, etc.) and the other to redesign business practices (develop new business practices that would enable a new vision). Another lesson learned by CIGNA in the IT BPR project was focus, most of all, on a mindset change.[17]

CIGNA's aggressive approach to BPR is a model that any organization can and should follow. In order to avoid the pitfalls CIGNA encountered and to maximize the potential for project success, CIGNA's ten lessons learned should be studied:

1. Diffuse and leverage learning from one project to another
2. Learn from failure
3. Foster commitment and ownership at all levels
4. Exploit "clean slate" opportunities
5. Tailor reengineering to the characteristics of the environment
6. Ascend to "higher forms" of reengineering over time
7. Move with lightning speed
8. Communicate truthfully, broadly, and via multiple forums
9. Select the right people
10. Focus, most of all, on a mindset change

Return To Top

The 1990s signified a re-emergence of business process reengineering. Although we have now seen the failure rate for BPR projects approach 70%, many companies were eager to pursue this course of action in an attempt to revive themselves during stagnant economic conditions. However, BPR can be a powerful weapon in an organization's arsenal if properly understood and applied.

The most critical step in the BPR process is proper analysis of the organization, it's systems/processes, and it's goals. In order for an organization to successfully utilize BPR, accurate understanding of the concepts presented in this paper must be fully mastered. A list of BPR best practices (with regard to the analysis phase) can be deduced from this text.

1. Teams must be properly formed
2. Use of data flow and entity-relationship diagrams can assist in identifying core processes
3. Accurate understanding and utilization of benchmarking principles is crucial
4. Organizations must define efficiency as this is usually a primary benchmark used
5. Organizations must develop a vision and understand most vision involve IT
6. Organizations must develop a list of lessons learned and ensure that a mistake is not repeated

Return To Top

WORKS CITED

1.	McLuhan, Marshall. Personal Quote. http://www.quoteland.com/topic.asp?CATEGORY_ID=141. 11/09/2002.

2.	Hammer, Michael, James Champy. Reengineering the Corporation. 1st ed. New York: HarperCollins, 1993.

3.	Whiting, John T. "Reengineering the Corporation: A Historical Perspective & Critique." Industrial Management. November/December 1994: 14.

4.	"Methodology Selection Guidelines." http://www.prosci.com/project-planning.htm. 11/09/2002.

5.	Band, William A. Touchstones: Ten New Ideas Revolutionizing Business. New York: John Wiley & Sons, 1994.

6.	Kozar, Kenneth A. "Representing Systems with Data Flow Diagrams." http://spot.colorado.edu/~kozar/DFD.html. 11/10/02.

7.	Rogers, Bill. "Entity-Relationship Diagrams." http://www.sxu.edu/~rogers/bu433/er.html. 11/10/02.

8.	Yu, Eric S.K., John Mylopoulos. "From E-R to "A-R"-Modelling Strategic Actor Relationships for Business Process Reengineering." Intl. Conf. On the Entity-Relationship Approach, Manchester, U.K. 13-16 December 1994.

9.	Trimble, Dave. "Benchmarking - Uncovering Best Practices and Learning from Others." http://www.prosci.com/benchmarking.htm. 11/9/02.

10.	Arunachalam, V.S., Dr. Easwaran Subramanian. "Business Process Analysis - A Letter from America." http://bprc.warwick.ac.uk/arun-probs-16.html. 11/9/02.

11.	Kallio, Jukka, Timo Saarinen, Markku Tinnila, Ari PJ Vepsalainen. "Measuring Delivery Process Performance." International Journal of Logistics Management. 11 (2000): 75-87.

12.	Choi, Chung For, Stephen L. Chan. "Business Process Re-Engineering: Evocation, Elucidation, and Exploration." Business Process Management Journal. 3 (1997): 39.

13.	Bustard, David W., Zhonglin He. "A Framework for the Revolutionary Planning and Evolutionary Implementation of a Business Process and its Computing Support." Logistics Information Management. 11 (1998): 370-374.

14.	Covert, Michael. "Successfully Performing BPR." http://members.ozemail.com.au/~visible/papers/BPR.html. 11/11/02.

15.	http://www.cigna.com/general/about/index.html. Corporate Website. 11/11/02.

16.	http://www.cigna.com/general/about/glance.html. Corporate Website. 11/11/02.

17.	Caron, J. Raymond, Sirkka L. Jarvenpa, Donna B. Stoddard. "Business Process Reengineering at CIGNA Corporation: Experiences and Lessons Learned From the First Five Years." Management Information Systems Quarterly. 18 (1994): 233-250.

ADDITIONAL BIBLIOGRAPHY

1.	Webster, D., M. Black. "Business Process Re-engineering: A Case Study of a Developmental Approach." Total Quality Management. 9 (1998): 369-378.

2.	Mercer, Michael. Absolutely Fabulous Organizational Change. Castlegate Publishers, 2000.

3.	Greenberg, Lowell J. "The Most Common Business Reengineering Factors and Pitfalls." http://earthrenewal.org/bprmist.htm. 11/11/02.