What is a robot operating center?
What is a robot operating center (ROC)? And, more importantly, what role does it play in the intelligent enterprise journey? writes Pareto Automation's John Slagboom
Photo by Edgar Moran on Unsplash
The term ROC immediately riveted my attention. It was the first time I had encountered it and I have read hundreds of articles on RPA and intelligent automation over the past few years. There it was, in a recent piece written by Pascal Bornet titled How to Succeed in Your Intelligent Automation (IA) Journey.
Well over a dozen other RPA/intelligent automation experts and I had contributed to Pascal’s article. ROC, I suspect, might be a summarized interpretation of my contribution to the article—a synonym for intelligent automation ops dev used to maintain and enhance robots.
In a whitepaper titled BiModal RPA—The Struggle to Transition Through Cultural Ambivalence to an Intelligent Operations, with the help of Deepak Sharma and other experts, I define the “what”, “why”, “how”, “where”, and “when” of intelligent automation ops dev used to maintain and enhance robots—in contrast to project oriented intelligent automation dev ops, which is used to build robots. Both ops dev and dev ops automation teams report to a COE (center of excellence).
I especially appreciate Pascal’s careful attention to make a clear demarcation between the COE and ROC, and maintenance by a robotic operation center separate from COE:
“When the first robots are delivered into production, a robotic operation center (ROC), distinct from the COE, needs to be set up in order to manage business as usual (e.g. maintenance, escalation of issues, manage robot changes). Clear boundaries between COE and ROC allow each of them to have a stronger focus on their respective roles."
While various project methods like dev ops should be used to build robots, they are not optimal to operate them. This much is intuitive. Most, including myself, accept as best practice to use a COE for overall enterprise automation governance. This leaves daily operations of robots, that can be quite varied depending on the industry and processes being automated.
In my world of managed health care (MHC) claim operations, automation is very advanced—or at least chronologically mature. COEs ought to be a best practice by now; standard RPA fully exploited; and yet another two billion plus in automation ROI still exists that will only yield to what’s next in terms of cognitive technologies on the one hand and the most responsive and agile business models on the other hand. At the heart of the future, best MHC intelligent automation business model is an extremely advanced ROC, which is essentially the new operations team.
My automation theories and practices evolve out of this context, and therefore my definition of ROC includes the “business as usual” aspects of robot operations listed in Pascal's article; however, also extend far beyond it. My ROC is nothing less than an operation/IT hybrid team, where IT developers are embedded in operations, report to operation frontline leadership and are literally joint team members with operations SMEs. Robots are just another type of inventory worker along with humans. Both human processors and robots are monitored by the same workforce management software and are directly accountable to operations leadership, assisted by their SMEs and team developers working in a modified “agile” style.
Robots are just another type of inventory worker along with humans—both human processors and robots are monitored by the same workforce management software and are directly accountable to operations leadership
In the best setups, the operations supervisor/manger/SMEs have significant remote-control capabilities of their digital worker robots by a “cybernetic” arrangement via dashboards that update the robots’ custom rule engine decision matrix (see Autonomics or Cybernetic RPA). I am aware that such an ROC set up will transition effectively to a no ops model, where ops dev ROC and dev ops IT centric team effectively merge into one, very small team of elite professionals (which I address in my whitepaper AI Automation Legacy–The Robot Pilot).
Yet, it will be another five years before machine learning accuracy and process transparency issues are sufficiently addressed for full MHC operations adoption and perhaps another five years to achieve a no ops status? Ten years is a long time nowadays.
The question in the meantime for MHC insurer leadership is this: how are you going to automate approximately half of that remaining ten per cent of MHC claims? It’s worth another billion annually at least. Yes, you need to integrate cognitive technologies like computer vision and NLP now. However, most of that ROI is going to be through new business models a like a COE governing two distinct teams: dev ops and an ops dev ROC.
John Slagboom is a principal consultant at Pareto Automation. This article was originally published on LinkedIn Pulse and is republished here with the author's permission.