Nathan E. Myers - Self-Service Data Analytics and Governance for Managers

Complex software installations can be performed by a Bot, given that the number and order of steps are discrete, finite, and well understood. Reconciliations, which occupy many in accounting, finance, and operations, can readily be performed by Bots. Any number of activities that require the merging of data from any number of systems, departments, or processing outputs can benefit from a Bot, though in many cases there are ready-made tools available for ETL use cases that are better suited to this task.

There are general rules of thumb that allow reviewers to confirm that a process is viable for RPA. In order for it to be viable, as a starting point the target data attribute needs to be mastered consistently such that it appears in the same format, placement, or field on a page, file, or screen. If it is being captured for entry elsewhere, the Bot must be able to readily interface with the destination application and to navigate to the target field for entry. More complex processes can represent a challenge for Bots, where instability of input formats and locations is introduced. Any processes which require qualitative discernment would likely be out of reach for independent Bot processing. However, Bots in a first pass could wade through processing queues, process only qualifying transactions in scenarios where prerequisite values and criteria are met, and surface all other nonconforming transactions to an exception queue for the human operator, when they warrant scrutiny and discernment. Sure, it is cherry picking, but does it add up to appreciable savings? In many cases, the answer is yes .

Another way to deal with complex processes is to break them down to a series of the most basic discrete steps. For the simpler steps in the processing chain that are viable, Bots can be deployed for rapid execution, leaving the more complicated processing steps in the value chain to an operator (who now enjoys a bit more time to perform them). A much-repeated folly is to promise your stakeholders that an entire process from A-to-Z can be automated. Very often it is simply a matter of time until a time-sucking challenge is encountered that endangers the delivery as a whole, or at least the perceptions of the delivery. In reality, for virtually all automation projects, there is very often residual manual tail of work left unautomated by the effort.

One alternate approach is to embrace this fact from the start and to employ a modular approach to automation, by narrowly defining the scope of Bots within a process chain. The scope of the Bot could be defined to be only a very narrow sliver of the overall process. An example may be that when product controller performs a reconciliation of trade blotter positions to general ledger positions on T+1, they perform 27 steps across several systems, many of which involve discernment, judgment, and the benefit of their considerable experience and expertise. Within the process overall, there are only several individual steps which are well suited for RPA. For example, two steps that are critical and must be performed without exception, are: (1) download an extract of yesterday's trade activity from the risk management system, and (2) launch the general ledger application and set the value date to the prior day. These narrower scope processes can be successfully automated with a Bot, even though the remainder of the processing steps may be overly complex or unsuitable for automation. By modularly defining the scope of the Bot and deploying them for limited use, the time-to-market can be hastened, versus spinning your wheels attempting to automate the process from head to toe ( chasing a unicorn ). The individual savings on any given day may be small, but the benefits can be considerable, if the same functionality can be reused with only minor customization. (You have now built an application launch Bot for the general ledger. Need a Bot to launch any other applications? Simply rinse, adapt, and repeat). The benefits can add up when there is wide applicability and abundant replication opportunities for modular functionality to be redeployed to the benefit of hundreds or even thousands of employees across an enterprise.

At the time of this writing, the robotics platforms of four companies dominate, although this is a moving target. The industry-leading platforms are as follows: Automation Anywhere, Blue Prism, UIPath, and NICE. These names are less important than gaining an appreciation for the underlying technology and the appropriate use cases to which they are best applied. For now, remember that Bots are best deployed for stable and repetitive processes that exhibit very little variance.

Machine learning (ML) is the subset of artificial intelligence (AI) that is focused on the study of computer algorithms that improve automatically through experience. Machine learning algorithms build a mathematical model based on samples of data observations or training data , to make decisions or predictions, without being explicitly programmed to do so. Above, we introduced RPA, which relies on very regimented coding of specific operations, depending on explicit variables. With machine learning, a number of samples are analyzed to understand the relationships of inputs and to determine how outcomes are derived. The more training data that is pumped through the model, the better the algorithm should get at predicting the “right” answer. Machine learning algorithms are used in a wide variety of applications, such as email filtering and computer vision, where it is difficult or infeasible to develop conventional algorithms or code to predict and specify needed tasks.

This morning, one of your authors arose an hour earlier than normal to get in a jog on this pleasant June day. As he pulled the phone off the charger, a message on the screen read that the phone was scheduled to be fully charged at 5:45am. The change in schedule had clearly thrown off the charging fairy, as the battery power read only 94% charged. One hour and a good jog later, the author then launched his thermostat app to turn down the AC, before getting in the car to begin the commute. Once in the car, the same phone displayed a message indicating that there was light traffic to the train station, a journey which was predicted to take 8 minutes. A prompt came up to allow for quick directions to the train station, which was hastily declined. Afterall, the authors are brilliant not only with data analytics and governance books, but with getting themselves to the train station, even without the benefit of GPS-assisted instructions.

It is easy to see machine learning in action, in just the first 90 minutes of the day. It is not exactly clear which of the author's observed activities or features were used to trigger his phone to make suggestions, but it is clear that routine daily actions observed and logged over time had served as training data and had ultimately resulted in a number of predictions about subsequent activities or labels . Clearly, the phone knew the time the alarm was set for, at what time the commute begins, and where your author's car is left for the day.

There is a scale of maturity for machine learning capabilities, beginning with descriptive analytics to look at what has happened in the past with data aggregation and mining, moving forward to diagnostic analytics, to understand the drivers of the target outcomes. Moving further along the continuum, we get to predictive analytics to help us to project from past observations what will happen in the future, based on statistical forecasting models, and on to prescriptive analytics, which uses optimization and simulation algorithms to advise on possible outcomes and to determine what actions should be taken. In the phone example above, the machine learning model is far out to the right, even approaching prescriptive analytics. The model was able to predict the next actions and to prescribe what to do about them – launch the driving directions app, as you are in the car and headed to the train station!