Business process reengineering (BPR) extends far beyond the scope of information technologies and software engineering. Among the many defi...
Business process reengineering (BPR) extends far beyond the scope of information technologies and software engineering. Among the many definitions (most somewhat abstract) that have been suggested for BPR is one published in Fortune magazine : “the search for, and the implementation of, radical change in business process to achieve breakthrough results.” But how is the search conducted, and how is the implementation achieved? More important, how can we ensure that the “radical change” suggested will in fact lead to “breakthrough results” instead of organizational chaos?
A business process is “a set of logically related tasks performed to achieve a defined business outcome” . Within the business process, people, equipment, mateencompasses rial resources, and business procedures are combined to produce a specified result. Examples of business processes include designing a new product, purchasing services and supplies, hiring a new employee, and paying suppliers. Each demands a set of tasks and each draws on diverse resources within the business.
Every business process has a defined customer—a person or group that receives the outcome (e.g., an idea, a report, a design, a product). In addition, business processes cross organizational boundaries. They require that different organizational groups participate in the “logically related tasks” that define the process.
We noted that every system is actually a hierarchy of subsystems. A business is no exception. The overall business is segmented in the following manner:
Each business system (also called business function) is composed of one or more business processes, and each business process is defined by a set of subprocesses. BPR can be applied at any level of the hierarchy, but as the scope of BPR broadens (i.e., as we move upward in the hierarchy), the risks associated with BPR grow dramatically. For this reason, most BPR efforts focus on individual processes or subprocesses.
Principles of Business Process Reengineering
In many ways, BPR is identical in focus and scope to business process engineering . In an ideal setting, BPR should occur in a top-down manner, beginning with the identification of major business objectives and goals and culminating with a much more detailed specification of the tasks that define a specific business process.
Hammer suggests a number of principles that guide BPR activities when they begin at the top (business) level:
Organize around outcomes, not tasks. Many companies have compartmentalized business activities so that no single person (or organization) has responsibility (or control) of a business outcome. It such cases, it is difficult to determine the status of work and even more difficult to debug process problems if they do occur. BPR should design processes that avoid this problem.
Have those who use the output of the process perform the process. The intent of this recommendation is to allow those who need business output to control all of the variables that allow them to get the output in a timely manner. The fewer separate constituencies involved in a process, the smoother is the road to a rapid outcome.
Incorporate information processing work into the real work that produces the raw information. As IT becomes more distributed, it is possible to locate most information processing within the organization that produces the raw data. This localizes control, reduces communication time, and puts computing power in the hands of those that have a vested interest in the information that is produced.
Treat geographically dispersed resources as though they were centralized. Computer-based communications have become so sophisticated that geographically diverse groups can be placed in the same “virtual office.” For example, instead of running three engineering shifts at a single location, a global company can run one shift in Europe, a second shift in North America, and a third shift in Asia. In each case, engineers will work during daylight hours and communicate via high-bandwidth networks.
Link parallel activities instead of integrating their results. When different constituencies perform work in parallel, it is essential to design a process that demands continuing communication and coordination. Otherwise, integration problems are sure to result.
Put the decision point where the work is performed, and build control into the process. Using software design jargon, this principle suggests a flatter organizational architecture with reduced factoring.
Capture data once, at its source. Data should be stored on-line so that once collected it need never be re-entered.
Each of these principles represents a “big picture” view of BPR. Guided by these principles, business planners and process designers must begin process redesign.
A BPR Model
Like most engineering activities, business process reengineering is iterative. Business goals and the processes that achieve them must be adapted to a changing business environment. For this reason, there is no start and end to BPR—it is an evolutionary process. A model for business process reengineering is depicted in figure. The model defines six activities:
Business definition. Business goals are identified within the context of four key drivers: cost reduction, time reduction, quality improvement, and personnel development and empowerment. Goals may be defined at the business level or for a specific component of the business.
Process identification. Processes that are critical to achieving the goals defined in the business definition are identified. They may then be ranked by importance, by need for change, or in any other way that is appropriate for the reengineering activity.
Process evaluation. The existing process is thoroughly analyzed and measured. Process tasks are identified; the costs and time consumed by process tasks are noted; and quality/performance problems are isolated.
Process specification and design. Based on information obtained during the first three BPR activities, use-cases are prepared for each process that is to be redesigned. Within the context of BPR, use-cases identify a scenario that delivers some outcome to a customer. With the use-case as the specification of the process, a new set of tasks are designed for the process.
Prototyping. A redesigned business process must be prototyped before it is fully integrated into the business. This activity “tests” the process so that refinements can be made.
Refinement and instantiation. Based on feedback from the prototype, the business process is refined and then instantiated within a business system.
These BPR activities are sometimes used in conjunction with workflow analysis tools. The intent of these tools is to build a model of existing workflow in an effort to better analyze existing processes. In addition, the modeling techniques commonly associated with business process engineering activities such as information strategy planning and business area analysis can be used to implement the first four activities described in the process model.
Words of Warning
It is not uncommon that a new business approach—in this case, BPR—is at first hyped as a panacea, and then criticized so severely that it becomes a pariah. Over the years, debate has raged about the efficacy of BPR . In an excellent discussion of the case for and against BPR, Weisz summarizes the argument in the following way:
It is tempting to bash BPR as another silver-bullet fad. From several points of view—systems thinking, peopleware, simple history—you’d have to predict high failure rates for the concept, rates which seem to be borne out by empirical evidence. For many companies, the silver bullet has apparently missed. For others, though, the reengineering effort has evidently been fruitful.
BPR can work, if it is applied by motivated, trained people who recognize that process reengineering is a continuous activity. If BPR is conducted effectively, information systems are better integrated into the business process. Reengineering older applications can be examined in the context of a broad-based business strategy, and priorities for software reengineering can be established intelligently.
But even if business reengineering is a strategy that is rejected by a company, software reengineering is something that must be done. Tens of thousands of legacy systems— applications that are crucial to the success of businesses large and small—are in dire need of refurbishing or rebuilding.