Author: Brian French, CEO and Founder of Salient Process
This is Part III of our video series on Hyperautomation.
In this video, we discuss building the Hyperautomation organization.
Previously we covered What is Hyperautomation and Scaling Beyond RPA to Hyperautomation.
In Part one of the “What is Hyperautomation” series, we covered the disciplined iterative of the infinite loop that is business-driven hyperautomation
[insert loops]
In Part two “Scaling Beyond RPA to Hyperautomation, we discuss
[insert picture]
In part 3 of the Hyperautomation Loop Series, we will be defining the organizational side of executing the Hyperautomation infinite loop. This chapter will be broken up into 5 sections to break it all down in an organized manner
Before we begin, we will discuss how automation is done today by leveraging the Digital Ops Toolbox. We start with breaking down the
If we were to break down the tool box, here is what it might look like:
Process Discovery/ Mining = Process Discovery
RPA= RPA or Task
iBPMS= Workflow
Business Rules Engine= Decisions
Doc Mgmt/ Ingestion = Content and Capture Automation
Chatbots/ Conversational AI = Chatbots!
This leaves us with AI / ML, iPass, and Low-Code.
By taking AI/ML and applying that across all of the capabilities within the Digital Ops Toolbox will gives us Operational Intelligence
Then we apply iPaas which incompaces the Analytics and AI Integration for connecting to other systems
And finally we apply Low-Code. Low-Code is something we can describe as something each capability should offer but it can span all these areas, just like Operational Intelligence and Integration.
Now, if we look at this picture, it looks seemingly well put together! We cover a lot of automation ground. For many companies, they have a lot of these components of the Digital Ops Toolbox already in place.
When you dig deeper, at least at most companies, these end up being verticals of automation and tend to be run in isolation from other areas. They’re effectively silos and there’s not a approach to automation across them.
Within each of these silos, there may be a methodology but there is no overarching methodology or governance across these automation silos. In addition, somethings you even have silos, within the silos- where organizations have each business unit determine what their approach to automation should be independently.
So then, you have an even MORE fractured methodology across these silos.
This effectively means we are looking across the spectrum of hyperautomation and not just stuck in our silos. We still need capabilities specific methodologies, but also need an overarching methodology across automation.
(Siloed View of Automation)
We need to remove the barriers between the functional areas of automation and make sure automation is being looked at as a overarching effort, rather than a myopic approach!
(Holistic View of Automation)
The first thing to focus on is the Hyperautomation Strategy Practice, which consists of:
Just for references, a Process Owner is someone who has
invested interest in making sure that is a successful one. Their bonus may be tied to how well the type of process in question performs. They’re also someone who is respected throughout the organization. People look to them as the implicit leader of that process, but it is not typically an official position at companies
Process Analysts and Minors is a key role for making sure all of your key processes are documented and for your specific automation efforts. You have these experienced analysts that are looking at this, not just from a process perspective, but an automation perspective to make sure your processes are running efficiently and effectively.
The second part is Hyperautomation Delivery Practice. This consists of:
Hyperautomation Solution Delivery is made up of the people that have the capabilities in the different Digital Ops Toolbox technologies. In other words, these represent the verticals mentioned above.
The Solution Delivery team has the capability to deliver expertise in those different technologies.
Of course in the Hyperautomation Delivery Practice, we need Hyperautomation Project Management but you also need Solution Architecture.
A Solution Architect is someone who understand at a high level the different technologies work and how they can best be combined to enable your business to get their work done faster and smarter with less manual and mundane work.
and lastly, you always need testing (Hyperautomation QA).
The third part is Hyperautomation Shared Infrastructure. This consists of:
At the time, it is out of scope for this particular discuss so we won’t be touching on this too much. All in all- it is more economical and scalable to have a shared set of capabilities and infrastructure that your Hyperautomation practice could access.
Lastly, we will need support throughout all of these phases.
As far as overall Hyperuatomation Organization goes, how would oversight work?
Within this structure, there needs to be a Hyperautomation Oversight Committee that would be essentially made up of key representatives the 3 spheres shown above, as well as support.
This group would be responsible for vetting project proposals that come from the hyperautomation strategy practice. The oversight committee is responsible for the roadmap for hyperautomation, and a for anything that spans the 3 spheres above.
Before we discuss how an oversight committee works… lets step back and …
This process role is one of the most important components organizations need to succeed at Hyperautomation. If we look at a typical enterprise architecture planning structure, Business Process Discovery fits in there nicely.
Typically, it is a shared service with process analysts or miners doing the process discovery and mining and then relating that back to the rest of the enterprise.
The Hyperautomation Strategy Practice (shown above) has analysts who are more focused on specific hyperautomation projects, and creating not only the “as-is” and “to-be” process models but whether and what parts of those processes are suitable for applying automation to. Of course, much of the grunt work of process discovery can be accomplished by process mining now… however, process analysts provide that last mile infrastructure.
A Business Executive would sponsor a project. The Hyperautomation Strategy Practice would take a look at that project and say “Okay… does this fit in for what we do within out overarching Hyperautomation Delivery Practice?”
to take a look at that process. That team could consist of one or more analysts from that strategy team.
(mentioned earlier in section 2, pt. 2: Hyperautomation Delivery Practice) would know across hyperautomation (or the digital ops toolbox) how these different technologies can help the company before more effective and efficient.
(mentioned earlier in section 2, pt. 1: Hyperautomation Strategy Practice) will be apart of the Virtual Process Team
We will need Subject Matter Experts for each swimlane in the process
at least at a high level. You can achieve this by the Process Mining or Manual Process Modeling (mentioned in section 3: Oversight) but truthfully- you need both. Process Mining can get you some of the data you need, but the last mile of process analysis requires human insight and knowledge of your business.
Once we have things documented,
or if it even makes sense to automate any of the processes. The approach recommended here, is to take a holistic view.
We want to find out what type of automation best fits with the type of work being done. We don’t want to take a process and squeeze it into a workflow or bpms solution. We don’t want to see if we can squeeze it into content management or make the whole thing run on by putting in RPA… We need to look at the process and say what types of automation makes sense based on the type of work being done.
We will create an orchestration that leverages the automation capabilities as necessary. This means it might be RPA, or it might be sequential workflow.
Or in some cases, the work might be so expert that none of the automation tools apply.It my just be a human augmented by artificial intelligence.
But the key is you have to look at the processes from a holistic perspective and determine what the best automation is to apply based on the work being done. That is the job of the virtual process team.
If they determine that its a fit within our overarching Hyperautomation Delivery Practice – The Business Executive is going to sponsor that project to proceed to the Hyperautomation Oversight Committee.
The Hyperautomation Oversight Committee is going to look at it, compare it against their roadmap, look at their bandwidth, etc. They’re going to determine, “Can we do this project given all the other things we have going on?”
If they say yes, they’ll go ahead and approve the project.
In order to have continuity, we are going to make that virtual process team apart of the virtual hyperautomation project team.
From there we cover the issue with the way organizations are approaching Hyperautomation today (silos).
We then propose a solution by leveraging a flexible and scalable approach to building teams for Hyperautomation.
