This is on the one hand due to the rise of AI technologies and the subsequent understanding what can be achieved with algorithms that mimic human understanding. AI having arrived in the mainstream (and even dominating the mainstream discussions) is now generally understood as being capable to perform cognitive tasks that humans perform. We have known and preached this for a long time but it is a good development that our former niche becomes standard.

On the other hand IDP gets more and more integrated into the main business processes. In the past Capture used to be almost always departmental. Capture was only allowed in a (badly lit) corner of an Enterprise mainly because no Capture system was able to fully integrate into Enterprise IT and most importantly comply with all security rules established for enterprises.

This has changed to the better in the past few years. At Skilja we have invested a lot of effort to strictly follow all security requirements so Vinna (our enterprise platform) can become a part of enterprise IT. This means on the one side that during development we are running frequent security screenings and penetrations tests to ensure utmost security for the software. For example Vinna and Skilja Software is Veracode Verified since many years. On the other hand we independently make sure to follow all defined industry standards very closely.

The most important aspect to be allowed to run in an enterprise is authentication and authorization. Typically an enterprise will not (or only grudgingly) allow an application to store user names or passwords outside of their internal identity management software. A platform should not have its own user management. This is a no-go for many customers. Therefore Vinna from the beginning always used roles that then are mapped to users in the enterprise user directory. In Vinna 3.0 still the password needed to be entered by the user and was sent (encrypted) to the authentication backend.

Since version 3.1 our Vinna platform uses the OAuth2 protocol for the authorization of users. OAuth2 itself does not directly deal with the authentication of users and clients. Instead the authentication backend is required to grant authorization and thus access. OAuth2 is supported by a lot of backends, namely Microsoft Azure AD and Keycloak. All communication with the backend (Resource Server) is bundled in the Skilja Authorization Server that is used by all Vinna Platform services, Clients and Activities.

Vinna provides authentication via different methods:

• Authorization Code Flow with PKCE via a web browser
• User name and password authentication via the password grant flow
• Client authentication via the client credentials grant flow

Authorization Code Flow with PKCE (proof key for code exchange) is the current best practice when logging into any client application because it avoids entrusting a client application with user credentials.

A user that wants to log into a web site is redirected to the log in page of the Skilja Authorization Server. If the user has not yet authenticated itself to the Skilja Authorization Server, they enter a user name or password into the login field. After the credentials have been verified, the user is redirected back to the web site where they started, along with an authorization code. This authorization code is used by the website to exchange it with the Authorization Server for an access token. The authorization code part prevents user credentials to ever be entered into a potentially non-trusted client application. The PKCE part in this flow prevents the access tokens to be passed around in redirect URLs shown in the browsers URL tab, thereby preventing accidental token leakage by copy/pasting the url.

The client credentials grant flow type of authorization as shown above allows to register client credentials with the authorization service, along with claims which each clientId may receive. This type of authorization is intended for machine-to-machine communication and not for typical user interactions. In this flow, a client Id and matching client secret is sent to the authorization service that issues an access token. Once the access token expires, client Id and client secret can be used again to obtain a new access token. Also, in some cases a refresh token is made available that can also be used to acquire a new access token

Overall this new architecture of authorization and authentication allows an enterprise to integrated Vinna and all IDP activities that run within Vinna into their environments, available to all users opening up much more options to use IDP in their processes than if they were separated in their own network.

New Process Editor UI

The new design makes creating processes with no coding – no scripting – no configuration file editing as easy as it should be. Vinna 3.0 comes with the new BPMN process editor, with improved speed and usability. Now in Angular 10, all functions are componentized and can be integrated separately.

Plenty of new features improve the design and runtime management of processes. Cooperate better with your team members, as you write comments directly to activity instances. Work together designing the process. All activities can be configured through the UI – either through standard dialog or individual extended dialogs of activities, which can even bring up their own web UI. When a process is locked, you can now immediately see by whom. Besides many graphical changes, e.g. in the view of processes, document types and variables, it is now also possible to switch all views to lists and search in all trees and lists. You can see all environments where a process(-version) has been published to and we allow deletion only when no published version exists.

Vinna 3.0 Process Designer

Process Version Management

If you ever were in charge to manage a production system you know how important staging and versioning is. “Never touch a running system” is common but in the end leads to legacy problems as nothing can be updated any more. Key to any enterprise-critical production system is version management that allows full control over what is changed – of course with thorough testing in staging steps. Therefore, version management and staging is a central part of Vinna architecture from the start and has been further improved in version 3.0. You can now create major and minor versions (1.0, 1.1, 2.0, …) of processes. The latest version you edit is always marked as a draft version – you can’t break anything! Deploying a process happens for a certain selected version. So it is easy to work on major changes of a process and already test it but at the same time create hot fixes (patches) for existing production processes if necessary. And you can even change variables in each of your runtime environments separately for each version.

Vinna 3.0 Process Version Management

Environment Management

Environment ist the runtime system where a process is published to. Many environments – on premise, private cloud, public cloud – can be managed from the same Designer. The environment is executing the process by hosting and running the activities as necessary in as many Activity Servers as needed. In Vinna 3.0 we now have “transient” Activity Servers that auto-start with a VM or in a Docker, do their work and shut down again when not needed. Together with the separation of Activity Server configuration from the instance, you can easily assign arbitrary resources to a project to scale up dynamically in peak hours, or reduce hardware cost by using just as many servers as you need. An overview over all assigned activities and activity servers across an environment fulfills a long-requested requirement.

Process Monitor

The 3.0 runtime backend is fully compatible and introduces a lot of invisible changes related to scaling, performance and security. Process Monitor is the GUI to monitor the runtime and also has been completely redesigned. It comes with a lot of improvements and usability enhancements. Many visual usability enhancements were made with the new controls like grouping, filtering and customization of the UI for business operators. There is now a new tab for directly previewing documents in a work item with all their data. Licenses can now be reviewed and managed either in runtime or in design time with a common license view including status and report for click rates.

Vinna 3.0 Process Monitor with grouped work item list.

Vinna is an open and process-oriented platform, that allows users to define a process in exactly the way as it is optimally operated in a company. The design allows full flexibility in the data model with a hierarchical document model supporting batches, folders, documents and pages. The documents are processed as work-items in the flow and passed through activities. The activities are either standard tasks like OCR or Classification, or custom tasks as integrations into the platform. Any number of activities can be defined in the process as micro services, including arbitrary routing decisions based on intermediate results. The architecture of Vinna is service oriented (SOA) and the runtime is easily deployed either in the cloud (Microsoft Azure, AWS or private cloud), on premise or in mixed environments where the data storage is kept in house and processing happens outside.

All communication between services and databases is transaction based, securely encrypted and uses standard REST protocols over HTTP and HTTPS.  Three powerful HTML based graphical user interfaces are provided for defining, managing and monitoring processes. Vinna is available for small projects but also incorporates all enterprise features need for large production systems. The biggest Vinna customer now processes 100M documents p.a. in one system, which is 400.000 documents per day.

Whitepaper and data sheets are available if you are interested in further details, please contact us through info(at)skilja.com to obtain your copy.

Now as this process is built and works well, the question arises how to integrate the new capabilities in your line-of-business applications and existing processes. File import and export is insecure and outdated. Full integration requires too much effort from IT that might not be available.

Fortunately there is a solution 🙂 : By plugging in an Event Driven Activity (EDA) you can enable ANY process to be accessible through a standard web service protocol. Simply by adding the EDA to an existing process you make it available to a RESTful service call. The EDA can be the only start point of a process but it can also be added in addition to existing starters like file importers, message queues or IMAP collectors that pump documents into the same process.

Typically you add one EDA starter and one or several EDA Reporter or Listeners. These are accessed through a simple web protocol by the EDA consumer. The Consumer can either be a web page (as in the example below) or a Windows application like an RPA client that automates the cognitive task scheduling. Both are provided as sample source codes with your installation. At any stage of the process the Consumer is optionally updated via event on the progress of the work item in the process. When processing is finished the results are retrieved either through an event or from a queue that is queried via REST.

The process can be deployed anywhere – there is zero setup. Simply use the URL of the service and of course the credentials for the secure and encrypted communication with the authentication service. The process can sit anywhere in the cloud and be used by any client world wide that has access –

Through EDA VINNA is used completely in slave mode and the consumer is shielded from any complexity of the process.

The process can contain any number of steps and routes, including manual correction, approvals or even sending tasks to the crowd. The Consumer will see none of this, it will simply get notified on the results on a standard API irrespective of the process. So when the process is changed and enhanced, the Consumer can stay as it is. This is the true power of process as a service. “Technology under the hood”- Especially when combined with online learning that will continuously improve the result.

A nice example is shown in the graphic above. The Consumer (in this case any RPA client) choses to use a classification service by selecting the process (through EDA) and the classification project that should be used. In this case both classification activity and classification Web designer access the same classification model in the database. Therefore an admin user can even modify the classification model and the taxonomy or create a new one. Because the process itself and the call to use it stay unchanged. This process also contains a manual correction step (Batch Review) that is conditionally used in case of uncertain results. The system can even send a link for a correction task as a web page so the user can make any decisions or corrections of submitted tasks herself without having to install anything. The corrected results in turn will then be aggregated and used for online learning. If several hundred users are using this process it will quickly optimize the results automatically without any further effort. And at all time the actually processing can happen anywhere in the world on any cloud server.

This is the power of process as a service.

In this post we examine the role of Intelligent Document Processing (IDP) relative to Robotic Process Automation (RPA) and how these technologies drive Digital Transformation when combined. In part one we look at what is driving and enabling Digital Transformation. Part two then is dedicated to RPA and why IDP is essential. 

Digital Transformation

Companies all over the world are redesigning and digitizing their businesses at an ever faster pace and they have many reasons for doing so:

• They want to serve their customers faster and better.
• They understand that automation and using AI technologies improves innovation, agility, scalability and cost-efficiency
• They appreciate that in contrast to human labor-intensive processes digital processes
  • take less time to design
  • need less capital investment
  • are faster to deploy
  • and (much) less costly to run.

The above is commonly referred to as Digital Transformation. Citing Salesforce’s definition: “Digital Transformation (DX) is the process of using digital technologies to create new — or modify existing — business processes, culture, and customer experiences to meet changing business and market requirements.“ 

The main drivers of Digital transformation are the ongoing globalisation and the Fourth Industrial Revolution which has led to dramatically increased levels of competition. DX greatly improves the agility of businesses so they can adapt much faster than ever before to changes in the market. Changing or even completely redesigning digital processes is a lot easier and comes at much lower cost which results in significantly increasing a business’ competitiveness. Note that even terminating digitised processes comes at a much lower cost than when a lot of capital investment and labor was involved. Basically businesses have no choice. They must become digital. And those who are slow to change find themselves in an increasingly disadvantageous position. New businesses nowadays will always start with a digital concept in mind and by doing so will avoid manual processes if that is possible and makes sense. 

Market Data on Digital Transformation

What actually makes things very different from say ten years ago is the enormous progress. Worldwide spending on technologies and services that enable digital transformation (DX) by business practices, products, and organizations is forecast to reach $2.3 trillion in 2023, according to a new update to the International Data Corporation (IDC) Worldwide Semiannual Digital Transformation Spending Guide. DX spending is expected to steadily expand throughout the 2019-2023 forecast period, achieving a five-year compound annual growth rate of 17.1%. “We are approaching an important milestone in DX investment with our forecast showing the DX share of total worldwide technology investment hitting 53% in 2023,” said Craig Simpson, research manager with IDC’s Customer Insights and Analysis Group.

In their July report Grand View Research reported that the global Robotic Process Automation market size which is a segment of the overall DX market was valued at USD 1.40 billion in 2019 and is projected to exhibit a compound annual growth rate (CAGR) of 40.6% from 2020 to 2027.

Why is Digital Transformation taking place now

In the last decade we have seen a tsunami of digital transformation projects driven by an accelerating desire of companies to increase competitiveness and innovation. But of course one could argue that businesses always had that desire. The question one could ask is: Why is all that happening now? Haven’t companies not been automating for decades already? Yes, but not at the current pace. 

Note: at this stage it is unclear how the Covid-19 pandemic will influence market dynamics. It seems however unlikely that the need for companies to digitize their businesses will slow down. On the contrary, it is much more likely that the opposite will happen.

What has made things totally different from say ten years ago and has really enabled Digital Transformation to take place is the enormous progress in both computer science and in the computer industry. Compared with say 10 years ago we see:

• an enormous increase in computational power
• the rise of super powerful algorithms, algorithms that need incredible amounts of computational power which is now available
• vastly improved connectivity both in speed and access points and it is improving at an accelerating pace (5G)
• smartphones: in 2009 170 million smartphones were sold. In 2020 1.5 billion units are estimated to be sold. That makes for an estimated 3.5 billion people having a smartphone in 2020
• huge and disproportionate – compared to the rest of the economy – amounts of money, that have been invested in tech companies. Successful tech companies have rewarded their investors  with multiples that dwarfs any other industry.
• and last but not least an insistently growing appetite of consumers and businesses for more, better and faster service anywhere at any time.

Some examples of how robotic process automation and document processing drive Digital Transformation in companies

A large international pharmaceutical company wanted to capture all details from their purchase orders and perform lookups and validation using their ERP. Tasks were automated using a RPA system. An intelligent document processing system was needed to read the data from the POs.

A large financial services company wanted to use RPA to automate their KYC process which involves capturing, verifying driver licences, passports etc. Early in the process they found that they also needed an intelligent document processing system.

A global logistics company wanted to automate their invoice processing (millions of documents). Their RPA system was found to be up to the challenge. But the company initially backed off because of the complexity of extracting data from millions of invoices (semi-structured) with a wide range of varying lay-outs. Only after a proof of concept clarified that there was an intelligent document processing system on the market that was up to the challenge the company proceeded with the project.

In part 2 of this post we will discuss how the combination of RPA with IDP works and what are the challenges that need to be considered.

———————————————————————————————

Jupp Stöpetie as CEO of ABBYY Europe established ABBYY’s presence in the Western European markets, growing the brand and market presence to a leadership status for +25 years. His experience includes founding and growing companies and managing all levels of business operations, sales, and marketing. Jupp left ABBYY in spring 2020 and now works as an independent consultant based in Munich, Germany.

Main emphasis was put on easy and secure deployment into runtime environments in a customer infrastructure. Vinna allows designing and testing of a process completely outside of production and then using a built in staging system to move it securely to production. This step is called publishing. Vinna 2.0 allows the administrator to also configure the actual runtime environment completely from central Process Editor by distribution of activities to activity servers, assignment of reservations and definition of priorities. A process is such automatically deployed to a target environment and to the activity servers including all configurations but also all binaries. This is schematically shown in the graph below. At no time the runtime server need to be accessed except through a browser and HTTPs protocol. In addition processes are versioned in design and in runtime to avoid any interference of new settings with existing production work items.

Publishing a Process and Activities in Vinna 2.0

Support for Oracle, Azure SQL, Azure Blob has been added on top of existing MS-SQL and NoSQL databases. Variables allow to predefine connection strings, import paths and any other parameter specifically for each target environment. One example: In a test system you might define a user with admin rights on a lookup database for testing purposes but this user will be automatically be replaced with a more restricted user on the production system.

Vinna 2.0 Runtime Architecture

Vinna is an open and process oriented platform, that allows users to define a process in exactly the way as it is optimally operated in a company. The design allows full flexibility in the data model with a hierarchical document model supporting batches, folders, documents, pages. The documents are processed as work-items in the flow and passed through activities. The activities are either standard tasks like OCR or Classification, or custom tasks as integrations into the platform. Any number of activities can be defined in the process as micro services, including arbitrary routing decisions based on intermediate results.The architecture of Vinna is service oriented (SOA) and the runtime is easily deployed either in the cloud (Microsoft Azure or private cloud), on premise or in mixed environments where the data storage is kept in house and processing happens outside.

All communication between services and databases is transaction based, securely encrypted and uses standard REST protocols over HTTP and HTTPS.  Three powerful HTML based graphical user interfaces are provided for defining, managing and monitoring processes.

Whitepaper and data sheets are available if you are interested in further details, please contact us through info(at)skilja.com to obtain your copy.

Vinna was presented last week at the open house conference in Berlin that Skilja organized together with our dedicated partner ScaleHub (www.scalehub.com) with our partners TCG (www.tcgprocess.com) and Eucon (www.eucon.de).

Vinna Dimensions

The three dimensions of Vinna are:

• Process: Definition of flow of action define according to BPMN
• Documents: Richly structured and open model for storage and enrichment of documents and other media
• Activities: Process modules which are individually configured or created

Vinna is an open and process oriented platform, which defines a process in exactly the way as it is optimally operated in a company. If you wish you process documents in batches then create batches. If you want to work case or document centric then use these entities in the process. The design of the platform allows full flexibility with any number of activities to be carried out in the process, including arbitrary routing decisions based on intermediate results.

Vinna is based on a data and document model that is completely and transaction safe in a modern SQL database. Using a modular architecture of the communication layer Vinna can be scaled and distributed optimally. Processes with more than several 100.000 items per day are easily manageable with intelligent load balancing.

Of course the architecture is service oriented (SOA) and can be deployed at will in the cloud or on premise or in mixed environments. All communication between services and databases is transaction based, securely encrypted and uses standard protocols. The platform is multi-tenant capable, supports staging, versioning, assisted deployment and provides built in SLA monitoring of all processes.

Vinna Tools

As a part of the platform three powerful tools are provided with pure HTML GUI:

• Process Designer: Definition of processes and activity management according to BPMN
• Process Monitor: Operational view on running processes and SLA monitoring
• System Monitor: Technical view on running services and current state of the system messages, current throughput per service and activity

Vinna Modules

Vinna modules are activities in the process. The platform already comes with a number of standard activities included, like import, export, full-text OCR and PDF creation. Our own classification components and technology from selected third parties are provided as options. In addition individual activities can be created based on customer requirements or directly by the customers themselves using the open .NET API or the REST Interface.

Give workflows a miss: A provoking claim in the age of business process automation. Because whenever we think of the automated processing, we think in categories of how information gets to the relevant persons fast and efficiently. But especially when it comes to automated processing of vendor invoices, this consideration is the wrong approach, because it is necessary to automate processing as far as possible so that only a small amount of invoices have to be sent on a control and approval journey actually using a workflow.

All beginnings are easy
Whenever we are addressing the subject of automated invoice processing in a first meeting with a customer, our counterpart talks workflow. Traditionally the incoming electronic or scanned image of an invoice is received in accounting. They then  determine the responsible person, sends the invoice and waits for the respective invoice release. After its return to accounting, booking, filing and payment are carried out and that is all.

This may be a good approach when you are dealing with very few invoices, maybe five to at most ten units per day respectively less than 2.000 invoices per annum. In addition, dealing with this amount, an existing e-mail system and a bit of organizational aptitude should be sufficient to keep track. However, as soon as the number doubles, triples or even quadruples, such an approach reaches its limits shortly, because all the sudden a staff member of the accounting department will spend most of its working day sending invoices on their electronic journey and controlling the returned invoice approvals.

Therefore, when it comes to invoice quantities of 10.000 units or more, a better alternative has to be considered. One that avoids wait time and grants full overview over all invoices in circulation. So at first glance, implementing a workflow-system seems obvious. A system that offers the possibility to track the invoice distribution and intervene in the process at any time. However, is this sufficient? Or is it rather a missed opportunity?

Invoices are a bonanza
A workflow can be a good thing, but honestly: Does it not seem absurd to you, too, to send an invoice that you receive on a monthly basis to the same person time and again and subsequently use the same old data over and over again for accounting? In this case, would it not be much more feasible if the system carried out such processes on its own?

In order to enable an intelligent processing system to do so, it has to be provided with high-quality data at a very early stage. Therefore, at the beginning of an automation process paper invoices, on the one hand, have to be scanned and recognized or automatically read, the delivered data records of electronic invoices, on the other hand, have to be reformatted into a standard format, so that all further processing steps can be executed uniformly.

Once the invoice data is available in a consistent electronic way, it can be processed automatically. The objective of an optimized business process automation has to be to store knowledge in such a way that data can be processed highly automatically, or in other words, whenever possible without human intervention.

When analyzing your everyday invoices, you will quickly realize that a large number of it is returning. This means that information and knowledge on how to deal with these invoices is present within your organization. This knowledge can be stored in systems or inside the heads of your staff. In case this process is to be automated, it is important to use this information and to prepare it in such a way that the processing system can take highly independently all necessary decisions based on this knowledge.

For example, there is project ABC and it is know that the invoices of supplier XYZ always belong to this project and that they are always booked the same way. At the same time, these invoices are checked and approved by the ever-same person of the ever-same department. The binding source for the invoice checking is the corresponding contract negotiated with supplier XYZ for project ABC.

It does not make any sense to enter this information into the accounting system time and again whenever the invoice comes in. In addition, it is equally useless to e-mail this invoice to the ever-same person hoping she or he will return the approval before the cash discount period has expired.

In this case, we are speaking about an automated workflow where the basic information of a vendor is stored in the processing system and used automatically as accounting and approval template whenever such an invoices comes in. However, processing invoices that way implies that the invoice recognition is carried out consistently, by way of example using the unique vendor master record of the accounting system.

Why do contracts exist?
The cynical answer could be: So that they can be discarded somewhere and forgotten until someday the big search begins. Well, hopefully not, but in most of the companies that we have met so far, there is no or an only very limited structured contract management. Because of this, goods and services are often only vaguely known and simple information such as period or term of notice is not available on short notice. In case contracts are recorded in a system in a structured way, the information contained can be used to automate the processing of all invoices by the respective contracting party. Generally, terms of credit, rates and conditions, installment plans, periods, budgets et cetera are defined in the contract, so that the electronically available invoice data can be matched with the respective contract information.

Generally, if there is an existing leasing or rental agreement it is known when the respective invoices come in, which amounts have to be paid and how they have to be recorded. In case no deviation from the contract is discovered, there is absolutely no need for a check and approval process. Letting these invoices be checked and approved by the ever-same person time and again and to record them in the ever-same way is nothing more than a waste of precious time.

For contracts with variable invoice amounts, similar procedures can be applied. By way of example, checking the often-comprehensive telephone bills is feasible only when there is a peculiarity respectively a deviation such as an extraordinary invoice amount. Therefore, effectively automating the processing of invoices with contract reference requires the use of such procedures in order to process these recurrent invoices fully automatically and to detect deviations so that your specialists can systematically focus on these peculiarities.

An order is already entered in the books
The potential of automating invoices with order reference goes even further. Many organizations operate standardized purchasing systems that manage the orders of goods and services. Generally, requisition, approval, process of quotation and finally placing the purchase order with the supplier are part of the things managed by such systems. In addition, an approval process of the desired order is an essential part of this procedure. Furthermore, all relevant information regarding prices and conditions, accounting, cost centers, projects et cetera is already deposited when placing the order. Therefore, it does not make any sense at all to run through these steps all over again and to manually check and record all information again by the time the invoice arrives.

Using automated order matching, the processing system checks whether there is a deviation between invoice and order. In case no deviation is detected, there is no reason to manually check the respective invoice and run through an approval process all over again. This a complete waste of precious time, too.

The workflow spiral
And yet it moves, the workflow spiral. However, only for the few invoices that are sent by (still) unknown suppliers or do not have either contract or order reference. As far as we know, in a well-positioned organization these kinds of invoices only represent a very small part that often lies in a single-digit percent range. Making a workflow system the heart of an automation project because of this small amount of invoices and thereby renouncing the actual automation potential is as wrong as missing cash discount periods. In short, it is a missed opportunity.

(This post appeared first in Interact Magazin on the Interact homepage in German)

####

DR. RICHARD COP is co-founder and CEO of Interact Consulting: «Which impact does technology have on our society and which impact do we have on technology? These questions take center stage for me and I also dealt with them in my dissertation on the process of structural change in telecommunication. I want to optimize processes, harmonize technology, organization and people, and above all, promote interaction. Therefore, as entrepreneur, today I design fully integrated processes together with our customers.»

With process automation and digitization, using modern Classification technology, address and table extraction and semantic understanding the content of the documents becomes digitally available. In the current phase insurances are using this data and modern learning analytical methods to actually automate not only the process but also the decision making. If all information is available a KI system (like Skilja’s learning classifiers) can automatically decide if a claim is standard and can be paid right away or if it needs expert inspection. An application for a new contract can be clarified and checked mostly by semantic and analytical algorithms, that link it to the policy of the insurance – leaving the underwriter the task to finally check the suggestion based on the conclusion made by the machine.

In two recent studies from McKinsey, one by Sylvain Johansson and Ulrike Vogelgesang  (Automating the insurance industry), the other by Michael Chui, James Manyika, and Mehdi Miremadi (Four fundamentals of workplace automation) the authors show in a very impressive way how this will affect the work place in the industry:

As the automation of physical and knowledge work advances, many jobs will be redefined rather than eliminated—at least in the short term. The bottom line is that 45 percent of work activities could be automated using already demonstrated technology. If the technologies that process and “understand” natural language were to reach the median level of human performance, an additional 13 percent of work activities in the US economy could be automated. The magnitude of automation potential reflects the speed with which advances in artificial intelligence and its variants, such as machine learning, are challenging our assumptions about what is automatable. It’s no longer the case that only routine, codifiable activities are candidates for automation and that activities requiring “tacit” knowledge or experience that is difficult to translate into task specifications are immune to automation.

Being McKinsey they look specifically at the workforce, the FTEs (full time equivalents) needed for a task and the required skills in the future. Using benchmarking across insurances McKinsey finds very interestingly that most time is spent in policy creation, policy servicing and claims management.

Of course claims management is minor in Life but significant in P&C. The graph is interesting because Skilja is right now involved in several projects in Life where we exactly aim at reducing the time needed for underwriting a policy. And the reduction we see is significant using modern KI, deep learning and other algorithms. New technology and agile development methodologies allow swift process automation at limited cost.

The effect in insurance workforce is dramatic as shown in the first graph above. Up to 25% of the FTE in these repeatable tasks will be consolidated. Meaning that the insurance can lower the cost, increase the number of customers served and reduce the time to process a claim or application.

For more detailed information we recommend to read the excellent original article “Insurance on the threshold of digitization: Implications for the Life and P&C workforce” available for download here.

If you are interested how this can be achieved from the technological side and what the current state of the art of classification, document understanding and automatic decision making is, please look here www.skilja.com or let us know info(at)skilja.com.