Hyperautomation is an effective approach to coordinating this transformation. According to Gartner, “hyperautomation refers to an effective combination of complementary sets of tools that can integrate functional and process silos to automate and augment business processes.” At Itential, we believe two of the most promising opportunities for hyperautomation will be gained through synergies between RPA and network automation and between ML and network automation.
The reality today is that traditional methods of managing the network only address between 30 minutes to two hours of a typical network change process that can span weeks of time, including ten to 20 hours of manual effort along with multiple hours or days of idle time. On average, network operators implementing automation only end up addressing between 10 and 20 percent of the possible work involved and ignoring 80 to 90 percent of the process that they could be automating.
So, what does the ignored 80 percent of the automatable network processes look like? Beyond execution, organizations are ignoring the opportunity to optimize and automate the entire network change process, from planning and scheduling to all the pre- and post-network health checks and inventory and change request updates. Along with these activities, there is idle time created by hand-offs between tasks. For example, a planning team may perform a scheduling task and hand the job off to an engineer to gather network addressing information. This hand-off may happen manually, via email, or in a ticketing system, but typically there is some amount of time that elapses between when the planner finishes their work, and the engineer begins theirs.
The resources required and transition time between these various stages call for an extensive amount of swivel-chairing between systems and the various people across the organization who must manually interact with disparate network management systems. Each of these manual steps has a cost and increases the error rate of network changes, driving fear and uncertainty in the organization every time a change needs to be made. To achieve end-to-end automation, organizations need to broaden the scope of their automation efforts to better align and increase the velocity at which they can deliver change.
With that said, we see RPA as a step toward a fully automated network, not an end goal. RPA’s focus is on streamlining interactions with existing applications, while the end goal would be to migrate off the existing applications (with their keyboard/user/human-centric focus on input) toward programmable systems. This will introduce a machine-to-machine-centric model, which in turn provides more speed, flexibility, and capacity while shortening time intervals by eliminating idle time. We expect RPA to continue to be used in coordination with network automation in the short term, especially in situations where a system or application that is critical to a specific business process does not have an application programming interface (API) for exposing its functionality.
For example, an internally developed inventory system may not expose an API. Instead, it may force users to interact with the database only through its user interface. If such an inventory system contained data related to the assignment of virtual local area networks (VLAN), and the network team wanted to automate their process for data center creation and operations, they would use a network automation platform. This will create automations for the end-to-end processes while using RPA as a sub-process to automate the interaction with the inventory system.
Ultimately, utilizing RPAs with an automation platform allows organizations to leverage tribal knowledge that teams possess without enforcing a steep learning curve for software development and new enterprise tools. This combination supports most organizations’ goals of extending automation initiatives beyond simple data analysis and single-step mundane tasks to seamless end-to-end automation.