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 The Origins of BPM

BPM has two primary intellectual antecedents. The first is the work of Shewhart and Deming (Shewhart 1986; Deming 1953) on statistical process control, which led to the modern quality movement and its contemporary avatar, Six Sigma. This work sought to reduce variation in the performance of work by carefully measuring outcomes and using statistical techniques to isolate the “root causes” of performance problems – causes that could then be addressed. Much more important than the details of upper and lower control limits or the myriad of other analytic tools that are part of quality’s armamentarium are the conceptual principles that underlie this work: the core assumption that operations are of critical importance and deserve serious attention and management; the use of performance metrics to determine whether work is being performed satisfactorily or not; the focus on hard data rather than opinion to isolate the root causes of performance difficulties; the concept of blaming the process not the people, that performance shortcomings are rooted in objective problems that can be identified and dealt with; and the notion of never-ending improvement, that solving one set of problems merely buys an organization a ticket to solve the next round.

The quality approach suffered from two limitations, however. The first was its definition of process as essentially any sequence of work activities. With this perspective, an organization would have hundreds or even thousands of processes, from putting a parts box on a shelf to checking customer credit status, and the machinery of quality improvement could be applied to any and all of these. Focusing on such narrow-bore processes, however, is unlikely to have strategic significance for the enterprise as a whole; on the other hand, it is likely to result in a massive number of small-scale projects that can be difficult to manage in a coherent fashion. Even more seriously, the quality school took as its goal the elimination of variation and the achievement of consistent performance. However, consistent is not a synonym for good. A process can operate consistently, without execution flaws, and still not achieve the level of performance required by customers and the enterprise.

The other primary antecedent of BPM, my own work on Business Process Reengineering (Hammer 1990; Hammer and Champy 1993), had complementary strengths and weaknesses. On the one hand, at least in its early days, reengineering was positioned as an episodic rather than an ongoing effort; it lacked the continuous dimension of quality improvement. It also did not have as disciplined an approach to metrics. On the other hand, it brought two new wrinkles to the process world. The first was its refined definition of process: end-to-end work across an enterprise that creates customer value. Here, putting a box on a shelf would not qualify as a meaningful process; it would merely be a small part of an enterprise process such as order fulfillment or procurement. Addressing large-scale, truly end-to-end processes means focusing on high-leverage aspects of the organization’s operations and so leads to far greater results and impacts. In particular, by dealing with processes that cross functional boundaries, reengineering was able to attack the evils of fragmentation: the delays, nonvalue-adding overhead, errors, and complexity that inevitably result when work transcends different organizations that have different priorities, different information sources, and different metrics. The other new theme introduced by reengineering was a focus on process design as opposed to process execution. The design of a process, the way in which its constituent tasks are woven together into a whole, was not of much concern to the founders of the quality school; they made a tacit assumption that process designs were sound, and that performance difficulties resulted from defects in execution. Reengineering recognized that the design of a process in fact created an envelope for its performance, that a process could not perform on a sustained basis better than its design would allow. Should performance requirements exceed what the design was capable of, the old design would have to be discarded and a new one substituted in its place.

2 The Process Management Cycle

Over the last decade, these two approaches to process performance improvement have gradually merged, yielding modern Business Process Management – an integrated system for managing business performance by managing end-to-end business processes. Figure 1 depicts the essential process management cycle. It begins at the bottom, with the creation of a formal process. This is not a minor, purely formal step. Many organizations find that certain aspects of their operations are characterized by wild variation, because they lack any well-defined end-to-end process whatsoever. This is particularly true of low-volume, creative processes such as product development or customer relationship management. In essence, they treat each situation as a one-off, with heroics and improvisation substituting for the discipline of a well-defined process. Such heroics are of course unreliable and unsustainable.

Fig. 1
figure 1

The essential process management cycle

Full size image

Once a process is in place, it needs to be managed on an ongoing basis. Its performance, in terms of critical metrics that relate to customer needs and company requirements, needs to be compared to the targets for these metrics. Such targets can be based on customer expectations, competitor benchmarks, enterprise needs, and other sources. If performance does not meet targets, the reason for this shortcoming must be determined. Broadly speaking, processes fail to meet performance requirements either because of faulty design or faulty execution; which one is the culprit can generally be determined by examining the pattern of performance inadequacy. (Pervasive performance shortcomings generally indicate a design flaw; occasional ones are usually the result of execution difficulties.) If the fault lies in execution, then the particular root cause (such as inadequate training, or insufficient resources, or faulty equipment, or any of a host of other possibilities) must be determined. Doing so is a challenging undertaking, because of the large number of possible root causes; as a rule, however, once the root cause has been found, it is easy to fix. The opposite is true of design problems: they are easy to find (being indicated by consistently inadequate performance) but hard to fix (requiring a wholesale rethinking of the structure of the process). Once the appropriate intervention has been chosen and implemented, the results are assessed, and the entire cycle begins again.

This cycle is derived from Deming’s PDCA cycle (Plan Do Check Act) (Deming 1986), with the addition of the attention to process design. Although this picture is quite simple, it represents a revolutionary departure for how enterprises are managed. It is based on the premise that the way to manage an organization’s performance is not by trial and error, not by pushing people harder, and not through financial manipulation, but through the deliberate management of the end-to-end business processes through which all customer value is created. Indeed, BPM is a customer-centered approach to organizational management. Customers neither know nor care about the many issues that typically are at the center of most executives’ attention: strategies, organizational designs, capital structures, succession plans, and all the rest. Customers care about one thing and one thing only: results. Such results are not acts of God or the consequence of managerial genius; they are the outputs of business processes, of sequences of activities working together. Customers, results, and processes form an iron triangle; an organization cannot be serious about anyone without being equally serious about the other two.

To illustrate the process management cycle in action, consider the claims handling process at an auto insurance company. The old process consisted of the claimant reporting an accident to an agent, who passed it on to a customer service representative at the insurer, who passed it on to a claims manager, who assigned it with a batch of other claims to an adjustor, who then contacted the claimant and scheduled a time to inspect the vehicle. Because of the handoffs in this process, and the associated inevitable misunderstandings, it typically took 7–10 days before the adjustor arrived to see the vehicle. While this was no worse than others in the industry, the insurer’s CEO recognized that this represented an opportunity to improve customer satisfaction at a “moment of truth,” and insisted that this cycle time be reduced to 9 hours. No amount of productivity improvement in the individual activities would have approached this target, since the total actual work time was very little – the problem was in the process, not in the tasks. Accordingly, the company created a completely new process, in which claimants called a toll-free phone number and were connected directly to an adjustor, who took responsibility for the case and dispatched a teammate driving a mobile claims van in the field to the vehicle; upon arriving, the teammate would not only estimate the amount of damage but try to settle the claim on the spot. This new process was both much more convenient for customers and less expensive for the company, and was key to the company increasing revenue by 130% while increasing headcount by only 5%.

However, this was the beginning, not the end, for the process. Just having a good design does not guarantee continued good results, because problems are inevitable in the real world. Computers break, people do not absorb their training, data gets corrupted, and so on and so forth, and as a result a process does not achieve the performance of which it is capable. The company used process management to monitor the performance of the process and recognize and correct such performance problems. It also stayed alert to opportunities to modify the process design to make it perform even better. At one point, the company realized that the process as designed was not necessarily sending the most appropriate adjustor to the scene of the accident but just the next available one; a change to the design was made to address this. Of late, the company’s management has gone further. They recognized flaws in the process design – for instance, that it required adjustors to make damage estimates “at midnight in the rain”. Accordingly, they have come up with an even newer process, in which the claimant brings the damaged car to a company facility and picks up a loaner car; the adjustor estimates the damage at this facility and then arranges for the repair to be done by a garage. When the car is fixed, the claimant comes back and exchanges the loaner for his own car. This is much easier for the customer, and much more accurate and less costly for the company.

3 The Payoffs of Process Management

Through process management, an enterprise can create high-performance processes, which operate with much lower costs, faster speeds, greater accuracy, reduced assets, and enhanced flexibility. By focusing on and designing end-to-end processes that transcend organizational boundaries, companies can drive out the nonvalue-adding overhead that accumulates at these boundaries. Through process management, an enterprise can assure that its processes deliver on their promise and operate consistently at the level of which they are capable. Through process management, an enterprise can determine when a process no longer meets its needs and those of its customers and so needs to be replaced.

These operational benefits of consistency, cost, speed, quality, and service translate into lower operating costs and improved customer satisfaction, which in turn drive improved enterprise performance. Process management also offers a variety of strategic benefits. For one, process management enables companies to respond better to periods of rapid change (such as ours). Conventional organizations often do not even recognize that change is happening until it is reflected in financial performance, by which time it is too late; even should they recognize that change has occurred, they have no mechanism for responding to it in a disciplined fashion. Under a process management regime, by contrast, change is reflected in the decline of operational performance metrics, which are noted by the process management system; the design of the process is then the tool through which the organization can respond to this change. Process management also provides an umbrella for a wide range of other performance improvement initiatives, from globalization and merger integration to ERP implementation and e-business. Too many enterprises treat each of these phenomena as independent, which leads to a proliferation of uncoordinated and conflicting change initiatives. In fact, they are all either mechanisms for supporting high-performance processes or goals that can be achieved through them. Linking all of a company’s improvement efforts under the common umbrella of process management, and managing them in an integrated fashion, leverages a wide range of tools and deploys the right tool to the right problem.

Thousands of organizations, large and small, private and public, are reaping extraordinary benefits by managing their end-to-end business processes. A handful of recent examples:

  • A consumer goods manufacturer redesigned its product deployment process, by means of which it manufactures goods and delivers them to its distribution centers; inventory was reduced by 25% while out-of-stock situations declined by 50%.

  • A computer maker created a new product development process, which reduced time to market by 75%, reduced development costs by 45%, and increased customer satisfaction with new products by 25%.

  • A capital goods manufacturer increased by 500% the accuracy of the availability dates on new products that it gave customers and reduced its supply chain costs by up to 50%.

  • A health insurer created a new process for engaging with its customers and reduced costs by hundreds of millions of dollars while improving customer satisfaction.

Something to note in these and many other cases is the simultaneous achievement of apparently incompatible goals: reducing inventory, say, while also reducing out-of-stocks. Traditional organizations view these as conflicting goals and trade one off against another; process-managed organizations recognize that they can be improved by creating a new process design.

4 The Enablers of Process

Despite its elegance and power, many organizations have experienced difficulties implementing processes and process management. For instance, an electronics company designed a new product development process that was based on cross-functional product teams, but they were unable to successfully install it and get it operating. The reason, as they put it, is that “you can’t overlay high performance processes on a functional organization”. Traditional organizations and their systems are unfriendly to processes, and unless these are realigned to support processes, the effort will fail.

There are five critical enablers for a high-performance process; without them, a process will be unable to operate on a sustained basis (Hammer 2007).

Process design. This is the most fundamental aspect of a process: the specification of what tasks are to be performed, by whom, when, in what locations, under what circumstances, to what degree of precision, with what information, and the like. The design is the specification of the process; without a design, there is only uncoordinated individual activity and organizational chaos.

Process metrics. Most enterprises use functional performance metrics, which create misalignment, suboptimization, and confusion. Processes need end-to-end metrics that are derived from customer needs and enterprise goals. Targets need to be set in terms of these metrics and performance monitored against them. A balanced set of process metrics (such as cost, speed, and quality) must be deployed, so that improvements in one area do not mask declines in another.

Process performers. People who work in processes need a different set of skills and behaviors from those who work in conventional functions and departments. They need an understanding of the overall process and its goals, the ability to work in teams, and the capacity to manage themselves. Without these characteristics, they will be unable to realize the potential of end-to-end work.

Process infrastructure. Performers need to be supported by IT and HR systems if they are to discharge process responsibilities. Functionally fragmented information systems do not support integrated processes, and conventional HR systems (training, compensation, and career, etc.) reinforce fragmented job perspectives. Integrated systems (such as ERP systems and results-based compensation systems) are needed for integrated processes.

Process owner. In a conventional organization, no one is responsible for an end-to-end process, and so no one will be in a position to manage it on an end-to-end basis (i.e., carry out the process management cycle). An organization serious about its processes must have process owners: senior managers with authority and responsibility for a process across the organization as a whole. They are the ones who perform the work illustrated in Fig. 1.

Having some but not all of these enablers for a process is of little or no value. For instance, a well-designed process targeted at the right metrics will not succeed if performers are not capable of carrying it out or if the systems do not support them in doing so. Implementing a process in effect means putting in place these five enablers. Without them, a process may be able to operate successfully for a short term but will certainly fail in the long run.

5 BPM Capability for Process

The experiences of hundreds of companies show that not all are equally able to install these enablers and so succeed with processes and process management. Some do so effectively, while others do not. The root cause of this discrepancy lies in whether or not an enterprise possesses four critical capabilities that are prerequisites to its summoning the resources, determination, and skills needed to succeed with processes (Hammer 2007).

Leadership. The absolute sine qua non for effective deployment of process management is engaged, knowledgeable, and passionate senior executive leadership of the effort. Introducing processes means introducing enormous change – realigning systems, authority, modes of operation, and more. There is no change that most organizations have experienced that can compare to the disruption that the transition to process brings. Unless a very senior executive makes it his or her personal mission, process will run aground on the shoals of inertia and resistance. Moreover, only a topmost executive can authorize the significant resources and changes that process implementation requires. Without such leadership, the effort is doomed; with it, all other problems can be overcome.

Culture. A Chief Operating Officer once remarked to me, “When one of my people says he doesn’t like process, he really means that he doesn’t want to share power”. Process, with its focus on customers, outcomes, and transcending boundaries is anathema to those who are focused on defending their narrow bit of turf. Process demands that people at all levels of the organization put the customer first, be comfortable working in teams, accept personal responsibility for outcomes, and be willing to accept change. Unless the organization’s culture values these principles, processes will just roll off people’s backs. If the enterprise culture is not aligned with these values, leadership must change the culture so that it does.

Governance. Moving to process management, and institutionalizing it over the long run, requires a set of governance mechanisms that assign appropriate responsibilities and ensure that processes integrate with one another (and do not turn into a new generation of horizontal silos). In addition to process owners, enterprises need a process office (headed by a Chief Process Officer) that plans and oversees the program as a whole and coordinates process efforts, as well as a Process Council. This is a body consisting of the process owners, the executive leader, and other senior managers, which serves as a strategic oversight body, setting direction and priorities, addressing cross-process issues, and translating enterprise concerns into process issues. These mechanisms need to be put in place to manage the transition to process, but continue on as the essential management superstructure for a process-managed enterprise.

Expertise. Implementing and managing processes is a complex and high stakes endeavor, not for the inexperienced or the amateur. Companies need cadres of people with deep expertise in process design and implementation, metrics, change management, program management, process improvement, and other relevant techniques. These people must have formal methodologies to follow and must be sustained with appropriate career paths and management support. While not an insuperable barrier, many organizations fail to develop and institutionalize this capability, and then unsurprisingly find themselves unable to carry out their ambitious programs.

Organizations without these four capabilities will be unable to make process management work, and must undertake urgent efforts to put them in place. Developing leadership is the most challenging of these; it typically requires the intervention of a catalyst, a passionate advocate of process with the ear of a potential leader, who must patiently familiarize the candidate with the concepts of process and their payoffs. Reshaping culture is not, despite myths to the contrary, impossible, but it does take time and energy. The other two are less difficult, but are often overlooked.

6 The Principles of Process Management

It can be helpful to summarize the concepts of process management in terms of a handful of axiomatic principles, some obvious, some not, that together express its key themes.

All work is process work. Sometimes the assumption is made that the concepts of process and process management only apply to highly structured, transactional work, such as order fulfillment, procurement, customer service, and the like. Nothing could be further from the truth. The virtues of process also adhere to developmental processes, which center on highly creative tasks, such as product development, demand creation, and so on. Process should not be misinterpreted as a synonym for routinization or automation, reducing creative work to simplistic procedures. Process means positioning individual work activities – routine or creative – in the larger context of the other activities with which it combines to create results. Both transactional and development processes are what is known as core processes – processes that create value for external customers and so are essential to the business. Organizations also have enabling (or support) processes, which create value for internal customers; these include hire to retire, information systems development, and financial reporting. Such processes have customers and create value for them (as must any process, by definition), but those customers are internal. The third category is governing processes, the management processes by means of which the company is run (such as strategic planning, risk management, and performance management). (Process management is itself a governing process!) All processes need to be managed as such and so benefit from the power of process management.

Any process is better than no process. Absent a well-defined process design, chaos reigns. Individual heroics, capriciousness, and improvisation rule the day – and results are inconsistent and unsustainable. A well-defined process will at the least deliver predictable, repeatable results, and can serve as the staging ground for improvement.

A good process is better than a bad process. This statement is not as tautological as it seems. It expresses the criticality of process design, that the caliber of a process design is a critical determinant of its performance, and that some processes are better designed than others. If a company is burdened with a bad process design, it needs to replace it with a better one.

One process version is better than many. Standardizing processes across all parts of an enterprise presents a single face to customers and suppliers, yields profound economies in support services such as training and IT systems, allows the redeployment of people from one business unit to another, and yields a host of other benefits. These payoffs must be balanced against the intrinsically different needs of different units and their customers, but our bias should be in favor of standardization.

Even a good process must be performed effectively. A good process design is a necessary but insufficient prerequisite for high performance; it needs to be combined with carefully managed execution, so that the capabilities of the design are realized in practice.

Even a good process can be made better. The process owner needs to stay constantly vigilant, looking for opportunities to make modifications to the process design in order to further enhance its performance.

Every good process eventually becomes a bad process. No process stays effective forever in the face of change. Customer needs change, technologies change, competition changes, and what used to be a high level of performance becomes a poor one – and it is time to replace the formerly good process with a new one.

7 The EPM as a Management Tool and BPMS

The foundation of process management is the Enterprise Process Model (EPM). This is a graphical representation of the enterprise’s processes (core, enabling, and governing), showing their interconnections and inputs and outputs. Figure 1 is an example of such an EPM, from a large distributor of industrial products. An effective EPM should be simple and clear, fitting on one page, and typically including no more than 5–10 core processes. Such a high-level representation is then decomposed to provide additional detail, breaking each top-level process into a number of subprocesses, which are further decomposed into activities. There is as yet no standard (nor even near-standard) notation or architecture for process representation or for how many levels of detail are appropriate.

The EPM does more than just provide a vocabulary for a process program. It offers something few companies have, a coherent and comprehensible description of the company’s operations. It is remarkable to note that conventional representations of an enterprise – the organization chart, the P&L and the balance sheet, the mission and value statements, the product catalog and customer list – say nothing about the actual work of the company and what people do on a regular basis. The EPM provides such an operational perspective on the enterprise and as such should be used as the basis for managing those operations.

In particular, the EPM offers a way of dealing with the projects and programs that constantly changing times raise, since ultimately every business issue must be translated into its impacts on and implications for operating processes. The following is a representative set of such issues that companies have recently needed to address:

  • A risk management group has identified areas of high risk to the company. The processes that impact these risks need to be identified and redesigned in ways to help mitigate them.

  • A new company has been acquired and there is a need to perform comparisons between the processes of the acquiring company and those of the acquired one, to help produce a roadmap for integrating the two companies by moving from the old processes to the new ones (Fig. 2).

    Fig. 2
    figure 2

    Example of an enterprise process model (EPM)

    Full size image

  • A new corporate strategy or initiative is announced, which entails changing the definitions of some of the company’s key performance indicators (KPIs). The company needs to determine those process metrics that are drivers of these KPIs and update them appropriately.

  • A change is made to some modules of an enterprise software system, and managers of different processes need to be made aware of the impact of the change on them.

  • An activity that is used in several processes is modified in one of them, and these changes need to be reflected in all other occurrences of that activity.

  • When a change is made to a business policy, it is necessary to make appropriate corresponding changes to all those processes in which it is embedded.

The EPM needs to be used as an active management tool for situations like these. More than that, companies focused on their processes need automated tools to help them actively manage their processes, for purposes like these and others. Such tools could legitimately be called Business Process Management Systems (BPMS), a term used at the opening of this chapter.

As of this writing, BPMS is a notoriously, broadly, and vaguely defined product area. Vendors with very different offerings, providing different features and supporting different needs, all claim the mantle of BPMS. However, to oversimplify, but slightly, contemporary BPMS software is principally used for two kinds of purposes: to create descriptions of processes (in terms of their constituent activities), which can be used to support process analysis, simulation, and design efforts; and to generate executable code that supports the performance of a process, by automating certain process steps, integrating systems and databases used by the process, and managing the workflow of documents and other forms passing through the process. While (as is often the case in the software industry) vendor claims and market research forecasts for these systems are somewhat exaggerated, they nonetheless do provide value and have been successfully deployed by many companies. Unfortunately, despite the name, contemporary BPM systems do little to support the management of processes (rather than their analysis and implementation).

A software system designed to support true process management would build on the capabilities that contemporary BPMS products provide (to define and model processes), but go far beyond them. It would embed these processes in a rich multidimensional model of the enterprise that captures at least these facets of the enterprise and the relationships among them:

  • Definitions of processes and their activities, and their designs

  • Interconnections and interrelationships between processes, including definitions of inputs and outputs and mutual expectations

  • Metrics, both enterprise KPIs and process-level metrics, including current and target performance levels

  • Projects and activities associated with process implementation and improvement

  • Business organizations that are engaged in implementing and executing processes

  • Process versions and variations

  • Information systems that support processes

  • Data elements created by, used by, and owned by processes

  • Enterprise programs and initiatives and their connections to processes

  • Control points and risk factors

  • Roles in the organization involved in performing the process, including their organizational position, skill requirements, and decision-making authorities

  • Management personnel associated with the process (such as the process owner)

  • Enterprise strategies and programs that are impacted by processes.

Such a system would need to know the “semantics” of organizations and of these facets, so that instead of operating as merely a passive repository, it could act as an intelligent model of an enterprise and its processes. As such, it could serve as a powerful tool to support management decision-making and action in a complex, fast-changing environment. Such a model would not be populated by data created by operational systems but by a rich representation of the enterprise. It would be a tool for managing processes and not for executing them.

Some companies are using existing BPMS systems for these purposes, but they report that these tools offer little or no active support for these purposes, other than providing a relational database and a graphical front-end. There are no built-in semantics in contemporary systems that capture the characteristics of organizations and their many dimensions, nor do they have an embedded model of process management.

8 The Frontiers of BPM

Despite its widespread adoption and impressive results, BPM is still in its infancy. Even companies that have implemented it are far from finished and many companies – indeed many industries – have yet really to begin. Unsurprisingly, there are a host of issues with which we have yet to come to grips, issues that relate to truly managing an enterprise around its processes and to the impacts of Business Process Management on people, organizations, and economies. The following is a sampler of such issues, some of which are being actively investigated, some of which define challenges for the future.

Management structure and responsibility. As more power and authority get vested in process owners, other management roles and responsibilities change dramatically. Functional managers become managers of resource pools; business unit heads become agents of customers, representing their needs to process owners. These are radical shifts, and are still being worked out. Some companies are experimenting with moving many standard processes (not just support ones) from multiple business units into what amounts to shared service organizations. Others are outsourcing whole processes. The shape of the process-managed enterprise is still emerging.

IT support. How do developments in new information technologies impact processes and process management? ERP systems (somewhat belatedly) have come to be recognized as process software systems, since their cross-functional architecture enables them to address work on an end-to-end basis. What implications will SOA (service-oriented architecture) have on process design and implementation? How will process management impact data management? For instance, some companies are starting to give process owners responsibilities for master data management.

Interenterprise processes. Most organizations focus on processes that run end-to-end within their companies; however, in many cases, the real ends of these processes reside in different companies altogether. Supply chain processes, for instance, typically begin in the raw material supplier’s operations and end with the final customer; product development processes are collaborative and must encompass suppliers’ efforts. Some companies have been working on these processes, but we lack models for their governance and management. Who is the process owner? How should benefits be allocated? What are the right metrics?

Standards. Are there standard EPMs for companies in the same industry? Are there standard sets of enabling and governing processes that all companies should deploy? Will we see the emergence of best-in-class process designs for certain widely occurring processes, which many different companies will implement? What would these developments imply for enterprise differentiation?

Processes and strategy. Processes are, on the one hand, the means by which enterprise strategies are realized. On the other, they can also be determinants of such strategies. A company that has a world-class process can deploy it in new markets and in support of new products and services. At the same time, companies may decide that processes that do not offer competitive advantage should conform to industry standards or be outsourced.

Industry structure. How will process management affect the structure of industries? As companies recognize that certain processes represent their core capabilities, while others are peripheral, will we see greater outsourcing of the latter – perhaps to organizations that will provide processes on a service basis? Will customer and supplier organizations intertwine their processes to create what are in effect operational (rather than financial) keiretsus?

Beyond these macro questions, even the basic aspects of process management – designing processes, developing metrics, training performers, and all the rest – are far from settled issues. There is much work to be done. But even absent solutions to these challenges, it is clear that process management has moved from the wave of the future to the wave of the present, and that we are indeed in the Age of Process.