Congratulations! You now have not only the basic understanding of RPA and what it might mean to your organization, but you also have the details you need to get started and see the initiative succeed.

To summarize, first, what is Robotic Process Automation (RPA)? It is simply automating repetitive manual processes. Every organization has them. Perhaps it’s a manufacturing company that bills for its products. The salesperson sells the item and enters the order into the system. A clerk finds the name and price of the item based on some serial or other identification number, looks up the name and address of the customer, types the invoice, places it in an envelope, and puts it in their outbox. They then get the next order and follow the same process, day in and day out. A “Bot” (robot) could do this: read the order, look up the customer’s name and address, populate the fields on a blank invoice, and send it to the printer which may be equipped to fold invoices and insert them into envelopes. Then, once or twice a day, someone from the mailroom can pick up the invoices and send them. The clerk or clerks who were responsible for these tedious tasks are then freed to work on other tasks that actually take thought. Chapter 1 provided you with an excellent understanding of RPA.

If you have identified the need to automate processes within your organization, how will you get buy-in from senior management and line workers? If things are progressing well, senior management may not want to change. And line workers may fear for the safety of their jobs (this could be a real concern if one of the goals of automation is headcount reduction). By reading Chapter 2, you now know how to address these issues.

What should governance for an RPA program look like? How should it be structured? What roles should be involved? Who should sponsor the program? What will the sponsor’s responsibilities be? And what overall framework will the program operate in? It must be structured, but be sufficiently flexible to adapt to changing needs. How is that done? As you read Chapter 3, you learned the answers to these questions.

Once you have senior- and middle-management approval and have identified some early adopters, how do you find processes for automation? What are the key components to look for that might make a manual process a good candidate for automation? As you learned in Chapter 4, a manual process that is basically done the same way repeatedly is one that should be evaluated for automation.

How do you solicit processes for possible automation? Once word of the RPA program becomes public in your organization, there may be many people who will be interested. That is excellent, but there must be some orderly manner for them to submit their requests. Each request must contain some basic information so you can make your initial evaluation. Chapter 4 discusses the request form, and there is a template for this in the Appendix (Appendix 1). Feel free to adapt it to the needs of your company, but try to keep it simple. You don’t want people to feel intimidated by it.

When a manual process has been identified as possibly a good candidate for automation, you need to determine if, in fact, it is. You need to determine how much variation there is in the process, so you can know if it can be handled by a “Bot.” How is this done? You also need to estimate what the savings will be in time (and time equals money, as we all know). After you determine that, you need to estimate what the cost of automation will be, so you can determine return on investment (ROI). And are there other considerations besides ROI? What if your major competitor is getting products to market faster than your company, and management sees some of your customers moving to the competition? How do you evaluate if that is worth the cost of automating some processes to be more competitive, even if the money saved by automation will be minimal? Chapter 5 provides you with the tools you need to make these decisions. It also helps to understand that while the initial assessment may indicate that the process is definitely worth automating (cost of automation will save money: good ROI, etc.), as you proceed through the life cycle of the individual automation project, additional information will be discovered. Some of that information may indicate that the cost of automation will be significantly higher than initially estimated, or the cost savings will be lower. At that point, a decision must be made (and here is one area where the sponsor plays a role) as to whether or not to proceed with the project or cut your losses and cancel it. Doing so is NOT a failure; our RPA program is designed for incremental steps and corresponding milestones to evaluate the information and work completed in each phase. Excellent work may have been done during opportunity assessment, but as developers and others work through solution design (Chapter 6), they will uncover more information, and some of it may indicate unanticipated expenses in development or less savings than initially estimated. It is better to find this information now, than to proceed through the expense of the entire project, go over budget, and find that the solution does not deliver as anticipated.

What happens if, after obtaining steering team approval to proceed to the next step, you learn, in that new step, that complexity is greater than initially thought, or the savings will be far less than estimated? You know from Chapter 5 that this simply indicates that the RPA program is working as it should. It is incremental: you gain some initial information and make a decision about moving to the next step. If that decision is made, you gain additional information and then make another decision about advancing. At any point, you may learn something that reduces the feasibility of completing the project. That is fine; this happens and is not a failure. It is far better to proceed a short distance into a project and then learn that some initial assumptions were inaccurate, than to spend the time and effort to complete the project and only learn at the conclusion that the expected benefit will not materialize or the cost of creating the solution far exceeded the amount the solution will save.

As discussed in that chapter, there may be other roles that are required, depending on various circumstances in your organization. Tips on how to determine if there are, and what their responsibilities would be, are detailed.

Once you have your team established, and have identified some good candidates for automation, and designed the new Bot, you need to deploy it. There are many components to Bot deployment that may differ from the way you generally deploy new software. Chapter 7 details this information for you.

In Chapter 3, we introduced the centralized, decentralized, and hub-and-spoke models. In Chapter 8, we detail these models, with key information on their advantages and disadvantages to assist you in selecting the one most appropriate for your organization.

Today, there are many development methodologies: Waterfall, Agile, hybrids of those, Lean, DevOps, and others. All of them can be used effectively with an RPA program. There are some commonalities and some differences depending on methodology, and Chapter 9 provides the detail required to assist you in deciding which methodology is best or, if one is mandated in your organization, how best to incorporate RPA within it. This chapter also helps you understand some of the roadblocks you will encounter, in situations where you may need to work to successfully interact with a business unit that is using and familiar with a different methodology than you have chosen for RPA.

One of the advantages of RPA is its scalability; as things change within your organization (e.g., new applications introduced; company grows), RPA can change right along with it. David Chappell, in his article, “Understanding RPA Scalability: The Blue Prism Example,” describes RPA scalability this way:

No methodology or technology remains the same over time; it either evolves or disappears from the scene, replaced by something better. RPA is no exception. In Chapter 10, we discuss the latest trends you need to be aware of as you introduce RPA to your program. You will probably start with the basics of RPA, but Chapter 10 presents you with a clear idea of where you can take the program in the future and how it may benefit your specific organization.

The introduction of any new methodology always has risks. In Chapter 11, we explain areas that we encountered that caused us to pivot from the road we thought we needed to take to one that was smoother and more effective. Things we thought were quite straightforward still caused some people to question the validity of RPA. This chapter, of course, doesn’t list every challenge you may encounter, but by following its guidance, you will avoid some of the headaches we suffered through. Following the information in the entire book should prevent a few of your own headaches!

Finally, the book concludes with a detailed Appendix. Here you can find templates for all the forms described in earlier chapters, with complete instructions on how and when to use them, and how to complete them. You learned, of course, that these are excellent starting points for any new RPA initiative, but time and experience will help you to know if and how they should be tailored to suit the needs of your particular organization. We recommend, however, that you initially use them as presented herein.

To conclude, you now have at your fingertips everything you need to succeed with the introduction of a Robotic Process Automation initiative in your organization. We wish you every success as you embark on your RPA journey!