Over the last 30 years, what is now called Business Process Management (BPM) has evolved from simple workflow systems to a host of products and methodologies. As with any popular business concept, BPM has come to mean many different things to many different people. At its crux, BPM is a discipline to apply systematic process redesign and employ automated tools to achieve improved productivity, effectiveness, and management of specific, repeatable business processes.
A common area of misunderstanding comes when people begin to think of BPM as a technology or a system. BPM is a discipline that combines elements of technology but ultimately relies on bringing technical tools and knowledge together with a detailed understanding of business needs and goals to develop better methods of performing specific business functions. One of the keys is that BPM cannot be successful without a combined effort of IT and the business. That being said, there are many vendor products that provide useful tools to help implement successful BPM solutions.
In this blog series, we will examine BPM from multiple perspectives. Part 1 looks at BPM from a tooling perspective to analyze the dimensions of a good BPM tool, trends in implementation, and out-of-the-box products.
BPM as a Tool
BPM tools provide a starting point necessary for creating an effective BPM solution. But no out-of-the-box vendor tool can, by itself, handle all of the potential business processes effectively and efficiently. Business processes are just too varied to be covered by a one size fits all solution that can easily be configured by business analysts. BPM requirements are as varied as businesses and all the disparate processes that comprise a business’ operations.
At one extreme are processes that are appropriate for highly automated straight through processing (STP) with minimal human interaction. Such a process relies heavily on close integration between existing systems, high-speed transaction processing, and simple user interfaces, if any, for limited exception processing. This type of business process would be best implemented using a product designed to orchestrate services or provide high-speed message processing.
At another extreme is a highly variable, knowledge worker process that may include ad hoc routing, team collaboration, and smaller numbers of long-lived work items. This process might be implemented using just email and standard office tools or with a BPM case processing tool.
A third situation might include a highly routine, high volume, but human-centric set of processes. This situation calls for a sophisticated user interface that brings all the information together for the user and allows them to perform their routine tasks as efficiently as possible. The routine and high volume characteristics of the transactions allow for a greater return on money spent customizing the application to the unique needs of the process.
While they are all BPM solutions as the term is commonly used today, they require different tools, techniques, and levels of customization to implement efficient solutions. Some tools may provide adequate support for one or more of these scenarios, but no off-the-shelf tool will provide a highly effective, complete solution for all of them without customization. This is one of the reasons that BPM has become fairly confusing – it just does not make sense to look at it as a monolithic market, especially when looking at the automated tools that support its implementation.
Dimensions of a BPM System
Understanding the full depth of BPM as a discipline requires an understanding of the different dimensions that can define a BPM solution. Numerous dimensions exist that can be used to segment the growing BPM solution space. Some of the most important include:
- Level of human versus system processing – In a system that defines BPM as the orchestration of a set of services, the focus will be on simple and highly efficient queuing and routing as well as translation of data among systems. In a system that involves significant human processing, more focus will be on providing efficient user interfaces and work management tools.
- Long running versus short running workflows – In a system that defines BPM as the orchestration of a set of services, total workflow time may be seconds or less. In a government case processing application, the total time for a case may be years.
- Attached content versus data only – Workflows that include content are often driven by the receipt and updating of the content. They need tools to allow users to efficiently access and act on this content as an integral part of the process flow. Data-only workflows do not need these types of capabilities.
- Deterministic versus ad-hoc routing – Knowledge worker systems tend to be more user-directed, at the simplest level becoming like an email system. Other systems derive significant value from having pre-defined routing rules that enforce business standards and consistency in the process.
- Relatively stable workflows versus frequent workflow changes – Some systems are built with the knowledge that routing paths may change frequently and unpredictably, while others incorporate fairly static routes although rules for following the routes may change. While any system must be built to be flexible to changing business priorities, change is expensive and should only be introduced when necessary. Thus, different design and implementation approaches should be taken depending on the projected need to frequently revise the basic workflows once they have been designed.
- Full-time users versus occasional use – Users in a back office operation will tend to use the system full-time and be very familiar with it. They will want it designed for maximum efficiency. An occasional user that might use a travel expense workflow might only use it once a week. They need a system that sacrifices some efficiency for ease of use.
- Large systems versus small systems – Systems with lots of users and volume can justify spending more to customize the workflow and user interfaces. The cost of the extra work is amortized over a much larger group of users.
- Level of empowerment of users – Does the workflow include rules to drive the assignment of work or do users select from lists? Are tools needed for supervisors to manage the first line users?
This wide variation in BPM scenario characteristics poses a dilemma for standardizing on a single out of the box BPM tool for all your BPM needs. No single product by itself can do an excellent job in all of these situations. And these tools must be supplemented with design techniques, subject matter expertise, and traditional system development approaches to handle all of the variations.
The Quest for Painless Implementation
Another trend driving many off-the-shelf BPM tools is the push for simple, fool-proof implementation. Some early BPM tools got a bad reputation because implementation required lots of programming to produce even a simple system. By its nature, human-centric BPM brings together the information from many different systems to provide a single automated desktop to the user. This can require complex integration to disparate systems. In addition, BPM tools that concentrate on the backend routing still require significant work to create the front end that users need to interact with the work flowing through the BPM processes.
An industry goal has been to build a tool that can be used to implement BPM solutions without programmers. Industry analysts have encouraged this goal as a key element for any industry leading BPM tool. However, this approach tends to favor relatively simple BPM solutions. Otherwise, the complexity of the configuration becomes tantamount to programming. Likewise, the approach tends to obscure the fact that for any reasonably complex system, one still needs to practice the system implementation discipline and processes needed to build any system. You cannot skip design, testing, and release control and expect to produce a complex system that works.
So while these BPM tools may make the actual “programming” simpler through custom configuration tools and utilities, most of the work required to implement and maintain a complex solution remain. As systems become more complex, configuring these tools can be as difficult as some programming, but the tools require specialized training and often do not have the debugging and other utilities that have made programming more efficient over the years. In addition, in their quest for simplicity, some tools limit the ability to customize the system to meet the needed requirements. These limitations are usually not apparent until you try to implement a specific requirement.
The Generic Out-of-the-Box BPM tool
The goal of the typical BPM product today is to provide a tool that allows a company to implement BPM solutions quickly and efficiently with little to no custom programming. To be successful in these goals, BPM product vendors pick specific segments or dimensions of the BPM market to which they orient their product. With sufficient customization, any tool can be used as a basis for any class of BPM solution. But, out of the box, different tools tend to be best suited for specific solution areas as characterized by the dimensions of a BPM solution described above.
Over the last few years, these trends in the market have tended to move many BPM products towards ad-hoc, lower volume type BPM applications. These applications are characterized by individual in-baskets, more ad hoc routing, simple browse type interfaces for users to select work, and lower volumes of work. The typical user can easily browse their current list of assigned work due to the limited number of items. User interfaces are fairly simple, and interactions with in-house custom systems are limited.
This type of BPM system also fits many people’s initial concept of what an automated BPM will look like. That is, a system that gives everyone a personal electronic in-basket, a means to view and act upon work items in their in-basket, and the capability to route the work items to other users. This is a system well suited to knowledge workers where less emphasis is placed on standardization of work, and more emphasis is placed on flexibility. An emerging class of case processing tools fits into to this segment of the market.
These tools also highlight the ability to rapidly make changes to the routing paths and rules to quickly modify the workflow. While there is a class of BPM solution where this makes sense, just because it is possible to make changes quickly and easily to a BPM environment does not mean that an organization should make frequent changes. If the process involves a significant number of users, any changes will be disruptive to the organization. Changes that are not carefully thought out before implementation may unnecessarily add cost to the operation as opposed to increasing efficiency. Likewise, changes that are not thoroughly tested before being introduced to a production environment will likely disrupt work and cause unnecessary downtime for the organization. In the case of BPM where users often cannot work at all if the system is down, this can be very expensive.
Acknowledgements
This blog post is an excerpt from Peter Gretz’s white paper, “Effectively Applying BPM to High Volume, Human-Centric, Production Operations.”
Check out part two of the series, BPM as a solution.
