“A good design will actually design the company,” says Donald Norman.
Especially so, when a company desires the company of bots. All along, we have been telling you how RPA is the need of the hour, and the various processes and trivia involved in the project framework delivery. It is no surprise that the actual development and deployment process in RPA forms an extremely integral part of the entire project; and any errors in these processes can result in the creation of faulty bots. However, are processes directly handed over to the developers in order for them to bestow life on the process robots? Just as a home needs an architect to design its various chambers, automation also requires one to carefully construct a systematic framework to be implemented in the project. Let’s welcome the architects of automation, solution architects! In our earlier blog, we’ve already discussed, in a nutshell, 5 different job profiles in the RPA domain. We’re back with a blog, and today, it’s time to dedicate a few minutes and paragraphs to the persons who form the pillars of automation.
1. HAVE WE PLANNED OUT OUR PLAN ADEQUATELY?
While planning is a crucial step, one must ensure that the plan addresses all important and intricate phases and aspects of the venture, so that the implementation can be smooth and hassle-free. It is the responsibility of a Business Analyst to study the various processes of a business and then decide which of these processes may be automated. It is here that the Solution Architect steps in. The role of a Solution Architect begins when this automation idea needs to be put into practice, but requires a systematic approach for this implementation to be carried out.
2.CAPTURING THE AUTOMATION PROCESS FOR YOUR BUSINESS PROCESS
The Solution Architect devices effective process maps and comes up with relevant solutions that can boost the automation process to a great extent, and act as a framework for the RPA developers to easily step into their roles. The solution architect essentially designs two types of process maps or designs – PDD or Process Design Document; and TDD, or Technical Design Document. While the former design is aimed at addressing the ‘as-is process’ of the RPA project, the latter one attempts at capturing the ‘to-be process’.
Once the processes to be automated have been earmarked by the Business Analyst, the Solution Architect then carefully studies these processes, and determines how the automation can be carried out in order to meet the requirements of the company as evaluated by the Business Analyst. The Solution Architect has to constantly keep in mind the aims and objectives of the automation process that have already been agreed upon by the clients as well as the automation providers; while also presenting a tangible and plausible solution for automating the rule-based task in question.
3.PROCESS DESIGN DOCUMENT
The Process Design Document focuses on the overall automation process, from data gathering, process standardization and recommendations, to development, testing and deployment of the process robots. The solution architect constantly communicates with the Business Analysts and Project Managers in order to ensure that there is no disagreement between the persons involved in the process; and to bridge any discrepancies in the process.
It is after the development of the Process Design Document capturing the as-is process, that the Standard Operating Procedure or SOP may be devised in order to break down the complex processes and sequences of the plan and ensure easy programming. One also needs to design the process capture template, modeling standards and process maps, before the actual development procedures commence.
4.LET’S GET TECHNICAL!
Now, we have successfully completed the as-is process, and received a thumbs-up for the same from the clients, as well as the various other persons involved in the project. We have also successfully completed the recommendations phase, wherein the specific RPA processes to be carried out are earmarked, and the unnecessary ones are eliminated, with detailed analyses of cost benefits and feasibility. Now, our RPA developers are almost all set to take the RPA project to the next level by actually creating our bots. But…are we missing out on something?
The role of the solution architect does not simply end at producing the Process Design Document. While the PDD helps in identifying the various stages and phases of the project, this document is not sufficient in itself for the RPA developers to take over their herculean task. The Solution Architect now has to create and document another design specially dedicated to the RPA developers; namely, the Technical Design Document or TDD. The Technical Design Document focuses specifically on the guidelines to be followed by the RPA developers while developing the bot; as well as the technical specifications to be employed in the software. This document enables our able RPA developers to follow the plan through with ease, and with a systematic framework to fall back on during times of confusion or doubt. Along with the TDD, a Target Operating Model is also designed in order to chalk out the vision or aim of the RPA development project.
In this way, the Solution Architect acts as the backbone of the RPA development process; carefully setting up the foundation of the RPA project so that the construction may become easier and hassle-free. The solution architects ensure that the plan does not simply remain a shallow idea, but is made viable, plausible and accessible to all the persons involved in the project.