Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

The BPR (Business Process Reengineering or Redesign) movement erupted on the business scene in the early 1990s promising to save organizations, especially large corporations, from certain decline by radically transforming their work practices with the help of IT systems. Business Process Management (BPM) as a business and research discipline followed a few years later.

The founding fathers of the BPR movement, Davenport, Hammer, Short and Champy [3, 4, 7–9] saw the transition to a business process view as a way of parting from the industrial age way of organizing work for predictable markets.

Whereas in the industrial age the main focus was on scaling production to meet an ever growing demand for generic products, businesses now needed a way of guaranteeing affordable quality, on-time delivery of products and service that meet (often individual) customer needs.

Existing ways of working, whether in manufacturing or in the service industries, were seen as too complicated and intricate. A radical simplification was seen as necessary. This simplification was powered by the possibilities of sharing information across time and space afforded by IT systems. It became possible to design work with the outcome in mind, the product or service matching expectations delivered on-time and within a budget. The intricacies of delivering these products and services could be greatly simplified with an emphasis on the collaboration between individuals across departments.

In this paper we show that present day most common BPM tools focus more on the intricacies of delivering a product and service rather than on the outcome and collaboration envisioned by the founding fathers. We argue that it is both desirable and possible to add a modeling phase where the focus is on the collaboration and outcome before modeling the details of the process. Our purpose is not to propose yet another BP modeling notation, nor to trivialize BP modeling. Our aim is to help BP modelers to realize that BP modeling is not solely about describing tasks and their sequencing, that more high-level descriptions enables them to design better processes.

2 Outcome vs. Tasks

From the early writings of Davenport and Short [4], and Hammer [7] to their subsequent books [3, 8, 9], the vision for BPR remained remarkably steady. The organization of work as a fragmentation of the assembly of a complete product into a series of routine tasks, while necessary and useful during the industrial age, was preventing companies from offering the products and services customers were expecting in the 1980s.

This is beautifully said by Hammer in the following quote [7]:

“Conventional process structures are fragmented and piecemeal, and they lack the integration necessary to maintain quality and service. They are breeding grounds for tunnel vision, as people tend to substitute the narrow goals of their particular department for the larger goals of the process as a whole. When work is handed off from person to person and unit to unit, delays and errors are inevitable. Accountability blurs, and critical issues fall between the cracks. Moreover, no one sees enough of the big picture to be able to respond quickly to new situations. Managers desperately try, like all the king’s horses and all the king’s men, to piece together the fragmented pieces of business processes.”

The managers and supporting staff are called by Hammer and Champy [9]: “the glue that holds together the people who do the real work”. They state that in many organizations the cost of the glue has surpassed the cost of direct labor. This, they argued, leads to “Inflexibility, unresponsiveness, the absence of customer focus, an obsession with activity rather than result.” Likewise Davenport and Short [4] say that “difficult interfunctional” (inter-departmental) issues were hampering many quality improvement efforts in manufacturing companies. They report on an example where different departments within a company each optimized its performance but the overall process “was quite lengthy and unwieldy” [4]. Hammer and Champy [9] therefore advocate that processes “must be kept simple.” Designing processes with many handovers from one person to another and what’s more crossing department boundaries is unlikely to yield good results.

The remedy envisioned in BPR was to see the whole process, from end to end, and focus more on the results created by the process than the tasks and their coordination. The definition of the concept of business process, as set forth by Hammer and Champy [9] embodies both views:

“a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer.”

It is easy to get carried away by the focus on the activities comprising the process at the expense of the input, output and value. There is probably a natural tendency for modelers to think of a process in terms of a sequence of activities. There was also the need to implement an IT system that supports the process, hence the need to give the details of the activities.

This was, however, not at all what was meant by Hammer and Champy. Addressing this problem at a later stage, Hammer provided an updated definition of a business process [8]: “a group of tasks that together create a result of value to a customer” and specified that “The key words in this definition are ‘group,’ ‘together,’ ‘result,’ and ‘customer’.” Note that tasks is not in the list of key words. This is because for Hammer the tasks are less important. He defines the process perspective as seeing the [8] “collection of tasks that contribute to a desired outcome” rather than isolated tasks. He goes as far as saying that [8]: “the essence of a process is its inputs and its outputs [..] Everything else is detail.” therefore recommends that a process be seen as a black box that creates value by transforming inputs into outputs.

This black box view can be understood as the direct result of the clean slate approach advocated by Hammer [7, 8] and Hammer and Champy [9]. In this approach there is no reason to analyze the existing process because it will only tie the analysts’ minds into the old ways of working. The process should be created anew by focusing only on the desired results. This is a marked difference from the other BPR current by Davenport [3] and Davenport and Short [4]. They emphasize the need for a process vision, outcome and objectives, but still recommend the analysis of the existing process citing four reasons: (1) Developing a common understanding among the people involved in the process redesign; (2) Easing the migration to the new process; (3) Recognizing problems in the existing process so as not to repeat them; (4) Providing a baseline for measuring the new process.

Business Process Reengineering, more than Business Process Redesign, sought to make radical transformation from a clean sheet. If only minor improvements were needed, e.g. 10 % increase in profit or 10 % decrease in cost, no reengineering was called for according to Hammer and Champy, rather, a quality program or some such was entirely sufficient [9]. Our point here is not to argue for or against radical change. We do argue in favor of an initial step in business process modeling where the process activities are not modeled at all. Process modeling should begin by describing the process as a black box, as advocated by Hammer and Champy, focusing solely on the outcomes of the process for its stakeholders and not activities, their sequencing or their attribution to roles.

In essence, we seek to model how the business process brings suppliers, customers and regulators together to create value for them all. It is useful to remember that Davenport and Short envisioned early on the use of groupware to improve interpersonal processes [4]. Likewise, Hammer and Champy saw companies, not as asset portfolios but as “people working together to invent, make, sell, and provide service.” [9].

3 Scope of the Process or Who is the Customer

The focus on customer satisfaction as the focal point of process design is common to both currents of BPR. Davenport and Short [4] identify two main process characteristics. Processes have customers (internal or external) and they cross organizational boundaries. For Hammer [8] the first principle of process design is to be customer-driven.

The customer-driven focus ties back to the outcome of the process. The first accounts of these outcomes were quite simple. Hammer and Champy [9], for example, define that the order fulfillment process ends when the goods are delivered. Hammer [8] moves this end point to when the customer has paid the bill, defining three outputs for the process: the delivered goods, the satisfied customer and the paid bill. The paid bill, according to Hammer [8], is the best indication that the customer is satisfied. Moving the end point of the process and including more outputs in the outcome is synonymous with the expansion of the scope of the process. Davenport and Short [4] consider this scope expansion to be a key issue of process analysis, for example adding order entry into the sales process.

Hammer [8] advocates to analyze the process from the outside-in so that customer requirements drive the process design. This means beginning by defining what quality, flexibility, delay, price and such that customers expect from the process. There is an inherent limitation in this reasoning in that it considers the customer in the singular form. With respect to his earlier work, Hammer [8] stretches this notion of single customer to multiple customers. He lists all of the following as customers of a pharmaceutical company selling a medicine [8]:

  1. A.

    “The patient who takes a medicine.

  2. B.

    The physician who prescribes it.

  3. C.

    The pharmacist who dispenses it.

  4. D.

    The wholesaler who distributes it.

  5. E.

    The Food and Drug Administration scientists and officials who approve its use.

  6. F.

    The insurance company that pays for it”

The question is then, what makes these people customers of the pharmaceutical company? What is the determinant of a customer? Hammer definition of a customer is [8]: “Customers are people whose behavior the company wishes to influence by providing them with value.” It so happens that the people whose behavior the company wishes to influence include those we call suppliers. Indeed, Suppliers who do not receive what they expect from a client can also refuse to be part of its process and thus avoid being influenced and given value by the process. Hammer [8] acknowledges this by stating that the process should include measures that ensure that the company doesn’t go broke trying to satisfy customers. This means that despite earlier claims by the BPR proponents, the company cannot simply design a process that caters to all the wishes of its customers. Most business processes include steps that cater to the different needs of the stakeholders involved [15]. All the stakeholders participating in the process have to somehow receive some value from their participation. Notice that this may be negative value for so called disfavored users [16].

4 BPM Missing the Big Picture

In BPM the accepted definition of a business process is quite similar to the one proposed by Hammer and Champy (see above), namely [11]: “a set of partially ordered activities intended to reach a goal.”

Unfortunately, most of the attention of practitioners and researchers alike has been on the set of activities rather than on the goal (or outcome). As a result, the vast majority of notations used for business process modeling e.g., BPMN, YAWL, UML, IDEF, Petri nets, EPC, have elaborate constructs for modeling activities, their sequence, exceptions, messages, roles etc.

Figure 1 shows a typical business process model designed with BPMN. This is the level of detail at which most business processes are modeled. We see the sequence of activities assigned to the patient and to the doctor’s office. What cannot be seen in this model, at least not explicitly, is why these two stakeholders (the patient and the doctor’s office) engage in this process. What is the outcome for them? With enough scrutiny, we can see that an “illness occurs” for the patient who then begins on a long track of dialoging with the doctor’s office. By the end of the process, the doctor’s office sends a medicine that is received by the patient. What is the effect of the medicine on the patient and what the doctor’s office receives in return for its involvement in this process, is not part of the model.

Fig. 1.
figure 1

Example of a BPMN business process model (source: [12])

Full size image

As we can see very little or no provision is given to modeling the outcome, goal or value for the stakeholders who participate in the process. This is essentially the same as putting together the industrial era tasks, dividing them among those who perform the process, and hoping for the best. Remember Hammer’s definition that a process must be first viewed as something that transforms an input into an output. Where are the collection of activities, the togetherness of the stakeholders? Where is the value of the process and for whom?

Also not part of the process in Fig. 1 are the other stakeholders mentioned by Hammer, e.g. the pharmacist, the wholesaler, the FDA. Adding them into the process model, at the level it is described in Fig. 1, will render an already complicated model very cumbersome. By modeling the process as a black box, it is possible to show its effect on multiple stakeholders while keeping the model quite simple. This is the subject of the following section.

5 Collaboration Over Task Orchestration

In Fig. 2, we show one way of modeling processes as black boxes and their outcome for the stakeholders involved. The modeling notation used is SEAM [19] but others can be used too (See Related Work).

Fig. 2.
figure 2

A collaboration and outcome view of the Treatment business process

Full size image

The enclosing block arrow represents the Healthcare market segment. At the top we represented a supplier called Health Organization that provides a service called Treat Patient to a Stakeholder called Patient. The two stakeholders are bound by a relationship that we call Treatment. It is this relationship that represents the business process as a black box. The business process creates changes on both the Health Organization and the Patient at the same time. In this example the Patient goes from the initial state of being Sick to the final state of being Well. Simultaneously, the Patient’s record in the Health Organization is transformed from Sick Patient to Well-being Patient. The Well-being Patient state and the Well state are the final states of the process and together define its outcome. How these transformations are done, through what sequence of actions is not modeled here. Only the inputs and outputs as described by Hammer and Champy [9] and Hammer [8].

The upper Health Organization and the Patient are shown as black boxes. Only their activities and states are shown. The bottom block arrow names Health Organization is a white box representation. It shows the stakeholders participating in the provision of the Treat Patient service. Here again, we see a process called Treatment. This process is internal to the Health Organization. It connects the internal stakeholders that the Patient may or may not see. We described those found in Hammer’s description quoted above, namely: Physician, Pharmacist, Wholesaler and Food and Drug Administration (FDA). Each one or more states corresponding to the outcome of the process. The Physician, for example, has three states, she records the Sick Patient, the Well-Being patient and the Paid Treatment. Notice that we don’t show the activities with an input and output as in the upper level stakeholders. This is to show that the notation can be used with even more parsimony.

With the global view afforded by the model of the process as a black box and its outcomes it is possible to expand or shrink the scope of the project as envisioned by the founding fathers of BPR.

We’d like to emphasize that our point is not to “trivialize” process modeling by reducing it to the black box view. Our proposal is to augment BPMN style process models with with a more abstract view that affords to reflect on the process as managing a set of relationships between stakeholders. It has been shown in [20] that with SEAM it is possible to drill down from the black box view of the process to a BPMN like process diagram embedded in its context.

6 Related Work

The representation of the process as a collaboration between several stakeholders was imported into SEAM from Catalysis [2] where it is called a joint action: an abstraction of “multiple interactions” that shows “the net effect on all participants.” Note that there is a concept called black-box pool in BPMN. It is mostly used to represent external stakeholders or when there is no need to represent the set of activities in the pool. This however does not show the collaboration and its effects. In BPMN, the closest concept to our description of a collaboration (joint action) is the Transaction a Sub-Process that [12], “leads to an agreed, consistent, and verifiable outcome across all participants.”

As we have said in Sect. 5, SEAM is not the only method that can be used in order to more clearly view the net effect of a business process on its stakeholders. Other methods or frameworks include, the state-oriented business process modeling [10], BMM [13], SIPOC [18], e3Value [6] and BMG [5, 14].

A simple example is Samarin’s [17] proposal to begin by modeling a business process as a black box, showing only its input, output, guidance and resources with an IDEF0 diagram. This goes a long way toward modeling the essence of the process, but stops short of explicitly showing the collaboration between stakeholders and the outcome for each one.

7 The Loss of the Big Picture in BPMDS

A direct parallel can be drawn between the road taken by the BP modeling tools and the Working Conference on Business Process Modeling Development and Support (BPMDS). BPMDS was created in 1998 by Ilia Bider and Maxim Khomyakov as workshops whose goal was to [1], “facilitate discussions of the topics relevant to the practice of modeling and building computerized support [to business processes].” Unlike most academic conferences, the organizers of BPMDS made serious efforts to bring together practitioners and researchers in the field of business process modeling and to maintain open discussions about business process issues. Access to practitioners was greatly facilitated with help available for transforming their papers into academic articles, and sessions were devoted to open discussions and brainstorming about business process issues. However, as BPMDS enjoyed increasing success with academics, which ensured its survival, it became harder to invite practitioners and to discuss general purpose business process issues. BPMDS became a regular working conference devoted almost exclusively to technical academic paper presentation. This evolution made a powerhouse of academic publishing, but at the loss of its identity as a meeting place for practice and research devoted to discussing business process topics.

8 Conclusions

In this short paper we discussed the vision of the pioneers of the BPR movement, who viewed business processes as connecting and providing value to their stakeholders. We showed that this vision seems to have been overlooked by business process modelers with the result that business model modeling notations offer scarcely any modeling construct for that purpose. We then described, ever so briefly, a modeling notation that has explicit elements for modeling a business process as a collaboration among its stakeholders, including the value it provides them. We hope that this work will be a first step toward a rebirth of the BPR vision for BPM practitioners and researchers.

One interesting research that can be spawned from this was of thinking is to trace every task in a business process to some outcome for a stakeholder. This would establish traceability links between tasks and outcomes and will go toward one of the wishes of BPR, namely to remove all tasks that do not bring value. Without knowing which value is created by which task it is a guessing game to remove tasks from a process.