How Establishing a Strong Governance Framework for Intelligent Automation will Enable your Program’s Success
By Jonathan T. Hardy, Intelligent Automation and Digital Transformation Executive
Establishing a strong Intelligent Automation (IA) governance framework should be seen as the foundation upon which your program will build its success. In essence, what this means for your program is how it will engage the broader enterprise to establish a pipeline of automation opportunities, determine which opportunities make sense to move forward with, and how it will maintain those opportunities in production. However, governance is often seen as a burden that provides unnecessary bureaucracy that slows innovation and program velocity. While this can certainly be true if the framework is not well thought out, this should be considered the exception for that reason and not the rule.
An important concept to keep in mind is that Intelligent Automation is the use of technology to automate a manual process across the computer applications and systems utilized by that process in a deterministic, or rules-based, way.
Merriam-Webster defines governance as “the act or process of overseeing the control and direction of something”. By providing your IA program with a strong governance framework, you enable your program’s ability to establish controls that will allow you to ensure that the processes within your program are moving in the right direction and are sustainable. In addition, this can be further enshrined by articulating aspects of the framework with written policies, standards, and procedures. Particularly for Intelligent Automation, six critical pillars for your governance framework should be advanced:
- Engagement
- Delivery
- Development
- Governance
- Infrastructure
- Operations
Engagement
It is important to think of this pillar as establishing your relationship management function between the program and the broader enterprise. In doing so, you will want to create a communication plan to lay out your engagement efforts. An important part of this plan should be focused on educating the enterprise on what IA is and what IA is not, and on how IA differs from traditional software development.
This will pay dividends in helping the business find opportunities and level-set expectations concerning IA’s bot journey or lifecycle (from opportunity identification to deployment). It will also provide exposure to the enterprise on the promise and value proposition of IA, getting the enterprise aligned to what is needed to be successful with an IA program, and establishing a working relationship with senior leaders throughout the enterprise in both technology and the business.
Lastly, one of the final activities on a typical bot journey is called Benefit Realization. This is typically done once the bot is deployed for 6 to 12 months to ensure that the assumptions
made for the automation have materialized for the key metrics determined for your program. Reporting on both forecasted and realized benefits should be a regular and reoccurring expectation from this pillar. The ultimate goal of all of the engagement activities is in helping to build a robust pipeline of automation-ready IA opportunities (stable, standardized, and repetitive processes) that are proactively primed by a highly IA-educated and motivated enterprise.
Delivery
The Delivery pillar establishes how you will define and iterate through your bot journey or lifecycle from the current process understanding and documentation phase (As-Is), to the automation solution design (To-Be), and then the development to deployment phases in a continuous integration/continuous delivery fashion. For IA delivery, most organizations develop and deploy using Agile. In doing so, you will have your typical Scrum Master, QA Tester, and IA Developers. However, two roles on your delivery teams are critical to building robust IA solutions, and those are the IA Business Analyst and IA Solution Architect (or Tech Lead by some).
Also, typically within IA delivery, your IA Business Analyst (BA) is “quarterbacking” in the earliest phases of automating the process and providing critical support in the later phases during development and deployment. In the earlier phases, the BA is working to document the process, determine its feasibility, conduct walkthrough sessions with the subject matter experts to understand and document the As-Is process, and determine the solution design is working hand in hand with the Tech Lead throughout these phases.
From there, the BA will use the solution design along with additional technical input provided by the Tech Lead to write stories for the backlog for development purposes. Lastly, the nature of most IA projects are relatively small, short-term, and discrete initiatives, and given this, your project management approach should reflect this.
Development
While development does happen within the Delivery pillar, it should be thought about independently as a car manufacturer thinks about engineering. This is because many adopters of IA (or in its rawest form, RPA) often complain about how fragile automations are in production, the frequency in which they fail, and their low quality overall. While one part of this must be covered in the delivery pillar in ensuring that the exception paths are well documented from the current manual process and how robust the solution design is architected, a large part of it must be addressed in how the automation is engineered and developed. It is important to proactively create a set of standards based on the development best practices utilized for the IA platform that your firm decides to employ.
These development standards should be enforced using a formalized code review process that will ensure consistency of adoption of your minimal development requirements. In many cases, the failure of an automation has as much to do with the development approaches taken in building it as any other factor. The outcome that you want from this pillar is to ensure that the automations developed by your practice are robust, stateful, and resilient in production, and able to deal with minimal production environmental change without failing. If there are issues with the automation in production, then you want to ensure that the automation is engineered to identify and remediate issues quickly.
Governance
This is often a misunderstood and undervalued function within most organizational make-ups, let alone an expressed strategic pillar. This is a big mistake because a strong governance function can drive uniformity and consistency within your program and ensure that your program is ready for any audit, and/or regulatory reviews, that are common within industries such as financial services. In addition, your governance function should assist the program in understanding the risks that the program poses to itself, and the enterprise as a whole, and determine what controls should be in place to mitigate those risks.
Another central responsibility that Governance should have is to formalize your program’s own set of policies, standards, and procedures. By doing so, you are adding the authority of compliance to those activities that you feel should be mandated to the entire enterprise as musts and will have the assurance that audits will be conducted to guarantee those musts are complied with. The reason for this is to safeguard that regardless if you are federated or centralized, if your program is the central authority for IA within the enterprise, then you need to warrant that you have some clear rules for the road.
Finally, your governance function could help with things such as role alignment to the framework and bot journey as a part of creating and maintaining a RACI or with things like helping to draft needed RFPs for the program or reviewing SOWs working with teams like Sourcing, but these are not necessary core requirements to the pillar.
Infrastructure
This pillar primarily deals with the initial implementation and periodic upgrades of the Intelligent Automation platform that your firm decides is right for its needs. This means determining the architectural design for your IA infrastructure and deciding what hardware will be needed, how it will be laid out to support this effort from a diagram standpoint, and what scheme you will need to host your VDIs so that your digital workers will have a place to do their work. This will also mean devising a disaster recovery plan which might entail rolling your IA infrastructure from a primary site to a secondary fallback site in case of natural disasters, general failures, or other matters that could cause your primary site to fail.
It is important to remember that not having a strong disaster recovery means that your entire digital workforce will be at risk, including those who might be running critical processes for your business that you have decided to automate. Further, this pillar will have information security responsibilities and ensure that your IA platform and the automations that will run from it are properly secured, logged, and vaulted. Finally, in addition, this can also involve other auxiliary technologies like Process Mining or Intelligent Character Recognition (ICR) that will support your Intelligent Automation efforts with additional capabilities.
Operations
Once your automation is deployed, your Operations or Production Support team ensures that your digital worker “shows up for work” based upon a plan devised by its process owner per its solution design. However, some important notions must be understood by both your IA program and your process owners once their automation is in production. Firstly, the IA Operations team will monitor the automation to ensure that it is running as conceived and will report back to both the process owner and other stakeholders any issues with the automation. Secondly, the IA program does not own the process, nor the automation performing the process. The reason for these two notions is that accountability for the process should not shift from the business to the IA program. Like if they were managing a human worker, the business should be actively monitoring the output of their digital workforce to ensure that it is accurate and as expected.
Lastly, the responsibility for credentials management for the digital workforce should be maintained and managed by your Operations team. The reason for this depends on the organization, managing credentials for the digital workforce can be quite complex given the array of credential types, from Single-Sign-On (SSO), Non-Personal Service Accounts, to Third- Party credentials for applications and systems utilized outside of the company’s tech stack.
Some organizations will choose to mirror the human workforce for credentials, while others will use some hybrid approach; however, given the various credential types, there will be varying renewal schemes that must be centrally managed.
Conclusion
An important concept to keep in mind is that Intelligent Automation is the use of technology to automate a manual process across the computer applications and systems utilized by that process in a deterministic, or rules-based, way. Given that you are not building an application, platform, or system IA should be viewed through a different lens than traditional software development. Many IA programs fail because they are not deliberate in distinguishing the difference between these seminal concepts. What the pillars provide you is a sustainable structure where you can bucket all of your key activities and roles to organize and operate your program (your IA factory). Having a strong governance framework will enable you to build high- quality “Enterprise Automations” in a consistent, predictable, and repeatable fashion that is both inherently scalable and maintainable as it moves through your IA factory. Encapsulating your program within an Intelligent Automation Center of Excellence (CoE) is the natural next step in galvanizing the foundation of your IA program. If established robustly, a strong IA CoE will be the conductor of your IA governance framework and a cornerstone to your IA program’s success and your company’s digital transformation efforts as a whole.