Six years into intelligent automation at TriNet, we’ve certainly seen many wins and impressive program maturation. Still, our operational structure isn’t without challenges. Recently, we noticed we were running into the same issues time and again, so we’ve begun to refine our operating model. And while this is an ever-evolving effort to streamline our process from pipeline to production, I’d like to share the promising operating model we’ve devised in hopes that it might help inspire your team should you also need some operational fine-tuning.
The Activity Owners
All process owners within our CoE reside within the RPA team. We’ve identified 5 activity owners to take the lead on specific actions during the pipeline-to-production process:
- Developer – We are evenly split between onsite and offshore US-based hours developers, as well as a few citizen developers who have completed the AAU Advanced RPA Certification.
- Tester – The dedicated person in charge of all test cases. Based on demand, other developers may chip in to help with testing when overloaded.
- System Analyst – The single point person who owns all the different applications being touched and automated, as well as who escalates any production issues.
- Platform Owner
- Solution Architect
The New Model
Our general model is designed for the Product team to work closely with business stakeholders to go through discovery and ideation efforts to create a business case. Together, they will formulate a business requirements document (BRD) that initiates a review with the Solution Architect. Next, key stakeholders from Business, Product, the CoE, and Security complete a risk and compliance review and grant approvals in order to move forward. From there, a user story is created, the sprint backlog is prioritized, and the opportunity is added to the bot catalog.
A new addition to the model is called BRD (1.2) Click-level. This addition was a result of a lack of detail we continually observed in the original BRD. This click-level includes all in-depth screenshots and details needed to design and develop an automated solution as necessary. From there, we complete the high-level design, development, testing, and deployment to production.
Considerations
Our thought process behind this generically positioned model was to not burden a single person from the Product team with creating all the use cases. Instead, we can tap any resource within the Product team to help replenish our pipeline. Additionally, although our System Analyst role is positioned within the RPA team, the broader intent is to be able to plug this role into any application team where it might be needed.
Work in Progress
I want to reiterate that this operating model is still a work in progress and not fully implemented, but we feel this orientation will greatly optimize our overall automation operations. As we continue to tweak I’m interested to know if anyone has done something similar. Your program may not be at this critical point yet, and Pathfinder has some great resources for you to better understand where you should focused based on your program’s maturity. But if this is something you’re working through or have ready ironed out, I’d love to hear your thoughts and suggestions. Reach out and let me know!