Change Agent: Getting Started in BPMChange Agent: Getting Started in BPM

Newcomers to business process management invariably ask, "How do I get started?". If you view BPM as a software technology, you would normally answer this question something like, "Well, you start with a small pilot implementation, and ..." But most people curious about BPM don't think of it as a software technology or an "implementation" at all. They see it more as a new way to understand and measure their business--from a cross-functional, process perspective rather than from the functional perspective that typically has dictated org-chart boundaries and the scope of enterprise applications.

From that perspective, the way to get started is obvious. You start by modeling your core business processes. Modeling is not implementation. It's essentially a paper-and-pencil exercise, but it's easier and more effective with a process-modeling tool. In most organizations, "modeling" is something that IT architects do, but process modeling is inherently a business-analyst function and requires a distinctly business-oriented perspective.

Process modeling can be performed at different levels for distinct business purposes. At a high level, its purpose is simply shared understanding of the essential features of the process, the handoffs between roles or organizations, together with some sense of the goals or key performance indicators for the process as a whole. It is basically descriptive, and completeness or fine detail is often not required. But you can take modeling to a deeper level, estimating the values of the KPIs (key performance indicators) to be projected using simulation analysis. Performing process modeling at this second level requires a complete model, though knowledge of the technical implementation of each activity isn't necessary.

The ultimate goal of BPM, however, is to go even further. Level 3 modeling can generate an executable implementation in a BPM suite. That means development of an automated, end-to-end solution without programming. In a growing number of BPMS offerings, the process designer in IT doesn't use the business analyst's model as a "requirements document," but actually layers the implementation attributes on top of the original model (see my "Put to the Test" review). At this level, modeling becomes an essential enabler of business-IT collaboration.

A good process model is more than a Visio sketch. To be effective, process models require a structured diagramming notation that is both simple enough to be understood by untrained users, yet precise in the process semantics attached to its various shapes and lines. Until recently, most structured modeling notations were proprietary to each tool vendor, but today Business Process Modeling Notation is emerging as the de facto modeling standard in the BPM world. That's good, because standardization not only expands the number of people who can understand your models in detail just by looking at the diagram, but also significantly lowers the cost of the tools required.

BPMN by design is ultra-simple. It only has three basic shapes: rectangles for process activities, diamonds for flow control points, called gateways, and circles for events, signals that "something has happened." Events make BPMN different from conventional flowcharting, since they describe how a process responds in real time to signals from external systems or processes--a customer changes an order or an error or time-out occurs. Typically 80 percent of process cost comes from 20 percent of the instances: the exceptions. BPMN lets you model how those exceptions are handled.

Also, unlike most modeling notations, BPMN is meant to be shared by business and IT. It can be used at Level 1, Level 2 and even Level 3. The spec describes mappings to the BPEL execution language standard, for example.

If you're wondering how to get started in BPM, it's simple. Just model your current process. No large upfront dollar commitment is required; several BPMN-based modeling tools are free. That first step leads to shared understanding, discussion and debate, then to proposals for improvement. At Level 2 you can quantify the expected performance improvement using simulation, and at Level 3 you can even build the implementation, without code. You'll get there eventually, but you have to take that first step.

Bruce Silver ([email protected]) is an independent industry analyst and author of the blog BPMS Watch. Engage in the discussion at www.brsilver.com/wordpress.