From Emiel Kelly: Can you really understand the behavior of a process from a process model? But more important; how do you turn a 'to be' process model into a 'to be' process? Do you still see a big gap between the 'theory of process models' and 'the reality of processes'?
Seems like Peter combined more questions into one, but my main question would be:
Can you really understand why a process isn't performing from a process model (in BPMN for example)?
Yes, but not necessarily the way Emiel or the way this question is worded you would think. If you have an agreed-upon, well designed model that everyone likes the gap is in effecting that model. I've had a mantra for over fourteen years now, ever since the BPM "cowboys" first started showing up and touting models as an end-all, be-all panacea - "a process model does not a performant workflow make." Every BPMS has idiosyncrasies - "tips, tricks and traps" - as to how it effects and executes a process. That is, there are good ways and bad ways to design process automation on a given platform and I would not do one the same way I would on IBM Case Manager versus the way I'd do the same solution on IBM BPM versus PegaPRPC versus Appian versus BonitaSoft versus Bizagi, etc.
If you don't implement a process tuned to a given platform's idiosyncracies performance, stability, scalability go right down the turlet. This is the technical debt comment from Dr. S yesterday or day before and it rises up and bites many an implementation and client again and again.
As always, just my tuppence.
Definitely still a gap! Probably for lots of different reasons. Here is one:
model-reality divide. This is the gap between the abstract process model and the executed process (how things are done vs. how we say they are done). It can occur when there is a lack of information fusion or a blockage of information sharing. The accurate representation of a process is inhibited. I wrote a bit more about this and how some companies like Toyota use Yokoten to combat this gap in a blog post here --https://goo.gl/vPxoXQ
Oh my... where to begin...
Years back, I was engaged with a process analyse exercise with a Dutch telecom provider. Modeling away I just didn't get it why the business thought why this important. As they just didn't seem to care... Then I came accross a product with actually a philosopy behind it: Who is your audience?!
I might already have mentioned it in a former blog or answer, but the remark and question of an accountmanager working for that company went: "Walter, I don't give a d*mn about your models, the only thing I want is a valid, authorised pricelist." At that moment I suddenly saw it: It needs to be both practical and it needs to be a vehicle for analysis etc. I had to serve multiple audiences but use1 solution...
Using the product I was able to serve both the accountmanager. I "subscribed" him on the pricelist, which was a result of a process of course. It wasn't about modeling anymore, it was about process knowledge management! And there I knew that process knowledge management added real value. Far more than just creating models most business user would never look at or understand (well, not in that order...).
Now... The drill: I still think that a lot of people have a mental idea of what BPM / Process Modeling means. And that's pretty unfortunate. As that mental idea has been caused by various (BPM) tech implementators, with only tech / automation in mind. I don't say that that is not important and yes, tech is getting better and better... But the focus could have been so much better. The practical business gains could have been so much bigger...
So... Yes. There is still a gap, but I'm still advocating to narrow, and hey, maybe even close that gap one day.
NO...the process map can now be the application the real issues is that folk just do not believe ....or want to believe...the speed of build and support for easy change is truly disruptive. It really does work handling simple or complex making a future proof investment for business. Very simple really...all logic pre coded incl rules etc and build in the model to configure what is required. Click a button and using a declarative technique automatically sets up ready to run. Not only no gap between theory and reality but closes the gap between people and build of next generation Adaptive applications.
There is no common-agreed 'theory of process models'. (Remember the 8th law of BPM, see ref1)
There is no objectively-comparable 'the reality of processes'. (Remember the 1st law of BPM, see ref1)
Thus, it is too premature to discuss and, even, measure a gap between two undefined “things”.
Model is by definition just a facet of reality, one that helps us understand certain aspects of it (as per model's scope), but never all.
So it is natural that there is a significant gap between model and reality.
If we're talking about execution, there's just plenty of examples.
Just the other day we were discussing about the importance of data within business processes. Yes, we have the data object and the data store object. Trying to execute business processes with these data objects is like trying to shave with a bowling pin.
BPM.com is home to lots of jokes about consulting.
That's because BPM projects are still very much "craft" and not "manufacturing".
In this context, today's excellent question could be disaggregated into its parts: (1) "Is there a science of process modeling?" and (2) "Is there engineered process technology" based on that science which can be used in every day business? And there's a third question, (3) "How good are we" at using that engineered BPM technology?
The answer is the science is almost there, but the usage lags. In part because there's a lot of software engineering still left to be done (for example to deliver manager-friendly software which encompasses all of process, data and rules together and which is not arbitrarily restricted by BPM engine math problems). BPM software usage also lags because reality is really complicated. And there are questions of tacit work and process governance too.
Modeling work automation reality, and then deploying automation artefacts based on that model, is like a moonshot.
How many organizations can afford a moonshot?
So compromise happens. And we make little steps forward.
One little step for a plant manager . . . er, that's it for now.
Probably the biggest gap is between what business leaders see as a process model (their operational activities at every level from strategic down to executable) and what the BPM IT vendors see as a process model (executable BPMN). And it is now the business leaders signing the Purchase Orders, not IT. Business leaders buy solutions, not BPM platforms. "Never mind the problem, we just want a solution".
This IT view of BPM and process is outdated and the discussions are simply fighting for a better yesterday.
Is essence all models are wrong, but some are useful. You model for a purpose, and have different models for different purposes.
I use almost daily a model, in my car or in the trainstation, to get information how I will arrive at my destination. Is that reality? No it is a model, but it helps to understand the process I follow.
Can you understanding why a process is not performing on a model? Well, a model will help in thinking through the process. (Or the cases that follow that process) Adding actual data - facts - will help to better understand the process, and the performance of the output of the process.
can I look at a model of a house to see if it is "performing"..or more specific, the electricity model. Well, yes you can. Can I solve the problem when the electricity is not working? You need to measure, but the model will help to find out what you (should) measure.
Wow, thanks for all the responses.
To me "the dynamics of execution" is what misses in a flat processmodel like BPMN. That makes that such a model is so far from reality that can hardly be used to understand why processes aren't performing as expected.
Won't bother with a too long story here on the forum as I already wrote something about it here
Absolutely, the gap is wide and extremely painful now because BPM cannot enter the mainstream and be usable for SMB until the gap is non-existent.
I think the entire BPM industry is at a turning point in history, after decades of stagnation and tiresome million-dollar process mapping and improvement projects that are over-engineering and unused. Six Sigma still does not have a trustworthy way of knowing whether a process actually improved and STAYED improved or not. It's all based on snapshots and surveys, not real-life data from people doing a process.
I believe the future of the industry (both for SMB AND enterprise) is about making it easy to actually track a process being done.
Legacy approaches for process models based on flowcharts - simply cannot work today. Try looking at a flowchart on your small phone - is that going to work? Flowcharts are relics from the 19th century when people were just units in a production line. These days, nobody follows flowcharts - people collaborate.
Therefore, I believe the future of modelling is centered around the elimination of incredibly complex BPMN (which nobody but consultants and IT understand) and also flowcharts.
Linear and flat representation in checklist format are the only way to fit a process onto a phone, and we've managed to actually do it ourselves. Perhaps the real future is embracing web standards, since process search, discovery and state can also be an easy web standard that works for everyone.
There is definitively a gap. But there are also gaps depending on the process you are trying to implement.
Well structured processes work well when you have a goal of automation in mind. Ultimately the goal is to do the same thing over and over again with little to no room for deviation from the set forth standard.
The bigger gap shows up when processes involve people and the multiple permutations they may experience in real life. While it may be possible to approximate the model to reality, it will never catch all possible real life situations. This is why processes do require some level of flexibility and adaptability to perform per the "best practices" and "guidelines" defined by the underlying model. Software tools that allows and embrace this flexibility and put this in the hands of the "process users" rather than "process implementers" will likely have the better chances of success. The interesting dynamic here is how "process implementers" approximate the process reality as executed by the "process users" so that the gap is less and less over time.