Pay attention to BPM

In 1931, statistician Walter Shewhart developed a framework for "continuous improvement." What became known as the Shewhart Cycle outlined four key steps for improving processes: Plan-Do-Check-Act.

A plan is developed to improve a process; the plan is implemented; the results are tested; adjustments are made; and the cycle begins again. One of Shewhart's most famous students, W. Edwards Deming, took this concept, along with others, to Japan. The manufacturing world has never been the same.

The Deming revolution--built around concepts like continuous improvement and just-in-time (JIT) inventory--had a universal impact on global manufacturing. Today, there is a new form of enterprise software that has the ability to do for white-collar business processes what Deming did for manufacturing. Delphi Group believes that business process management (BPM) is "quickly emerging as the moniker for the next killer app in enterprise software." Believe it or not, this may actually undersell the potential impact of BPM. BPM will not just change the software industry--it will change industry in general. Just like Deming.

What type of enterprise software could possibly have such an impact? BPM is a new programming paradigm for the enterprise that leverages browser-based applications, e-mail, global connectivity and enterprise application integration (EAI) infrastructure to deliver a powerful, business-focused programming solution. A mix between workflow, EAI and application development, BPM makes it easy for companies to codify their current processes, automate their execution, monitor their current performance and make on-the-fly changes to improve the current processes.

Here is how it works. Business analysts work alongside IT staff and create a graphical flow chart of targeted processes within the organization. These graphical designs are typically done in an integrated design environment (IDE) and represent the different events, decisions and actions that are performed by employees as well as the flows of data that are necessary to perform each task. Once defined, people begin to interact with the new application. New "processes" are started by an individual (for example, entering a new customer issue) or as the result of an event (for example, a customer account goes past due). Actions are then passed from person to person through the concept of a task inbox, and typically the passing of a URL.

For the first time, a single person can easily "hand off" an application to another person. For instance, during an approval process, one person may initiate a purchase order. If that order is over a predefined limit, the order may then be passed to the task box of the person's supervisor to await approval. The supervisor will click on a URL in the inbox, immediately see all the relevant data, and then perhaps decide to approve the order. The order may then be passed to the purchasing department and even potentially forwarded out to the supplier.

What types of processes are companies automating with BPM software? A more appropriate question might be: What process are they not automating?

Typically, there are six key components that exist in any BPM solution:

• IDE. An integrated design environment used to design processes, rules, events and exceptions. Believe it or not, many companies report huge improvements in process design merely from the act of sitting down and creating a structured definition of each process. The holy grail for BPM packages is for business users to be able to design all processes with no help from IT. (We are not there yet.)

• Process engine. The process engine keeps track of the states and variables for all of the active processes. Within a complex system, there could easily be thousands and thousands of processes with interlocking records and data. As such, this engine is nontrivial.

• User directory. Administrators define people in the system by name, department, role and even potential authority level. As an example, this directory will enable tasks to be sent automatically to "someone that is on duty in the customer service department and has a queue of less than three customers." It also allows for on-the-fly adjustments when there are personnel changes within the organization.

• Work flow. This is the communication infrastructure that forwards tasks to the appropriate individual. This can actually be built quite simply by leveraging browsers and corporate e-mail.

• Reporting/process monitoring. Companies need the ability to track the performance of their current processes and the performance of personnel who are executing these processes. This is critical to the effort of continuous improvement.

• Integration. EAI is critical to BPM because all business processes will require data from systems throughout the organization. Widespread adoption of Web services could minimize the amount of effort needed here.

What types of processes are companies automating with BPM software? A more appropriate question might be: What process are they not automating? Companies are using BPM software to automate such disparate tasks as employee hiring and orientation, professional services fleet management, accounts receivable management, sales pipeline management, collaborative design, procurement, customer service--and the list goes on and on.

Handling exceptions appears to be an area where BPM really shines. Organizations have few problems when it comes to normal orders or customer requests. However, it's the 5 percent that are exceptions that dominate the majority of the company's time and resources. Also, BPM is excellent for processes that extend beyond the four walls of the organization. In these cases, partner company employees will need access and roles within the system.

There are five groups of companies that hope to profit from the BPM software opportunity.

First, there are roughly 10 different pure-play start-ups with BPM offers, including Savvion, Metastorm, Fuego and Lombardi Software. The second group consists of work-flow vendors that have repositioned themselves as BPM players. Two prominent examples here include FileNet and Staffware.

The third group is the EAI crowd such as SeeBeyond Technology, Vitria and Tibco Software, which are heavily promoting their BPM solutions as extensions of EAI. Fourth on the list are the enterprise resource planning (ERP) vendors that have added BPM to their core functional applications. These providers will likely do well in shops that are heavily committed to one vendor. Lastly, there are the platform vendors--BEA Systems, IBM and Microsoft. These companies are building BPM on top of their application server architectures.

Simplicity is the key here--technology for technology's sake just won't fly.

BEA has an extremely clear vision for BPM. BEA will build the technical components of BPM mentioned above (IDE, process engine, roles, etc.) and leave it to the developer community to codify specific, best-practice processes on top of their architecture. This plan will allow BEA to leverage its position as an application server leader. It also produces a bit of a dilemma for the pure-play companies, many of which run on top of BEA's application server. Do these companies move upstream and focus on specific business functions or vertical solutions? Or do they risk having redundant technology with the platform vendors?

Microsoft, which is packaging its emerging BPM components in BizTalk, has a similar vision. It is rumored to be working on a BPM development environment that will take advantage of Visual Studio, the Visio flow-charting tools, and Active Directory for role management. It would also be quite obvious for Microsoft to leverage its leading position with its Outlook client whereby the "Tasks" folder would now represent queued business process tasks for each worker.

One interesting note about BPM is that it sits both on the business side of the house and the technical side of the house. Should a BPM vendor call on the IT staff or a business manager? The work-flow, EAI and the platform vendors clearly approach BPM from the technical side of the house. These companies are more comfortable selling technology than selling business process improvement.

The ERP vendors, on the other hand, live in this business world and are very comfortable talking about specific business impact in the sales call. It would appear that the pure-play vendors have more opportunity in approaching BPM as a business application than as a technical application. However, they will each have to make strategic decisions as to which core components they build versus the ones they leverage from the platform vendors.

It is important to remember that the "B" in BPM stands for business. The essence of BPM software is that it solves business problems for business users. Whether Web services or Corba or .Net is part of the underlying technology is about as interesting to these decision makers as the brand of disk brake is to most people who purchase automobiles. Understanding this critical issue is the one thing that will allow the pure-play start-ups to outflank the larger incumbents. BPM purchasers want applications that are easily understood, quickly deployed and have immediate impact. Simplicity is the key here--technology for technology's sake just won't fly.

Of course, the real winners here will be customers that embrace BPM to further automate, enhance, streamline and optimize their core business processes. These processes are the core intellectual property of most businesses. And just as the level of competition in manufacturing increased with JIT, the level of competition with respect to nonmanufacturing business processes will increase with BPM.

Companies that lead will succeed.

To join Gurley's "Above the Crowd" distribution list, visit Benchmark Capital's Web site.

The information contained herein has been obtained from sources believed to be reliable but is not necessarily complete, and its accuracy cannot be guaranteed. Any opinions expressed herein are subject to change without notice.