BPM.com
  1. Peter Schooff
  2. BPM Discussions
  3. Tuesday, January 31 2017, 09:46 AM
  4.  Subscribe via email
A question raised by Manish Nepal on this blog where he writes: "Will the next big innovations in BPM come from a mobile experience? Or is a mobile-first BPM app simply a pipe dream?" What do you think?
Vasileios Kospanos Accepted Answer Pending Moderation
I could easily answer NO for both however the questions are open for various interpretations. YES, mobility IS important for BPM and innovation in it - however more technologies are surfacing that are actually a better fit for BPM. Off the top of my head, Robotic Automation, Machine Learning, Natural Language Processing & Natural Language Generation are just a few other technologies - equally important to mobility, for the future of BPM innovation.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
David Chassels Accepted Answer Pending Moderation
Not really mobile is just another user interface which will help efficiency and may support new ways to work but the basics remain the same.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
John Reynolds Accepted Answer Pending Moderation
It will help in the long run by finally breaking the coupling between the process definition and the UX.
Workers and customers need to interact with processes. They need to interact from many devices, and they need to interact whether or not they're connected to a network.

That's the UX participants need. Cross platform. Connected or disconnected. Big screen, small screen, no screen.

Mobile first is a start, but not focused on the bigger picture.
Proprietor and Product Craftsman at John Reynolds' Venture LLC
Comment
Careful! On the one hand, yes, you want to be able to drive your application through a huge variety of interfaces. But the more disconnected your UI is from your engine, the fewer options you'll have for useful interactions between the two. The offline UX is going to be different than the online, for example, unless you offer no interactions through the online UI that wouldn't be available offline.
Layering is critical (note to Microsoft: I'll explain later what "layering" means). But it does introduce the challenge of creating interfaces that are standard enough to be re-used but flexible enough to support more than just the least common denominator. (Note to Microsoft: I'll explain later what "standard" means.)
  1. E Scott Menter
  2. 8 months ago
I don't equate "decoupling" with "disconnecting" (and I'd assume what John said above is along the same lines).
To me, decoupling means that you are able to evolve/upgrade the two components separately (while still connected via same logic / API / integration layer!). Hardly a feature of monolith solutions.
  1. Bogdan Nafornita
  2. 8 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 3
E Scott Menter Accepted Answer Pending Moderation
Blog Writer
Mobile isn't, per se, a BPM concept at all. But, as BPM workflows morph into BPM-driven digital applications, user experience (UX) as a whole (including mobile UX) has become increasingly significant. Indeed, things have reached a point at which a number of products offer little more than very attractive front-ends glued onto surprisingly weak process/application engines.

(College applicants, take note: Engineers make Ferrari engines and stick them in VW Microbus chassis. Marketers stuff a bunch of ill-fitting junkyard debris under the hood of a freshly-painted Pantera with gold leaf inlay and leather seats made from pampered Kobe cattle. Guess which one makes more money?)

Not that I'm bitter about that or anything.

The painful truth is, however, that UX may indeed be more important than core capabilities. When you were building applications for your back office, they could be as ugly and nonintuitive as a tax form; after all, those folks were stuck using whatever you gave them.

But when planning customer-facing digital applications, the UX stakes immediately skyrocket. Revenue depends on adoption, and adoption depends on UX. Your engine lacks fancy tools for testing, or rule chaining, or event correlation? Well, that's IT's problem. And hey, if adoption rises, and the dollars, yen, Euros, pounds, or shkalim are rolling in, we can just hire more IT folks to make the thing even slicker, right?

Problem solved.
http://www.bplogix.com/images/icon-x-medium.png Scott
Comment
Yikes! "Surprisingly weak process/application engines".
There are so many implications and insights here . . . note especially the possibility of "market failure". Efficient markets should drive good product engineering. In the case of BPM software technology, good engineering would run all the way from process engine to surface (UX) and back etc. Especially in the context of "customer journeys" and "customer experience", both of which are ideally built on business process technology, one would think that an efficient market would drive development of ever better process engines. Market failure then is the failure to do so, despite amazing academic and engineering work apparently not fully exploited (and with acknowledgement of progress from BPEL days).
One could also draw the conclusion from your comment that the "process engine is not a commodity", claims to the contrary notwithstanding.
This could be a question for the Forum -- are there differences between process engines, and what are the implications?
  1. John Morris
  2. 8 months ago
@Walter, you've captured the reality of what a well-managed business process programme should look like. The reference to process mining is a hint too that top-down (i.e. BPMN-specified processes etc.) situations likely don't capture the messy facts on the ground.
Let's return though for a moment to the engine itself. The market may think of the engine as a commodity, which is to say that the functionality one expects from a BPM engine is not really differentiated from vendor to vendor. The engineering reality however, built on continuing academic research, is different. I think this is what @Scott is referring.
This is not just "engineering purism" -- the implications are very significant.
Either you can "think-draw-work" or you can't.
Currently the neophyte business analyst learning a BPM tool for the first time runs into engine-based restrictions when building any kind of complex business process environment -- i.e. an environment that is more reflective of reality. The 80% of simple patterns that are easy to build are your commodity patterns; the last 20% which are more difficult to build are where you differentiate -- and where you get your margins.
From as sales and marketing perspective understanding the potential of better engines could be "liberating". It would be nice if the response to using a new BPM tool is more "delight and enthusiasm" and less of "this is hard, I'm proud of mastering such difficult engineering and, we didn't deliver on our objectives yet". That tail should not wag the dog. : )
  1. John Morris
  2. 8 months ago

@John . .

Sure, we could debate differences across process engines but the role of processing engines is well known, possibly a commodity in terms of function but probably not in terms of implementation.

We expect steps to post as per flow graph logic, to the attention of the right class of user, with instructions (if needed), with context/situation-appropriate data collection forms.

We want the forms to be populated by data collected upstream to each step that is being posted, with rules at-the-ready, so that the user does not actually get to the step if things are not right.

Then, more rules that operate on data being added, edited or deleted, followed by exit from the step on commit only if things look good after all of this.

Do you agree that reasonable expectation is all of this can and should take place in the background (i.e "orchestration from background BPM")?

My take is differences at the UX in the run-time RT environment would make for more interesting discussion and have more impact on operational efficiency and effectiveness, unless we are talking about end-to-end highly automated processes.

For 95/5% to 5/95% structured/unstructured work, steps simply post at the time they should, based on process logic, or they are held back for reason of lack of data.

For the steps that do post, we have three levels of management that impact outcomes

a) users micro-scheduling steps
b) users engaging/suspending/re-engaging steps
c) supervisory leveling and balancing of steps across users.

Try data mining under the scenario of each user working on 20-30 Cases per day (several or many different process templates relating to individual patients, claims, orders) in between meetings, phone calls etc and the conclusion is likely to be that the sum of wait times between steps can very easily account for more of total processing time than the sum of step performance times.

The quality of interventions is likely to vary as well (too many in/outs require that the user experience "S" curve each time leaving/returning).

So, for me, in evaluating RT environments, we need a motion time study on users at in trays and calendars - we want to make sure they reach the conclusion that it's easier when they log into the RT environment to get steps and record progress/commit than to not log in.
  1. Karl Walter Keirstead
  2. 8 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Karl Walter Keirstead Accepted Answer Pending Moderation
Mobile e.g. globalstar, irridium, inmarsat is an essential service for international infrastructure protection (US $5K to $7.5K per year per phone for 500 hours of connect time). The larger the incident, the more likely internet etc links will be overloaded or off the air.

Mobile allows a degree of access to command/control center Case incident detection/avoidance/management systems where process template incidents are receiving orchestration from BPM.

Trying to install an executable that encapsulates the functionality of 750,000 lines of source code (run time side only) onto a smartphone is a challenge.

Our approach has been to use embedded CEM for outreach/inreach to/from a portal when an internet connection is available (using smartphones)
References
  1. http://www.kwkeirstead.wordpress.com
Comment
The qualification "Mobile allows a degree of access" is that for perimeter CIR the volume of data picked up by face recognition, surveillance video, buried cable sensors, radar sensors, fence sensors, and, now, fleet micro drone locator/jammers is very high.
  1. Karl Walter Keirstead
  2. 8 months ago
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Emiel Kelly Accepted Answer Pending Moderation
Mobile and BPM? Wasn't that a thing in 2011?

Now it is "any place, any time, any way"

You all know I am a Chief Financial officer. Because of chip in my arm, my processes always know where I am.

So last weekend I was on a city trip with my friends. We were having a drink in a pub when suddenly the music stopped and a little robotic voice came from the speakers "Emiel, your assistance is needed with an invoice" I replied "show me". I didn't have my phone with me, but the phone of my friend started to buzz and showed me the invoice details.

I took a look and said "I approve payment". But because of security reasons I have to approve that with my finger prints. So I picked up my pint of beer. 1 second later the music stopped again and the robotic voice says "Emiel, Invoice has been paid. Enjoy your beer"
Sharing my adventures in Process World via Procesje.nl
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Dr Alexander Samarin Accepted Answer Pending Moderation
Mobile in BPM is a typical distributed computing problem – what functionality to be executed in a mobile node and what functionality to be executed in a server node. Any human task execution, inbox, some stats, etc. are perfect for mobile nodes. Thus a set of standard API for BPM-suite tools will be very useful.

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
John Morris Accepted Answer Pending Moderation
Customer journey (and indeed any "journey" in any department), the realization of lots of engineering work and business analysis, has been a very hot topic in business software for a few years.

BPM should be the platform for any customer journey programme, for all the obvious reasons. And at the same time, anytime, anywhere, any work mobile is also a key part of that customer journey programme.

So I would say it's not about "mobile BPM" (who really cares about the generic idea) but "mobile-enabled journey-on-BPM" (open for business and ready to go to work). And insofar as "journey" is not the only work pattern, one can substitute other work patterns in the equation too.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Boris Zinchenko Accepted Answer Pending Moderation
Mobile experience is one of the most important factors, which incredibly extended BPM scope. Mobile devices have broken traditional BPM borders and made process actors mobile in literal sense enabling them to go outside of traditional office environments and desktops. This is even truer for mobile AI business units emerging with IoT. Mobile capabilities merge BPM with real world where everybody can view and ‘sense’ it outside of traditional computer environments. No doubt, all future development of BPM will be closely related with mobile experience.

It is hard to tell, if stationary (not mobile) environments and devices should still be considered. On a client side, a border between notebook / tablet / phone / gadget becomes increasingly vague, while all these are ultimately mobile devices. Desktop workstations are gradually squeezing into narrow technology niches. Server environments rapidly move into distributed clouds. It is hard to tell, if there will remain anything isolated from mobile experience in very near future. Surely, it will crucially impact BPM, which is aimed to govern and orchestrate this new mobile reality.

Please see below a summary on usage share of operating systems, which gives an approximate view on current distribution of mobile platforms worldwide.

https://upload.wikimedia.org/wikipedia/en/thumb/1/17/StatCounter_OS_Worldwide_December_2016_map.png/800px-StatCounter_OS_Worldwide_December_2016_map.png
References
  1. https://en.wikipedia.org/wiki/Usage_share_of_operating_systems
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 9
  • Page :
  • 1


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