What is Robotic Process Automation (RPA)? Our Complete Report.

About Top Illustration:

« Built and unveiled for the first time in 1770, the Mechanical Turk or chess-playing automaton is a famous hoax built at the end of the 18th century: it was an alleged automaton with the ability to play chess. It was partially destroyed in a fire. Nowadays a replica has been created: it is controlled by software and really plays chess alone. »

RPA is an approach and methodology to do process automation. RPA is not a technology, neither a significant scientific breakthrough, nor a product, but really a process for implementing automation mechanisms. As we define it in this state of the art, the approach consists of the use of “software configured to autonomously exploit the functionalities of existing third-party applications in order to execute all or part of a business process”. In fact, RPA is based on a relatively simple idea that considers that if a human can do certain tasks then a robot can do them too!

This does not apply to all operations, as our algorithms are still far from being able to think, conceptualize, and perform deeply complex actions. However, in a professional world, there is a significant set of administrative tasks that are highly streamlined and repetitive. RPA has a leading role to play in these contexts. Back-office professions are, consequently, the first to be concerned by RPA.

RPA draws its strength and excitement from its ability to create robots (i.e. software agents) that perform tasks like a human behind the screen: mouse clicks on the right buttons, logins to web services, reading documents, copy/paste from email, audio transcription from phone conversations, report creation, collecting information on the web, etc. The prevailing idea lies in the analysis of these tasks and their orchestrate to automate all or part of an administrative officer’s job.

The RPA phenomenon also derives its power from a very “no-code” oriented automation. Many RPA development studios are available today to produce robots, deploy them, and run them without being a developer. Depending on the automation problem and the technologies used, the complexity of these robots can be trivial to extremely high, which will then require specific software developments.

Nevertheless, while such an approach is already useful for automating many tasks in a wide variety of contexts, it leads us to consider back-office jobs in a different way. If a robot can do a large set of tasks without human intervention, what will be the real use of our software? What will be the usefulness of our user interfaces and their ergonomics?

Shouldn’t our solutions become APIs providing only services? Are these services then coordinated/piloted/orchestrated by software agents or robots? The RPA, therefore, leads us to ask a fundamental question about the design of our future solutions. What will the back-office tool in financial management or human resources look like if tomorrow 80% of its functions are executed by a robot?


The Robotic Process Automation or the RPA approach, which was timidly highlighted in 2012, has gained strong interest since 2015 (Figure 1). In 2019, according to Gartner Consulting, RPA market estimates were $1.3 billion. The RPA was born from a simple observation: a significant amount of the daily activities of the back office are carried out systematically and can, therefore, be automated.

Figure 1. Google trend analysis of “Robotic Process Automation” searches from 2012 to today (May 2020)

The RPA has not emerged from a sudden technological or scientific breakthrough, nor does it propose a revolution in its operation. Today, it is a collection of technologies that, put together, automate the most streamlined activities of our organizations. This makes it a real opportunity for innovation in all of our management products.
The RPA approach, therefore, proposes to automate all repetitive and extremely deterministic tasks; i.e. leaving no room for ambiguity and therefore not requiring the intervention of human intelligence. We can note that a significant number of back-office activities meet these criteria. De facto, a large number of administrative activities are candidates for the use of the RPA. We give some examples in this document.

Robotic Process Automation (RPA) is a way to increase the automation of repetitive and deterministic business processes. It is not a particular technology.

Cases of use are extremely numerous and RPA could form the foundation:

  • The disappearance of a set of repetitive, low-value-added tasks
  • The emergence of imposed and exogenous software interoperability
  • From a cognition distributed  between man and machine

Understanding RPA

In the end, RPA is difficult to pinpoint simply because it is a polymorphic phenomenon, involving different levels of automation, a wide range of technologies, and very heterogeneous applications. So we propose to establish a definition that is unique and argued in terms of different points of view and the current state of the art.


Table 1 lists a set of definitions from a variety of sources and highlights salient terms.

RPA is an umbrella term for tools that operate on the user interface of other computer systems in the way a human would do. RPA aims to replace people by automation done in an “outside-in’’ manner. (van der Aalst et al, 2018)operate on the user interface in the way a human would do
RPA (Robotic Process Automation) is an emerging technology involving bots that mimic human actions to complete repetitive tasks. (link)bots that mimic human actions repetitive tasks
Robotic process automation (or RPA) is a form of business process automation technology based on metaphorical software robots (bots) or on artificial intelligence (AI)/digital workers.[1]. It is sometimes referred to as software robotics (not to be confused with robot software). (link)business process automation software robots artificial intelligence
Robotic process automation (RPA) is the application of technology that allows employees in a company to configure computer software or a “robot” to capture and interpret existing applications for processing a transaction, manipulating data, triggering responses and communicating with other digital systems. (link)configure computer software capture and interpret existing applications
Table 1. RPA definitions and diferentiating terms

These four definitions highlight several important aspects of RPA. A first essential trait tells us that an RPA system reproduces what a human will do. Then we find aspects relating to the nature of the task itself that would be repetitive and part of a  process. Second, these definitions highlight how the RPA system runs, which would be configured software that would use the user interface of existing applications. Finally, the definitions mostly refer to Robots or “bots” which emphasizes a strong autonomy of the system.

Our definition of RPA will, therefore, be: Software configured to independently exploit the functionality of existing third-party applications for the purpose of running all or part of a business process

As a result, several characteristics emerge from an RPA approach:

  • Defining a Process: Defining such a robot requires modeling a process. In our case, a process is a set of actions that have transformative power. Data provided as input is processed and returned to the exit. For example, recording social data and a CV into a candidate profile in an HR system is a process.
  • Autonomy: The robot must be autonomous. That is, it must be carried out on-demand or on a regular (and transparent) basis with the minimum of human intervention. In this sense, a background task performed every morning at 9 am is a self-contained process.
  • “Configurability”: The robot must be configurable. That is, it must be able to be adapted to a wide variety of situations (data, application environment, interfaces) with the minimum code possible. Without this “configurability” aspect, the robot would look like classical software development.
  • Interfacing with existing: the robot must interact with a previously existing application environment. It, therefore “exchanges” with other software via their APIs or directly by controlling the user interface.

It is essential that these four properties are respected to speak of RPA. Otherwise, it is a classic software development.

Traditional automation versus Robotization or RPA

The difference between a Robot that manages a process autonomously and a background task, or a “cron” is relatively subtle and often misunderstood/perceived. The difference lies in how to approach the automation of a business process. This difference is due to three key points:

  1. Technological difference: Conventional software development will initially rely on programming and the availability of API or other more complex integration methods (memory sharing, file sharing, socket openings, etc.). RPA mimics user interactions to create automation.  The unavailability of standards or APIs is no longer a hindrance to the integration of several systems as long as they have a user interface and data access.
  2. Conceptual difference: Similarly, the process is no longer modeled as a set of logical processing steps but as a succession of actions that a human agent would have performed. The focus is shifted from the processing to be carried out to the existing interfaces between the components/applications carrying out these treatments.
  3. Skill difference: Software development naturally requires programming skills. In an RPA approach, the focus being positioned on the sequence of user actions the robot design can be apprehended by a “non-developer”. In addition, many software studios (UIPath, Automation Anywhere, BluePrism, etc.) can now design, test, and deploy these robots with minimal training.

The differences listed above clearly highlight the strength of an RPA approach in comparison to a “classic” development. RPA can be achieved easily, without development expertise, by maintaining an extremely user-centric focus and by exploiting mechanisms such as UI control to facilitate integration. In addition, many tools exist and can now define the process that the robot will follow interactively via WYSIWYG (What You See Is What You Get) interfaces. Finally, in the long run, robots are cheaper than humans. Business process outsourcing solutions are more economical when automated and yield better results.

RPA differs from conventional automation in its ability to be implemented by non-developers and its focus on maximum reuse of existing applications

However, such an approach to automation today only responds to relatively simple automation cases and has a number of limitations. For example, an RPA is particularly performance-intensive and low in safety.

Our 5 RPA Levels: From Simple Task to Cognitive Agent

Like other levels of automation (e.g. the 6 levels of vehicle range, from conventional driving to total autopilot), an RPA can be graduated depending on the degree of autonomy it offers. This scale implies de facto increasing complexity. We have not found a clear consensus on such a scale, which is why we propose to adopt Berger-Levrault’s:

Level 1Classic automationIt is an extremely mastered sequence of tasks that leaves no room for analysis. This level is close to what we achieve with a macro. This macro performs a task and the software repeats it by manipulating (software) the operating system pointer and keyboard input.
Traditional keyboard/mouse input control technologies, Business Process Management, browser driver, API to databases, etc., are involved at this level.
The process is prescribed.
Level 2Adaptive automationIt is a first-degree increment and may require advanced functions to analyze the location of buttons on an interface (“validate” or “cancel”), recognize files, data formats, classify documents as an agent would have done by “habit.”
Generic artificial intelligence technologies are used at this level, especially to make screen reading.
The process is prescribed.
Level 3Smart automationThis third degree uses the ability to process unstructured data  and structure it for use in the process. For example, reading documents or extracting information from emails is part of the unstructured data that a Level 3 RPA can process.
Process-specific and data-specific artificial intelligence technologies are involved at this level.
The process is prescribed.
Level 4Learning autonomyThis fourth degree involves all the previous benefits but from a learned process. The robot observes the behavior of the agents, infers the underlying processes, and becomes able to reproduce them autonomously.  For example, a robot would observe the actions of an HR service for a few days, deduce the underlying processes and be able to reproduce them independently. The combination with The techniques of Process Mining is promising to reach this fourth level (Geyer-Klingeberg et al, 2018).
The process is inferred.
Level 5Cognitive autonomyFinally this last degree adds a step of optimizing the inferred processes,  implementing improvements and executing them. Learning and improvements can be done iteratively.
The process is inferred and improved continuously.

These five degrees illustrate a scale between a robot agent who trivially repeats a sequence of actions that have been exposed to him and an agent that includes an organization, data flows, and is able to execute them or adapt to any anomalies (potentially to propose optimizations). Note the proposed change in vocabulary between levels 3 and 4. We propose to slide from automation to autonomy, the robot demonstrating inference capabilities from existing processes.

Figure 2. Illustration of the 5 degrees of automation of the RPA proposed by Berger-Levrault.

Existing technologies can achieve a 3 degree of RPA. Degree 4 still imposes many technological and scientific difficulties since it is necessary to have the ability to automatically observe all (or very large part) of a human being’s activities in order to infer the correct process. In addition, the process of inference algorithms from the existing, so-called Process Mining, works well in laboratory conditions but still very difficult in complex environments in the field. Achieving degree 5 is still purely speculative.

In RPA, depending on the automation problem and the technologies implemented, complexity can be trivial as extremely complex

RPA and Artificial Intelligence (AI): An Efficient Combination

As shown by the previous five degrees artificial intelligence and RPA are very complementary, the second using the first. The first degree of RPA does not particularly require the use of AI, as the scope of execution and data is considered to be fully mastered at all times. Artificial intelligence technologies intervene when an adaptive factor must be used by the system.
For example, when a button on an interface is not always placed in the same place, it is necessary to “read” the screen to the robot. OCR (Optical Character Recognizer) and image recognition techniques using neural networks will ensure that the robot-controlled mouse pointer is located under the “validated” button and not “canceled.”
Similarly, when input data is not structured, AI can be used to analyze it. For example, in an automatic e-mail invoice processing scenario, modern Automatic Language Processing (NLP) techniques, such as AI sub-domain, can be used to extract information from the email and attachment. This is a trivial task for a human who can read the document and extract the relevant information but who needs to use AI to be processed by a machine.

For an RPA, the AI makes it possible to carry out sub-tasks involving unstructured data such as emails, documents, etc..

Artificial intelligence techniques are therefore an ideal complement to RPA for sub-tasks where conventional algorithmic processing would become too complex. They allow you to perform relatively simple actions with a very high level of reliability where the data is not structured.

However, the use of AI in RPA significantly complicates its implementation. A recent study by Mazars on RPA in finance shows that the success factors of projects are reduced to 50% when artificial intelligence techniques are involved.

Figure 3. Complexity of implementation and chance of success of RPA according to a Mazars study, 2019

Be careful, however, not to confuse an RPA with a cognitive agent. An RPA (regardless of degree) remains designed to unroll a process and ensure that the underlying data flows run properly. There is no intelligence per se, and an RPA does not have the ability to understand, conceptualize, or issue initiatives. RPA is not a new term foreshadowing the arrival of hypothetical Artificial General Intelligence (AGI).

RPA Candidate Activities

The purpose of an RPA is therefore to automate repetitive and streamlined tasks that are regularly performed by human agents. Compared to human performance, RPA has the following advantages:

Figure 4. The properties of an activity applying for an RPA

An activity eligible for the development and implementation of an RPA must be:

  • Dematerialized: It is essential that all sub-tasks of the activity be dematerialized. To date, we do not have physical robots that would manipulate paper documents or perform actions in the physical world.
  • Repetitive: Recurrent activities are good candidates for RPA simply because they make the cost of developing the robot profitable.
  • Rationalized: The activity must be heavily streamlined, i.e. there must be a “good” way to do it. You have to have the ability to clearly specify an information processing process.
  • Directed by a human: If the activity is already carried out autonomously by non-RPA software, then the development of a robot is not relevant unless the latter has superior implementation performance. If the robot can supplant a human then its interest in terms of efficiency and cost becomes obvious.

The complexity of the workable tasks can gradually increase (see the 5 degrees of the BL RPA). To date, technologies can perform tasks such as:

  • Open emails and attachments
  • Authenticate on applications
  • Move folders and files
  • Copy/paste
  • Filling out forms
  • Collect information on the web
  • Do calculations and checks
  • Extract relevant information from documents
  • Making choices based on simple organizational rules
  • Etc.

This non-exhaustive list illustrates a subset of actions that, when combined, allow for a wide range of back-office activities. Many sources cite examples of RPA being put into practice in a wide variety of occupations such as application testing, billing, quote generation, human resources OnBoarding, inventory management, web-based monitoring, etc.
As our Berger-Levrault solutions are largely aimed at the back-office trades, it is clear that the underlying activities are prime candidates for an RPA. Here are a few examples.


Invoice processing is an archetypal example of an RPA candidate. In the private sector, the classic scenario is to receive an invoice by email, read the information, re-enter it into the accounting software, bring it closer to the associated accounting imputation, and put it into payment. In addition, RPA allows for a large amount of verification that increases the quality of the process such as:

  • Double bill detection
  • Optimizing working capital policies to decide payment dates
  • Abnormally large invoice detection compared to a supplier’s usual invoices
  • Checking VAT rules
Figure 5. An illustration of the invoice processing process via RPA (link)

Tools, such as WorkFusion, use RPA combined with artificial intelligence to largely automate this process. They claim to be able to automate 80% of the work of processing invoices, the remaining 20% being dedicated to exceptions and special cases. The market leader in RPA tools, UIPath also puts invoice processing as a typical example of using its UIPath Studio platform.
Mindee, co-financed by the BPI, has built its business model solely on these activities of extracting information from administrative and accounting documents using deep neural networks. Its technology is considered a relevant brick in an administrative document processing process.

In the public, the processing of invoices is slightly different because the receipt of invoices is dematerialized via the Chorus Pro Bill teleservice. Therefore, there is no need to extract information from a PDF document because the receipt is already accompanied by the metadata of the invoice. The rest of the process, on the other hand, is an excellent candidate for the RPA. Reconciliation of the invoice with the accounting imputation can be carried out automatically as well as sending the items to the agent.

In France, a local authority’s budget is voted by voting levels (chapters, investment operations, payment appropriations on programs, etc.). The chapters are codified and regulated (e.g. 012 Personal expenditure). For the communes, it is today and mainly the M14 instruction that determines the budgetary nomenclature. Eventually, instruction M57 will be used for all local authorities. Each allocation is therefore extremely codified and standardized, there is little room for randomness. Orders/invoices with third parties follow this codification. The issuing of the order must be preceded by the setting up of an accounting commitment enabling the allocation elements to be predefined and to check (reserve) the credits that will be necessary for payment. The invoice is received via Chorus Pro Invoice. Via Chorus Pro, the invoice is accompanied by metadata, so there is no need to read the content of the document.

Human Resources

Human resources occupations also contain a large number of activities that are candidates for robotic automation. This applies to most management tasks such as processing expense notes, monitoring leave and absences, editing employment contracts. They can also update databases in case of employee events, such as a change of position, a move, or a work stoppage.
We detail a few examples with payroll management and recruitment.

Payroll management

In the vast majority of cases, data entry is done by the payroll manager. In the public sector, cases, where the officer seized these elements himself, are rare, with few communities equipped with HR portals. It appears, therefore, that this activity is a good candidate for the use of RPA. De facto, payroll managers have more time to deal with these particular cases such as bonuses, down payments, short contracts. Some examples of payroll management tasks and RPA candidates include:

  • Assistance in the seizure of variable items every month (e.g. absences, overtime, illness, etc.). Requests arriving by email or instant messaging can be analyzed and processed via an RPA to be re-entered into THE SI-RH.
  • Help with verification of returns  (i.e. URSAFF, retirement, pension, taxes (since PASRO), etc.). The various statements to the agencies concerned may be incorrect. Assistance in verifying these statements appears essential. The use of AI or RPA more broadly appears to be potentially relevant.
  • Helps control input errors on data used prior to the issuance of a payslip. An RPA combined with an AI can be responsible for identifying data that is outside the normal framework on an aggregated payroll data table. When the data required to create a payslip is produced, it is subject to the model that indicates its reporting to the standard. In this way, we think it is possible to automatically highlight non-coherent data and therefore ipso facto errors (which may come from input errors for example).  This topic is also part of the process of standardization of declarations called DSN (Nominal Social Declaration) widespread since January 2019.

From Recruitment and OnBoarding to Departure

In the recruitment process we also find a multitude of spots that are good candidates for an RPA:

  • The search for candidates is the first example. Posting job offers on multiple sites, collecting, and recording CVs are time-consuming low-value tasks. RPA can reduce HR functions to allow them to focus their attention on more important activities such as candidate selection and interviews. RPA can conduct automatic searches of candidates on social networks, pre-analyze and sort CVs, identify keywords and re-enter them in a suitable tool or simply on an Excel board.
  • The OnBoarding of new employees is repetitive and consists of a succession of small tasks: requesting equipment from the CIO, adding in legal registers, creating accounts and user profiles, booking badges, signing mutual and pension contracts, etc. These different steps are repeated with each new hire. An RPA can orchestrate and perform these actions effectively, especially in institutions that recruit intensively.
  • Departure management can also be automated by ensuring that access to different applications and data is removed. The RPA here avoids oversight and guarantees safety.

Huge Possibilities

Financial management and human resources are sectors that are preferred candidates for automation. This is because they involve a very repetitive set of tasks and that the framework for the execution of these trades is particularly standardized, regulated, and standardized practices. The scope of the RPA does not stop at these two sectors. Potentially ALL business sectors are affected as long as the activities respect the properties (cf. Figure 4) that we have listed.
Here are a few additional examples:

  • Classifying documents: Electronic Document Management (EDG) can easily be disrupted if a naming and sorting verification process is not in place. The organization of a GED can be delegated to an RPA that renames, ranks documents according to their origins, their contents, the time of year, etc.
  • Automatically processing and classifying citizen requests: public institutions such as town halls receive requests from their citizens through a citizen web or mobile portal. Their treatment can be particularly tedious and repetitive. An RPA can take care of verifying the validity of an application, assigning the relevant processing department according to its content, re-entering the information received in the adapted business software, and finally mandatory information intended for citizens to keep them informed of the progress of the procedure.
  • Extracting equipment information to fill a GMAO database: Filling an equipment management database can be particularly tedious. An RPA can read the equipment manuals, extract interesting information (serial number, maintenance periods, etc.) and re-enter them in the GMAO.
  • Processing support and support requests: Requests for support arrive in continuous flux when it comes to large-scale software such as Berger-Levrault’s. It is common for multiple requests to arrive simultaneously and deal with the same need or bug. An RPA can group them by topic, while identifying the team or even the developer able to fix the problem and producing a record in a project management tool (e.g. Atlassian JIRA). The work of the manager/project manager is reduced and above all the process is optimized.
  • Automatic software testing: Testing software is tedious but still essential to ensure it works properly. The testing procedures are extremely repetitive. An RPA could automatically replicate the user tests performed by the testers by manipulating the user interface (i.e. by controlling mouse and keyboard inputs) and thus automatically test much more frequently.


Many solutions are available on the market to make the principles of RPA operational. Each year, Gartner offers a « magic quadrant » to classify players in the market.
As shown in Figure 6, in May 2019, there are three market leaders: 1) UiPath  (US), 2) Blue Prism (UK), and 3) Automation Anywhere (US). There are also some open source solutions. These leaders offer the same type of offer that we detail below.

Figure 6. Gartner’s Magic Quadrant for RPA as of May 2019

RPA Studios

These solutions are all in the form of a development studio to define the robot’s behavior. The robots are then deployed on a web platform and can be piloted and monitored to determine how often they should launch and collect potential errors.

As Figure 7  shows, the studio defines a process, consisting of a sequence of atomic actions. The libraries available will include very basic actions such as launching a web browser, entering text, opening a file, downloading data, browsing a web page, analyzing text, connecting to a cloud account, etc. Actions that allow you to carry out daily activities of the back office. Note that it is also possible to record an action sequence on the desktop and replay it as a macro.
The success of solutions like UIPath lies in the immeasurable amount of action that can be achieved. The component library is extremely rich and ranges from a simple click on the screen to the execution of genetic algorithms. With UIPath, Blue Prism, and Automation Anywhere it is of course possible to develop its own components to extend the space of possibilities.

Figure 8. Illustration of the deployment of a robot with UIPath

The process once specified in the tool can be deployed on a cloud platform. Process robots can be monitored and executed by hand or autonomously. With UIPath, for example, the Orchestrator platform is available to deploy created robots. This platform can be deployed on any cloud infrastructure (On-Premise, Private/Public Cloud or Cloud UiPath). A mobile app is also available to monitor the execution of robots.
Turnkey RPA solutions such as UiPath, Blue Prism or Automation Anywhere are therefore designed to make RPA easy to access by non-experts or even non-developers. These RPA development environments add a layer of simplification to RPA development by offering a graphic editor and providing ready-to-use action component bookstores that can be combined.

RPA Studios provides a simplification environment for RPA development through large, ready-to-use component bookstores and by providing deployment and execution mechanisms.

Beware though, our first experiments with UIPath for web-scraping spots (i.e. collecting information on a website) show that if UiPath proves extremely effective for relatively simple cases, a developer will go much faster using modern scripting languages like Python for complex cases.
It is important to note that some examples of RPA studio exist in the mobile world. For example, Apple’s Shortcuts app can be considered a consumer RPA solution. It allows a non-expert user to set an action sequence, compile them into a robot (a shortcut), which will run on its own on-demand or at regular intervals. This is a first example, of RPA on mobile.

Figure 9. Apple Shortcuts app illustration.

RPA Open Source

To our knowledge, there is no well-established open-source solution. Because RPA relies on a set of action-executing components, a very large amount of technologies can be used to implement RPA, such as:

  • BPMN technologies (Business Process Modeling)
  • AI (Tensor Flow, Scikit-Learn, loud, etc.)
  • OCR
  • File managers
  • Internet browser drivers (i.e. as Selenium)
  • Deployment containers (i.e. like Docker)
  • etc.

A list of technologies that can be used to implement RPA would, therefore, be tantamount to listing all the components necessary to achieve any automation. Nevertheless, there are a few open-source bookstores to facilitate the orchestration of these technologies. For example, Automagica provides a Python bookstore that includes a range of components to:

  • Automate the browser
  • Automate the desktop
  • Automate Microsoft Office
  • Automating business applications
  • Mouse clicks
  • Image recognition
  • OCR
  • Remote desktop automation

Automagica also provides a web service to deploy and monitor robots developed in Python. However, this technology is reserved for Python developers with proven expertise because no graphical facilities are offered to build processes. TaskT is a .NET bookstore that also automates a set of tasks such as launching VB and PowerShell scripts, working directly with Excel spreadsheets, and performing OCR. TaskT is accompanied by a server to control and monitor deployed robots while providing an associated dashboard  (Figure  10).

Figure 10. The proposed robot monitoring dashboard not TaskT

In the same way, the RPA-Python and Robot Framework libraries carry a series of functions to control a web browser, mouse, keyboard or use an OCR.


In this report, we detailed the nature of RPA, the different levels of automation possible, examples of candidate activities, and some examples of existing technologies. This study shows that: RPA is not a technology in itself but a way of approaching automation. The challenge of automation is always the same, avoiding low-value added and repetitive stains and thus increasing cost and performance.
We have also highlighted that RPA is a progressive phenomenon and there is no unified and systematic process for automating trades. On the other hand, it is necessary to identify “opportunities” for automation that can be registered at different application levels ranging from the simple spot to the cognitive agent that analyzes and optimizes.
We’ve also shown how the strength of RPA is to rely on the reuse of existing applications, software solutions that already address business issues with their rules. The goal is then to coordinate, sequence, and make them interoperable as an agent behind his screen will. We also showed how artificial intelligence technologies are a toolkit that significantly increases the automation capabilities of tasks including unstructured data such as emails, documents,  or even voice.

Finally, the RPA now has a comprehensive, mature, and particularly feature-rich development studio that allows you to move from development to deployment and execution. Some open-source solutions are also available to test the approach.

More ...

Scroll to Top