BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 10 May 2018
  5.  Subscribe via email
A point Nathaniel Palmer brought up in his keynote at bpmNEXT, do you think BPM will be the framework for how we manage and control robots?
Max Young
Blog Writer
Accepted Answer Pending Moderation
No. BPM doesn't take it's own medicine* when it comes to describing user tasks: and that's what Robots do: the tasks of users. The ultimate solution will embrace BPM ideals, but it won't be BPM as it is now.

FYI, if you want to hear some *really* smart people(and me) discuss exactly this topic just a few weeks ago, here's the video on the conversation.

https://youtu.be/RG419dvxa3o


* BPM's own medicine: BPM doesn't have a visual metaphor for detailed user Tasks.
References
  1. http://www.capbpm.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
Yes of course it will or should.....data in and out needs to be recognised and reliable with a Robot just a task doer! I would go further in that creation of a robot needs to be understood and transparent and the BPM discipline has a role to play...just look at VW fiasco...?

As for RPA a good BPM supporting Platform should deliver significant automation indeed if not you using the wrong software platform!
Comment
  1. Max Young
  2. 7 months ago
  3. #5324
I agree with should. Will is a different matter....
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
Perhaps. BPM-as-discipline creates probably the best kind of management/governance framework that organisations can use to understand the context for RPA implementations, direct RPA investments, monitor the results of automated work and drive improvements. On the other hand, today's BPM platforms (or DPA platforms, or whatever we want to call them) may well be completely excluded from new automation platforms agglomerating around RPA tools.
The extent to which this happens will depend on how smart the BPM/DPA vendors are at expressly addressing the interests and needs of organisations that want to start by automating individual tasks, but then grow curious about how they can perhaps drive more varied automation approaches more broadly across business processes. It'll also depend on the RPA vendors themselves - whether they grow fast and then build or acquire their own workflow technologies, or whether (as now) they maintain partnerships with existing players like Oracle, IBM, Appian...
Comment
I just realised that when you said "robots", Peter, I immediately assumed you meant RPA..! My bad.
I don't think the basic argument changes, though.
  1. John Morris
  2. 7 months ago
  3. #5322
Neil, I noted your focus on RPA -- which then caused me to think about RPA-as-Robot. As you say "basic argument doesn't change". And in fact helps understand even. A physical robot and a software robot (and we can extend the definition to autonomous agents etc., even) are all robots. Which need use cases, business cases, management and governance.
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Max Young
Blog Writer
Accepted Answer Pending Moderation
Neil Ward-Dutton : Are you still evil about this topic? :)

More seriously, I think you're 100% right the the right solution will embrace BPM ideals(or, as you would say, frameworks for understanding the context of RPA, the ROI of same, etc), and I hope that BPM offers a spec or an extension that will be used to describe the benefits of RPA.

But I'm not optimistic that it will do so fast enough.

We've talked about this before, but I think BPM would have to embrace it's own ideals about power of pictures to tell a story(which it can do), but also embrace task-level modeling(which I think turn off a lot the true believers). Practically, I don't that the market will wait. I hope I'm wrong.
References
  1. http://www.capbpm.com
Comment
  1. David Chassels
  2. 7 months ago
  3. #5321
Actually a task driven model is very effective and readily welcome by business as it represents the actual build and deployed application. You are right some do not welcome ....in IT.....!
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
At a high level RPA will fall into the SOA, ESB type frameworks and as applicable be within BPM/DPA frameworks. However, RPA is a specialty and its construct will have its own framework for management and control. As robots perform work, that work may or may not be in the confines of a BPM/DPA. For example, robots that may perform IT operational functions like file movement, restarting machines, or triggering an IoT device read... are not necessarily a BPM framework governed item. It might be called within the BPM/DPA framework. On the other hand, a robot performing a swivel chair or populating customer data in several systems as the result of a process "onboarding a wealth management client" is a BPM governed event. In that case RPA is an interface element to the BPM framework and governed by the DPA. Overall, BPM/DPA frameworks should incorporate RPA but the management and control of all RPA is not entirely BPM/DPA frameworks. However, as I mentioned in another BPM Today post, I believe BPMN and the BPM framework(s) are due for an overhaul thus this current question may be answered such that the new BPM frameworks morph into something more grand and define, manage and in control of all RPA.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
Wow Stuart spot on and what you articulate is exactly what we created with years of R&D and learning with early adopters. I watched that video and now realize what a mess exists in the BPMN arena. Interesting you recognise power of SOA what effectively we created 'in a box' orchestrating all required data and linking to people their roles and state. It is a complete new architecture which actually delivers all but of course not how the industry has evolved where big vendors acquire multiple components and try to merge ....?
The levels of automation are indeed high such as the adaptive UI entering data only once easy escalation real time reports on activity time driven action automation easy build of a configurator to result in desired outcomes even intelligent processes using past decisions and more will evolve ....
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
“manage and control?” I think so. I can imagine that some tasks will be assigned to robots and such tasks will have a robot’s program to be executed. (Just omit “small” details as queues, DSL, robot specialisation, error-handling, time-out, idempotention, etc.). A robot gets a task, the robot downloads a program for this task, the robot executes this program, the robot completes the task and the robot reboots itself.

Easy, it worked even 20 years ago.
https://2.bp.blogspot.com/-sA3ApJIW3Gs/WvRrMBFEosI/AAAAAAAAKGg/J_OaTqtqMy0z0xYINfki2GTu9IrNRSzfwCLcBGAs/s320/ro-small.PNG

Thanks,
AS
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
Robots broadcast advisories or initiate actions in three (3) ways

1 internal rules (i.e. continuous or cycle testing of data generated by sensors, uploading of exceptions/actions to a data log),
2. human action (a user changes ‘offline’ to ‘online’, inputs some processing parameters and clicks on Submit)
3. messages that reach out to robots via workflow engines as “system” process steps become current (includes structured processes comprising multiple linked steps and ad hoc processes of one step each).

BPM will NOT, should NOT be the framework for how we manage and control robots.

The framework of choice will remain a workflow/workload platform where BPM is THE core component.
References
  1. https://kwkeirstead.wordpress.com/
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
Yes, to the question as to whether BPM (technology and methodology) should be the framework for "managing and controlling robots".

Why? Because BPM is "THE technology of the work of business", by definition. Only in BPM is work a first-class citizen of that technology. All other technologies, in the extreme for example with code, enable the laborious creation of tools for automating work. With BPM, you start out understanding the work itself. And if you add a robot to your work process, you'll be able to define what the robot needs as input, and what the robot will deliver as output. And where that output should go etc. etc. BPM is the technical context of the work of robots.

Why BPM Is Unique & Important: Part 1 - One Technology of Work

As has been pointed out above, BPM does not (yet, and perhaps ever) have specific technological artefacts, languages and protocols for robot control. But that is a separate domain. In the context of the work of an organization itself, BPM is the technology for organizing that work. And according to use cases and business cases, managers may deem it a good idea to drop in robots for the purpose of automating some or all of any given work process. These robots can be hardware, software, RPA, autonomous agents, or what have you.

What is the alternative? Managing the context of the work of robots where that context is in some sense hard-coded and/or the work is not a first-class citizen of your context. Sure it might work. But non-BPM robot work context management will ultimately be more expensive, less flexible, less rich, less reliable and less manageable.
Comment
In Active Assisted Living (helping people with limitations, e.g. elderly people), in addition to assistive robots there are also assistive animals (e.g. dogs). Can BPM manage and control animals?
  1. Max Young
  2. 7 months ago
  3. #5325
@Dr. Samarin: perhaps, to the same degree that treats and verbal commands, can.
  1. John Morris
  2. 7 months ago
  3. #5326
Now we are into the world of linguistics and even psychology. "At the work-face" task management modeling and tools are (as pointed out above) a layer or two below what BPM covers. But insofar as helper animals perform work, then BPM is appropriate to helping organize that work. That help however might be limited to low-transaction volume meta work (licensing, vaccinations etc.). Once the dog is in place, it's pretty autonomous. :)
  1. David Chassels
  2. 7 months ago
  3. #5327
There are formal and informal process the later may only have an outcome report...the dog has been introduced may have occasional report all is well..or not... Maybe a time line can trigger enquiries as to how dog is doing!
Karl Walter Keirstead
@john.. I subscribe to BPM as "THE technology of the work of business" so. yes, for engaging robotic action, or at least trying to engage robotic action (b/c the robot, with its own set of rules/actions, may not be able to or want to respond to engage specific actions).

What is important (same as in Cases when only Case Managers close Cases), is that human ALWAYS have absolute control over "OFF" and in areas of critical actions, absolute control over "ON" I.e. never engage without first checking with an authoritative human.

Outside of this, as Max correctly points out, robots "march to their own tune" - we don't want BPM or platforms where BPM is core to be an in-line bottleneck.
  1. John Morris
  2. 7 months ago
  3. #5334
@Walter -- In turn I agree with you. Humans must be in control. And this isn't only a nod to Isaac Asimov ("Three Rules of Robotics") but we've seen reports of robot/human mishaps already, in part because of the "off switch problem". Being in control of technology has been a priority for as long as technology has been around. My Dad used to say "you boss it, don't let it boss you". And on the factory floor, it's a matter of life and death sometimes.

That said, we can also agree I suspect that there is "work-in-the-small" (e.g. specific workbench tasks) and "work-in-the-large" (e.g. insurance underwriting processes). And the modeling languages are different. BPMN (or what have you) for the latter. And specific robot control task languages for the robot-assisted bench work. And an interface between them.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
As an utmost certainty, what is considered BPM as a software solution today will not be used to control physical robots. One of the many reasons is that modern robotics use a tactile feedback technique with lots of realtime sensor inputs. BPM could be used to instruct already programmed robots to perform a sequence of such pre-programmed tasks. But as such robotics orchestration software is widespread and much more powerful than BPM why would anyone want to make a step back? More autonomous robots won't at all be able to use tasks sequences but they will need to react to recognised patterns. The 'assisted living' robots are extremely limited and DO NOT use process flows while they can only work in very well defined environments and conditions. Autonomous driving today uses a completely shortsighted technique where recognised patterns trigger rules or flows of tasks with truly unusable results. Ever tried a Tesla? AI is all hype and BPM for robotics is just farfetched ...
Comment
Agree that "recognized patterns" is a silly approach.

Trains have been around for 100+ years. It does not matter that the coupling be physical between cars. All we need for long distance travel is a GPS destination and a magnetic strip on the middle line of the highway.

That would solve the problem. Who needs to "pass" when everyone is travelling at the same speed.?

Once you punch in your exit ramps you can manually navigate as usual when you get off the freeway.
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
The BPM framework, understanding it as an accumulation of annotations, proven design and implementation practices, could work to connect different RPA implementations, and maybe even physical robotic applications, creating an overarching business process but certainly not as a "language" to define, design, publish and improve upon RPA's themselves.
If you closely analyze the workings of an RPA, you'll usually find automations on an application integration level. That may or may not entail data transformation or analytics. In either case, UML/BPMN, the creation of a BPM CoE, UX definitions and so forth (something you would encounter typically as part of a BPM framework), would be ill- or only partially fitting to define an RPA solution. DMN could work to a certain degree and of course "micro-technical" design practices, defining the "if-then-elses" of a data input error, connection timeouts and data driven routing. As stated in the previous topic, I don't think RPA needs its own annotation nor would it be wise to force a BPM framework on it. For the most part, common application design practices and documents should suffice.
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
This is hilarious. As near as I can tell, RPA or Robotic Process Automation, is simply a buzzword for plain old automation. The notion of "software robots" lies at the heart of RPA and software robots are computer programs for manipulating data/information. More years ago than I care to remember, I made a really good living automating much of the work of insurance claims examiners, financial aid assistants, and people who handled claims for lost or stolen travelers checks. What's different about RPA? Nothing as far as I can tell. The late Geary Rummler used to say, "If you put a good person in a bad system, the system will win every time." To paraphrase Geary, "If you put a good robot in a bad process, the process will win every time." For me, the key issue isn't robots (software or hardware), or automation, or process; instead, it is the definition of results to be achieved and then identifying the most effective and efficient means for their achievement. People, robots, software, or paper and pencil, might all come into play; it all depends on the results and the means of their achievement. That's the framework that should govern.
References
  1. http://www.nickols.us
Comment
"it is the definition of results to be achieved and then identifying the most effective and efficient means for their achievement. " - this is clear, e.g. a particular systems approach is used to architect "Active Assisted Living" system domain.
  1. John Morris
  2. 7 months ago
  3. #5329
While there's truth in your comment, there's a direct line from screen scraping, especially green screen screen scraping, to today's RPA. This puts us right away in a very distinct sub-set of all the things one can automate.
  1. David Chassels
  2. 7 months ago
  3. #5330
Agree about the "RPA" tag...another over hyped one which is misleading with the "R"!
  1. more than a month ago
  2. BPM Discussions
  3. # 12
Accepted Answer Pending Moderation
Robotics is the most business focused environment in the world. Why? Because the only thing robots know and do is business, simply by virtue of their design and definition. Just imagine a robot walking along a street or watching TV for a leisure. It is an oxymoron. The ability to make something outside of business imperative is most important and fundamental ability distinguishing humans from machines.

Therefore, BPM language is the most natural and efficient language to interact with robots. Intentionally or arbitrarily, the world of robots has already shaped as a BPM world from very beginning. It is only matter of terminology to recognize it as such or devise another dedicated synonym. Of course, BPM notations tailored for robotic automation have their own specifics. But it is mere an issue of relevant notation, rather than principal applicability.

Management and control of robots is an exclusive field where BPM blossoms in its uncompromising clearness and unrivaled shine of perfection.

https://caseagile.com/wp-content/uploads/Robot_BPM.jpg
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 13
  • Page :
  • 1


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