I don't know that I'd characterize the processes as "unstable", but they will certainly have to be flexible.
We're already begining to find the concept of implementing and deploying a truly end-to-end process is somewhat quaint given the pace of change within organizations and their partner ecosystems. The challenge has gone from optimizing one process to optimizing a swarm of collaborating processes. Should be a lot of fun!
Gartner's statement implies that customer needs will violently shift every second and this will trigger some magic flexible design of business processes done by ubiquitous citizen developers (because I don't think there will ever be such a large swath of BPM consultants or zero-code platforms available to keep 70% of processes in a deliberately unstable state!).
I think these guys are getting a little bit carried away by the pseudo-disruptive culture in certain areas of certain tech domains within certain territories of certain countries.
I don't think the customer needs are changing at such a blistering pace - it's just that, due to mobile computing, we've massively lowered our attention threshold and we believe that everything we read is new.
Other than that, I agree with John Reynolds - we will witness far more choreography among swarms of processes - and that's enough instability to keep this industry humming for the foreseeable future.
“Truth changes as men change, and when truth becomes stable men will become dead, and the insect and the fire and the flood will become truth.”
― Charles Bukowski
What is stability? Isn't it another word for death? If you are not changing your processes, then you are not learning. If you are not learning, you are not competing. If you are not competing, you are dying.
The 70% figure is an arbitrary estimation that matches what the paying audience wants to hear. The whole point of specialized BPM technology is to give you the ability to be agile, to change, in the face of a changing world. I would say all processes are unstable.
So, yes, plan for at least 70% of your business processes to be unstable. Or else you are dead.
Small snippets of process to deliver regulation or best practice joined together with human adjudicated decisions is the present not the future. Indeed I would suggest it was already the present when people started getting excited about 'case management' (Stands back)
But I do enjoy the pseudo-science of 70%. Combining that with the language of hyper-disruption must have felt really 'cool'.
To have any meaning beyond rhetoric, "stable" has to refer to systems theory or math.
Specifically a system is stable in a domain of behaviour if it is resilient given a bounded range of inputs.
So, how exactly is an unstable system a desirable goal?
Either managers "manage" and get paid for it, or they should give up. The fact that "reality is rich" and "complex" is no reason to abandon hope in the rational.
The construction of so-called unstable systems seems like some kind of magical thinking. (I'd be delighted to learn how I'm wrong about this and how the idea actually makes formal sense!)
The Gartner article is disappointing as it conflates different levels of systems (tactical versus organization-wide) and indulges (as noted above) in hype.
And then there's the whole fetishization of "agility" and "adaptation". It's OK to be agile "at the edge". But it is impossible for an entire organization to be agile, if that means giving up identity.
Swarms of insects represent successful genetic adaptations. But the evolutionary risk for individual agents is very high, as is shown by the death rate of Fortune 1000 corporations over the past generation. Either you maintain your identity and make it work -- i.e. eschew agility -- or embrace the evolutionary risk of the individual insect.
Whilst we'd all love to think that companies can be agile and react to change, but day to day evidence interacting with companies and government departments, shows that they can't even get their basic processes straight. The concept of an end to end process is important as it gives some employee alignment. It is at the lower levels that the agility can and should occur.
This is underlined in the same Gartner report is "Through 2017, insufficient business process management (BPM) maturity will prevent 80 percent of organizations from achieving the desired business outcomes from their digital business strategies."
I try to interpret the cited management-consulting viewpoint via an architecture viewpoint.
Instead of making business processes unstable (thus reactive) to serve diverse customers, companies have to have a solid Corporate Unified Business Execution (CUBE) platform to provide an individual process for each customer.
Of course, such an individual process is based on a rather generic process template to produce a rather unexpected process instance. Such individual processes look very “unstable” for an external observer, e.g. a management consultant.
Essential business components of such a platform (in addition to technical components depicted in ref1) are:
By the way, John’s problem with end-to-end processes is resolved by this approach as well (see ref4).
Re "70%" I think that basis for this value came from an observation that
Thus 2/3 of customer demands are “unstable” processes.
Re “stability” – stability is good (e.g. being stable is much better than being optimal) and stability is mandatory to be agile (you can control the evolution of the system).
Only Gartner could use "unstable" to confuse description of processes....! Of course customer facing process must be adaptive to change as required to keep customers happy and engaged. They will evolve to be dynamic recognising the customer history and even incorporate intelligence but unstable...? Well maybe Gartner have no confidence in their vendors' capabilities? Do they even understand how digital software can actually work to deliver stability yet flexibility supporting business operations?
As many commenters have pointed out 'unstable' is probably a poor choice of words. Having said that, the ability to rapidly iterate on processes is becoming increasingly important. There are two reasons for this.
Interestingly, both these are hallmarks of the lean approach. So, it seems that applying lean principles to BPM is an interesting avenue to explore.
The main impediments to Lean BPM are the long lead times in defining, deploying and modifying processes. These long lead times in turn are due to the fact the individuals in the best position to define and drive the processes (i.e. the actual business user/knowledge worker) are not the same individuals that are able to use the BPM tools.
Some will refute this last point. But how many "actual business users" do you know that use BPM tools to define processes? "Actual Business Users" will use email, document sharing, task management tools and of course apps to run "processes". Even ACM is used by a tiny fraction of business users compared to say Project Management Tools. Based on the success and wide use of these "actual business user" tools it seems to me that a Lean BPM approach unambiguously geared towards "actual business users" is necessary and feasible.
I have linked to some of my thoughts on what the principles of a Lean BPM system would be. Any feedback would be appreciated!
I agree with Keith that stability can be a precursor to death of a process.
A process that sees change is not "unstable" - each change presumably has an ROI where the investment has time to generate cited benefits.
David Letterman might say " pick another word, any word"