Long Live BPM 2019
10th of February 2019Every beginning of a new year, there is always a slew of retrospectives about all manner of architectural and managerial methods, and more often than not, we will see articles, usually by luminaries of said methods to declare this new year the end of the discipline they are known for. This year is no different, as we spot a thread over at BPM.com where Jim Sinur, guru in this area, doesn’t quite say that BPM is dead, but that there are several aspects of it that deserve to be deceased. It is funny to realise that Jim Sinur’s observations were also a large part of my 2018 retrospective of BPM.
So, let’s take a closer look at the seven point that Jim Sinur is listing so that I can give my take on what he is trying to position as dead men walking. See below for a screenshot of the post that he made on the BPM.com forum for reference. The thread contains other people’s point of view on the matter as well, so be sure to check out the source of this thought.
The first point states the belief of process experts that business processes are at the center of the universe rather than a tool to be wielded in order to help business deal with their ever-changing reality and the reality of the market in which they position themselves. This is a fallacy not only present among BPM enthusiasts. I have seen enterprise architects taut the same insight about their capability maps, governance experts about COBIT or any other methodology they employ, and even developers about their weapon of choice out of all the coding languages. I tend to agree with Jim Sinur on this one. I do not believe a silver bullet to cure all ailments of a company will be found in my lifetime, but I am always happy to be proven wrong. Further down in the thread, John Morris seems to disagree, and while reading Roger Tregear’s book “Reimagining Management”, it does seem he does not share this view either, as he quotes the cornerstone of modern management to be the primacy of the process.
The second point is about applying management to processes that offer very low visibility to its participants. Here I do not agree. Even if processes have no visibility, it is advisable that as a company you should at least be aware of these processes in order to determine whether this lack of visibility is warranted, or whether it is a lacuna that needs to be addressed within an appropriate time span. If we disregard these processes and let them persist in their fog of war situation, and they would have no use or added value, they would continue to consume resources that could be put to good use elsewhere in the organization. As a synergetic process, they might even slow down processes that are critical and visible to the organization. So, to disregard them during process management might come back to haunt us, usually at the most inopportune of moments, invoking the obligatory cursing of Murphy’s name. And if he means fully automated processes, the visibility becomes even more significant as operational support people should have the tools to be able to do their jobs when troubleshooting and proactive maintenance and hotfixing.
The third point where he states that reactive processes should be come proactive puzzles me a bit, as I do not clearly see or understand where he wants to go with this point, so I am going to refrain from commenting on it.
When listing processes with hard coded rules and sequences (4th point), it seems to be the old BPM versus ACM discussion. This feels strange to me as Jim Sinur’s diagram on the matter had already concluded to me that they are both tools in the same toolbelt of management techniques. Even on the market, most iBPMS tooling nowadays supports both BPMN and either CMMN or a similar case modelling syntax. This battle has been fought and both of them shared a joint victory. No point in dredging up old war stories and opening up old wounds.
(c) Jim Sinur as seen in "Mastering the Unpredictable"
When talking about dynamic governance (point 5), I am going to assume this is about implementation of sociocracy within an organization and leveraging this organizational structure to manage processes with an increased buy-in from your participants. I hope this is what Jim Sinur is hinting at, otherwise I am barking up the wrong tree. While this is a viable management technique, I feel that he falls into the same fallacy of was referring to in my assessment of the first point. It is a valuable approach, but by no means the only exclusive way to go about process management.
Looking at the sixth point in the list: When it comes to the possibilities for automating user tasks within a process, it is clear that capabilities such as RPA, CPA, machine learning and any other new technologies that might pop up in the coming years, have been a blessing for the BPM discipline and gives its practitioners a plethora of options to help organizations streamline and optimize their operational endeavors to be more cost-effective and effective in general. This was already on the radar of several people at the BPMNext 2017 summit, where Nathanial Palmer revisited his definition of iBPMS tools.
Point 7 (“Processes that are not linked to customer journeys”) sounds to me a lot like Jim Sinur’s earlier point of process visibility. There are many support processes that are not directly linked to a customer journey, for instance maintenance processes, that should not be so casually discarded. They are the grease that keep the cogs clicking in those processes with a direct result for the customer. If they are ignored too long, significant technical debt might accumulate, triggering an eventual massive cost in maintenance with expensive digital transformation initiatives as a result.
My two cents on the matter are here for anyone’s reading pleasure, and I do not pretend to have the same expertise and experience as the originator of this thought. I can only write down my musings in the hope that my readers can take from it some wisdom or take this article (or the parts useful to them) as a basis for their own conclusions.
| Thought | BPM | Business Architecture |