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

At one time, this term included virtually all the individual technologies that will be introduced in this chapter, in one form or another. However, once the loosely organized science gives birth to a proven discipline, the emergent capability is purged from the definition of AI and can stand alone. Therefore, AI is by definition the nebulous and nondescript potential technologies that may ultimately emerge to emulate human thinking, capabilities, and interactions. Prior to building critical mass and emerging successfully as individual disciplines, optical character recognition (OCR), intelligent character recognition (ICR), speech recognition, observing any combination or sequence of variables for compound decision making, language translation, robotic process automation (RPA), neural networks and machine learning – all of these lived in the vague, blurred, and ambiguous land of potential to emulate human-like capabilities – artificial intelligence.

The next technology we will introduce in this chapter is distributed ledger technology (DLT) upon which blockchain is based. In order to transact digitally and with confidence, the ownership chain of assets of value must be trackable and auditable. If we think about all the transactions our companies engage in, one activity that often represents manual work and a break in straight through processing (STP) is verifying transactions when questions arise after-the-fact. Think of the number of reconciliations performed across accounting, finance, and operations functions in business today. Often, reconciliations are aimed at comparing and agreeing things like transactions, assets, securities, and account balances to confirm the true state of a ledger. A reconciliation is essentially the comparison of two datasets to either confirm their agreement or to identify any exceptions or breaks . Once exceptions are identified, countless hours of investigation can follow, tracing the exceptions back to transactional source data to confirm which of the two data sets under comparison are correct, and to take the necessary resolution steps to correct the faulty dataset. What if this could be solved in a different way?

Distributed ledgers contain different types of shared data, such as transaction records, attributes of transactions, credentials, or other pieces of information worthy of retention and validation. Blockchain technology allows a network of computers to agree at regular intervals on the “true” state of a distributed ledger. On a blockchain, transactions are recorded chronologically, forming an immutable chain, and can be made private or public, depending on how the technology is implemented. The ledger is distributed across many participants in the network; it does not exist in only one place. Instead, copies exist and are simultaneously updated with every fully participating node in the ecosystem. Therefore, a blockchain emerges as a single validated source of truth. Suddenly, a decentralized network can achieve broad consensus about the state and authenticity of a block's contents. Each participant in the network can verify the true state of the ledger, contribute to maintaining the accuracy and authenticity of the ledger, and subscribe to the resulting dataset as a golden source of truth. This technology can be used to transact at low cost, or to reduce reconciliation efforts and minimize the costs of resolution steps.

What if counterparties to transactions were both (or all) participants on the same distributed ledger? If they each (or all, respectively) agreed on the validity of ownership or asset movements, and each subscribed to the resulting golden source of truth, would there be a need for the vast numbers of after-the-fact reconciliations or the audits that are undertaken to resolve exceptions? Would there be an opportunity for exceptions to emerge at all? So goes the theoretical benefits case for distributed ledger technology to the accounting, finance, and operations functions in large organizations.

Use cases abound for distributed ledgers and blockchain. In accounting and finance functions, there are a number of opportunities to harness this to settle and reconcile transactions more efficiently than is done currently. Think of the processes undertaken by your own organizations to research the completeness of transactions, the accuracy of balances, or the true state of ownership. Have a think about the number of reconciliations and comparisons performed in your own office to get a sense as to whether there are opportunities to gain efficiencies by consuming a single source of truth that has been validated through consensus of participants. In logistics, benefits can accrue from leveraging an immutable audit trail of goods as they move through the economy – as supplies move to manufacturers, through the goods production process, as finished goods move out the door to distributors, and how they pass logistically through shipment and delivery to consumers. Other use cases arise in identity and authentication. It is clear that distributed ledger technology will change the way we do business in the future. This technology is in no way the focus of this book, but we want readers to be familiar with key disruptors that are shifting the landscape in the new digital age.

One of the tools that has gained prominence is robotic process automation (RPA). Robotics, or Bots, for short, can be used to automate routine processing steps that were previously done by humans. RPA is most appropriate for highly routinized or transactional processes or for the routinized portion of more complex processes. Obvious benefits of RPA can be measured in three ways:

1 In many cases, the cost of software licenses required to maintain the Bot can be less than the costs to maintain the number of employees they can replace. This is often, but not always true.

2 Given that Bots, by definition, structure processes that were previously unstructured and manually performed by operators, they can lead to increased control and process stability.

3 Bots can perform processes at speeds unrivaled by humans, when appropriately configured. This means that work which previously required a full day to perform (or many equivalent workdays to perform, in cases where an entire team performed the task in the legacy environment) can be accomplished in minutes – or even seconds.

Data entry is often a prime candidate for this technology, when the target source data for input can be found in a consistent array. Imagine for a moment that a receivables clerk routinely captures an extract of received cash from a bank statement, traces the amount back to a receivables balance, and then formulates a cross-asset journal entry in the general ledger to debit cash and credit accounts receivable. If we assume that there is connectivity between the Bot software and all component systems related to the process, and if we assume that there is a high-quality mapping of customer static allowing the operator to relate the enterprise name on the bank statement to the accounts in the receivables master, and if we assume that adequate controls surrounding this process can be built to ensure it is rigorous and stable, this process may be a great candidate for a Bot.

Today, readers may be interacting with Bots without even being aware. Individuals may engage Chatter Bots (Chat Bots) in any number of platforms. Chat Bots are NLP-intensive applications which are programmed to perform human-like on-line chat conversations. Customers interact with them in much the same way as they would, were there a live operator on the other end of the line. The software would respond to social and conversational queues like “Hello” and respond in kind (“Hello, Reader!”). They would also perform a classification to understand what information is being requested and what operations are required to respond most appropriately. These are heavily used by support teams and can multiply the bandwidth of existing staff. Of course, there are limitations. The Bots must be explicitly programmed to respond to written queues, meaning that each response must have been explicitly provided for, as the program is developed. The Turing Test was developed to test the ability of a machine to interact in a way that is indistinguishable from a human. On this scale, many Chat Bots today fail to convincingly resemble humans, but they can be used to great advantage when requests are highly predictable and standardized.