Delivery process

This article describes examples of possible phases when delivering a process automation solution from the initial idea until the end-of-life of the automation.

The phases described in this article are not a strict guideline to follow, just an example of possible real-life phases during the project. The phases are not strictly chronological, either. Iteration can and should be used for learning and testing out ideas and possibilities.

Idea

Your company has a business process. The process occurs often, includes the same steps every time, and requires someone to complete it manually. There is not much thinking involved or decisions to be made, just following the same actions over and over again.

It might be that you have an idea for a process that can not be completed even manually at the moment. Sometimes automation tools can enable you to start executing completely new processes instead of just automating existing ones.

Processes that occur often and that can be documented in clear rules, and steps to take are good candidates for process automation.

The idea of possibly automating the said process might come from anyone in the business. Perhaps from the person completing the process or someone else involved in the process.

It all starts with an idea. Maybe you should automate the process? How do you know if automation would be possible?

Business case analysis and feasibility study

After having an initial idea of automating a process, it is time to estimate if it is feasible to automate the process.

In some cases, the process always contains the same steps and follows clearly defined rules on what to complete in each step. If the steps and actions can be documented comprehensively, and do not require intelligent decision making, the automation potential for the process can be considered high.

Sometimes the process might involve non-trivial decision points or contain steps that would be difficult for a robot to complete. For example, some systems might always require an "I'm not a robot" test to be passed to continue ("Select all squares with traffic lights.")

The feasibility study can assist with deciding whether to continue with further analysis of costs versus benefits or to abandon the idea of automating the process altogether. Sometimes it is possible to proceed with some other approach than process automation since automation is not always the best solution for your desired outcomes.

It might be feasible (technically possible) to automate the process, but is it worth it? You need to figure out if the gains from automating the process are good enough for your business to justify the costs of automation.

In some cases, automating the process can have a positive impact on your business. However, if the automation costs are high, the positive impact gained might not be worth it.

Automation is not always the best option to improve the process. It is a good idea to step back and try to see the big picture before diving into process details. Maybe the whole process can be removed if some of the earlier business flows are optimized or re-organized?

Sometimes the process is deemed necessary, but it might still be possible to optimize the process. This optimization should be done before automating the process. Simpler processes are typically easier to automate than complex processes.

Process improvement and specifications

After getting to the conclusion that automating the process is feasible and that implementing the automation generates positive gains for your business, it is time to document your process.

Before documenting the process, try to think if it would be possible to improve it or to make it easier to automate. If the current process is suboptimal, the automation will be suboptimal, too.

The documentation acts as a step-by-step guide on how to complete the process from the beginning to the end. There might be multiple decision points or various possible end states for the process. All of these need to be documented in detail to achieve a robust automation solution. The estimate of the effort of the implementation should be pretty clear at this point.

Creating this document requires in-depth process knowledge. It should be clear and unambiguous. The process definition document will act as the basis for the automation implementation. You might want to use videos or screenshots to communicate the process better.

Often it will take some iterating to get everything documented. The documentation can be updated when learning new details during the automation implementation. You don't need to try and get everything documented in the beginning. Make your best guess and proceed to implementation to gain new insights into your process and to learn about it.

Automation development

After creating the initial process definition documentation, the automation implementation can start. During the implementation, you might find new steps or corner cases that you did not foresee when creating the initial process definition. Iterating the documentation and implementation will eventually produce the first potentially production-ready automation solution.

Involve the business expert during the development to get valuable feedback as early as possible.

Build your implementation against comprehensive test data in a production-like environment.

You might want to experiment with various approaches when implementing process automation. Maybe complete the happy path first to learn if it is possible to complete the whole process or whether there were unexpected challenges that you need to overcome to continue.

After completing the basic flow, you could start implementing exception management, retry logic for some steps, etc. Finally, you could implement reporting and other end-of-the-process robots.

You might want to intentionally provide invalid data for the process to see if the robot can handle the situation with grace. You could use tools such as Chaos Monkey to simulate unexpected system outages.

Chaos Monkey is responsible for randomly terminating instances in production to ensure that engineers implement their services to be resilient to instance failures. - https://netflix.github.io/chaosmonkey/

Create documentation regarding the robot.

Acceptance testing

After iterating the automation implementation to the point where it passes the full process flow and can recover from or handle exceptions, it might be a good idea to let the process run and to be observed in a controlled but production-like environment.

It would help if you had plenty of real data to test against.

Involve the business process experts during acceptance testing, too.

Launching to production

Each process is unique. There is no single correct procedure to follow when launching the automation to production. Some processes might be more critical than others and require special attention. Of course, some general practices can be applied to all production launches.

After you estimate the automation solution to be ready for production, it is time to launch it. You should receive time and personnel to monitor the initial launch period carefully to react to unexpected issues promptly.

This would be an excellent time to update the documentation to its final format.

Support & Maintenance

The automation solution might need updating if and when the systems or the process steps evolve. You want to have people available to implement the required changes to your automation scripts.

The documentation should also be kept up-to-date when the process changes.

Summary

Delivering a robotic process automation solution is similar to a typical software development process. Involve business experts, use iterative practices, write proper documentation, use software development best practices, do testing, and monitor the solution when it is in production.