Exception handling from Robotics perspective

[DavidRubiano]

Hi! I'm having some thoughts about how we handle / present a Business Exception (BE) in Blue Prism.

I find that from a robotic / automation perspective. That a BE is actually an completed task in BP. The robot have done all work that is defined, tag the item with the BE tag, Exception info and then mark as Completed.

I know that using the BP template, an BE is marked as an exception. But would it be bad practice to change this to mark it as a completed item?

From reporting perspective, we could show what cases is a BE so that the business can handle those cases.

------------------------------
David Rubiano
Senior Consultant
Capgemini
Europe/Stockholm
------------------------------

[IshanMahajan]

Hi,

From my perspective, we should continue to mark BE as Exception instead of Completing them.

Human intervention should be required only for Exception cases not for Completed cases, otherwise on long term it would be hard to calculate success factor of your overall automation as you would need human to look for completed cases as well as exception cases.

i have seen developers using BEs in their automation but they forgot to use best practice and convert a BE and SE, so that is also a possibility you can come across where you would have multiple SEs but very less BEs, and bot would be responsible for all failure even though it is Business not following defined rules.

------------------------------
Ishan Mahajan
India
------------------------------

[John__Carter]

You're certainly right to consider BEs as 'not errors', and maybe you could go so far to say they are complete cases. The automation has worked the case as per the design, so I guess it's a perspective thing as to how you record and report that.

------------------------------
John Carter
Professional Services
Blue Prism
------------------------------

[IngridOlsen]

​Hi all

We use BE to indicate that the task is out of scope for the robot, and should be handled entirely by the business. From a robot perspective that task is marked ad completed since it does what we expect it to do and we have no actions to investigate the robot robustness.

Everything else is SE or SUE, and those indicate that the robot could NOT do whatever we expected it to do. The business still has to check and complete  those cases, but here the controller/developer also investigate why those SE og SUE happens, and if the robot needs to be more robust.

The business then gets a report with all cases indicatng which they need to check (BE, SE, SUE etc)

Hope this helps
Best regards
Ingrid



------------------------------
Ingrid Olsen
Configurator and proces consultant
Forca
Europe/Copenhagen
------------------------------

[NicholasZejdlik]

On the flip side, marking BEs as an Exception makes it more difficult to determine which of the failed items were due to an issue with the process.

On my team we mark the SEs as an Exception, and mark BEs as Completed, which makes it very easy to see if we need to debug or re-spy elements on a particular process. We also tag all items depending on the possible outcomes within the process, so in that way we still have a method to report on BEs.

I don't think there's a right answer to the question, since both methods have valid reasons, and it comes down to the preferences of each organization/team. I think the more important thing is to highlight the need to ensure that mechanisms exist for all outcomes so whether an SE or BE or any other kind of exception occurs, you have the means to report on it.

------------------------------
Nicholas Zejdlik
RPA Developer
------------------------------