The word automation, reminds me of the famous movie “Modern Times” by one of the greatest entertainer and satirist “Charlie Chaplin”. This movie kind of sums it up.
When I started architecting the Robotic Process Automation (RPA) project for one of our client, I was excited, and as things started to clear up, I found it very difficult to get the overall picture, so many stake holders, with so many diverse interest groups. Everyone had a view of the RPA project specific to their respective area of interest. And this is quite natural. It became evident that in order to socialize the solution, as solution architect it is my responsibility to articulate the end to end high level picture covering all the stake holder’s interest before the solution is in place.
As a cognitive person my interests and curiosity runs wild at time and end up probing many seemingly unrelated topics. This helped to understand stake holder’s concerns and understand their point of views and articulate my understanding accordingly. Before I jump into the project learning and technicality (there are tons of literature available in the internet on technical aspect) let me share few of the thought collected and realized during the process of understanding the larger picture.
It is said, to understand a problem, we need to go to the root of problem. (I am sure, for the interest of the project we need not have to dig that deep to understand the root cause to this level as described below)
The Origin of the word Robot!
The word ‘Robot’ was coined by the Czech playwright Karel Capek (pronounced “chop’ek”) from the Czech word for forced labor or serf. Capek was reportedly several times a candidate for the Nobel prize for his works and very influential and prolific as a writer and playwright.
The use of the word Robot was introduced into his play R.U.R. (Rossum’s Universal Robots) which opened in Prague in January 1921. The central theme, in part, was the dehumanization of man in a technological civilization.
However, we should also remember,
“Humans were still not only the cheapest robots around, but also, for many tasks, the only robots that could do the job.”
– by Kim Stanley Robinson. (For those who don’t know, Kim Stanley Robinson is an American writer of science fiction)
So what is Robot in modern terms, the Oxford definition of Robot is as
“A machine capable of carrying out a complex series of actions automatically, especially one programmable by a computer.”
And the term ‘robotics’ refers to the study and use of robots.
I personally believe anything that saves human effort which is not enjoyable; dreary and repetitive in nature, should be automated.
Automation can be as simple as a Script or Macro. Coming from a programming background, I still love to code, and writing a piece of code/script/macro to do some repetitive job, gives me immense satisfaction. (Just to let you a secret, at one point I created a macro to update my stupid time sheet, and speed up many ritualistic reports).
As an Architect I have been involved in various initiatives to stream line processes. As a result I had to identify patterns, designed/created Frameworks, code generation utilities, create ORM tool configuration, create best practice and coding standard, review checklist, QA scripts, etc.
In a word I try to take away the artistic/craftsmanship part of coding as much as possible and convert it to some type of engineering repetitive process to yield same quality result every time. Thus things become dreary/un-interesting and repetitive for the developers. And hence automation comes into picture. I believe –
At the core of any automation the philosophy of de-skilling existing skillset is central. We should also remember that automation generates new skill requirements as well.
The socio-economical side of Automation
Can we consider the below picture as automation?
In this case instead of a robot human being is used, whose time and emotion is comparatively superfluous. Probably it all started with the industrial revolution and assembly line production concept.
The above picture still holds good in many societies where human effort and time is economically and ethically cheaper than automated machines. So there is a socio-economical side to the viability of automation. Many of the industrial and economic practices of yesteryears are considered immoral in today’s society. And this up lift in our moral conscience is possible due to automation.
“Let us remember that the automatic machine is the precise economic equivalent of slave labor. Any labor which competes with slave labor must accept the economic consequences of slave labor.”
― Norbert Wiener (for those who don’t know, Norbert Wiener was an American mathematician and philosopher)
Types of Automation
The ultimate justification of any IT investment in an organization, boils down to support their business processes, that speeds up individual tasks, eliminate or reduce human errors etc. Thus using robotics to automate any business process can be termed as RPA. Here Robot is referred to a software robots or artificial intelligence (AI) workers.
- RPA (Robotic Process Automation)
RPA automates simpler types of task. It takes away mainly physical repetitive activities that don’t need knowledge, understanding, or insight—the activities that can be done by codifying rules and instructing the computer or the software to act.
- Cognitive Automation
In cognitive automation, we need and depend on the knowledge base that a human requires in order to complete a task. Cognitive automation can deal with natural reasoning, language, and judgment. It can also establish context. There is a difference between the two. As of now, RPA as a technology is comparatively matured. Cognitive automation is in its infancy.
- Traditional automation through IT integration
Primarily the objective of this type of automation is to move data from one application/system to another. This approach involves hand-coding integration, and typically takes place within an enterprise. This remains a tried-and-true method for moving data from one system to another. Classic example is ETL, API, Services etc. using ESB, EAI etc.
In RPA the Robot mimics the actions of a human user interacting with the application user interface of a computer system. The software robot operates on the user interface (UI) in the same way that a human user would. Unlike the traditional forms of IT integration which have historically been based on Application Programming Interfaces (or APIs), which were system to system communication based on various application layers like data layer/service layers etc. which are software architectural layer beneath the UI.
Why Consider RPA over IT solution?
- Cost saving
If we look at any RPA initiative charter, most of the time, the primary driver seems to be cost saving in business process operation. And that is wrong. Cost alone should not be the primary driver, this will lead to functional and non-functional requirements to address immediate short-term financial gains, particularly a result of labor savings mandate. Take the opportunity to refine the business process as well.
- Time to roll-out and dependency on IT
At time using IT to automate certain scenarios, is costlier in terms of roll-out time and project initiation.
- Bureaucracy and Regulatory obligations
There are situations in many business processes, where certain manual steps or activities needed to satisfy statutory obligations. Most of the time these requirements are sudden and no time to automate through traditional integration channel. These are right candidates to use RPA just to relieve the stress that builds up in organizations.
- Check the Return on Investment (ROI) between RPA and IT solution.
One of the most common way, of deciding between the two is looking the ROI of implementation and run and maintain cost of the automation.
- IT department is too bureaucratic
Often business operations find going through IT frustrating because it’s so busy and bureaucratic.
Being a Solution Architect I feel this is not the problem of IT, because the nature of responsibility it has, demands it to be bureaucratic. The reason IT department gets worried is because of the disruptive, potentially disastrous effects of people playing around with IT in the enterprise without fully understanding how it’s going to affect infrastructure, governance, security, and all the important touch points that IT department is held responsible for.
- Requirement for business governed automation roll-out
It has been felt in most big organizations that business wants something relatively small, which they can manage to roll-out without or little IT support. If an RPA tool is usable, cheap, and doesn’t require much IT skill to implement, and an automation script/robot can be rolled out by the average operator in a business unit, it is empowering the business. It’s crucial, therefore, that IT is brought on board early to align with over all IT strategy of the organization.
Things to consider before selecting a process for RPA
Not all business processes are capable of being automated using RPA.
-
IRM and compliance requirement
There are business processes which need to meet certain compliance requirements. At times the RPA platform in question may not support requirements. To qualify potential business process for RPA, we need to take approval from IRM and other compliance authorities. These are better to be automated using traditional IT solution.
-
Do not make changes to the target application/system to accommodate RPA
There could be situations where certain steps in the business process generated output for human consumption, to carry forward the subsequent steps to complete the process. For example, a SAP system generate some PDF doc/ or image which a human operator will read to trigger the next steps. We should resist the temptation to change the target application (in this case SAP) to generate an output so that Robots can read it.
-
Incorporate proper support and governance model for the RPA platform
It is absolute necessary to identify the major support and governance checkpoints right at the beginning even before laying the first box of the RPA platform. This has the potential to delay the RPA platform roll-out and lead to cost escalation. Identify the necessary roles required to support and govern the RPA platform. My understanding is an organization’s support and governance model may influence the selection of RPA product and tool. During RPA platform product selection we generally ignore this. Most of the POC is concentrated to validate the technical feasibility to implement various business process scenarios.
-
Encourage development of best practices and Center Of Excellence
Creating an automation scripts and configuration of robots are equivalent to coding. If we don’t standardize it, it will be night mare to maintenance. A badly coded script (rouge script) has the potential to pull down the entire RPA platform.
As an organization if we have a long term plan, then we have to build Centers of Excellence CoE over time, which should include business operations, and developed skills and capabilities within that center. Develop experts who assess the feasibility of a proposal from a business unit. Develop skills to configure a robot, install it, and develop automation scripts, and controllers or admins who switch it on and off and plan its work and how it fits with human work and monitor the environment performance and exceptions. There should be some sort of continuous improvement capability and relationships with IT, governance, and security.
To move up the RPA maturity ladder CoE should lead the organization to come up with self-development kit where a template is provided and specialist programmers design the robot/scripts based on business patterns.
-
Periodically check if a Process needs to be moved to an IT Solution from RPA
Hold periodic review of the automated processes to check if some of them should be considered to be moved to traditional IT solutions. Primary parameters should be cost of maintenance, Robot crashing or failure etc.
And of course, if you have read till this line please do press the like button or drop your comments.