Webinar

The future of RPA: Migrating to Gen2 tools

As our industry evolves, new RPA providers offer distinct benefits over the first generation tools. For example, Robocorp’s pricing model and modern, AutomationOps approach help businesses save money and accelerate innovation.

Could it possibly be worth the time and money to switch RPA platforms? What about the re-writes and risks of breaking bots? And are the Gen2 players all they’re cracked up to be?

There are many factors to consider when evaluating a platform migration. Which means there will be plenty to discuss during Robocorp's October 12th.

Our panel of automation experts will discuss:

  • The Gen2 players and what they offer
  • How migrating can reduce costs and open new possibilities
  • Evaluating the risks and rewards of migrating platforms
  • What a replacement or dual vendor strategy can look like
  • The migration process: planning and technical conversions

Speakers

Co-Founder & CEO, IAC

Olivier Gomez (OG)

Co-Founder & CEO, IAC

Co-Founder & CEO, Robocorp

Antti Karjalainen

Co-Founder & CEO, Robocorp

Thought leader in Intelligent Automation and AI technologies

Shail Khiyara

Thought leader in Intelligent Automation and AI technologies

Gen-2 RPA: Webinar transcript

Peter: My name is Peter Steube, I'm proud to work with rower Robocorp. For those of you who don't know us, we are a company that is bringing forth an exciting new approach to the automation industry. In a single sentence, we are an open source cloud-native and modern platform focused on empowering RPA professionals to produce more sustainable and cost-effective automation. As most of you know, the RPA industry has historically been dominated by just a few vendors. What you may also realize is that these quote-unquote gen one providers of RPA are commonly constrained by, and this is not limited to their proprietary toolsets, licensed-based upfront pricing, high infrastructure costs, and antiquated development and deployment experiences. In light of the innovation that Robocorp is now offering the industry today, we will discuss the risks and rewards of migrating replacing end or a multi-vendor strategy. In order to do so we've enlisted a panel of automation, industry titans. Shail Khiyara will soon be moderating and driving the discussion. 

Shail has spent the last half-decade building the intelligent automation market, which comprises of both RPA and AI technologies. As a unicorn in intelligent automation and digital transformation he has served as a CMO and chief customer officer at three leading automation firms helping to shape this industry. He is also the founder of VOCAL, an independent automation customers-only group, which actually stands for the Voice of the Customer in the Automation Landscape and now has over 50 key decision-makers in the automation industry from across the globe. We are also joined by Olivier Gomez a.k.a. OG. He is a recognized global expert and pioneer in the field of intelligent automation and RPA, he is also the CEO and co-founder of Robocorp partner IAC as a senior executive with 23 plus years of experience. He is a leader of large-scale automation transformations with strong ROI for the fortune 2000. Olivier scaled and ran one of the largest automation footprints in the world for HP DXC, which included over 6,000 unique bots, which helps give him a very good grasp of operational aspects as well. 

And lastly, Antti Karjalainen, CEO and co-founder of Robocorp. Antti is a long-time open source enthusiast with a background in software engineering. He serves on the board of robot framework foundation and is leading the charge when it comes to evolution within the automation industry focusing specifically on eliminating the boundaries that have played the sector to date. Before handing the floor to Shail, please keep in mind that today's webinar is being recorded and a replay will be published soon after. Also at the end, we will leave a few minutes for audience Q and A. You may submit either in the chat or using the Q and A function in the zoom. With that said Shail, the floor is yours. Good luck guys.

Shail: Peter, thank you, really appreciate it. Welcome all to this exciting session of the future of RPA migrating to gen two tools. RPA, as many of you know, has had an interesting history and it's continuing to evolve and with over 65 companies in the space, 12 acquisitions that have occurred in just the last 24 months. This industry continues to evolve and continues to be disruptive and disruption is a natural evolution, it's happening now. We've seen it in the first wave of RPA players, we've seen consolidations and we have also most recently amongst the big three, we're seeing a private equity takeover very recently. Antti is joining us from rainy Helsinki and Olivier is in what seems to be a very calm evening in your window there in the south of France. Welcome Antti and Olivier.

Antti: Thank you.

Shail: Well, let's dive right in. This is sort of a no spin zone where we want to talk about what's next beyond RPA and automation as you know, is a very hot topic. There's around $9 billion of investment that has gone in this space in the last 30 months and before we talk about gen two let's put the customer in the center of our conversation and talk about what are the customer needs? What is it that is not being fulfilled with the traditional automation, let's say gen one?

Antti: Yeah, I mean, Olivier, you go first. 

Olivier: Sure. Let me share my view here. So first of all, what's really important to understand is that this is a very normal and natural evolution for any new technology. RPA and the entire ecosystem is a new segment in the software industry, by the way. I think it is the fastest-growing segment in the software industry. If I'm trying to explain what's in the mind of most of the customers nowadays, it's very simple. They are starting to expect and demand outcome. They are slightly over the excitement wave that happens when something new is created. Trying to give a comparison, probably when electricity was invented people were super excited and super amazed by the capability. Very similar capability, maybe not for super geek people, but for most of the world having a bot that can do work for you and take over the tasks that you don't want to do is pretty cool. It's pretty overwhelming. 

I think now we are over this innovation wave and we are starting to enter what I would call an industrialized wave, where people are starting to have a normal expectations. Nowadays, when people talk about electricity, they talk about how much it costs, as simple as that. So they have an evolved expectation around this innovation. Very similar here, clients are expecting outcomes and there are things like what is the return on my investment? There are things like can you drop the total cost of ownership of running a bot? Can you increase my time to value so that I can basically get the result, not in six months, but in a matter of weeks? So those are the things that I would say the market is starting to request and expect and, again, pretty normal as we are starting to exit this excitement and new shiny object type of phase.

Antti: Yes, so as I look at the first phase of RPA, it was driven by a few companies out there. Obviously UI Path has done great for themselves Automation Anywhere kind of the notable first growers in there, there probably has been others. Then at some point, let's say a few years back, I felt that there was an RPA company coming out every week. I used to see a new one entering the space, and it was always, we saw a lot of copycats like me too, we can do that too, it's the same thing and for the longest time, for instance, the licensing pattern has been the same. It's always bought licenses, it's orchestration license, something tied to the execution units and now finally we have with the first wave going past that first hype cycle in a way, starting to see something new emerging from this sort of second-wave companies that are starting to rethink how we do things in RPA, what is driving real customer value, how these RPA projects are being built and run and operated and maintained, and even sunset at the end of the project. Seeing this a few years ago, will buy in and understand a lot more. 

Because the goal here is once we are past this initial hype wave of I play with the tool, and I'm building trust that the tool can do the job. Now, I need to start scaling seriously and if you have a weak return on investment because you are using a technology that has a super high license cost, as an example, then I can tell you that there's no way you are going to scale, even if the technology does the job, because the CFOs and actually your business case will turn red everywhere. So again, what is gen two, it's simply the disruptors that come after the innovators that are listening to the requirements from the client, and they embed that natively in their technology, and those who are able to do that, they will basically do very well because they will enable the clients to achieve an outcome and to basically do what is required to have this digital workforce replace this human glue we've added forever.

Antti: Yes, I'd like to add to that. First of all, human glue sounds pretty suspicious to me, by the way as a concept. But in general, we've seen RPA COEs in major corporations being built on the first generation. They get a lot of value from the first projects that they go through and build out a massive digital workforce. But at some point, they hit a ceiling. They say, no, we cannot actually go beyond what we have reached here so far with the first-gen technology. Whether it's depending on the licensing or the cost structure, or whether it's just the technical limitations or the tool that they've chosen, so they can kind of start looking for this dual vendor strategy where they want to bring in another tool to augment their capabilities. Obviously, if you've been in many of those discussions and a lot of times the first-gen vendors, what they've done now, obviously huge market penetration, like a ton of of sales, new sales happening, and now they need to expand. 

 

So what they start doing is they start horizontally adding solutions, whether it's process mining, whether it's chatbots, hyper-automation, all of that, and capability to expand on the customer accounts. But these customers that are saying that, okay, we've hit the ceiling. Now we don't need to add yet another high bill automation capability, we want to just add more bots, how can we do that? And that's where technologies like Robocorp come in and can really help them augment them.


 

Olivier: And just to add to that, because I want to give a practical example here. Typically when you start, you identify activity that you want to automate in ICOs location. When you start scaling and you are a global organization, and you want to scale across the world, including Asia, the cost structure is going to be totally different, and it's going to be more and more difficult to basically build a case to do automation in area where it is not Europe, it is not US. So those are examples of things that are, that ceiling that Antti is describing can materialize in different ways, but you want to start scaling, I don't want more features. I want the core structure of what I am deploying to be right and that's really important,

Shail: I think Olivier, you make a very important point about the core structure and this ties back to what I was mentioning earlier about the bot based architecture with which gen one started, there was also mention of scale. So are you both saying that gen two actually allows you to scale faster because the core fundamental technology is a differentiator. What are your thoughts around what makes; first of all, does gen two allow you to scale faster, which there are challenges in gen one? And if so, what enables you to do that?

Antti: If you think about we need to actually separate whether we're talking about mid-market versus the enterprise. Obviously the enterprise will stick around with gen one for a longer time. Mid-Market hasn't really started with RPA, so we've seen a ton of uptake with RPA in the mid-market where we can see a partner ecosystem, for instance, taking Robocorp and really running that as a service to offer the business outcome of bots and kind of scaled down market where we haven't been seeing RPA that much, but just talking about the enterprise itself, any thoughts on that, Olivier, on your side?

Olivier: So for me, the scalability of a technology is not always related to the technology itself, but it's included. So again, back to my point, it's all about going through the different approvals inside an organization and validation inside an organization that actually what you are doing is positively impacting the P and L of the organization, top or bottom of the P and L, but you have to have visible effect of what you are doing. So back to the technology, if I am deploying something that is allowing me to positively impact the P and L, everyone in the organization, the CIO, the CFO, and the CEO will ask for more. If I am working with a technology provider that understands that I'm working is a service provider that understands that, then all the rest is virtually details. Of course, you will hit limitations with certain vendors, which will force you to move to someone who doesn't have those constraints. But conceptually the scalability of the is simply related to does it make a difference to the business? If yes, I want more, if I want more, I'm looking for the right technology. If I don't have the right partner right now, I switch, obvious.

Antti: Yes, I see that the enterprise is still very focused on the COE-led model where we've seen RPA scale-up, it's always been driven by the COE. Teally the citizen developer model hasn't really come through in that way or I haven't been able to observe it in the market when talking with customers that they had adapted. I see this in developer lead path and just scaled tremendously with positive results. Where we have seen scaling up, definitely driven always by COE and there be typically see more technically capable COEs being able to take technologies like Robocorp, and then run with that and continue for over scaling past the first initiatives.

Olivier: Another point that is important here, that is I would say related to running the automation. So automation ops or whatever you want to call it, you basically are going to scale if you can handle what you have today. And back to the point, we have seen many, many COE that are slowly evolving from a team of people building bots to a team of people doing support of the bots and then you are back to the typical IT issue, right? If I have 80, 90% of my resources maintaining what I have instead of innovating, and again, reaching a ceiling, it's a very typical situation. So the capability of the technology, the vendor, and the service provider to be able to run the footprint efficiently so that you can keep scaling and you don't collapse, this is absolutely critical and gen two, if I have a cloud-based, native cloud-based solution that is giving me instant let's say, instantiation of my bot that is giving me 99.9% uptime so I don't have to worry about that and plenty of other things that will help my run and maintain phase, then I am a lot more comfortable to grow my digital workforce because I can handle it.

Antti: Great point by the way, we have a good article that we authored around automation ops, fully agree with that point of view. Just happens that we've actually incorporated that kind of modern DevOps type of operational model into the product itself, which again, didn't happen with the first generation because they started out with this model that this is going to be outside of the IT, like not part of the IT organization. Slip it in under the covers, and nobody needs to know, well, you'll build a hundred bots, somebody who needs to know about that and maintain them for sure.

Shail: I think that's a very good point that you bring up and customers generally tend to migrate to alleviate the pain points that they have, and that are not being met with their current solutions. So clearly in the market, we are seeing a multi-vendor RPA strategy but in addition to that, additional technologies are being added to the stack. You've talked about chatbox analytics, AI process mining capabilities. Why is this migration required? Why do you think a customer should migrate? When should they migrate from a gen one to a gen two?

Antti: From our perspective, sometimes it's just required because a vendor might be updating, you typically see in the enterprise specifically, you'll see that your customers are gonna be lagging multiple versions with on-premise deployment. Now, gen two, being typically cloud-native, you don't see that kind of lag behind in versions. So you actually might hit a natural point of, hey, we don't even support that version anymore, you need to rebuild your bots to the natural break point in that evolution where you might consider migrating away. Then there might be events like a private equity takeover that starts, let's say the customers start thinking about, hey, is this going to be the company that's going to be innovating in net for the next coming five years? Should I sign up for a multi-year license commitment to this company? That's another natural breakpoint, but all in all, this is something that happens with every technology out there, every possible technology that we see go through these evolution cycles is bound to have a first wave and another wave with migrations involved. 

We've seen it with video conferencing, for instance, everyone migrating over to zoom when we've seen a clear winner. Then Microsoft is in there with Teams, we've seen it with the I-PASS vendors. We used to have TIDCO started out in the late nineties, then we have other players MuleSoft and so forth. It's just a constant evolution that happens in the space and part of the natural progression of, well for it's just a cloud that really didn't exist when the first-generation RPA players were being created, that kind of sets it up for a generation change.

Olivier: Yep. So the way I look at it right, is so first of all, obviously this is something that evolves all the time. This ecosystem that we are describing is changing all the time. It's alive and as anything alive, things die, things come in and that evolution is pretty much the same as any other IT space. It has to be managed and this idea of there is a risk to migrate, be careful, this is a very close to me, this is very close to, I'm trying to build stickiness here into this environment. At the end of the day we can talk about that in details, but obviously as any change, there is a risk that risk can be very easily managed. It's not too far away from, I have a bot that breaks and I got to fix it, it's a bit more advanced way of I'm rewriting it and redoing it, I'm converting, I'm migrating. But at the end of the day, I want to downplay that. I mean, it's very natural. It's very normal. You are totally free. You don't want to be stuck. You want to have multiple vendors. You want to go for the one that gives you what you need and the benefits that we see by having this freedom to move to the right place is by far exceeding the risk that you are taking to do so.

Shail: One thought that comes to mind is that there is a lot of challenges with upgrades. Olivier, I'm sure as you went through 6,000 bots in prior engagements you've had, you may have gone through some upgrade cycles as well. In the market today, there are about 25,000 customers in the market and 50% of them are still sitting on legacy automation software, older versions of the software. And why, because upgrades are a pain and bots tend to break, the bot fragility that I was talking about earlier. And while the majority of the gen one vendors are adding to their TAM, their total addressable market, many customers still cannot take advantage of those new functionalities because they haven't upgraded. So if upgrades are a pain, what makes it easy for customers to migrate?

Antti: Yes, that's a good point, upgrades are oftentimes a pain especially, like I said, running on-prem. We've seen that actually migration work, if you think about just pure migration of an existing bot that might have taken months to implement in the first run, then you do migrate it's typically fraction of the time involved. So it actually might be proportional to a migration workload that you might be looking at otherwise in any case. So we've seen instances where it takes, we had a customer who migrated away from one of the first gen platforms, and they had multiple bots that they had built across a six-month time period and they were coming up on their license terms. So they were a bit in a rush, they brought in a robocorp partner to handle the migration, took them under 30 days from zero to running in production, those new bots taking rid of the old gen one licenses. While the partner was doing that migration, their own internal team got ramped up on the technology and started producing other automations already on top of the platform. So think about six months initially implementation, 30-day replacement implementation. So that kind of gives you a perspective on the fact that when you architected the automation, you figured out all the pain points, you kind of have it defined already, it's much easier to go about and just go with the migration.

So I don't need to host this orchestrator here. I don't need to host these super PBMs. I can actually run these in containers or then run in lighter-weight virtual machines, run multiple bots on the same virtual machine, et cetera, that some of these examples actually include customers having their infrastructure bill in addition to having the license bill. So that has been pretty significant and my favorite type of migration may be being we've seen people running things like Python-based bots through platforms like UI path, which are definitely not designed to do that, but that somehow they have ended up with that kind of architecture. So that's like lift and shift to Robocorp, which is Python-native supported platform. So these are kind of that the things that we see out there, it just makes a ton of more sense to run those Python-based bots on a platform that's actually made for them instead of using a UI path orchestrated to do so. So maybe I've covered all the big three that I've seen, but so many other examples out there. I'll let Olivier, you chime in as well.

Olivier: Yes, so we do a lot of assessment for the clients, and the typical trigger for them to consider another technology is please first reduce the complexity, bring simplicity. So we talk about infrastructure. So infrastructure has a cost, it's not just the cost. You have large companies that are relying on all the vendors and there is always let's say a very long process to create a new bought and provisioned infrastructure and do the network slash firewalls slash installation slash, so it is perceived as, it is not simple, it is difficult and please help me go to a place where it's a lot easier to do. What is connected to that is please also help me handle the fear that I have of making a change of basically. So right now, I'll give you a specific example, we have a client that has a certain install base, which is gen one and they now come to realize that they would like to have a dual vendor strategy. So we do introduce a gen two vendor in the mix so that they basically build trust, they see the value, they understand the simplicity of working off the cloud, of having a more flexible way of consuming and we also show them slowly that not only you can introduce a new vendor to build a new bot, but actually moving from this old bot to this new bot crossing technology is not a big deal. 

You assess correctly the situation, you understand the sending point, the receiving point to new technology, you understand the differences, they both have strengths and weaknesses that we have to handle. You basically convert the bot and then you help the client through very heavy testing, help the client understand that the input-output of the new bot is exactly the same as the old one. So at the end of the day the confidence that I can now use this technology that fulfills all my requirements and actually does exactly the same as the previous technology is something that it's very easy to articulate to the client, if you correctly assess, you correctly convert, and you correctly test once it's tested and the outcome is there, the output is same, then it's just the trigger to decommission the old is very simple.

Shail: So how long does this usually take in your mind as you've gone through this Olivier, this migration itself? Does it vary depending on the complexity?

Olivier: Yes, yes, yes. When you assess an environment, not all bots are equal, you can have a very small bot that does very simple copy and paste reporting type of task and then you have a monster of a bot that is not just RPA, that has a brain, it has vision, it has language. So it basically has a lot of capability and it depends on the size. That's why assessing the environment, phasing the conversion, the simple bots, it's a matter of weeks, it's a matter of weeks. The more complex bots, you also want to make sure that the technology you are selecting as the receiving end has all the capability because there's, of course, gaps and mismatch, not all the technology has the same, let's say objects available, the same libraries available. So there's a number of things that need to be done, but the assessment is really critical to understand what it is I can move as a first phase, quite easily to build confidence and then I can address the more complex one later on. So again, I would say from a few weeks to obviously a few months, if it's a monster of a bot

Shail: Fair enough. So Antti and Olivier, I've been asking some of the questions that have already been popping up in our Q and A box. So just continuing on that theme, because I think we're at the end of our narrative here today. But one other question that has come up beside some of the ones that I've asked is, does Robocorp have a control room that has an option to trigger multiple bots, dynamic group whenever a new transaction is received?

Antti: Yes, absolutely we have and we have been architecting the cloud-based control room solution from the ground up in a way that's going to be able to handle transactional data for the bus pretty scaleably, I'd say. We are running thousands and thousands of bots over there right now and we're just going to be launching some of our work item management features soon enough in a few weeks time I think, I don't want to speak for my marketing team's behalf here so there's already building capabilities to be able to route work to bots and launch multiple bots to process work, do the stuff like fan-out work to multiple bots in concurrent, and then found them in as resource get picked. So kind of that takes advantage of the licensing or that the fact that there is no licensing scheme that would limit your concurrency. So you can have an elastic workforce in the cloud to operate that kind of workload.

Shail: Excellent. Thank you. Thank you, Antti. I think we have time for one more question. We're a little bit over time for what we had scheduled, but there is one other question that has popped up that I want to make sure we address. With respect to the migration plan, the question is, do we rewrite the workflows in gen two? Or are there hoarding utilities in gen two?

Olivier: So there are multiple ways to approach this. So there are quite a few, first of all, there are quite a few vendors out there who are basically trying to address this market, this conversion market by if I move away from blue prism and I go into Robocorp. So there is a way to extract, let's say XML then to convert that to something that will be an obstructed view, a technology abstracted view of the bot, and then move that back into Robocorp. So there are a lot of people working on the converter. Having said that I don't believe that anyone is at a point where you can click a button and you can convert from A to B. So there is a need to rewrite a part of the bot, whether it's 10% or 90%, there was a need to rewrite a part of the bot. Now, having said that people are making a big fuss about this, but this is not a big deal. You know exactly what the bot is doing. The starting point is not, I need to reinvent the wheel. I need to define what the bot is doing. I need to do the discovery. I need to write a solution document. All of that is done. All you got to do is to take what the bot does, and you have visibility of that and to convert it, if you have a tool that does 50% of the work, that's great and you do the rest manually. This is not a big deal. I want to again downplay this idea that, it's not like moving a house, it's a lot easier to do the conversion.

Shail: Thank you all.