Business Process Management:
The Future of IT

(February 2003)

• Overall status of IT in large organizations today
  • Business impact
  • Platforms
  • Delivery
  • Financial planning
• Table 1: The automation ethos of BPM, with comments added
• Table 2: BPM contrasts
• Shifting the BPM focus
• The blueprint in action: examples
• Conclusion: IT Futures

  ---

Business process management (BPM) is the future of IT. Systems development is its past. How well IT adapts to the BPM opportunity and challenge will shape its identity and success. While it will be 1-3 years before the IT future becomes the BPM present, it is time for both business and IT units to start moving to ensure they are there on time.

BPM is a broad term for (1) designing and sourcing business process capabilities and (2) exploiting the opportunities of information technology to leverage processes whose efficiency and effectiveness significantly impact competitive, economic and organizational positioning. BPM is not reengineering, workflow automation, or outsourcing, though these are tactical elements within it. The strategic element is the interaction between people: “customers” who make requests and “performers” who proactively negotiate offers and agreements to meet the request and ensure the organizational coordination needed to meet the customer condition of satisfaction. The tactical skills of BPM are the management of routine procedures, document flows and information management. The strategic skill is the coordination of the relationships those procedures should serve. The challenge to IT is not to let its approach to BPM become just the tactics, driven by the ethos of automation.

Here is the overall status of IT in large organizations today: 

• Business impact: Just about every business innovation relies in whole or in part on IT. IT is thus now in the business mainstream not on its technology periphery. This makes it integral to BPM as both an enabler and a driver of innovation. The BPM payoff opportunity becomes the IT opportunity and one not to be missed.
  
  

• Platforms: IT is close to becoming the equivalent of electricity: increasingly accessed through open standards, ubiquitous, affordable and a general-purpose information and communications power supply.
  
  

• Delivery: For the first time in its fifty-year history, the technology base of IT enables speed, flexibility and integration of both existing systems and new services. There remain many gaps in standards and products but foundational Web Services are rapidly emerging as just what IT has been aiming at for decades: modular building blocks that operate across every type of operating system, data resource, legacy system and network and that enable rapid development of applications. That means that BPM can move at business speed not systems development pace.
  
  

• Financial planning: IT is now a discretionary business expense, not “technology.” There is no mystique left in IT in the era of ubiquitous PCs, laptops, PDAs and the Internet as commonplace as ATMs. After many decades where there was an IT “budget” that was largely justified and coordinated by IT itself, organizations now have business plans that require IT expenditures. They are less and less willing to divert scarce financial capital to the notoriously high risk, high failure mass infrastructures (such as ERP and CRM) or high hype Something of the Future world of IT (examples here are the claims for the Paperless Office, Clicks not Bricks and e-commerce oversell). They demand a business logic for IT and a risk management strategy.

Together, these new commonplaces lead to the obvious: IT = process, process = people + IT, and process innovation = business innovation = IT innovation. This is not “new”, though IT offers new enablers. BPM continues along a long historical path. Business process transformation lies at the core of just about every single innovation over the past two centuries that has fundamentally reshaped industries. Examples are Adam Smith’s invention of division of labor, Ford’s assembly line, Taylor’s scientific management and, in the post World War II eras, total quality management as exemplified by Toyota and, more recently, the supply chain and logistics revolution led by such companies as Dell and Wal-Mart.

To a lesser degree, business process reengineering contributed to a radical rethinking of process principles, though its track record is decidedly mixed, with initial claims and successes followed by many disappointments and backlash. What BPR did achieve was a linking of process and IT as a source of business leverage. It is this linkage that BPM aims to extend. IT extends the process path by providing powerful tools for “informating” work and workers, for automating the procedural elements of process, for coordinating communication and collaboration, and for dramatically reducing time and complexity of activities.

The four commonplaces listed above add a new momentum for the next generation of business process management. That IT is now in the business mainstream means that it is naturally integral to process thinking; earlier process movements, including TQM, did not have the technology base to draw on nor the cultural bridges between the world – and language – of business and of IT. Much process innovation was highly organizational in focus and methods, under the generic term “change management.” Toyota’s kanban was paper-based and its lean production methods made little use of IT. That was seen as a virtue in the 1970s and 1980s. This was the era of the “productivity paradox” that showed no correlation between the massive growing investments in IT and business performance.

The process paradox has been resolved. Skilled users of IT outperform average players in their industry by a factor of 1-3 in such areas as working capital per unit of revenue (supply chain management and B2B e-commerce), revenue per employee, overhead as a percent of sales, and capital efficiency. (See Keen (1997) and Keen and McDonald (2000) for detailed figures and references.)

That IT is now becoming equivalent to electricity in its platforms means process innovation is less and less constrained by or kept waiting for new technology platforms. The emerging body of Web Services tools creates a new degree of flexibility, speed in application development and ease of integration that reduce many of the historical problems associated with IT, most obviously difficulties of integration, speed of applications development, the operational burden of mis-named legacy systems and the complexity of middleware. BPR was strongly driven by IT thinking but the systems it drew on had to be specially crafted. The same has been the case for CRM, where data resources and telecommunications services have had to be expensively built before any process advantage could be created.

Now, a combination of historical forces has come together to provide for the very first time a comprehensive, flexible and universal IT base: IP (Internet Protocol), Web service tools such as J2EE, SOAP, XML, UDDI, and a host of open standards and supporting development and implementation capabilities. Organizations now can move away from the mass of systems, applications, data structures and their incompatibilities that have so rigidly limited options for process design. Many of the “stovepipes” that mark and complicate processes reflect this IT history. Web Services are beginning to end that. In doing so, they shift IT development from technical applications to the design of modular services – and away from systems building to process transformation.

The new era of tools also transforms delivery time. The era of ERP and CRM was marked by massive upfront investments and years of implementation before any possible payoff could occur – and in many instances there has been no payoff, only write-offs. This meant that process management innovations moved at the same pace as IT implementation, not business timetable needs. Delivery of modular services built on the IP/Web services infrastructure base is now routinely handled in 90- or 180-day units of work – business ventures rather than technology projects. This allows organizations to think in terms of process mapping and process design, with the technology implementation flowing naturally from that work, instead of being often unnaturally constrained by and following on the technology.

The last of the four new commonplaces is in many ways the key one: IT is now a discretionary financial expenditure, not “technology.” Many organizations are choosing to economize on or delay IT investments. They are looking at new options for sourcing IT-dependent capabilities, including business process outsourcing as well as the more established outsourcing of data center operations. After the past decade of often out of control budgets for ERP implementations, the costs of Y2K, and the indiscipline of the dot com and Web commerce frenzy, it is highly unlikely that we will see comparable scale and risk being accepted by senior executives in future. IT will need to pay its way and IT managers will not easily be able to argue, as they could with ERP and Y2K, that major investments are competitive necessities. We can expect accelerating efforts on the part of both suppliers and buyers of IT services to push towards converting IT from a high fixed cost and upfront capital investment to a variable, pay as you go cost via hosting, outsourcing, alliances, next generation ASPs and save and share contracting arrangements. Business executives will be looking for a flow of value-adding results from IT, at reduced risk and within the time rhythms of business – 90/180 days – not of IT applications – years in most instances. (The 90/180 day unit of funding and implementation fits naturally into the budgeting and reporting cycle and is long enough to deliver something of value and short enough to hedge risk and respond to uncertainty and sudden change.)

The effective IT organization of tomorrow will thus look to have fast and cost-effective impact on the core of the business – its priority processes. There is just one catch. The process path is at a fork, with two ways for IT to choose between: the workflow automation path or the interactive relationship path. Workflow automation is the structuring of information and procedures. Interactive relationship design is the leveraging of the dialogue of contracting, negotiation, collaboration and commitment that is the foundation of “service” and of the process differentiation that establishes competitive advantage. Most IT units are more likely to choose the workflow automation route, because it is natural for them to do so; their strengths and tradition are in systems, automation, structuring procedures and managing data. It is the wrong path to choose in the context of the four commonplaces. For the business, processes are not just workflows and BPM is not automation. The workflow path moves IT away from the main opportunities for business impact and financial payoff.

The clear difference between the two approaches can be quickly and simply illustrated by the example of business process management itself. Consider a BPM initiative that aims at accomplishing the goals of the journey along the workflow automation path, as expressed in the representative quotations in Table 1 below. The BPM process itself does not fit at all into these BPM definitions. First, the design process cannot be routinized; it involves bringing together a team and arriving at agreements on goals, resources, responsibilities, timetables, budgets, etc. The client will make requests that the implementation group will respond to, each making offers and negotiating time, cost and features. They will arrive at a plan that establishes commitments. During the implementation process, they will collaborate and communicate on both a routine and non-routine basis. They will surely need to handle unanticipated problems and exceptions to the plan. There will be many decisions to make that demand judgement and input from many parties. The process is not linear but includes overlapping activities, often across many business units and organizations (in this example, the value network will almost surely require active involvement by IT specialists, the implementation team, outside software and/or systems integration service providers, groups that are affected by the process or that provide inputs to it, etc.).

Table 1 The automation ethos of BPM, with comments added

Obviously, there are many aspects of most overall business processes where automation and streamlining of workflows are appropriate and valuable. Most complex processes are made even more complex, unreliable and expensive because of breakdowns in information flows, gaps in procedures, misunderstanding, errors in documents, multiple computer systems and databases, keeping track of messages via voice mail, e-mail, fax, phone, mobile, PDA, and the like. It makes plenty of sense to apply IT to rationalize and streamline these. But even if every single opportunity were taken to apply every tool of workflow automation to BPM itself, the core of the process will if anything have been damaged, not improved.

Consider the goal-setting steps in a BPM venture, for instance. The customers – in this instance, a group in the business unit – is not going to accept a predefined, routinized target, but will want options to select from and room to negotiate and commit to a specific contract that may place speed ahead of cost. They may choose to phase implementation rather than attempt a single project, and juggle availability and scheduling. If they instead are given a straight-through processing routine handled by fixed business rules, this is not a process but a procedure. If it can be turned into a procedure, as car loan application processing has been, then there is no room for judgement and skill. Just follow the procedures. Take it or leave it. No exceptions.

Table 2 lists two processes, which are very similar in terms of workflows but very different in terms of the customer-provider interactions. The workflow automation definitions and methods treat them as equivalent.

Table 2: BPM contrasts

Here is once more the weakest aspect of IT in action: placing the imperative of automation above human interaction, and thinking of processes as activities and linear steps. Much of the failure of BPR came from this tendency. It made sense to talk about reengineering, say, the accounts payable process but how about telling a management team and in this example the IT team that “We are here to reengineer you people.”

The workflow automation path applies only to linear processes with fixed inputs, clear business rules, rigid conditions of performance and information flows. These can be made more efficient through streamlining and automation but they do not constitute the processes that build relationships, either with customers, suppliers, internally across the organization or with business partners. These inherently and fundamentally rest on contracting and negotiation of commitments. They are a service whose effectiveness depends on managing requests, making offers and on being exceptional in handling exceptions.

This shifts BPM from streamlining of procedures to coordination of all the work – and interactions between people and between people and their work – that manage and deliver on these commitments. “Coordination”, like communication and collaboration, is a term that has become watered down in its meaning in everyday business usage. Contracting and negotiation capture better the nature of process in this regard. The core strategic issue for IT is to choose methods and BPM tools that contribute to these. There are many tools on the market under the label “collaborative technology”, groupware and the like. They can be of substantial value for helping in, say, the goal-setting process of this example. They typically help groups on a face-to-face or remote basis identify, discuss and vote on or rank alternatives. They maintain threads of conversation and they coordinate communications. Most groupware includes facilities for filing messages and for organizing information by person, project, topic, date, and status (“to do” lists, etc.) But, and the “but” has large implications for IT’s choice of BPM tools, most of these systems do not coordinate commitments. Indeed, what is missing from them and from BPM tools in general is support for the key loops within a process: negotiation to commitment to meeting the customer “condition of satisfaction” for the process. Microsoft Exchange and Lotus Notes are examples; they coordinate message flows and filing but not commitments.

Here is a standard example of the difference between the workflow and relationship view of BPM. In a complex mortgage application, the customers do not really want a mortgage. They want to buy a house and move into it. This involves far more than just filling out an application that the bank then processes. There is a wide range of contracting involved here that goes beyond the bank’s mortgage department. In many instances, the realtor coordinates them on behalf of the customer. There is the literal negotiation with the seller, contracting for the title search and inspection, interactions between buyer and seller about what furniture and fittings come with the house and negotiations as to which additional ones can be added to the deal. Within the bank, there are many process elements that the customers do not see or even know about except when there is some problem: risk management, the bank’s portfolio balancing, securitization of the loan, and meeting many regulatory requirements.

The process is often highly flawed. The realtor has to call around the parties to find out the status of the application. No one involved has full “visibility” into the process. The bank knows about its part of the work but may not realize that there is some delay in, say, the title company. The appraisal is on hold and no one quite knows why. Logically, the standard bank mortgage procedures can be automated and many e-commerce businesses have tried to do this but with little customer take-up. That is because the customer is not standard in terms of expectations, situation, and wishes -- the condition of satisfaction for the process performance. The skilled real estate professional is a literal agent across the process; clients expect him or her to negotiate and contract on their behalf and to manage the visibility into the process. Is it then illogical to use an agent and pay a hefty commission when there are plenty of alternative options? The customer decision on which choice to make rests on the extent to which they recognize and value the contracting process versus the transaction procedures.

For car loans, car insurance, credit card purchases, and fast food the more the procedures are streamlined, routinized and automated, the more the customer gains (convenience, speed, price), and the more the company gains (cost, administration, reliability). But the more that “service”, “relationship”, “customization” and “interaction” differentiate the process, the more that such a view of BPM blocks effectiveness and substitutes efficiency.

Logically, for instance, most aspects of standard securities trading can be automated and automating the procedures of buying and selling stocks is a commodity service on the Web, with more and more free deals and lowered prices. Is it then illogical that Charles Schwab became the dominant leader in online trading at an average transaction cost of $29.95 when customers could make transactions at $6.00? Schwab was exceptional in handling exceptions – the trading transaction was just a transaction not a relationship. A rule of thumb in modern business is that transactions trend towards commodization and zero price but that relationships trend towards differentiation and premium price. BPM automation of the transaction hastens commoditization.

Shifting the BPM focus

Here are recommendations for IT organizations in planning their BPM methods and tools:

• Coordination of contracting and commitment-making is the strategic priority
  
  

• Coordination of information and workflow procedures within the process is the tactics.

There are six major targets for business process innovation in any large organization, whether in the private or public sector:

(1) customer relationships,

(2) logistics and supply chain management,

(3) shortening of cycle time in key processes,

(4) knowledge mobilization and leverage of human capital,

(5) building and sustaining business partnerships and alliances, and

(6) improving the financial dynamics of investment demands, cost structures and in the case of the business revenue flows and quality.

 It is close to impossible to define any strategic initiative in any of these areas where IT is not at the minimum a key support and in many instances the core enabler. In all these areas, however, automation is not the BPM opportunity. Customer “relationships” by the very term involve dialog, personalization of service, variety of options, and responsive handling of exceptions and special needs. Logistics and supply chain management benefit from B2B software and services that automate much of the procurement, shipping, delivery and accounting but relationships and collaboration remain critical to effectiveness as contrasted with efficiency. Knowledge mobilization – a more meaningful term that the much-debased one of knowledge “management” – rests on collaboration, communication, cooperation, coordination, community and other “co-“ words. Co- means together, and with others. Cycle time in product development, business partnerships, and financial planning are all highly dependent on the quality of interaction and all rest on contracting and commitment.

Processes can be positioned along a spectrum from automatable procedure to extempore collaboration. At the extreme points technology dominates at one end with limited need for or leverage from the people side of process and at the other end people dominate with equally limited need for or leverage from automation. It is the processes in the mid-range that pose the greatest challenge for BPM and offer the greatest payoff.

 The two key questions for any IT organization in this context are:

• Where does it want to focus its resources, skills and offers to the business?
  
  

• What tools does it need?

Obviously, the main theme of this article is that IT should not gravitate to the automation extreme. (Nor, of course, should business gravitate to the other end of the spectrum.) There are many forces pushing IT in that direction: the general history of IT embodied in its ethos of automation and apparent in BPR and CRM, both of which too often assumed software generates value and tried to overstructure the people side of process, plus the tone and assumptions of BPM vendors and trade press articles, which is captured by the quotes in Table 1.

Here is a blueprint for filling the middle space and leveraging both people and technology:

• Target high payoff BPM opportunities where the effectiveness of a process benefits from people plus technology, not either alone.
  
  

• Adopt process mapping tools that capture the flow of contracting and commitments in processes: most BPM software and methods capture only workflow activities and sequencing.
  
  

• Choose process design and implementation tools that use visual representations of processes that are natural to business people involved in the process. Too often, IT-centered tools rely on data definitions, structured methods and functional specifications that get in the way of effective Business-IT collaboration.
  
  

• Use Web services and related tools to build modular process services quickly and incrementally. 90 and 180 days is rapidly becoming the unit of time for BPM ventures, as contrasted to the multi-year systems development timeframes of ERP and CRM.
  
  

• Build BPM teams led by business people and supported by IT specialists.

All these are interrelated. BPM design and implementation can be led by business people only if the tools let them map the process in a way and in terms natural to themselves. If the team is to get results, it must get away from the long lead times of traditional IT application development and over-reliance on IT specialists; that makes Web services integral to BPM. And finally, for BPM to provide payoff the tools, their uses and users must be able to fill the middle space in the spectrum.

The blueprint in action: examples

The practicality and payoff from adopting this simple blueprint is illustrated in a study of BPM initiatives in a range of companies that aimed at radically cutting cycle time in key processes. They show a common pattern that provided the base for defining a “recipe” for success. The eight companies in the study all cut cycle times by 30-70 percent. The processes included:

• Ford Motor Company: managing warranty services approval (69% reduction with “hard” savings of $1.5 million a year)
  
  

• International Truck and Engine: special quotes for customized trucks (40% cut)
  
  

• Lockheed Martin: problem resolution in manufacturing (50% cut, savings of $1 million pa)
  
  

• Lubrizoil: new product development for specialty chemicals (“dramatic” impact; exactly figures not made publicly available)
  
  

• General Motors: IT service delivery (80% cut, associated labor costs reduced by 69%)
  
  

• RR Donnelly and Sons: customized production and supplier collaboration (15% overall productivity increase)
  
  

• The Laser Center: opening new centers (40% cut)
  
  

• Telecom Inc. (a pseudonym): (25% cut, 25% salary savings, 90% reduction in billing issues)

These processes are non-linear and complex, with many variations. They are large in scale and important in their business impact. They are highly interactive with many negotiations, authorizations, collaborative discussions and problem resolution. The processes are of critical importance to each of the firms, in terms of either the customer relationship, time to market or organizational productivity.

The BPM initiatives all used methods and tools provided by Action Technology, Inc. ATI is one of a number of companies that have built their services and products on the “loops” model of business process as the coordination of requests and promises – contracting and negotiation that create a commitment – and action/delivery on the commitment. This model was developed by Fernando Flores, Terry Winograd and their colleagues and has a long track record of application and embodiment in software tools, in this instance ATI’s Metro suite. Key to the loops framework is the concept of the customer “condition of satisfaction.” The model and its applications and impacts are discussed in a wide range of books and papers. It is grounded in a rich body of theory and ontology. That ATI and other companies have embodied it in successful toolkits used for over a decade attests to its empirical validity and practicality.

Efforts to apply BPR and ERP tools to streamline these processes had been tried in most of the companies but had failed. The very fact they are not amenable to BPM automation is part of why they are such a major opportunity. They were a frustration for the business. Their visibility, urgency and complexity made cycle time reduction a source of payoff of value to everyone involved. A manager in Ford described the almost 90 day time to approve a warranty claim as “the emergency room” of the company. It involved 15 departments. Customers were kept on hold, as were dealers during that period with obvious impacts on their satisfaction with the firm.

The processes were – as is typical in most companies – muddled. People involved in all the BPM ventures used very much the same language to describe them: inconsistency, no tracking or status “visibility” across the whole process, manual routing of e-mail, lost or deleted messages, errors on forms (most studies show that 20 percent of all business documents contain some mistake), lack of integration and standardization of systems and information, many “How do I….? Where is…….? Who do I contact……” questions, phone calls, staff dispersion, growing workloads, tasks and decision items being shuffled around or delayed, waste, drift….. The list goes on and on. They are the reality of business and there are many reasons for this: historical drift, technology incompatibilities, organization and reorganization, etc.

It is obviously tempting to tackle muddle by structuring workflows, defining and standardizing business logic and automating tasks. The loops strategy is to coordinate the interactions between people and tasks. This includes but is not limited to designing and implementing software, network and information aids. Many information flows and procedures within the full process are automated through Metro. But the broader purpose is to leverage human interactions; this is technology for coordination not automation.

That demands tools for process mapping. What is important is to:

• Capture the flow of contracting as defined by requests and promises and intermediate negotiations. People understand processes in these terms: Who initiates a step/task, Who is responsible for carrying it out? What steps/tasks do they in turn have to initiate? What is the condition of satisfaction for declaring it complete? Very complex processes can be mapped in this way, starting from an “as is” analysis that often reveals breakdowns in the process caused by gaps in loops that affect earlier or later loops in the process, lack of clarity of accountability and authority, conflict in interpretation or priority of the condition of satisfaction and the like.
  
  

• Ensure that the tools are visual and natural to use by non-technical business people. Mapping and design tools are a form of simulation – a model of the process first as is and then as should be. Visualization is fundamental to human thinking; the adage here is “If you can’t see it, you can’t get it.” The leaders of International Trucking and Engine’s BPM team stresses the ongoing value of the visual maps. They also report, as did several of the other companies that the natural language and way of viewing processes meant that they needed to provide only short training to both the core team and the wider groups involved in the BPM initiative, typically 2-4 hours. The tools established a shared language and framework through interviews, the initial mapping, “quick start” prototyping, “last trip” design, and requirements analysis. They stressed the importance of being able to “fully visualize” the process and added that (1) “Creating and maintaining a process map at this [high level] of detail pays for itself many times over, (2) as the size of the business process or the development group grows, so does the usefulness of the map, and (3) it is a living document; to be useful it MUST be kept current throughout the life cycle of the business process it represents.”

These visual representations of process loops contrast strongly with the established analysis and design tools of IT. The BPM literature is full of discussions of XML schema, business rule repositories and rules engines, add-on BPM facilities offered by ERP and CRM vendors, application integration tools, workflow management software, functional specifications, Lotus Notes, groupware, document management systems, business process modeling language, etc. These play a role in technical design and implementation, obviously, but without visual, natural mapping tools, the last success factor in the BPM portfolio will be weakened: business team leadership of BPM.

In every instance in the cycle time study, the core team numbered 6-12 people of which IT specialists were a distinct minority and in most instances were not assigned full time. The 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 participants centered on integration of the new BPM software into legacy systems and enterprise networks plus data access and architecture. The lead time for the ventures was 3-6 months with a few longer implementations of 9 months. One manager commented that the key to success is “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.”

This is BPM as business-IT collaboration. That’s what it must be for IT to play a lead role in enabling and supporting innovation. To recast the early rallying cry of BPR which was “Don’t automate, obliterate”, “Don’t automate, coordinate.”

Conclusion: IT Futures

IT has a literal identity crisis. What is it in terms of business contribution, management responsibility, focus and roles? Obviously, expenditures on IT will continue to flow, albeit at a lower rate of growth than historically even after the 2000-2002 recession ends. But the entire context of IT has changed. It is now a mature industry and a discretionary expense. More and more of IT is a matter of sourcing, with outsourcing and co-sourcing growing in sophistication, availability and scope. In-house systems development is becoming the exception not the norm. Resources for IT innovations are being carefully, even skeptically, rationed; examples are electronic commerce and mobile commerce. Executives are demanding evidence that IT makes a business contribution and reduces its notorious history of risks, delays and gaps between promise and payoff.

IT must build a new identity. That identity is business-centered, focused on business process management, enabled by the new generation of Web services and most of all entirely dependent on IT shifting from technical planning and implementation as its core of identity to the financial dialog and delivery as the basis of a new credibility and contribution.