Robotic process automation can be applied across departments, from HR and Customer Service to Finance and Operations. 70-80 per cent of rules-based processes can be automated,
Rita Brunk | Genfour
The opportunities for automation are plentiful - robotic process automation can be applied across departments, from HR and Customer Service to Finance and Operations. 70-80 per cent of rules-based processes can be automated, but what are the restrictions and barriers within automation?
Should I operate my mess for less or optimize first?
Implementing robotics process automation doesn’t mean that you need to upgrade and optimize your existing IT infrastructure. Robotic process automation is IT system and process agnostic, so no extra spend is required to get your IT infrastructure automation-ready. Automation works through any front end GUI, so is non-invasive, just like a human agent.
What are the barriers to automation within a task?
Automation lends itself to high volume, rules-based tasks that require extensive numerical calculation, such as payroll. The barrier for automation is usually where a task requires a more ‘human’ response. Robotics can, however, be used for ‘partial’ process automation, while humans tackle the trickier, more emotive tasks.
The health industry, for example, can deploy robotics process automation to take care of time consuming administration, freeing up healthcare professionals to spend more time with patients.
There are, of course, certain limitations to consider when regarding industrial robots working on the factory floor. In basic robots we design machines to do specified tasks, and in more advanced robots, or artificial intelligence, we design them to adapt, respond to, and learn from their environment. The function that the robot is intended to perform is a fundamental aspect of its design, and, indeed its barriers and limitations. Robots have basic levels of complexity and each level has its scope for performing the requisite function.
Are robots restricted to transactional work?
The kind of robots deployed in robotic process automation tend to be restricted to transactional work. In this instance, the term ‘robot’ is merely semantic; these robots are not physical robots, but robots that exist as software, built on computer algorithms.
Robots that go beyond transactional work enter into the domain of artificial intelligence.
What can/should a robot not do?
What a robot can or should not do is entirely dependent on the type of robot. For instance, robotic process automation robots lack the capacity to deviate from their preprogrammed function, and so cannot perform tasks where they are required to engage with humans.
Until recently, robots deployed on the factory line could not be used in areas of production alongside humans, as they were deemed to be too dangerous and there were limited mechanisms in place for intervention, should an incident occur. The new, plug-and-play generation of industrial robots are a more reactive, lighter weight version of their predecessors, thanks to advancements in sensor and vision technology. If a human worker gets in the robots way, the robot will stop, enabling a collaborative work environment between man and machine.
Another recent breakthrough in industrial robotics is the capability to grab and grip small objects to perform more intricate tasks, such as mobile phone assembly.
While the limitations of what robots cannot do are becoming less and less, there remains an ethical standpoint which determines that a robot should not do anything that has the potential to endanger humans.
Are my ERP systems barriers to the use of robots?
Enterprise Resource Planning systems, or ERPs, are not barriers to the use of robots. Because the robot is programmed to mimic a human, the same access given to a human can be given to a robot. They just perform activities in the ERP, but they do not they modify the code. Because the robot is ERP agnostic it can pull data from multiple ERP systems.
For example, it could pull employee data from PeopleSoft and incorporate it in a spreadsheet which has data taken from Salesforce and SAP to gather a salesperson's compensation data, projected sales (revenue), and revenue generated year to date. Today, in many cases, a human goes in and out of these three systems pulling the data and downloading it into a spreadsheet. Why not let the robot do it so that the analyst can maximize doing the value-added work which is analyzing the results.
Because the code in the ERP is not manipulated by the robot, the activities programmed can be done much quicker than if a change needed to be made to the ERP. This is why the payback on a robot is predominantly less than one year. Many of the ERP projects that were shelved due to unacceptable payback should be revisited via a robot.
Are my language needs barriers to the use of robots?
Robotic process automation can process from global, versus regional, perspectives, and is language agnostic. Robots are programmed in specific programming languages, so the language of the human deploying it are not a concern.
There are over 1,500 programming languages in the world, and each language has different advantages for robotics. Here are three of the top programming languages for robotics:
-
C/C++
A lot of hardware libraries use C or C++ because they allow for interaction with low level hardware, allow for real time performance and are very mature programming languages. As robotics is very reliant on real time performance, C and C++ are probably the closest thing that roboticists have to a ‘standard language.’
-
Python
Python and C++ are the two main programming languages found in ROS. Like Java, it is an interpretive language. The prime focus of Python is that it is easy to use, and there are a number of free libraries for it. As more and more electronics start to support Python as an ‘out-of-the-box’ program, it’s likely that more and more roboticists will adopt Python.
-
Java
Java is an interpretive language, which means that it is not compiled into machine code. Instead, the Java Virtual Machine interprets the instructions at runtime. The same Java code can also be used on a number of different machines.
Our next blog in the RPA ABC series will look at what steps business leaders should take in order to begin the robotics journey.
About GenfourGenfour provides a fully managed, digital workforce that consists of robotic process automation, cognitive technology and attended desktop automation. Our workforce rapidly automates your repetitive, rules-based processes, to deliver the most valuable and predictable outcomes for your business.
Rita Brunk is the Robotics and Automation Transformation Lead for the US at Genfour, the robotic process automation (RPA) and AI delivery specialist. Rita has seven years of automation experience within a shared services environment, which developed to incorporate robotics tools.
Prior to joining Genfour, Rita led a global shared services effort at Hewlett Packard for robotics. She opened and closed various captive shared services sites outside of the US, and several sites under her responsibility won SSON Excellence Awards for value creation in a mature shared series centre.
For the past 15 years, Rita has held a number of executive positions in a captive shared services environment focused on process optimisation and the development of analytics within the finance, HR, logistics, procurement and marketing functions. During this time, Rita oversaw large teams located in Michigan, India, Costa Rica, Argentina and Mexico. For the last two years, she led global efforts to reduce headcounts across all locations, implementing RPA to drive this progress.
The content & opinions in this article are the author’s and do not necessarily represent the views of RoboticsTomorrow
Comments (1)
Featured Product
