1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 19 March 2019
  5.  Subscribe via email
As Keith Swenson wrote here: "Models have served their role in history but now we are seeing a new trend we have seen the limit to what process models can offer. We’re now finding the business process models are holding organizations back." What do you think?
Accepted Answer Pending Moderation
I think the problem Keith Swenson is rightfully concerned about is a too detailed level of granularity that BPMN diagrams often have from the perspective of the average business user. If you don't adjust the level of abstraction to the purpose of the model, you certainly end up with a process model landscape that resembles a legacy code base: nobody understands it and it needs constant refactoring. To avoid this, things like automated modeling convention checks, simplified BPMN element sub sets, and higher-level notations like process maps and customer journey maps exist.

Still, I think Keith Swenson is pushing the programing analogy too far. Many process models are not executed by machines, but used as tools for structured communication by humans. And as such tools, they do a great job in managing complexity, for example by bridging the gap between business and IT. This does not mean we cannot do better; of course, BPM(N) should evolve and provocative ideas like this one help drive progress :)
I agree, the pictures make great drawings, and drawing a picture while discussing business (or coordination) make a lot of sense. But imagine for a moment that instead of drawing the picture as an input to system, that instead the picture was produced by the system. And the picture changed every day. The picture shows the current state of the process, without the picture trying to force the state of the process.

Many people will think that conformance is an important concept. Conformance to what? To a process model, of course. But there lies the problem. The act of gathering all that into a single, authoritative place, along with all the agreements, becomes a burden that never quite pays out. The effort of getting everyone to agree, becomes the barrier to change when nobody has the time to re-agree to the modified model.

Instead, I want to let the system do all that work of gathering and drawing up the picture. It is kind of obvious after you see it. Just as Google maps will find a route for you through a city, this new approach, ESP, will find the route through the organization, and avoid the cost and problems of a pre-defined business process model.
But Keith you know that now the picture is the system built direct from user input and at a click ready to run no code generation or compiling. Very quick and also very easy to change. Let's remember compliance needs must always be recognised and with the benefit of full audit trail of activity as required. All users including managers have real time access to activity which can contribute to improving productivity. All this recognises no such thing as a static process but business always in complete control . Certainly not a burden indeed empowerment of people is a consequence. As for cost a fraction of old hard coded inflexible way of past....
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
Peter it is always a great compliment to have you pick up the topic of one of my blog posts.

I have a series of posts coming out that are going to lay out 6 different ways that hand built process models -- as a construct -- are not meeting the demand. The main points will be:

  • Process Models are too much like programming
  • besides that, organizations change more quickly than process models can
  • besides that, BPMN is too much of an imperative language for organizations
  • besides that, CMMN is not declarative enough
  • besides all that, a process model requires you be omniscient about your organization
  • finally, besides all that, process models require agreement which is burdensome

To summarize this: hand built business process models are simply not agile! We already know from the software field that building elaborate plans for the development of software is a doomed approach because the time spent making the elaborate plans is never quite returned. It is better to have simple cycles of doing and reflecting and improving than to cast an elaborate plan in concrete. Business process models need to be "minimum viable processes" - but that is not what you get with a hand built process model. The process model is a single canvas, but what you need is a multitude of canvasses which every participant can draw their own part. That is the essence of a radical new approach called Emergent Synthetic Processes which I will be presenting at bpmNEXT.

I should leave it at that, and I very much look forward to the always intelligent, always interesting remarks by the experts who contribute here.
6 great points ...very true.
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
It really depends on the time and method taken to build the process model, and who needs it for what purpose.

Often in the past we have been hired by clients who have had very large teams modelling every single activity and action for months and months with nothing to show for it but lots and lots of files.
We always begin by having a serious conversation with the client (preferably 'C' level) asking 'Why exactly do you want us to build you a process model?". Sometimes we have to dive deep to get the real answers which have frequently included: "We need to cut costs but we don't want to let valuable people go", "We feel this operation is inefficient but we don't know why", "We need to integrate n departments who seem to be doing the same thing" (our record was 14 departments), "We can't pin down if this department and its manager is adding any real value. Its all smoke and mirrors and we need some hard evidence to take action." "We need an accurate baseline reference point and identification of the gaps with the changes we have to make". And the more positive: "Our staff are under stress, we want to improve the work/life balance by removing work which is wasteful, unnecessary and/or can be automated or done by a third party"

Whatever the answers, I then sit down our mapping workshop teams to develop what we call a 'meta model' so that we gather the information that's sufficient and necessary for the client's purpose. That way we don't waste time gathering irrelevant information. However we always ask and capture all of the workshop participants' views, anecdotes, and complaints on what causes them problems or what they think can be done better. We do this anonymously so there's no comeback from their manager. However we do convert all of this into a list of quickwins and low-hanging fruit that can be implemented as soon as.. so that there can be some early, often valuable, benefits from the outset.

On the subject of participants and managers: we always pressure the client to allow front-line staff in our workshops and NO managers. We bar managers because their front-line knowledge is often very dated and they subdue the other participants to the point where they say little until their manager has spoken. With front line staff we often find that our fairly informal workshops are the first time anyone has asked them questions like 'what do you do?' 'how do you do it?' and 'Who do you think benefits from it?"

Because we are taking front line staff away from their real jobs, the workshops have to be short (2 hours max), highly participative, fun and productive. With our method and the teams we train, we can capture, convert and digitise, validate and analyse a departmental or functional process model in some days, not weeks or months.

The client gets the answers to their questions, the digitised process model gives them a clear reference basis for the sequence of activities and, as importantly, the links and dependencies between each. And there are often 20 or 30 useful staff ideas that have either been ignored or never raised in the past. And when those get fixed it sends a key morale boosting message back to the front line saying "you have been listened to, and we are taking the action(s) you wanted"

So to answer the question: Yes some process modelling approaches do hold companies back. It really depends on what you do, how you do it, with who and for what purpose.

You make a very good point here. I am focused on a model for "facilitation" of the work (a.k.a. automation). To do that, you need quite a bit of detail, and that is subject to change.

You accurately point out that business process models can be used for other purposes. They can help an executive team to understand what is currently going on (and maybe what is currently going wrong). In this usage, it is a partial picture which focuses on a relevant aspect. I am going to have to figure how to make it clear that this is still relevant and quite a different topic than my central one.

  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
All models are wrong, some are useful. Everything depends on what kind of models we create and how do we use the models to help us to dialogue and understand the situation. The models are just an image of reality. In a fast-changing complex business environment, outdated process descriptions just add confusion and slow down the needed action for improvement. I try to help my clients to strive agile process management. Anyway, in some stage of the improvement, there is always a need for modeling of the process (=input, action, output) to clarify the issue and the need for appropriate remedy. The only way to improve is to make something in a different way.... and this the case for process modeling.

Br. Kai
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
“Emergent Synthetic Processes is an approach that promises to offer a custom-built process for each instance. “ it seems as an archaeological discovery of one of my favourite blogposts about BPM from the year 2010 – see option 3, 4 ,5 and 6 from [1]

And, process models become DIGITAL models which are, actually, integral parts of digital systems. The expression “All models are wrong” is wrong. [2]

And, let go through Keith’s list:

“Process Models are too much like programming – be they must be systemic because you don’t want to mess up you business

“besides that, organizations change more quickly than process models can” – don’t put the cart before the horse, please! – organisational changes are made by changing processes

“besides that, BPMN is too much of an imperative language for organizations” – it is only one of many techniques to express the coordination of work

“besides that, CMMN is not declarative enough – it is only one of many techniques to express the coordination of work

“besides all that, a process model requires you be omniscient about your organization” – no at all, if there is an architecture of your organisation

“finally, besides all that, process models require agreement which is burdensome” – any change in an organisation requires some agreement by definition.

  1. http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html
  2. https://improving-bpm-systems.blogspot.com/2018/04/better-architecting-with-digital-model.html

>> "...omniscient about your organization” – no at all, if there is an architecture of your organisation

We should talk a bit more about the "omniscience" point, because I think you have only deflected the requirement from the process model to the organizational model. That does not actually solve anything. When modeling a process "by hand" the modeler would have to go and examine the organizational model, and understand what is there, in order to draw the model. Clearly a properly maintained organization model would be a huge benefit in that. It makes it easier to centralize the knowledge of the organization. My point is that some person still needs to internalize this knowledge in order to draw the process diagram.

What if, however, we could automatically generate the process model based on the organizational model, along with some specifically designed rules that guide that generation. Process synthesis. At first glance this does not save any effort because the specification of the rules is possibly more work than the drawing of the model. But the difference is that the maintenance of the rules can be distributed to many individuals in the organization.

Because a process model must have some coherence, it is hard to collaboratively draw a process model. Sure, a number of people can be involved, but there is no way to constrain the edit actions to be limited to a particular person responsibility. But, the rules used to synthesize the model CAN be controlled in this way. That is the key advantage.

We still use a process model, we just don't require a person to get themselves into a position to be able to draw it by hand.

>> any change in an organisation requires some agreement by definition

Not really. Inside my team, I can reorganize how tasks are being done, and nobody outside my team really cares. The problem is when I have a process model that includes things my team members are doing, along with things your team members are doing. Now we have a problem. I want to change my part, but I need to get your approval that your parts have not changed. Even if I make it very clear that I only changed tasks 1, 2, and 3 while you only care about tasks 7, 8, and 9, it still takes some of your time to consider and approve this. That is an unnecessary level of agreement, because I claim the only reason you care about how my team does it is because all of the tasks were (arbitrarily) drawn on a single process model.

Process model vs organisation model - can a model "generate" another model? Yes. This is exactly I try to do with Smart Cities. The Smart Cities reference architecture methodology comprises 100+ models with explicit relationships between them and the guidelines how to generate a particular model from some existing models. Such generation may be semi-automatic or manual. Approximate sequence is the following: Mission -> vision -> capabilities -> functions + processes+... -> org. structure, etc. See slides 37-41 https://www.slideshare.net/samarin/towards-softwaredefined-organisations

Changes - shall local changes be announced at the system level? In a perfectly built system some local changes are agreed "by design", i.e. the architecture guarantees proper encapsulation for some local changes. In real systems, some local changes may cause "side effects" somewhere else.

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

High level “models” are always useful. Once you start to develop lower-level models, it becomes important, though, to synchronize strategy<-->operations-> -> strategy to avoid top management thinking a process does this, with operational folks knowing it does that.

Nothing wrong with building a high-level model, compiling the map and rolling it out for piano-play in front of a group of stakeholders if this helps with understanding of a proposed low level process, and facilitates the development of such processes.

Rollout of a high-level model to a production environment is not recommended as it violates the rule that steps along workflows need "owners" who can be held accountable. It is worth mentioning that plan-side owner tags must be performing_actor_classes/skills, not named individuals.

I picked up on a couple of things in the article that may be worthy of discussion or debate.

“If your process model has 40 to 60 different activities with all the various conditions that direct the flow between them, the model has to extend across multiple pages. When it does so, it is no longer easy to see and understand.“

I am not clear on what a "page" is - if I have a 60-inch screen, is that my page?

We draw our maps on a ‘canvas’ – I built an 8 foot x 8 foot one just now and had no problem scrolling it easily/rapidly from left-right and top-bottom. Clearly, long directional arcs are to be avoided, but in the environment we use, you can have Go-To's and Came-From's that eliminate long directional arcs.

Coming from the construction business (using CPM) where 30 foot wide x 4 foot deep maps are commonplace, the notion of "pages" seems unnecessary.

Switching to BPM, given the paucity of end-to-end processes, few process fragments are likely to need 8 x 8 foot maps.


“a large multi-page model [process] can be just as hard for someone to understand as a large program.”

For me, staring at either is non-productive.

Best practice for understanding any process is to compile it, roll it out, have some data handy and then make a video featuring execution of an instance of your process template OR get a small number of users to "run" a few instances of the process template in a Case.

Some say this is too time-consuming - I disagree.

A good facilitator can map as fast as domain experts say " . . . .and then we do this" PROVIDING he/she does not try to build auto-execute rule sets or paint complex forms. Happy to do a cake-bake with anyone who would like to see how our folks build process maps.

By all means include branching decision boxes but make the options manual-select initially - park a blank form with one memo field at each decision box option and type in a narrative that can later be used to build a rule set off-line. Don't subject domain experts to rule set building.

In respect of data display/data collection forms at process steps, initially post a blank form with nothing more than the name of a formand one memo field OR post an image of an in-use paper form but, again, include a memo field for recording notes/observations. A process step form can take from 15 mins to hours to build so don't subject domain experts to time delays when building process maps.


“requires the skills of a programmer”

True for most rule sets - you don't need much complexity to get to where rule set construction becomes complicated at forms, at pre-processing steps, at post-processing steps, at process control point steps, and at decision box branching options.
  1. http://www.kwkeirstead.wordpress.com
My point about the 40 to 60 steps is to bring to light how the "demos" always include 4 or 5 activities and from this they give the impression that a model can be easily understood without work. Clearly a Java program of those 4 or 5 activities would be far more difficult to understand. This difference is very large with 4 or 5 activities, but that benefit diminishes greatly when you have a large number of nodes. At that point, you can't just look at it and get the gist. Instead, you have to carefully read a large number of nodes and "internalize" it. It does not really matter whether this is printed on 20 sheets of paper taped into a big 4 x 5 grid, or whether it is 20 sheets of paper which have continuation markers to link them together. Either way, the work is to understand and internalize, because just looking at the chart is no longer sufficient.

The chart will always be easier than the Java code, but I am saying the difference is far less clear when the number of activities gets large.

Where I am going is to a system where the diagrams are not "hand drawn" but instead are automatically drawn from other clues that individuals submit. Once again, it is not so much about the initial drawing, but the later maintenance of that drawing.
@Keith Thank you for the comment

I have never been a fan of 'staring' at flowgraphs other than CPM flowgraphs where left to right is a "to-scale' timeline. All discussion re large flowgraphs has for decades been pointless if the organization does not have a flatbed plotter (the paper goes up to 42 inches deep, last I checked)..

I just wonder if ANYONE today needs/uses printouts when you can drag a scrollbar horizontally or vertically and have the graph refresh as fast as you can drag the scrollbar. No need to entertain complaints about needing to drag in two directions - it would not be that difficult to click, hold and drag at a point in empty space and go at any up/down at any angle the user wants.

I agree "continuation markers" is a buggy whip approach but for folks who are very familiar with a flowgraph or set of flowgraphs with GoTo/CameFrom connectors, we have had some success with a "total sheet view" where you see blurred clusters of workflows with a zoom in option. We never got around to an adding auto-zoom to a quadrant of interest.

We had, at one stage, an elaborate transparent Globe display for "things" where you could see objects coming around the back side of the Globe but the testing conclusion was that the computer screen size was the limiting factor to viewing tens of thousands of nodes at one screen. Very important to us in our apps to be able to host 50,000 datapoints at one sheets - you have probably see examples of these at my blog.

We had better success getting users to engage a search and have the software highlight what it found and did not find and hiding outlines (i.e. containers) where nothing ways found.

Scrolling issues aside, I am still intrigued by the need to "internalize" - if I can browse quickly, do searches /masking of clutter, then, at each node in a flowgraph click and get to see the forms that are needed for display/data pickup, see any instructions that new users might need (text, PPT, video) and get to see what the routing is (without the need for complicating swimlanes), what else is there that anyone needs to "internalize"?
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
From what I've seen. the answer is yes and no. Process models provide great insight into what is and what could be as a result of changing the way things are done. Shift inputs here, redirect the flow, and assess the impact - so no, they do not hold companies back in that sense. Where I say yes is that many companies fall into a state of analysis paralysis by playing out too many scenarios with their models in an attempt to find the perfect solution to improve or replace a process. As a result, what could have been designed and changed in a month took three, and what might have taken three is now nine.

My point is that the focus should be on the problem, or goal of improvement and automation of processes, not the technology. Companies I have seen take this approach along with a somewhat Agile mentality will design and simulate an initial model, make a determination of this is suitable and then implement it knowing it will need refinement based on updated and real data.

Yes Business Process Models can hold a company back, and No if it is focused, and done with the knowledge the model will not be perfect.
Bob Larrivee
President and Founder
Bob Larrivee Consultancy
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
Keith is absolutely correct in pointing out that models like BPMN are too complex, inflexible, and programming-like, and that therefore they can represent a significant barrier to keeping up with rapid market and regulatory changes.

Bet let's perhaps not throw out the baby with the bathwater. It is not impossible that a model exists that minimizes the drawbacks of BPMN while preserving the values of predictability, flexibility, and accountability. (Well, yes, I'm saying it does exist. But I'm saying it in a coy, thoughtful manner. That's just the way I roll.) I'm pretty leery of the idea that “hey our process is going to change organically and it'll be a new one every day”—that sounds to me less like a business and more like a bunch of people doing whatever they want and hoping it works out.
Scott's opinions only. Logo provided for identification purposes only.
There is a misplaced expectation that a graphical model can remove the programmer. For automation purposes, the BPMN will always be better than the Java code, what I am trying to say is that the difference is not different enough to remove the programmers from the loop. I have nothing against programmers, but having to have a specialist -- whether we call them business analysts or programmers -- will form a barrier to change.

Where I am going with this is to say that the model should not be "hand drawn" but instead generated from the system as a reflection of the layer that people are really working at.

Are you leery about the process changing every day? I recently have started using Google maps to plot my drive home, which can be anywhere from 25 to 65 minutes. Google maps knows about the places that are currently backed up, and it quite often plots a different route. There must be a dozen different possible routes, and it uses different variants every day. I would assure you: I do actually get home every day. There is never a situations that end up at the wrong place! However, the course is different every day.
@Keith. As I have explained a few times the graphical designer where build can take place does not need a programmer. Sure if a complex algorithm required get good coder but under instruction from business and ready to use. The core business logic is pre coded covering all required activity in any business process. Because no coding code generation or compiling change readily supported and where anticipated user could do. However our experience suggests users do not see it as their job plus having a good communicator can pull all ideas together to implemented change. Where process change anticipated that can be seen as an informal process which allows the user to do what is required but does need a result to be inputted...and with inbuilt timing lack of action quickly identified. As for speed of build hours not days. AI readily incorporated as required. I can see a possible future move where once built then Automation of a change could be incorporated in certain circumstances.....now on our agenda for a future move..thanks for the idea.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Appropriate process models provide the transparency necessary to come to fast well informed decisions and related actions. Hence, they speed things up. However, the usage scenarios of the models need to be clearly defined. This determines the right modelling methods, content and level of detail.
  1. Caspar Jans
  2. 1 year ago
  3. #5976
I was planning on writing a long text on the validity of process models, until I read the input from Mathias and that basically sums it all up. Well put!
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
The validity and viability of process models, constructs or methodologies, surely depend to a very large degree on the given business context, verticals, markets on one hand and the right balance between formalized structure and flexibility, on the other hand.
Extremes, where no underlying structures and models exist, are at least as harmful to a business as are completely rigid processes that only slowly or not at all adapting to swift market shifts.
In our past implementations of mission critical, end-to-end processes, accompanying base structures and models have always proven helpful. BPMN is still a valid framework to standardize process visualizations that are intuitive enough for all process stakeholders to understand, the APQC's PCF provides a pragmatic starting point for many companies to start developing their continues improvement cycles and CMM, for instance, provides guidance to the end user to start combining process flow charts with decision tries in a single representation.
In that sense, process models certainly have had varying levels of benefits. However, at least in our markets, these models did not yet have a negative impact on process management success, while the complete absence of them unquestionably did.
NSI Soluciones - ABPMP PTY
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
No.... most business are so tied up with their inflexible silo systems the idea of a meaningless model not on radar...but when they recognise the possibility of a model that not only reflects how their people work and create new information but can be the actual system..without old IT barriers then the game will change.
@David . . .

We are still seeing "old IT" - I saw this very recently in one area of law enforcement where the culture of the IT Dept had successfully transitioned from "digital plumbers" to a culture of understanding that the Dept was core to the success/failure of key strategic initiatives (not all strategic initiatives need IT contributions but most can benefit from IT contributions).

The problem often lies with the rest of the organization that still views the IT department as a non-main event.

It is my observation that organizations that embrace ACM/BPM eliminate the silo "problem". Silos per se are NOT a problem.

Enlightened organizations can continue to use the functional organization model (if that suits) - their "silos" simply become parking lots for staff with similar skill sets, retaining the legacy benefits of silos for cross-learning and easier mentoring for new hires.

The "new" silos see a rollout of staff each "morning" to "work" that has a focus on efficiency across Cases (i.e. initiatives). Within each initiative, there is a Case Manager who motives the "team" to focus on goals and objectives of the Case. (focus on effectiveness).

Going back, organizational theory has not changed - we have functional, project and matrix organizational structures (the latter combining the best features of the first two). It's my view that with ACM/BPM, the choice of organizational structure takes the organization out of the efficiency loop (i.e. "work takes over") but can impact effectiveness.

My experience at Bechtel (25.9 billion USD in 2017) was that project organizational structures were best for large engineering / construction projects, with a matrix organization at worldwide Head Offices.

Bechtel was the 1st engineering/heavy construction company to supplement the ES-EF-LS-LF (early start, early finish, late start, late finish) CPM model with P/AS-P/AF-E/AS, E/AF (Plan or Actual Start; Plan or Actual Finish; Expected or Actual Start; Expected or Actual Finish).

My take is there are useful learning experiences to be derived from auditing once-through projects, end-to-end repeat initiatives and mixed structured/unstructured initiatives.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
Couldn't agree more with Keith. It's been my battle for 25 years.

Once asked a company 'what' s the goal of your processes'

'To model them'

I cried for 2 days.

Processes are executed to deliver results. If a model tells the truth it should tell you what is that result and what is needed to deliver that results.

And that makes a model complex. And less complex models don't tell the real story.

But if you want to discuss a picture of blocks and arrows; be my guest.
Sharing my adventures in Process World via Procesje.nl
  1. John Morris
  2. 1 year ago
  3. #5985
Don't cry Emiel. :)
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation
Process Models are too much like programming

This must be the top statement I'd like to become true during my lifetime :)

besides that, organizations change more quickly than process models can

You must be very lucky - I have yet to meet that customer than can change their behaviors, rituals, internal political dynamics, legacy systems, rules, mindset... faster than I can change their processes not even in models, but in software too!

besides that, BPMN is too much of an imperative language for organizations

I agree, but then the whole point of a successful business is a repeatable pattern for generating customers, revenues, profits. If you only prescribe that pattern, the impact is tremendous. I cannot generically exclude any programming language, no matter how prescriptive, in helping to code that repeatable pattern in an organization.
Yes, all caveats about being agile and flexible do apply.

besides that, CMMN is not declarative enough

hence its complete and utter uselessness.

besides all that, a process model requires you be omniscient about your organization
finally, besides all that, process models require agreement which is burdensome

unless they're organized as microservices around business functions sharing a common collaboration language
CEO, Co-founder, Profluo
  1. John Morris
  2. 1 year ago
  3. #5986
Bravo "repeatable pattern'!
  1. more than a month ago
  2. BPM Discussions
  3. # 13
Accepted Answer Pending Moderation
The main reason for the hold back is that Process Modeling tools suck - they don't enable change to the model. When you combine this with inappropriate volumes of detail a model becomes completely unwieldy. Mapping/modeling software today is like the typewriter ...when the job really needs a word processor.

Also, current tools lack separation between the process flow (desk to desk or work center), task flow (the work done at the desk or work center) and the procedural instructions (the buttons to push). Exec management want to know the first level end-to-end - How the Business Works - ops managers / supervisors and workers want to know what tasks are required for a particular stage, and workers need the step by step button pushing procedural instructions. Each level has an order of magnitude more detail so start with the process flow and diver deeper when needed.
  1. more than a month ago
  2. BPM Discussions
  3. # 14
Accepted Answer Pending Moderation
In response to Keith's 6 points

Let's take each point in context of what is now available...and of course ignored as far too disruptive for established player!

Process model is simple reflecting business is actual simple now in hands of business analyst skills not coders and Nothing like programming!

Yes business do change and do need to be supported by software. The model makes it easy as no code generation or compiling with a change control ensuring smooth seamless transition.

Looks like BPMN and CMMN past sell by date...?

Declarative technique very effective from model to pre built business logic covering all needs very effective..but IT do not understand such simplicity!

Omniscient yes and knowledge is in hands of employees who can now have direct input into the model and with very quick build can give their feed back

Sadly IT have created so many barriers that users agreement way down agenda and hence great cynicism as systems imposed. The model readily understood by business users and will change the old ways and attitudes.....but many vested interests will indeed have resisted......

PS want to understand more see research paper summary on Object Model Development Engineering and by the way no one can patent as prior art rules so have a go!
  1. http://www.igi-global.com/chapter/object-model-development-engineering/78620
  1. more than a month ago
  2. BPM Discussions
  3. # 15
Accepted Answer Pending Moderation
Wow! "ESP" ( a.k.a. "Emergent Synthetic Process" ) is an amazing concept. And the analysis of BPM as "programming" and all the problems that implies (e.g. "procedure" rather than "declaration" etc.) is fantastic. I'm most interested to learn where ESP can go, because certainly BPM needs momentum. I suppose we will have to wait until after BPMnext for all the details; but at least from the slides that are available now we get a little hint as to where ESP could go, as per @Keith's slide deck "Not Your Grandfather's BPM".

Specifically in the deck I note the word "gig", as in a process whereby organizational leadership defines "Service Descriptions" and then processes are "synthesized" from there. The "gig" term shows up because apparently this means we see the formation of a gig economy inside the walls of the corporation. So there are huge corporate governance implications here.

I note an interesting historical analogue, which was one of the earliest collaboration tools, "The Coordinator" by Action Technologies, pioneered by Fernando Flores. The background goes thru Chile and Cyberneticist Stafford Beer. The idea around The Coordinator, based on speech-act theory, was "proposal" and "commitment". In other words, not unlike the idea of the gig economy, work is organized around a series of offers and acceptances. (This rather up-ends the definition of the corporation per Ronald Coase, where the corporation exists precisely to avoid contracting costs.)

The idea of "emergent processes" suggests as well process mining; Prof. Wil van der Aalst and company seem to want to push process mining much further in the direction of acknowledgement that real business processes are a lot messier than BPMN diagrams would suggest or allow.

I'm excited to learn more about how synthetic emergent processes could help with the messiness of business reality. In particular though I'm interested to see what would be the impact on corporate leadership and governance. Certainly ESP for non-core processes. But core processes are about the work of business, and have to be owned by accountable executives. A corporation is not just a set of happy outcomes for stakeholders, especially shareholders. A corporation is about owning and leading value-creating processes. I fear that "emergent" implies an excuse for an abdication of leadership. And without leadership, one becomes merely agile, which I have suggested is a random walk to nowhere in particular.



Here's S+B article from in 2009 "Fernando Flores Wants To Make You An Offer"

"Spend any time with Fernando Flores and he will assess you. He may make an offer, which you are free to accept or decline. If you accept, he will make a commitment to fulfill his promise."
Stafford Beer during a TV interview was asked what he thought about the effectiveness of seat belts for accident reduction. He gave a vague response.

The interviewer then asked whether some other approach might work better. His response . . . . . "Spikes in the dashboard"
  1. John Morris
  2. 1 year ago
  3. #6001
Yikes! Not an advertisement for the work, I think. (Beer retired in Canada, near Toronto.)

There's been a renewed interest in some of these topics with the growth of socialism in the U.S and the publication of a book and numerous articles on the "Cybersyn" project.


I once had an interesting chat with Flores fils at a trade show - at the Action Technologies booth.
  1. more than a month ago
  2. BPM Discussions
  3. # 16
  • Page :
  • 1

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