This is the third and final part in my series on business process management. In the previous episode, I shared a handful of tips to design successful business processes and build an application your users will actually appreciate. I introduced ‘otopop’ as a generic design principle. If you haven’t read it yet, I recommend to do so before you continue reading this post. Chances are it’ll make more sense to you.
However, if you apply the good practices you already learned, and avoid the common pitfalls I share in this post, success is certainly attainable.
The don’ts in BPM
Did you ever notice? Sometimes, people’s expectations are just not realistic. Occasionally, it seems people expect technology to automagically solve whatever problem they experience. So it happens with business process management too. If an organization is in some kind of trouble, In fact, if your organization is in chaos already, with people fighting over responsibilities and what not, introducing business process management as a solution to your woes is doomed to be a waste of time and money. In itself, it will not fix anything. Inventing a new way of working, shifting culture can certainly be supported by business process management, but it still requires true leadership to bring change about. There is only so much technology can bring on its own. If you want to be realistic, rather look at BPM as a tool to streamline your way of working. That’s what technology has to offer. And if you want to bring change, it might be best to first bring in BPM to harmonize and streamline the current way of working, and only then gradually bring changes to your processes. Otherwise resistance to change may simply turn into resistance to use your business process application.
If you interview people about the work they’re doing, and the process they follow, often a lot of the work involves collecting information from different sources and registering it into different applications. It may be tempting to model the business process likewise. However, this is a common pitfall. Remember the otopop principle? What you’re actually doing here is importing application integration logic into your business process. This will clutter your design, and make it cumbersome to maintain. IT changes all the time, which may very well impact your business process model. However, you should only want to change your business process model when the business process actually changes. So the best thing to do is integrate with data sources on a logical level. Just fire an application event, and have some integration service do the heavy lifting. This will keep your business process clean and future-proof.
Mind you, however, your business process should still be in full control of execution. In other words, your application integration logic must always support the business process, never constrain or direct it. It should never merge different business activities into one service, for instance. It should also not enforce a fixed sequence of processing, especially if that makes no business sense. In other words, it should always allow the business to organize their processes the way they see fit.
Another common pitfall is to design the decision logic into the process flow. Again, think otopop. Taking a decision is a single activity, even when it is automated. Just imagine how a process model would look if you would model all the criteria involved into deciding to grant a patent into your process model. Or when all the rules on how to distribute work inside the organization are translated into gateways in the process design. And then think about the effort it would take to update it to changes. There is a reason why business rules engines and decision management systems were invented. There is even a special type of model, the decision model notation (DMN) published. DMN complements BPMN, providing a separation of concerns between the decision and the process. So think again when you face the problem of modeling complex decisions.
To make parts of your process reusable, refrain from modeling fixed sequences of activities. Either join them, if they abide to the otopop principle, or, in case of a breach, put an intermediate event in-between. You may soon experience the same kind of event stemming from a different part of your model. Presto! Reusability potential unveiled. In general, it’s likewise a good practice to design more abstract activities, whenever the execution is largely the same. It makes little sense to have separate activities for “Send notification of delay”, “Send notification of progress”, “Send notification of shipment” when, in fact, the activities are alike. Rather have a single “Send notification” activity handling a number of different incoming business events, each assigned to a different notification template.
A special case of abstraction is found in the activity “Keeping a Register”. There are many types of registers to keep. A cash register, a membership register or a product register. Or even the patent register. The process of keeping the register up-to-date is surprisingly similar – and often the follow-up action of business decision. Consequently, registration activities can easily be standardized, and modeling separate activities for keeping different registers should be avoided.
By the way, if you value flexibility and agility in your operations, modeling flow should be avoided whenever possible. After all, any predetermined flow will constrain the order of activities. This is sometimes necessary. But even then, it’s often better to rely on your people to do the sensible thing. There just might be the exceptional occasion you haven’t thought of while designing your process, which requires to take a decision before all the formalities are settled. Perhaps you want to be able to stretch the immigration rules if the applicant is the future queen. Things happen. And when your flow is cast in stone, you’re stuck. So it is always a good idea to leave as much responsibility with your case managers, and to hold them accountable for their decisions. Look at it this way. If your process just defines the guardrails no-one can ever cross, then you trust your people to choose the best pathway in every case they come across.
Remember, a clean, consistent business process model will support a clear user experience. It also works the other way around. A clean, consistent user experience design supports clear business processes. So, never underestimate the art of user experience design and the power of a well-structured process design. Making software as simple and intuitive as possible may be hard, but is very rewarding too.
Take-aways
Applying a business process management product can be of great help in streamlining and harmonizing your operations. Especially when your process is less than straightforward, perhaps error-prone, and you desire to establish control. I’m not sure we will ever leave the business–IT alignment problem behind us, but I’m sure that when you follow the do’s and don’ts I shared in this series, we will make significant progress.
If you face real-world complexities in your business processes, you will most likely need multiple technologies to help you conquer those. Fortunately, WSO2 offers a rich set of technologies as an integrated, business-ready platform – a solid business process server, an award-winning enterprise service bus to do your application integration –which comes with a business rules engine included– and a full-blown analytics server, capable of doing real-time analytics, to get you really in control. And there is even more. Machine learning. Entitlement management. API management. You name it.
Making the best use out of each of these technologies, however, is not easy. It does require vision and experience. That’s were Yenlo comes in. We help our clients to become successful at leveraging their full integration potential, ranging all the way from architecture to operations. Perhaps you should just give us a try.
