Boldly Automating Where No Automation Has Gone Before

April 28, 2008
Exploiting a new frontier in process automation pushs the productivity bar to new levels.

For the past 100 years, the mantra of our client's industry has been "one machine, one operator." A dedicated operator is responsible for all of the configuration and monitoring tasks of the manufacturing station. The machine's productivity is directly linked to the performance of the human operator.

In both theory and observed practice, humans do not perform repetitive tasks over long periods with high levels of accuracy and speed. To meet the client's objective of maximizing throughput and minimizing costs, the inherent inefficiencies of the human must be addressed.

The obvious approach is to remove, or at least minimize, the dependency of the human operators. This is much easier said than done. The machines used by our client are typical of large manufacturing stations. The machines use a personal computer for interfacing with the human operator. Application software on the personal computer allows the operators to load, monitor, and configure the machine. Interim progress of the manufacturing activity is monitored by the operator via a display within the machines's application software.

In order to remove the dependency on the operator, the tasks performed within the application software must be automated. If the application software has the appropriate features already built in, process automation is straightforward. If those features don't exist, automation becomes must more challenging and most efforts come to a screeching halt.

One of our clients is a national leader in the printing industry. This client is very focused on high quality, low cost, and fast turnaround. They have achieved their market leadership by injecting innovation into a very mature industry. Of course, the software application used by our client does not provide the features or interfaces for process automation. Instead of conceding defeat, a solution was constructed and deployed using the WinApp Navigator product, a tool designed for process automation projects where no traditional interfaces exist. The tasks once performed by human operators are now being executed by software in an automated fashion.

The solution has been in operation with 10 printers for over 13 months in a 24/7 environment. Printers are loaded automatically with the new job information as soon as the preceding job is completed. The job information is keyed in via the solution software more quickly than is humanly possible and with 100% accuracy.

Detailed improvement metrics are proprietary but the increase in throughput exceeded the client's theoretical upper limit. The best evidence of the success is the age old policy of "one machine, one operator" is no longer followed. The new paradigm consists of a single operator assigned to oversee the operation of four printers. By bringing a new perspective and technology to an old problem, we were able to develop a very successful solution for our client.

How does one bring process automation to a software application that does not support it? Before that question is answered, let's briefly review the application automation realm. Software-based process automation can be partitioned into two broad categories, intra-application and inter-application automation. Intra-application automation deals with automating tasks within a single software application. Automation may be achieved with scripts, macros, and configuration changes within the single application. This type of automation is typically easy and inexpensive to implement.

Inter-application automation involves process automation which spans across two or more software applications. While the potential level of process automation is higher, inter-application automation is much more difficult to achieve for numerous reasons. One of the key factors is the integration of the participating applications. Since no automation occurs in a "vacuum," the target application must be presented with the data required for its processing. At the completion of its activities, the results of the tasks must be retrieved in order to be used elsewhere in the process.

Surprisingly, there is only a small, finite set of techniques in which to enter and retrieve data from the target applications. The types of techniques or interfaces include:

  • "Swivel chair" Interface -- This type of interface relies on a human user to manually enter data into the target application, retrieve the results, and enter the new data into a different application. The user must "swivel" from one application to another application.
  • Database Interface -- These interfaces insert, update, and read data directly in the database thus bypassing the logic within the application.
  • Application Programming Interface -- Application programming interface (API) is the most common type of interface. The vendor of the application provides an interface that can be used to enter and retrieve information.
  • HTTP Interface -- This interface can be used for web-based applications. The interface acts as a brower and interacts with the target application via HTTP requests.

Of these four types, the application programming interface (API) is the recommended approach. The "swivel chair" interface limits or even negates the benefits of the process automation efforts. Since a human is a key component, the process could be slow and error prone. The database interface approach works best for data retrieval tasks such as report generation. Inserting data into the database without being presented first to the application for it's validation, processing, and manipulation is not for the faint of heart. The HTTP interface is valid only for web-based applications.

The question that arises at this point is what to do in situations where an API is not available and the application does not support an HTML browser. Typically, the automation effort would be abandoned or the "swivel chair" interface would be implemented. There is another choice although it is infrequently used in process automation. The technique, called "GUI scraping", interacts with the graphical user interface (GUI) of the target application as a human user would. A GUI scraping interface can start applications, navigate through dialog boxes, and enter data into fields. This technology has been used in software testing environments for several years but it has not been leveraged in process automation solutions.

There are three major reasons why GUI scraping interfaces are not widely used. The first factor is that the technology is largely unknown outside of the software development community. Even within this community the technology is used on larger, more expensive projects. It is typically not found on small to mid-size projects. The second factor is the tools that have the capability of GUI scraping are focused on software testing and not process automation. The costs and developer expertise associated with these testing tools can be significant. The third factor is blind arrogance on the part of the technical decision makers. Since the technology is not well known, the opponents claim that it can't possibly be valid.

Our experience shows that this technology is very valid and the increase in productivity easily justifies the associated costs. We are currently taking this technology to other industries in desparate need of process automation. The leading project makes health records personal by providing the patients their medical records in a low cost, automated fashion. It involves the automated retrieval of health records from a clinical system and the automated, secure delivery of the information to the respective patient.

Increasing business performance is a never ending quest. Costs must be driven down, quality must be raised, and schedules must be shorten... always. A critical component in the equations of business is process automation. With so much potential benefit, it should be encouraged, it should be leveraged, and it should be exploited. To enable process automation in ways never before possible, GUI scraping technology should be considered as a valid tool in this quest.

Jim Ladd is President and Founder of Wazee Group Inc., an IT consulting company delivering solutions, not problems, to their clients. http://www.wazeegroup.com

Sponsored Recommendations

Voice your opinion!

To join the conversation, and become an exclusive member of IndustryWeek, create an account today!