BUSINESS PROCESS REENGINEERING (BPR)

Introduction

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, we 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.
Business processes are simply a set of activities that transform a set of inputs into a set of outputs (goods or services) for another person or process using people and tools. We all do them, and at one time or another play the role of customer or supplier.
You may see business processes pictured as a set of triangles as shown below. The purpose of this model is to define the supplier and process inputs, your process, and the customer and associated outputs. Also shown is the feedback loop from customers.

So why business process improvement?

Improving business processes is paramount for businesses to stay competitive in today's marketplace. Over the last 10 to 15 years companies have been forced to improve their business processes because we, as customers, are demanding better and better products and services. And if we do not receive what we want from one supplier, we have many others to choose from (hence the competitive issue for businesses). Many companies began business process improvement with a continuous improvement model. This model attempts to understand and measure the current process, and make performance improvements accordingly.
The figure below illustrates the basic steps. You begin by documenting what you do today, establish some way to measure the process based on what your customers want, do the process, measure the results, and then identify improvement opportunities based on the data you collected. You then implement process improvements, and measure the performance of the new process. This loop repeats over and over again, and is called continuous process improvement. You might also hear it called business process improvement, functional process improvement, etc.
This method for improving business processes is effective to obtain gradual, incremental improvement. However, over the last 10 years several factors have accelerated the need to improve business processes. The most obvious is technology. New technologies (like the Internet) are rapidly bringing new capabilities to businesses, thereby raising the competitive bar and the need to improve business processes dramatically.
Another apparent trend is the opening of world markets and increased free trade. Such changes bring more companies into the marketplace, and competing becomes harder and harder. In today's marketplace, major changes are required to just stay even. It has become a matter of survival for most companies.
As a result, companies have sought out methods for faster business process improvement. Moreover, companies want breakthrough performance changes, not just incremental changes, and they want it now. Because the rate of change has increased for everyone, few businesses can afford a slow change process. One approach for rapid change and dramatic improvement that has emerged is Business Process Reengineering (BPR).

Business Process Reengineering (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?
Such an approach is pictured below. It begins with defining the scope and objectives of your reengineering project, then going through a learning process (with your customers, your employees, your competitors and non-competitors, and with new technology). Given this knowledge base, you can create a vision for the future and design new business processes. 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.
In summary, the extreme contrast between continuous process improvement and business process reengineering lies in where you start (with today's process, or with a clean slate), and with the magnitude and rate of resulting changes.
Over time many derivatives of radical, breakthrough improvement and continuous improvement have emerged that attempt to address the difficulties of implementing major change in corporations. It is difficult to find a single approach exactly matched to a particular company's needs, and the challenge is to know what method to use when, and how to pull it off successfully such that bottom-line business results are achieved.

Reengineering Success Factors

More than half of early reengineering projects failed to be completed or did not achieve bottom-line business results, and for this reason business process reengineering "success factors" have become an important area of study. The success factors below are derived from benchmarking studies with more than 150 companies over a 24 month period.
Success factors are a collection of lessons learned from reengineering projects. Reengineering team members and consultants that have struggled to make their projects successful often say,
"If I had it to do over again, I would…" ,
and from these lessons common themes have emerged. In this module we examine these themes or success factors that lead to successful outcomes for reengineering projects. These include:
Top Management Sponsorship (strong and consistent involvement)
Strategic Alignment (with company strategic direction)
Compelling Business Case for Change (with measurable objectives)
Proven Methodology (that includes a vision process)
Effective Change Management (address cultural transformation)
Line Ownership (pair ownership with accountability)
Reengineering Team Composition (in both breadth and knowledge)

Top Management Sponsorship
Major business process change typically affects processes, technology, job roles and culture in the workplace. Significant changes to even one of these areas requires resources, money, and leadership. Changing them simultaneously is an extraordinary task. If top management does not provide strong and consistent support, most likely one of these three elements (money, resources, or leadership) will not be present over the life of the project, severely crippling your chances for success.
It may be true that consultants and reengineering managers give this topic a lot of attention. Mostly because current models of re-designing business processes use staff functions and consultants as change agents, and often the targeted organizations are not inviting the change. Without top management sponsorship, implementation efforts can be strongly resisted and ineffective.
Top management support for large companies with corporate staff organizations has another dimension. If the top management in the "line" organization and "staff" organization do not partner and become equal stakeholders in the change, AND you only have staff management support, you most likely are ill-prepared for a successful reengineering project (line management in this context are the top managers of the operation ultimately accountable for business performance -- P&L, customer service, etc.). Projects that result in major change in an organization rarely succeed without top management support in the line organization.

Strategic Alignment
You should be able to tie your reengineering project goals back to key business objectives and the overall strategic direction for the organization. This linkage should show the thread from the top down, so each person can easily connect the overall business direction with your reengineering effort. You should be able to demonstrate this alignment from the perspective of financial performance, customer service, associate (employee) value, and the vision for the organization.
Reengineering projects not in alignment with the company's strategic direction can be counterproductive. It is not unthinkable that an organization may make significant investments in an area that is not a core competency for the company, and later this capability be outsourced. Such reengineering initiatives are wasteful and steal resources from other strategic projects.
Moreover, without strategic alignment your key stakeholders and sponsors may find themselves unable to provide the level of support you need in terms of money and resources, especially if there are other projects more critical to the future of the business, and more aligned with the strategic direction.

Business Case for Change
In one page or less you must be able to communicate the business case for change. Less is preferred. If it requires more than this, you either don't understand the problem or you don't understand your customers.
You may find your first attempt at the business case is 100 pages of text, with an associated presentation of another 50 view graphs (overhead slides). After giving the business case 20 times you find out that you can articulate the need for change in 2 minutes and 3 or 4 paragraphs. Stick with the shorter version.
Why is this important? First, your project is not the center of the universe. People have other important things to do, too. Second, you must make this case over and over again throughout the project and during implementation - the simpler and shorter it is, the more understandable and compelling your case will be.
Cover the few critical points. Talk to the current state, and what impact this condition has on customers, associates and business results. State the drivers that are causing this condition to occur. State what your going to do about it (vision and plan), and make specific commitments. Keep focusing on the customer. Connect this plan to specific, measurable objectives related to customers, associates, business results, and strategic direction. Show how much time and money you need and when you expect to get it back. Don't sell past the close. No matter how long you talk, you will get resistance from some, and support from others, so you might as well keep it short.
The business case for change will remain the center piece that defines your project, and should be a living document that the reengineering team uses to demonstrate success. Financial pay back and real customer impact from major change initiatives are difficult to measure and more difficult to obtain; without a rigorous business case both are unlikely.

Proven Methodology
The previous module presented several BPR methodologies, and it is important to note that your methodology does matter. Seat-of-the-pants reengineering is just too risky given the size of the investment and impact these projects have on processes and people.
Not only should your team members understand reengineering, they should know how to go about it. In short, you need an approach that will meet the needs of your project and one that the team understands and supports.

Change Management
One of the most overlooked obstacles to successful project implementation is resistance from those whom implementers believe will benefit the most. Most projects underestimate the cultural impact of major process and structural change, and as a result do not achieve the full potential of their change effort.
Change is not an event, despite our many attempts to call folks together and have a meeting to make change happen. Change management is the discipline of managing change as a process, with due consideration that we are people, not programmable machines. It is about leadership with open, honest and frequent communication.
It must be OK to show resistance, to surface issues, and to be afraid of change. Organizations do not change. People change, one at a time. The better you manage the change, the less pain you will have during the transition, and your impact on work productivity will be minimized.

Line Ownership
Many re-design teams are the SWAT type -- senior management responding to crisis in line operations with external consultants or their own staff. It's a rescue operation. Unfortunately the ability of external consultants to implement significant change in an organization is small. The chances are only slightly better for staff groups. Ultimately the solution and results come back to those accountable for day-to-day execution.
That does not mean that consultants or staff are not valuable. What it does mean, though, is that the terms of engagement and accountability must be clear. The ownership must ultimately rest with the line operation, whether it be manufacturing, customer service, logistics, sales, etc.
This is where it gets messy. Often those closest to the problem can't even see it. They seem hardly in a position to implement radical change. They are, in a matter of speaking, the reason you're in this fix to begin with. They lack objectivity, external focus, technical re-design knowledge, and money.
On the other hand, they know today's processes, they know the gaps and issues, they have front-line, in-your-face experience. They are real. The customers work with them, not your consultants and staff personnel.
Hence your dilemma. The line operation probably cannot heal itself when it comes to major business re-design. Staff and consultants have no lasting accountability for the solution, and never succeed at forcing solutions on line organizations.
You need both. You need the line organization to have the awareness that they need help, to contribute their knowledge, and to own the solution and implementation. At the same time you need the expertise and objectivity from outside of the organization.
Building this partnership is the responsibility of the line organization, stakeholders and re-design team. No group is off the hook.

Reengineering Team Composition
The reengineering team composition should be a mixed bag. For example,
some members who don't know the process at all,
some members that know the process inside-out,
include customers if you can,
some members representing impacted organizations,
one or two technology gurus,
each person your best and brightest, passionate and committed, and
some members from outside of your company.
Moreover, keep the team under 10 players. If you are finding this difficult, give back some of the "representative" members. Not every organization should or needs to be represented on the initial core team. If you fail to keep the team a manageable size, you will find the entire process much more difficult to execute effectively.

IT's Role in Business Process Reengineering Initiatives
By some estimates, over seventy percent of today's companies are performing business process reengineering (BPR). BPR realigns business processes along more strategic lines by examining current processes and redesigning those processes to increase efficiency and effectiveness. As more organizations launch BPR projects, one issue becomes painstakingly clear. Radically altering business processes within highly automated work environments typically requires modification to the information systems that support those processes.
Information technology (IT) organizations have had significant difficulty meeting the BPR challenge due to the inherent complexities involved in "retooling" complex legacy environments. In order to more effectively respond to BPR retooling demands, IT must play a more active role throughout a BPR project. IT must:

Increase their level of participation in all areas of a BPR initiative;

Provide key information regarding automated processes to business analysts;

Build a transition strategy that meets short and long-term retooling requirements;

Enforce the integrity of redesigned business processes in the target system;

Reuse business rules and related components that remain constant in a target application.
Factors driving a BPR project can include improving customer service, streamlining processes to cut costs, or addressing inefficiencies in other high impact areas. For example, customers frustrated with having to speak to multiple individuals regarding an insurance claim may switch to the competition. To address this problem, an insurance provider determines that service functions must be consolidated to one point of contact. The underlying systems that manage claims handling do not support single point of contact processing. In this case, legacy systems have become a barrier to the success of the BPR initiative.
Regardless of the motivating factors, creating an implementable retooling plan to support a BPR project remains a frustrating, yet essential, challenge to IT organizations. Retooling strategies can include surround technology, off-shore rewrites, redevelopment of impacted systems, webification and package acquisition. Surround strategies, like the creation of graphical user front-ends or a data warehouse, provide some near-term benefit, but tend to ignore fundamental problems with stovepipe information architectures.
Off-shore projects, which involve shipping a system overseas, typically focus on a technical rewrite of a system. Redevelopment of impacted applications normally couples redesign of the technical architecture with redefinition of system boundaries and addition of new functionality. Linking business functions to the internet still requires managing and synchronizing legacy data and applications. As for software packages, organizations must invest adequate time to determine if a package meets BPR requirements and the amount of customization required if it does not. The applicability of each of these approaches must be analyzed on a case-by-case basis.
To determine retooling strategies, a relationship between IT and the business must be formalized early on. This relationship, which supports BPR analysis and implementation, is reciprocal because business and technical analysts must devise a continuous feedback communication loop for projects to work. This is particularly critical because current systems analysis helps articulate the as-is business model while the redesigned business model dictates the impact BPR has on existing information architectures. Once this reciprocal cycle is in place, IT can determine exactly how to upgrade, redesign, or replace selected systems in order to implement reengineered business processes. Figure one highlights key steps in a retooling strategy.

BPR Retooling Steps
1. Define strategy, select modeling methodology & establish BPR project plan
2. Build as-is business model for impacted business areas based on strategic vision
3. Refine / expand as-is model for all processes supported by existing systems
4. Integrate as-is process definitions with current system functions & components
5. Finalize functional and technical architecture required to meet BPR objectives
6. Select retooling strategy to redevelop, surround, acquire, webify or off-load applications
7. Maintain design integrity between business requirements and retooled applications
8. Reuse applicable components including rules, interfaces & data in target application
9. Validate retooled application against initial simulation of redesigned processes
IT Plays Key Role in Assessing Changing Business Requirements
Being able to determine appropriate retooling strategies requires that individuals with knowledge of the information architecture be on the BPR team. Early and ongoing involvement of IT personnel benefits all aspects of the project. Initial IT involvement focuses on discovery. If a process is to be fully understood, and portions of that process are automated, analysis of underlying applications facilitates the completion of the as-is business process model.
Organizations need to develop an organic blueprint of the business to create widespread awareness of vision and a common understanding of how the organization functions. This includes defining the organizational units, processes, resources, and interactions between each of these objects. One approach might be to use Ivar Jacobson’s ‘Use Case’ techniques. Use Case defines stakeholders within an organization and their relationship with various objects.
Use Case modeling was first defined in Jacobson’s book Object-Oriented Software Engineering. A major benefit of Use Case is that it offers a simplified notation for users. Use Case facilitates the expression of business events and objects impacted by those events. Modeling a complete business process is more intuitive when it can be bounded by tangible events. For example, a process begins when a customer places an order and ends when an order is received and payment is made. Use Case is also an excellent way of representing roles within a business model.
Because Use Case integrates with object-oriented techniques, it bridges the gap between strategic business modeling and the systems specification process. This gap has historically resulted in system designs that do not support BPR requirements. To that end, some vendors have automated Use Case modeling to support techniques such as the Booch object-oriented method.
Traditional business process modeling techniques are not as powerful as object-oriented techniques in terms of being able to break down complex systems. Traditional models also do not provide the same level of flexibility, emphasis on reuse, and intuitive link to software design models. Organizations using traditional BPR techniques can end up with rigid models that are unnecessarily redundant and complex. This should be considered when defining the business model and create a cross functional systems design.
While many people agree with the goal of developing flexible, reusable process models that can interface directly with system design models, some challenge the view that object modeling is the best approach. While object-oriented models are mathematically correct, it is non-trivial to follow them. This is particularly true for the non-technical business user.
One approach involves storing business processes and interactions in an automated facility designed to manage those processes. Each process may then be decomposed into the user interface required to implement that process. This requirements model is easy to understand, helps visualize a target system, and actually becomes the front-end design. Another issue typically ignored during a BPR project is that process redesign tends to be an ongoing effort at many companies. Using a process automation tool provides flexibility to business analysts and users who must update business process models on an ongoing basis.

Existing Architecture Must be Mapped to Business Model
One major IT requirement involves mapping the existing information architecture to the business model to accurately depict current processes. Historically, companies could separate business operations and underlying technology. This distinction is no longer possible. Both areas must be analyzed in an integrated fashion to understand current business processes. This involves analyzing the systems, as well as human interaction with those systems. This includes reviewing system functions, user interfaces, operational procedures, and the often convoluted process of data sharing.
The method used by IT analysts to refine the as-is process model requires documenting current functions and presenting the information in a way that can be integrated into the business model. For example, if order processing is being reengineered, analysts must review system functions that initiate, register, process, deliver, bill, and collect payment for an order. In many legacy architectures, these functions are scattered across numerous standalone or stovepipe systems.
IT-based analysis involves building an inventory of all impacted systems and includes system name, location, operating environment, owner, interfaces, and programs. This inventory should be established at a subsystem level where applicable. The information collected here can be tracked using spreadsheets or in an open repository using a standardt ransition model. While a formal repository representation of a transitional model is more robust, the spreadsheet is a good communication vehicle for users.
The transition model can be established using standard repository technology. Additionally some products include a database that allows analysts to store information about a system. In some of these products, meta-data can be depicted in an object model that can then be used to model business processes. This integrated view, coupled with the ability to layer objects, allows business analysts to view summary information and IT analysts to view the physical detail.
Building a base of information that defines an existing information architecture requires working with systems analysts to identify which pieces of which systems support key business functions. A function is "a group of business activities which together completely support one aspect of furthering the mission of the enterprise". Research can be done through interviews with system subject matter experts or through interrogation of interfaces, including screen and report headings. This process is called "reverse requirements tracing" and is most effective when results are verified with subject matter experts.
Legacy functions are mapped into the transition model as they are identified. The research process focuses on those systems that contain functions that support the processes defined in the business model. Each function, as it is discovered, is linked to the business process it supports. That function is then linked to the user interfaces that implement or initiate it. Interfaces include on-line screens, batch reports, and job control streams. User interfaces can be linked to the programs that implement that function during the implementation phase - depending on the retooling strategy.
Analysts continue to link business processes to functions, and functions to physical components, until all automated processes in the business model are mapped. The reason a business process is linked to an extracted function as an interim step in the transition model is due to legacy system limitations. Functions, normally scattered across stovepipe systems, are extracted from complex legacy interfaces. Creating an interim mapping is therefore easier than trying to relate legacy components directly to process-driven business models.

Retooling Strategy Must Consider Legacy Architecture Evolution
In any BPR project, the as-is model should be used as a basis to redesign workflows. As processes are eliminated, updated, added, and re-sequenced, links to legacy system functions are maintained in the transition model. The modeling approach used can be flexible, because the open transition model supports mapping of legacy functions to object, user interface, or other types of models. Upon completion of the new business model, work can begin on the retooling strategy. This requires an assessment of the existing architecture and target requirements which results in a detailed, retooling implementation plan.
The first step in the assessment requires management to identify feasible retooling hypotheses. This includes surround strategies, redevelopment, offshore options, internet options and / or package acquisition. Several basic issues drive which hypotheses are considered. An immediate requirement to address customer service consolidation may necessitate surround technology, such as graphical front-ends or data warehouse. An offshore rewrite could also serve as an interim strategy to stabilize a weak system. Additionally, selected off-the-shelf packages may meet retooling requirements. Finally, redeveloping impacted systems may be the ideal long-term solution to meet BPR requirements.
Regardless of the approach, the transition model can be used to support detailed analysis, design, and implementation. The analysis needed to finalize the retooling plan includes maintaining links between business models and detailed design models, further decomposition of legacy functions, and mapping legacy functions to detailed target models. The type and depth of analysis depends on the strategy being examined. Fore xample, requirements mapping to a package compares package models with target and legacy design models to determine reuse, deactivation, integration, and migration requirements.
Full-scale redevelopment, depending on the target architecture, requires detailed extraction and reuse of existing business rules. Extracted business rules must be mapped, at the applicable level of detail, to target design models. Augmentation of target models, and reuse of key business rules, can significantly streamline redevelopment cycles and shorten implementation windows. Many of the existing business rules can be reused under a target architecture. Organizations are spending a lot of money trying to recreate business rules when they don’t have to.
These concepts challenge traditional BPR retooling strategies which include surrounding impacted systems or undertaking a complete rewrite. The first approach ignores the fact that underlying architectures remain segregated and convoluted. The second approach rarely accommodates legacy migration requirements and tends to exceed delivery windows and budget plans. Selecting a common sense approach, based on detailed analysis of target and existing architectures, yields the best results.
Several redevelopment options can be applied as a way to retool legacy architectures. Regardless of the approach, systems should be phased in over time, while deactivating legacy components along the way. One approach is to create a system to support the cross section of the business being reengineered. In the order processing example, this means mapping all business rules extracted from multiple standalone systems to a target design model. Rule extraction is accomplished using a combination of slicing and cross-system extraction tools.
Another approach, applying similar techniques, performs multi-system integration on all relevant systems. This approach retools the existing architecture on a broad scale. The focus is on mapping legacy to target design models, rule reuse, redundant rule consolidation, legacy deactivation, and transition management. Both approaches require phased decomposition of existing systems into reusable business logic, data access, and communication segments. Data store consolidation and redesign is performed concurrently. The transition model plays an active and critical role throughout the implementation process.
Internet utilization requires an assessment of the role of legacy data and functionality. Leveraging the Internet requires more than setting loose scores of para coders. Redevelopment offers this broader view of the issue and the solution. Even package strategies require a retooling component. Legacy systems must be inventoried, deactivated, and integrated as part of package implementation. If the package requires retooling, redevelopment techniques may be applied after implementation. Any of these longer term approaches can be coupled with a parallel, interim surround strategy to deliver value near-term.
While it is true that BPR retooling efforts, a relatively new endeavor for IT, have stumbled in the past, this no longer needs to be the case. Following a few basic guidelines, along with education on the tools and techniques that support the process, allows managers to evaluate more options and make more informed retooling decisions in the long run. As IT moves up the retooling maturity curve, realistic interim and long-term retooling options should become the norm.

Reengineering Recommendations
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.

CONCLUSION
Reengineering efforts must be clearly connected to actual business, market, and organization strategy. Easier said than done! If that connection isn't made and maintained, no amount of communication can compensate. Reengineering "ownership" must be broadened to include human resource executives, who are busy with their own renewal initiatives. It must also build a stronger base with employees battered by more than a decade of downsizing. The reengineering movement has spent only a small fraction of what quality improvement has on employee education. Along the same lines, reengineering champions should give more thought to how their programs and projects should ideally be integrated with other important improvement efforts like quality leadership, customer satisfaction and retention, and economic value added (the Stern Stewart model). BPR will be regarded as another tool for management to "pad" its short-term results instead of doing its essential task of innovation, market creation and growth. At the moment, there's nothing poised on the horizon to end the popularity of BPR. Unless these broader issues are addressed, however, you can be sure something will turn up