Posts

Abstract:

Automation is another buzz word that creates a sense of extreme capabilities: we tend to think of it as our Savior for all problems or we dismiss it as yet another concept. Even if a CIO wanted to introduce automation, she is not sure of how to go about it.

In this paper, the author attempts to trace the evolution of automation and clear some misconceptions. He also proposes a methodology called DEER to get into Automation in a Corporate.

In the beginning:

Automation as a word has assumed different meanings over time. It is interesting to think of the situation when the word first came into parlance. In hindsight, we can see ‘automation’ was the opposite of ‘manual’. But when something was done by a man, where was the need for him to know that he could rely on something else (not somebody else) to do the task? Without such a vision, there was no need to give a term to what he does. So, how did the words manual and automatic evolve?

Anyway, leaving the paradox behind, let us look at automation. Probably Automobile is automation where the man, instead of ‘crossing the place manually’ used the automobile to do so. Then, maybe the term stuck: whenever something can be used instead of a manual task, it may be called automation.

It is interesting to note that the compiler design is achieved through what is known as ‘finite-state automaton’ – another use of the term.

Let us, again, leave the etymology of the word and let us look at how somebody can go about automating things in the Corporate world.

The definition that Automation is the opposite of Manual is convenient. It is also good enough for now.

Anything that is not done manually can be called as Automation and end result should be the same whether you do it manually or through automation.

Before proceeding, it serves the purpose to clear the wrong assumption that automation is always to save $.

Though saving $ could still be the ultimate objective, automation has two important dimensions:

• Without automation, certain tasks simply cannot be handled by a human. An example could be the handling of nuclear waste. Here we are better off with automating the task through a mechanical robot.
• Scaling up (doing more of the same activity) with associated boredom and chances of errors in repeated activities make automation a better choice than forceful engaging of human. Imagine the world of excel spreadsheet where the column of ‘total expense’ needs to be filled as the addition of three data: food, accommodation and tips. Without F9 (explicit or automatically triggered) manual updation of the cells will make life boredom and result in errors.

Automation: Hardware or Software;

One more dimension of Automation is that it could be through hardware/gadget/device or Automation could refer to Software.

The automatic disposal of garbage or driverless cars could be examples of hardware-based automation (and invariably including some kind of Artificial Intelligence too). However, in this article, the stress will be more on automation on/through Software.

Revisiting Definition:

Now, we will realize that ‘automation’ as ‘not manual’ will not be good enough for us. Automation in the context of this article is not simply a replacement of manual work, because we are not talking of applications/packages like ERP and Accounting. They also replace manual work – but our interest is not these ‘huge’ applications. (More on this later). We are thinking of ‘small’ level automation. For a better way to understand the difference, let us call these ‘small level automations’ as RPA (Robotic Process Automation).

For convenience, from this point on, we will use the term Automation to mean RPA, unless specifically mentioned differently. This is important to appreciate. For an analogy, you may consider a Lathe and a Screwdriver. Both can be called ‘machines’ (are you remembering any movie?) – but we are better off distinguishing between them.

Three major automation types:

Though there are several methods used in Automation (Software related), three major methods can be readily appreciated. They are listed below:

Most of the Automation in Software relies on an object model of a software or the API’s provided by existing software.

Now, you can easily realize that the extensions built on browsers or mail clients, such as Thunderbird are automation mechanisms that rely on the API’s or object model or special processes. The same kind of logic applies to MS Office Products such as Word, Excel and Powerpoint. The object models of MS Office can be used to automate several mundane tasks when you create an MS Office document or when you need to edit (mainly for consistency) an existing document. A small automation using Object Model is described in the next section as an example.

One inherent assumption behind the PDF document example is that the PDF was not a simple scan of the print-out but properly created one (by the client who sent the Purchase Order) from the document at his end. If it is just a scan, there could be one more step to convert the scanned document to a machine-readable document through OCR’s (Optical Character Recognition) which may be assumed a part of ‘Artificial Intelligence’ again.

Automation through Screen Scraping:

Automation through Simulation of User entry:

A readily appreciated application of this category would be automated testing tools. Through appropriate scripts, the tester may easily repeat the test conditions or work on a regression test.

An MS Office related Example

The author of this article has been using some simple automation as an effective tool for productivity. No RPA tools have been used in this situation.

The main objective of this exercise is to convert a series of images in a directory into a PowerPoint presentation. Done manually, it is going to prove a boring job and error-prone to some extent. Through the object model and VBA, the author wrote a module to insert the images one by one and expanding it to the maximum available area, without losing the aspect ratio.

Should we develop an Application, then?

It will not be a surprise if you are left with a baffled mind now: does it mean, automation is as good as an application that has to be developed as a regular project?

The emphatic answer is NO.

When you have to write a program to add two numbers, a very trivial example, you can just write the code and test it and declare it done. However, a System is going to call for more activities, demanding consistency. For example, the simple addition program may really be a part of the bigger picture: computing the tax for a month, adding the cumulative tax paid with the new amount and monitoring payment. You cannot just write a series of individual programs. Now, you get into a concept of ‘framework’ for development.

RPA tools provide this framework.

We looked at two examples earlier: automation through screen scraping and automation through user entries simulation. Assume we need to combine the two: the team leader will enter the list of members and expect the automation to cover both entries of one team member ID after another, pulling the results on the screen and then storing the answers. If one plans to do these without some kind of a ‘glue’, it is just going to be impossible or involve too many repetitive tasks. RPA tools provide this convenience.

As a special nomenclature, some RPA tools automate tasks through what is known as ‘bot’s, probably a short form of a robot.

Be warned. RPA tools are going to be costly. They normally work on a subscription model. But the justification they will provide will be in terms of the effective money one saves by way of reducing the overall cycle time, improving the accuracy of the results and re-deployment of resources in other areas.

So, how does a CIO really proceed: Follow the DEER

This is a question whose answer a CIO is going to seek. It may not be clear for her on what can be automated and how. For an application development, it is always easy to identify the requirement and talk to the vendors. For example, CIO may say that she would like to develop a system for automating the payroll. Here ‘automation’ term is really going to represent an application development, since as per our definition, automation means it is through RPA.

One may see that automation, as we talk of RPA is to fill the gaps and not for developing a (large) application.

How do these gaps come?

By way of answering this question, let us define the steps that can be followed by the CIO:

Drill List:

The CIOs are encouraged to review all activities that are happening in the company: whether manually or through an application (developed in-house or supplied by a vendor). Drill down all such activities to the lowest meaningful tasks. The guidelines may be to use a document as the basis or an individual worker as the basis. A special instruction is to ensure that all MIS reports are identified – as a direct output of existing systems or a pure manual work or as a combination.

Equal Neighbors:

The CIO arranges the tasks as a chain of events (there can be multiple chains), If a successive and the preceding tasks in a chain are both through an existing application, they may be passed. But if there is one (or more) tasks in between computer application tasks or repeated for data entry, the CIO should mark it as a potential place for RPA. If you apply this logic to the production of an invoice from the Purchase Order, the chain may be thought of as:

—————————————-

Receive the PO from the vendor as a soft copy, PDF

Take a print out and hold it in hand

Input the details on PO into a GUI

Generate the invoice

—————————————-

Here the CIO should ask herself why there is a need to read and enter the data manually. Why not the computer read it directly? (Another sub-query will be on the need to initiate a printout. Why not automate the printing of the PO when it is received? Yet another query could be why print at all? Feed it directly to the GUI. Maybe, here the CIO may conclude that for statutory audits and/or back up purposes, one may need to take a print out. OK, granted!)

It is repeated that the CIO identifies, for the purpose of RPA, only gaps and not the major computerization requirement. If manual tasks are interlaced between an existing application and the manual activities or between available reports and extra fields from the database, they are potential targets.

Estimate Urgency and Savings:

This is a step to prioritize requirements so that the high priority ones are scheduled first.

Produce Bots:

Through this step, the CIO arranges to develop the bots applying Agile methodology. The bots are developed by the developers and tested by the functional people.

The above methodology can be summarized by the acronym ‘DEER’ and serves to introduce automation in the Corporate by the CIO.

Conclusion:

The readers are welcome to share the feedback on the article with the Author. Also, they can contact him if there is an interest to explore RPA in their Organizations.