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.
That idea is the basis of my new book, BPMN Method and Style, and my new BPMInstitute class Process Modeling with BPMN, offered September 23-24 in Washington DC. If you want to learn how to effectively engage the business in BPM across your company, come to that event.
I work with business clients to redesign their processes. This is an intervention to (re)create a “clean slate” for the process; the first step to manage processes and improve it in a controled environment.
To perform such a redesign, we pull together an improvement team from the operations for 2 to 6 weeks (depending on scope). The team members are the knowledge expert from the various aspects involved in the process, from mail room clerks to processing clerks to client-service reps to accountants. At the end of that time, the team has 1)mapped the AS IS; 2)identified problem areas and performed a root cause analysis; 3)defined principles for TO BE; 4)created the new process and documented it (including risk analysis, dependencies, benefits, change management strategy etc). Our output is a proposed new process, to be presented to senior management. The team disbands at that point, having accomplished its mandate.
We have been doing this type of work for over 8 years and found that merely subjecting this disparate team to the notions of process management can be a challenge. As we want them to “get it”, we decided to not impose the added challenge of learning to use a tool. We have found working with Post-it notes to be the most effective way to map out the AS IS and TO BE, given the team is together in one room for the duration of the project.
We do not use BPMN is our redesign projects. I have taken BPMN training to assess where it could fit and see a valuable use for this when we need to simulate a conceptual new process. I do not see a role for BPMN at the time the afore-mentioned team is convened. The team is not together long enough to be able to learn and apply effectively BPMN.
That being said, I do see a role further down the line: Upon senior management’s decision to move ahead with the recommendations, a new team is formed with the mandate to validate the (first team’s) concept and implement it. This second team can be together for a period of time extending from a few weeks to a few months, depending again on the scope of the process being implemented.
This second team would benefit from the simulation capability allowed by BPMN. Again, this is a disparate team, which very often does not include an IT member; hence it still would face a learning curve with BPMN and still be without assurance it could produce a effective BPMN model efficiently. We opted not to pursue that approach.
Instead we favor the development of BPMN expertise within the organisation. Such expertise would be brought into an improvement team from a central source. This would ensure standardized modelling and enable the central repository of processes. While working with the improvement team, the BPMN specialist should limit his models to Level 1. Further along in the implementation, when IT becomes involved to develop backend support solutions, the specialist could refine the model at the required level.
One area I still do not have clarity: Should this BPMN specialist be someone with an IT background, or someone with a statistical background? I have been going back and forth of this and currently tend to favor the latter…