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

From a comment E. Scott Menter made on this discussion where he wrote: "Flowcharts (including IMHO BPMN) are simply not a great way to build an executable process model." What do you think?

Accepted Answer Pending Moderation

When reading the question, one thing keeps on resonating in my head: "what does executing mean?"


Because doing all steps in a process on paper or with notepad is also executing a process. I don't need a process model for that. So probably it means something like "done by some kind of machine that needs to be told what to do."


But then again; before being able to answer the question, what is the machine, the process should be executed in:


- in a vending machine?


- a multifunction printer?


- in a car manufacturing robot?


- in a workflow tool?


- on a website?


So this drills down to good old BPM questions like:


- what processes are we talking about?


- what are the desired process results?


- What are the desired characteristics of the process (not only machines/tools?


- if needed, what is a good way to support the executing, monitoring, management and improving of those processes by machines/tools


and maybe then; what is the best way to "feed the machine?"


Instead of inventing the next "standard" for executable process models.
Sharing my adventures in Process World via Procesje.nl
Re: "Because doing all steps in a process on paper or with notepad is also executing a process. I don't need a process model for that"

True, YOU don't need a process model but that assumes
1) you will be performing all of the steps yourself.
2) you have a felt pen to mark up on paper or notepad the steps you have done
3) you don't need to record any data at each step.
4) you don't need a history of work done by whom, when, here, at what time, with what data
5) you don't need a way of monitoring the progress of step performance plus ad hoc step insertion toward meeting the Case objective(s),
6) the data you would be otherwise collecting is not needed by other local or remove systems and applications.

I lot of "don't needs"

For most work related to the performance of steps, there are multiple steps, connected in complex ways, with different skill levels needed at different steps, with extensive need for context/situation appropriate data collection, building up of a reverse chronological history of who did what, when, how, and why and a need for data sharing.

This cannot be done by staring at paper process maps.

And, remember that for each Case\template\instance you may have another 20 to manage at any given day.

And, there may be 5 different processes making up these 20 Cases at your InTray. Not unusual at all that as you complete one steps along one Case\template\instance, the person who has the Role for the next-in-line step needs to know a) that you just completed a step and b) what data you recorded.

A good example of this need is in home healthcare where one provider does a home visit and is immediately replaced by another. Progress notes need to be recorded, uploaded, consolidated and available for the incoming provider - time is of the essence.
  1. Amit Kothari
  2. 2 years ago
  3. #2445
You forgot the biggest place a process actually gets done - chat apps. Like email, but much better and far less noisy and a lot easier to manage.
  1. Emiel Kelly
  2. 2 years ago
  3. #2449

You're right and stresses my point of understanding of the process needs (and it's level of automation). And that is of course depending on complexity of cases, amount of cases etc etc.

And you are absolutely right that staring at paper process maps doesn't help anyone.
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation

Process models that are immediately executable seems like a popular request this industry has been asking for. When I think about what that looks like I get a lot of questions about what the requirements would be and what would define success (from a software aspect). Here are a couple questions that come to mind.

[b]Who would the primary audience be?[/b]

(contractors/consultants, citizen developers, "non technical" business pros)

[b]What would the primary purpose of the process model be?[/b]

(primarily human or primarily system processes)

[b]Should the users of the process be able to dynamically define new tasks?[/b]

(primarily human processes building through doing)

[b]How simple would the integrations need to be to other systems?[/b]

(primarily system processes push/pulling data)

Those are a few of the questions I would have for this group. I'm very interested in this topic as I am actively working on solving this issue. I look forward to any insights. Also, how much does our previous conversation about jargon play into this?

Not much effort needed for

"Process models that are immediately executable seems like a popular request this industry has been asking for."

See the next post with a link to 360 degree mapping, template compilation, run time execution of instances of the template.

There are four very short videos that will remove much of the need for questions relating to the advisability/inadvisability of drag and drop process mapping.

Civerex has clinics/hospitals with hundreds of users and thousands of patients using this type of software to run their operations using "best practice" protocols.
  1. Emiel Kelly
  2. 2 years ago
  3. #2486
Assuming he final goal is some kind of BPMS with worklists to show cases at hand, eforms to execute activities, my answers would be

Who would the primary audience be?

- I believe as much change power as possible should be given to the executor of the process. In my dreams that means that everyone in the process can build their own tools. But a carpenter wouldn't build his own powerdrill, but at
least he should be able to make clear what are the needed characteristics.

So in real life I think users should be able (for example in a model) to help defining the process support they need (what problems do we solve (the holes) and what tools do we need for that (drill)). SOme kind of prototyping. When life users should be able to make changes depending on the case at hand (changing the speed of the drill, changing bits)

The should be able to help in the outer circle and be in the lead in the inner circle described in my article here: http://procesje.blogspot.nl/2016/05/customers-dont-care-about-bpm-cycles.html

What would the primary purpose of the process model be?

- both. Depending on the process how many steps can be done by the system, but you should be aware what parts of the process can not/will not be supported by the system so you can decide how that part will be covered

Should the users of the process be able to dynamically define new tasks?

- depending on the process, yes. But this only works if it is a data driven-process where the progress of the process is based on the data gathered. For example if I build a house, I can easily add another door, even it is not in the drawings. And the other way round; if I draw an extra door, the drawing is not forcing me to really add that door. So just adding that extra step must really have an impact in the real process.

How simple would the integrations need to be to other systems?

- in these data-driven processes, data is essential, so I would say; so simple even I can set it up.
In spite of our differing views on what a Case is and whether it is an environment for hosting process templates versus moving through processes, what you write here "BPMS with worklists to show cases at hand, eforms to execute activities" works for me.

I don't get "..everyone in the process can build their own tools".

In principle, I have the notion that everyone should be able to build their own processes, assuming little need for integration but, if all they do is perform their tasks, others can do the integration.

The problem at a practical level is many can't or don't want to "think" process, so facilitators have to come in. Not a problem.

As for tools, you may have seen in my video an embedded diagnostic step and an embedded Treatment Plan step and there was, in the simple example, also a Medications step (not shown in the video). The latter was was a link to a very complex system of prescribing, pharmacy fill, built by others.

All of these "widgets" are way beyond the capabilities of ordinary users "building their own tools" - the diagnostic algorithm took about 1 year to build, with multiple revisions but it became what we figured would be a core component (callable task) in our healthcare "BPMs" so the investment was worth it.

So, yes, all the carpenters need is to describe their needs to a facilitator and, aside from widgets, they can reasonably expect a runable process within hours with no coding OTHER than rule sets construction and interoperability which really need help from a super user or IT.
@Emiel re "Should the users of the process be able to dynamically define new tasks?"

i can't think of any process that is not data driven.

Even if all you need for progress assessment is recording of "done" at each step/task, the "done" checkbox checking is data.

if your run time environment does not get to know that a step has been completed, it cannot advance the processing to the next step.

I suppose, however, you could have a totally automated process that self-generates data i.e. the task starts, waits for 10 seconds and either gets some data or the system plugs in "no data recorded" and moves on. So you could run through an entire process with "data" only collected at one step except that auto-posting of "no data recorded" by user "system" really is data.
@Emiel, Re "How simple would the integrations need to be to other systems?" I say they need to be as simple as possible but having worked with generic data exchangers, sadly, in an environment where publishers can post data using their own data element naming conventions, and where each subscriber insists of reading published data using their own individual data element naming conventions, we quickly get to parsers and formatters which have to be written. Tedious, yes. Requires programming, yes. Can ordinary users do the programming, Not in my opinion.

The other route which is to standardize on data elements and their relative positions for data transport does not work very well because even with need-to-know filtering, a typical transaction (10,000 items in healthcare) has 90 pct blank data which is very awkward.
  1. Emiel Kelly
  2. 2 years ago
  3. #2491
ad 1 I understand facilitators need to come in, but my dream is that everything is kept as close to the execution of the process as possible. But agree that process is not seen as sexy most of the time. So I never use the word and talk about work'job/this is what we do here and try to make everyone a (process)improver

ad 2 Techically "clicking done" is data,but with data driven I mean that the end product is also build up of data (a digital product). So ten times "done" doesn;t sound likemuch valueable data to me.

ad 3 I think you are right that it is more complex than I like ;-)
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation

Flowcharting (draging and droping objects on a graphic canvas or sheet) i.e.nodes, arcs, directional arrows and very little more is the approach of choice for building an executable process model (for modeling) and for generating a run time production process template (for work performance, for monitoring of progress and data sharing).

When you are done (i.e. done building), you press the compile button.

Rick has raised good questions . . .

[b]Who would the primary audience be?[/b]

(contractors/consultants, citizen developers, "non technical" business pros)

[b]What would the primary purpose of the process model be?[/b]

(primarily human OR primarily system processes OR any mix of the two)

[b]Should the users of the process be able to dynamically define new tasks?[/b]

(yes, during modeling by re-mapping, re-compiling and then, at run time, via insertion of ad hoc tasks within a Case Management environment)

[b]How simple would the integrations need to be to other systems?[/b]

(primarily system processes push/pulling data i.e. via a generic data exchanger that allows publishers to post data they are willing to share using their native data element names and allows subscribers to read data on a need-to-know basis using their native data element names. You then need a new data transport format for each subscriber who is unable to use one for the on-file data transport formats.
See it all in action at


The videos (4 of them) are for the healthcare industry but the mapping, minus some special widgets needed to do diagnosis and to build treatment plans for patients are pretty much the same for insurance claim modeling/execution, etc.
Just in case the videos do not link automatically at YouTube, here they are in a playlist


Important you watch them in strict sequence.
  1. Rick Willis
  2. 2 years ago
  3. #2444
I get where you were going with that design. You have a great UI for engineers and BPM professionals.

I'm working on tackling a different problem of making it accessible to regular business users, not consultants. The feedback we have been getting is that it needs to be simple. Simple being a relative term.
Well, there are two UIs, the mapping environment is indeed for engineers and BPM professionals BUT the run time UI is for regular business users.

And this UI cannot get any simpler that one screen where these users can plan, organize and manage all of the work they have to do each day.

All of us, every day, come in and first look at our fixed time appointments and attend to short tasks in between these appointments or try to advance the status of one or more larger tasks.
in between these appointments.
You keep using that word, "IS". I'm not sure it means what you think it means.

This time, though, you added a really fun part: "press the compile button". That clears up my confusion. I had assumed you were talking about an actually executable process model.

Hard to avoid the use of "is'' - the word apparently is in the top 20% of words in terms of usage.

You may be right that "is" means something other than what I think it is.

I looked it up and found this ".. (used with: he, she, it, and with singular nouns) a form of the present tense (indicative mood) of be".

Not particularly helpful.

Seems like it can be a statement of fact or a subjective pronunciation.

It would be interesting to find out what you expect the outcome of "pressing the compile button" should be.

Not sure I understand what "actually executable model" means. .
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation

For the sake of a focused discussion, I'll also assume that this is about machine-executable process models.

While there is no best way to build them, as each of us have their own tools of the trade, I believe that there are a few traits that make them generally better (for customers), in today's world (shall I call them the "laws of modern executable process models"? nah :-) ):

a/ they are following some interchangeable, open, standard so they could lower the vendor lock-in by being able to run on multiple standard-abiding engines;

b/ they must be designed with a microservices mindset (distributed, expandable, largely independent chunks of business logic);

c/ they must be accompanied by a harmonized, canonical, data model;

d/ they must be accompanied by an interface concept that follows the user journeys flowing from a/ and the information design requirements flowing from c/.

From the best of our experience, a great process-driven application architecture for such process models is of type MSVVM.
CEO, Co-founder, Profluo
  1. Amit Kothari
  2. 2 years ago
  3. #2518
Why have you decided this about machine-executable process models?

What is point of building a model when it's not designed for humans/people?

Why can't it be for both humans and machines together?

Ultimately, a human is far more important than a machine-executable process model, unless you want to release the gremlins by assuming a machine can run a business?

And about all the above - how would someone who works in HR, sales or marketing understand all this and without any help - make such a "model"?
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation

From my book, subclause 2.5

... the following essential requirements for the ideal process development tool.

- A BPMN-like modelling notation should use a standard execution semantic which can be validated and which guarantees the adequate interpretation of models by different software for different uses, e.g. for functional testing, performance simulation and execution.

- It should be possible to represent the same business process model with different levels of detail, e.g. a high-level view for a normal user, and a more detailed view for a business analyst.

- There should be a modelling procedure [and patterns] which guide different stakeholders how to use these different levels of detail.

- Details of the execution of business processes should come from a coherent set of standards, similar to that provided by the W3C for HTML: a) xHTML for structure and content, b) CSS for presentation, c) DOM-based API for dynamic modifications, and d) some other specialized standards.

- Different types of artefact [data, rules, events, roles, reports, automation] should be easily accessible from a business process development environment.

- It should be easy to plug additional DSL-like tools for the explicit definition of relationships between artefacts into the business process development environment.

- It should be possible to reduce and eventually eliminate the need for the explicit use of intermediate formats such as BPEL and XPDL.

- It should be possible to offer some techniques for improving the comprehensibility of business processes by all stakeholders.


+ Various coordination techniques are available.


pretty much agree, although a couple of req's do refer to presentation rather than execution.
Thanks Bogdan. I believe that a good and consistent presentation helps to improve understanding and thus execution.
Interesting, but, um... what question are you answering?
@Scott - about machine- or computer-executable business process. Didn't you know?
  1. Amit Kothari
  2. 2 years ago
  3. #2519
And you've tried explaining this to a normal business person - without them telling you to leave the building and close the door on your way out?
Obviously, my explanation of the basic BPM concepts is for BPM specialists not for any person from the street. A specialist must be able to explain those concepts to different stakeholders. The best way is to show how BPM can address their concerns and change their working habits for the better.
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation

First do research on software capabilities that can support people at work where processes create an outcome. Look for a platform that includes all requirements such as UIs, workflow, rules, state, data manipulation etc and of course ability to use legacy systems as required. MDE that supports no/low code is an area to investigate

The end result should be "Adaptive" where inevitable change readily supported and the UIs are dynamically created with the right data to the right person for required instance.

Once you understand just how build works then you can design your process working direct with user knowledge knowing this can be direct inputted into the build environment. This will require a sound data structure and be able to readily input people their roles and authorised activity etc. With such configuration of pre coded tasks and links the executable process is a click away for first cut for more user feed back. This build can be executed in days and so new a journey will begin with business now in control of their processes.
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation

Amen. They are not.

I have always been vocal and clear about this. We eliminated the use of flowcharts on our app, but emulated all the features of a flowchart using "if this then that" statements.

Nobody looks at flowcharts, and nobody cares. They are tired, dead and finished.

Oh and try looking at a flowchart on a phone - does it work?
  1. Rick Willis
  2. 2 years ago
  3. #2446
That last question really drives home the flowchart issue. I dig the "if this then that" style of building rules for sequence flows.

If not a flowchart on a phone, then what?
  1. Amit Kothari
  2. 2 years ago
  3. #2447
Rick - new device, new rules, new UI, new model. What works is something linear (checklist-like) since it spins down nicely on a vertical phone screen. Then, the other tricks make it non-linear e.g. IFTTT statements. Finally, there's no "following a path" like flowcharts, there's just "hide this step" and "show this step" computed in real-time - adaptively - based in previous steps and inputs. That's what we've built so far at Tallyfy, and it's got all the features of flowcharts. A lot more awesomeness is coming soon.

Also - this new UX/UI feels empowering. There's nothing as negative and boring and "you're just a cog in the system" as following a flowchart.
Amit, I dare you to find just one person who ever said that flowcharts should be consumed by average business people on their phones while doing their work...

Why are you continuing to propagate counterarguments no-one ever raised just to drive your point?

Oh, and IFTTT is complete bullshit when it comes to managing meaningful business. Unless the worker is a mindless drone who needs simple, linear, one-step instructions and rules. There are no exceptions to be managed (there is no (E)lse in IFTTT, right?), no real data that flows, no check if two rules overlap or contradict... what in the name of God is a real business going to do with those "rules"?...

IFTTT-style programs are great for consumers. Not too great for business.

I have tried them all, in all their glory: IFTTT, Zapier, Locale, Tasker etc. I ended up uninstalling all of them, except for Tasker. Again, just as a consumer middleware. I do not dare having my business touch that silliness with a 10-foot pole.
Right, eliminate flowcharts / decision trees and you have to say you will not take on any business in construction, in healthcare and probably a number of other industries.

Flowcharts are not "tired, dead and finished"

The statement "Nobody looks at flowcharts" is not entirely correct.

Some people need to look at flowcharts to see who did what, when, how and why (healthcare patient histories i.e. a medical error occurs, why was the best practice not followed needs to be discoverable.

Compilers need to look at flowcharts each time a revision is made to a flowchart - otherwise, they would not be able to compile and roll out templates and users would not be able to plan, monitor and control the execution of work.
  1. Rick Willis
  2. 2 years ago
  3. #2457
It's ok Amit. I still like you.

I dig you are challenging the status quo with your approach. How are we to advance without questioning the "industry standard" approach?
We can avoid a long drawn-out unproductive sub-discussion here.

Read "The art of problem solving" by Russell Ackhoff.

Decisions involve choices and if you can't see the likely outcome of a choice then you cannot make decisions.

No flowgraphs, no way to see likely outcomes, no way to make decisions.

Might as well close up shop and go home.

I can look up the quotes and add them here if anyone wants to read them.
Hmm, IFTTTs vs flowcharts? Sounds like trees vs forests. But, finally, flowchart and IFTTT are only two from many coordination techniques.
  1. Rick Willis
  2. 2 years ago
  3. #2462
I feel like you are unnecessarily coupling the "likely outcome of a decision" with a flowchart. That's the part that I'm personally questioning. I have a quote that seems applicable to this scenario.

"Tradition is the corpse of wisdom." - Zed
Rick... re "coupling the "likely outcome of a decision" with a flowchart" is essential.

I have a construction project with a focus on building a temporary road to a construction site.Site "A" is more appropriate but the road goes through a bog which means you have to do that part of the road during the winter (ice bridge), The "B" site is less desirable and costs a lot more.

As you approach the branching decision box you have to make a risk assessment. Go for A or for B?.

The outcome is a more expensive project versus a less expensive one with significant cost differences.

I maintain the outcomes and the flowchart need to be tightly coupled.

And, if we skip the building of a flowchart, then I would love to hear how top management would be briefed at the time the decision needs to be made using a "checklist".
Hey Amit, I'll support your position more fully in comments below. But it seems to me that the nature of the arguments made here highlight an important point about why purchasers should run, not walk, away from flowchart-driven solutions.
@Scott/Amit... I really don't get . . . .

"nobody looks at flowcharts, and nobody cares"
- does that include designers of flowcharts as well as others?

"why purchasers should run, not walk, away from flowchart-driven solutions"
- how would anyone build a field of houses or start up a cement plant without a flowchart-driven solution? Is business different, other than being characterized by a mix of structured work and unstructured work?
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation

And in the end we don't need executable process models.

We need executable processes!
Sharing my adventures in Process World via Procesje.nl
In the end, YES!
The point about MDE is that the process model becomes the executable process at a click no code generation or compiling...it really works...but will challenge many vendors' current business model
Of course it works.. David does it, I do it, others can or should be able to do it.

Look at my short four videos for proof but please let's not have anyone come back and say "this is impossible" - the recordings were done in real time with no editing.
Challenge vendors' current business model, absolutely.

The buggy whip folks were probably not too happy when automobiles were first introduced.
@Emiel, if you don't like word "model", try to use the word "plan".
  1. Emiel Kelly
  2. 2 years ago
  3. #2464
@Alexander I don't care about words but about the fact that work doesn't get done by a model (or a plan)

And btw, some tool coordination thing, even created from a model with one click; I wouldn't call that an executable process but just one of the thing that helps to execute your processes.
@Emiel RE "but just one of the thing that helps to execute your processes" - not "just" but the essential part, considering that people can be replaced by robots and software.
For most of us a "model" is a representation. (i.e. when was the last time someone took a ride in a model airplane?).

A "plan" is different - typically an integral part of an S.O.W. (Statement of Work) and it DETAILS who is do what, when, how and oftentimes why.

It's fine to build a process model, compile it, then run it for the purpose of shakedown for process improvement.

Next, however, comes the plan, typically at a lower level of detail and that, too, is a map that gets compiled, and rolled out but for an entirely different purpose (i.e. plan, monitor, control).
Oops.. "typically at a lower level of detail " should read "typically at a higher level of detail".
  1. Amit Kothari
  2. 2 years ago
  3. #2520
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation

Uhhh... in the BPMS it's going to execute on? No, seriously, all the big boys' process designers are built straight into the BPMS. Design, then run, your process models there. And, oh yeah, most of 'em are BPMN compliant except for the flying horse crowd.
Sure, and customers can "upgrade" to the big boy's 20 year old technology if they are silly enough.
Which by license seats and revenue both the majority do. Customers like the big boys. They make them feel warm and fuzzy, secure, safe. And twenty year-old technology is not where any of the big three are right now.
as always, technology is not the limiting factor, but the business model. And big boys have indeed a 20-year old business model for addressing the BPM market.
@bnafornita, mmm...on the top three bottom-up I'd say more like 20, 10 and 10 on the 'business model' part, but I don't care about the vendors' addressing, I care about what the client does with their stuff. Clients are usually several years ahead and more innovative on their implementations than the vendor gives them credit for, barring a large SI or Big Four coming in. ;)
Building mapping facilities as part of a BPMs is bad.

- You don't have the same volume of activity building a process as you do running thousands of instances of process templates daily.

If your mapping environment is separate then you can generate output that could be posted to any number of BPMs but vendors want you to use their 'all-singing-all-dancing" packages.

Building an environment that requires BPMN is bad.

- By all means let the consultants use whatever languages/notations they like. In golf, there are no rules that say you cannot user a putter as a driver, wedge, putter. If that is what you want to do, go for it.

Building a BPMs today is bad

- customers need an Adaptive Case Management environment to allow any mix of structured work and unstructured work to be hosted. it's OK to have an ACM environment that you call a BPMs environment.

As for customers and what they buy, again, let them do what they like.

Big Blue of the 1960's all over again, with two choices . . .

1) keep your job until the next merger because no one can say you picked the wrong solution if you go :"Big Blue"


2) do the necessary homework, pick a solution that gives the "best bang for the buck" with a result of increasing competitive advantage.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation

Buy a configurable app that already has the core processes built into it and then use their internal workflow/configuration tools to tweak it.

Salesforce or MSDynamics or Pega for sales, Salesforce, ServiceMax for service, Salesforce, Hubspot or Marketo for marketing. Workday, FinancialForce, Sage or Fairsail for HR.... and so on and so on.

RE “Buy a configuratble app that already has the core processes built into it” - this is a trap for customers – to have a bridle one have to buy a horse as well.
  1. John Morris
  2. 2 years ago
  3. #2470
Answer to Ian's question: One has to have an enterprise app which is the focus for any given point solution. AKA "ERP" I guess. ServiceMax is never going to stand alone etc.
I think you have just summed up the mess of legacy with hard coded applications from whole mix of suppliers. Fact is next generation operational software that focuses where information is created will be driven by the single platform capability at fraction of price...and one consequence will be the end of the SaaS lock in model...?
Configurable apps are a great way for vendors to get customers on a slippery slope.

The "enterprise app" is important - it needs to host background BPM templates to provide orchestration, global rules to provide governance, accommodate ad hoc insertions, carry out RALB (auto resource allocation, leveling and balancing across multiple customers\templates\instances), auto-build a history, accommodate real time, semi-real time and batch inflows and outflows.

We call the environment "Case"
  1. Emiel Kelly
  2. 2 years ago
  3. #2483
Why even bother configuring for processes that don't have any competitive advantage like financial, hrm etc? What can be unique about that?

Just use throw away processes that run from (in) the cloud for $1.75 per finished case. ($ 1.60 if you buy a voucher of 50 cases).

Spend the saved time and money on things that really matter; your customers.

Re: "Spend the saved time and money on things that really matter; your customers"

The thing is you can, in your process management environment, do as much Customer Experience Management as you like, WITHOUT the need for a separate CEM software system

See CEM and BPM - in the sandbox

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

Alexander - I am sorry, but I don't understand your comment
I am sorry Ian, I over-estimated my ability to manage my non-mother-tongue language. I wanted to that buying a small executable process will require a huge platform. It is normal, considering that BPM is the vendor-driven market. I believe, that BPM customer will prefer to buy only executable processes and use a BPM platform of their choice.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation

Lots of good answers, especially including "buy it" (@Ian). But let's look at the narrow technical meaning of the question:


[b]"What's a good [quote][u]capture-business-analysis technology[/u]
enabling business and IT dialogue around the desired process model?" to start with, and then . . . [/b][/quote]

2. "
[b]What's a good [quote][u]model-to-executable technology[/u]
 enabling process artefact construction?" to complete the job.[/b][/quote]


Such narrow definitions of the question exclude larger questions such as "
[i]What's the best way archtecturally, organizationally and economically of acquiring the business processs artefacts I need to succeed in business?"[/i]


[i]An answer to the narrow definition of the question is [quote][u]find the engineered product that minimizes the gap between "thinking", "drawing" and "using"[/u]
. The acronym "what you draw is what you execute" (WYDIWYE) captures this idea.[/i][/quote]

In other words, what BPM product
[u]minimizes the roundtrip problem[/u]
? This is the single biggest challenge for BPM adoption. The
[u]model to executable process artefact gap[/u]
is all too often very wide, even if the costs are frequently hidden. Note that once you have acquired the BPM technology or product you need, you will still have challenges around roundtripping -- if you mix up back-end integration with business logic, you'll probably lose much of the benefit of such technology (Volker Stiehl's recipe is relevant here).

We can assume that other important BPM technology capabilities are all in place (business rules support especially).
Agree with ". . . model to executable process artefact gap is all too often very wide"

The gap is easily narrowed by cloning the model then expanding the steps as needed until you ge to a level of detail where you can detect handoffs

"Model map to execution", "process map to execution" protocol should be the same.

One click !

Any more than this and the gap is being unnecessarily maintained.
RE "then expanding the steps as needed until you ge to a level of detail where you can detect handoffs" - sound similar to programming in FORTH.
RE "Model map to execution" - a bit more complicated because it is necessary to program (sometimes graphically) in several, often, unique, DSLs and in a very iterative way. But, fortunately, this is a way to convert a complex problem into a complicated one (in the Cynefin framework terminology).
  1. John Morris
  2. 2 years ago
  3. #2480
Nice reference Alexander to the Cynefin framework; interesting and useful (and for me, novel).
The reason to expand down to where you can take note of handoffs is that it is difficult to assess progress when a step has too wide a scope or too many contributors.

The other reason is when one phase of any piece of work is "complete" and the flow needs to go to say a different department, a different machine, a difference software module,a different location, there can be idle time.

When you are doing audits, it's not unusual to find that the sum of wait times between tasks can rival or exceed the sum of task performance time.
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation

We in UK have pioneered this build in a model and click to execute. The first early adopters were in the late 90s and we were warned that what we had was going to be a big challenge as it would change a very big market dominated by large companies! We know others had tried but given up so what was our core difference? We have always been business driven and when we looked at what support people needed at work we identified relatively few “task” types and then “coded” to be generic ready to configure and stored as data inside a relational data base.


Once this had been done it was decided to make it easier if could be displayed in a model and when configuration complete at a click using a declarative technique the application would automatically be set up ready to run. Easy well yes but big learning curve but we realised we were cracked a huge problem and refused to give up! Frankly “IT” did not get it (or want to …?) and all early adopters were business driven. The "big" analysts over the years saw it but we were on our own and  basically ignored….although one younger analyst did call it the “holy grail” but he did not last long! That has been our real challenge -- too many vested interests and well known as the “innovators dilemma”.


With passage of decades what have we proven in terms of capability and cost? Interestingly by focusing on what users needed we ended up with a complete platform to build all requirements which “IT” articulated as but to us was simple business logic!
Process engine - to ensure all works to plan.
Rules engine - reflecting real world of compliance.
Calculation engine - automating system work.
State engine - Real time feed back from any point.
Workflow - everything connected in right order.
Audit trail, events, escalations - = control with empowerment.
Rapid prototyping - user involvement in build no need for a final spec
Time recording - supports activity based costing.
Real time reporting - becomes predictive.
Build mash ups - one screen multiple data sources.
Linked intelligent Ajax grids - enter data only once.
Roles and performers - people and machines recognised.
Management hierarchy - see who does what and when to reallocate work
MDM Orchestrating legacy with business processes as required in single environment a - 21st century approach to recognise the past
Call Web Services - wrapped up in a process.
User interface dynamically created linking people, roles, task type and data via forms for specific instances.- supports adaptive capability
Content handler and in memory work capability - to ensure high performance.
Pre-built templates for custom documents, letters, e-mails, messages etc dynamically populated with instance specific data and edit capability in browser - recognition of external communications documents etc
Process and task versioning control – ensures minimal disruption, if any, to implementation of changes

One early adopter has now been using as a case management application distributing grants with means testing and scheduling payments as required. To give an idea of what the build profile looks like. Over 15 years total cost of build and supporting constant change £2m It has 75 process maps (226 over life cycle)‏, 2406 associated tasks (5087 over life cycle)‏, 538 user interfaces (forms)‏ (1114 over life cycle) no code generation or compiling yet does it all. Just recently converted to web from client server some 300 UIs converted total cost less than £50,000.


That’s what “disruptive” means and what the potential is with this Model Driven Engineering approach. We know there is more to come and it will change the market in favour of the customer….just as hardware has experienced so software will effectively be commoditised. It is the BPM discipline that gives structure to design with build now readily supporting user ideas without technical barriers.


We were so early regrettably we had to hold back until the market was ready. Such a discussion has been long over due and it is clear the market is ready as “digital” brings that people focus. Like many disruptive technologies it has been held back by powerful vested interests but we now prepare to globalise and share the knowledge and the code to make the world a better place supporting people at work.

We went about the same route, starting about the same time and I am not surprised at all at your £2m, our running total is $US 5mm (very close), but probably not as painful as here in Canada you get back R&D credits of 40% of your labor, which is most of the costing.

Curiously, we we ship with no process maps, no tasks, no user forms ( each customer makes their own), We have no code generation but we a key component between the map and the ability to do auto-resource allocation, leveling and balancing is our compiler.

So, about the same investment, totally different approach but, I suspect, the same result, i.e. delighted customers. Two have been with us since the year 2000. Where customers got bought out (mergers) they often disappeared off our grid, the parent paying no attention whatsoever at what had been done/accomplished.

Its good to get these numbers out there if only to illustrate the futility of startups thinking they can replicated 1.5 million lines of code in 2 weeks on the back of an envelope.
  1. Emiel Kelly
  2. 2 years ago
  3. #2492

We also had that at Pallas Athena in the '90s .

We were able to turn models used for discussing and analyzing the process into a dynamic case management system by dragging and dropping data, users, forms etc.

Based on Petri-nets. The word BPMN wasn't invented yet ;-)
  1. John Morris
  2. 2 years ago
  3. #2494
Fascinating ...

... and moving too. (Am I allowed to say that in business?)

A great example of timing and the Innovator's Dilemma.

And a motivation for good too . . . as ELO says, "Hold on tight . . . "

: )
Clearly for my approach to work (i.e. no processes, no forms, etc) it has to be that building them is not perceived as any big deal, otherwise no one would buy my solution and everyone would go to David or others.

Our audiences may be different - my customers each have their own "best practices". They are actually very protective of these and view them as giving their organization a competitive advantage - they would never want us to re-distribute these to their competitors.

No two customer installations are the same.

Our environment is more like MS Word, Microsoft doesn't ship sample letters that you can customize, you compose your letters starting with a blank canvas, same as with our offerings.

There is of course software on the market for incorporating companies etc, that has pre-set templates.
As Mr Spock would say, looking at these totally opposite approaches, "fascinating".
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Accepted Answer Pending Moderation

Set aside one lousy day for meetings and look what happens. Yikes!


On the upside: I am quite sure that nobody is going to ever see my comment way down here in the "Oldest Comment First" basement. That gives me a lot of freedom to say, gee, pretty much anything, does it not?


First, let's establish some common ground. We appear to agree that what I am proposing is different than what most vendors offer today. Great! So we can probably also agree that, given sufficient information, customers will select the product that (they think) best suits their needs.


I'm pretty comfortable with that.


Now onto areas not characterized by such pleasant consensus. The enlightening part of this discussion, for me, was the lack of rumination on the actual subject of the quote: flowcharts. Instead, many remarks seemed (to me) to conflate flowcharts with models, treating them as largely synonymous when in fact the former is simply one implementation of the latter. For example, I'll pick on Karl for a moment. In response to Amit, he said, "Compilers need to look at flowcharts each time a revision is made."


Here's how that exchange sounded to me:


Amit: "Cars that run on petrochemicals are old news."

Karl: "Internal combustion engines need petrochemicals to pump into the cylinders, or they'll stop moving."


Yes, that's correct. It's also a non sequitur. The internal combustion engine will always demand hydrocarbons, but nobody is arguing otherwise. Rather, they're suggesting that there are far better alternatives to that specific mechanism for converting from potential to kinetic energy.


Which is not to say the legacy technology has nothing going for it. But if the only type of engine you can conjure is of the gas-guzzling, smog-spewing variety, then perhaps a little additional imagination is called for. On the other hand, if you're well aware that there are other types of engine available, but you have solid arguments for why the venerable internal combustion workhorse was, is, and always will be better than any imaginable alternative: great! Let's hear 'em.


But I don't think I did—hear any, that is. That being the case, perhaps the question for BPM buyers today is: what kind of car do you want to be driving when the last gas station closes?
  1. John Morris
  2. 2 years ago
  3. #2526
Scott, since your comment the basement has been dug even further, much further!

As for defining terminology, my early reply was an attempt to address your question in a structured and limited way.

Without refering specifically to BPM or workflow in the question, I asked what is a good "business analysis capture technology" and then what is a "good translation technology" to turn that information into useable automation artefacts.

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

@Scott. . .I'm sure the commentators are not done with this topic.

I found the opening statement "Flowcharts (including IMHO BPMN) are simply not a great way to build an executable process model." to be intriguing,

I took an opposite view and spent a lot of time reading / responding.

If flowcharts (maybe we should be calling them flowgraphs) are NOT a great way to build an executable process model, I am hoping to learn why and if it turns out there is a better way, some of the folks at this forum may very well stop building flowcharts.

Seems to me a flowchart is quite different from a model.

A flowchart lets you see how nodes are connected via directional arrows, when you add to your flowchart roles, data collection forms, and rules you get to a model and if you convert the graphic map to an "executable model" via a "compiler" (not the right word?, pick a different one) you can test your model.

I am happy to have you pick on me
  1. more than a month ago
  2. BPM Discussions
  3. # 15
Accepted Answer Pending Moderation


I totally agree with the "let's disrupt everything" discourse - so many things deserve, and are ripe for, disruption. However, just because we are able to juggle the buzzwords
[i]du jour[/i]
in some forum, it doesn't mean we actually understand what needs to be done to disrupt said things.

Specific example: "flowcharts are crap because no one reads flowcharts on a phone". To keep the analogy, it's like saying: "cars that run on petrochemicals are old news, because no one makes omelette with them anymore". I don't know who conviced the quoted gentleman that flowcharts must be contemplated all day long in order for work to be done, but for sure this made him a great disservice.

Another specific example: "3 billion people are using chat apps so this must be the future of business process management". To keep again the analogy, it's like saying: "7 billion people use their legs to move around, so this must be the future of transportation".

And how are chat apps the amazing new, disruptive business tech? They've been around for more than the BPMN standard, and for sure the DMN standard is younger that pretty much most of them. So, what on earth is "legacy" anyway? I'm not positioning flowcharts as next level of innovation, since the standards are just frameworks, they just facilitate process innovation.

So what has fundamentally changed in the chat app landscape that makes them disruptive now? The audience is now 3 billion, indeed. There's more money flowing in from the 4 horsemen. But the use case is absolutely the same as 10 years ago: unstructured communication. AI will help structure it a bit, but it must be in perfect English and no one knows exactly who's there to account for mistakes. Will you be able to cancel a multi-million dollar order just because the sales bot chat app "misunderstood" the decimal placement?

And ultimately, if I haven't provided enough examples, I think your analogy is misleading. The challenge you are bringing to the table is about the best way of innovating the "how" (business processes), not innovating the "what" (products and services, like "electric vs ICE").

So in your analogy, your position on workflows should be about the best way to build cars, not about the type of cars that needs to be built. To which end disruption pundits would fill in the gaps: "robots are not a particularly suited process to build cars, we should use a new revolutionary technology, like chat apps".
CEO, Co-founder, Profluo
  1. Amit Kothari
  2. 2 years ago
  3. #2516

You state "what needs to be done to disrupt said things." We are already doing it - to the disbelief of most people.

You disagree that "flowcharts must be contemplated all day long in order for work to be done". So why make them in the first place? To waste time and feel clever?

"chat apps the amazing new, disruptive business tech? They've been around for more than the BPMN standard, and for sure the DMN standard is younger that pretty much most of them"

Wait a second. I can't believe I just heard that something that 3 billion use every day (which they did not just 3 years ago) - is being compared to some acronyms that no business person understands or cares about. How did you link chat to BLAHMN? So your argument is what? The AGE of the "standard" has anything to do with anything?

Your points make absolutely no sense - whatsoever. What has an omelette got to do a with a car?

""how" (business processes), not innovating the "what" (products and services, like "electric vs ICE")"

So how do your flowcharts innovate the "what" - exactly? Are you saying rigorous rule-based flowcharts are how people build innovative new products?

" your position on workflows should be about the best way to build cars, not about the type of cars that needs to be built."

Why not? What if what have is agile enough so that it can (and has) done both?

What makes you think the "use case" for chat is just "unstructured communication"? We've already made it structured. Right now. It's real, and it's here.

What makes you think business people are going to ask YOU what the "use case" for chat is? They don't need your approval before using a chat app to get work done. People are finding their own use cases, by themselves.

""robots are not a particularly suited process to build cars, we should use a new revolutionary technology, like chat apps""

When did I say this was about manufacturing? We're only focusing on white-collar jobs, where process management and BPM is a total failure.

"Will you be able to cancel a multi-million dollar order just because the sales bot chat app "misunderstood" the decimal placement?" - What makes you think chatbots don't already have validation and cleansing for data inputs that's far BETTER than UI's? We've actually nailed this. And also - why wouldn't you make the same mistake in a UI? Why does it matter whether you filled the same erroneous data in a UI or in a bot?

I have seen no valid counter-point to my views. I have only seen more evidence that the flowchart camp that attempts to link an "executable" process to BPMN/whateverMN is scrambling to justify itself in a world that's already changed.


flowcharts are just maps of the software logic - they are not meant to be consumed as such by end users. Just as IDEs are environments for building software, so are flowcharts - models that are executable within a process engine. I am sure you don't sell your software by displaying your IDE to your customers. Neither do we by showing flowcharts.

However, most of our customers are totally interested in understanding how they can monitor their processes. And then we show them the flowcharts at runtime, populated with their transaction tokens, with their process metrics and the heatmaps. They relate instantly to that - it's always a collective "ooh". Customers want to understand immediately how their enterprise software works in a collaborative environment. That's exactly what flowcharts are supposed to do. And we don't do training for them: after all it's just basic 4 symbols (a rectangle, a diamond, a circle and an arrow). Everybody gets them instantly. And we don't need to explain to them that the 4 symbols are actually BPMN, or that the simple table over there is actually a DMN executable logic. It's irrelevant to them what the actual name is. They just get it how it works.

My point about bringing a product into a discussion about process was exactly that: it's absurd. Flowcharts don't innovate the "what" (i.e. they do not interpret the data that is flowing through them). They innovate the "how". At Apple, the "what" is innovated by creative iterations of the Industrial Design team (and there's a process there as well). It is what makes them spectacular. However, the insane profits that they are commanding over the rest of their competitors are due to an uncanny ability to innovate the "how": the production and logistics processes. They are embedded into their go-to market strategy. And they are incredibly rigorous. This indicates that they have a very clear, shared map of how they are doing things. A flowchart is just a way of having that map.

So it's pointless to hammer a process technology for not innovating the product. It's not been designed for that. Hence my omelette with ICE quote.

While your app may save the business process world, it would be pointless to hammer it just because it's a checklist (which is actually the way most BPMS's propose work to the end users anyway, maybe for the past 15 years).

You should really not dismiss this space just because it looks boring and stale to you. I actually see around me companies that are growing like crazy exactly because of workflow technology. But again, technology is one key aspect of a great product. A great business model is far more important though.

As for validation of mistakes, of course they can happen in a classic UI as well, but this is usually orchestrated to more humans (there are supervisors, managers that are supposed to chip in with their responsibility as well). In the case of AI, supervision by humans would be a moot point. And hence responsibility would be hard to pin.

As for white-collar jobs where flowcharts are not suited... *Linear* flowcharts are not suited. But you can design highly complex, non-linear, ad-hoc flowcharts, triggered by events and data, to model knowledge/case work as well. We did it, and so did hundreds of similar companies before us.

And I'm not scrambling to prove anything - my company is far younger than yours and I already have a problem to fulfill what I already have to deliver to my customers. Sales is not my problem. Finding talented developers is. So flowcharts are actually the way to mitigate this challenge - my build productivity is incredible - I can turn rather complex custom apps from idea to full cloud deployment in days, maybe a couple of weeks if the deployment is on premise and requires legacy integration.
  1. more than a month ago
  2. BPM Discussions
  3. # 16
Accepted Answer Pending Moderation

In addition to Scott's comment above - I would throw one more spanner into this that very few have addressed, instead choosing the nonsense that "oh everything is great".


What if CUSTOMERS (not self-appointed BPM vendor-gurus) decide that they actually want something to work easier, better, faster, cheaper, mobile, and conversationally? Both the modelling and the doing.


OMG - what will we do then? Tell customers that they're stupid?


Say that they should go back to trying to get work done by "modelling" a flowchart and then never actually looking at it again - ever?


It's encouraging that David Chassels above has been customer-driven from day 1.


Now if 3 billion people now use chat for hours DAILY (even replacing email in some cases) and mostly on phones - which was not the case just a few years ago - the rules and the entire game of how they get work done has also changed. The smart money has already put tens of billions of dollars behind this. Are old-school BPM vendors saying that they disagree with Apple, Microsoft, Google, Amazon and Facebook? How can process modelling be unaffected if the way/the place I actually do work has changed?


The actual verbage of micro-actions like approvals has also changed. A single touch enables you to "like" or "approve" something. A single swipe in the right direction is all it takes to conduct several atomic actions. The process is irrelevant. The tasks I have to do WITHIN the process are all I care about. That's now a gentle notification in a hugely scalable outside brain that remembers everything for me, removing all my stress of attempting to stay on top of the process tasks I owe other people, or what other people owe me.


There's already so many ways to make unstructured chat work as a structured process. And it's transformative - we can now actually track people doing individual actions in any structured process in real-time, within chat - which was NEVER possible with a flowchart. Process improvement only works when you collect execution data.


Did anyone notice the topic of this entire thread used the word "executable"? Yea, so how does a human "execute" a flowchart today? Why is the object that's meant to help you (a flowchart) - so utterly inaccessible and useless? And how am I supposed to track who is doing what, by when, how and know where they've reached?


Previously, you did work with a pencil and paper. The actual pencil has changed. It doesn't work on the same paper anymore. And now the paper has changed too.


OR if you're an old-school BPM vendor, just put your head in the sand like an ostrich and pretend nothing happened. Keep doing your "let's model for 8 weeks" approach. Keep selling to IT - who are soon going to be just paper pushers that try to keep up with cloud contracts for things that business users have decided they want with/without their approval.


Business users can and will dictate what wins. Nobody else. Customers are not going to accept BPM nonsense anymore.


I'm not going to try and agree with tired, old BPM vendors - since it's so obvious to me that it hurts. And I'll become even more passionate as I am actually proving this thesis to be more and more correct as days go on.


I am finding that neutral people (like consultants) are open and listening to these valid points. They have less vested interests, and can become much more responsive to their clients - who love hearing about things that are simple, easy and 100x better. I'm hearing from an exponentially increasing number of consultants every day, and we are rewarding them better (financially) than anyone else.


As Scott said - if you can't present any alternatives - step aside, or group with your buddies into a little corner that's crumbling. Nobody cares about BPMN and DMN and USELESSBORINGMN. It's not the way business users want to model anything, and it doesn't help customers get their work done.
  1. more than a month ago
  2. BPM Discussions
  3. # 17
Accepted Answer Pending Moderation

Hi, Amit . . .

Interesting questions, worthy of taking time to put together a response.

[i]"how does a human "execute" a flowchart today? Why is the object that's meant to help you (a flowchart) - so utterly inaccessible and useless? And how am I supposed to track who is doing what, by when, how and know where they've reached?"[/i]

One by one . .


[b]"how does a human "execute" a flowchart today? [/b]

- They don't, they never did.

- They execute (perform) tasks that post to a run-time environment from background templates derived from plan side flowcharts


[b]Why is the object that's meant to help you (a flowchart) - so utterly inaccessible and useless? [/b]

- assuming one believes they are meant to help and are capable of providing help (the amount of help needed depends on what you are doing, plus other things), they are as accessible as you want them to be and useful depending on needs/wants/desires..

- from within a Case Management run time environment, one click will let you view the template map

not inaccessible, not useless (to some people) . . . we know from psychology that some people are "visual" others are not.

No need to put all of the visual folks into a "basket of deplorables"


[b]And how am I supposed to track who is doing what, by when, how and know where they've reached?"[/b]

- get software to mark up your run time map (the template for the Case that has the focus, not the plan side model map), about the same way you might mark up a paper run time map using a felt pen marker. As you hover the mouse over a step you will see what, when, how, and where.

No harm at all seeing the same status / progress info in the form of line items in a list, so flowcharts are simply an option.

So far as I know flowcharts are not evil, they don't cause you to gain weight, and the ones I have been working on today have not bitten me once all day..

I think what riles participants up is the use of extreme adjectives such as "inaccessible", "useless", "not a great way" . . .

  1. Amit Kothari
  2. 2 years ago
  3. #2507
Karl - did you just state that the link between doing work and modelling work is broken?

Isn't that why all of this is unsolved?

Why should modelling be so hard? Why can't modelling either become close to or equal to - "doing"?

What if I don't want to "get software" and spend weeks learning it - for all the above? What if I just want to do it in the app where I already spend 3 - 4 hours a day both at my desk (a laptop) and on the go (a phone)?

How exactly is a flowchart "accessible when you need it"? If I need it on a phone - what do I do? Do I need a new pair of glasses to see an A3-sized flowchart on a tablet/phone?

Why exactly is a flowchart not useless if you just stated that people attempt to "post from templates derived from flowcharts". What makes you presume that people even do this today?

If I am not using software for the "run time map" (whatever that means) - how does anyone know what I am doing, and how can I track anything?

What if I don't have a mouse? Phones have touch screens with very limited real-estate.

This appears to bring up a hundred more questions than answers.
Sure, each answer brings up more questions until a topic has been properly discussed and understood.

Terminology is one just one reason.

I did not say the link between modelling work and doing work is broken.

A model to me is just an interim phase to get to a best practice template.

The reason companies build physical models of, say, equipment, is because they let designers gain insight that avoid problems getting into production equipment.

Business processes are the same.

Go for the full detail and risk having to scrap the initiative because management does not approve the initiative or build a model, get approval and then only build the production version (best practice template).

Don't want software? - do it by hand. You get to leave the office at 2200 hrs whilst others using software can leave at 1600 hrs and play a few rounds of golf.

If you do want/get software, pick a solution that takes hours to learn as opposed to weeks.

By all means, with software, do it at the laptop and at the phone. Or, at a phablet, You can size/re-size at a phone using your fingers, you can scroll.

Autosizing at portal apps is relatively common.

Re: "people attempt to "post from templates derived from flowcharts"" - they don't, it's the case management environment that does this automatically, seamlessly, in the background.

Say we have three tasks 1-2-3 to perform

My role is to perform #1, you #2 and Scott #3.

I come into the office and see #1. I perform it. I am done.

You now see #2, if you want to know what I did, you go to the Case History where you see data, as it was, at the time it was collected. You perform step #2, You are done.

Scott now sees #3.

I did not post it to Scott's InTray, you did not post it, the system posted it by referring to the template that a compiler carved up into discrete steps by scanning/interpreting the plan side process map that someone built. Soon as one task is complete the software posts the next-in-line task(s).

Everyone knows what everyone has done and is doing.

You can track everything as well as anticipate who next is going to do what.

No mouse? No worries? your finger works, next-next-next works, voice to command may work, some phablets have pens, fighter aircraft pilots can target in the direction they are looking.
  1. more than a month ago
  2. BPM Discussions
  3. # 18
Accepted Answer Pending Moderation

Reading over the material at this discussion, I think we need a few more rounds before the traditional stampede over to a new question takes place.

Scott riled up a bunch of us by stating "Flowcharts (including IMHO BPMN) are simply not a great way to build an executable process model."

At the 1st post, Emiel threw one spanner in the works, asking what "executing" means.

Here we are at response #19.

My experience is we can execute a model or we can execute a "best practice" template.

The former is a best practice under construction (albeit at a higher level of summary) whereas the latter is, (graphically, for those who relate to flowgraphs), the "best practice".

We cannot "execute" graphs but we can compile them/interpret them/ scan them/ transform them by carving them up into discrete run-time steps that have various attributes such as the performance skill level needed, data collection forms needed to record data and some mechanism for attesting to the completion or commitment of individual steps.

Scott says the "really fun part" happns when we "press the compile button". I agree - a lot of behind the scenes things take place when you do this.

The objective is to be in a position, within some run-time environment, where software, machines and/or people can post steps to user InTrays for their attention/action.

Clearly, as one step is completed, we need the environment to provide orchestration by posting the next-in-line steps to the appropriate classes of users.

These users really need orchestration - in healthcare, a nurse can easily need to provide services to 20-50 patients per day, each of these patients will typically be at a different step along a private care pathway (read best practice template) and many patients will be on different pathways at different steps.

The nurses indeed are not robots, it's totally unrealistic to think that all possible interventions for any patient could be "guided" by a best practice template.

What this means is the nurse needs to be able to insert an ad hoc step at any point.

They also need the ability to skip steps in the best practice, re-visit an already completed step, and record data at a not-yet-current step (i.e. the data has become available) - no point writing the data down on a piece of paper, then waiting for the step to become current and, only then, recording the data in the patient Electronic Health Record.

Lastly, the nurses need to be able to micro-schedule their work, supervisors need to be able to set priorities, supervisors need to level and balance workload across, in this example, nurses.

Can one do all of this on a cellphone? In principle, yes.

Can the run-time system work without orchestration, no. This would mean the organization would have no way to manage its best practices.

Is a flowgraph yes/no "a great way" to build an executable process model? You tell me.

How long does it take to build a flowgraph that captures the steps/directional arrows etc.?

How long does it take to build a best practice some other way? What does the result look like?

If you don't like to build flowgraphs, even if another way takes five times longer, do it, providing a) you have the time b) the customer is prepared to pay for the end result.

The main lookup I made in participating at this discussion was the advice given by Dr Russell Ackoff. (The Art of Problem Solving, 1978)

The advice was along these lines "Decisions involve choices and if you can't see the likely outcome of a choice then you cannot make decisions"

My comment . . . .no flowgraphs, no way to see likely outcomes, no way to make decisions.

Execept that maybe there IS (+1, Scott) an alternative to flowgraphs, but we need to see/hear what that is.

Linear task lists clearly are the way to go at run-time. Amit uses them, my group uses them.

A live/batch chat capability is a no-brainer (improves the customer experience or journey).

Once you admit that chats are "a good thing" you are admitting to ad hoc steps and your feet are firmly planted in "Adaptive Case Management" (a run-time environment with governance, with background BPM, with embedded CEM, with RALB or auto resource allocation, leveling and balancing, plus lots of other capabilities) that lets you "manage work".

I have found a few folks who hold the view that "process management" means building, testing, updating paper process maps. OK, that works for a silo whose output is a paper process map.

For others, the end is a new beginning and the next thing to do is roll out the best practice in a run-time format so as to manage, not the process, but the Case that is hosting various (typically) process fragments and ad hoc insertions.

And the purpose of "managing" a Case is to support or contribute to corporate strategy/initiaties.

And the purpose of formulating strategies/initiatives is to build, maintain and enhance competive advantage.

All of this in support of Peter Drucker's various statements along the lines of "the purpose of a business is to stay in business".

A small problem is that for some, the purpose has changed to "let's buy this company, fire management, put some lipstick on the pig, flip the company and make a lot of quick money".
@Peter - I'm hoping we will get a less engaging topic this week - I need to get some work done.
  1. Amit Kothari
  2. 2 years ago
  3. #2514
Karl - we don't use linear steps. We can do everything a flowchart does, in a checklist-like UI.

Would love to get your feedback if you use it!
@Amit... Precisely . . . "We can do everything a flowchart does, in a checklist-like UI." - this is the way things should go.

People within businesses and people at home relate to "to-do" lists.

In my 2014 video, things are a bit confusing in that the do-list displays the current step plus all forward steps in a tree (we quickly blocked that because users could not run away fast enough).

All users want is to see what they have to do for now/today.

So yes, to a checklist-like UI, but in many business sectors, there is data collection to be done so no sufficient to just say "I am done".

However we don't encumber users with data collection forms unless/until they click on a line item.

I did say that at times, users need to look back at the chronology of events to see which sub-paths in a protocol were/were not followed but otherwise the ordinary users would rarely need/want to see any underlying flowgraph.

I also said that the "compiler" needs to "look at" a flowgraph easy time the flowgraph is changed for the simple reason that it has to roll out a new template.

We are all in the game to improve efficiency and effectiveness - there are may possible approaches, methodologies, practices etc.

So long as the desired outcome is reached, there is no such thing as a "best" way.

Different consultants/customers like things done in different ways.
  1. John Morris
  2. 2 years ago
  3. #2530
LOL @Walter's plea . . .
  1. more than a month ago
  2. BPM Discussions
  3. # 19
Accepted Answer Pending Moderation

Frankly, I am shocked about the intensity of this discussion. Thus the basics must be aligned first.

In this discussion we are talking about *
* or *computer-executable* or *computer-assisted* execution of business processes. It means that some parts of business process execution are delegated to software.

@Amit RE “Yea, so how does a human "execute" a flowchart today?” Yes, I saw organisations which coordinated work of their employees by a technique called “route-sheet” (which is a linear flowchart). Also, you may remember images of many lady-typists for whom other ladies assigned next tasks (see “Save the private Ryan”). And, I am sure, you participated in some projects in which Microsoft Project was used to express flowcharts.

Now about the “
[b]business process[/b]
” concept. There are two viewpoints on business processes.

1. “Observer” viewpoint - Business process is a collection of related, structured activities (or tasks) that produce a specific service or product (serve a particular goal) for a particular customer or customers. [ see https://en.wikipedia.org/wiki/Business_process ]

This viewpoint is typical for an external observer for whom the design of future work is not fully known.

2 “Meta (or creator)” viewpoint - Business process is an explicitly defined coordination for guiding the purposeful enactment of business activity flows.

In other words, a business process is an agreed plan which may include some variants and may be adapted during its execution.

This viewpoint emphasis an intentional, systematic and shared design of future work which is the primary concern of any business process owner.

See also [url=http://improving-bpm-systems.blogspot.ch/2014/01/definition-of-bpm-and-related-terms.html]http://improving-bpm-systems.blogspot.ch/2014/01/definition-of-bpm-and-related-terms.html[/url]

Then, the “
” concept which is “The organization of the different elements of a complex body or activity so as to enable them to work together effectively” in accordance with the Oxford dictionary. In some sense, it is a hidden activity within business processes – in addition to execution of typical human or automated activities, someone or something must take care about coordination of human and automated activities. Usually and unfortunately, people who follow the viewpoint “Observer” do not recognise it. Actually, coordination is the most important part of business processes. Just imagine an uncoordinated football (soccer) team play or uncoordinated chess mates. Disaster!

Coordination explains WHY a particular business process is like that you see it (e.g. as a flowchart)!

Obviously, there are many ways to coordinate activities – I call them “coordination techniques” (see [url=http://improving-bpm-systems.blogspot.ch/2014/03/coordination-techniques-in-bpm.html]http://improving-bpm-systems.blogspot.ch/2014/03/coordination-techniques-in-bpm.html[/url] ). Flowcharts, IFTTT, check-lists, AI-based logic, etc. are example of coordination techniques.

So, coordination, as the essential activity for achieving a goal of a business process, may be delegated to some software (instead of several people who may interpret or execute processes differently).

Of course, it is necessary to use some formal languages to tell to a computer how to execute some activities (including coordination). Such languages are, fortunately and primarily,
which are easy to understand by the business. If those DSLs are not sufficient, it is necessary to use general-purpose programming languages, e.g. Java, Python, C#, etc. Ideally, their use must be minimized, to have “low-code” development.



"Coordination is the most important part of business processes"


and the chief coordinator at Cases is the Case Manager.

He/she (in consultation with others) decides when to close a Case.
  1. Amit Kothari
  2. 2 years ago
  3. #2515
"Lady typists". Really? 1965 called. Their lady typists want their flowcharts back.

Try explaining all this to a layman who wants to get work done - in 30 seconds.

You are also assuming that normal people understanding what a "DSL" is - or care about this.

Do you see the problem?

Have you tried saying the above to a successful business owner who is 25 years old and wants consistent processes?
RE "You are also assuming that normal people understanding what a "DSL" is - or care about this." I am not assuming - people, who were responsible for a single activity, asked me to make processes fully visible and understandable for them because people would like to see themselves as contributors into organisational results. Those people wanted to talk to people who work on activities before and after their activity.

RE "Try explaining all this to a layman who wants to get work done - in 30 seconds." - Fortunately, it is not necessary to explain "all this" upfront. Only a few basic concepts. (Of course, "DSL" is for geeks).

RE "Have you tried saying the above to a successful business owner who is 25 years old and wants consistent processes?" Usually, business people understand the need for coordination very well and they know that coordination must be explicit and ideally, objectively, applied. Watching football (soccer), playing chess or serving in army help a lot.

Obviously, my explanation of the basic BPM concepts is for business process specialists not for any person from the street. A specialist must be able to explain those concepts to different stakeholders. The best way is to show how BPM can address their concerns and change their working habits for the better.
I am with Alexander on " people wanted to talk to people who work on activities before and after their activity"

For sure they don't want to just sit in a cubicle where things appear in their Intrays (physical InTray or e-InTray and when they are done they put their output in an OutTray.

This is where "coordination" comes in.

They want to take to subordinates, peers and bosses. They want to know when a precursor step/action is going to be complete so that idle time between steps along a process can be avoided/reduced.

I am very excited about being able to embed CEM in a BPMs.

Amit's 'live chat" facility is CEM and as he states, much better then e-mail.
@Karl, RE "and the chief coordinator at Cases is the Case Manager" - it is also possible to have coordination *between* separate cases.
@Alexander .. How about a separate discussion topic featuring coordination between customer, distributor, manufacturer.where the need for separate entities may exist at the supplier level?

i.e. manufacturer has an Rdbms (Entity 1) where the cases are distributors with transactions of two types i.e. consignment shipments to distributors, and orders from distributors.

Then a separate manufacturer Rdbms (Entity 2) where the cases are warranty registrations from customers but with a link to distributors because warranty requests will in part be due to manufacturing defects, others due to distributor failure to properly install.

An example of coordination across or between cases might be how to orchestrate across customer cases, the shipment from a manufacturer with customer-self install of a kit that fixes a bad install from one particular distributor?

The distributors would have an Entity with Customers as Cases (fill order, ship, install). The distributors would get their BPM orchestration from the manufacturer.

An example of coordination between cases would be for the distributor to export customer sales records to the manufacturer so that the manufacturer would have a db of all customers, not just the ones who register, resulting in the manufacturer being able to directly contact customers who did not register to advise them of the availability of the kit.
@Karl, RE "topic featuring coordination between customer, distributor, manufacturer" Sure, we need to progress to digital-contract-as-a-process http://improving-bpm-systems.blogspot.ch/2016/07/digital-contract-as-process-enables.html
@Alexander .. Agree. "digital-contract-as-a-process" - this is important.

The way I would approach the setup for the manufacturer/distributor/customer/warranty/recall problems is each major stakeholder (manufacturer, distributor) would have one or more entities with cases.

The manufacturer probably would not want to mix up customers, distributors in one "BPMs"

But, they could benefit greatly from interoperability and they would want to be able to cross walk from, as in my example. a distributor record in one of their BPMs direct to the customers of that distributor to allow the customers to self-install a fix to the distributor install problem.

Anyone with experience interlinking SQLqueries across multiple databases knows that SQL queries are not easy to set up, especially when new ones are required on-the-fly.

We have had good success with free-form search Kbases that would, in this example, have for the manufacturer, all products, distributors, customers, warranty/recall tickets and from there weave the processing down to different Entities.

Blockchain would be nice to provide the tracking.
@Karl, Hmm, what do you think about a twitter-like stream (or channel) within each case for everyone who are involved in it?
@Alexander . . what we have from within each case is a CEM reachout component that pushes tasks to a portal.

It's strictly a 1:1 channel because we built it to trigger pushout from Calendar Events at individual user Calendars. Soon as the Calendar Event is posted at the Case, a portal task appears to the exclusive attention of the user.

When the user logs in, sees the task and responds by recording some data or simply indicating "done", the dat uploads to the Case Calendar Event, so very little danger the response can go to any Case other than the Case that sourced the pushout.

We are implementing right now a live broadcast "Notify" facility that can port to all stakeholders at a Case but there is no provision for any of them to respond.
  1. more than a month ago
  2. BPM Discussions
  3. # 20
Accepted Answer Pending Moderation

Wow, spent one day on the motorcycle and the discussion exploded..


Because all my own processes are done by AI (which, of course, modelled their own flowchart), I had plenty of time reading this and one thing strikes me as being just a simple BPM consultant that helps organizations to help their customers (to me the customer is never the organization using the BPMS/chat/whatever, but the customer of that organization):


What happened to process?


I see a lot of words about tasks, clicking on buttons, DSL etc but nothing about the fact that processes are just a means to deliver useful results and to be able to make them useful you have to make clear:


- What do we promise to our customers?


- What are the needed characteristics of the process to deliver that result


- What is the best way to manage it?


- How do you wanna keep track of cases


- etc


Just basic questions to make the right decisions to finally take a decision on supporting gadgets. And for some processes that might be chat apps, for others workflowish tools (with a flowchart to design the engine) and for otheres Excell or a piece of paper.


But probably thinking this way is too idealistic ;-)


And besides that; I would miss the fun of reading all those "that's nonsense, that's stupid" comments.


BPM community; thank you!

Sharing my adventures in Process World via Procesje.nl
Nevertheless, this is the first step to the customer-centric BPM from the current vendor-centric BPM,
  1. Emiel Kelly
  2. 2 years ago
  3. #2531
BPM has always been customer centric.

BPMS might have been a little vendor-centric ;-)
Is BPMN customer-centric or vendor-centric?
  1. Emiel Kelly
  2. 2 years ago
  3. #2533

  1. Amit Kothari
  2. 2 years ago
  3. #2535
Emiel - I agree strongly with your view on supporting your customers' customer. Often, it's just IT buying a BPM and that's when it all goes down a slippery slope.

With us - we've been seeing a ton of client-facing use cases like client onboarding that people would never dare to expose via a BPM tool. This is where (your quote) - "make them clear to make them useful" and chat/easy approaches that anyone "gets" in 15 seconds become extremely effective.

In terms of terminology - we use "task" as one step in a "run". A "run" is a copy of a "process". We are moving into the psychology of getting people to say "let me run this process".

The above basic questions are exactly what we've been hearing too, and answering them with even more basic (and simple English) answers is the future of this field. Processes are awesome, but are currently ridiculously hard to (a) model (b) do and track and (c) get process improvement metrics out of. Can I do and see (a), (b) and (c) in 60 seconds and show a breathtaking user experience? We're working on it.

So in a way, your note extrapolates that the evolution away from flowcharts and BPMN is also about opening up the highest-value customer-facing use cases (which are new) where engagement and ease of use is critical.
  1. John Morris
  2. 2 years ago
  3. #2538
Amit, not much can be done in sixty seconds. Some things are just irreducibly complex.
  1. Emiel Kelly
  2. 2 years ago
  3. #2542

Whether or not your approach or anyone else's is better; it all stresses the point that in our exciting world of processes there are different types of processes that need different ways of supporting and managing them.

Like I wrote about here: https://www.linkedin.com/pulse/process-management-your-trip-nice-castle-emiel-kelly?trk=mp-reader-card

Like Karl's examples in healthcare; those are processes that are dynamic, maybe unique for each patient. To support the execution and management of that kind of processes you need other things than when the goal of your process is to produce pushpins a day.

Processes are like people; if you don't understand their needs, you might give them a counterproductive medicine. (which of course will pay for the big bonuses of the Pharmaceutical Industry)
  1. Amit Kothari
  2. 2 years ago
  3. #2543
Emiel - if you referring to the diversity from the simplest process to the most complex variants and even infinite variants/tangents per-step, the non-flowchart approach is the only way to model it all.

IMO it's even more powerful than case management, with each "run" able to be entirely unique - while having social conversation, problems and even letting people submit suggestions for process improvement, in context - in a single place. And all wrapped around a facebook-like newsfeed of activities + what's coming up - all working in real-time - on any device. Each step has it's own custom payloads/forms and we even EMIT real-time webhooks that integrate to 500+ cloud apps. Inversely, we LISTEN to events from any cloud system to automate action on a step, it's breathlessly easy. Human mess is exactly what we've solved - not repeated robot-like processes.

The only way I can explain the insanely awesome UX/tech is to tell you what we actually did. Totally rejecting legacy BPM thinking was the only way to achieve this.

Best seen to be believed, tbh.
  1. more than a month ago
  2. BPM Discussions
  3. # 21
Accepted Answer Pending Moderation

I have a mathematical background, and am unapologetically scientist-centric, particularly as I am also involved in product development.

Formal structures such as BPMN serve a very important purpose in the industry, be it to encourage better engines to manage and execute the formal model, or to provide a common language for discussing and comparing processes with the same end goals. There are other formal executable models, such as, petri-nets that also represent processes, and are equally good. The added bonus being able to mathematically validate the model. This is important if you want the trust the product particularly with industrial processes, as opposed to back office processes.

Does all this mean that the customer has to learn BPMN speak? Of course not.

You can use whatever your customer prefers, paper and pencil, flow charts, or preferable a more modern design tool. They all have their place in helping the understanding of the problem space.

A very long time ago a client I was working at conducted an internal study to consider the replacement of the paper based change management process. It was perceived among some managers that a new automated tool (mainframe) would be good for the company. Interestingly the study concluded that the paper based system had at least a further few years to run, and the cost of the tool and training could not be justified at that time.

I am sure with the frequency of changes that occur in industries (both from external and internal forces, regulatory and business) the study would conclude otherwise now. You cannot survive with a paper based change management process, other than very trivial processes. The need for feedback loops would negate it.
  1. more than a month ago
  2. BPM Discussions
  3. # 22
Accepted Answer Pending Moderation

Prototyping is the specialty of finding that a thought isn't going to take a shot at the very beginning, rather than after you've conferred a substantial spending plan and connected with a total venture group. The reason for a model is to fall flat quick, so you can begin again with a superior thought.
  1. https://www.docup.in/
  1. more than a month ago
  2. BPM Discussions
  3. # 23
  • Page :
  • 1

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