- E Scott Menter
- 3 months ago
I tried to summarize the different BPM components to be considered, in case of interest, in chapter of the new book "Digital Transformation with BPM" (link below).
In that sense, I could imagine BPMS becoming more focused on the business process execution side of things and consolidated packages containing everything from a BPM engine, over form builders, all the way to BRE's becoming more a thing of the past.
What I hope to become obsolete is the constant whining of pundits that BPMN is too complex to use it for communication to customers. None of my customers has complained about it - and my typical customer has much more modest origins than the typical white-collar, Fortune 500 CxO customer that the pundits usually serve. For perspective, none of my customers have seen anything remotely close to a visual execution programming language and the only education they received was a 5-minute explanation of their own workflows.
Another hopeful entry in the obsolescence list is the assertion that strongly coordinated workflows are a thing of the past - 80% of the humans of this world still operate manually and they could immediately use some of those workflows. This is an especially disingenuous assertion, when coming from the same people that hail low-code, Zapier, IFTTT and various IoT integrations, all of which are the epitome of strongly coordinated workflows.
Folks who buy paintings don't lecture the artist on why kind of paint / brushes he or she should have used. So. why lecture analysts who like BPMN and whose customers relate to BPMN diagrams?
The point is we map once, then a few more times as part of improvements but, next, the focus shifts to managing thousands of Cases that load process templates (the average physician has something like 3,500 Cases, any 20-30 require attention on a particular workday).
On human participation, the range goes from low (industrial process control), to moderate (mix of structured and ad hoc interventions) to high (pure research).
Aside from a few special cases, once the map is done/compiled/rolled-out, the only "user" who really needs to refer to the carved-up map is a computer program that only cares about 1's and 0's.
Except, as I have pointed out a few times, for folks like medical staff who need to know who did what, when, and why, in the past and supervisors who provide oversight on the progress of work and need to view the 'balance-to-go"
Anyone doing MRO on military aircraft also needs to look at the Hx.
My rules for the use of BPM are . . .
- any work that benefits from more consistent use of a template
where you have multiple Cases, hosting end-to-end process templates or process fragment templates or both,
where steps are connected in sometimes non-trivial ways,
where different steps require different performing actors,
where different steps require the collection of different data elements,
most of these "I know best, screw the lowly standards" players will be very profitable and quite small, mostly focused on the North American market, which is large and homogenous enough to warrant enough turnover for all these smart henhouses.
oh wait, that's happening already in the BPMS market!
- Bogdan Nafornita
- 3 months ago
# any mapping technique that does not allow drag-and-drop mapping by a facilitator as fast as stakeholders can say "and then we do this".
# any facility in a mapping environment other than "one mouse-click" to compile and generate a run-time template of a mapped process.
# any mapping environment that does not accommodate sophisticated run- time data collection at steps (i.e. context/situation-appropriate forms as attributes of process steps)
# BPMs as we know them today
I am avoiding highlighting here features of Case Management environments that seriously facilitate or complicate the potential for background BPM to provide orchestration and governance for the management of Cases.
On most fundamental level, BPM consists of knowledge and technology. Technology is a way to accumulate, store and implement (execute) the knowledge. Technologies are superseding one another and quickly getting obsolete in ever accelerating cycles of technical revolutions, while the knowledge is a fundamental asset, which only grows in value with time.
Basic laws of mathematics and physics are known for several centuries and discovery of these laws shaped modern civilization. Computers appeared as manifestation of these laws and increased our ability of interpretation but did not change the laws as such.
Similarly, BPM is a way for discovery and interpretation of behavioral laws of large human collectives in their interaction with consumers and production facilities. These laws are also fundamental and change very slowly (if change at all). Professional BPM allows establishing islands of long-term stability in quickly changing corporate environments by accumulating and storing principal metadata and knowledge of the business.
BPM technology is just a tool to handle this knowledge. It does not matter, if a model exists in a form of BPMN, EPC, UML or whatever future notation to come. It does not matter, if a model can be executed or not in a specific BPM engine. However, it is crucially important that the model correctly represents all aspects of running business.
If the model is fundamentally correct, it will easily survive and move across generations of notations, implementations and technologies, while serving as a driver for these innovations. Exactly for this reason there always exists a demand for business transformation services where syntactically consistent models and metadata serve as a ground and guarantee for smooth evolution of business.
It's for this reason that math and BPM executability is important. I If you have lousy math underneath your BPM product, then you will have trouble when you get to the 20% of non-standard processes. The cost of not having complete business freedom when using any software is much, much higher than we realize. (BPEL was notorious in this regard.)
Clearly no business person wants anything to do with Petri nets (or any other similar math) directly. But that's not an argument for technologists themselves to not use the best math to build BPM products. The BPM engine (claims to the contrary) is not yet a commodity. Resolving a complex graph in real time is very difficult. At least, this is what I'm told! : )
Surely, Petri nets for end user modeling can be an overkill. However, same Petri nets and much more complex structures might be entirely relevant as a hidden technical implementation. Again, the task is always to represent the real business structure and processes of organization in most compact and efficient form, whatever notation and methodology will be most relevant for this goal.
In our work we passed on the notion of providing a "decision box'" construct - not needed, the designers said, just lasso two or more ordinary process steps, make sure the attached form at each decision box option has a rule set that allows the step to "fire" and the customer is good to go. None of our customers finds this awkward.
Other easy-to-include constructs are "no earlier than" start times at steps. You don 't want either a flow graph that says your July 4th event is going to happen on July 5th. One thing to know it is running late so you can do something about it, another to have the event date floating.
Every run-time environment can benefit from a "link to process" facility - this allows users, systems, to dynamically thread processes or process fragments together thereby avoiding the need for large stand-alone plan side maps of "the process".
Except for the odd end-to-end process, there is no "process' at a Case until the Case is closed.
In theory each Case is unique, but, nothing wrong with cloning a particular Case with its combo of structured/ad-hoc steps, nothing wrong either with auto-mapping of a new process that drops skipped steps and puts ad hoc interventions in line. (i.e this Case went well, let's declare it to be a "best practice" ).
Of course they ended up in massive confusion, but still they said they do not want to go to more "traditional approaches such as BPMN" :-)))
- Bogdan Nafornita
- 3 months ago
Petri nets are a BPM notation. Unlike many other BPM notations, Petri nets have an exact mathematical definition of their execution semantics, with a well-developed mathematical theory for process analysis. For this reason, they are popular in academia. Probably for the same reason, they are rarely used in practical BPM modeling, apart from very specific and complex analytical tasks.
Notations as such do not represent laws or metadata but just serve as a form of expression. Similarly, one physical law can be written in several complimentary formulations like in quantum mechanics. It is only essential that each BPM formalization correctly represent the reality of organizational structure and business operations. If this rule is observed, models drawn in various notations will ultimately converge to singular representation of a business, which they represent.
Agile is indeed where we all need to be, assuming an inventory of process fragments so each user does not have to start from scratch.
Whiteboading, unless you mean e-whiteboading, needs to join buggy whips.
You are spot on with drag/drop mapping with "one-click" coding.
If a facilitator cannot build an initial map as fast as his/her audience says ".. and then we do this" another mapping environment would serve the audience and facilitator better. (requires an inventory of images of forms that will be used; requires describing rules in narrative terms only - otherwise things get bogged down), Forms/rules can get done later.
And, no amount of staring at paper process maps beats a small number of stakeholders piano-playing a compiled process to "close gaps" etc.
- Page :
However, you are not allowed to reply to this post.
Join the Discussion
Webinar:Your Digital Disruption Survival Plan
Thursday, July 13th @ 1:00pm Pacific/4:00pm Eastern
In this fast-paced and informative roundtable discussion, three leading experts on business process management will explore the right methods and capabilities that make difference between success and failure with enterprise process management initiatives