Processes, Packages, and Best Practices

Vendors such as SAP, PeopleSoft, and Oracle often refer to their applications as “best practices.” They argue that they developed their modules after studying what worked best at several companies and that the modules represent very efficient ways of handling the processes and activities they support. In fact, of course, these modules represent “average practices.” In many cases they are an advance on the applications that companies had before, but once a company decides to use SAP, Microsoft, or Oracle modules in their HR department, then their HR processes will be the same as those of their competitors who are using the same modules from these same vendors.

Compared with the business process improvement approach we have advocated throughout this book the use of ERP applications occurs in reverse order. In effect, you begin with a solution—a new inventory application from SAP—and proceed to modify your existing inventory process to accommodate the inputs and outputs of the new inventory application. It is still possible to begin by analyzing the existing process, substituting the new SAP module or set of modules during the design phase, and then making the adjustments necessary to use the modules effectively. But the heart of this kind of ERP redesign effort is to accommodate the way your company works to the ERP application and not the other way around.

We think ERP applications represent a reasonable approach to improving a wide variety of business processes. If the processes are easy to automate and add little value to your overall business, then there’s no reason why you shouldn’t simply rely on efficient, average solutions, and focus your energies instead on core processes that do add significant value. Let’s face it, managing payroll deductions or handling an office inventory database are enabling processes that need to be done, but they rarely add anything to the bottom line.

The problem comes when companies try to use ERP applications for tasks that are not routine and decide to tailor them to better fit with the way their company does business. The various ERP applications are essentially database applications; they manage database operations. Each of the ERP vendors has its own favorite database, and it’s very hard to modify the internal workings of ERP applications once they are installed. If your company acquires a payroll application and then decides to tailor it you will find that the value of buying an off-the-shelf application diminishes rapidly. Moreover, the maintenance costs will rise in the future. When new versions of the ERP application are released they won’t work at your organization until the new ERP modules are modified to match the previous modifications you made. If you find yourself considering ERP applications, and simultaneously planning to make lots of modifications in the ERP applications you buy, you are probably making a mistake. If the process is really a routine process and adds little value it’s probably better to change your workflow and use the application in its standard version. If you really can’t live with the vanilla version of the ERP application, then you ought to ask yourself if you really want to buy an ERP application in the first place. (We’ll return to this problem later in this chapter.)

There are vendors that sell applications or develop applications that offer more flexibility than standard ERP application and in the long run don’t cost as much if you want a highly tailored application or know you will want to change the application frequently. On the other hand, of course, these applications will probably not integrate with other modules as well as the standard ERP modules do, and that will add to the cost of more specialized applications.

ERP vendors have recently experienced problems as companies have begun to rely more on the Internet. Most ERP applications were designed to be self-contained systems, tightly linked with and relying on a proprietary database management system. ERP systems were not designed to support distributed data management. Most aren’t especially good at working with other ERP applications, and they were totally unprepared when companies began to want to integrate applications into web portals or into supply chains that communicated over the Internet. In the past few years most ERP vendors have redesigned their systems and have begun to release new ERP applications designed to communicate via the Internet. In most cases, however, this adds another layer of complexity to the problems of integrating applications into e-business systems.

A Closer Look at SAP

Let’s take a closer look at SAP, the dominant ERP vendor. SAP provides overviews, which it calls business maps, of processes that it offers in a number of industry-specific areas. Specifically, it offers business maps, or what we would call process architectures, in each of these areas:

Figure 16.1 illustrates one of SAP’s business maps. In this case we have illustrated SAP’s telecommunications business architecture. On the left side SAP lists the functional areas or in some cases large-scale business processes. On the right, in each row, are the processes included in the general category listed on the left.

Thus one functional area is service assurance, and there are four SAP processes under that function heading: service agreements, customer trouble reporting, customer trouble management, and trouble resolution. Figure 16.2 shows the specific SAP components or application modules that are used to implement (automate) each process.

Notice that, although the various components have different names, they often have the same component number. This suggests that the components are in fact subcomponents or modules of larger SAP applications, or that they rely on the same database for stored information. As we suggested earlier, SAP has reengineered its software applications to move them from a client–server architecture to a component architecture, and the original design often shows through.

We illustrated SAP’s telecommunications business architecture so you can compare it with the eTOM business framework developed by the TeleManagement Forum, which is pictured in Chapter 4 as Figure 4.25. The eTOM architecture was developed by a task force of telecommunications managers and uses terms that are probably more familiar to those in the telecommunications industry. The SAP architecture was also developed by a telecom industry group organized by SAP. The resulting framework uses more generic process names since it relies on existing SAP modules whenever possible. In addition, keep in mind that the eTOM architecture was designed to describe a set of processes that might or might not be automated at any given telecom company. The SAP architecture, on the other hand, only lists software components that SAP sells or plans to sell, or that an SAP-associated vendor sells. Each software component may be entirely automated or it may provide user interfaces, so that employees can use interface screens to monitor or control the processing undertaken by the component.

Figure 16.3 illustrates a different SAP business architecture—in this case the architecture for insurance. Notice how similar the lists of functional areas or large-scale processes are. Also, notice that functional areas near the top and bottom of the diagram describe processes that are very similar to those listed on the telecommunications business architecture in Figure 16.1. Once again, the insurance architecture was developed by industry representatives in conjunction with SAP, and as before it relied on standard SAP modules whenever possible.

If a company decides to work with SAP the SAP representative provides the company with a detailed description of the SAP business architecture and the processes making up each component and asks the company managers to choose which they want to use. Once a company has chosen the modules or processes they want to acquire they can tailor them by changing names to match the terminology already in use at the company or by changing the actual processes themselves to conform more closely to practices at the specific company. It’s especially difficult to link SAP components to other components that you use at your company, or to mix modules from more than one ERP vendor.

Tailoring also takes quite a bit of time. More importantly, once an SAP process is tailored it’s harder for the company to use new SAP updates. Before the company can install the updates the company must first tailor the updates to match the existing SAP modules you have already tailored. The cost of tailoring SAP applications rapidly eats into the cost savings that one hopes to get when one buys off-the-shelf software, and raises maintenance costs. A company gets the best buy when it acquires SAP modules and uses them without tailoring, or creates add-on modules that don’t change basic SAP modules.

SAP is in the business of selling processes or components that are very similar. They have created some unique modules for each industry, but overall they still rely on the initial modules they introduced in the 1980s, which include core accounting, inventory, and HR functions. There’s nothing wrong with using standard modules, but any business manager should realize that many competitors are also using SAP modules. Thus using an SAP process doesn’t give a company a competitive edge, but simply provides the company with a clean, modern implementation of a software process.

So far we’ve looked at the business architecture view of SAP processes. Once you have settled on a specific component you can obtain a more specific process diagram. SAP uses diagrams from the ARIS product of IDS Scheer, which is now a division on Software AG. (The founder of IDS Scheer, August-Wilhelm Scheer, is a software engineering theorist who has written several books on business process modeling and software development.) Software AG’s annual conferences titled Process World 200x are major events in Europe and North America and provide a good overview of the ERP-driven approach to business process improvement.

Figure 16.4 provides a process diagram of a process used by a car retailer. The diagram begins at the top of the page and flows down.

The rectangles with rounded corners represent activities. The six-sided boxes represent events or decision outcomes that occur during the process. The small circles represent decision points or describe the logic of a flow. Thus the circle with ^ represents AND. If two events are joined by an AND, then both must occur before the next process can occur. (The circle with XOR inside represents exclusive OR, which means that one or the other must occur, but not both.) The person or department responsible for the processes appears at the right in an oval. On the left, in thin rectangles, are documents that are accessed, modified, or stored in a database.

SAP is widely used, and thus there are lots of programmers who understand and use ARIS process diagrams like the one shown in Figure 16.4. In addition, ARIS supports a number of other diagrams, including one that has swimlanes and is more like the diagrams we have been using in this book. The diagram in Figure 16.4, however, is the standard ARIS process diagram.

Figure 16.5 presents the same information that is shown in Figure 16.4 using the process diagram notation we have used in this book.

As can be seen in Figure 16.5 there is a clearer distinction between events that a customer performs, documents that are inside the sales system, and events that define the flow of information in the process. By simply scanning along a swimlane, one can quickly see all the places the retail dealer interacts with the customer. Similarly, using other swimlanes one is provided with a better idea of who is responsible for which activities. Note that all the activities pictured in Figure 16.5 are mixed employee/IT activities. In other words, in each case an employee must enter information into the sales database from a personal computer.

We have omitted most of the logic flow notation. In some cases we show two arrows arriving at a box. Our diagram does not tell us if both inputs are required, if either one is sufficient to start the process, or if both are required before the process starts. We could easily add this information by inserting symbols inside the diamonds on our Business Process Model and Notation diagram. Most managers making a high-level process diagram don’t care about this level of detail, but this is definitely an issue that software developers must resolve before they can develop software. However, they are issues that managers often ignore when they are defining business processes.

The process notation used in the SAP reference model by ARIS is designed to tell its users more about control flow between processes. On the other hand, it doesn’t emphasize the relationship between the process and the customer, or make it clear who is responsible for what activities. As a strong generalization the diagrams we use are better for managers who want to analyze and design business processes. The diagrams produced using ARIS methodology are better suited for software developers tasked with implementing a system that relies heavily on the management of documents that reside in SAP systems.

Figure 16.6 illustrates another type of SAP diagram. In this case an e-business process that relies on the Internet to pass information between three parties—customers, an insurance company, and companies that repair cars—is illustrated. The processes or activities are shown in six-sided boxes. The flow is indicated by the fact that some boxes abut others.

SAP calls the diagrams shown in Figure 16.6 C-business maps, which stands for collaborative business maps. In essence, this is a special kind of ARIS diagram to illustrate simple e-business interactions.

What we like best about Figure 16.6 are the business benefits and value potentials that SAP includes on the right and left sides of the basic diagram. In essence, SAP lists reasons why specific activities will save or make companies money. When they have specific data they indicate them as a value potential, and usually add footnotes to indicate the source of the data. Thus, in the example in Figure 16.6 we see that SAP predicts that approving auto repairs online will result in cost savings, and suggests that Diebold Deutschland saved 40% of the cost of the activity.

All the business architectures and C-business maps are available at http://www.sap.com (SAP’s website). SAP offers collaborative business maps in CRM, supply chain management, product life cycle management, e-procurement, marketplaces, financials, and HR. The kinds of benefits SAP lists are most reliable when a company implements a standard process. Little data are available on the more industry-specific processes, which emphasizes that the ERP-driven approach is usually best employed when a company wants to automate processes where the logic is relatively simple and where the processes don’t add much strategic value.

Implementing an ERP-Driven Design

In a review of ERP implementation efforts the Gartner Group argued that the most important thing is the training of end users. This follows directly from the nature of the business process redesign efforts that are driven by ERP applications.

In essence, you begin with an architecture and choose components to use. Then you turn to specific process sequences and choose specific activities to implement. As a result you have selected a whole set of processes and activities that you intend to install at your company with a minimum of changes. Some activities will be fully automated, but most of the activities you select will require that employees learn to use interface screens on PCs to enter or retrieve information from the SAP databases that form the core of any SAP system. That may sound simple, but in fact depending on what your employees are doing now you will need to teach employees an entirely new process.

Consider an auto dealer that used a less sophisticated system. The salespeople talked with customers and eventually filled out a form, which they then used when they phoned to see if a car with the desired characteristics was available. At some point, assuming the car was available, the salesperson would negotiate a price and then take a brief break to get the manager’s approval of the deal being struck. The order in which the salesperson performed those tasks and the verbal exchange with the customer, while all the details were being attended to, was probably quite specific to individual salespeople. Once the SAP system is installed our salesperson is going to have to learn to carry on his conversation while entering information into a computer. The SAP system assumes that the manager approves online and that the supplier determines the availability of the car online, and so forth. It’s probably going to take quite a bit of training before the salesperson feels comfortable with the new process. And the auto example is relatively simple, since it largely follows the sales process already used in auto retail showrooms. Other processes that rely on the use of databases can rearrange the steps in an established process in a much more confusing manner.

SAP is not the only ERP vendor that offers architecture and business process diagrams. Oracle and Microsoft both have something similar. Figure 16.7 illustrates a process map developed by Siebel and IBM to show how Siebel’s CRM software could be organized with IBM’s BPMS WebSphere software.

Most companies begin with an analysis of their As-Is process. Then they “overlay” the ERP modules they intend to install, eliminating the subprocesses and activities that the new ERP apps will replace. What one obtains is a new diagram with lots of disconnects. Interfaces to the ERP applications are PC interface screens (links to database documents). The trick is to create a new To-Be diagram that ties each of the existing activities that remain to ERP modules that have been inserted. Once you have done that you need to review which employees will be doing what tasks and revise job descriptions accordingly. And then you must provide the training necessary to ensure that people can do their new jobs.

One technical problem involves the “translation” of diagrams. We recommend using the types of process diagrams we have introduced in this book. These diagrams make it easier for managers to see how processes work and who is responsible for what activities. Thus to “overlay” a set of SAP activities you need to do a translation of the SAP diagram along the lines illustrated in Figure 16.5. This probably isn’t something the redesign team should attempt, but something that the facilitator or someone in the IT department should be able to do for the team.

Figure 16.8 illustrates a sales order system that relies on two different ERP modules. The ERP Sales Quotation application is essentially an application that checks an inventory database to determine whether ordered items are in stock. The ERP Sales and Distribution application is an application that creates a printed bill of lading. The sales order system is an automated system that could be on a company portal, or it could simply be an application that is accessible online to retailers who sell your company’s products.

In this example we’ve shown some of the activities that occur inside each ERP application. In most cases we would simply have a single process box to indicate each ERP application. The people working on the process really don’t need to know exactly what goes on inside ERP applications. What they need to know is what inputs they need to make, what outputs are made, and who has to process the inputs and outputs. In this example, since the customer is interacting with an automated system, inputs to ERP applications are made by the sales order system, which is itself a software system. If this system replaces a process that involved employees, then appropriate changes would be required. The output of this process is a request to shipping (a bill of lading) to send an item to a customer. Shipping needs to know how to accept such an order and how to handle it. Assuming employees are working in shipping we would probably want to do another process diagram to define just what happens in the ship item subprocess.

The main point here, however, is that you can create swimlanes for ERP applications and indicate how the ERP applications interface with existing process flows. Preparing the transition to the use of ERP applications means understanding exactly how the ERP applications will interact with your existing processes, and then training your people to handle the ERP inputs and outputs when the system is implemented.

Before we discussed ERP-driven redesign we considered workflow. In essence, ERP systems are also workflow systems. Instead of designing a unique workflow system with a workflow tool, one simply chooses ERP components or processes to assemble into a system. Underneath, however, the ERP vendor provides a workflow engine that passes control from one component or process to the next. An IT manager can use the ERP management system to exclude specific documents from a particular process or to quickly modify the order in which processes are used. By combining precoded processes with workflow, companies gain considerable control over basic processes.

Case Study: Nestlé USA Installs SAP

A good example of a company that used ERP packages to reorganize their business processes is provided by the US subsidiary of Nestlé SA, a Swiss food conglomerate. Nestlé USA was created in the late 1980s and early 1990s via acquisitions. In 2002 it included seven divisions, which collectively sold such popular brands as Alpo, Baby Ruth, Carnation Instant Breakfast, Coffee-Mate, Nescafe, Nestlé Toll House, Power-Bar, Stouffer’s Lean Cuisine, SweeTarts, and Taster’s Choice. In 2002 the company employed some 16,000 employees and earned about $8 billion in revenues.

In the mid-1990s the various companies that make up Nestlé SA were all operating as independent units. In 1997 a team studying the various company systems concluded that collectively the companies were paying 29 different prices for vanilla—which they all purchased from the same vendor. The study wasn’t easy, since each company had a different number or name for vanilla and purchased it via completely different processes. Simply isolating vanilla and determining a common unit price required considerable effort.

In 1997 Nestlé USA decided that it would standardize all the major software systems in all its divisions. A key stakeholder team was set up to manage the entire process. By March 1998 the team had its plan. It decided it would standardize on five SAP modules—purchasing, financials, sales and distribution, accounts payable, and accounts receivable. In addition, the stakeholder team decided to implement Manugistics’ supply chain module. The team considered SAP’s supply chaining module, Advance Planner and Optimizer, but it was brand new in 1997, and they decided to go with the better known Manugistics module that was specifically designed to work with SAP modules.

Before even beginning to implement SAP modules people from the divisions were gathered and spent 18 months examining data names and agreeing on a common set of names. Vanilla, for example, would henceforth be code 1234 in every division.

Somewhere along the line the project to install SAP modules also became a Y2K program. By moving to standard software that was guaranteed to be free of bugs associated with date problems that might occur when applications started dealing with dates subsequent to December 31, 1999, the companies would avoid any Y2K problems. Unfortunately, this placed a deadline on the entire implementation effort—it had to be done before January 1, 2000.

As the various SAP applications began to roll out to the divisions the stakeholder team managing the entire effort began to get lots of unpleasant feedback. Jeri Dunn, the VP and CIO of Nestlé USA, explained that in hindsight they had completely underestimated the problems involved in changing division cultures or modifying established business processes. By the beginning of 1999 the rollout was in serious trouble. The workers didn’t understand the new SAP modules, and they didn’t understand how the outputs they were now getting would help them do their jobs or manage the processes they were responsible for.

It was at a major meeting in early 1999 that Dunn was given responsibility for the project. Among the other conclusions reached by this executive committee meeting was that the Y2K deadline would be ignored. Henceforth they would figure out the implementation requirements for each SAP module and then let that specification guide their schedule. They decided that it was relatively easy to install SAP modules, but that it was very hard to change business processes and to win the acceptance of the people responsible for ensuring those processes operated correctly. They also decided that much more care needed to be taken to determine just how the SAP modules would interact with the processes and applications that would remain in place.

At the same time that Dunn took over a new director of process change was hired, and a process manager (VP) for the supply chain was promoted to help Dunn on the remainder of the project. In most cases the team now began to focus on modeling processes and defining process requirements and then creating a plan to install the SAP modules. Several installations were delayed for months or years to accommodate groups that were not prepared for the process changes required. As we go to press (2018) the Nestlé transition is coming to an end. The company spent approximately $200 million on the transition. Dunn claims that the project has already paid for itself. The new planning processes, for example, make it possible to project Nestlé USA–wide demand more accurately and to save significant inventory and redistribution costs. The VP for Nestlé USA’s supply chain, Dick Ramage, estimates that supply chain improvements have accounted for a major portion of the $325 million that Nestlé has already saved as a result of the SAP installation.

Dunn says she’s happy with the SAP applications and very happy that all the companies are now using the same basic processes. Still, in an article on the transition in CIO Magazine in May 2002, Dunn claimed that if she had it to do over again, she’d “focus first on changing business processes and achieving universal buy-in, and then and only then on installing the software.”

Nestlé USA’s use of ERP applications and their problems are typical of most large companies that have elected to rely on ERP applications to drive major changes. The company embraced ERP applications in hopes that they can organize and standardize their software applications and databases across departments and divisions. Most large companies have started on this path and found that it takes much longer and is more painful than they had expected. Few have completed their ERP transitions. The problem lies in the fact that ERP applications aren’t a solution. They are a tool to use in changing business processes. This isn’t something that IT can do by itself. The transition must be conceptualized as a business process transition and guided by business managers. ERP applications must be installed as part of the overall business process redesign effort, not as an independent activity. Used in an appropriate manner ERP applications offer a powerful tool to aid in business process redesign.

Using BPMS to Improve ERP Installations

Most large companies have installed packaged ERP and CRM applications in the course of the last decade. Some have installed the same vendor’s ERP applications throughout the company, while others have installed a mix of packaged and best-of-breed applications. Figure 16.9 provides a very abstract way of looking at an ERP installation. Imagine a company that has a process with three activities. To automate the activities, or at least to support the employees performing the activities while simultaneously gathering data that can be provided to managers, the company decides to install an ERP system. To keep things simple the company buys all its ERP modules from a single company and thereby ensures that the modules will all talk to each other and will store their data in a common database, making it much easier to generate reports. The vendor has three modules that support the three activities. Luckily, Activity 1 is so similar to the assumptions made by the corresponding ERP application that no tailoring is required. Unfortunately, both Activity 2 and Activity 3 include steps and flows that are performed differently from the way the two ERP modules normally handle them. Thus IT agrees to tailor the two ERP modules. We represent this with little boxes inside the modules, which we hope suggests some tailoring.

When the ERP application was finally rolled out—it took quite some time to tailor the ERP modules—everyone was happy. Later, however, when the ERP vendor moved from Version 2.0 to Version 3.0, Module 2 and Module 3 had to be tailored all over again. It didn’t take long for the company to realize that it was going to have to keep paying and changing its ERP applications as each new version of the ERP software was released.

Unfortunately, the problem we have described is only the tip of the ERP iceberg. If the company involved is a large international company it probably rolled out ERP to its different branches and subsidiaries over the course of several years. Moreover, to keep everyone happy IT keeps tailoring ERP applications to support the local practices of groups in each of the branches and subsidiaries. Let’s imagine that ERP Module 2 records sales data and that ERP Module 3 prepares a statement for the customer. The European division uses both ERP Module 2 and Module 3, tailored to their way of doing business. The Indian subsidiary and the Japanese subsidiaries also use ERP Module 2 and Module 3, but each tailored in a slightly different manner. In other words, when the ERP vendor moves from Version 2 to Version 3 the company is actually going to have to buy several copies of Module 2 and several copies of Module 3 and then tailor them to replace all the different versions of those modules it is using throughout the world.

Multiply this by a dozen different business processes and you have anywhere from dozens to hundreds of different ERP applications running in a large international organization. The costs of this approach can be staggering. Figure 16.10 highlights the ERP multiversion problem that most large companies face.

A quick glance at Figure 16.10 suggests that three different units all perform an activity that is rather similar—recording sales data in the case of Activity 2—and that huge savings could be achieved if all divisions and subsidiaries agreed to perform the same activity in the same way. Then the company could tailor one module to support the common activity and not have to support multiple versions of ERP Module 2.

Several companies have launched efforts to significantly reduce the number of different ERP applications they have to support. To do this they are turning from IT to the business units and creating enterprise-wide process managers. Thus, Company X now has a worldwide sales manager and a worldwide procurement manager, and so on. Each process manager is charged with creating a standardized process that will subsequently be supported by a single installation of an ERP application. Other benefits of enterprise standardization rapidly emerge as training is standardized, reporting becomes more consistent, and it becomes easier to move salespeople from one business unit to another, but let’s stay focused on ERP.

Figure 16.11 shows a matrix that was developed by a company trying to get control of its ERP applications. In this case we have placed the traditional organization chart on its side and have the CEO at the left rather than at the top. As you can see the company has created a global process board and identified one sponsor for each major process area. In fact, to get to the organizational structure shown in Figure 16.11 the company had to create a business process architecture and define its major business process area. Having done that and assigned process sponsors the sponsors then convened meetings that brought together managers from across the world. We’ve highlighted the sales process in Figure 16.11. The sales process sponsor held meetings with the sales managers from all the company’s departments and divisions. Together they worked out a common sales process that each unit could follow.

Once the company’s worldwide sales process manager pulls together people from all the business units, he or she will hear all the reasons why sales are different in Europe than in the United States or Japan. There is always some truth in these claims. But if one’s goal is a company-wide process and it’s backed by senior management it can usually be achieved, especially at a high level of abstraction. Once the process is standardized it is possible to configure a single installation of an ERP application to support the new standard processes.

We’ve been impressed by the number of CEOs who are determined to make this happen and by the results they are generating. In some cases the companies have had ERP for years and are simply tired of the costs and problems associated with supporting multiple different versions of their ERP software. In other cases companies are just installing ERP, have learned from others, and are waiting to install ERP modules before they arrive at standard processes. They are determined there will be a single installation of an application. In either case the road to improving the ERP installation lies through enterprise process redesign and standardization. Figure 16.12 illustrates the goal of Company X.

When we first met CEOs and CIOs and heard these stories we began to worry that they were simply creating process silos that would be just as troublesome in a few years as the departmental and business unit silos they currently struggled with. Let’s consider Company X. In Europe it sells large manufacturing equipment. In Japan it sells small commodity items. Surely the two types of sales are different. Remember how we discussed Porter in Chapter 2 and concluded that competitive advantage accrued only to companies that were able to integrate all the processes in a single value chain in the best possible way. Surely if one wanted to create a well-integrated value chain for large manufacturing equipment and another for the sale of small commodity items one would modify the sales process in different ways to integrate with and to support the different marketing and manufacturing processes.

Enterprise Resource Planning and Business Process Management Suite

Without knowing it Company X is preparing to move to BPMS. They now have enterprise-level process managers and teams and they are now struggling with how to keep their simplified ERP structure, while simultaneously allowing different divisions to tailor their processes to better integrate with the overall goals of their specific value chains. A salesperson from one of the BPMS vendors explains to Company X that BPMS can provide the best of both worlds. The company can use a BPMS product to separate dependencies between ERP modules and to provide tailoring within the BPMS package, without having to tailor the ERP modules. At that point they will have a single installation of an ERP application and the ability to tailor specific processes.

Figure 16.13 illustrates where Company X may end up a few years after it has installed a BPMS package to manage its sales process. In this case the standard process has been defined in a BPMS product. Rather than tailoring ERP modules all the tailoring that needs to be done is done within the BPMS tool. We’ve represented these as activity boxes 1 and 2 in Figure 16.13. (Put more technically, one creates business rules within the BPMS environment that analyze and prepare data to be submitted to the ERP modules. As an added benefit, the ERP modules can be managed by the BPMS tool rather than compiled together. Thus, now the BPMS product manages ERP and allows the user to make changes rather easily, Company X can avoid the problems companies with large compiled sets of ERP modules now struggle with.) Company X may very well find that they can use the BPMS system to tailor their basic sales processes to support multiple value chains, while simultaneously maintaining a single installation of an ERP application.

In a completely rational world we might advise Company X to skip the phase they are in and move to a BPMS effort. In reality, however, BPMS is still a new technology and Company X’s people are a bit too conservative to jump on a new technology. They are, however, very much aware of how much the multiple versions of ERP modules are costing them, and they are motivated to try and eliminate that problem. And they have figured out that they will need to control processes at the enterprise level to bring about a single installation of ERP. Thus Company X has moved into enterprise process work in a very serious way and is in essence preparing itself for more process work in the future.

We have been impressed with what we’ve seen. Many business process management (BPM) gurus in the 1990s urged companies to focus on enterprise process work and to assign enterprise-level process managers. In reality, most companies focused on specific process redesign efforts. Today, a surprising number of large companies have definitely moved beyond one-off process redesign efforts and are focused on process management and corporate-wide process standardization. It’s a major step forward and will undoubtedly lead to even more interesting things in the future.

The scenario we have just suggested illustrates the problem that ERP vendors face. One of the most popular uses of BPMS software to date is to create process management systems that can manage ERP applications. By keeping ERP applications generic and doing any special tailoring in the BPMS application the company reduces its costs and increases its control and its ability to change rapidly. The company also gains the ability to mix applications from different ERP vendors, since the BPMS product can potentially manage whatever database the company wants to use and keep it independent of any particular ERP module.

This movement constitutes a clear threat to the dominance of the leading ERP vendors, and if it proceeds will significantly reduce the importance of ERP software at leading companies. ERP vendors have responded by seeking to generate their own BPMS solutions and offering them as alternatives to other BPMS products. Thus SAP is developing NetWeaver, Oracle is working on its own Business Process Management Suite, and Microsoft is developing its BizTalk server. Broadly speaking, each of these products is primarily an application integration tool. ERP vendors will have trouble matching what BPMS vendors can do because they are trying to support their existing installed base while simultaneously innovating, and that’s hard for any software vendor. While the leading BPMS vendors support business processes with lots of employee activities, ERP vendors have traditionally focused on automated processes and will have to come up to speed with expanded workflow capabilities to match the capabilities of the best BPMS vendors. Similarly, ERP vendors have traditionally designed their products for IT developers, as the ARIS diagram we showed earlier suggests. ERP vendors will also have to rethink their entire positioning if they hope to create products with interfaces that are friendly enough to allow managers to modify processes.

From all we’ve said you might conclude that we don’t think most ERP vendors will be able to transition and generate the kind of highly flexible BPMS applications that companies will be demanding in the next decade. In fact, we think it will be hard and we don’t expect the small ERP vendors to manage it. The large ERP vendors—SAP, Oracle, and Microsoft—have enough resources and technical sophistication that they ought to be able to do it. Indeed, they are already making a major effort, and we expect them to intensify their efforts in the years ahead. Thus, although it is easy to think of ERP and BPMS as separate technologies, in fact they will merge in the years ahead. BPMS vendors will add application-specific knowledge to their products and ERP vendors will add BPMS engines to their suites. We expect some interesting mergers as ERP and BPMS vendors struggle to figure out how to create the best applications for their customers.

Notes and References

Davenport, Thomas H., Mission Critical: Realizing the Promise of Enterprise Systems, Harvard Business School Press, 2000. Having helped launch the BPR movement Davenport noticed that by the late 1990s many companies were implementing process change with packaged applications from ERP vendors. In his book he reports his investigations into the whole trend. When Davenport wrote the book he was the Director of the Institute for Strategic Change at Andersen Consulting. Davenport is now Director of the Business Process Institute at Babson College. More information is available at http://www.babson.edu.

The software and business process theorist who has dominated the ERP space is August-Wilhelm Scheer, Head of the Institut für Wirtschaftsinformatik at the University of Saarlandes in Germany. Scheer started by developing techniques for modeling software systems and founded IDS Scheer GmbH to promote his approach and sell the software tool ARIS. Recently IDS Scheer was acquired by Software AG. The ARIS approach is used by SAP, the largest packaged application software (ERP) vendor. Some of Scheer’s books include the following:

Scheer, A.-W, ARIS—Business Process Modeling (3rd ed.), Springer, 2000. This book focuses on process modeling, especially as it is done with ARIS in SAP R/3. A book for IT developers, not business managers.

Scheer, A.-W., ARIS—Business Process Frameworks (3rd ed.), Springer, 1999. This book focuses on the ARIS approach to process redesign using SAP R/3 products and the ARIS software tool. It talks about aligning strategy and processes, but it is a book for IT developers and not business managers.

Scheer, A.-W., Business Process Engineering: Reference Models for Industrial Enterprises (2nd ed.), Springer, 1994. The book lays out Scheer’s basic approach to process reengineering. A book for IT developers, not business managers.

All of Scheer’s books are very technical and written for software architects, not business managers. More information on IDS Scheer is available at http://www.ids-scheer.com.

The main source of information on SAP and the diagrams used in this chapter was the SAP website (http://www.sap.com).

Curran, Thomas, Gerhard Keller, and Andrew Ladd, SAP R/3 Business Blueprint: Understanding the Business Process Reference Model, Prentice Hall, 1998. A good introduction to the use of SAP modules to model business processes. Lots of detailed ARIS examples. A book for IT developers, not business managers.

Conference Board Study, ERP Post Implementation Issues and Best Practices, December 2000.

Worthen, Ben, “Nestlé’s ERP Odyssey,” CIO Magazine, May 14, 2002, pp. 62–70.

IBM, and Siebel Systems, Reinventing the Integrated Customer-driven Enterprise (Special Report), IBM, 2002. Siebel has since been acquired by Oracle.

Woods, Dan, and Jeffrey Word, SAP NetWeaver for Dummies, Wiley, 2004. A good introduction to NetWeaver, SAP’s evolving BPMS entry.

Forndron, Frank, Thilo Liebermann, Marcus Thurner, and Peter Widmayer, mySAP ERP Roadmap: Business Processes, Capabilities, and Complete Upgrade Strategy, SAP Press, 2006. This book describes how SAP is modifying its ERP modules (converting them to mySAP modules) that will be able to run with NetWeaver.

SAP has created a special website within their SAP Community Network for business process experts that is designed to help business analysts learn about the latest developments in BPM. More information is available at http://www.sdn.sap.com/irj/sdn/bpx.