BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, 21 March 2017
  4.  Subscribe via email
BPM has been around a long time, and with all the changes happening in business and IT, what still used aspect of BPM do you see going obsolete in the near future?
Emiel Kelly Accepted Answer Pending Moderation
Those...how are those annoying things with an opinion called... Oh yes, people. People it is!
Sharing my adventures in Process World via Procesje.nl
Comment
Awesome and on point. +1. Hell, +2.
  1. E Scott Menter
  2. 8 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Patrick Lujan Accepted Answer Pending Moderation
Blog Writer
As-is modeling.
Comment
Think of the thousands of consultants you're putting out of work who make an honest living spending all kinds of time and money to carefully plot out the way we NO LONGER want our process to work.
  1. E Scott Menter
  2. 8 months ago
What? Has-Been modeling pays my mortgage. Not so disruptive, please.
  1. Emiel Kelly
  2. 8 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Kay Winkler Accepted Answer Pending Moderation
From an architectural BPMS perspective, aspects to evolve up to a point of segregation, rather than becoming obsolete, I think, front end builders and rudimentary rules engines are good candidates. While many platforms nowadays come with pretty complete WYSIWYG form builders for automated processes, in real life however end user most of the times tend to rely on the creation of user frontends for processes in technologies such as .NET. Same goes for process business rules, where business rules engines (BRE's) become increasingly more common for BPM implementations.
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.
References
  1. https://bpm-books.com/products/digital-transformation-with-bpm
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Dr Alexander Samarin Accepted Answer Pending Moderation
Monolith architecture of BPM-suite tools and their "jack of all trades" mentality.

Thanks,
AS
Comment
Excellent formulation!
  1. Boris Zinchenko
  2. 8 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Bogdan Nafornita Accepted Answer Pending Moderation
+1 for Patrick's and +1 for Alexander's inputs.

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.
Managing Founder, profluo.com
Comment
@Bogdan.. Good points !

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,

  1. Karl Walter Keirstead
  2. 8 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 5
David Chassels Accepted Answer Pending Moderation
BPMN and BPMSuites. Next generation no/low code platforms will quickly build any custom aadaptive solution to support the digital BPM thinking/discipline.
Comment
@David, My thinking exactly.
  1. Karl Walter Keirstead
  2. 8 months ago
it's just that those platforms will each implement their own semantics and logic, which makes scaling via any channel impossible.
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!
  1. Bogdan Nafornita
  2. 8 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Karl Walter Keirstead Accepted Answer Pending Moderation
Commonly used aspect(s) of BPM today that will quickly become obsolete

# 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.
References
  1. http://[email protected]
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
E Scott Menter Accepted Answer Pending Moderation
Blog Writer
Two words: Flow. Charts.
http://www.bplogix.com/images/icon-x-medium.png Scott
Comment
@Scott.. Can you elaborate please?
  1. Karl Walter Keirstead
  2. 8 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Boris Zinchenko Accepted Answer Pending Moderation
Technology.

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.
Comment
Boris, are Petri nets (of course one mathematical language for modeling graphs), on which an executable BPMN model might be deployed, technology or law?
  1. John Morris
  2. 8 months ago
Concerning the 80/20 rule -- the 80% is likely the standard, commodity part of a business. The 20% remaining is where you distinguish yourself -- and likely earn a disproportionately large part of your margins. (That 20% is very likely to be more complex too.) I encountered this situation in the world of RAD and application generators. Application generators could get anyone to 80%. But it was the non-standard last 20% that prospects really cared about. If they understood their 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! : )
  1. John Morris
  2. 8 months ago
Karl, I totally agree that simplicity is mandatory, especially in context of end user interactions. However, it is important to distinguish a simplicity arising from deep understanding of the subject and ability to formalize it in simple terms from a simplicity, which emerges from poor awareness on relevant business domain. Needless to say, real organizations can be very very complex. It is then an art and professionalism of consultant to formalize and represent them in a simple and logical manner.

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.
  1. Boris Zinchenko
  2. 8 months ago
Life does not have to be so complicated - circles interconnected by directional arrows with a few special constructs (e.g. a loopback with a run-time counter) put most customers to the 80/20 zone.

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" ).
  1. Karl Walter Keirstead
  2. 8 months ago
I have encountered one famous start-up who was modelling their processes via Petri nets because they wanted "Turing completeness" :-)))
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" :-)))
  1. Bogdan Nafornita
  2. 8 months ago
Neither of two.

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.

  1. Boris Zinchenko
  2. 8 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Stuart Chandler Accepted Answer Pending Moderation
Blog Writer
Process mapping up front will disappear. Maybe not quickly but clearly, general mapping tools are being less used to design. Agile is pushing build quick thus whiteboard drawing is done in short order and in a flash coded. Playing back the application closes gaps and poof things go into production (yes, over generalizing). Process mapping is only supplemental vs being the driver. And user experience, using the application or storyboarding is the way forward.
Comment
The customers can have their cake and eat it (assuming minor hand holding).

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.
  1. Karl Walter Keirstead
  2. 8 months ago
@Karl -- re: "piano playing", .a.k.a. I think "simulation" -- a great idea -- but simulation in my experience has never been widely practiced "in the real world". This could be a good BPM.com question . . .
  1. John Morris
  2. 8 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 10
  • Page :
  • 1


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