A Recipe for Business Process Management:

Slashing Cycle Time

(February 2003)

• Overview
• The recipe and the cases
• Developing the BPM/CT (Cycle Time) Recipe
• Recipe Step 1: Target priority processes for cycle time transformation
• Recipe Step 2: narrow down the focus to processes where complexity and scale have generated muddle and waste
• Recipe Step 3: work with the process as is and transform it incrementally
• Recipe Step 4: Build a small team led by a strong process owner from the business
• Recipe Step 5: Dynamically map the process as is and as will be in terms of the coordination of requests, promises and corresponding negotiation-commitment loops
• Recipe Step 6: move along a path of continuous, incremental improvements, guided by the maps
• Recipe Step 7: Scale, integrate and extend
• Summary and Review
• Bibliography

  ---

Recipe: The beginning of a prescription or formula for a remedy; the means for attaining or effecting some end; the statement of the ingredients and procedure for making something. (Oxford English Dictionary definition)

Overview

Business Process Management is the generic term for emerging methods for improving process quality, cost, and speed via information technology. It offers the same potential contribution to business innovation as did earlier process movements, most obviously Total Quality Management and Business Process Reengineering. It also runs the same risks as these of early promise turning into backlash and disappointment. When a field of IT-related practice is very new and is intendedly innovative, there are two extremes of approaches to design, development and applications: applying lessons from individual exemplary cases and building generic structured methodological frameworks. Each extreme limits the emergence of sound principles of practice. Individual success cases are too often over-generalized in terms of principles and resulting claims; the stories get turned into fables. At the other extreme, vendors, consultants, academics and computer scientists offer a variety of frameworks, schematics and checklists, whose applicability and validity may be difficult for their intended users to assess. They offer rigor and structure, but often without evidence of success.

The aim of this paper is twofold: (1) to suggest a more effective “recipe” approach to research-with-practice that applies to IT-based innovation in general, with BPM the specific context here, and (2) to present a particular recipe for slashing cycle time in business processes. Recipes are instruction guides built on proven experience. They are precise in their formulation but leave open options for variations in their details and provide room for improvements. There are many of them; there is no single dish. They are formalized and tested out by experts and passed on for others to use. By definition, they are repeatable. They emphasize the correct preparation of ingredients and sequencing of steps. Clusters of recipes form a style of cuisine.

The paper presents one proven recipe for BPM, derived from analysis and interviews in a number of companies that have successfully implemented major business process transformation. All are among the leaders in their business sectors and their BPM initiatives address a key component of their competitive positioning and customer relationships. The payoffs have been substantive – and measurable in “hard” quantitative terms not just “soft” qualitative ones. The investment has been relatively small; while full figures are not available, the direct cost appears to be in the range of one to two hundred thousand dollars. Typically, they take 3-6 months to implement by a core team of around 10 people, most of who are not full-time on the project. Many of the applications have won awards from industry associations.

The criteria for selecting these companies for analysis were (1) their common focus on cycle time as the target of BPM opportunity and (2) their common view of processes as fundamentally built around the interactions of people, with those interactions leveraged by technology. This “closed loop” model and associated tools provide an effective recipe for business process transformation in companies where cycle time is core to both customer and company and where complexity of coordination and interaction largely generates slow cycle times: interaction, communication, judgement, negotiation, commitments, and exception-handling. Figure 1 shows the model.

Figure 1

Source: Action Technologies, Inc.

This loop model contrasts strongly with the workflow automation view of business process management that is represented in the typical comments below:

“BPM emphasizes the management aspect of automating processes to achieve maximum ongoing flexibility with minimum development and time.” (Ebizq.net, 2002)

“As enterprise processes become more automated, and more and more interconnected, one piece of technology refuses to go away: the human being.” (Workflow Meets BPM, Infoworld, April 27, 2002)

BPM is: “Streamlining the system of delivering a document to the appropriate recipient and determining where and when the document is sent next.” (Business 2.0, April 2002, page 37)

This is a narrow conception of process that offers effective recipes in some contexts but is applicable only to well-structured and routine procedures with few exceptions, well-defined business rules, limited options for customers/requesters, minimal flexibility in execution by process performers, and minimal opportunity for human capital and organizational skills to make a difference in the effectiveness of the process, as contrasted to its efficiency. These are procedures where the human element adds little value and the business rules can be automated. Consumer loan credit scoring is a well-established example. What used to be handled by a loan officer’s experience, skill and judgment is now an automated set of algorithms and database queries. It takes the people out of the loop. The BPM/CT recipe presented here places them at the center.

Recipes are domain-restricted. The recipe for beef stroganoff can be adapted to use yellow onions instead of pearl onions or to cut back on the garlic but it will not work if the cook substitutes fish for beef. The tension between the viewpoint of BPM as automation of workflows and that of BPM as leveraging people through technology is resolved if the recipes that each of them offers – proven, precise, repeatable, and tested out – are carefully and specifically defined in terms of their domain-applicability. Instead of providing “the” definition of business process and BPM – “streamlining the system of delivering a document” for instance – it is far more useful to offer to practitioners proven recipes for streamlining the delivery of documents and accept that other recipes differ in their implicit conceptualization of BPM and hence their domain applicability.

The art form in developing and applying recipes is thus to be very clear about their domain features. The recipe presented in this paper is for the transformation of cycle time in business processes whose effectiveness rests on collaboration, coordination, communication, and commitment management among people, leveraged by technology. It is hard to see how a recipe for workflow automation could be effectively transferred to this context.

Both research and practice in BPM need to be recipe-driven. Practitioners obviously want evidence of applicability in their evaluation of opportunities and tools. Researchers aim to provide generalizable results via scientific methods. Generalizability is the test of research results in any domain that aims at influencing how organizations make use of technology. The approach taken here is to avoid the typical review of ten case studies of group decision support systems: “Each GDSS facility was designed based on a philosophy, and the software used in each facility also varied widely. Different tasks, as well as different measures of dependent variables, were used in the study. There is so much variation across these studies that generalizations become problematic.” (Dennis, page 602) Note that there is no criticism here of the individual studies; indeed, each of them may well be outstanding. But they do not add up to what is needed to link research and practice: a common recipe.

The recipe and the cases

Here are the main steps in the recipe sequence, with short comments added:

• Step 1: Target priority processes for cycle time transformation. These are ones that are Win-Win-Win for customer, company and business partners, and where cutting cycle time provides self-justifying, self-explanatory benefits that do not involve complex ROI justifications.
  
  

• Step 2: Narrow down the focus to processes where complexity and scale have generated muddle and waste. Do not omit Step 1 by immediately looking for wasteful and muddled processes that do not affect business performance if they remain muddled and wasteful. Avoid this typical mistake made by proponents of business reengineering which led to streamlining processes that do not generate economic value added for the firm. They are “background” not priority processes that support largely administrative tasks but do not affect business effectiveness.
  
  

• Step 3: Work with the process as is and transform it incrementally. Move in the style of TQM rather than BPR: a campaign of continuous change rather than a radical attack. Do not try to blow the process up and start afresh. That may be conceptually appealing but it creates the political, economic, organizational and cultural stresses that brought BPR from the best-selling “Manifesto for Business Revolution” to “Everyone knows business process re-engineering and management can mean trouble!” (Business Process Management Journal prospectus, emeraldinsight.com, May, 2002)
  
  

• Step 4: Build a small team led by a businessperson who is respected across the units involved in or affected by the process. The core team of around 10 people delivers phased results in 3-6 month increments. IT staff are technical advisers not developers. Development is handled within the team with, in several instances, the use of 1-3 outside consultants.
  
  

• Step 5: Dynamically map the process as is and as will be in terms of the coordination of requests, promises and corresponding negotiation-commitment loops. Process is people collaborating to deliver a service. Workflows are procedures within this contracting. They are not the process. All restaurants have essentially the same workflows but Chez Michel and Mike’s Tavern are very different in their processes: value criteria, flexibility of customer options, interactions between waiter and customer, and measures of value – collaborations, negotiations, and contracting.
  
  

• Step 6: Move along a path of continuous, incremental improvements, guided by the maps. This is not a recipe for fundamental, radical and dramatic change.
  
  

• Step 7: Scale, integrate and extend: Build, build, build.

The cases, their process targets and the payoffs are summarized below:

These are all very complex processes that span many departments and business partners and that involve many people. For instance, the Ford Motor Company warranty approval process originally took 60-90 days and required the coordination of up to 15 different departments. The new BPM system that cut cycle time to 23 days – a 69% improvement – has over 600 users on four continents. It includes most of Ford’s major brands, such as Ford, Lincoln/Mercury, Jaguar and Volvo. Charles Ragan, Lead Developer for Information Technology and E-business Infrastructure at Ford Motor Company, describes the warranty approval process as “Warranty and recall work is the emergency room of Ford Motor Company….. Losses or savings here can affect the company’s financial position and shareholder value.” (Source: seminar presentation, 2002.) There are 45,000 user accounts, with 400-500 transactions a day. The BPM system links to 13 production applications.

The same scale, business criticality, complexity and volumes of communication apply to the other cases. International Truck and Engine’s special quote process involves around 16,000 custom quotes a year for trucks that can cost over $100,000 each, and much more for prototypes. The Laser Center’s “branded center” startup processes are a race against time in a market of explosive growth but also aggressive and expanding third party market encroachment; each addition to TLC’s fifty centers is a heavy capital investment, with the start-up costs “prohibitive in all but the largest markets.” Opening a new center also requires coordination among many parties that do not routinely talk to each other: doctors, clinic managers, construction companies, electricians, real estate operators, utilities, etc. Lubrizol’s BPM system for product approval has 1,500 users. Lockheed Martin’s QADS – Quality Assurance Document System – has 500.

These are not pilots, prototypes, or streamlining of small-scale and simple processes with linear workflows – well-defined step-by-step procedures – and limited complexity. They are large in scale, important in their business impact, and above all meet the old adage that time is money. They are highly interactive, involving many negotiations, authorizations, collaborative discussions and decisions about how to handle exceptions.

In many instances, the people-to-people coordination loops mainly address the exception-handling, which distinguishes real customer service and real collaboration from rote procedures, whereas business rules and workflow support tools handle the completely routinized elements. For almost every customer, the moment of truth in an established relationship is how a “problem” is handled, an error resolved, a personal touch provided, and an agent able, ready and authorized to override the fixed rules of the procedure. In many ways, any basic recipe for BPM should thus be a mix of two principles: (1) embed routine procedures in software (automate) and (2) be exceptional in handling exceptions (leverage people). Product development, customer relationships, teamwork, business innovation are all processes where effectiveness – as contrasted to efficiency – rests on the non-routine elements of collaboration, coordination and commitment. These add up to a business service. The workflows are procedures within a service.

The eight cases cover a wide range of specific processes and types of application but they share many common features – about their goal, the target processes, their focus on the human elements of process, scale of effort, risks, choice of BPM tools and implementation strategy. It is these commonalities of aims, ingredients and procedures that make for an effective BPM recipe for these companies in their business context. Change these and a very different recipe may be needed. Apply another recipe in this context and it will probably fail. But conversely, apply it in comparable contexts and it moves BPM practice forward. Add more such recipes derived from other sets of case situations and mesh them selectively with tool- and method-centered perspectives on BPM and we will have a body of practice that can help build critical mass.

Developing the BPM/CT (Cycle Time) Recipe

The approach taken to develop a BPM recipe is simple:

1) First, define the domain features: Identify 6-10 companies, which have commonalities in their BPM successes. In this situation, the key commonality is that their BPM focus was on cutting cycle time and that they have achieved very substantial improvements in this area. The second commonality is that they are primarily in manufacturing. The third is their adoption of the closed loop process model. Financial service companies were excluded from the study not because cycle time is unimportant to them – consider speed of handling mortgage applications, for instance or launching a new service – but that the many differences in market segmentations, customer relationships, transaction processing, organization of financial services versus manufacturing products, and many other factors could – not necessarily would – blur the picture and obscure the patterns. The third commonality is that all the companies adopted the same approach to process mapping and the development of BPM software applications.

Hence the domain features here are:

• BPM target of opportunity: cycle time in processes that are a recognized business priority.
  
  

• Business context: Manufacturing services and product development.
  
  

• View of process: Coordination of the “loops” – requests, promises and hence commitments – among multiple actors.
  
  

• Methods and tools: Dynamic process mapping of the loops and creation of software to coordinate them.
  
  

• Implementation: rapid evolutionary development without traditional functional specifications; a business team drives all implementation, with the IT function as expert advisors on architecture, data management, security, etc.

2) Use all available sources of information to reconstruct what happened – the motivation for the initiative, its business justification, inception, planning, execution and impact – via articles, interviews, management presentations, technical plans, and case reports. The focus in developing recipes is on the process of business process management; here the richness of case data is essential to capture what worked and why.

3) Look for the BPM commonalities that explain the successes. If there are few then there is no recipe. Where the patterns are consistent, they form the base for defining the recipe. Obviously, this is a highly interpretive exercise. The focus is on moving from case richness towards methodological precision and grounding.

4) Assess if and where those commonalities form patterns of action and impact that add up to a reliable set of recommendations for BPM practitioners to adopt and adapt in their own context. If so, this constitutes a recipe.

Commonalities are the key to the interpretative and deductive process – commonalities that define the domain features and commonalities of BPM that define the recipe. The first commonality among the eight companies in this study is that they operate in industries where cycle time really matters: for product development, customer service, opening of new facilities, etc. This means that the traditional Achilles heel of both BPM and information technology investment – the lack of a convincing business case and evidence of ROI – does not cripple initiative and innovation. This is perhaps the single key element of this particular BPM recipe. Improving cycle time in the recipe domain is a self-justifying, self-explanatory target of opportunity. No one can be against it and it is W3 in nature. 

Here, W3 does not stand for World Wide Web (though of course the technology that underlies the Web is a key part of the recipe) but for Win-Win-Win – a win for customers, company and business partners. No one has to explain why, say, a 30% cut in cycle time is of value to the company and to the customer. Fundamentally, organizations have three choices to improve their processes: they can do them faster, cheaper or better. In some instances doing them cheaper can threaten W3: poorer customer service and slower response. In others, doing them better may add cost and slow things down. Doing them faster by cutting corners can add cost and lower quality. By contrast, doing things faster through disciplined BPM in and of itself leads to better and cheaper. That is certainly the case in the eight companies’ experience and there is a commonsense explanation for this. When cycle time is recognized by managers to be longer than it should be and where a process is clearly over-complex, then almost by definition this is because there are redundant steps, errors and corresponding rework, time wasted in tracking things down, difficulties in accessing status information, and the like. In that situation, cycle time improvements strongly correlate with cost and quality improvements.

The cases support this conclusion, which is reinforced by the more broad evidence from one of the most successful business process movements of modern history: e-commerce supply chain management and logistics. The leaders in SCM use half the working capital per unit of revenue and their overhead costs are 20-50 percent lower than the median competitors in their industry. Surveys routinely report that 20 percent of standard business documents have some error on them. The result is illustrated by Campbell’s Soups that reports that its sales reps used to spend two days a week resolving disputed invoices. A quarter of GE’s 1.2 million invoices a year had to be reworked because of some error or mismatch of information. Obviously that adds unnecessary cost and is L3 not W3 – a loss of service to the customer, loss of productivity for the company and loss of efficiency in optimizing the supply chain. Supply chain management tools and methods take out time and, as in our case examples, use technology to manage document flows that reduce errors from 20 percent to well under 1 percent. (See Keen and McDonald and Boyson et al for supporting figures.)

Additional examples of such a link between cycle time, costs and loss of quality run through the eight cases. Process complexity creates costs and adds time. There are many “background” processes – ones that are necessary elements of everyday operations but that do not add competitive or economic value – where this is a bearable burden. An example here is payroll processing. Shortening cycle time from a week to a minute adds nothing to shareholder value so that here our recipe does not apply and one that explicitly focuses on cost management is more applicable (that recipe will almost surely be based on business process outsourcing). But where cycle time is a priority process – one that directly affects competitive positioning – or an identity process – part of the company’s brand and core to its relationships – then it most certainly applies. (The distinction between identity processes, priority processes and background processes is presented in Keen, The Process Edge (1997) and Keen and McDonald, The eProcess Edge (2000))

There are seven main steps in the BPM/CT recipe. While there were obviously some variations among the companies in the details, the patterns of ingredient and sequencing were very much the same.

Recipe Step 1: Target priority processes for cycle time transformation

Here is Step 1 in the BPM/CT (Cycle Time) recipe: Target priority processes where cycle time improvements are W3 and the payoff is self-justifying and self-explanatory. For any BPM investment the obvious question is “Who cares?” In every single case, the answer was “everyone.” The visibility of the processes, their impact on core business performance measures, their criticality in the customer relationship, and the widespread recognition of their complexity and burden on productivity meant that the many parties involved in both the process and affected by it cared: Ford car dealers waiting to get approval for a warranty repair, the frustrated customer wanting to know what is happening, the account manager in Lubrizoil trying to clinch a large special order, the knowledge workers responsible for key elements in International Truck and Engine’s product Release Review (“a.k.a. The Gauntlet.”) When customers care, and the workers and managers care, and business partners care, detailed ROI forecasts are not needed, only specific agreement on goal metrics – cycle time savings in this case – that the decision makers accept as proving payoff. When they do not care, no amount of spreadsheet calculations of ROI will convert the skeptics or mobilize the apathetic.

Recipe Step 2: narrow down the focus to processes where complexity and scale have generated muddle and waste

Step 2 in this recipe is to narrow down the BPM focus to highlight processes that meet the first step criteria and where over time the growing scale and complexity of the processes have led to muddle – waste of effort, miscoordination, “superfluous” communication, multiplicity of information sources and links to software systems, and multiple media of communication.

As with any recipe, the sequencing of steps is critical to success. Step 1 cannot be skipped. When it is, there is a strong tendency for companies to focus their BPM on muddled processes that are largely administrative in nature. Removing the muddle ends up with improved procedures but not necessarily improved business performance. These are “background” processes, ones that support operations – payroll processing, employee benefits management, or regulatory reporting, for instance. Getting these processes right is in no way the same as getting the right process right.

The companies in this case analysis all chose to invest their BPM resources in processes that are customer-facing and performance-critical (Step 1). Here, taking out the muddle enhances customer relationships and competitive position.

There is obviously a strong correlation between cycle time and muddle. This was fully recognized by just about everyone in the case exemplar companies. It needs little discussion except to contrast a key aspect of this BPM recipe with the recommendations of mainstream BPR in Hammer and Champy’s book (1993) that launched this highly influential process movement. Their recipe missed out an ingredient. BPR’s key first step was to identify processes with muddle. It did not address the W3 and payoff criteria. That is illustrated by the difference between the article and book. The Harvard Business Review article highlighted as one of its two main examples the policy issuing process in Mutual Benefit, a New Jersey insurance company. The reengineering reduced cycle time significantly, from weeks to hours.

The company is never once named in the book, however, because it went insolvent in the meantime. Mutual Benefit got a process right but it did not get the right process right. Policy issuing was a background process, not a priority or identity one. The fact that a process is full of muddle does not mean that it should be a priority for BPM. Muddle is everywhere even in the very best companies. The ones in the case analysis routinely described the same problems: inconsistency, no tracking or status “visibility”, manual routing of email, lost or deleted messages, department level databases and personal spreadsheets, many “how do I…. where is…..?” phone calls, lack of integration and standardization of documents, systems and information, staff dispersion, overwhelming demand and growing workload, difficulty of linking suppliers into the process, tasks and decision items being shuffled around by phone, voicemail, fax, inter-office mail and email, poor coordination and follow-up, no process measures, wild and uncertain variation in cycle time, “waste”, drift……… The list goes on. They are the reality of business and there are many reasons why so many processes are in such a state: historical drift, technology incompatibilities, organization and reorganization, etc. Obviously, this is a problem but it is equally obviously the BPM opportunity. When processes that are priority for the company accumulate muddle, then (1) this is because of history and complexity, not incompetence, (2) previous efforts to remove the muddle have not worked, and (3) a BPM recipe that can remove the muddle generates substantial business payoff.

Recipe Step 3: work with the process as is and transform it incrementally

Step 3 in the recipe is: Work with the process as is; do not start from scratch but map it and evolve its improvement. This step in the BPM/CT recipe diverges very strongly from the reengineering approach to BPM, which deals with muddle by starting with a blank sheet of paper and entirely redesigning the process. All the companies in the case analysis stressed that they worked with the process as it is and decided on a strategy of incremental and continuous improvement. The BPM teams based their decision not to reengineer on previous failures in efforts to do so, previous investments in software to structure and streamline workflows that also had produced limited and/or disappointing results, and on more implicit assessments of the impracticality of getting organization-wide support for large-scale initiatives that would inevitably disrupt operations and demand radical change management.

Step 3 has important consequences for BPM in general. It aligns more with the spirit of TQM than BPR. The BPR mainstream aggressively and explicitly attacked incremental and evolutionary change: ”Business reengineering means starting all over, starting from scratch” and “Incrementalism is the path of least resistance for most organizations. It is also the surest way to fail at reengineering.” (Hammer and Champy, page 202.) But it is not the surest way to fail in business process transformation. Radical reengineering demands its own domain-specific recipes for it to be effective. It is worth noting that most of the companies in the cycle time study had earlier tried the BPR approach and/or the implementation of large-scale ERP systems as the base for process transformation; none had succeeded.

Recipe Step 4: Build a small team led by a strong process owner from the business

In all eight companies, a marked feature of their process transformation initiative was the composition of the team of 6-12 people of whom IT specialists were a distinct minority and in most instances not assigned full-time. The core team members were all fully knowledgeable about the process domain, a need that the team leaders emphasized as critical for success. The role of the IT specialists centered on integration of the new BPM software into legacy systems and enterprise networks plus database access and architecture. The International Truck and Engine team was typical: 9 people, with 5 from the company’s Process Development group and 4 from IT. They built the new Special Quote BPM tools in 9 months. The stated criteria for choosing the team were: “Find the 4-5 people who know the system and whose knowledge is respected…. You must find a process owner who cares….. And people who will get their hands dirty.” (Action Technology Inc. seminar presentation, May 2002)

Donnelly’s teams numbered 10-15 with development time amounting to 4 weeks to 4 months for the 2,700 projects they completed over a four year period. The advantage of small teams in this recipe seems to be that this (1) facilitates rapid prototyping, (2) forces rapid, phased and incremental development initiatives, and (3) minimizes up front risk and investment. Most of the teams drew on additional knowledge and input from the business – the cycle time processes involve many actors, subprocesses and interested parties. This recipe is fully consistent with a general trend across the entire business-IT world: a move away from the large-scale developments marked by the ERP and CRM eras towards 90-180 days as the unit of time for delivering a result and building large systems out of smaller components.

Recipe Step 5: Dynamically map the process as is and as will be in terms of the coordination of requests, promises and corresponding negotiation-commitment loops

None of the eight companies in the study reported that they spent any time on functional specifications for a new system, which is the established discipline for software development. Instead, they focused on dynamically mapping the process. International Truck and Engine’s Process Development leaders, Jeff Bauermeister and Mark Thompson, defined their goal as “Develop a tool that communicates the exact process modeled including participants, protocol, routing, e-mail notifications, and cycle times in a way that developers, process owners, trainers and end users alike can comprehend.” [emphasis added for this article] They add that:

• “Creating and maintaining a process map at this level of detail pays for itself many times over.”
  
  

• As the size of the business process or the development group grows, so does the usefulness of the map
  
  

• It is a living document, to be useful it MUST be kept current throughout the life cycle of the business process it represents.”

One of the consequences of escalating complexity and scale of processes is that no one has full “visibility” into them. In, say, a special customer order process or even a consumer mortgage process, skilled people know about their part of the process and their direct interactions with each other but not about overall status. One of the values of process mapping is to encourage a fairly high level shared overview of the full process dynamics. The Laser Center’s team comments that “defining, mapping and developing a repeatable and measurable process clarified and improved future crossfunctional projects”, for example.

The tools used in the eight companies were all provided by Action Technology inc., and based on the loops model as originally developed by Fernando Flores, Terry Winograd and their colleagues (Winograd and Flores, 1986. See also Keen, 1991, for a summary description.) It has two key features for process mapping. First, it corresponds to how people think about the dynamics of a process, by capturing its flow of requests, promises and negotiations; it is a natural representation of a process that also directly translates to a system design in ways that functional specifications, data-entity diagrams, and workflow tools largely do not do so. Secondly, it is highly visual; it is a simulation-modeling tool that provides a Vision Support System. (See Keen and Sol, 2003) VSS refers to tools that support decision makers – in this case process designers – through visualization; the VSS adage is “If you can’t see it, you can’t get it.” BPM relies on business people being able to get it where “it” is the mapping of the process, first as is and then as will be.

International Trucking and Engine’s leaders stress the ongoing value of the visual map in this regard. They and others also report that they needed to provide only short training to both the core team and the wider group involved in the initiative, typically 2-4 hours. That training was part of the initial mobilization effort and established a shared language and framework for collaboration through interviews, process mapping, “quick start” prototyping, “last trip” end-state design, and requirements analysis. International Truck and Engine emphasize the importance of being able to “fully visualize the process.”

This point is one that many IT-, information- and workflow-centered views of BPM appear to overlook, as do those centered on business rule repositories, process automation software, and such innovations as “OMG is developing new UML modeling standards and BPMI.org is developing an XML-based business process modeling language (BPML)…..” (the new language “has a strong mathematical foundation” (Internet World, 2-1-02) Lotus Notes, for instance, while functionally very powerful, is by no means natural or visual for the communities involved across the business, organizational and technical elements of BPM. If you can’t see it, you can’t get it. The BPM/CT recipe does not rely on any one tool but it does depend for its success on choosing tools that meet this imperative. 

Recipe Step 6: move along a path of continuous, incremental improvements, guided by the maps

The BPM/CT recipe totally differs from the basic BPR master recipe, which basically begins with “break a dozen eggs.” The core thesis of Hammer and Champy was that “The Crisis That Won’t Go Away” demands “fundamental”, “radical”, and dramatic redesign of processes. The eight companies explicitly relied on continuous and incremental change. The results justify their approach. The process mapping is the guide along a path that for all the companies has cut cycle time by 30-70 percent in priority W3 processes. Meanwhile the slash and burn approach of traditional BPR generated dramatic flashes in the pan but few reliable recipes. The individual most associated with reengineering commented in mid-2002 that “As a brand name, it’s [BPR] about as attractive as ‘painful rectal itch.’” (Michael Hammer, verbatim, in Who Has the Next Big Idea, Fast Company, May, 2002, page 108) Yet, less than a decade earlier, Hammer stated that “The curtain is rising on the Age of Reengineering.” (Hammer and Champy, Reengineering the Corporation, Page 216) and “everyone” knew that reengineering was the future of business.

The BPM/CT recipe is part of the very same cuisine as TQM. There are clearly situations and domains where fundamental, radical, and dramatic change is needed but the evidence here is that companies can make substantial progress in their BPM without the horrendous stresses and disruption – and often demoralization – associated with the Age of Reengineering.

Recipe Step 7: Scale, integrate and extend

The potential weakness of the BPM/CT recipe is that its incrementalism and phased initiatives may easily results in lots of pilots, mini-applications and small-scale systems that do not scale and that are not integrated into enterprise networks, databases, processing systems, ERP, CRM and other resources. The recipe relies on fast and small. IT professionals know well from decades of experience that this too often results in short-term success and long-term failure. Integration is increasingly being eased by the new toolkits for software development that are built on the Internet Protocol (IP) and on Web service tools. After four decades of continued research and development of methods, the software engineering field is moving closer and closer to its goals of agents, objects, reusable components etc. Without overstretching the analogy of BPM recipes with cooking of meals, Web services, XML, SOAP, J2EE, UDDI, .Net, and other items in the IT alphabet soup of acronyms are becoming the most basic ingredients of every recipe, equivalent to stock and seasonings.

Scaling is more complex and an issue of concern for most of the companies in the BPM/CT study. “Concern” does not mean “problem” but simply highlights that this is the next challenge for them. The choice of BPM technology platform and tools rests on scalability. Any business process recipe is invalid if it is not based on scalable technology. The adage must be “If you can’t scale it, don’t build it.” The companies in the cycle time study built it and scaled it. The generic approach of start small, grow applications by incremental, continuous improvement and avoid large-scale investments and lead times may easily disguise the scalability of the recipe and encourage the alternate ones commonplace to ERP and CRM, which equate scalability with scale and thus aim at large-scale application developments.

Scale includes growth in number of users, process cases, customers, transactions, etc. Ford Motor Company’s Warranty Service BPM now hosts 13 production applications, with 45,000 user accounts and a daily rate of 400-500 user transactions. RR Donnelley’s supplier management and customer product development BPM system has evolved to a cross-enterprise platform with over 11 thousand components. The Laser Center’s center implementation BPM grew from 43 to 100 users.

Summary and Review

This article is motivated by a variety of interests and challenges. The overriding interest is twofold: how to help build effective BPM practice and avoid the limitations and traps of BPR and workflow history. The overriding challenge is also twofold: to make best use of case examples and experience and also to resolve the tension between the workflow automation and process as human collaboration views of BPM. The conception of recipes is the synthesis of these four motivators:

• BPM practice: The recipes are not a “cookbook” but a framing of domain-constrained proven, repeatable, and disciplined experience.
  
  

• Avoiding the workflow and BPR historical traps: By recognizing that there are many varieties of BPM – conceptions of “process” and “process management”, methods, tools and targets – the recipe approach gets away from process dogma and highlights the limited applicability of any BPM approach. Workflow automation certainly plays a major role in many BPM contexts but it is far more specialized than its proponents often recognize. Efforts to take the human element out of the process loop have failed time after time. The comment cited earlier is not encouraging for BPM if it is accepted as general in applicability: “One piece of technology refuses to go away: the human being.” The recipe described in this article is one where the human being is not a “technology” but the very core of process effectiveness.
  
  

• Cases: The recipe is not built on single case successes but on a critical mass of cases. Individual cases are just stories and are not a reliable base for generalized conclusions and recommendations. They are essential in moving BPM ahead because they capture successful innovations, include political, economic, technical and organizational forces and trade-offs, and help stimulate managers’ interest and strategic thinking about BPM opportunities. But just as in the old adage one swallow does not make a summer, one case does not show a trend or make a methodology. Recipes are not methodologies but they help bridge from case-based innovation to structured methods.
  
  

• The tension between process as technology and workflow to process as people and collaboration: Both viewpoints end up in new technology applications. This recipe uses process mapping, builds and scales IT applications, and automates sub-processes in terms of document coordination, information resources, and business rules. But it offers a more general approach to BPM than just workflows and automation. The loop model is described in more detail elsewhere. (See for a summary, Keen, 1992.) In the author’s view, it offers far more opportunity to help organizations benefit from BPM than most other perspectives. That is just a view, however. The recipe provides evidence to support the view without denying the domain-applicability of other views.

Is this the only recipe for BPM? Of course not. Does it apply to all types of process? Again, of course not. Does it work? Very much so. Does it provide proven and measurable payoff? Definitely.

The follow-on to the work summarized here is to move ahead on the four motivators: BPM practice, avoiding the historical BPR traps, learning from cases and experience, and resolving the technology-people tension in BPM. We need more recipes. Examples under development are ones for Business Process Outsourcing, customer service and customer-facing processes in specific domains (financial services, call centers, etc.), and project management. The cycle time transformation recipe may well turn out to be generalizable to more domains than manufacturing. It may or may not transfer well to domains where cycle time is not the same priority and self-explanatory, self-justifying target of opportunity. Regardless, BPM need recipes and this one is a useful start to building a base of sound business, organizational and technical practice.

Bibliography

Boyson, Sandor, Thomas M. Corsi, Martin E. Dresner and Lisa H. Harrington, Logistics And The Extended Enterprise: Benchmarks And Best Practices For The Manufacturing Professional (New York: Wiley, 1999)

Dennis, A.R., J.F. George, L.M. Jessup, J.F. Nunamaker, and D.R. Vogel, “Information Technology to Support Electronic Meetings,” MIS Quarterly, Vol 12, Issue 4, December 1988, pp. 591-624

Hammer, Michael and James Champy, Reengineering the Corporation: A Manifesto for Business Revolution (New York: Harper Business, 1993)

Keen, Peter G. W., Shaping the Future: Business Design Through Information Technology (Cambridge: Harvard Business School Press, 1997)

Keen, Peter G. W., The Process Edge: Creating Value Where it Counts (Cambridge: Harvard Business School Press, 1997)

Keen, Peter and Mark McDonald, The eProcess Edge (New York: McGraw-Hill, 2000)

Keen, Peter G. W. and Henk G. Sol, Rehearsing the Future (in manuscript, 2003)

Winograd, Terry and Fernando Flores, Understanding Computers And Cognition, (Norwood, New Jersey: Ablex, 1986)