Bracing for BPM Disruption
The term “Disruptive BPM” has been used quite a lot and you see this term floating around the inter-web in recent years. I have been contemplating about this potentially controversial topic for over a year now. In this blog series we’ll explore the notion that it is actually a good idea that the “BPM world” should be disrupted. And in saying that, I do not mean in the traditional sense of the term “Disruptive Technologies”, like how Apple disrupted the music industry with iPods and iTunes. No, I mean apocalyptical disruption in the very fabric of all so called BPM practitioners’ thinking and all so called BPM technologists’ ideas of the same topic.
And in doing so, I hope it defines what disruptive BPM should look like in both cultural and technological aspects and how we can brace for this Tsunami through solutions like Appian. Within an organization’s context, I hope to discuss why BPM, in its traditional sense, would and should be disrupted with technologies like Appian within both Business and IT areas. In short, bracing for BPM disruption can be achieved by knowing, acknowledging and embracing innovative BPMS technology, and in turn, harnessing them as the key catalyst for revolutionary changes within the organization, to reach places where traditionalist BPM-practitioners have never been before.
A World Divided
Before I can even suggest that BPM can and should be disrupted to evolve to a new form. Think caterpillar-butterfly. We need to first understand this unbelievably huge dichotomy of this term – Business Process Management (BPM). It is as if the father of BPM bore two sons!
To perhaps the academics, engineers, scientists, managers or even philosophers the concept of BPM has been broached as a systematic management approach to improve process effectiveness and efficiencies. This is typically done through a sound methodology that continuously identifies key processes, improves them and implements these improvements through either technology and/or process change management. Some mistakes this for drawing boxes in a thousand Visio files. Let’s call this Businesses’ BPM. Businesses’ BPM is a type of discipline. They have university courses and masters degree on this very topic. Businesses’ BPM practitioners might use Business Process Analysis (BPA) tools, talk about governance and methodology, design process architectures, etc.
Very interestingly, technologists had a very different evolutionary path to this exact same acronym (the other brother). “BPM” in this case, evolved from workflow automation. Recently, analysts tried distinguishing it a little by adding “S” behind this BPM acronym, typically called Business Process Management Suite (or System, depending on which definition you read) – BPMS. In short, BPMS is one way of automating some processes – an exceptionally good way. In some cases, vendors keep the same acronym, ignoring the “S” by simply naming their technology product their “BPM Solution”. In our case we simply call it Appian.
The confusion between Businesses’ BPM, the management philosophy, and BPMS (a.k.a. Appian in our case), the software/technology, causes the first of many problems when trying to engage in “BPM”-related conversations at any level. So it is important to understand clearly the differences of the two BPM “sons” before we continue to understand why BPM should be disrupted.
“It’s incredible! BPM didn’t care that BPM exists.”
I guess Businesses’ BPM practitioners kind of know that BPMS technologies exists but somehow, that is only a small component tool in their bag of tools that they might use “when the stars and constellations should align”. I know. I was once a Businesses’ BPM practitioner. And in a way, still am if required.
BPMS on the other hand has a different belief system. As if to indicate that having an innovative IT solution would solve all of, what are inherently, businesses’ Process Management (not modeling by the way) problems; they operate as if Businesses’ BPM is not required at all. I’ve heard on many occasions, by customers, saying something along the lines of, “We have a BPM Solution that will help fix all that”.
It’s incredible. It’s as if they are rival siblings that know of each other but don’t want to have anything to do with each other. They don’t get together over Christmas to have turkey and ham!
Is it possible that the reason why Businesses’ BPM has been notoriously hard to get going, to justify or get budget for because often times the perceived planned value is hard to actualize? There is such a high upfront commitment in cost that when BPM is finally going it runs out of steam? “We have 1000+ process models in our repository!” one might say, gleaming with enthusiasm, as if proud and seen as a valuable accomplishment of having drawn the entire enterprise. Is this BPM’s true value? Granted, there are very successful “level 5” BPM matured companies out there. But how many are there? How many years have we been shouting BPM from the mountain tops?
Is it possible that technologies like Appian can and will disruptively change the relationship between business and IT and the nature of applications themselves? Here at Appian, we have seen it happen countless times. Appian is so easy to use that we can directly automate processes using process models created by business users and used by business users. Does this change everything we know in IT about application development? Is it also possible that we will see the end of large inflexible compiled applications, e.g. ERP? Will they be replaced with smaller modules based on process models? That’s great. However, would we have the same chaos as Microsoft Access or Excel had if we let business “loose” on process model-based development? Wouldn’t we need to Manage and Govern these processes someday? Somehow?
I challenge that one cannot exist without the other. They are two sides of the same coin. Like Siamese twins, these two brothers need to make up, to understand and respect each other and learn to work as a team. To know when one would need to act and the other support. Like a two person team tennis match. Both won’t need to hit the tennis ball at once, but working together, they win the game.
Maybe BPM disruption needs to be at the business/IT interface and in the very meaning of IT development or perhaps it needs to disrupt the different facets of the management team and their thinking…
Senior Solutions Consultant