As BPM begins to expand beyond isolated projects to mainstream programs at the division or enterprise level, there is a need to engage a far greater number of business people in the effort. That’s not easy, and achieving it is going to require significant change in the way BPM is practiced.
The most important role for business is probably documenting current-state business processes and analyzing them for possible improvement. But conventional practices in this area are inefficient and inherently small-scale.
One typical scenario involves a team of business analysts or business architects mapping various processes using Visio or Powerpoint. Doing this requires no special tools or training, but the resulting process maps are not easily shared without elaborate accompanying explanation or documentation. The reason is each modeler makes up his or her own conventions about what the shapes and symbols mean. There is no defined methodology. The sphere of understanding is thus limited to the individual modeler. This scenario doesn’t scale, and you can’t base a BPM program on it.
In another typical scenario, a process improvement consultant comes in and works with a small project team, with the goal of fixing some process problem in the business, or at least mapping out a plan of action. The consultant’s emphasis is typically on a facilitated methodology, not on tools. In fact, the “tools” employed are frequently yellow stickies on the wall and paper-based tables and charts. While this is fine for fixing isolated problems, it does not scale to program-level BPM. Again the sphere of shared understanding of the process, as-is and to-be, is limited, in this case to a small radius around the facilitator. And paper-based tools? Come on, this is the twenty-first century!
At the other end of the spectrum, a small group of business architects or enterprise architects may use repository-based Business Process Analysis suites to model the business at the division or enterprise level. Besides process, these suites model data, strategies and goals, KPIs, policies and rules, organizations and roles, services and systems, and so on. The tools are great for looking at the company’s core end-to-end processes and aligning them for consistency, data integration, and governance at the enterprise level. But they rarely get down into the weeds of the problems affecting process performance and quality at ground level. They are really about architecture, not process improvement. The tools are proprietary, very expensive – over $10K per seat – and require weeks of training in the methodology. For this reason alone, the approach does not scale.
Each of these approaches brings something important to engaging the business on a larger scale: software tools that are easily accessible, business-friendly, and inexpensive; a way to clearly express problem areas, including exceptions, in the process model; a well-defined methodology for translating process understanding into diagrams that can stand on their own; and a repository to facilitate model sharing, cross-referencing, versioning, and reuse. The trick is combining them.
Pieces of the solution are coming into focus. BPMN is one key ingredient, as it provides a business-friendly visual language for process modeling, able to express exception-handling and other process details, with predefined meanings for the shapes and symbols. Thus the diagrams, if created correctly, can stand on their own, shareable across the enterprise without accompanying explanation. BPMN is a standard, and tools are inexpensive, in some cases free.
A model repository is another. This is a database of process models supporting versioning and governance, allowing collaborative editing by team members without sacrificing authorization and access control.
Making these tools easily accessible across the business has been a challenge in the past. Now a number of tool vendors, including IBM, Lombardi, and SoftwareAG, are making repository-based modeling, including BPMN, available through cloud computing. Typically these are vendor-hosted sites that allow users to set up collaborative BPM team spaces on the web for a low monthly subscription. While the previous BPM era emphasized downloadable desktop tools for business users, the new trend is toward browser-based tools hosted on the web by the tool vendor.
With the tools in place, you still have the problem of using them effectively. BPMN proudly has no methodology, and its full palette of shapes and symbols is admittedly overwhelming. Very few people, in fact, either in business or IT, know how to use BPMN effectively. To encourage business engagement, one tool vendor strategy is to reduce the modeling palette to a minimal working set, essentially those carried over from traditional flowcharting, and make up the lost expressiveness through freeform commenting features. The idea here is that to engage business more fully, we need to lower the tooling barriers, making BPM so intuitive that anyone can do it.
I would call that the predominant view right now, but I don’t think it’s the right view. Certainly it’s not the complete answer. The reason is that in order to capture the exceptions at the root of process improvement, and in order to collaborate with IT in the development of improved to-be process implementations, business can’t rely on what it already knows about process modeling, because it doesn’t know enough. It needs to learn to think about process in a more disciplined, structured way – more like IT, but from a non-technical business perspective. It needs to understand what the BPMN shapes and symbols really mean, and how to use them effectively to communicate through the diagram. And it needs a methodology, a step-by-step cookbook for going from an empty page to a complete diagram.
In other words, instead of just dumbing down the tools to the level of untrained users, we could also educate and train business people to use BPMN as it was meant to be used. I’ve been doing that for over two years, and I’ve come to see through that experience what is probably obvious to many of you already: business users are not all the same. They don’t all have the same skills and they are not all trying to do the same thing with process modeling. What is essential detail to one group may be down in the weeds for another.
Consequently, I believe the right approach is to view BPMN as a hierarchy of levels. Level 1, meant for any business person, uses a limited palette and is intuitive to untrained users. Level 2, aimed at business analysts and business architects, uses a wider palette to capture nuances of process behavior, including event and exception handling. Level 2 is that long-sought common process language shared by business and IT, something absolutely needed to truly empower business in BPM. Level 3 is using BPMN to describe executable process implementations, really just for IT.
The hard part is making each level a refinement of the previous one, not a do-over. That means imposing some structure and discipline in the methodology of Level 1, so that the Level 2 modeler doesn’t just throw out the Level 1 effort but instead just tweaks it. The end result is one model, viewable at different levels of detail by different groups of users for different purposes, not separate models for each purpose.
