The do’s in BPM
To conquer the many complexities involved in real-world business processes, it is a common practice to create models on different levels of abstraction, such that a process diagram is always bounded by the context of the higher-level diagram. With proper tooling, you can drill-down your process flows, and, given a well-structured design, quickly navigate throughout the design. If you’re not able to structure your processes top-down, chances are your process modeling effort will end up in total chaos.
You might be wondering if there is an end to the splitting-up of activities into lower-level diagrams, in other words: Is there a fundamental building block for business processes? The answer is a resounding yes. When you are at a level of detail that activities are always carried out by one actor (aka person or role), at one place, and within one short period of time, it makes no sense anymore to split it up. You might have come across the acronym ‘otopop’, which can help you remember this design principle: One-time, One-place, One-person. So, for instance, “write an email” makes a sensible activity, which you don’t split into “find a device, open your favorite mail client, press the button for a new email, type a subject, open your address book, select one or more accounts as destination addresses, optionally add a number of cc accounts, write your text, carefully read what you’ve written, and correct when necessary, and finally press send.” After all, a process model is not an instruction manual.
If you have multiple processes, and often even inside a single business process, you’ll soon discover that certain activities, or sequences of activities, occur multiple times. That’s a good reason to separate those out and manage them separately. You should always connect the main process and it’s auxiliary processes through uniquely named business events. Business events are the linking pins between your process model parts. Keeping a library of business events will help a consistent use, and thereby improve the maintainability of your process models.
If part of your process is executed by a third party, it often happens this third party offers the same or similar services to others too. There are two approaches to follow, the black box and white box approach. If all you need to assure is the interface to the external business process, a black box approach will work fine. You just agree on the events (start event, stop event and intermediate events), and on the delivery channel. However, if you need a deeper insight into the state of the outsourced process, and especially insight into the expected future flow of events, this may not be enough. In these situations, a role as observer in the outsourced process may fit your needs. And in case you’re very directive, you may just as well enforce your process on the third party, having them use your portal to do their work.
By now, BPMN 2.0 has become the common modeling language to design your business processes. If you haven’t adopted it yet, do so a.s.a.p. and leave those language barriers behind. In doing so, it’ll be easier to embrace open standards, if any, in your specific value chain. If there are no open standards yet, it is definitely a good idea to start developing a joint community of practice. Do invite all of your business partners, competitors, and their business partners to join your initiative, to create as much support for a common design as possible.
No matter what kind of tooling you are using, the experience you provide your users with is notably the most important success factor of all. A poorly designed user interface can easily break your business process initiative before you have time to fix it. Moreover, the user interface design may very well prove to be the most valuable piece of design for your system. This is where a logical structuring of tasks and cases gets decided. It’s also where you manage priorities and handle exceptions. Consistently. Besides, it should work for both experienced and inexperienced users, and for users in a multitude of roles, with different authorizations. In many situations, individuals play a role in a number of different processes, further complicating the design. And if you face inherent complexity, a simple solution just won’t cut it. A well-designed user experience, however, does help people do their job efficiently and effectively, like oil in a machine.
In the next and final part of this series, I will share some thoughts on the pitfalls of business process design you’d better avoid. And, of course, I’ll give my take-home message. So, please keep posted.
