1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 14 July 2016
  5.  Subscribe via email

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'?

Accepted Answer Pending Moderation

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)?

Sharing my adventures in Process World via Procesje.nl
No, you can't. See my "tips, tricks and traps" comment below. You have to trace through the process's execution to see what's not working as expected, including analytics' usage. It's like code. There's what you want(ed) it to do, there's what it does. ;)
@Patrick.. Precisely.
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Patrick Lujan
Blog Writer
Accepted Answer Pending Moderation

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.
@Patrick.. Re "a process model does not a performant workflow make.". - depends on how it was designed. A summary start->perform->finish concept model might be OK for an elevator pitch. No point compiling that to a template, rolling it out to a run-time environment and having different roles piano-play instances of the template.

If the modeller/process designer's objective is to give operational staff the ability to "manage" a process, then they need a level of detail where a new step presents when there is a change in roles (otherwise handoffs become difficult).

If one resource is performing some scope of work that has different phases (steps) where specific data needs to be recorded, then we need to go to more detail.

Beyond this, it's micromanagement.

Nothing of course to have two (2) execution modes, one for a new worker who is not familiar with a process, where an instruction sheet pops up before the worker gets to a data recording screen.

No instructions needed of course when running a instance in "expert" mode.
  1. Ian Gotts
  2. 3 years ago
  3. #1954
...but an operational process is more than a "performant workflow". The end to end process is a series of manual activities (some ad-hoc, some very defined) and automated activities (in BPM tools but also in line of business apps like Salesforce).
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
The gap is huge, particularly in the aspect of portraying the user's experience in interacting with processes that are intertwined.

What looks like a simple process is often in practice highly nuanced by the real world business context.
Founder at John Reynolds' Venture LLC - Creator of ¿?Trules™ for drama free decisions
There is always that up-front assumption that you completely and correctly captured what that UX should look like and understood it correctly. Then again, there's vision and then there's reality.
Hmm, I would have thought ". . .always that up-front near certainty that you have not completely and correctly captured".

In our practice we map in real time, compile roll out, model and we need several iterations of this before we stop getting complaints:

The list of possible complaints seems endless - the logic is wrong, steps are missing, steps are not needed, the forms that post are the wrong forms, the forms that post have missing data points/too many data points, the layout of the data elements on these forms is not the way workers like to record data, the labels on the form are misaligned with the intended context, the rule sets do not branch the right way, the calculations are not right . . ..
@karl well, yeah, I was being optimistic but "anti-agilist" aside, even with the best process discovery, modeling, design it usually does take a few iterations to get it right based upon those "highly nuanced" parts and people who do the process daily still themselves not knowing, understanding it as well as they say or think.
All requirements are wrong. Especially UI/UX requirements and business process requirements. But if you listen you can build the right requirements into your UI/UX and into your business processes.
I like to just sit in the cube and say "show me what you do."
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation

Definitely still a gap! Probably for lots of different reasons. Here is one:

[b]model-reality divide. [/b]
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
  1. http://
And, there is, aside from mostly end-to-end processes, no such thing plan-side as "the process" -

What we typically load into the run-time environment are "process fragment" templates that people, software, machines thread together.

At any point along the Case timeline, you can have ad hoc insertions plus external events that auto-import to your Case and disrupt ("Your order has been delayed due to industrial action - the expected manufacturing time is now 16 weeks instead of 3).

Oftentimes, we only know "how things [were] done" at the time a Case is closed (i.e. it ain't over till it's over).
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation

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:
[i][quote][b]Who is your audience?! [/b]

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 use
[b]1 solution...[/b]

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,
[i]with only tech / automation in mind.[/i]
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.
I love your account of the "I don't give a d*mn about your models" incident.

I once arrived at a site and announced I was ready to hear a description of the client's problem"

The response was "Never mind the problem, we just want a solution".
KM ontology anyone? ;)
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation

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.
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation

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”.


  1. Emiel Kelly
  2. 3 years ago
  3. #1932
Sorry Emiel, I should say - discuss and measure a gap between two undefined “things” is a good consulting assignment.
@samarin, dunno about that. If there's an agreed-upon definition of a thing and consensus that those are the parameters we're going to act upon...
  1. John Morris
  2. 3 years ago
  3. #1946
It is to laugh or to cry! What are we doing then if we have no theory and no reality? A sales person has to represent "something"! The first steam engine was built without a full theory of steam power and without railway tracks. But the engine got built and the tracks were laid. And theory and practice followed.
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation

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.

CEO, Co-founder, Profluo
  1. Emiel Kelly
  2. 3 years ago
  3. #1944
Did you see my beard?
I couldn't see past your tallness :-)
Right, it's like the UML. Models are different lens views of the same thing, just coming at it from different angles depending upon what you're trying to understand or convey.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation

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) "
[u]Is there a science[/u]
of process modeling?" and (2) "
[u]Is there engineered process technology[/u]
" based on that science which can be used in every day business? And there's a third question, (3) "
[u]How good are we[/u]
" at using that engineered BPM technology?

The answer is the science is almost there, but the usage lags. In part because there's
[u]a lot of software engineering still left to be done[/u]
[i]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[/i]
). 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.

[i]One little step for a plant manager . . . er, that's it for now.[/i]

Science + black art = alchemy = BPM. It's transitive. ;)
  1. John Morris
  2. 3 years ago
  3. #1952
Alchemy is also precursor to the science of chemistry and to chemical engineering. In the same way then, BPM-today is precursor to BPM-tomorrow.
Any chance of getting a few examples of ". . . BPM engine math problems"?
It is definitely still a craft.
@karl, might be something related to the fact that BPMN models are a sub-class of sound (soundness is a mathematical property) workflow nets, which are a sub-class of mathematical Petri nets with one source, one sink, and all other nodes on a path from source to sink.
  1. John Morris
  2. 3 years ago
  3. #1960
Thanks Bogdan; I recall you have written (on BPM.com, but couldn't find the reference) about coding in support of cross-process dependencies (i.e. write a variable, read a variable) which I think is an example of what happens when each process has to be squeezed into a single source-to-sink model. This isn't strictly an engine math graph resolution problem, but it is an example of the limitations of the technology (and just one source of friction between imagining a process and deploying a process).

As far as math is concerned, real life is messy, with loops and dependencies all over the place. One has to learn process model style restrictions in order to use today's technology in large part because BPM execution engines are limited in the complexity of the process graphs that they can resolve in real time. And that’s a math and software engineering problem.

For any given set of tokens at any given point in a process graph there will be forward and backward dependencies and one can imagine the escalating calculations required for a complex model. BPMN as sub-sub-class of Petri nets is the science; executable BPMN is the math-based software engineering.
I was scolded a couple of weeks ago by a certain Mr. Samarin about an example of an incorrect process I showed to him :-)). Yes, the process was semantically appalling for a BPMN expert (XOR gates not neatly joining after a splitting behavior, multiple end events etc). My customer didn't complain though - it produced the exact business behavior they expected.

I know the math well enough so I can live without it :-))
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation

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.

  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation

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.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation

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 [url=http://procesje.blogspot.nl/2016/05/process-models-really-helpful-for.html]here[/url]
Sharing my adventures in Process World via Procesje.nl
Nice post, Emiel! I wish I had more time to expand on it.
  1. John Morris
  2. 3 years ago
  3. #1963
"Flat" captures it. Even models generated by process mining (and I encourage anyone who hasn't seen a process mining animation to watch in amazement), which reflect the richness of reality much better than Platonic BPM models, are still only a one dimensional point of view (e.g. customer or patient).

Thus however marvelous the software and the model, they are necessarily gross simplifications. And using the model requires are all sorts of practical domain-savvy work-arounds.

As Mr. van den Hoven nicely points out, many models are useful, but all models are wrong.

It's worthwhile to make sure business clients aren't over-sold . . . the casual assumption of model fidelity to multi-dimensional reality leads to disappointment. You have to "own your simplification".
  1. Emiel Kelly
  2. 3 years ago
  3. #1964
Agree John. Even process mining shows some dynamics on top of a flat model.

And in the end, it only shows you symptoms of process performance.

Finding the cause is the next thing. Let alone implementing the improvements...
As long as this "the dynamics of execution" is absent, BPM is not able to address modern challenges such as "smart-contracts". Remember http://bpm.com/bpm-today/in-the-forum/do-you-see-smart-contracts-having-an-impact-on-bpm
  1. Emiel Kelly
  2. 3 years ago
  3. #1967
Thanks @keith Yeah, there's much to expand on it for sure!
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation

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

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.

Flowcharts are not going to go away.

We still need "best practices".

I have a healthcare customer with 150 users that provides home healthcare services where only 2 staff build/maintain flowcharts and they reasonably would not want to do so on a small phone (some of their flowcharts measure 20 ft x 3 ft)..

Twenty (20) of the users work in various clinics and use PCs or tablets (rarely phones)

The other 130 users that do the home visits use small phones exclusively. They must type up and upload their home visit report before then travel to their next patient.

All 150 see a "representation in checklist format" at their InTrays.

Without exception, they see a date/time list of tasks they have to do for TODAY (on a PC, on a tablet, on a small phone) and when they click on a line item they see one or more data collection forms. As/when they "submit", their task list refreshes.

Re "These days, nobody follows flowcharts - people collaborate" -

I think this has been true for a long time - Case environments for healthcare feature "background" BPM - the users rarely need to look at the flowchart.

Collaboration is routine in healthcare (handoffs when day workers go off shift, handoffs when one person starts a procedure and another takes over, handoffs when a supervisor re-assigns an in -progress step to level workload, two or more people at an encounter with a patient)..
  1. Amit Kothari
  2. 3 years ago
  3. #1973
Karl - thanks for the comment. Have you ever seen a zero UI or bot-only implementation of process management within a chat UI such as Slack?
@Amit ... I looked at Slack..

Interesting to an extent - we use Skype for 1:1 and small group chats and file exchange. We often copy/paste the Skype history to document software design conversations that can go one way, for a while then take a side trip and later come back. Skype works well for all of this.

Generally, I would say "offline" communication is bad if the content of discussions does not find its way into Case Histories (the problem is easily avoided by copy/paste, except that some cleanup is generally needed).
We are using Slack at work. It's cool, but it adds zero productivity when it comes to work processes. Zero productivity goes well with zero UI.
  1. Amit Kothari
  2. 2 years ago
  3. #2012
Bogdan - are you suggesting that easier communication leads to zero productivity?

I think several hundred million people will disagree with you there.
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Accepted Answer Pending Moderation

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.
  1. more than a month ago
  2. BPM Discussions
  3. # 14
  • Page :
  • 1

There are no replies made for this post yet.
However, you are not allowed to reply to this post.