There’s no doubt that RPA is a liberating technology. Liberating in the sense that RPA allows users to automate existing manual processes. RPA is truly a step forward. However, despite RPA’s ability to bridge the integration digital divide, it is by no means magic. Successful RPA projects still require the right people, in the right places, doing the right things.
Roles in a Successful RPA Project
So, who are these people and what should they be doing to support a successful RPA project? Let’s take a look.
1. Process Designer. The Process Designer is usually a business user who understands the existing process and the vision of the desired process. While this role should ultimately be handled by one person for accountability purposes, it is important that the Process Designer works closely with all who perform the current process in order to accurately capture its nuances. Understanding and incorporating these nuances can make or break a project. Knowing and understanding that user 1 does something one way, while user 2 does it another way is critical. Ultimately, the Process Designer needs to fully understand these nuances and then either institutionalize or consolidate them.
The Process Designer is the keeper of the specification for the RPA project. They should be responsible for looping back into the specification feedback and changes made during the development and testing phase. Good RPA products should help facilitate this feedback loop.
2. Automation Architect. The Automation Architect is the person who builds the automation using the RPA tooling. Depending upon the tooling used, this role may or may not require developer-level expertise. While many RPA vendors like to brag that their automation studios do not require programming expertise, don’t kid yourself. If you’re looking to automate a process that involves rules and logic, it requires programming. Whether one is writing syntax or configuring loops and branching in a case tool, it’s programming, and the automation architect should have some experience in the discipline.
3. Production Manager. After a project is tested and rolled into production, it then becomes the responsibility of the Production Manager. The Production Manager is responsible for the following:
a) Ensuring processes are being triggered as intended (e.g. “Does the job kick off properly at 1 am each night?”)
b) Addressing inline processing bot prompts (e.g. “Invoice amount exceeds PO amount but order is a special order item – reject or accept?”)
c) Handling process exceptions – (e.g. “Invoice was rejected, now what?”)
d) Reporting bugs to the Automation Architect
e) Reviewing analytics and providing process improvement information to the Process Designer
Depending upon the depth and breadth of the automation, more than one person may be responsible for handling some of these functions in production. However, only one person should ultimately own the production environment and ensure the tasks are performed properly and looping feedback where appropriate.
Obviously, there is nothing wrong with breaking down these three high-level functions into smaller chunks and distributing responsibility accordingly. However, don’t overcomplicate things. One of the main benefits of tactical RPA is speed and agility. Since RPA allows us to streamline existing business processes and quickly take advantage of new opportunities, the last thing we want to do is bog these projects down with excessive layers of process.
Want to learn more about implementing RPA in your organization? Our knowledgeable RPA experts are always happy to be a resource! You can reach out to us here, and someone will follow up with you shortly.
Tag(s):
Workflow Automation