BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 20 September 2018
  5.  Subscribe via email
Would you say there's still a big gap between process models and the reality of processes?
Accepted Answer Pending Moderation
Except for end-to-end processes, if the organization has a respectable inventory of process fragments (enough of these, enough detail), there is no gap between "work" and the reality of "processing" .

I don't think there is a "reality" to a process fragment - it's just a guideline with some embedded rules to prevent/discourage extreme unwanted deviation away from a "best practice" .

Reason: The knowledge worker otherwise has supervisory override over what gets done, what does not get done, what gets done next.

He/she can stream an RDBMS record (insurance claim, order, patient, police incident response) onto a process fragment and perform the steps as in the workflow, or skip steps, re-visit already-committed steps, record data at not-yet-current steps. [except where the workflow designer has tagged a step as an auto-exec step].
References
  1. http://www.kwkeirstead.wordpress.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
No but not all get that! As we say the "Map is the App" yes it is true you can now build any enterprise level application via a graphical interface where all business logic with different task types, links (workflow) UIs and all supporting needs such as RPA in built. We pioneered in UK (Microsoft tried to copy and patent) with early research over 20 years ago. Well proven but ignored as very "disruptive"...fraction of cost and future proof with change readily supported...just a question of when .......!
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
I would say that there is not. Considering the full set of artifacts provided by BPMN 2 to model almost any business situation, plus DMN, plus some documentation related to RPA components, plus web services (SOA) documentation, the process models correctly represent reality. In any abstraction level that you consider.

Said that I think that there is still a gap between the process model and the executable process (including the BPM Suite, the RPA artifacts, SOA integrations, etc.). The models are so complete, and complex, that it is often very difficult to implement with real (and affordable) tools. So, what sometimes happens, is that we have a very complete and powerful model, but it is very difficult to implement and use.

Agile approaches, with low-code BPM Suites, intuitive RPA tools, and apps connectors (like Zapier instead of pure Web Services), helps to reduce this second gap. Maybe they provide a smaller set of artifacts to model the process, but lets you move to execution immediately. So, the full path from reality to model to execution is shortened.
CEO at Flokzu Cloud BPM Suite
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
Firstly, I believe it depends on the level of granularity of the process model. If we talk about E2E processes, than the reality is pretty much in sync with the process model, however even on this level I have encountered a number of gaps between the model and reality. Simple example: on a high level the purchase to pay process follows these steps:
Shopping cart (+approval) -> Purchase Order -> Good receipt (not always relevant) -> Invoice receipt -> invoice verification -> Payment to vendor
Easy, right?
You don;t want to know how often the previous company I worked for received invoices for purchases without the existence of purchase order. In such a case, the reality is certainly not in sync with the model.

If we now dive deeper and arrive at the EPC or BPMN model of for instance the creation of the purchase order, than the differences only become bigger. When we conduct a process mining exercise (and we read out the log file of an ERP system into our process mining application) for this particular step (creation of purchase order), the result we get back is certainly not one single happy path wich all process instances follow. On the contrary, there are so many alternative routes that are being followed that makes the London subway map look like a Mondriaan painting (easy and straight forward).

As I am typing this, I have to conclude that the reality basically never perfectly follows the model and thus there is very often a gap between the two.

By the way, a model is a simplfied version of reality, hence it can never be the same (but that is more food for a philosophical discussion)...
BPM is all about mindset first and toolset later....much later
Comment
@Caspar, very exact and profound analysis, on which I entirely agree.
  1. David Chassels
  2. 2 months ago
  3. #5715
Casper you raise couple of very valid points in current perception of capabilities. Yes reality may well not have a detailed track of tasks in certain circumstances. We call that informal processes where there is a start and an expectation of an outcome where workers use their skills intellect etc. However such informal processes are readily incorporated into design and build in the graphical build so the second point is use the right "platform" and it looks like this does not include BPMN then you do have a model that is exactly what is deployed. As for multiple paths in formal processes again this is readily incorporated.
Your comments just help me understand just how "disruptive" our declarative approach is.....
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
There always exists a discrepancy between a model of business process, however well designed and accurate, and real execution of this process in a business environment. The reason for this gap is an unforeseen depth and hidden details inherent to any real process.

Real business model of organization is ultimately unlimited in its depth. Going from highest management levels, it descends to individual departments, client relations, production units, technical code of equipment and controllers etc. In vast majority of cases, it is impossible and senseless to build a complete model covering all and every fine detail of the business.

Omitted lower layers of the model create (pseudo) random fluctuations during execution of the model. Real execution paths of a process never follow its model exactly. However, in case of the correct model, we can expect to see that an ensemble of execution paths statistically converges to the model as to its average path over a significant set of observations.
Comment
@Boris . Yes, yes, yes.

This is why we have ACM (consisting of 1. workload/workflow platform, 2. background inventory of BPM process fragments)

Put the Case (a cursor position in an RDBMS) onto a process fragment template, then follow the template, BUT, if you need to deviate, just go ahead and skip, jump, re-visit, record data at not-yet-current tasks and the rule sets discourage or block extreme unwanted deviations.

Bottom line, users can do what they like and if the organization takes the trouble to mine their data and update their "execution paths' . they are in the business of 'continuous improvement' and their "best practices" get better.

No need for a complete model - the process fragments are capable of increasing efficiency, effectiveness, reducing errors and omissions . . . . ., all good stuff.

So, a big question is why doesn't everyone understand that the BPMs or ACM run-time environments that members of this forum have CAN handle real "work" and, for the average corporation that is low on the maturity curve, are capable of giving the organization a jump start improvement in efficiency?
@Karl Walter, thank you. Incredibly relevant observations. Exactly case variability makes business models real and robust.

  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
Of course. A model is a model and not reality. Even when the model steers an application. Then it's still an application, not a process.

And those who believe you can understand processes by a model, good luck.... http://procesje.blogspot.com/2016/05/process-models-really-helpful-for.html?m=1
Sharing my adventures in Process World via Procesje.nl
Comment
  1. David Chassels
  2. 2 months ago
  3. #5719
Totally disagree....all process can be represented in a model where build can now take place which becomes a live application supporting people at work and ensuring knowledge of activity correctly recorded with one version of the truth. Sure some processes are informal as I have described and may not be helped or need an end to end application.. but still needs to be recognised maybe only time being the measure awaiting the outcome.

I was modelling processes in the 70s and yes they were not contained on one application with silo systems doing a lot of "processing". But now with outside in BPM driven thinking with good supporting software driven by business in their language the game changes...you remind me of a conversation I had a decade ago as I tried to explain to a traditional programmer this new capability. He smiled and yes sure but not I my lifetime...and walked away not wanting to really understand........!
  1. Emiel Kelly
  2. 2 months ago
  3. #5720
I am not disagreeing with the fact that applications can be build/run based on models. That's been around for years. But to me that's an application to support the execution of a process, not a process.

And even if it was, the application is the process, not the model.

But to me a process is everything you do and need to deliver a result. So including people, information, steering, behavior, etc.
  1. David Chassels
  2. 2 months ago
  3. #5721
Ok agree the process is "everything"... My point is you can now build the process application in the model, click and deployed so the model is the process application; effectively the "new code"...simple and very powerful that delivers all business process execution requirements.
(sigh) ... Policy, Procedure, Protocol, Practice, Model, Modeling, Simulation, Application, Platform, Orchestration, Governance

For me, an application is an encapsulation of features and functions.

As for "model", we all know that typically is 'a young lady walking back and forth on a "runway" wearing the latest clothing fashions that will soon become unfashionable'.

If, indeed, it's a "runway", why do they walk so slowly?

?
English is difficult - I have never been able to figure out why we "park on driveways" and "drive on parkways".

Right up there in terms of confusing terminology, I do not understand why I have to pay to drive on a freeway.
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
Digital models are the reality. See ref [1]

Thanks,
AS
References
  1. http://improving-bpm-systems.blogspot.com/2018/04/better-architecting-with-digital-model.html
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
I agree with the notion that there are different levels of deviations for process models compared to reality. Of course, that is to some extend explainable by the factor of abstraction a process model by default represents but also by the distance of the process model from the final customer (market) as well as from the business' mission critical context factor.
A typical mission critical process could be a sales process, which, grouping its activities by purpose, could then be divided into a "Time-to-Yes" (TTY, the approval part) and a "Time-to-Cash" (TTC, the post approval execution) portion. Usually, one can observe a tight representational fit of a process model and TTY, while the further one travels the TTC portion, the more deviations between these two occur.
I believe, that pattern is heavily influenced by an increased process maturity (knowledge - yes, Karl :)), the closer a process (portion) is located to actual, mission critical market forces.
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
If there is a significant gap between the model and the expected real process, it's the modeler's doing:
If the model is easy to use, but too simple to reflect reality, there is an incomplete understanding of the reality.
If the model is very accurate, but hard to use, there is a lack of modelling skills.

If the difference is between expected real process and actual real process, it's the business's doing: there is insufficient drive or expertise to push the desired transformation.
CEO, Co-founder, Profluo
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
  • Page :
  • 1


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