Now consider that the 80% is the commodity part of your business, i.e. the less complex part where there are probably apps pre-built with implicit data structures, processes and rules and UX. But you get most of your margin (in a competitive marketplace) from the last 20%, where you can't buy off-the-shelf.
That last 20% is by definition the more complex part -- where you achieve competitive differentiation. But being more complex, it's also where simple tools fall down. So, why bother? The cost/benefit often doesn't add up when you look at it this way.
- Scott Francis
- 2 months ago
- E Scott Menter
- 2 months ago
1) Pro camera manufacturers (and their customers) are having a hard time because end users no longer seem to want/ need quality - it seems perfectly OK today to tape a wedding using a smartphone as opposed to hiring a professional videographer. I asked one couple how they felt about jittery videos where most of the scenes are over/underexposed , color balance is off and the sound is dreadful. Not a problem, they responded, it's no worse that the selfies we send/receive each day.
2) critical path diagrams that used to be de rigeur but are being skipped today by some organizations who feel it is OK to plan/monitor/control using to-do lists only.
Since building process maps seems to be "difficult", one possible customer scenario is "why bother to map?", particularly when many workers really don't care about organizational efficiency/effectiveness.
End users of such systems are themselves already at no code but they need their IT departments to code rule sets and to interface to/from microservices.
If the users have a need for ancillary apps not on the market, they have to commission their IT or outsource to develop these.
"Citizen developers (for sure)" will amount to nothing
I'd say something about blockchain as well - but I may be biased here by my customer size - I cannot yet see the compelling case for immutable public ledgers in the enterprise. Enterprises have a gazillion reasons to lie and hide, most of the times even more so than humans - they will likely sit on the fences on this one for a while.
Isn't that a synonym for Competitors' Technologies? ;-)
A few examples (sorry @Bogdan):
AI - business process is already a model and you got a lot of data (including results) thus one can validate the model, validate its use and make adjustments.
Blockchain – a perfect multi-owners records management which allows BPM to be placed between various business partners.
Low-code – good DSLs and architecture can reduce amount of code-to-be-written (and duplicated)
AR/VR – is it a way to access your processes faster, better and cheaper? Think about GPS.
AI on process model data - yes, but it may not be that much data, plus there's algorithms that do this pretty well already in the process mining space. Of course could be improved by AI, but it's not going to get that magical. AI excels on nonlinear, nonexplicit relationships - not exactly the case with explicit process models.
Blockchain - great - do you have any examples where this has been done and could not be implemented by other means in the enterprise space, where anyway access control and encryption are a given?
Low-code - yes, for dev purposes it's clear, we invest in this everyday. But for regular non-programmers to develop fully-fledged process enterprise apps?
That's not say that these features of an (I)BPMS are useless - all to the contrary - they absolutely have the potential to enrich any BPM initiative. However, most end users don't dedicate the sufficient resources to take advantage of these technologies. Ironically, at the same time, these same users put said technologies as obligatory requirements on any RFP (which in turn motivates vendors to engage in hype cycles...).
Same observations we made with features around social BPM, process rules portals on others.
Healthcare is an example where a simple at-a-glance inspection of the patient "e-chart" gives the physician a lot of information of assistance to "what should the next intervention be"
I suppose a similar consult at the history for trouble tickets tells the support rep what kind of customer they have on the line (frequent support desk caller, many "problems" that turn out not to be problems, requests for custom features that never get authorized, etc.)
Auto-histories require NO resources to build.
Otherwise you need some orchestration.
BPM handles this for work that can be mapped plan-side.
If deviations away from plan-side are needed we move to Case (i.e. ACM/BPM) where two major needs are satisfied
1) decision support by way of consultation of the Case history
2) easy access to cross-case data history/predictive algorithms - so that users can have suggestions re options at branching points (go this way/ go that way)
If time/cost considerations overshadow, we call a CPM engine or you embed ES-EF-LS-LF calculations onto your BPM flowgraphs.
Calling an engine works much of the time (providing you can get to it and get back results). Embedding functionality that will be used only occasionally can be a major source of bloatware.
As I explained in my infrastructure protection comment a day or so ago, BPM is also good at avoiding work (alarms -> avoidance -> no need to do any work).
I can think of more humorous than serious responses to this I think there are lots of hyped tech that can interact with BPM at the edges. Or in specific spots. That's all to the good and time to get the popcorn out.
My first example would be the explosion of workflow for the masses, which some have said will create an RIP BPM tombstone. As was pointed out in the Forum discussion about this (or at least specific to Apple's acquisition of Workflow), and in Neil Ward-Dutton's blog on the subject, rather than being a disruptor for BPM, this may end up lifting the whole BPM market due to the increased visibility of workflow to the masses. It could also drive larger BPM vendors to include more user friendly features.
Another example of a highly hyped technology which some have said will kill BPM is RPA. While I definitely believe RPA has its place, and can think of many use cases where it should be used instead of some other type of solution, it is still just a subset of an overall BPM discipline, and one could argue BPM vendors should be offering an RPA solution with their overall BPM offering. I think a fairly good explanation of this can found via Nividous's open source implementation of RPA for IBM BPM. However, I just don't see RPA displacing BPM since it's usage is limited and I have not seen yet how implementations can overcome the inherit "brittle" nature of the implementation.
Of course, coming from BPM background I am going to have a BPM centric view of the world. More than likely, some of these things I believe are hype will end up actually disrupting at least some portion of BPM. I just can't predict which those are .
I smile at the comments on the no/low code movement as being over hyped. Yes as ever it is hyped but reality is that significant reduction in need to code in the business arena is coming and a few have proven. Even Bill Gates 10 years ago saw removal of coding as the holy grail of software yet his organisation fails to deliver as promised.....was that vision or hype? I think the former as a genuine belief but fact is such delivery will be very disruptive and large vendors do not promote their own demise....
So where are we in the evolution of capability to support the outside in BPM thinking? Our 20+ years research and working with early adopters using the no code approach has proven that it works yet we have been ridiculed and ignored as the industry hype and self interest has ruled. Whilst I have been encouraged by the no/low code movement much is hyped and so I do understand why this is mentioned by some as over hyped....but reality is it will be the future and lead by user needs in being supported at work.
We need to see much greater research by industry analysts to articulate just how the BPM supporting software actually works. This move will put buying power into hands of informed buyers. This is a vital change in disbursement of knowledge not driven by the over hype from big vendors which has held back progress to sort out the decades of complexity and over sold promises/hype to business.
- 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