With the proliferation of apps for individual processes, does it make the whole management aspect of BPM that much harder? If so, what is the best way to manage them?
Probably everything in one BPMs makes it easier, because then you could set up a total performance dashboard for your process landscape.
With separated apps, I think the answer lies in data.
All those apps that are used for individual processes will for sure generate data about all cases executed. That's cool within the app itself to manage those cases.
If you want to have a better view of the performance of all the processes supported by several apps, I'm thinking about something like process mining. Of course it will take some effort to prepare the data, but then it should be possible to create views on the performance of your total process landscape.
But, it's really depending on useful data that tells something about the performance of a process as a whole.
And that is again depending on making clear what 'a performing process' means in your context.
At first glance, it looks like the answer might be yes, but in fact it’s still no. The relevant rhetorical response is: compared to what?
In theory, if you have all of your process execution on a single platform that includes visibility tools, then that might make management easier, but in practice that's probably not the right comparison. That ‘proliferation of apps for individual processes’ doesn’t mean that they are moving from that notional one-big-BPMS to separate apps.
I suspect that the apps for individual processes are a response to how hard it is to use one-big-BPMS for all processes, especially the small ones. In practice, these apps are more likely to be moving process execution from spreadsheets ’n’ mail than fromone-big-BPMS. The result is not they they are getting harder to manage. If anything, the new apps are more likely to make management easier by providing better managment features than what they replace, even if they're not integrated.
Taking a step back, this is really a question about systems integration, which is the biggest and oldest IT problem in the book. If we’ve learned anything from recent decades, it's the folly of trying to make the integration problem go away by putting everything in one big system, or joining everything together with one big integration platform.
Looking forward, a more plausible solution is that those apps - and SaaS especially - can reduce the size of the integration problem by integrating with each other, potentially via integration apps like IFTTT and Zapier. Then instead of each organisation to integrate all of their custom systems, they are more likely to find themselves adopting apps that already have integrations with each other.
Perhaps this will lead to SaaS clusters- indpendent SaaS products that have more integration wtih each other than they do outside the cluster.
The rise of Process Apps, if it happens, will significantly change the conversation because those apps will be tailored to very specific domains - such as "Accounts Payable". The management of those apps won't be in abstract process terms, but in specific domain terms.
I'd expect to see the APIs exposed by those apps, along with the configuration options exposed by those apps, as the heart of the conversation - which will very pragmatically dictate the boundaries of what those apps are appropriate for.
I think this is a good thing - but it will be a big change.
Running a business used to be so simple. You hired some people, put them in offices and factories and distribution centers and they did what you asked them to.
But it has changed with the distributed workforce (gig-economy), distribution partners and distributed applications (cloud). The only thing that hasn't really changed are the end to end operational processses. Sure they have evolved. But a product company stil has to "design-build-sell-distribute"product. You stil need an end to end, heirachical map of how the business operates, even if "non-employees" are following it. Documented, not automated.
At this point some of you will stop reading because you say "21st century companies are ad-hoc, case-managed, agile, constantly changing". Bollocks. Parts of companies are very agile, but huge areas need to be stable (with continuous improvement) and regulated. And how are you going to sub-contract all this work, if you don;t have a clear view what it is you want done?
Charles Handy (UK business guru/philosopher) back in 1994 prediced the "doughnut organisation". Small centre core and everything else is subscontracted. Just recently at a Fortune Global Leaders Summit, John Chambers, ex-Cisco CEO predicted that a company would be 2 people - a CEO and CIO and everyone else wold be sub-contracted. A radical thought, but you can see the balance of employees to contractors changing.
53 MILLION people in the US are in the gig-economy. i.e. they are sub-contractors to a larger company
This change in business model is what is making the business bit of "BPM" hard to manage. Low-code apps for individual processes is making the IT architecture a train-wreck and the IT bit of "BPM" hard to manage.
Interestingly, I believe these fundamental changes in business will actually drive a resurgence in BPM (and the purchase of software).
Change drives the need for BPM.
As long as process apps are in the right context the answer is not really... So, first you need to understand (be in control of) the context in the first place.
Example: When my personal process apps are executing inside a specific domain, doing an execellent job, and don't need to interact with anything outside that domain, I'd say it's manageable. But to me, as a system thinker, this sounds pretty weird, as you cannot foresee the butterfly effect here... So now the answer would be yes...
That said: You need to have insight in the total and decide if stuff like process apps (but also ashtrays and whiteboard markers) do contribute to the whole.And as soon as you cannot tell, or better, understand and justify if a process app contributes to the whole, you are out of control I'd say.
Do process apps make BPM more difficult to manage?
How about business?
Do process apps make business more difficult to manage?
First, what are "process apps"? I propose they are just another phrase for -- "apps".
Insofar as all apps are force multipliers for some kind of work, and all work involves some sort of process, therefore most software has some process built-in, either implicitly or explicitly. (ERP can be disaggregated into constituent data, rules, interfaces -- and processes.)
Not at all unexpected that within a large corporation different projects/departments would be using different BPMs'.
Where things become problematic is if you have a knowledgeworker contributing to two different Case environments.
i.e . they cannot easily prioritize their work because some tasks are in one environment and some in a different environment.
“apps for individual processes” – friend or foe ? Enabler for your business or an obstacle for it? As usual, all depends on your architecture.
Ideally, your architecture is done correctly (synergy between digital, BPM-suite tool, blockchain for a better security, disconnected work of mobile devices, etc.) to allow that any process-centric solution is automagically being an app as well.
In the absence of architectural guidance each of your process app is developed by different subcontractors with their own choice thus making the IT support and integration are nightmare.
Every business app in this world supports a business process. Whether end-to-end or fragment, domain-specific or generic, it still supports a business process. And it has done so ever since computers were used in business.
Now, what is a process app? Is it an app that uses a BPMS framework, that uses BPMN as its underlying execution semantic? If yes, then my answer is that the rise of process apps will revolutionize the BPM systems approaches around the world.
This will happen on two levels:
1/ on an API basis (as per John Reynold's assertions above) - process apps will initially communicate on a basic level via API interfaces. This will remain just a "cool" territory, as IFTTT or Zapier never went beyond this. The API economy, I have stated before, is tricky and treacherous.
2/ on a process-exchange basis (full architectural compatibility, as per Alex Samarin's assertion above). But this requires vendor maturity and commitment towards standards adoption. There are good signs about this (see OMG's MIWG), but the white space is still huge and the difference between vendor intent and vendor ability/willingness is significant.
If we subscribe to the idea that processes transform inputs to outputs, it follows that at the lowest level in a node/arc flowgraph, each "step" is a "process app".
Some of the steps are nothing more than merge points but most steps need to collect data as part of attesting to the completion of steps and recording data that will be needed downsream from such steps.
To this end, there will typically be a form at each step and many times the form will have calculation rules.
Seems to me the step is an "app".
Moving along, I don't see a need to make a special case for a step that has a link to a remote engine that accepts data from the step and delivers data back to the step.
We know from black box theory that it is always more difficult to validate processors where you only have access to what goes into the processor and what comes out but a BPM practitioner can impose pre-conditions and post-conditions to decrease the risk of unwanted actions.
I don't see the rise of process apps making BPM either easier or more difficult.