BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 03 August 2017
  5.  Subscribe via email
As it's easy to get bogged down modeling processes, when do you know you're done modeling a process?
Accepted Answer Pending Moderation
Being ‘done’ modelling a process is like being done mowing a lawn.
Comment
Perfect response Peter ;-)
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
When both the work flow and data flow are implemented in the most practical and cost effective means available.
References
  1. http://www.phmainstreet.com/mba/mbass.htm
Comment
  1. Ian Gotts
  2. 1 year ago
  3. #4319
Nooooooooo. The process model continues to exist alongside any automation as it is the basis of iteration...."agile". Plus it is the operations & training manual and compliance evidence for the business. It is a critical asset of the business.
@Ian.. The way out of the complaint is to say that when we are "done" plan side, we generate a template and it is the template that is used to generate instances.

The process model continues to exist... ready for copies of the model to take on change and have users "model" the changes.

With processes that appear to be straightforward but end up (for one drug trial we did) having 600,000 permutations, it is difficult to invent scripts to stress test all of these, so, in practice, we are never done.
  1. Tim Bryce
  2. 1 year ago
  3. #4330
@Ian Gotts
I'm afraid I do not understand your comments. Of course the model is maintained, but the question was regarding how do you know when you are finished with it from a design perspective, which I think I answered rather succinctly. Is it a "critical" aspect of the business? No more than the other models, such as the business model, the systems model (including software), and the data base model; all are important to maintain and keep up to date.
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
Seems to me there are two distinct types of modeling

a) plan side modeling, where the objective is to bring the process close to what is called a "best practice".

b) run-time modeling where many permutations and combinations of instances are processed to make sure, for example, that there are no branching decision boxes that cause run time fails.(e.g. decision boxes that lack a "none-of-the-above" branching option).

Interventions above and beyond these can easily take process modeling initiatives into diminishing returns territory
Comment
A good time to throttle back on modeling is when you start to see "hammers looking for nails".
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
Just for my understanding; modeling a process for....?
Sharing my adventures in Process World via Procesje.nl
Comment
planning your work?
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
Considering that the word “modelling” is rather ambiguous let us replace it by the word “planning”. Thus the question “When Do You Know You're Done Planning a Process?” has an obvious answer – “When that process is not needed anymore”.

Thanks,
AS
Comment
plan, develop, model, simulate, test, debug, enhance, improve, align, update, upgrade, stream records onto template instances
@Karl, can you do "enhance, improve, align" without "plan"?
@Alexander.

No, we cannot do "enhance, improve, align" without "plan". In fact, there is not much worth doing without a plan - you might as well do arbitrary interventions in the absence of a plan.

"Planning is the design of a desired future and of effective ways of bringing it about" (Russell Ackoff, 1970)

Processes can be strategic or operational.

I submit one cannot do any of "plan, develop, model, simulate, test, debug, enhance, improve, align, update, upgrade, stream records onto template instances" without a process.

We need a process to evolve a plan, we need a plan to evolve a process.
RE "We need a process to evolve a plan, we need a plan to evolve a process." Can we simplify - process a plan and plan a process?
@Alexander Seems to me the suggested simplification changes the meaning . . .

"Process a plan", to me, gives an impression we have a plan and are doing something with it (possibly implementing the plan).
"Plan a process", on the other hand, sounds about the same as "evolve a process"
  1. John Morris
  2. 1 year ago
  3. #4340
Consider distinguishing the business activity of planning (i.e. the whole planning and managing chain listed above) and modelling, where modelling is the specific activity of abstracting and building a representation of the world. This is work with an output as object,"the model", which is then a technology artefact which is useful.
@John, RE "modelling is the specific activity of abstracting and building a representation of the world." Imagine that a new process has to be created. It does not exist yet but its model can be created. I think an explicit and machine-executable model of a process is not abstracting and building a representation of the world. It is new part (created by humans) of this world.
@Alexander . Interesting comment "an explicit and machine-executable model of a process is not abstracting and building a representation of the world"

Seems to me the notion of "representation" comes from mathematical models or physical scale models that people build.

Architects used to build scale models of houses so as to allow customers to view the layout - today they build 3D computer models where you can do a "walkabout", complete with "your" furniture in place. The 3D model remains a model in that you cannot live in the house until it is built.

In business, a process being modeled can be a representation/abstraction if it is at a higher level of summary relative to the eventual production process. If you build your model using "images" of forms as opposed to real forms that accommodate data collection, we have another type of representation. Often, we see both a high level of summary and form images (i.e. faster/easier).

Closer to production execution of business process instances, you can, in many situations, afford to expand to the actual production level of detail and substitute real forms for imaged forms - once you get to this level there is very little difference between the "model" and what will be the machine-executable run time process.

Here, we can continue to 'model' the process by having a small group of stakeholders "piano-play" the process but we no longer have a "model of the process" (i.e. what we have under test is very close to a 1:1 representation of the actual process).
@Karl, RE "there is very little difference between the "model" and what will be the machine-executable run time process." - actually, no difference because a digital artefact (mistakenly called "model") is the reality. Of course, the relationship between "template" and "instance" adds extra confusion, although any “instance” is the “template” at the moment “t0” (start of the instance life cycle).
@Alexander - Agree, no difference. And, yes the term "model" is a mistake.

We do need template\instance though because you can have multiple templates running contemporaneously and things become indeterminate in the absence of instances.
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
You never end modeling a process (unless it is discarded, as Dr. Samarin says).

But, you may "pause" modeling, in order to automate the process, measure and analyze it based on objective indicators (KPI's) and personal observation. And then, modeling again to improve it.

So, I'd say that you should "pause" your modeling, when you have a MVP (my mutation from lean strategies): Minimum Viable Process. A process that achieves its objectives and can be used to be analyzed.

Best !
CEO at Flokzu Cloud BPM Suite
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
An interesting question. In theory, if you follow guidelines such as the ABPMP CBOK, there should be at least some sort of validation of the "to-be" model against a baseline (control group?), be it the process "as-is" with real life data and/or alternate "to-be" models.
In reality however, there normally is at least 1 of the following 3 elements amiss, in order to bring such a model evaluation to fruition: 1. time and budget, 2. know-how, 3 technical tools.
Even if the evaluation turns out to be an "inside job", I have yet to encounter an organization mature enough (a bit old but something like this: link, at levels 4 - 5) to set aside the budget it would take to undergo a detailed analysis of how a new process model compares to another.
The know-how of process model evaluations is also something to be considered, as it not the same as evaluating a product, business trend or a resource (alignment of model evals to process performance management). Lastly, evaluating a model does at some point involve a simulation of sorts. Many "pure player BPMS" lack the technical features to run meaningful statistical scenarios, based on different given process models and changing sets of variables. That in turn would require incorporating other applications, in order to compensate (SPSS, R, SAS, Arena and such).
In short, nowadays, most of the time you are done modelling, whenever you managed to translate the users requirement into working model within a BPMS. That doesn't mean of course, that that's how it's supposed to be :)
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
When the project runs out of funding. They all inevitably do and then the 'continuous' part of process improvement goes straight out the window and long-term calcification begins. Until the next great initiative comes along; usually coinciding with the arrival of a new SVP or CXO.

Cynical, but true. :p
Comment
I see a number of red flags here.

Firstly, "out of funding" can be the result of bad cost estimating, or things changed from the time of authorization but the goals/objectives remain valid and worthy of additional funding. Out of control, granted, is a valid reason to shut down such projects.

As for ROIs that include funding for "continuous process improvement", I can't recall ever seeing an open-ended ROI.

Inclusion of costing in an ROI for "maintenance", on the other hand, is common and it is very easy to dedicate part of "maintenance" to "continuous improvement".

Why "great initiatives" need to come from a new SVP or CXO is a mystery to me?

Sure, it can happen but what % of the time?

Whatever happened to operational innovation that results in ROIs being submitted to new SVPs/CXOs for approval. My experience is many of these folks (not all of them) are too busy playing golf to come up with "great initiatives".

"Continuous process improvement" is a lot easier to handle when the funding comes from annual departmental operating budgets as opposed to ROIs.

Here, the usual finite timeline that is core to an ROI, runs for 12 months and the easy route is to simply roll over a line item of the type "continuous process improvement" for additional 12-month periods.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Junior Process Analyst: when the End event is first laid out in the model (fingers crossed).
Senior Process Analyst: when the process model has been tested via simulation (fingers crossed).
Actual Senior Process Analyst: when the Process Developer stopped asking me difficult questions (fingers crossed).
Process Developer: several weeks after go-live, when the obvious bugs have been squashed (fingers crossed).
Project Manager: whenever the Project end date is (fingers crossed).
Process Manager: whenever my next assignment starts (fingers crossed).
Process Improvement Manager: it's a never-ending virtuous circle, grasshopper (I hope my job carries on, fingers crossed).
External Consultant: what Process? no, you should have done Cases! Let's do it again! (fingers crossed)
COO: my Starbucks coffee is cold. There's something wrong with our Office Management processes, let's focus everybody on that.
SVP Sales: there should be no processes, we are all just one big mind focused exclusively on serving the customers.
CFO: Stay out of my ERP with your colorful visual crap.
CEO: I hate it when the sun burns so hot on the golf course.
CEO, Co-founder, Profluo
Comment
  1. Emiel Kelly
  2. 1 year ago
  3. #4336
You forgot:

Employees: Please can those visiotherapists stay in their fancy process improvement room, while we help our customers?
Maybe to add customers' voice as well? "If you stop modelling/planning your processes then we will move to another company"
  1. Emiel Kelly
  2. 1 year ago
  3. #4338
I think they will go to another company when you stop executing your processes well. Customers don't care about your process models.
RE "Customers don't care about your process models." of course, they do because they do not want face the same errors in your processes.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
With our DBP the model IS the application and as such you are never finished as inevitable change is required to be supported. This capability removes need for a final spec as ideas evolve before and after initial deployment. It be comes the visible transparent record of what has been deployed as effective actively the "new code" easily understood by business people including compliance, auditors, regulators etc as required.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
Why should we engage in discussions re customer participation in processes?

Is there really any reason not to seek/accommodate customer inreach and outreach at ANY point along a Case timeline?
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
When are we done modelling a process?

This question gets to the viability of the whole BPM technology project.

Starting from the premise that process modeling is one of the most powerful and important business technologies for any business, here are two perspectives on the modeling question:
-------------------------------------------------------------
1) TECHNOLOGY -- MODELING & ROUNDTRIPPING: The idea of modeling is great; in fact its at the core of what software is all about! Models in practice though have all sorts of issues; the biggest of which (not only in the process world) is the roundtrip issue. Make a nice model -- then make the model into useful or "executable" software. (The model instantiated as executable is, for all practical purposes, no longer the original model, and is likely also no longer business-analyst or business-friendly.) Then after using the resulting process, several days later learn what changes you need to make. This is good and inevitable. Now figure out how to incorporate those changes in the deployed model/process. (It would be nice to go back and forth between original process model and executable process model - this is the idea of the "roundtrip".) There are multiple ways of doing the roundtrip, depending on the software you are using. Except in a few cases, all of them are expensive in time and/or skilled labour. Your realize that your "push-button business idea / process modeling / business transformation cycle" is a lot less agile than you had hoped for.

See the following BPM.com article for more discussion:

Challenges of Being a BPM Pioneer: Part 4 - Building Work: Deploying Process Automation Artefacts

ANSWER: Concerning technology then, when are you "done process modeling"? You are done according to business needs, however your ability to reach that point will be slower than you'd like because of the modeling roundtrip problem. In many cases "being done" signficantly overlaps with "being frustrated".

SUGGESTION: You can avoid this problem if you confine your process modeling to very simple processes, or if you use newer technologies that minimize roundtrip issues (depending on process complexities), or especially if you implement the "business logic segregation pattern (see reference).
-------------------------------------------------------------
2) BUSINESS -- MODELING & MVP/LEARNING: What is a new "business process"? It's a new technology artefact which is a tool for helping you get more work done, more efficiently. It is in effect a "business product" of whoever built the BPM process. And it can be effectively managed as a business product probably better than as an engineering product. @Juan above as alluded to the idea of "MVP" ("minimum viable product" originally, but how about "minimum viable process" (see business startup guru Steve Blank, @sgblank). The MVP idea is powerful: really understand the business objective you need to support, and do only the minimum you need to do in that direction. This is in part a statement of humility - that you will learn more after deployment of an MVP than possible with any up-front analysis. That's in fact the whole idea behind MVP - learning. So you are "done" when you have an MVP. And then do it again.

ANSWER: Concerning good business practices then, when are you "done process modeling"? Your are done when you have a minimum viable process.

SUGGESTION: Think about "process artefact manufacturing" as a business. Business are always learning, but individual business products are packaged and shipped. As fast as possible. The MVP approach can be a model for this.
-------------------------------------------------------------
Comment
I assume the reason for wanting to go back to the original process model is to make and roll out changes?

The problem is to how to offload possibly thousands of instances, all at different steps along your process, compile the changed process, generate new instances and position the orders/claims/patients at what were current steps on the old instances.

If part of the change involved elimination of a step that was current you may have difficulty determining where to re-position your order/claim/patient (prior to the step that is now deleted, or after the step that is now deleted?)

Consider the more complex scenario where I have a process 1-2-3-4-5-6 and make a change at 2 that impacts 5.

No problem for instances not yet at 2, no problem for instances at 6 but what if you have an instance where the current step is 3 or 4?

Clearly, you will not have picked up possibly new data that is now required at 2 and it is possible that step 5 will be expecting/requiring the data that is missing.

So, depending on where your instances are at, it is not easy/straightforward.
@John, RE "modelling is the specific activity of abstracting and building a representation of the world." Imagine that a new process has to be created. It does not exist yet but its model can be created. I think an explicit and machine-executable model of a process is not abstracting and building a representation of the world. It is new part (created by humans) of this world.
@John.. I am having a problem understanding "The model instantiated as executable is, for all practical purposes, no longer the original model, and is likely also no longer business-analyst or business-friendly."

Why is the model instantiated.. not as close as users need it to be i.e. are you saying things have changed over implementation such that the process now has extra or deleted steps and that the run-time instances are out of date?

Why is the executable no longer BA or business friendly? Surely one could take reality from the Case (skips, jumps, insertions) and overlay this onto the original map, thereby showing the BA exactly how and where the run-time instance deviated from the original.

And, assuming a user-friendly run time environment such as a single split screen (tasks on one side, calendar on the other), do we not have with this a very good fit with the way people actually carry out work?
  1. John Morris
  2. 1 year ago
  3. #4350
@Alexander, re:creating a new process, and the meaning of such an act (and for the record this question is important, regardless of what some might say about abstractions).
You have made the interesting point that we are talking about adding to "a new part of the world" ("human-created"). (This is even a marvellous idea!) Consider the separate parts of this task: (1) idea for a new business process; (2) business analysis for a new business process; (3) BPMS-based model of the new process; (4) executable BPMS model of this process; (5) instance(s) of the executable. This "new process technology artefact manufacturing chain" flows from idea to artefact -- like all engineering artefacts. And as moderns familiar with technology we accept that the executable process model is "part of our world". Whether the original ideas are also part of our world I'll leave to the ontologists and philosophers. I will make the argument however that between idea and artefact is representation -- which puts BPM representations in the domain of language. (Interesting things can be said about language.)
Does getting all this correct help in the slightest where technology adoption is concerned? Or where selling BPM services are concerned? Certainly not directly - business doesn't care. But vendors should understand.
  1. John Morris
  2. 1 year ago
  3. #4351
@Karl: good questions, two to which I'd like to respond. Here are my versions of the questions:
1. "MODEL UPDATES OF LIVE PROCESS INSTANCES" - You have highlighted a huge issue. All organizations want to learn and to be agile. Especially when we have long-running processes (how about months or even years, for example tracking animal life-cycles). As soon as we deploy any new business process in a BPMS it's almost inevitable that we start learning that change is required. As you know there are ways of managing this important aspect of a BPM programme, but especially one can break up large/long processes into lots of smaller processes. Where real-time changes in live process instances are concerned (this is the brass ring of BPMS power), I'm familiar with one BPMS that permits this.
2. "MEANING OF NOT-BUSINESS-ANALYST-FRIENDLY" - In my experience, and is more broadly documented, deployed BPMS process instances typically require lots of technical work to make them viable (technical logic, SOA/APIs, performance-related etc.). The resulting process diagrams become more difficult to read, and in situations where the executable is a different language, one also has a roundtrip challenge. In all process artefact manufacturing cases, the Volker Stiehl recipe to which I've referred above, in the URL, can make a big difference. [The two models here are No. 3 and No. 4 in my reply to @Alexander above..)
@John, RE "business doesn't care" Sure and when we, BPM-experts, call that ready-to-execute artefact as "model", the business people, in 99%, react with "all models are wrong but some of them are useful". Thus, continue with this word "model" we are killing BPM.
Accommodating real-time change in live processes instances, in my view, pretty much makes/breaks any BPMS. save those whose customer bases only work with rigid processes. Nothing negative here, if you don't need or want agile, fine.

Breaking up large/long processes makes a lot of sense - if you have a process that "calls" a small process over and over, the last thing you want is to try to anticipate plan side, the number of copies of the small process. Embedding several means any maintenance you do has to be done several times as opposed to once.

A "link-to" capability solves this problem, but the organization needs to generate and subsequently index all data by sub-instances, otherwise it will never know which of, for example, possibly 5 customer orders, the data a, b, c, relates to. (the correct approach being I1a, I1b, I1c and I2a, I2b, I2c , , ,)

We end up needing "record holder\process template\instance\data"

None of this chaining of processes (large or small) works without pre-processing (should I engage processing or does the data / global variables tell me I should not?), then, for an extra level of comfort and to reduce downstream pre-processing complexity, not a bad idea have post-processing (did the process do what it was supposed to do?)

The bare minimum is one pre-processing auto-execute task as the 1st step along any process.

Re "Business - Analyst - Friendly", I don't see why a deployed BPMS process instance would need much input from a Business Analyst when you have in-line pre/post processing, users cannot easily engage incredibly stupid processing.

The process designer can define icons for as many external calls as needed with meaningful names and Help hints and just let the users pick processes/external apps as they wish.

As for performance, well, that requires a BA for sure because most run-time environments don't do motion-time-studies on how Case workers spend their time. Their patterns can change daily (today I have a two-hour window between meetings and I will a) advance the status of one large Case or b) finish off my tasks for three small Cases)
RE "Accommodating real-time change in live processes instances, in my view, pretty much makes/breaks any BPMS" - yes, yes and yes.
@John, RE "The model instantiated as executable is, for all practical purposes, no longer the original model, and is likely also no longer business-analyst or business-friendly." - I think, this is BPM-suite tool dependent thus not mandatory in BPM. I worked with one canadien product in which models and instances were treated in the same way (just
a slightly different set of operations on them).
  1. John Morris
  2. 1 year ago
  3. #4365
+1 @Alexander the difference between original BPM process diagram model and BPM executable model -- being "tool dependent". And the difference is as you say certainly not mandatory in BPM.
Three points: (1) BPM technology is a huge math/engineering challenge -- it's taken > 20 years to get to the product(s) to which you are referring -- and we're not done yet; (2) the technology business press has not really put much focus on this game-changing development; and (3) the organization of IT/business analysis/LOB for the resulting new opportunities (Volker Stiehl's recipe is just one aspect of this) has hardly begun. All this spells "OPPORTUNITY" . . .
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation
Alexander brings up an important point

"RE "business doesn't care" Sure and when we, BPM-experts, call that ready-to-execute artefact as "model", the business people, in 99%, react with "all models are wrong but some of them are useful". Thus, continue with this word "model" we are killing BPM"


The only thing of interest to business users is the ability to get orchestration (not that we would use these words) - the RT environment has to accommodate ALL interventions they want to perform including skips, jumps, exits, re-entry, re-visiting already committed process steps, recording data at not-yet-current steps, and inserting ad hoc interventions.

Individual users complain about governance but Case Managers want/expect governance and this comes to the UI in the form of advisories, alerts, cautions, warnings, at times hard stops.

What is absolutely critical is, once in, there can be no edits to Case History recordings. Otherwise, you no longer have a Case Management system.
Comment
RE "orchestration " - may it become "coordination" as a more generic concept than "orchestration" and "choreography"?
Yes, "coordination" is more generic and this picks up ex-BPM resources who may or may not show up in the Case History. i.e. I am a performing resource at a process step (i.e template\instancestep) and I seek a 2nd opinion. Some organizations may have a "consult" form where the performing resource takes note of the 2nd opinion but many users discuss a situation and then, as the performing resource record the consensus or their view only and commit the step.

My use of "orchestration" is we have things in the background to the BPMS that provide advice and assistance (context-situationally- appropriate) - I don't think most people would describe a rule set as providing coordination. The performing resource is the person in charge, they are free to accept/ignore this advice/assistance.
  1. more than a month ago
  2. BPM Discussions
  3. # 13
  • Page :
  • 1


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