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.
Sharing my adventures in Process World via Procesje.nl
At first glance, it looks like the answer might be
[i] yes, [/i]but in fact it’s still
[i] no. [/i]The relevant rhetorical response is:
[i]compared to what?[/i]
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
[i]one-big-BPMS[/i]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
[i]one big system, [/i]or joining everything together with
[i]one big integration platform.[/i]
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
[i]SaaS clusters[/i]- 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.
Founder at John Reynolds' Venture LLC - Creator of ¿?Trules™ for drama free decisions
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.
Ha, there you go. Excellent, And Emiel: We talk further Tuesday evening; this is *exactly* the point. Also here (my current company, their customers) this is a constant struggle... E2E is the fundamental layer for anything else. Period. I did't say you can completely control it, but hey. We are way too used to isolated container thinking that then need interfaces between them... Did I mention swimlanes? Brrr...
Refreshing application of business and economics to questions of technology, especially process technology. (I'm personally familiar with the sub-contracting part!) Especially the highlight that "huge areas of [business operations] need to be stable" is a nice counter-balance to hype around constant change.
As long as process apps are in the
[i] right context[/i]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
[i]inside a specific domain, doing an execellent job,[/i]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,
[i]you are out of control[/i]I'd say.
Do process apps make
[u]BPM[/u]more difficult to manage?
How about business?
Do process apps make
[u]business [/u]more difficult to manage?
First, what are "process apps"? I propose they are
[u]just another phrase for -- "apps"[/u].
[i]Insofar as all apps are force multipliers for some kind of work, and all work involves some sort of process, therefore [quote][u]most software has some process built-in[/u], either implicitly or explicitly. (ERP can be disaggregated into constituent data, rules, interfaces -- and processes.)[/i][/quote]
What happens when we pull processes out of ERP? Or build new standalone apps around processes?
There are two challenges concerning "process apps": (1)
[u]inter-app communications complexity[/u]and (2)
[u]loss of common process language.[/u]
[b]WRONG KIND OF COMPLEXITY[/b]-- First of all we have to connect all these standalone processes together, as several people have noted above. And we see lots of people talking about "API-as-a-service" and the "API economy".
APIs are the general case of "B2B". My experience in B2B integration (i.e. B2B Gateways for ebXML, EDI etc.) leads me to note how difficult and complex B2B and APIs can be. (A major part of B2B costs relate to the whole MDM ["master data management"] challenge.)
A focus on APIs, necessary when you have a proliferation of independent apps, necessarily escalates applications complexity. You think SAP is complex? Try building the equivalent of SAP functionality in process apps. A focus on APIs is kind of like focusing on nicely printed ledger books in the world of accounting. A ledger book or an API is the interface or representation to what's really important. Not the thing itself.
[i]And a cognitive load for no good business reason.[/i]
[b]BUSINESS TOWER OF BABEL[/b]-- In addition to the complexity issue, I suspect that we will see a growing "common process language issue". It's a certainty that any exposed processes in process apps will not be exposed in the same way. So orchestrating a portfolio of process apps to work in concert will require mastery of multiple process languages.
[i]Again, increasing cognitive load for no good business reason.[/i]
Whatever process apps are, they are a ticket to "silo city". And as Mr. Gotts implies, this seems to be a "trainwreck".
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.
As previously stated these apps will be highly domain specific.
They will be managed by a multi-tenant BPM application or something similar to a classic BPM application that supports almost instant on demand process provisioning and rapid process adaption. As ever in the process world the biggest hurdle will be integration, specifically cloud to cloud integration.
Agree with AS the right supporting architecture driven by BPM needs will readily absorb any "Process App"...whatever they are...?
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
[b]process [/b]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
[b]the rise of process apps will revolutionize the BPM systems approaches[/b]around the world.
This will happen on two levels:
1/ on an
[b]API basis[/b](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
[b]process-exchange basis[/b](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.
CEO, Co-founder, Profluo
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.
- Page :
There are no replies made for this post yet.
However, you are not allowed to reply to this post.
However, you are not allowed to reply to this post.
Join the Discussion
BPM IT BPM 2019 Process Architecture process modeling Open Source CX Business Process ACM Process Re-Use Robotic process automation skills AI customer service Business Processes Year Ahead customer experience artificial intelligence IT Department process maps Business tranformation process 2019 transformation case management RPA IBM hype cycle digital transformation Red Hat Business Process Management 2019 RPA 2019 DT Automation process mapping The Year Ahead for BPM BPM Year Ahead BPM Challenges Customer process swimlanes
Also on BPM
- Overcoming Goliath: The New Nimbleness of BPM and Workflow
- Taking Processes to the Next Level: ProcessMaker Discusses the Ever Evolving Nature of Today's Work
- Post-platform Enterprise Pattern: Faster and Cheaper Inter-Enterprise Ecosystem Business
- First Impression: ADVANTYS WorkflowGen
- Automation and Customer Experience
- A New Architecture for Automation: Neil Ward-Dutton Explains
- Does AI Change How We Deal With Information?