Rod Michael, Director, Global Market Access Strategy at Rockwell Automation once quipped that an attempt to automate a mess ends in an automated mess. Bill Gates echoed the same thoughts, probably a tad bit more eloquently when he said "automation applied to an inefficient operation will magnify the inefficiency". Witty remarks and cautionary quotes aside, the draw of automation is simply too strong. Streamlining of communication, visibility, accountability, operational efficiency, reduction in errors, improved governance, reduced TATs, reduced costs, better compliance; the sales pitch for business process automation is hard to ignore. Sooner or later, every enterprise will automate their business processes, if they haven't already. While this subject has enough material to fuel a few hundred PhD theses, I've listed out a few practical considerations for those who are making the move towards automation.

1. Solid systems - Automation will touch your core systems, be it your order processing, billing, provisioning, inventory management or transaction processing systems. The automation system needs to rely on near faultless execution of each of the underlying applications. Values from transactional systems need to be accurate and applications need to do as they are told. Integrity and availability of applications are probably the most important factors in enabling automation. Many enterprise processes rely on an event driven architecture where the events can be a simple one such as a customer request or transaction or a complex event based on a correlation of spatial and temporal characteristics of individual events. When applications trigger events and in turn business processes, the demand for application reliability increases. As the number of applications in scope increases, so does the multiplicative effect of their individual deficiencies. 

2. Transactions will fail - Either the requirements were insufficient, the code was poor, the testing suboptimal or the system administrators fell asleep. Irrespective of where the blame lies, transactions will fail and more often than one would like. The number of variables in modern business applications is way too high to guarantee zero runtime faults. In an ideal world, the processes automated need to have an underlying atomic commitment protocol such as a two-phase commit but in reality, the underlying applications were never built for automation. This means no rollback and no support for recovery procedures. This leaves the users with partially fulfilled transactions and intensive manual intervention for incident rectification. The design of processes must incorporate the deficiencies of the underlying systems or at the least, provide sufficient visibility to the process owners to recognize and rectify these failures.

3. Know what to measure and what to log - A commonly used adage is that you cannot manage what you cannot measure. This is particularly true for systems that automate business processes. Be it for measuring productivity and efficiency, identifying resource bottlenecks, ensure compliance or to enable process improvement, key metrics and events need to be logged. Equally important is the availability of key logs and records to enable debug and problem (both functional and non-functional) rectification when things do not go as planned. The distributed nature of the automation solution coupled with processes that aren't always linear make correlation of logs and events a challenge. This aspect needs to be a fundamental driver through the entire design process.

4. Factor in the flexibility - The only constant in business processes is that they change. The lure of designing a solution fit to purpose and delivering against an aggressive timeline is strong. Baking in flexibility into the solution is an act which more often than not affects cost, scope and time negatively. The cost of not doing so is having to explain why IT is not as agile as required by business. The pursuit of flexibility has to cut across all teams from business to analysis to development and operations but at the same time, strongly governed to ensure a balanced evaluation of benefits against the cost.

5. Stakeholders - Despite the overwhelming technical complexities that it poses, business process automation is never an IT project. Interestingly, stakeholders that are the most impacted by automation are the ones who find it most difficult to go through the daily rigors of a project of this nature given their demanding day jobs but ironically have the most influence over its success. It is important to ensure that key subject matter experts and decision makers from all affected verticals dedicate sufficient time and energy through the entire project lifecycle.

Finally, it is important to recognize that automation is a difficult nut to crack. Be it automation of IT operations, test automation or business process automation, the challenge of transforming legacy systems and processes and managing the change can be overwhelming. It would be good to bite what you can chew and perfect things as you go. (The views and opinions expressed in this article are those of the author and do not reflect in any way the organization represents)