Tag: robotic process automation

  • Salesforce Adds RPA Bots to MuleSoft Integration Platform

    Salesforce Adds RPA Bots to MuleSoft Integration Platform

    Salesforce today announced that it is now using robotic process automation (RPA) to connect disparate data via a no-code tool developed by its MuleSoft unit.

    Shaun Clowes, chief product officer for MuleSoft, said bots created using an RPA-infused integration platform can now automate much of the effort previously required to integrate data residing in different systems. Salesforce acquired MuleSoft in 2018 and, since then, has been working to make the platform for integrating application programming interfaces (APIs) a core element of its business process workflow tools.

    The news was announced at the MuleSoft CONNECT 2022 conference. The overall goal is to employ RPA and no-code tools to accelerate digital business transformation initiatives without writing code, noted Clowes. Overall, Salesforce claimed its customers are running 4.8 billion MuleSoft transactions daily, resulting in a 74% decrease in operational costs and a reduction of more than 100 billion hours of work every month, using Salesforce Flow tools that are integrated with the MuleSoft integration platform.

    In theory, no-code tools that integrate disparate data sources can be used by professional and so-called citizen developers alike. That capability should reduce the time and effort required to create those integrations. A recent survey conducted by Salesforce found nearly 96% of respondents said that modifying and rebuilding automation is a challenge as systems and business requirements change. In addition, four out of five respondents noted that restructuring existing application and data landscapes to support automation would likely compound their organization’s technical debt.

    More than half of respondents (53%) said they are using integration and API management capabilities to some extent, with 44% employing those capabilities to drive business process automation initiatives. A full 80% said they are working toward putting hyperautomation on their technology roadmap within the next 24 months.

    Of course, the MuleSoft platform can be employed beyond the portfolio of software-as-a-service (SaaS) applications provided by Salesforce. However, it’s also become apparent that more organizations are building and deploying custom applications on top of a range of SaaS applications in addition to building and deploying applications written in procedural code that might be running in the cloud or in an on-premises IT environment.

    It will be up to each IT organization to determine how much they need no-code integrations as part of a larger DevOps workflow, but as it becomes easier to create integrations using RPA tools their numbers should increase. The impact all those integrations will have on DevOps pipelines remains to be seen, as well. Many organizations will need to revisit their DevOps workflows as the number of application development projects being simultaneously launched continues to increase.

    In the meantime, it’s clear that no-code/low-code tools infused with RPA capabilities will empower more end users. That shift will have a profound impact on DevOps teams, as the sheer volume of code and associated integrations increases. The challenge, of course, will be finding a way to make sure that the integrations created are secure and that they can actually scale as more data sources are added.

  • 4 Ways to Manage Up for Automation

    4 Ways to Manage Up for Automation

    IT decision-makers understand how important a role process automation can play in a post-pandemic recovery. In a recent survey, 68% of these leaders said remote work caused key business processes in their organizations to break down. In the same survey, 97% described process automation as being vital to digital transformation and an important factor in achieving business outcomes.

    So, full speed ahead? Not exactly. While process automation’s benefits are well documented, many organizations remain hesitant to automate too many tasks because they’re afraid they’ll further complicate an already complex IT environment.

    This is where developers can help process automation initiatives get off the ground. They don’t control their organizations’ purse strings and they often don’t take the lead on planning new IT initiatives. But developers are the ones responsible for designing and building the software and tools that drive real business results. In a large sense, they occupy a key role at the heart of digital transformation.

    For organizations to gain the full benefit of process automation, developers need to be more intimately involved in automation projects. They need to have more say in how these initiatives are constructed, how they’re carried out and how they’re improved.

    Automation initiatives aren’t set-it-and-forget-it projects. They must tie in with end-to-end organizational processes, which will evolve over time. Organizations don’t want to bake in processes that won’t suit them two months or two years from now. With this in mind, process automation needs to be nimble, adaptable and smart–and it’s developers who have the skills and the insights needed to drive these initiatives forward, impacting broader organizational success. 

    To take on this larger role, though, developers must be given the right resources, tools and access to make their voices heard. Part of this is empowering them to manage up to senior leaders–on both the IT and business sides–to advocate for the types of automation projects that can drive true digital transformation.

    Here are four ways they can do it.

    Build Automation Demos

    The biggest enemy of a process automation project is time. The C-suite and senior IT leaders don’t want to spend months–if not years–debating the merits and feasibility of automating a series of tasks. They want to know quickly whether a project is viable and whether they should commit resources to it.

    Developers can set a project on the right course by creating a basic demo. It doesn’t need to integrate the complicated set of dependencies planned for the finished project; it just has to show people in power that the project will work. Demonstrate how a manual calculation project gets triggered by a quarterly deadline and estimate the time it will save a department on an ongoing basis. Show the leadership that the pain point workers have cited on feedback reports can be solved.

    Show Proven Examples

    While a demo visualizes how a process can work, a use case can illustrate how such a process has worked in another setting. Examples can be found in any number of places–in a formal case study, a tech article, a GitHub posting, a developer message board or materials supplied by a technology partner. Developers should tap their networks to get advice and run scenarios by peers. The goal is to find a situation where someone solved a similar problem with a manageable set of procedures–and it worked. Having a solid example takes the initiative out of the theoretical realm and gives the developer more credibility.  

    Get an Enterprise Architect on Board

    Once the demo and the use case are secured, the next step is getting buy-in on the vision for the automation initiative. This is the domain of the enterprise architect. It’s important for a developer to get this person on board as an ally. They should work with the enterprise architect to ensure that the set of tasks fits into the company’s architecture – today and in the future. If the company is pursuing a microservices strategy, the developer needs to show how automating a series of product quality checks can be accomplished inside this technology infrastructure.

    Keep Things Simple

    While organizations try hard to operate in an agile manner, sometimes that’s easier said than done. The people developers report to like to plan. Enterprise architects like to define perfect, future-proof architectures. The C-suite likes to envision scenarios and debate ramifications. Developers can break logjams by encouraging others to avoid the temptation to drown in detail. They should get comfortable with the concept, the demo, the use case and the vision–in that order–and then roll it out to the larger organization. 

    While process automation is widely seen as being vital to business transformation, building a project is often more challenging than it needs to be. Encouraging developers to take on larger roles can help organizations move automation initiatives past square one and on the path to digital transformation. 

  • How Low-Code is Anchoring the Digital-First Enterprise

    How Low-Code is Anchoring the Digital-First Enterprise

    When the pandemic hit, digital transformation was accelerated, and many companies turned to low-code development in the hopes of winning in the new agile world. Technology aficionados have heard the phrase, “Faster, better, cheaper — pick two.” Fortunately, low-code gives you all three and then some, adding “flexible” to the mix. It’s no surprise that low-code development interest is now surging, as it’s quickly becoming a critical component of a modern enterprise technology stack, with estimated low-code development market growth predicted to exceed 25%, growing from $13B in 2020 to $65B in 2027, according to research from Brandessence Market Research.

    With their roots in the rapid application development (RAD) tools of the 1990s, low-code platforms are an application development environment that use graphical user interfaces and configuration instead of traditional hand-coded computer programming. Formal software engineering skills are not required to create applications since a visual user interface in combination with model-driven logic is used. This opens the door to a wider range of people who can build apps for the business. With a little training, employees can rapidly create and deploy secure scalable software. One note to remember–low-code is not interchangeable with no-code, which is a subset of technologies aimed at business users primarily working on enhancing their individual productivity.

    A New Player in the Enterprise Technology Stack

    It’s impossible to argue against the need and demand for low-code in the enterprise. According to Gartner, more than 65% of application development in 2024 will be performed by low-code platforms. That’s a remarkable shift for a software category that did not exist a decade ago. The number of digital applications and services being built is exploding as well. Between 2018 and 2023, more than 500 million apps will be created according to IDC. To put that massive number into perspective, that’s more than the previous 40 years combined. With low-code, companies can rapidly produce applications within a shorter time span and at a fraction of the cost. Some skeptics may point out the lack of available IT resources, but business users can learn low-code development methodologies quickly, typically in less than one month. Clearly the old way of building apps cannot keep pace with today’s digital marketplace.

    Process Intelligence Jump Starts Low-Code Journey

    To help accelerate use of low-code and scale it across the enterprise, process intelligence is a key enabler. You cannot improve how you operate tomorrow if you don’t fully understand how you work today. And most companies truly don’t understand how they operate on a daily basis, especially at the granular user activity level required to automate a process or streamline a workflow. They have limited process understanding. They don’t know how their applications and data interact, and they don’t really understand what their customers expect.

    The impact of this gap in process data is well documented. The 70% failure rate of transformation programs is widely reported. McKinsey pegs the cost at nearly $1 trillion annually and noted that 14% of companies have seen a sustained and material improvement in their business. Another study from Gartner noted only 1% of companies have sufficient understanding of their processes to take full advantage of the technology solutions.

    Before embarking on a major initiative, a company must map its processes, its systems and its experiences. Today, that necessary level of operational intelligence just does not generally exist in most companies and on top of that it is very difficult to obtain without process intelligence.

    Low-Code and Process Intelligence – Better Together Than RPA

    Process intelligence was a similar catalyst for robotic process automation (RPA), but the opportunity with low-code is even greater. RPA programs enjoyed massive early uptake, but the challenge was how to scale the initiatives. Companies still struggle getting more than 50 bots deployed. Once any obvious low-hanging fruit is automated, it becomes difficult to identify what to tackle next and how to tackle it. Process intelligence answers those questions to help scale RPA.

    With low-code, process intelligence accomplishes that and more. The combination will overtake RPA as the gateway for AI and automation. Low-code is more efficient and scalable than traditional RPA development because it does not operate at the user interface (UI) layer, making the applications more resilient. Additionally, where RPA is traditionally limited to task-based activities, low-code is much more capable of handling sub-process and process level activities, making it much more valuable to the enterprise. Coupling process intelligence with low-code helps steer an enterprise toward a next-generation operation model that is faster, cheaper, better and flexible. It may also fully realize the promise of citizen developers that RPA struggles to achieve.

  • ServiceNow Acquires Intellibot to Gain RPA Capabilities

    ServiceNow Acquires Intellibot to Gain RPA Capabilities

    ServiceNow’s acquisition of Intellibot, a provider of a robotic process automation (RPA) platform, this week is part of a larger effort to automate the development of applications that are driving digital business transformation within enterprise IT environments.

    Earlier this month, ServiceNow unfurled a set of revamped low-code tools that both professional and so-called citizen developers could employ to build applications to modernize various business processes. However, many existing business processes are either manual or paper-based. An RPA platform enables organizations to create bots that mimic, within an application environment, the way those processes are currently managed.

    Josh Kahn, senior vice president for Creator Workflow Products at ServiceNow, said ServiceNow envisions the Intelligent RPA platform as a mechanism to automate rote processes that, for one reason or another, don’t manifest themselves via a set of application programming interfaces (APIs) that application developers can easily invoke.

    Each IT team, of course, will need to decide when it makes more sense to employ bots to digitize an existing workflow versus reengineering it using a set of custom applications infused with machine learning algorithms and natural language processing (NLP) capabilities. As digital business transformation initiatives become more urgent, the application development backlog within many enterprise IT organizations that require those capabilities is steadily increasing.

    However, in some cases, an RPA platform can reduce that backlog by surfacing a set of visual tools to automate a process that doesn’t require a lot of developer expertise to effectively digitize.

    In general, Kahn said ServiceNow is making a case for building a wide range of applications on top of the same software-as-a-service (SaaS) platform many internal IT teams already employ for IT service management (ITSM). That approach enables IT teams to streamline processes as the number of custom applications that need to be both developed and, ultimately, managed, steadily increases over time, Kahn said.

    The developers of those applications might be professionals using a low-code tool instead of writing additional code to quickly build an application, or it might be a “power user” that has enough understanding of software development best practices to build an application. Regardless of who builds the application, the rate at which applications are built using low-code tools is clearly about to accelerate.

    Kahn said the next step for ServiceNow will be to embed the Intellibot RPA capabilities in the ServiceNow platform sometime after the deal closes in the second quarter. In fact, one of the reasons ServiceNow opted to acquire Intellibot is because, as a smaller startup vendor, it is easier to incorporate their RPA platform than it would be to reengineer a much larger RPA platform. However, ServiceNow remains committed to integrating with other third-party RPA platforms that are already being employed by its customers, Kahn noted.

    Regardless of how or at what rate applications are developed, the number of core technologies required to build them continues to expand. The issue IT organizations will need to come to terms with is the degree to which they want to stitch all those tools together themselves, or rely on a platform to do it for them.

  • How Low Code Is Transforming Software Development

    How Low Code Is Transforming Software Development

    Low code/no code is a business catalyst enabling technologies to automate processes and allowing developers to create real-time solutions for their business. With low code, businesses are able to build, customize and deploy apps with little to no coding.

    In this interview, Rackspace CTO Jeff DeVerter explains how low code is transforming software development and how Robotic Process Automation (RPA) complements low-code application platforms.

    Jeff is one of our distinguished speakers presenting at Low Code Today Virtual Summit. During his keynote presentation, he will explain the newfound prominence of low code and outline how enterprises can best utilize the technology to accelerate the delivery of software and applications.

    Find out why low code doesn’t mean “lone-coder” and why it’s important to have capabilities increased for the citizen developer by attending Jeff’ session at Low Code Today Virtual Summit on Nov. 19. To check out the full agenda or to register for free, visit the Low Code Today website.

  • The 2020 Digital Leader Priorities

    The 2020 Digital Leader Priorities

    When it comes to digital transformation, 2020 promises to be full steam ahead as many of the trends are already well underway. However, it’ll be those businesses that can execute at the quickening rate of technological change that will set the leaders and laggards apart for the years ahead.

    A survey conducted earlier last year by market research firm Vanson Bourne found that 50% of technology leaders have a challenging time managing their digital operations, and nearly 50% of respondents also said it’s their customers that identify problems before their technology and quality control teams do.

    Which brings us to our priority: Digital laggards need to step it up.

    Digital Transformation: Laggards Versus Leaders Packs Separate

    When enterprises shifted from their focus on e-commerce to a broader focus on their digital transformation efforts a few years ago, those who have been successful with their transformations are starting to reap results.

    Still, while the vast majority of enterprises do have digital transformation strategies that they are implementing, a Tech Pro Research report found 70% of respondent companies either had a digital transformation strategy in place or were developing such a strategy. While a separate study, the Kony Digital Experience Index Survey found a strong indication that those efforts aren’t paying off as well as many businesses may like—at least when it comes to their customers.

    According to Kony’s survey, customers are more satisfied when their digital experiences are effortless, and 63% said they would spend more money when their digital experiences are, in fact, effortless. That study concluded that businesses are not listening to the needs of their customers because only 28% of enterprise digital transformation initiatives are explicitly started with customer needs as the priority.

    The 2020 Priority: CIOs and chief digital officers are going to have to ensure that their organizations can execute against their digital transformation strategies. Those that create superior digital experiences are going to start to set themselves further apart from their laggard rivals dramatically. Those CIOs and CDOs at laggard companies are going to have to focus on turning themselves around as quickly as they can.

    The Continued Rise of Robotic Process Automation

    To advance their digital transformation efforts, most enterprises are increasingly turning to robotic process automation (RPA) and software bots to automate any cumbersome and costly manual processes they have in place. While the benefits of RPA and software bots are high, they don’t come without potential danger. These bots, if not managed properly, can open enterprises to increased security and regulatory compliance risks.

    The 2020 Priority: Effectively govern the security of their software bots so the associated risks are mitigated, and they can reap the most significant benefits from RPA.

    Low-Code Development Continues to Help Clear App Backlogs

    The demand for software is relentless, while the availability of professional developers isn’t limitless. And most enterprises have a backlog of application requests they can’t clear. According to a report from OutSystems, currently, 41% of enterprises use low code platforms, with an additional 10% about to start. That was up from 34% in the prior year report.

    Low code development platforms are popular because they help to make software development more accessible to non-developers by creating development more graphical. The low code development platform market is expected to grow to $27.2 billion by 2022.

    The 2020 Priority: focus on low code platforms for business users where it makes sense for them to be able to create their applications and capabilities. Not as a way to displace the development team, but to augment until those applications that warrant development and require professional developers can be built.

    AIOps Starts to Meet Its Promise

    As enterprises increasingly run their business-technology systems on a mix of clouds (both public and private) as well as on-premises systems, managing this infrastructure has grown more complex. The embracing of microservices, continuous delivery and DevOps has enabled organizations to deliver application enhancements more rapidly, automate testing and deliver their software with increased agility. However, interdependencies and the complexity of systems have also increased. This increased complexity shortened the amount of allowable time necessary to resolve system issues.

    When it comes to effective operations management, operations teams need to become as effective as possible since a breakdown anywhere in the environment can initiate thousands, and alerts can create multiple application and service disruptions.

    The 2020 Priority: This increased complexity will prove a catalyst for more enterprises to turn to AIOps. By using data gathered from operations management tasks with machine learning, organizations can become more effective at managing performance and availability and service management. AIOps has remained a buzzword for several years now, with very few actual deployments. That’s set to change.

    Optimizing Microservices Architectures

    Enterprises face a seemingly limitless demand for applications–customer-facing apps, back-office applications, APIs and digital services–and this demand has been a significant catalyst behind the popularity of microservices architectures.

    Microservices also help to ease budget constraints. Almost every survey shows microservices architectures are now in use by the majority of organizations, with benefits being cited, such as improved employee efficiency and customer experience, as well as infrastructure management. Microservices architectures also help enterprises to improve application scalability and bring new digital products and services to market more quickly.

    The 2020 Priority: Identify where microservices architectures can have the most significant impact on revenue-generating processes and prioritize the deployment of microservices to these areas first. It’s these areas where workflow improvement and application agility can have the greatest business impact.

    Looking out at a new year and imagining the possibilities is always exciting, but with the accelerated change in enterprise technologies and the level of digital transformation underway, this year is setting itself up to be more interesting than most.

    — George V. Hulme

  • DevOps Chats: Robotic Process Automation with Tricentis

    DevOps Chats: Robotic Process Automation with Tricentis

    Robotic Process Automation (RPA) has garnered a great deal of attention as organizations pursue automation routine tasks through automation software. RPA automates tasks integrated into digital business process automation.

    Wayne Ariola, Tricentis general manager of RPA, joins DevOps Chats to discuss how Tricentis brings its strengths and heritage in software testing automation into the world of RPA. The expansion into RPA makes a lot of sense when you consider testing technologies that operate on UX domain and data models, avoiding the pitfalls of brittle screen scraping approaches.

    Together, Wayne and I explore how business process automation using RPA intersects with DevOps tools, processes and teams, and how RPA benefits from the experiences gained in the DevOps community. Join us on this episode of DevOps Chats as we explore RPA and DevOps.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Wayne Ariola, who is general manager of RPA at Tricentis. Our topic today is RPA, robotic process automation, and DevOps. Wayne, welcome to DevOps Chat.

    Wayne Ariola: Thank you so much for having me on this beautiful Friday. I’ve been looking forward to it.

    Ashley: Best way to spend a Friday—well, second best, maybe. There might be a few other things—

    Ariola: Exactly.

    Ashley:– that might be above the list of this, [Laughter] but yeah, what a great day to do that. And I know we’ve had Tricentis, your CEO has been on before. Welcome back. Glad to have you on. Would you introduce yourself to our audience—

    Ariola: Sure, absolutely.

    Ashley: Tell them about you and, for those that don’t know, tell them what Tricentis does.

    Ariola: Absolutely. So, my name is Wayne Ariola, as you stated, Mitch, and I’m the general manager of our RPA solutions at Tricentis. And I’ve done—I think I’ve done at least three of four webinars on devopsy.kinsta.cloud.

    Ashley: Oh, yes.

    Ariola: So, I’m certainly no stranger to the audience, the topics, nor the concerns, yet I wanted to actually bring forth the news about RPA and see if I can’t connect it to what’s going on in the end to end DevOps world today.

    Yet, just a little bit about Tricentis, for folks who haven’t heard about Tricentis—you know, Tricentis is, today, considered one of the automation leaders out there in the world. You know, consistently across all major analysts who are always ranked as either (a) the number one leader, or, you know, right up there as number one. So, it’s been an interesting ride at Tricentis for the last five years as we’ve begun to kinda notch our way into the DevOps world.

    The one thing we are known for us really making software testing more productive. And we do that via automation. So, we know as we look at scaled agile that things need to happen quicker and then you add in the idea of CI/CD or these kinds of concepts, and then you really wanna be fast and agile. And we’re the company that makes sure that testing is not your barrier to speed. And that’s what we’re best known for out there.

    Ashley: Well, let’s start out by, I know RPA, robotics process automation, is kinda—is the hot thing or the new thing, however you wanna put it. How do you define RPA?

    Ariola: So, I mean, poor DevOps people, right?

    Ashley: [Laughter]

    Ariola: I mean, DevOps was the sexy thing for such a long time.

    Ashley: Oh, it still is. No, don’t break my heart, Wayne—come on, no.

    Ariola: Good, good. You know, you guys haven’t aged out yet, so.

    Ashley: No.

    Ariola: And all of a sudden, you know, RPA is like the Millennial of topics, right, these days.

    Ashley: Okay. [Laughter]

    Ariola: It is definitely on fire. In fact, I have a slide that I use in presentations that I compared DevOps to RPA. And the DevOps folks, it looks like there’s a bunch of people dancing, but then I show a picture of RPA and it looks like a rave—you know, a big, huge party at a rave with lasers and lights and a whole crowd thumping to the music.

    And that’s really what’s happening right now. I mean, the RPA world and the RPA market is just on fire, and it’s a bit crazy. But the reason why it’s a bit crazy is that the ROI associated with deploying automation or what is defined as RPA automation is really high. You get immediate value out of it, so it’s kind of like this—especially if you talk to CIOs, you know, they’re kinda saying that it’s kinda the no-brainer of today’s world.

    But this is, I mean, the DevOps folks are no stranger to this, right? So, we did, we went through this when we kinda went through the whole DevOps motion beginning with build automation, right?

    Ashley: Right, yeah.

    Ariola: You know, we kinda took a breath and we said, “Hey, this build process is manually painful and it’s difficult and it’s arduous.” And, you know, once we got through kinda the initial thing around the automating build, you know, the imagination associated with what could be automated then exploded, you know, and then you got into the DevOps motion, right?

    And I would say it’s a perfect parallel. RPA is doing exactly the same thing. It’s kinda taking these preliminary type of motions associated with manual processes and the automating them.

    Ashley: Well, you know, in a way, the way I think about it, Wayne, is, you know, to step back for a minute, the best developers I’ve worked with in my career have always been the laziest, and that’s a compliment.

    Ariola: [Laughter]

    Ashley: Meaning, they write the least amount of code, the automate everything—they don’t wanna do that manual stuff, right?

    Ariola: Yes. So true.

    Ashley: They wanna spend time on the things they enjoy working on. So, you know, in the DevOps world, of course, we’re big on automating things and maybe all of it isn’t automated, but it’s taking that same kind of, “Let’s take those things we don’t need to do manually and we really can automate it and look across IT, across business process automation—you know, the whole organization.”

    Ariola: Yeah.

    Ashley: That’s probably why it’s hot, because it’s not only in IT, but it can affect other parts of the business. So, I’m gonna lay claim to RPA’s roots being in DevOps. Now, you can tell me I’m totally wrong, but I won’t—

    Ariola: No, absolutely not, given the audience I’m speaking to. I agree.

    Ashley: [Laughter]

    Ariola: I totally agree. But it’s true, though—I mean, think about this, Mitch. Let’s unpack that just for two seconds, right? So, take the idea of that developer who’s lazy, right, and the fact that—what are you doing? And if you would, say, ask the person what they’re doing at any point in their day, it’s like, “You know what, I’m writing a script to do X, Y, Z because I’m so sick of provisioning this particular application to this environment,” whatever it might be, right?

    So, their knowledge base and their understanding of how to construct a script gave, especially in the DevOps world or the Dev world, these guys a leg up in terms of producing this automation to eliminate manual tasks.

    Ashley: They’re the most productive, yeah.

    Ariola: Yeah, exactly, and make that the most productive. But RPA is really trying to—and I hate to even use this word, but it’s the best way to describe it succinctly, is democratizing that, right? It’s giving people who are not as talented as your laziest developer the ability to actually create the automation to get rid of the mundane or manual tasks that are slowing them down, right?

    Ashley: Mm-hmm.

    Ariola: So, I mean, even by—Mitch, even by definition, you know, RPA is defined as a technology that predominantly leverages a combination of maybe UI and API or surface level features and applications to create more automated, routine, predictable data transcription or enablement work, right? So, automation work or executable work.

    So, if you think about it, it’s a technology that sits on top of—a super structure that sits on top of apps that allows you to do things more proactively across applications. So, making sure that a manual task to transpose data, to move data, to initiate something, to do data entry is eliminated by the automation itself, which is really cool.

    Ashley: You know, I kinda think of it as—I think of it as, an analogy would be just like sysadmins write scripts, right, to do things that automate it.

    Ariola: Yes, yes.

    Ashley: This is for other IT folks, but also can be end users, right, that automate filling out forms on online screens or doing some processing of “load this data into a spreadsheet, export it out to here, send it to here.”

    Ariola: Yep, yep.

    Ashley: Now, why do all that stuff by hand? Here’s an easy tool. Now, do you see RPA as primarily being rule based, or—I know you have an orchestration product. I don’t know if that’s primarily rule based, but how do you do RPA in a way that it’s accessible by as many people as possible?

    Ariola: Yeah. So, I mean, also knowing the demographic of your audience, RPA certainly falls into the bucket of, nothing new has be invented here, right?

    Ashley: Mm-hmm.

    Ariola: This is [Laughter]—this is definitely technology that we’ve had awareness of in the past. But it’s been uplifted for our era, right? Is really what makes the difference, right?

    So, you know, whether it’s rule based, whether it’s AI, whether it’s—it really depends on the task you’re trying to achieve, because not everything fits every scenario, right?

    Ashley: Mm-hmm.

    Ariola: So, if you—let’s try it this way, though. If you look at RPA and you take, let’s just take roughly 75% of the use cases out there, it falls into one of three buckets.

    Ashley: Okay.

    Ariola: One bucket is what I call poor man’s integration. Which is, you’re scraping information out of one system and you’re putting it into another system and then validating it in another or something like that, right?

    Ashley: Okay.

    Ariola: Meaning that you’ve gone to your IT group and you’ve said, “Hey, I got this integration project that I need” and they say, “I don’t have enough time.” And then you’re saying, “You know what? I’m just gonna do it myself with RPA” and you’re just gonna do it by scraping screens and moving and pushing data across multiple systems. Or maybe even—

    Ashley: “Here’s some vise grips and a crescent wrench, go fix it up.”

    Ariola: Exactly! Yeah, exactly.

    Ashley: Okay, yeah.

    Ariola: By the way, I call this poor man’s integration, or these kinda RPA use cases the best identification of backlog that you could ever have, right? You know there’s a problem here when you use it for this problem.

    Ashley: Okay.

    Ariola: So, the second group of activity that has been used is the augmentation or automation of manual tasks.

    Ashley: Okay.

    Ariola: And this is what you primarily hear about, right? So, instead of having me do the mundane task of pointing and clicking, going to another system, copying a number, bringing it over, taking—finding the core account number from a subsystem and pulling it into the work order, you know, pulling information from SAP and pulling it over to SFDC. You know, all that kinda manual stuff that’s going on in between. This is the second scenario that you’re just helping the human do something as part of their day to day activity, whether they’re processing an invoice or monitoring inventory or onboarding an employee or, you know, any kind of horizontal process that’s happening in the organization.

    And then there’s the third scenario that it’s being used for, really, which is—validate critical checks. So, when I say validate critical checks, let’s take the scenario, like, that we all got indoctrinated to in the last two years, which is GDPR.

    Ashley: Mm-hmm.

    Ariola: Where, if someone opts out from an e-mail perspective of your system, you want to make sure that they’re opted out of all systems of record. So, you might want to build a queue of opt-outs, which, the RPA engine comes in, grabs a unique identifier such as an e-mail from that system, and then goes into all other systems or potential systems of record and making sure or giving us, you know, taking a visual snapshot that the individual has, in fact, been opted out.

    So, those are kinda like the three general cases. And, of course, we then transist multiple horizontal, vertical, and technical domains for those particular uses cases.

    Ashley: Well, I thought with that third example, you were gonna tell me that I wouldn’t have to click on that. I accept cookies any more on all these websites, but—

    Ariola: [Laughter] You can set up an RPA [Cross talk] for that, no problem. You could do it.

    Ashley: [Laughter] You could, actually.

    Ariola: You could definitely do it—yeah, yeah, yeah. [Cross talk]

    Ashley: So, talk to us about what would you say are the top one or two use cases that customers come to you and say, “Oh, you do RPA? I’m trying to solve this situation”—what is it?

    Ariola: You know, it’s really funny, because it’s really across the board. And the industry is starting to sub-segment themselves now into vertical and horizontal type processes or technical—so, there’s three ways that the whole industry will ultimately segment. You’re gonna have pure plays, right, that are gonna be cross industry, cross horizontals. You’re gonna have some horizontal folks who are gonna go across—like, so, for example, we’re seeing new companies pop up that do just kind of HR RPA. Meaning, getting information in and out of HR systems, sensitive data—blah blah blah. And then you’re getting some vertical stuff. Like, you know, you have folks like, you know, Statenical and Edgver, which are Mphasis companies that are in the financial vertical that are really, really good at doing some stuff in the financial vertical.

    Ashley: Mm-hmm.

    Ariola: But in terms of us, you know, there’s really only—I would say there’s only about four or, three or four sure plays out there. Tricentis RPA is certainly one of those pure plays, and you know, we see a lot of insurance scenarios where you’re doing payouts, payment validation. We see a lot of things like supply chain data verifications a ton, a ton of that stuff.

    We’re seeing a lot of IoT type scenarios where a sensor is collecting information from one particular device and it needs to be married up with other IoT type of devices out there collecting information, and via an API, it’s being all sucked together and orchestrated together with RPA in order to produce an outcome, right?

    Ashley: Mm-hmm.

    Ariola: We’re seeing a lot of things around tax and payroll type steps and validation. A lot of stuff going on around SAP as well, by the way, for some reason.

    Ashley: Mm-hmm.

    Ariola: So, getting stuff in and out of SAP. And this is, there’s two major things going on, here. First of all, from a merger/acquisition perspective. So, in order to gain the short term benefits of any M&A activity without necessarily having to invest in the entire integration plan, you know, you can use RPA to assist you in moving data or updating records or updating customer numbers, right?

    Ashley: Mm-hmm.

    Ariola: And then you’re also seeing scenarios like it being used for S/4HANA migration, which is also really interesting. So, those are kinda the things you’re seeing, but it’s all over the place.

    Ashley: Yeah. Yeah, you know, I love the IoT example, because—I know it’s not your technology, but everybody knows “if this, then that,” right? That’s sort of the universal—

    Ariola: Yes.

    Ashley: Doesn’t work for every scenario, but it certainly is a great example of a really simple way to do RPA for IoT events and happenings. Talk a little bit about why did make sense for Tricentis to expand from automating testing to more generally providing an RPA solution.

    Ariola: Yeah. So, thank you for asking that, because I do happen to get that question quite often. So, at the core of—Tricentis’, you know, a real differentiator in the marketplace is this technology we have called model based automation.

    Ashley: Mm-hmm.

    Ariola: And most of what you’re gonna see today out there from RPA vendors are scripted technologies or technologies that use image based controls to understand screens. And the script based technologies and this image stuff, by the way, is the prime reason why software test automation has been so difficult. Because scripts fail.

    Ashley: Yeah, I was just gonna say. [Laughter]

    Ariola: Yeah, they’re brittle. They basically are hard to update. It’s hard to maintain. You know, it’s the old adage of keeping in sync with the code base and, you know, RPA is highly susceptible to changing UIs. And this is where we shine.

    So, our model based automation is actually, takes a much, much more technical approach. So, where most of the vendors out there, if not all of them, interrogate a UI from a screen perspective, we actually interrogate the implementation.

    Ashley: Mm-hmm.

    Ariola: And understand the UI from its more technical implementation perspective. So, if you take SFDC or if you take SAP or you take ServiceNow or any of these big, large vendors, the complexity of the UI even through a browser is pretty significant. So, the fact that we actually interrogate it at a technical level to build an abstracted model gives us the ability to deliver real, resilient automation.

    And what I mean by that is that, you know, we—universally, in our platform, you cannot script. If you wanted to script, you’re gonna have to go somewhere else, because you can’t script, because ours is model based. So, everything that we’re doing is actually produced from technical observations of the application itself. And then we allow you to put those observations or components that you discover—reuse them as LEGO blocks, right, and put them into different flows.

    So, the good thing is that, when the UIs change that are part of the automation, (a) if you have to make a technical change, you only make it in one spot, and that change propagates throughout all instances or all bots that are using that automation, and (2) because we actually do a highly resilient technical implementation, you know, we self-heal our technology or our bots in roughly 80 percent of the change cases.

    So, this is why were successful and still are successful in software testing, and this is why we decided to bring this to RPA, because it faces the exact same challenges.

    Ashley: Well, it’s almost a knowledge based approach, thinking about it as a model oriented solution, if you hearken back to screen scraping days, which is the brute force—

    Ariola: Yes.

    Ashley:—this vector is where the information is at that you’re testing—

    Ariola: Exactly.

    Ashley:—to a model based, which is more of a canonical based approach, which is a defined—

    Ariola: Absolutely.

    Ashley:—you have a way of determining what the information is and then you can detect when it’s changed. “Hey, there’s a new field. There’s a new—this field’s changed,” you know, whatever, it’s not in place.

    Ariola: Yes.

    Ashley: Now you have some reference model to pull from. It makes a lot more sense now. You can put logic based or flow based logic into an automation process rather than having to script it into everything as manual. I think that’s what you’re saying.

    Ariola: Absolutely.

    Ashley: Do I have it right, here?

    Ariola: You have it 100 percent correct. So, it also gives us a broader reach within the organization as well. So, you don’t have to rely on the highly technical skills to actually produce the automation or, even more importantly, maintain the automation that’s required by your business.

    Ashley: So, does this open up different people that you’re selling to in the organization? Are you still selling through the DevOps test organization in IT and you kind of expand what other places you can apply your RPA technology? Are you now calling on business units, end users, other application areas? What’s that mean for your business?

    Ariola: So, whoever has the problem, we certainly want to talk to about assisting them to solve it. You know, within the DevOps space, there’s a lot of conversation about maintaining the scripts that are automating everything around my infrastructure is painful, right? So, there’s conversations that are even in that horizontal area. However, you know, the skill set that’s mostly in that domain is highly technical, so, you know, there’s a lot of preferred—a lot of preference to actual scripting there. But within the line of business, there’s certainly a lot of conversation going on, and that broadens the conversation.

    But believe it or not, you know, when you’re talking about tests and test automation, although we do think of it as kind of a Dev test in motion, when you look at what Tricentis does, which is more end to end testing and protecting the end user journey because we cross applications, we have a lot of conversations with the business analysts. We have a lot of conversations with the line of business.

    Ashley: Mm-hmm. I can see that.

    Ariola: RPA tends to skew that more to the line of business, but what we’re noticing distinctly these days is, RPA is coming back to IT. And there’s a real, really interesting reason for that, and it’s what’s called the RPA death spiral. Which, it goes something like this. You asked IT to do an integration for you, but they were too busy. You decided, “Hey, by the way, I’ll use this RPA thing to bridge the gap right now” and you called in an RPA vendor and a service partner and you got your initial flow or bot stood up.

    Ashley: Mm-hmm.

    Ariola: But then again, you just don’t wanna—you don’t wanna spend a lot of money keeping that service partner on site because it’s expensive, and they go away. And once they go away—guess what? The interface changes on one of the automation sequences or bots that you have enabled and the bot breaks. And as soon as that bot breaks, [Laughter] where are you gonna go to? Well, you’re gonna go to IT.

    Ashley:Well, I can imagine.

    Ariola: And then IT—yeah.

    Ashley: Yeah, people come back to IT because the problem that they’re automating gets bigger than they want to handle or can handle.

    Ariola: Absolutely.

    Ashley: Or they need access to resources—“Hey, I need single sign on here to get to this information. I need this database that isn’t—

    Ariola: Absolutely.

    Ashley:—easy for me to get to as an end user.” So, lots of reasons.

    Ariola: Absolutely.

    Ashley: You know, things happen outside of IT because they’re easier, but then we need to go back to IT because they’re necessary to get what you need.

    Ariola: Absolutely. That’s why it’s kinda swinging back to IT. Now, also what’s happening is, when the line of business acted kind of like a shadow IT or kind of a rogue IT shop and adopted the technology, you know, now the CIO is essentially inheriting the maintenance tab.

    Ashley: Mm-hmm.

    Ariola: And now this is why, you know, the conversation is swinging right back to IT and the CIO.

    Ashley: I can see that. Yep.

    Ariola: And we’re back—from Tricentis’ perspective, you know, we’re back on home turf talking to the nerds that we like to talk to.

    Ashley: Mm-hmm. Well, this has been great. I really appreciated having you on, and a new topic for us on DevOps Chat with Tricentis. I don’t believe we’ve talked with you about this before. It sounds like you’re a big enough believer, you’d change your job to be the general manager of RPA.

    Ariola: [Laughter] Yeah.

    Ashley: I can tell you’re committed.

    Ariola: There’s no goin’ back—there’s no goin’ back now, yeah.

    Ashley: Exactly.

    Ariola: I’m committed.

    Ashley: Exactly. Well, it’s been fantastic, Wayne. Thanks for being on the podcast.

    Ariola: Absolutely my pleasure, Mitch. Thanks for having us.

    Ashley: Well, I hope you come back and we get a chance to talk to you again and maybe we can dive into some of the use cases you’ve solved for customers and some of the learning, so we’ll save that for another time, okay?

    Ariola: Love to do it.

    Ashley: Great. Well, you’ve listened to another DevOps Chat podcast. I want to thank my guest today, Wayne Ariola, who’s general manager of RPA at Tricentis. And, of course, thank you to our audience for spending your time with us today—it’s valuable, and we appreciate it. My name is Mitch Ashley from devopsy.kinsta.cloud and you’ve listened to another DevOps Chat. Have a good day and be careful out there.

    — Mitchell Ashley

  • Getting RPA Right the First Time

    Getting RPA Right the First Time

    Remember when every article you read about IT focused on digital transformation (DX)? Now the broad concept of DX seemingly has taken a back seat in the headlines to a number of hot technologies. One of these, Robotic Process Automation (RPA), is frequently positioned as the new next big thing of the tech world. But if you look closely, you’ll notice that DX never really went away–RPA is really just the latest piece being added to that larger digital transformation puzzle.

    Digital transformation is often explained as an ongoing journey that promises to help organizations break the traditional boundaries of enterprise IT, empowering business line workers to enable the delivery of faster outcomes and better experiences to customers. An important part of DX is eliminating the rote task work that plagues day-to-day operations. That can only be done with transformative automation technology. It’s no wonder that many organizations worldwide are focused on exploring, implementing or scaling RPA to help check that box.

    But as the RPA hype cycle starts to crest, don’t be fooled into thinking that RPA is the single turnkey solution to your enterprise problems. There are ways to avoid common pitfalls that are starting to emerge in RPA projects and ensure its successful implementation and achievement of business results.

    RPA projects need proper planning, a strategy and an implementation team, all tied into broader enterprise systems and process management. Without these, organizations are bound to face costly delays that can affect deployment plans and return on investment (ROI). In fact, a recent study from EY found 30% to 55% of initial RPA projects fail. In another industry survey, it was reported that 87% of respondents had experienced RPA bot failure while reporting that maintenance was the second biggest concerns users face.

    Here are the most common mistakes organizations should avoid to achieve real results.

    Thinking RPA is Easy Since It’s Everywhere

    This is perhaps the most common myth around RPA–enterprises expect to purchase a solution, train business users to build automation and see the ROI start to accumulate. It is reported that only 39% of bots are deployed on schedule, and it typically takes 18 months to push bots into live production. This is hardly an out-of-the-box solution.

    But we all know how difficult technology implementations can be. Very few things in our industry are truly plug-and-play–no matter what sales professionals might say. While RPA is pitched as a way to solve menial tasks, there is nothing menial about the process of automation and developing an application tailored to how work actually gets done. It is possible to train up employees to build simple automation, but the true results will not be realized without an end-to-end approach that takes into account the broader outcome the automated task is supporting.

    Remember, your business has rules on security, compliance and governance–all critical to the success of an RPA deployment. Are you considering these factors and all the affected stakeholders across the entire organization when trying to fix a problem within one department?

    There is a place for business users building automation, but to get to real scale and potential for transformation, IT needs to work together with stakeholders across different lines of business to design an end-to-end intelligent automation solution that ties into pre-existing business systems and accounts for their sophistication/complexity, while also accounting for where humans need to be involved.

    Attended or Unattended?

    RPA is the hottest trend since cloud computing, and it boils down to two basic forms: attended and unattended. Simply put, attended requires the help of human interaction on the desktop, while unattended takes over tasks without the need to interruption. Is one better than the other? Not necessarily. In the right situation, both can generate quick wins and task automation to assist the workers.

    Consider the desktop of call center agents. These workstations are known for having deep integrations with legacy technology that are geared toward repetitive, scripted and manual tasks. This provides the perfect opportunity for attended RPA deployments to address these types of functions that take place across the entire call center, delivering better customer outcomes and generating business value.

    There is a time and place for both attended and unattended solutions–it is important to understand which capabilities the RPA vendor is offering and how they will address the needs of your current situation. In many situations, attended can be an unexpected source of ROI opportunity, as the total volume of work automated in environments such as contact centers, can far exceed the amount of non-human assisted work that can be automated.

    RPA Will Solve All My Problems

    RPA is great—I wouldn’t be writing about it if it weren’t. But it’s not the end-all digital investment automation platform; it’s part of an organization’s digital transformation strategy and can create serious business value when used the correct way. Automating and streamlining the complexity of multiple, long-running processes that interlink internal and external systems, machine and human work, bespoke software and third-party apps and systems is not what RPA was created to do. That’s the work of a BPM solution  supported by  Case Management. Businesses need to realize how RPA fits into their overall digital transformation strategy and where specifically it can be applied across their organization to realize its true benefits.

    You’ve likely heard of the old saying, patience is a virtue. Let’s apply that to RPA deployments. There is so much promise and opportunity for RPA within the enterprise, but the major ROI numbers that some expect may not be there–at least not yet.

    Finding the right opportunities for RPA technology within the organization, getting company buy-in and developing and deploying the solutions all take time to create an impact. Businesses need to approach their projects with a strong understanding of where RPA can be applied and what it does well, like automating high-volume, low-complexity, rule-based tasks within an end-to-end enterprise process automation strategy, to realize the business benefits it brings.

    — Nolan Greene

  • The Barriers to Robotic Process Automation, Part 2

    The Barriers to Robotic Process Automation, Part 2

    Enterprises are rushing to embrace robotic process automation (RPA) but, as we covered in The Barriers to Robotic Process Automation, Part 1, they’re also hitting considerable challenges along the way. While we cited prominent barriers to the effective implementation of RPA in part one, here, we will provide practical ways organizations can overcome these barriers.

    One of the biggest causes of RPA failure is the lack of executive-level sponsorship for such initiatives. When it comes to RPA success, getting management’s attention–and keeping it–is essential. One way to do this is to focus on RPA quick wins and efforts that have a measurable return on investment.

    Next, IT leaders need to understand how significant digital transformation is to AI technology.

    “An efficient digital transformation strategy will eliminate internal IT silos through integration and automation, leading to opportunities for AI projects,” said Marcel Shaw, AI expert and Federal Systems engineer at Ivanti. Shaw pointed to how organizations that interface with customers will see opportunities for chatbots that leverage natural language processing technology, thereby reducing demand on operators while enhancing the user experience.

    “IT leaders will be able to take advantage of machine learning technology that will support and enhance complex automated processes that will fulfill customer requests from beginning to end, without intervention from a human analyst,” said Shaw.

    Such benefits could make RPA an easy sale to executive leadership. Other benefits that can be used to sell RPA to leadership include cost savings, more efficient processes, improved process quality and free staff to focus on higher-value tasks.

    “The only thing holding AI back at this time is a lack of experience with the technology. AI will take many years to develop. Some estimates point to a 75-year maturity lifecycle for AI. AI technology is designed to learn. As it learns, it will correct mistakes and mature, much like a human has to learn,” said Shaw.

    Next up: The high level of investment needed for effective, automated and intelligent robotic automation.

    “There’s a great deal of catching-up to be done before most companies can even consider building out their own advanced developments with AI,” said Salvatore Stolfo founder and CTO at Allure Security. “It may be more cost-effective and faster to partner with a software vendor that has already put the time into dedicated research and development to build an AI-powered solution, and then customize that solution for your particular use case.”

    Simha Sadasiva, CEO at Ushur might agree. “Many intelligent automation solutions on the market today require a heavy IT investment. This can include hiring an outside third-party just to manage the platform they’ve invested in,” said Sadasiva.

    “Those attempting to manage the technology in-house are finding that it requires personnel with sophisticated developer-level knowledge, which is in short supply today. These issues are causing some companies who were initially interested in exploring intelligent automation solutions to abandon their projects altogether,” added Sadasiva.

    Sadasiva said one possible way to solve this is to evaluate potential zero code platforms. “These are SaaS-based intelligent automation solutions born in and live in the cloud,” said Sadasiva.

    Finally, and while perhaps self-evident is often overlooked: know what needs to be achieved with robotic process automation.

    “An organization needs to identify what the problem is that they are trying to solve with AI. This needs to be the most important pain point to them at that point in time. Inherently AI requires data to be able to train the machine to learn,” said Ben Mercer, co-founder at personalized web experience provider Personify XP.

    “The challenge for some organizations, when it comes to accessing data, is that valuable data is stored on legacy systems and difficult to extract. In cases like this, it may make more sense to train the AI on new data, than fighting with legacy systems that may delay or reduce the ROI of the deployment,” said Mercer.

    Effectively managing data, AI and the resulting automation requires staff with strong skills and experience in these areas.

    “Regarding skillset development, most of the skills needed can be learned, but you need to find different types of team members who have a great comprehension of data and database management and secondly a development background,” said Jesse Tutt, CEO at mattress company Gotta Sleep.

    Finally, chances are if an enterprise is planning to do something there’s already someone who has tried and has lessons to share. “Every automation project has likely been done by someone else already. Tips and tricks are freely available from others who have more experience so networking on Linkedin, meetups, and conferences are key,” adviced Tutt.

    — George V. Hulme