Chapter 4

Business Process Reengineering in Supply Chains

Michael Hammer coined the term business process reengineering (BPR) in 1990. Enterprise resource planning (ERP) systems depend on BPR to gain efficiency. The concept of BPR can be traced to its origins in management theories developed as early as the nineteenth century. The purpose of reengineering is to “make all your processes the best-in-class.” Frederick Taylor suggested in the 1880s that managers use process reengineering methods to discover the best processes for performing work and that these processes be reengineered to optimize productivity. BPR echoes the classical belief that there is only one best way to conduct tasks. Best practices are vendor methods selected to be the best way to accomplish elemental business tasks. Accomplishing this goal depends on maximizing the effectiveness of policy development and program delivery, planning and budgetary arrangements, decision-making processes, organizational structures, workplace relations, and people management. Significant gains in performance have been attained through BPR.

BPR is suggested as a key step in the initial development of any organization’s ERP. While best practices often are useful, organizations that have developed core competencies in specific functions are better served by avoiding the vendor best practices that all their competitors can buy to retain what they do well. Amazon.com undoubtedly retains processes that it developed to make it successful in e-business rather than adopt all their ERP vendor’s processes.

Increasingly, information and communications technology, often in the form of an ERP, plays a vital role in determining the quality and accessibility of services. Expansion in ERP has opened the door for even greater efficiencies and enhanced service delivery through integrated processes. The strategic application of ERP opens up opportunities for even greater gains as public and private sector enterprises transform their existing processes. For individual enterprises and government agencies, the most noteworthy gains are achieved when ERP decisions are business-driven.

Processes

A process is a logical set of related activities taking inputs, adding value through doing things, to create an output. In business, there are many different ways to get work done. Information systems play a key role in providing a means to collect data, store it efficiently, generate reports to let management know what the organization is doing, and archive data for future reference as needed.

Blanket adoption of an ERP product will discard processes in which the organization has developed a competitive advantage. Instead of changing those processes, the ERP system should be modified. Other activities will be better done following the ERP system’s best practices. Even here, a transition period can be expected where employees who have to radically change what they do. Productivity degradation will occur while users learn to adapt to the new system. In the long run the new system is most often better. Those who refuse to adapt to it usually have to learn new skills with their next employer.

In general processes can be divided into two broad categories. Operational processes have to do with accomplishing typical business functions, including product development, order management, and customer support. Infrastructure processes are more administrative, such as establishing and implementing strategy and managing many aspects of the organization to include human resources, physical assets, and information systems. Each of these generic processes, whether operational or relating to infrastructure, involves sets of tasks needed to accomplish work.

For example, in the operational process of order management, it is necessary to forecast the volume of demand expected for the products produced by an organization. The function of forecasting can be accomplished in many ways:

Whatever the forecasting method used, it can become part of the process of determining the quantity to order each time an order is place.

A business process is what the organization does to get its work done. For instance, supply chains need to take orders from customers and contact downstream sources to create the product to fulfill orders. This process requires a number of actions. Before computer automation, this could have involved a process given in Figure 4.1.

The old process begins with receiving the customer order and then notifying the producer. The producer in turn then needs to notify its material sources to obtain the things needed to make the product. Often a single source was preferred, for simplicity and to reduce communication requirements. Once materials are received, the producer can proceed with production and, when completed, ship finished goods to the core supply chain organization. This organization then makes sure payment is received and, when this payment is confirmed, sends the product to the customer. The process is linear and slow and has potential for miscommunication. Keep in mind that this is a simplified supply chain and could involve many other elements.

Utilizing information technology offers many opportunities to reengineer processes, making them more efficient. A possibility is given in Figure 4.2.

Electronic automated systems can expand opportunities by reaching lower price sources from a larger pool of candidate sources. This also can reduce risk because more alternate sources are available in times of crisis, such as disruption by earthquakes, tsunamis, volcanoes, or wars. Deregulation and competition are drivers for the creation of new business models through BPR. ERP systems provide a higher level of flexibility in meeting growing customer demands, while demanding higher levels of automation and integration in almost all business processes.

The change implicit in BPR has many risks. Even advocates of BPR cite failure rates of 50 to 70%.¹ Reasons for difficulty in implementing BPR include the following:

Best Practices

One of the primary features of the SAP ERP product has been best practices. Business process reengineering is an activity designed to identify a best practice. Once a best practice is identified that would seem applicable to most organizations, it can be incorporated into an ERP system. SAP spends considerable research efforts to identify the best way of doing conventional ERP tasks. They had 800 to 1,000 best practices included in their R/3 software.² Consultants often develop further specialized expertise that firms can purchase. A best practice is a method that has been judged to be superior to other methods. This implies the most efficient way to perform a task.

A related concept is benchmarking. Benchmarking is comparing an organization’s methods with peer groups, with the purpose of identifying the best practices that lead to superior performance. Best practices are usually identified through the benchmarking phase of a business process reengineering activity. Best practices thus often change the organizational climate and attempt to bring about dramatic improvements in performance.

Vendors attempt to be comprehensive and to be all things to all people. But missed deadlines, excessive costs, and employee frustrations are common in the implementation of ERP. A more participative design approach could help in implementing ERP. If a client implements the entire suite of SAP modules, as well as their tools for system implementation, SAP can ensure timely implementation within budget. However, this approach disregards the human factors of the client business culture.

While business process reengineering was designed to consider human values and business purposes, these factors are clearly neglected in BPR application. Care needs to be taken to consider human factors in new processes. The human factor costs of training and obtaining cooperative participation is the key to the successful implementation of ERP.

Reengineering Options

Implementing reengineering can occur in two basic ways: either clean-slate or technology-enabled BPR. While these are not the only choices (they are the extremes of a spectrum of reengineering implementation possibilities), they are good concepts to explain the choices available in accomplishing reengineering.

Clean-Slate Reengineering

In clean-slate reengineering, everything is designed from scratch. In essence, clean-slate engineering involves reengineering, followed by selection of that software best supporting the new system design. Processes are reengineered based on identified needs and requirements of the organization. As its name implies, clean-slate reengineering has no predefined constraints. This theoretically enables design of the optimal system for the organization. This approach is more expensive than technology-enabled reengineering, but clean-slate reengineering is more responsive to organizational needs.

Clean-slate reengineering is slower and harder to apply than the technology-enabled approach to implementation. However, clean-slate reengineering offers a way to retain competitive advantages that the organization has developed. Ideally, this approach can develop the optimal system for the organization. Clean-slate reengineering can also involve significant changes in the way that the organization does business. However, the adjustment in how organization members do their business often retains the features that were found to work well in the past. Thus, while training is required, the impact is probably less than in the technology-enabled approach.

Technology-Enabled Reengineering

In technology-enabled reengineering, first the system is selected and then reengineering is conducted (constrained reengineering). The reengineering process is thus constrained by the selected system. This approach is faster and cheaper than clean-slate reengineering, because the software does not have to be changed (it is the basis of the design). Cap Gemini refers to technology-enabled reengineering as concurrent transformation.

The technology-enabled approach designs the organizational system around the abilities of the vendor software. SAP’s best practices, for instance, are designed to do things right in the first place. If SAP’s research came up with ways to do everything you do better than you used to do them, this would be the best option. It is the easiest to implement, is usually much faster to implement, and thus costs less to implement. On the negative side, it also usually involves the most change in organizational practice and thus the most complications for training. In practice, therefore, while the ERP installation project looks great from time, budget, and functionality perspectives, the actual benefits to the organization are often disappointing. Table 4.1 compares trade-offs across these approaches.

Many organizations have difficulty in efforts to switch from old legacy systems to ERP. These legacy systems included distribution, financial, and customer service systems developed in-house over the years.

Conclusion

BPR is an important philosophy. It aims to achieve improvements in performance by redesigning the processes through which an organization operates, maximizing their value-added content. This approach can be applied at an individual process level or to the whole organization. Business process reengineering is often a major component of an ERP installation. This implies massive changes in the way in which organizations do their business. This has great potential payoff but also implies a great deal of change in people’s work lives, which requires a lot of attention to demonstrate benefits, as well as a great deal of retraining.

Requirements analysis is important in identifying what a proposed system is to do. In ERP projects, requirements analysis takes the form of business process reengineering, to identify the best way (best practice) for each business process supported by the system. Business process reengineering can be accomplished in many ways, but two ways represent the extremes. Clean-slate BPR starts from scratch and is the ideal approach. Technology-enabled BPR begins with the software selected. This is faster and less expensive, as many of the processes are selected from the system. In practice, neither extreme is necessarily best. Hammer and Stanton credited reengineering as doing a great deal of good, despite being a euphemism for mindless downsizing by some.³ BPR has enabled companies to operate faster and more efficiently and to use information technology more productively. Employees often obtain more authority and a better understanding of the role their work plays for the organization as a whole. Customers get higher-quality products and more responsive service. Shareholders obtain larger dividends and higher stock values because BPR reduces cost and increases revenues. Executives no longer see their organizations as separate entities but instead see them as related elements in larger systems linked through information flows across the business, reaching customers and suppliers.