Tag: ML

A Well-Mixed Cocktail: Blending Decision and RPA Technologies in 1st Gen Design Patterns, with Lloyd Dugan of Serco

Lloyd showed a scenario of using decision management to determine if a step could be done by RPA or a human operator, then modeling the RPA “operator” as a role (performer) for a specific task and dynamically assigning work – this is instead of refactoring the BPMS process to include specific RPA robot service tasks. This is shown from an actual case study that uses Sapiens for decision management and Appian for case/process management, with Kapow for RPA. The focus here is on the work assignment decisioning, since the real-world scenario is managing work for thousands of heads-down users, and the redirection of work to RPA can have huge overall cost savings and efficiency improvement even for small tasks such as logging in to the multiple systems required for a user to do work. The RPA flow was created, in part, via the procedural documentation wiki that is provided to train and guide users, and if the robot can’t work a task through to completion then it is passed off to a human operator. The “demo” was actually a pre-recorded screen video, so more like a presentation with a few dynamic bits, but gave an insight into how DM and RPA can be added to an existing complex process in a BPMS to improve efficiency and intelligence. Using this method, work can gradually be carved off and performed by robots (either completely or partially) without significantly refactoring the BPMS process for specific robot tasks.

Emergent Synthetic Process, with Keith Swenson of Fujitsu

Keith’s demo is based on the premise that although business processes can appear to be simple on the surface when you look at that original clean model, the reality is considerably messier. Instead of predefining a process and forcing workers to follow that in order, he shows defining service descriptions as tasks with their required participants and predecessor tasks. From that, processes can be synthesized at any point during execution that meet the requirements of the remaining tasks; this means that any given process instance may have the tasks in a different order and still be compliant. He showed a use case of a travel authorization process from within Fujitsu, where a travel request automatically generates an initial process – all processes are a straight-through series of steps – but any changes to the parameters of the request may modify the model. This is all based on satisfying the conditions defined by the dependency graph (e.g., departmental manager requires that the manager approve before they can approve it), starting with the end point and chaining backwards through the graph to create the series of steps that have to be performed. Different divisions had different rules around their processes, specifically the Mexico group did not have departmental levels so did not have one of the levels of approval. Adding a step to a process is a matter of adding it as a prerequisite for another task; the new step will then be added to the process and the underlying dependency graph. As an instance executes, the completed tasks become fixed as history but the future tasks can change if there are changes to the tasks dependencies or participants. This methodology allows multiple stakeholders to define and change service descriptions without having a single process owner controlling the end-to-end process orchestration, and have new and in-flight processes generate the optimal path forward.

Automating Human-Centric Processes with Machine Learning, with Kris Verlaenen of Red Hat

Kris demonstrated working towards an automated process using machine learning (random forest model) in incremental small steps: first, augmenting data, then recommending the next step, and finally learning from what happened in order to potentially automate a task. The scenario was provisioning a new laptop inside an organization through their IT department, including approval, ordering and deployment to the employee. He started with the initial manual process for the first part of this – order by employee, quote provided by vendor, and approval by manager – and looked at  how ML could monitor this process over many execution instances, then start providing recommendations to the manager on whether to approve a purchase or not based on parameters such as the requester and the laptop brand. Very consistent history will result in high confidence levels of the recommendation, although more realistic history may have lower confidence levels; the manager can be presented with the confidence level and the parameters on which that was based along with the recommendation itself. In case management scenarios with dynamic task creation, the ML can also make recommendations about creating tasks at a certain stage, such as creating a new task to notify the legal department when the employee is in a certain country. Eventually, this can make recommendations about how to change the initial process/case model to encode that knowledge as new rules and activities, such as adding ad hoc tasks for the tasks that were being added manually, triggered based on new rules detected in the historical instances. Kris finished with the caveat that machine learning algorithms can be biased by the training data and may not learn the correct behavior; this is why they look at using ML to assist users before incorporating this learned behavior into the pre-defined process or case models.