As intelligent automation programs expand and evolve, the need to support and improve your digital workforce and bots also grows. This blog includes the full transcript from the The Modern Robotic Operation Center (mROC) in Action Virtual Webinar on December 8th, 2020 and and the YouTube video of the entire educational webinar: The Modern Robotic Operation Center (mROC) in Action. Featuring speakers from Ashling Partners, UiPath and Cushman & Wakefield.
The Modern Robotic Operation Center (mROC) in Action
Hi everyone, I appreciate everybody joining the modern robotic operation center, something we call the mROC at Ashling. We are really excited to be talking about this topic. This is something that is near and dear to our hearts and a lot of our clients hearts. So hopefully this will be part education and part collaboration.
So we’re going to go through the agenda. My name is Marshall Sied. I’m one of the co-founders of Ashling Partners. I myself come from the ERP process, re-engineering background, and I have never seen this much emerging technology thrown on both business and IT desks ever. This at times can be overwhelming. So not just on the capability front, but also on how we’re going to maintain and support in kind of a run state. It’s certainly something that a lot of organizations are working their way through. We think 2021 due to scale of not just volume, but also capability is going to emphasize even more the need to focus on the run and support side of the house. Which really kind of brings us to the conversation here today.
For folks who don’t know Ashling Partners, we really kind of simplify that, that world, we’re really all about kind of bringing to the world what the world needs more of which is, frankly, awareness and education. And then that leads to action, which leads to insights and improvement and self-awareness. So that’s really how we bucket ties, our services. And that’s really how we see the world within Intelligent Automation. Today, we’re really going to be focused on the sustainability and iterate and improve the piece which is really manifests itself in our world via our Modern Robotic Operation Center, which Charlie’s going to really got to leave that discussion here today.
Absolutely. All right. Thanks, Marshall. And thanks, everyone, for joining today. Really excited to spend the next hour together. I thought we would start with a quick round of introductions of the participants in today’s session. I’ll start and then we’ll work kind of left to right on the slide. So I’m Charlie Jacoby. I’ve been working in the automation space. For the last five plus years, I was a member of the leadership team for a scaled Intelligent Automation program at a large healthcare company. I now lead the Modern Robotic Process Operations Center at Ashling partners. So, with that, I’ll turn it over to Michelle.
Hi, everyone, my name is Michelle Yurovsky . I’m the lead for insights here at UiPath. And also for kind of all things analytics on the product side. I’ve been at the company for three years now. And I started off on the professional services team. So I was very hands on with customers building out automations and I got really interested in analytics and started focusing on that, and then I got asked to lead the charge.
I am Brandi Corbello, VP of transformation at Cushman and Wakefield. I really led standing up our capabilities internally and have been working closely with Apple on the mROC side.
I’m Thomas Mandel. I’m one of the senior analysts on the Cushman and Wakefield transformation team. So I’ve got to see the evolution and get to work with and interact with the mROC team on almost a daily basis with a lot of the processes and projects that I’ve helped to push through production and continue to support through that long term support phase.
Hi, I’m Dan Hart from NSK Americas. I’m the Director of Finance. We are a global, generally tier one, in some cases, tier two automotive supplier, based out of Ann Arbor, Michigan, I’ve been with an NSK for about 20 years, and most recently brought RPA NSK, about a year and a half ago going live. Thanks for having me.
The Modern ROC – A Critical Strategic Component
Okay, so moving on to the agenda. So we have four agenda topics for today, I’m going to lead off with a discussion around the modern rock and really talking about the modern rock as a critical strategic component as organizations look to scale automation. And then I’m going to turn it over to Michelle, who’s going to talk about unlocking data in production automations. And how we can use utilize UiPath insights to do that. And she’s going to do a demo of that capability as well. Then we’re going to have an industry panel. And Brandi, Thomas, and Dan are going to join us for that. And they’re going to give us some insight on real world experiences with production automations. And then time permitting, we’ll open it up for q&a.
So I’m just going to use the next several slides really to expand on what is the Modern Robotic Operations Center, give it some context, provide some definition. And then I want to do a double click into the release management capability, which is one of the core items within the rock, and has been important to a lot of clients that we talked to. And then I want to finish with why there really is a need for robotic operations as organizations are really starting to scale in the automation space, and how robotic operations is really been coming into focus of late.
So with that, I think a good place to start, you know, I think is Marshall mentioned how the space is evolving. We’re really seeing companies expand their automation footprint and with that is the need for a more modern approach to managing production.
This is a different space. There are different requirements than like standard application support that we’ve all seen in our past years. And so there are some really unique things that need to happen to have a successful automation program that has, you know, production automations that are supported on a day in and day out basis for what are often very mission critical transactions that those automations are performing. And having that in place is really going to allow organizations to be able to get to scale, and to really get the full value that that companies have been expecting, as they’ve been mining for use cases and designing the opportunities for automation. So with that, I think it is helpful to take a look back and get some context and some historical context on where automation has come and how it’s evolved. So if we look back, just in kind of that 2016 timeframe, companies were really focused on task automation. And it was a lot of desktop automation with manual triggers, that were macros that have been around for years, and many, many organizations were executing macros for core processes. Many of those automations on the desktop, and with macros were very siloed. They were per user or team and so you weren’t even really at the department level, you are within individual users and individual teams, within those departments. And it was really hard, there was business value, but it was hard to get your arms around, what is the full measurement of that business value? And how there’s got to be additional incremental opportunities. So then as we got into the 2017/2018 timeframe, we started to see the rapid evolution of RPA. And it really started out with an education on the art of the possible and to get people thinking about, okay, I was doing these task automations, prior, what’s really different about RPA? And what can it bring to my organization.
And obviously, you know, at the beginning of these things, there’s a lot of skepticism. So there was a need to really get to what is the opportunity for delivery of business value is this really real. So companies were getting educated on the art of the possible then doing some POCs, and pilots to demonstrate the capability and see if there was true business value, and then getting some initial production deployments. But the way these things were, you know, the way these projects and programs were really operating is, you know, the core team was engaging and everything. So they were, looking for the user stories, doing the education, implementing the POCs, and pilot implementing some of those early automations, and then managing those in production. And then as we got into , and 2019/2020 , there was there really wasn’t a, you know, an acknowledgement, I think that there really is value being realized. And not only value being realized on individual processes, but now we’re really looking at multiple process opportunities. And at the same time, there was a recognition of the convergence of adjacent technologies to RPA, like machine learning and AI and voice analytics. People are starting to recognize the power that RPA can bring in orchestrating some of these additional technology capabilities together into a cohesive unit to drive value through automation. That focus really allowed for a broadening of the use cases. So then the backlog of use cases started growing, because there were more applicable use cases. Organizations were really starting to increase production employ at production deployments and more and more companies were really looking to scale because of the demonstrated value.
So then we get to early 2020, actually at the end of 2019, Gartner terms, the coin, Hyperautomation, and it’s a concept really around, like targeting whole business functions in whole functional areas, and looking across those for all the automation opportunities and trying to wring as much, or trying to bring as much automation capability to those end to end business processes. And then the robotic platforms are really evolving as well. So now the evolution of these robotics platforms serve as really the hub for automation and orchestrating multiple capabilities and being able to use like an AI fabric or machine learning Python, Python algorithms to really harness all of those capabilities and drive even more value.
So with this, many more organizations, we’re getting to material scale in their production deployments. And with that, they were also getting to larger backlogs, often coming in through agile processes and work that was done to generate additional use cases. And so there was this convergence of more backlogs, more things into production, and a need to start thinking about specialization around support. And once things move into production, it’s you can’t have you know, one team who’s focused on upfront work, also managing all the things in production. There needed to be more sophisticated ways to monitor and manage those automations, to make sure that we’re that organizations were really realizing full business value from those.
The concept of the modern rock is something we’ve been talking about at Ashling for a while now. And there are really three levels to it. I’m going to spend a few minutes here talking about those and bring some additional detail to how we think about the modern rock.
So level one is core, level two is differentiated. And level three is strategic and strategic insights. So at the core, obviously, you’ve got to have some kind of service desk capability, the ability to receive issues, items, inquiries, and that’s really through kind of what we think of as a standard ticketing process. But what’s a little bit different in the automation space is because these, these automation capabilities are so transaction oriented, and often so instrumental in getting work backlog done, and business operations, etc. The SLA s and the response times, and the things that are needed by the business are a little bit different. So being able to have a automation defined service desk is really critical and core to the mROC. In addition to that, there’s some nuances with infrastructure, because virtual machines, virtual desktop instances are prevalent and at the forefront of automation, deployments and capabilities. And so the management of that infrastructure and ensuring that that infrastructure is up and ready and able to process at the volume necessary for these automations is another core component.
The other piece, and I’m going to do a deeper dive on this in a later slide, is application release management. So how do you take automations, you know, package them up and move them into production? And how do you do that when you have federated delivery teams and organizations, including more citizen developers than you do, maybe in other areas, citizen developers a relatively new concept in the automation space. Being able to have a consistent process to manage break, fix enhancements, regression testing, etc. So I’ll provide some additional detail on that in a subsequent slide.
At level two, we start talking about differentiated capabilities. This is where monitoring and Performance Reporting come in, and kind of the dashboards around automation. but if we think about what one of the key things with these automations is making sure that they’re performing not only successfully, technologically like the bot is starting picking up information and finishing from a technology perspective, but also that the volume of business transactions that are expected are flowing through that, and that that’s operating at those business transaction levels that are necessary for the business to be successful. So the monitoring is not just about technically, is everything working, although that’s a major component to make sure technically, everything’s working and things complete, as expected. But also, are we seeing the transactional volume that we’re expecting, and if we aren’t, who do we need to work with to make sure that you know, that that that can be remediated, so that so that the business can get the value that they’re expecting out of the automations. In addition to that, operations management, so business continuity, back capacity and optimization. So essentially, these bots are digital employees and the you know, one of the differences with digital employees is they can work 24/7 , or as long as an organization systems are up and available. So we can feed those bots as much work as they can get done in that period. They can run multiple process scripts throughout that 24/7 period, but keeping a close eye on okay, where are we really at with capacity can we add on to those bots? Or do we need to hire more digital employees essentially bringing in more bots is is a core component of what the ROC does on behalf of the organization.
As we move to level three, we get into strategic insights. I think that the ROC is going to serve as a critical bridge to the digital office. And as a part of that, as we talk about these bots, being digital employees, they need to be retrained, like when a process changes, just like you need to retrain an employee. Eventually, as these business operation, organizations evolve, they’re going to have a
staff of employees as we think of them today, human employees, as well as digital employees, and they will be stitched together and operate kind of holistically. But in the near term, there are some unique things that we’re doing in the in the ROC that are enabling those digital employees to be successful. And then having that tight of communication with the business teams who are expecting the output of those digital employees and have them as part of their staffing plan, etc. So that I think, is evolving, and I think the ROC will be a key bridge to the digital office. We also have a wealth of data available to us as we’re looking at these production automations, and what they’re processing. And so doing data mining against that and looking for continuous improvement opportunities within the automations that are running. But then also, importantly, identifying additional use cases that can be then communicated, you know, to COEs or other parts of the business to contemplate those for additional opportunities to realize value through the automation program.
As I promised, I want to just do a quick double click on the application release management piece. So having a well-defined and smooth operating application release management process and capability really leads to efficient, quality, and high quality production code migrations. And as a result of that, you get stability in production. Because if you’re not able to promote high quality code that’s been through a process, you’re going to have instability in production. So having a process like this in place is critical.
We hear from a lot of our clients, comments about segregation of duty requirements. So this is really how do we make sure that developers of code are not promoters of code. And that’s where the rock can play a really integral role in having that separation, which, you know, will satisfy audit and other requirements, etc. And as a demonstrated best practice. So, what I have here, and that I’m going to walk through is an example of how we handle application release management in an Azure DevOps environment. The way the process starts is that an automation developer would push code into a git repository, it would flow through these steps, and then we’ve built some custom capabilities to do extractions of descriptions and variables, etc. We’ve also configured a workflow analyzer capability, which is actually embedded in the UiPath robotics capability. So, we’ve configured that to look for the key things that demonstrate quality within scripts. If the script then gets through that, then we have met a certain quality threshold, that gives us confidence as we’re looking to move that into production. And then we finish out the process as we move here, with a push of key components of the automation into sequel tables. And then those sequel tables are linked to dashboards. Which are aggregated by build IDs. So we can have really good tracking of the code, the promotion process, and this really drives quality into our automation program.
With the ever expanding and evolving automation capabilities, the tremendous appetite that organizations have right now for scale, and the need to really have modern techniques to be able to get there. We are really passionate about the convergence of these things, and how this wraps into the concept of the Modern Robotic Operations Center. So with that, I’m going to turn it over to Michelle, and she’s going to talk about how UiPath insights can help to unlock data on production automation. So Michelle, I’ll turn it over to you.
Unlocking the Data on Production Automations
RPA is typically implemented because they’re looking for something, a goal. Whether it’s you want to save a certain amount of money, or a certain amount of time, or you want to increase maybe your compliance from 98% to 100%. Or you’ve basically been promised that there’s some outcome that you’re going to get from RPA. The question is, how do you measure if, after you’ve implemented RPA, you’ve actually met that outcome. So with that goal in mind, we’ve created a tool that is hopefully going to help you measure everything you’re looking for.
Data is the key to understanding your robots. We like to say robots don’t speak, they can’t tell you if they’re sick. They can’t tell you if something has gone wrong. So the language that you can speak with them as data. That’s why you need to have data driven development. And that’s why you need to be able to track your results with some reporting tool and specifically with insights, we’ve kind of tried to combine the best of both worlds as far as reporting goes. And we’ll dive a little bit into what that means in a future slide.
So when you start implementing RPA, usually what I’ve seen is a trend where customers are thinking about, okay, well, I just need to know if my robots are successful or not. I want to know how many processes I’ve run, very kind of operational metrics. The problem is, is that you focus on this operational metrics, and then it comes time to present this information to your leadership. The say, well, why should we invest in our pay again? And you can say things like, “Well, you know, my runs were 95% successful”, but that doesn’t actually tell them anything about what’s going on with your deployment? Is it meeting the objectives they asked for? Is it worth the investment? So part of the things that you need to be aware of is that you need to measure your deployment. But, you also need to be tracking business KPIs that relate to why you implemented RPA in the first place, whether that’s things like, you know, when you’re doing invoice processing, tracking, invoice number, vendor name, you know, things that help you report on specific metrics, like, how many vendors submitted invoices this month? And what was the most common error amongst vendors? And how much money is this costing our business right now, because we can’t process it, the things like that go under this kind of step two of optimize my processes, track those specific metrics, and via those metrics, understand how to further optimize your automation. So if you’re seeing that a certain vendor always has this error, and you weren’t accounting for that error previously, and you think other vendors will run into it, you add it to your automations as a condition to consider. It’s always this kind of loop, where you need to understand the outcome to further optimize development. This then helps you scale. Because if you’re understanding things like the benefits of RPA, you’re going to be able to make a much bigger case for why you should keep using it.
So what have we done with insights? The goal is for you to be able to measure both of those kinds of aspects, the operational things like what’s my success percentage, but also things like, how much time and money did I save?
Some things that we really focus on our out of the box dashboards, robot utilization, success rate of your automation, how long they took business specific outcomes, not in the out of the box dashboards, necessarily, but we’ll talk about this one, we have a special dashboard aimed towards time and money saved, then we have time and money saved, as you can see, that falls under the ROI dashboard, which is a totally custom template that’s made for you to kind of take as almost a base and fix depending on what you consider time and money save, because I have yet to see a customer consider it the same. Then for example, someone wanted to count the cost of air conditioning on the human cost side of the equation for money saved. So it really varies. And then of course, tracking things like errors.
So just some highlights about insights. If you’re already using orchestrator from UiPath, insights is currently integrated inside of orchestrator. So you set it up, and you just launch it from the same kind of place. So the UI you’re used to the experience you’re used to it’s, it’s all consistent. We also have alerts so that you can get notified of a various kind of range of things, whether it’s something like a threshold alert, meaning, you know, I hit 10 errors in the last 10 minutes or anomaly detection, which goes a step above. This is for you to see if things in your data are anomalous, without you having to specify what that means. So that’s backed by a machine learning algorithm that actually checks your data to see what is and isn’t standard for you.
Then we have dynamic dashboards. This is probably one of the things that I liked the most about the product is the fact that it’s, it’s so easy to just drag and drop widgets from one dashboard to another and also to customize. We provide a ton of formulas that you can use to take our dashboards and customize them for whatever fits your needs. I built the dashboards thinking that they cover about 98% of operational needs. And so far the feedback I’ve gotten is that they do a pretty good job of that.
We also allow you to forecast. So things like maybe the number of transactional errors you’re seeing, you can forecast to see what that trend is going to look like in time. That is also based on historical trends. So insights is all about historical data. If you’ve used monitoring before inside of orchestrator. It’s real time, but it lasts for 24 hours. So after 24 hours, you lose that data. Whereas an insights you can keep that data historically. So analyze up to, I don’t know, two, five years, really depends on your data amount, but we can scale quite large there. I’ve yet to hear of anyone hitting a bottleneck on time.
Lastly, we have shareable reports. So share a PDF or an image with someone that needs to see your report without actually having to go inside of insights and view it.
For those of you that aren’t familiar with kind of UiPath orchestrator, I’ll just quickly explain to you what this is. So, what you’re seeing right now is the insights tab inside of orchestrator. orchestrator is basically our command and control center for robots. So, this is where you kind of schedule jobs and deploy them. And also keep track of things like global variables, you want to reference across your automation. So, it’s really all about management and control.
Then when we come to insights, this is your homepage. These are out of the box dashboards. So, everyone that uses insights gets these dashboards, unless you don’t want them to, which is something that that we rolled out with our latest release. You can control who gets these dashboards and who doesn’t, based on what role they’ve been assigned inside of insights. There’s definitely a bunch of personas that would be using an analytics tool like this. Some of them are your standard management that has no idea how this works and doesn’t want to and just kind of wants to pop in and maybe interact with the dashboard, and then logout. Or you have more of the RPA developer side of things or a business analyst that’s pretty tech savvy. They want to come in and actually build dashboards. We’ve even been seeing process owners, like citizen developers that come in and want to build a dashboard based off of something they’ve automated. They can use any of these templates as a baseline. So, if we come into, let’s say, processes.
And the processes dashboard, we call out some pretty standard metrics, like the number of processes, you’ve run your success rate. And again, it highlights your completed jobs, your top 10 processes by runs and status, top 10 processes defaulted jobs. Just a tip, this kind of scatter plot is really good for finding data with anomalies, because as you can see, it’s really easy to tell that there’s something here that has disproportionately more errors.
Something that you’ve probably noticed if you try to build your own reporting, kind of display in a tool like Power BI, or tableau, if you’re using UiPath, is that you have to pick and choose whether you want data from orchestrator, or you want data from the robot logs, because the two data types don’t play too nicely together. So, we have out of the box dashboards for Power BI and tableau. But those focus on what comes out of orchestrator, and they don’t have robot logs. Error messages both come from robot logs. And that’s really the best way for you to get informed as to what has gone wrong in your automation.
If we want to interact with the dashboard, there’s a bunch of ways for us to do this. They come with pre canned filters, that today filter is turned off, you can turn it on if you want and then modify that time. We also have a folder filter, which is just a UI pass kind of the security segregation layer. You can also interact with the dashboard by clicking there, if we come back to this top 10 processes defaults to jobs. If you want to drill into why this dispatch queue item has, you know, disproportionately more errors, you can just click it. And it’ll add it as a default filter on the filters pane. And if we keep scrolling up, you’ll see it’s highlighted here, you now see the success percentage for it. You see the runtime stats for this process specifically. If we scroll down to error details, you also see the error specifically about this process and the number. This is a really good way for you to keep an eye as far as operationally how your automations themselves are doing.
Then if we go back to our out of the box set, which you can see here, you can go back to the homepage. We can drill into our robot’s dashboard. Something that a lot of people are concerned about is, are you using your robots effectively? Are you really making the best out of them? What do we think about on unattended to robots that can work 24/7 don’t need a human can work behind lock screens,
you can use them 24 hours a day. But if you’re only using them for three, as we are here, you have a lot of room to scale. So, robot utilization is kind of your key to understanding if you’re really using what you have effectively. It’s easy to know if you need to scale up or scale down. If you’re using three hours a day of a robot. If you only have three processes in production, this is an opportunity for you to automate a lot more inside of your business.
Here we have our total utilization across the robot type. Free scroll down, you can see a little bit more about average utilization per day per robot, which robot types you have. And then your top 10 robots with errors. So, this is a really easy way for you to drill into a specific robot that is having these errors, which probably links back to a specific cause. So maybe there’s something wrong with that machine. Maybe the one process that it’s running is built poorly, you know, you can use this kind of information to find out what’s going wrong in production.
Now we will more on to our ROI dashboard. This is kind of most of the templates. And the reason I say that is because time and money save is so subjective, depending on who you ask. The dashboard comes with this process baselines widget. And here we have the process name, the manual time and minutes take the human to complete that process, as well as the hourly cost. And these are all manual inputs. But a lot of customers want to add more dimensions to this instead of maybe hourly cost, they want yearly cost her instead of time and minutes, they want hours, or maybe they want things like business specific metrics, like points that they may be assigned. So, this is the place to do it. And all of the widgets on this dashboard depend on formulas. So, the time saved, money saved. All of these are using formulas that I’ll just quickly walk you through.
You’ll see here, this is all a formula. And it’s referencing that process baselines manual time. Because you can add and remove columns, you can reference whatever you want. So, if we come and look at how this is done, you see these are just manually inputted. So maybe I can put in a few more here.
And if I hit apply, it will reload everything. This is also a really great place for you to use forecasting. So, you can forecast let’s say your time saved over the next. I don’t know, week month, and it’s really up to you.
Lastly, let’s quickly talk about how you can use insights for business specific outcomes. The way we extract custom data that you’ve added to your workflows, is we create a new process table. Let’s look at launch email. This is a great example. So, it will be called process dash whatever that process name is. Then any custom fields you’ve added are going to be pulled out in this raw message section. Now the only custom field we’ve added is email. If we wanted to click to see what that email was, it’ll show up here, this is actually not the email this is the little bit more information this is about the mailbox.
But using things like this, you can also get like I was mentioning invoice number vendor name and create those use case specific dashboards that though they are referencing data from RPA are actually showing why you implemented it in the first place with real data that makes sense to you.
And with that, I think we’ve pretty much covered it.
Thanks, Michelle. Appreciate it.
Okay, so that brings us to real world experiences and our industry panel. So, I’m really excited about this portion because it really gets, it gives us a chance to hear from Brandi, Thomas, and Dan about what they’re seeing in the real world. So, with that, I thought I’d kick us off with Brandi and Dan, maybe just starting us out with, if you could give the audience a quick overview of your Intelligent Automation journeys and some perspective you have there. Brandi, I think we’ll start with you.
Real World Experiences: Industry Panel
At Cushman, our journey really started last April. So April 2019 , it’s crazy to think about now with a proof of concept with a larger, more end to end process, not just like really task automation, but really a larger end in automation process that impacts about, you know, 300 people. So coming out of that proof of concept that that group had signed up for a larger business case that we started working on, what would this look like to put into production. Our executive team was really excited. So, we did a top down assessment with our next level leaders on their, business units, and where opportunities could kind of fit inside of each of our business units, service lines, as well as back office functions. Coming out of that, that was late 2019, we had about another $15 million business case. At that point, we really had to start thinking about what does our internal capability look like? And how does a strategic partner fit into this? And that’s when we started really engaging with Ashling. On really what was run, and support looks like, because we knew people were excited. So how do we take off with this and not lose momentum coming out of the back half of last year. So, this year, has really been focused on standing up the team and standing up the partnerships throughout our organization.
We’ve kind of expanded outside of RPA. And we have, you know, machine learning model in one of our end to end process automations in production, we do have an LP and are stuck. And then we’ve started really using process mining. So, at the highest level, that’s kind of our journey, where we’re at today, and you know, really starting to look at shifting into our methodology of delivery. So moving from more of an a waterfall methodology into an agile methodology as we go into and really accelerate after we’ve set this up.
Thanks, Charlie. Yeah, so for NSK, we really started thinking about RPA, back in about 2017. And immediately our thought went to click ability and AP invoice processing, which I think is a common place a lot of companies start. There’s also concurrent with the deployment of Oracle EBS for all of our North American locations. So that was going to introduce all sorts of new controls and payables process or legacy system and actually resulted on us adding substantial headcount to the AP function to kind of resolve that. We knew locally that our Japanese parent party already had a relationship with UiPath. So it seemed like a no brainer to kind of start there. We just started discussions with them in about mid 2018, were put in touch with Ashling contracted with them to stand up a pilot automation to automate our PO based, purchase order based accounts payable invoices. That kicked off in about June of 2019, and went live in October.
Concurrently with that, we stood up an RPA Center of Excellence to oversee not only that project, but also sponsor sessions to kind of blue sky, other automation candidates across a handful of areas of NSA, but initially really focused just in finance. But present, we’re now kicking off our what we’re calling kind of wave two automations. We have three of them, one each and finance, HR and internal audit. We’re also introducing some additional enhancements to that API automation that we already have in place. We currently have, I’d say 30 to 40 really solid candidates in our pipeline, that are undergoing evaluation considerations and, and really, you know, now starting to think about expanding those pipelines into sales divisions, logistics, manufacturing, and all sorts of areas outside of just the back office.
Great, thanks for that, Dan. So, now maybe shifting the discussion a little bit to the topic at hand today around managing production automation. So, maybe I’ll start with you, Brandi on how did you really start thinking about at Cushman, managing your production automations and what are the most important benefits that you’ve seen so far? Since you’ve implemented the modern robotic operation center.
Coming from the consulting side have been in the industry for a little bit. So I would say we were first a little bit more proactive when it came to understanding that support would be needed. It looked a little different as we first started and got ramped up. But it was a part of like, our initial thoughts, we did want a different support team, then we did a Build Team, if you will. So we started thinking about that upfront, but then as you know, we thought about scale in 2020 , we started working with, with you all, Charlie, really on how do we, you know, make this a little bit more capable of handling scale and thinking about it differently. For us, it was more about keeping that separation of you know, not new automation, and then really like keeping the lights on for anything that’s in production, only because we knew the program that we had in place, and that the benefits wouldn’t be realized if we just kept the lights on for what got put into production in the first six months of this year. Also, I think, you know, it was more for a scale and velocity perspective. Additionally thinking about, our program is very end to end Process Automation oriented, not task automation oriented. So if you think about something failing, it’s a lot more critical for the things that we have production in production today. So really having that support allows us to create the scale as we think about a group of 300 people of relying on these automations in order to perform their jobs. So for us, that’s really, you know, the why, or the how we started thinking about it, as far as important benefits we’ve seen so far. As you know, with the ROC place there, you know, you all are catching things like prior to us having to send an email and say “hey, something didn’t work”. There’s really constant communication back and forth from our COE with the ROC on making sure those things turn on before the business feels it. So I’d say that’s one of the big pieces. And I think the second thing is really, we have a really strong group of senior analysts that are working with the business every day, and they can’t really keep the lights on and then help the business think about transforming their business, right. So this has really allowed our senior analyst to be able to spend their time appropriately on continuing to add value to their business partners. So I would say that is second part. The third aspect that we’ve seen from this, is just the thought leadership that we’re getting. As we think about operations and looking at the bridge that you had created, I still think there’s a lot that we can do. I think we have the foundation, but really excited to see, the differentiated piece in the strategic pieces start coming into play. We’re seeing it a little bit, but I think, for us, we’re starting to see that maturity start and really excited to see it kind of come through in the next year.
Great, awesome insights. Thanks, Brandi. Dan, In a similar vein, maybe you could talk a little bit about how you were thinking about it at NSK, as you were doing your early automations. You know, how are you thinking about the production management of those, and then maybe you could give two or three things that those folks listening today should consider as they’re contemplating, their automations in a production environment.
In regards to our vision at NSK, we a little behind Cushman and moving to the mROC. But it’s good to hear from Brandi that that transition has been a success. So we’re looking forward to that. But, as we sit here, presently, kind of ahead of putting them rock in place front, NSK, our business analysts and in our it function are actively managing the bots, reporting problems and opportunities through support tickets, as been mentioned. In the absence of the mROC, it’s really critical that we have internal resources dedicated assigned to monitor and ensure bot functionality, system uptime, that sort of thing. So issues can quickly be reported into our partners to help resolve them.
NSK doesn’t have a great level of knowledge internally that’s been developed yet. So, we’re heavily reliant on Ashling as a partner in that space on our single automation right now. But, you know, I imagine even with the mROC in place, having kind of moderately experienced internal people familiar with the operations to be assigned as key points of contact is really critical to the proper functioning of the design of this type of support model. You know, as it sounds like from Brandi’s experience, in our view, and moving to the mROC is really the advantages as for our analyst to be less hands on and shipped a lot of that monitoring, as well as tuning and improvement opportunities. We’re hoping, you to have a growing number of automations, picking up on wave two here, we really need to start paying more attention to our bot performance, which in our understanding is the mROC.
Further, our internal support analysts and others involved on our RPA trajectory really ought to be spending their time educating themselves. Learning to write scripts and simple automations and really growing our internal capabilities. Right now they’re spending a lot of time monitoring and maintaining our existing automation. As our RPA footprint increases, we really want to have a greater capability to further develop automations.
Finally, everything along the RPA journey really requires an executive sponsorship and support. Those at the top, and we’re fortunate NSK that this is the case, but really need to be committed to supporting the endeavor, through investment and technology, training and people for really to successful proposition.
Great. Thanks, Dan.
All right, Thomas. So, in your role as a senior analyst, as part of the transformation team and Brandi’s organization, I know you interface daily, probably multiple times a day with the mROC team. So maybe you could give some examples of how that really works, and how it enables you to address some of the challenges you face with the production automations that you have in place for your business partners across Cushman and Wakefield.
Thank you, Charlie, I think the two biggest points of impact that I noticed on a almost daily, or at least weekly basis interacting with the MROC team is first as you know, Brandi had mentioned the more proactive issue identification resolution. So prior to having that dedicated support function, I was in that role interfacing with the business anytime there was in an error that came up with a with a bot, or we noticed that a process hadn’t executed successfully, we’re now instead of me having to respond to that directly or receiving requests from the business, what we’re seeing is that the MROC teams identifying those exceptions responding within a matter of minutes letting the business know what the exception was that it’s being evaluated, and then usually coming back fairly quickly with a resolution to that issue with the bot run. This allows for free time to focus on supporting current initiatives and just to be there to get engaged with the team. And for the business, they’re seeing, almost immediate feedback when they see an error message they’re seeing someone respond to and get assigned to that right away. I think the other area of benefit with interacting with the team is just the very quick collaboration for more complex issues that we see during the initial phases of an automation being in production. Being able to hop on an impromptu call with the mROC support team, evaluate a new error that we haven’t seen before in the process and quickly come to a resolution and propose a solution on it and start having the team create and develop and test that fix so we can get the automation back up and running. I think that’s been a really huge piece for us as we think about Excel accelerating the time that we can quickly resolve these errors.
Great perspectives. Thanks, Thomas. So Brandi, Thomas, Dan, thanks a lot for the perspectives and sharing your experiences. That was great. I think the audience really appreciated it, and also appreciated you underscoring some of the key benefits of having a Robotic Operation Center in place. So thanks again. With that, Marshall, I think we’re going to kick over to q&a here. But before we do that, I think we had a couple polling questions that we want to share.
Question and Answer:
The first poll question is top priority for your automation program just at a high level in general. The second is about the dedicated team.
Production support is actually one of the lower ones at this point. So probably means that a lot of folks are still kind of building up the awareness and demand on the front end of their program.
And then for the second piece, a lot of organizations do have a dedicated team in place, whether that’s an external or internal or a hybrid. So that’s good, that should enable some scale.
The first question is around emerging tech, “what type of emerging technology are you guys leveraging in order to make your rock service successful”?
The second question is “Can you talk a little bit more about the handshake between build and run organizations?”
Sure, let me I’ll start out with the handshake between the build and run organization. So this is a really critical component, that transaction or that transition point, between build and run, it needs to be very planful. And, and I’ll explain the process that we use. We’re closely connected with the Build Team. And we understand what the pipeline is, which allows us to plan. What we try to do is based on the go live dates of automations is a couple of weeks ahead of time, we’re consuming the PDDs, SDDs, any documentation user stories that exist for the automation, that is going to be moving into production. And then in the week prior to production, we’re doing a code review with the development team. And then we’re involved, as we talked about segregation of duties in the promotion of the code into production. And when that when that automation goes into production, we have a hyper care period of two weeks,
give or take depending on the complexity, but we’re pretty consistent on the two weeks, where the developer is still accountable for ensuring that the automation is performing successfully and helping with any changes that need to happen in production, and the rock resources shadowing. And then at the end of that two week period that flips to a certain extent, and the main thing is the ROC resource becomes accountable for that production automation, they obviously can still reach out to the developer, but the developer is hopefully 100% focused on new development, new automation development. And so that’s really how we do the handshake between the Build Team and the ROC team.
And then the emerging tech questions a great one, we are very actively evaluating different capabilities, we’re looking at some AI capabilities to predict when bots are likely to fail based on data that we have in the logs. We are looking at some capabilities that can do some self-corrections, we’re actually looking at some support bot capabilities that we can basically custom build out that will allow us to do even more automated monitoring and management of bots in production. So hopefully that answers the question.
Great. Let’s go to the next q&a here. I’m sure we could open that one up to Brandi, Thomas, and Dan as well. But the next one, I think is good for the client panel here. “How do you assess business criticality of your automations”? And I’m assuming that’s related to how does that translate over to severity levels?
Well, you know, it’s interesting, like I think for us and you know, Charlie like and his team get to like feel this a little bit. A lot of the stuff we’re doing is you know, actually client facing deliverables. And it does impact about 300 plus people in each of our programs, so as we think about criticality, I would say, almost everything we have in production right now is pretty business critical.
So with that, it’s really the main driver of why we put into place 24 by 7 support, we don’t have like weekday support, just while like people are online, it’s 24 by 7, just knowing the mass of people that are impacted, and the fact that most of the stuff that is getting delivered by a bot will at the end of the day get delivered to a client. We haven’t really seen a situation, I don’t think but I could be proven wrong, that any of our processes are not business critical, because as I mentioned, we’re not really doing task automation. It’s all end to end automation. And really, it’s really important, especially as we start getting human in the loop components that we do fix whatever the bot is doing upstream or downstream, so the whole transaction will work to its entirety. That’s really where we’re at right now.
Well, I do have a question that came in for Michelle. So it’s about a future release integrations. “Are there any integrations that insights will have that aren’t there today with other aspects of the UiPath platform:
That’s a great question. So one of our key priorities for kind of the next year or two is to really build out those integrations with the rest of the UiPath suite. Right, we have everything from discovery all the way to measure, but not a super clear way to visualize all of that data in one place. And that’s really what we hope to use insights for. So you should be seeing integrations as early as early next year, hopefully, but definitely would like to have the whole suite integrated within the next two or three years.
We’ll ask one more, and then we’ll close. And I’m going to direct this one to Thomas. So I it’s a general question, Thomas, but I think you will have good experience to answer this. “How are you supporting non business rule driven automations in your program”? So I am assuming this is referring to no more than anything else at this point.
Yeah, so I can I can speak to this. So we have a automation that that I helped to execute and lead into production that has both a RPA as well as a NLG component to it. So we’re scanning in invoice documents, having those go through an OCR platform, and then there’s an RPA process that goes on top of that. So it kind of goes into that hybrid support approach of We not only have the UiPath side of the process, but we have the OCR side as well. So that’s something that, that I’ve been heavily involved in with the project that recently went live. So we’ve thought about in the two components of there’s the RPA piece of it, that is the same scope of what would be handled by the MROC. And then really, the OCR component of it is something that we look at from a continuous monitoring perspective more so on the business end, since there’s a human in the loop component to make sure as part of our production, monitoring and support, we’re not seeing items that get stuck in that queue to be processed, we’re seeing those actively get pushed through. We’re monitoring the accuracy of that, that feeds into the RPA process. So it adds on that additional layer of, we can make sure that the RPA process takes in all of those inputs once it’s received, and it’s executing correctly. But we’re also monitoring that the inputs from the OCR platform are in fact accurate. And if we are noticing any inaccuracies, how do we retrain that model effectively? So we get those issues corrected at the source, we put better data through the automation.
Thank you everybody.
This blog post includes the full transcript from the The Modern Robotic Operation Center (mROC) in Action Virtual Webinar on December 8th, 2020 and and the YouTube video of the entire educational webinar: The Modern Robotic Operation Center (mROC) in Action.