>> Narrator: Live from Las Vegas, it's theCUBE, covering UiPath Forward Americas 2019, brought to you by UiPath. >> Hi everybody welcome back to Las Vegas, we're at the Bellagio at UiPath Forward III, day two of theCUBE covers. theCUBE is a leader in live tech coverage. We go out to the events. We extract the signal from the noise. Erik Alexis here is the Vice President of Global Intelligent Process Automation at GE. Eric thanks for coming on. >> Yeah absolutely excited to be here. >> So, you guys have a COE, you're obviously heavily involved in essentially running the COE, is that right? >> Yeah that's my role at GE. I lead our Global Center of Excellence for intelligent process automation. Our journey started with UiPath a while back in 2016. So, it's been an incredible journey so far. >> And I want to get into that. So, before I do, I was struck by the Forrester analyst, Craig LeClair this morning made a statement. I don't know if you're in there, but he said, "Yeah COE, setting up a COE, "maybe that's asking too much." But I talk to a lot of people that have a center of excellence. Maybe it's definitional but what does your COE look like in terms of just it's role, size? >> Yeah it's a great question, so I think in terms of the role that we play more broadly, I mean we provide a lot of the technical expertise, the hands-on development and the operational support for our business units. And so we've really kind of developed that expertise over time, and we use our business units to really drive and identify the opportunities that come in through the COE. So, in terms of the size of the COE, we've got in total number of heads, we've got about 50 primarily technical resources there, that are supporting development as well as ongoing operation. >> Awesome, okay so let's talk about your journey. When did it start? What was the motivation behind it? How did you make the business case, and we'll get into it. >> Yeah so our journey started back in 2016, GE, we used to have a shared services organization that we had a very forward-thinking CEO at the time who wanted to really disrupt the way that we worked. And so RPA was something that was just coming out and kind of getting noticed by a lot of these shared services organizations. And so throughout the year we assessed a couple of technologies obviously landing on UiPath for a number of reasons. I would say in terms of our journey 2017 was kind of our year to prove the technology. We wanted to see if this stuff could really work long term and operate at scale. Given that I'm still here obviously, we proved that was correct and then 2018 was kind of the year of scaling and operationalizing kind of a sustainable model to support our business units across the board from an RPA standpoint. So, really building out a proper structure, building out the governance that goes along with building robots and building a kind of a resource team to continue to support the bots that we were at scale at that point, so maintaining those bots is critically important. And then 2019 has really been the year and I think the theme of this conference in general, a bot for every person I think that's the direction we're moving in 2019. We've kind of perfected the concept of the back office robot and the development of those, and running those at scale. And now we're moving towards a whole new market share when it comes to attended automation and citizen development. >> So, in '16 it was kind of kicking the tires it was almost like R&D. And then '17 was really essentially a proof-of-concept right so still a small team, a two piece kind of team kind of thing right? And then when you talked about scale, helped us understand what's involved in scale, I know it's also another big theme of this conference. What are the challenges of scaling and how did you resolve those? >> Yeah that's a very good question. I think it's a question that has been very common throughout this entire conference. I would say when I think about scaling what I've noticed over the past few years is that, the actual bot development is about 25% of the work that you need to do, right? When it comes to scale there is everything outside of the actual development is the important part. So, how are you funneling opportunities into a pipeline, how are you streamlining the entire process reengineering of fitting an RPA into an existing process, what's governance you have in place to make sure that the code of that development is clean and can be maintained long term? And then more importantly I think that people overlook, people think of scale as being able to develop a lot of bots. I think more importantly what scale is is being able to efficiently maintain a large portfolio of bots, and that's what I've realized this year. We've got now about 300 automations in production and your reputation as an organization is really on how well you maintain those bots, because if your bots are consistently failing, and you're not fixing them quick enough for your functional users to leverage them, then you lose a lot of credibility. So, I think that's been a big learning for us as we reach scale. >> That's interesting I mean I think about scripts, how fragile scripts are and you got a lot of 'em, and they almost always break. And so what is the discipline that allows you to have that quality of bot that is maintainable? Is it a coding discipline? Is it a governance? Is there other automation involved in maintaining those bots? >> No there is and I think the team that's under me, my technical team has done a phenomenal job of setting this up, but we've got some very rigorous standards that we've put in place around. We do have reusable components for example that need to be used on every single robot that goes into production, so that when I look at for example a bots login, that bots login is going to be the same across all my bots. So, every developer who's going to be maintaining that bot knows what it is and how to fix it. I think the standardized logging as well to make sure that we've got robust logging for every single robot is incredibly important because again that's going to be critical when somebody goes to try and fix the bot. >> So you are like an app store, you're enforcing rules like Apple for developers. >> Exactly. >> Okay so let me ask you a question. See now several years in if you had a mulligan, what would you do differently? >> Yeah I think that's another very good question. I think when you first start with this technology, it's unbelievably exciting, because it's something that you can immediately see the difference and the impact it can make, and so you want to try and apply it everywhere to everything, to solve every problem. And I think that's kind of where we got a little ahead of ourselves. We weren't as thoughtful as we should have been when we started taking in the use cases that we were bringing in and while I sit here and tell you that we've got 300 automations in production, I've also decommissioned about 90 automations as well. Because you kind of live and you learn as you go through that process on. This doesn't make sense for RPA. It's not driving the value anymore. It's not driving the right value for the company. >> And is that because the process needs to be reworked before it's automated or there are other factors? >> Yeah I think there's a couple of factors there. I think number one, some bots are intentionally just for short-term use. We look across the portfolio, some bots you design for to operate for two weeks for a massive for example document transition or something like that. So, that's a common reason for decommissioning. I would say secondly you just picked the wrong process. It's not big enough. You think this is perfect for RPA, but it's saving somebody maybe five or 10 minutes a week, which in reality do you really want to put all the effort and to continue to maintain something like that on a back office level? So, I think the size of the processes and the complexity you've got to be thoughtful about as well. >> Thinking about a bot for every worker, what does that actually look like? Is that like you get a laptop and you get a bot? How does that actually manifest itself? >> Yeah I think as I've talked to some of the teams and Daniel as well about this, it's really around I mean imagine opening it up just like any other application on your computer and Excel, you've got that sitting on your desktop and you use that for a number of different things. I think that's kind of how I envision it and everyone when they come into GE, they'll get their laptop and it's part of their kind of package of software that they get. One of them will be UiPath and I think again if GE where I see that as the future. We've got to be thoughtful about how that's rolled out because you want to make sure it's done the right way and you want to make sure that that succeeds and what comes along with that is a lot of education. There's a lot of people that need to be educated on the technology in order to roll that out effectively. >> It's part of the onboarding part, just part of the HR onboarding, and so you open up your laptop and based on your role you'll have a library of bots that are applicable for your job. Is that kind of what you envision? >> Again I think that's kind of the future state and so HR will have a common library that they can pull from and Finance will have a common library that they can pull from. And I think the announcement this weekend of or this week of our StudioX is going to make life significantly easier. So, if you need to kind of edit any of those components or make any custom steps, you can do that with StudioX, but I think having a pre-built set of bots by function would be extremely important. >> And StudioX is the citizen developer right? So, okay now how do you then enforce the edicts of the COE if Dave Vallente's writing automations. >> It's honestly a question that we haven't answered yet and I think that's the piece that we're trying to solve for now, to roll it out more broadly. And I think part of it's going to be training right? Educating the broader group, part of it is giving them access to front office robots and so you do have the code back at the orchestrator so that you can see kind of what's going on and make sure if there are massive changes that need to be made, you can make some of that centrally, so I think figuring out how to centrally maintain and store some of that code is going to be important. >> And the idea of moving beyond this what they call this morning the snowflake into the snowball. So, reusable components is something that I've heard a lot about. That's not trivial yeah right because mapping the right component for the right job is always going to be some kind of unique, not always, but there could be some unique element to put in words. So, what are your thoughts on kind of future? I mean we touched on some of them. It sounds like even though you started early, 2016, it sounds like you still got a long way to go. What's the roadmap look like for you guys? >> Well it's really never-ending because you know you see how quickly the industry is changing and how quickly these automation platforms. I think we're at the point now where these are no longer RPA platforms. They're automation platforms with all of the different features and you look at the broader ecosystem of the technologies being pulled into play. I think it's moving from robotics process automation into intelligent process automation. And that's really our goal and leveraging the ecosystem that the UiPath is built is I think what we want to do more of going forward. >> And the primary measurement of value to you, I'm inferring is time saved from doing non-differentiated tasks, is that really a key metric or are there others that you're looking at, bottom line dollars that you're saving or what? >> I think the way that we measure productivity is really in three major buckets. One is the hours saved so that employees can do other things and I would say that is far and away, the largest bucket that we have. But I think additionally you've got to think about direct cost out. I mean if my finance team comes to me and says, we're thinking about hiring a person to do this why not an RPA? Why can't we use an RPA to do that instead? So, it's not like anyone's losing their job over. It's just figuring out a better way to supplement your existing workforce. Then I would say the third way really is thinking about the compliance element of things. So, and that's often overlooked. You may not save anyone time. You may not save anyone hours or dollars, but what you can do is expand for example in your audit function, expand your testing or sampling of a certain criteria, instead of sampling maybe the top 20 risky units, you can now sample a 100% of a population, which fundamentally changes how you can get comfortable with your financial statements and other elements of the compliance. >> Talking earlier just I asked is sampling dead because of RPA right? >> It really feels like that you know. >> Dave: Eric it's super knowledgeable. I really appreciate you coming on. >> Absolutely. >> Dave: Congratulations on all your success really. >> Thank you very much Dave. I appreciate it. >> You're welcome. All right keep it right there everybody, we will be back with our next guest right after this short break. We're live from UiPath Forward III from Las Vegas. You're watching theCUBE. (upbeat music)