RPA & IA Live - SPEAKER SPOTLIGHT : RPA For the Enterprise.

Hello, everyone, welcome back to another exciting session on RPA and intelligent automation live. Our next speaker will be Eric Fisher, Senior Solutions Architect for Micro Focus. He's going to talk about RPA for the Enterprise, And the Eric has bandwidth microscope, is for the last 13 years. By way of where the exciting, he has nearly 20 years of industry experience in generation and orchestration, nitrate product evangelists for the last two years. Talk about RPA for the enterprise. Please welcome Eric Fisher.

Good morning, everyone. Thanks for joining. I appreciate the introduction. Just say, again, my name is Eric Fisher, I'm a solution architects, that micro focus. And today, we're gonna be talking a little bit about enterprise RPA, and what that means and how that's different from just, you know. That, any researcher having exploration on RPA and some of the differences there. So, I'm, you, have been the subject matter experts in our RPA since we introduced RPA a few years ago. But you've been following our and managing our practice around automation for, it's, just mentioned about the last 13 years. Or so and happy to, to join you today. So we'll be talking a little bit about RPA. Hopefully, that makes sense.

With that, you know, what some of the differences are with, with enterprise class RPA. And go through a couple of customer use cases, including one of our own, that we're pretty proud of for one of our internal business units. And then we'll be closing out with any questions you might have. So first, by nature of that definition to make sure we're speaking the same language, so RPA robotic process automation is basically a software robot technology that mimics human based interaction with IT and other systems, business process systems and in the environment. And I want to emphasize that that UI based human actions that's that's really critical to understanding the difference between your RPN general versus some of the other technologies around scripting and inactions orchestration that exist.

So with, with Enterprise Architect RPA. What you're doing, is really, really combining this notion of screen recording capability, you know, to be able to play that back in, in workflows to simulate, or automate business processes. And critical. And key to Enterprise Class RPA is to do this in a 24 by 7 mode, mission. Critical needs with data protection and audibility built into it. So how do I get to doing RPA for me? For instance, I want to automate my task to, now I need to extend this to the rest of the enterprise, And because I'm doing that, I need to make sure it's safe, secure, resilient, and, and, you know, works reliably anytime in the day or night.

So where does RPA come from, in fact. So if you've been in technology long enough. You probably remember, you know, on your desktop this little macro recorder where you could, you know, hit record and record what you're doing. So, you know, maybe doing some work in a spreadsheet or opening up an application, or you can record that test. And I remember back at least 25 years ago saying that on my desktop. So, really coming, you know, a long, long time in the comment, coming on that. Then about 20 or so years ago, you know, the industry introduced this notion of test automation. There were a few products out in the industry, mercury interactive, you introduced their functional testing application.

Really geared towards how do I automate, um, the testing of applications in a very resilient and repeatable way, You know, application testing, UI testing, make it very repeatable in.

The early.

Yeah, late 20, two thousands, 2007, 8 9 really. Was this growth, is hyper growth of orchestration number of players came out, really. The idea was to, how do I automate IT processes and how do, I know, automate, bring together multiple disparate systems from an API, command line perspective, and make that re repeatable? ..., put things in production. You know, turn, turn command lines into APIs and such. So really over the last five years with, with RPA, it's really taking the best of both of those worlds. And opening it up to a new set of users where you have more business centric or UI centric users that are trying to do mission critical or important tasks for the environment. So, it's merging this IT process with UI process, You know, backend systems in front end systems attended mode versus unattended mode.

Bringing this all together in a single, you know, Enterprise type of application, always available.

And, you know, the best way that I can find to describe this is to put this into terms that are a little bit more plain language, and I like to use this scenario, because it really does help me to explain a couple of things I talk about when I talk to my customers.

And we're going to use an analogy, though. I think most of us, if not all of us, are familiar with. And that's that of a toll booth, right? Whether you're going into a parking lot, or going through a toll road, the ideas, you've got two people that are negotiating a negotiating exchange of goods, for passage. In this case, we've got a car that drives a toll booth. You know, the toll taker says, that'll be two bucks. That. You know, the person in the car. Hands, the toll taker, a $5 bill, expect some changes. Expects receipt, hopefully, if everything meets the requirements, the gate opens up in a toll road and the drivers a lot pass through.

So RPA is really around changing that experience to remove the human interaction, part of it, to turn that all into a robotic process. Driver comes up and no longer has to communicate with the person, Just hits the big red button. And and, you know, they continue with their No process to exchange that currency for passage on the toll road. What I want to stress with that is RPA is not about process changed. And it's not about the process re-engineering when, you think about implementing it, kinda crawl, walk, run, you know, scenario for implementing automation. The worst thing you can actually do is jump right to the run stage without getting there. Slowly in the, in the best way, you can get a huge return on investment on, on really any automation. But in particular, RPA is to look at what your manual process are today. The ones that are manual the ones that are very repetitive. And how do I automate those using the process that exist today.

Not changing change control process, not implementing new steps. Not making any other tweaks or changes, but literally just, you know, implementing the process as it is today and hardening it, making it secure and making it resilient, and making it available to anybody in the enterprise to builds run.

Hopefully, that's clear to everyone.

So, what is needed for enterprise RPA to work?

Well, it all starts with a foundation of, of, you know, kind of an enterprise orchestration platform. So if you're not familiar with Orchestration, again, I mentioned before, this is a, a technology platform allows you to automate multiple different kinds of tasks, and historically, will, last 10, 15 years, this has been around IT processes, things, like incident change event, and be able to do that through ad hoc, or scheduled activities, or even embed these into your service request process. The purpose of orchestration is to bring together multiple teams will tools multiple environments, so you can run consistent processes you know all the time by any user.

I like to think about this is kind of, you know, if you think about the Staples, if you're familiar with the Staples, office supply store, a while back, they have this campaign, really used the big, red, easy button. You push the button, you know, the voice comes out and says, that was easy, and the job was done, right? That is really what orchestration is trying to do for our users, is to implement that kind of easy button to implement, you know, any kind of task that you might need. And as we surveyed our customers and the industry got survey, this was a survey that was done by Tech Validate a few years ago. Really, the, the results today haven't changed, but these are the top use cases that enterprises and executives are looking to automate with orchestration in general.

Right. So, task and process automation, predominantly, is a huge use case and there, you also got event and incident remediation change, management ****, done less. Galois things are in Cloud and network Management application. Deployment DevOps is becoming a growing one fact. Actually. I'd be willing to bet that, if we surveyed, again, DevOps would be a lot higher than 28% of this point disaster. Recovery automation, the ideas. All these use cases have, something very common, very similar in common. That, is, the ability to push the button, to execute a task very, very repeatable over and over and over again.

When you start looking at RPA, the requirement doesn't change just how you interact with your different systems does.

So what you get with RPA is that same orchestration engine in this particular around enterprise RPA, get the orchestration engine that is very scalable, very powerful, you know, highly available. But now you've put behind it an army of robots. These robots now have the ability to execute tasks through a user interface, whether it's a, you know, a web based application, that thick client, a thin client, a terminal emulator, you know, some sort of a UI technology on a desktop.

You know, mimicking mouse movements, mimicking commands through through interfaces, be able to pull this together, using that same capability that we had before around workflows, but now bringing in UI automation into that.

So this notion of robots on demand, is as part of the orchestration, is really at the heart of what enterprise RPA is. How do I have robots that have various skills associated with them and scale them up and down based on time of day, the day of the week, day of the month, And do that? Only when work is needed and when works, not needed, scale the robot. Army back down, so that it's doing, you know, and consuming less resources, and you can reduce the enterprise footprint you have on your server farms, et cetera, for running and manage the infrastructure.

So, the idea to scale up and scale down, as needs and demands change.

To shift around, you know, what is required for enterprise ERP RPI And so, this is, you know, a couple of points I want to emphasize. And we're getting, you know, a little bit more detail on a couple of these. And, I'll talk through how this impacts, you know, a couple of use cases.

But really, enterprise RPA focuses on, know, first of all, ease of use and accessibility. You know, it has to have an easy to use designs experience. No access to low and no code authoring capabilities. The ability to drag and wire multiple steps together and multiple recordings together multiple API calls together. Very quick and easy to, to adopt and where. That's very critical to be able to adopt Enterprise class system. It's one thing, when you're running an RPA tool on your own desktop, but when you start scaling us out to hundreds, if not thousands of users, it has to be very easy to consume. And that's it. Yeah. I don't want to understand that. The second is this notion of round resilient robots. So resilient robots is the ability to adapt to UI changes in and look at advanced in an intelligent object recognition. So what does that mean?

And we'll get into a little bit more detail about this because the idea of being able to not just follow XY co-ordinates of where the mouse is because that has inadvertent challenges to what happens in screen resolution changes. What happens if the user changes, how do you consistently, reliably know, repeat a recorded process? If you're relying upon where the mouse is clicking on a particular screen, and on your desktop, so resilient robots, it really is the ability to look away from X Y co-ordinates and start talking at the protocol level two for the applications you're interacting with.

Third is this notion of the central robot orchestration, just talked about that a moment ago on the previous slide. This is really, how do I take my UI, automation, merge it with my API automation, and create, manage robots? Do this all centrally?

Do this from a hosted or a managed solution, and do this at a very scalable mission, critical, happened.

Now, all of this is great.

But if you can't access it, if you can't execute these things, then, you know, the usefulness of, the technology starts diminishing. And so, having some sort of a self-service portal, or an API, or an interface to be able to execute these things, is very important. For enterprise class RPA.

Again, a lot of the early RPA adopters were very desktop centric. I can open up a widget on my desktop, or double click on an icon. It will execute my task for me Again, think way back 25 years ago around that Mac or quarter was only as good as having that macro on your desktop and be able to double click on it and execute that process. Right?

So extending that and making available to anybody is very, very important here, As is the scalable robots, which we also just talked about. So, how do I scale up and down based off of the workloads that are being asked of me, How do I ensure that I have enough capacity to do my job? You know, if I've got an end of month, you know, Financial report tasks that I want to do?

For instance, I've got a customer of mine that their requirement was to, at the end of the month, they wanted to execute a thousand times in concurrency, pulled down, simultaneous reports, assemble them together, and get the results out to a decision makers in the organization as quickly as possible.

Prior to implementing our RPA solution, they were spending, know, a month trying to pull together all the reports, And the more people they throw into it, you know, they could shrink that time down. And just, prior to implementing RPA, is taking them a week. So every month, they spend the last week, you know, putting all these reports together.

And now they can do it in the matter of, you know, I wanna say minutes, but definitely hours, fully automated from, you know, an unintended task is scheduled to run, you know, at 10 o'clock, in the last day of the month, and executes the task completely seamlessly, without people being involved.

Then the last thing, anytime you talk about enterprise, the criticality around encryption and data protection sensitivity, you've got the privacy requirements coming from Europe and the new ones coming from California. And more states will, you know, most likely follow in the coming years. But how do I ensure that What I'm doing and what I'm controlling is secure, is controlled and protected. And then if I ever had any challenges or problems, I can go back and understand what happened is, you know, has a full audit log with it.

And you can use that audit log to understand, you know, timings and even have its own ROI calculator built into it so you understand the value that it's returning back to you.

Now, I wanted to double click on a couple of those topics. So, the resilient robot, here's a couple of screenshots I'll show as an example. Right. So if you've ever used salesforce dot com, you'll probably recognize the screen.

The challenge with automating salesforce dot com is every user is going to have different, a different interface experience. Maybe they've used dark mode versus light mode, or they've hidden certain menu objects, or anything else.

So if all you're doing is recording your sessions then you know, what happens when you execute this on user number one, but user number two has a totally different desktop layout for their application? Are they gonna be able to Find, you know, the Cases menu of the cases menu is hidden, or move to the far left?

So, Native Object recognition is really around looking at the protocol level of the application, understand what it's doing, what field you're clicking on, what field you're reading, and understanding the application at that level, and putting in some intelligence into it. So, that if an OK button changes, its wording to a Submit button, that the, the recording and the playback of that recording still works consistently reliably.

And being able to do that, not just the web level, but things, you know, thick clients like sap, or Terminal emulators, like Rumba and Reflection X and Putty. Web based applications. Whether HTML or Flash or HTML five and things as simple as just a generic Windows applications, things, like an Excel application, you know, PowerPoint, you know, Microsoft's MMC and things like that. So how do I more natively understand the unique user interface, so that I don't have to worry about re recording my interface every time something changes.

And the second thing that I want to double click on it, this notion of the easy to use Design studio.

Please my recommendation is don't be fooled by the difference between easy to use, and low, and no code, right. So low and no code is, is, is certainly a feature of easy to use. But what tends to happen is, a lot of the RPA vendors out there are, kind of hiding so much, the complexity around how the product works that it becomes very inflexible.

You want to look for a product that not only lets you kind of adopt a low no code, you know, RPA strategy for, know, for doing things very quickly to your recording, your process very quickly. But then it gives you that advanced flexibility for no brain advanced scripting technologies, things like Python or JavaScript, be able to put in regular expressions as needed as you need to improve your skills as you need the capability to do something more sophisticated.

And you marry that with a repository or a library of out of the box content. So, that for a lot of the more common things, you don't have to do that scripting.

For anything recording, you don't have to do any scripting, but then, as your needs evolve, as you start integrating with no customer proprietary applications that the industry hasn't seen before, because you know your written them in house. How do you integrate with those particular applications? How do you onboard them into your RPA process? So, that's really you know, I just want to stress that one more time as you know, don't pigeonhole yourself into a product that you know limits you, to you know, very specific tasks or or interfaces and it gives you the ability to start there. But then grow as your needs.

Now this one I'm not going to read, but this was actually from the Forrester Wave Report. The last one that was done on RPA, but really distressed that, you know, first of all, there's, there's 100 and something, different RPA, vendors in industry. And this is a sampling of the, kind of the top three, there's about five or so, that kind of, are in the upper, right-hand quadrant of the wave report. But essentially, these are some examples of some of the top three vendor deficiencies. So as you're evaluating RPA products, you know, I wanna leave you with two thoughts.

First of all, look at what you're trying to accomplish, and how you're trying to accomplish it, and make sure that product does what you need to do.

Second, is RPA is relatively inexpensive. Most of the customers working with have, at least, for RPA products, because they have different needs to have RPA products that are therefore desktop based automation, or, or, you know, our RPA that's doing certain web based tasks. And the industry is still evolving to the point where there's no clear one winner. There's multiple different ways to do something. Every vendor has their own different strategies. Some strengths and weaknesses of, the key thing is making sure that you're picking you, if you haven't gone down the path, is the vendor that gives you the most amount of flexibility security availability for the processes you're trying to automate?

And so, now we start talking about the customer side of thing, who actually needs it? Who are the customers and what are some of those customers doing?

So, I kind of teased about this at the beginning, but there's really two.

Mainly, two personas in the RPA field, there's, this, are, you know, IT centric user and a business centric user. With the IT side, what they're looking for is the ability to continue down the orchestration path, but grow beyond what their knowledge that allows them to automate with.

So, one of my customers, you know, they got stuck with, with their orchestration product, not because the technology was lacking, but because they lack the necessary subject matter expertise to integrate with everything they were being asked to integrate with. They were trying to build provisioning workflows, but they knew nothing about provisioning into storage or provisioning into the network. And the network team, the storage team, knew how to use their tools but really didn't know much about the APIs for the tools and knew nothing about the orchestration language.

So you've got this kind of chicken And the egg problem around, you know, orchestration and automation in the data center, where you've got a set of users that need to automate something, but they don't know how the process works.

And the you know, the users that know how the process works, don't know how the tool works. Or how do you get these two teams to work together without doing a whole bunch of cross training?

So, the answer really becomes give the subject matter expert the recorder. Let them record their process, hand the recording back to you, and then you embed that into, Into the, the automation workflow. And that's really one of the areas where RPA is becoming very beneficial in the IT space.

On the business side of things, you know, it's everything that's been driving our pace in the very beginning of time, I want to grow my work, You know, workforce workplace, efficiency through automation. It's not necessarily about optimization. I just want to do my job and do it for me.

Well, chances are, if I need to do something for me, that there might be 5 or 10 other people that have the exact same need. So, instead of building something just for me, how do I build it for a bunch of nice, you know, my entire team or my entire division. When you start looking at large call centers and example of banking, call center might have 2000, no agents that have the same exact need every single day.

These are not programmers. These are not coders. They don't know how to write workflows. They don't know how to embed error correction. All these other things, You've got a team of automation, people that are very good at doing that.

These people know how to do their daily job, which is answer the call, look for some answers. You automate the process of gathering information and providing it back to the user. Well, if I can do all that and record that and hand that somebody, who can then put that into an automated process, then as a call center agent, all have to do is just click the button and then information comes to me almost immediately.

Right. So, mundane repetitive, error prone work, something that costs, you know, time on the phone with a, with an operator, between an operator and customer and things like that.

So, me give you some, a couple of real-world examples with some tangible information behind it. So the first example actually happens to be our own example. So Micro Focus is a very large software company. We've got about 18,000 employees worldwide. I like to describe micro focus is the largest company that probably never heard of, but you probably at some point of used our technologies, if not today in the relatively near future or recent passage.

You know, we're a global organization, We support hundreds and hundreds of companies, countries, you know, thousands of companies worldwide, multiple different languages, and multiple different currencies as a result of that. So, the challenge for our finance department was: how do I keep up with that pace?

How do I make sure that when we do a quote, that when we look at our, you know, forecasts reports, you know, when we look at the data that requires us to have, you know, dollars and currency involved, how do I make sure I'm doing it with today's information?

And so as any large companies do that's now global in nature, is that we have a person on staff.

Every day When they get to work, the first thing they do is they login to the request builder, which is an application from, from Bloomberg downloads the latest financial reports. Inquiry in particular, grabs the currency. The central bank exchange rates for the currency. And then imports into the Oracle NetSuite application that we use for our Finance Finance Operations Management.

This takes, it's the same exact process every single day. And it takes that person 20 minutes.

Right, so it's very repetitive. It's, it's potentially error proof or error prone. There's, there's a risk of something going wrong. But it's, you know, it takes 20 minutes every single day, or that person's job repeatable. You know, it, everything leads to what we can do with RPA. So we, actually, in our case, use our own RPA product, and micro focuses RPA. We worked with a our consulting partner with the ..., and recorded that, amongst other processes, but reduce that to three minutes of technical time. And the person actually doesn't even have to be involved in war, is launched as a scheduled job. So every morning at eight AM, the schedule goes off, You know, when that, when that analysts comes to work. No longer do, they have to login, and spend 20 minutes doing that, particular task, is login to Oracle financials, to make sure everything was loaded from the previous day. And they didn't get any errors that resulted from some sort of a bad. Important.

So, they started a second example I want to talk about really quick, is an Australian bank. This is a customer of ours that has actually been using RPA longer than we've actually had an RPA product. What's interesting about this use case is, it really emphasizes some of the metrics around why you want to implement RPA.

And we'll talk about this and jump into Q&A, but, you know, there are problems with a very inefficient process, very slow response time. You know, what the use case was as a customer calls up to the bank and wants to change the bank account that they use for their automatic payment.

It was taking weeks, and you've probably heard this, if you've ever had to do this in your own, where the operator tells you, hey, thank you for the new account information. There'll be no 1 to 2, you know, payment cycles, before we get the new account information loaded up.

Well, the reason why is because of all the different steps required.

When they implemented RPA, when they used a consulting partner, just like we did in our particular use case, in the first two months. This is why this is so interesting. Around RPA on the first two months, they were able to process 15,000 loan variations in over the first year, 120,000 days of customer wait time.

Mean just think about the Roi in the Customer Satisfaction Scores that you that will result when you save 120,000 days of people waiting on phone And back end times 11,000 almost 12,000 hours of manual Processes saved.

So why was that so impactful?

Well, this was the process before lot of steps. There's an offshore team. Everything was manually handed off. There was batch printing. There was scanning of the forms, and it was validation manually, making sure the account exists. Those right account, a lot of manual steps. Every single one of these took a lot of time, and a lot of people and process.

So with RPA, they actually went ahead and automated the entire process end to end.

So before that old process took 14 days to go through from end to end, now, they're able to do the same thing With no people involved with the exception of very small onshore at exit exception handling team been doing all that same thing within a day.

So fully automated. So reduce security issues, reduce increase speed. Reduce the cost of being able to implement that.

So, really, I just want to emphasize a couple of things will go right into the questions. If you have any questions, please go ahead and add them to the chat manager. Now, if you've got anything queueing up, but, you know, really emphasizing on the time consuming error prone task. And I want to also add enterprise scale, Right. How do I make this repeatable, not just for me, but for my entire division, my entire company, How do I put things into a schedule and make these, you know, processes that you can do over and over and over again? Right?

So as you're looking at enterprise class orchestration, what should you be looking for?

Well, you should be looking for a solution that makes it scalable for you, that it makes it, you know, enterprise class. It's running on a server infrastructure. It's running in the cloud. It's always available. It's secure. It's leveraging resilient robots so that you don't have to constantly keep re recording your process. Because a version of the application has changed, or your infrastructure changed. Or you added a new user, that has different preferences in different layout, right. So how do I integrate to, again, go back to what I mentioned before. How do I look at the protocol and look at the application itself as opposed to the user layout and how that works on the screen.

The roi on RPA, especially when implemented correctly, is significant.

Every one of our customers that is implementing RPA has told us that they've gotten near immediate return on their investment. The very first use case often pays for the license, the support, the implementation costs, the training costs, and then some, give you that example before. You know, that from our own finance department, 20 minutes, every single day, Right.

That's, that's an hour plus a week. That is, you know, 4 or 5 hours a month. That is, you know, 20, 30 hours.

I mean, if you think about the cost of a full-time equivalent, right there that, that, you know, very first use case funds. A year of implementation and operations, an RPA product.

Every other use case, after that, becomes, essentially, know, you can think of just pure profit, right? There's, there's, there's no cost to it, or minimal cost, implementing additional use cases and low risk, You know, reduce your risk of human error. So, how do I actually remove the cost of human error, Every, is, people were, our natural instinct, is to, we think we can do it better. We know how to cut corners, and do it safely. The reality is most companies have to follow a process. Whether it's, I tiller know, some socks related process to make sure that we're doing it right doing consistently. And we have a complete error proof mechanism for repeating these processes.

And all of this, you know, leads to decreased costs and increased productivity.

So, with that, I ended a couple minutes early here, but, you know, with, with a couple of minutes left, but, you know, just say, if we have any questions, I'd be happy to take them now.

Very, very good. Very, very good.

Terrific, Eric, and Eric, we have lots of questions, so get ready for this.

There was a lot of, a lot of, lot of participants asking questions. So I'm going to ask you to turn off your presentation now, Eric, so that we can see you in the screen. Great. And so, first of all, thank you for the presentation. If you're a true leader and practitioner of RPA, you understand the theory and the practice of implementing RPA and that's. and that's outstanding to have someone of your caliber presenting to us today. So, there are a lot of practical questions here on the, on how to make this work and, and scenarios, So, I'm gonna go through as many as we can from the audience here, as many questions as possible, so, Rashad asked, What approach should be adopted? When implemented RPA? In the process, having various scenarios scenarios, in order to reduce the number of exceptions.

So, what should be the, the, the approach for implementing RPA in a process that has a lot of, to reduce, that, has very scenarios?

And you want to reduce the number of exceptions. Yeah, that's a fantastic question. Actually, what I would have to start off with saying that I'm a big believer that, when you're looking at automation, that Agile is, is your best friend here, Right? So, so make things modular, make it small, make make incremental changes and improvements to the process.

So, when you're looking at, you know, especially things that have a lot of different individual tasks that you're trying to stitch together, or where a specific tasks may have multiple outcomes, or exceptions to them, is, you know, is create the individual, know, we call it an object, but the individual automation objects as modular as possible to handle each one of those. And I'll have to agree that, you know, handling exceptions is probably the most time consuming aspect to that. We were working with one of our customers with with Cap Gemini, about six months or so ago. And when you know their approach for, you know, consulting with the customers, about a third of the time, is actually sitting down with the customer.

White boarding: what the process is: doing the various recordings, stitching it together, doing a basic test in two thirds of the time, is handling all the exceptions and making sure that every error condition, exception condition, result is handled correctly. That it's been hard, and that it is secure, and I think, you know, security, and you should really go hand in, hand with, with exceptions, make sure that not only handling all of the air conditions. That might happen through the actual process, itself, but, you're also handling the data that you're moving through, the process as securely as possible. For instance, if somebody has to start the process off by providing their credentials, making sure that every step along the way, that you're storing those credentials in a very secure, safe way, or that, you're leveraging correctly. A tool like CyberArk or some other?

No credential management system.

So, you know, to kind of go back to the point is just making around, exceptions, as is make, it is modular as possible. You know, for each exception, create, you know, in our particular product, we have the ability to create a library of, of, of, of sub flows, you know, just like in any other coding language.

You can, you know, create a library for handling a certain kind of error condition or a premature log out, or database connection, and then, you know, having no conditional statements throughout the process. Are looking for, you know, Did I get an error? Is it successful? Did I receive the response that I wanted to?

So for instance, if I have to create a new user in HR system, did the user get created, and if so, I would expect a result set user account. created in. If I didn't, I should get a different error code, and making sure I capture those. And make sure that I'm making a decision in the workflow based off of that.

So you know, another way to put that is, when you are doing this as a person, you're going to make certain, you know, decision making criteria.

With RPA, the, you know, the decisions you make along the way aren't any different.

But you do have to make sure that you are considering them, and that they are part of the, the, you know, the entire end to end process.

one of the things I usually stress around RPA and I failed to mention at this time, is, is RPA. And, in particular, Enterprise RPA really needs to be that entire end to end business process.

and why you can start with a crawl, and moved to a run over time, You know, the better you can get to an end to end business process, encompass all of the integrations, the tools, exceptions, the conditions as possible. The more valuable that process will end up being, and the more modular, and the more, you know, repeatable and consumable. It can be to build other, other processes in your, In your Eric, I'm glad you mentioned that, because it's a perfect bridge to a question. That the rather the had about scaling best practices to scaling RPA across your organization. And bass car also asked about a related question on bill, on BPM, or business process management, and transition from business, process management.

To the RPA applications, we understand that every every customer that you work with, every every company, likes to think of themselves as unique. And they do things in a very unique way, and that we may have an approach that, that sound. But every organization, we never implement the solution as the best practice, right? We always have to adapt to what a customer thinks is the best practice for them. Which in some cases, it's true of most of the cases is not necessarily true. But the culture eats strategy for breakfast.

So, we have to adapt to the realities of the customer, and that, if you're going to, if you had a customer there was open to the best possible approach for RPA implementation, what would that look like from a, what they would start with. Business process management and to end process understanding, and then a mapping of that, those end to end processes into RPA, describe to us, what would the ideal, the best case scenario for implementation of RPA and then the scalability of RPA in an organization would look like?

Yeah, You've asked actually a lot of questions. So, I'll try and and dissect that just a little bit. So, so a couple of things is, you know, start with the scalability question. So, so when we look at scalability, It's, it's tooth two factors: one is, is the is the infrastructure of the tool, the technology you're implementing. Is it scalable?

Can it handle, you know, five concurrent workflows? Well, chances are anybody can do that, can handle 500 or 5000. Well, now you start kind of you know reducing the number of tools that have the ability to do that. So you want to have a toolset that gives you the ability to you know at the front end to be scalable. Right. And I can take my orchestration engine and scale across multiple servers. So as I grow as my technology needs change, I can add more capacity to add another node into the cluster, and I get more capacity, right? Almost, almost immediately. Right, I'll load balanced across multiple nodes. And same thing on the robot side, if I need to spin up another robot server for the purpose of doing another concurrent type of task, That's different than the first one, say, for instance, my process requires me to know. It's an HR process that requires me to go to my Siebel application, and my Oracle e-business financial application, my Active Directory.

And, you know, my sap, and I want it, you know, those are all, you know, for different clients that I'm going to be using to interface with.

With, with my systems, I can do them serially, and do one at a time in that process may take 20 minutes waiting for each tool to do its job, go to the next one. Or, I can do that parallel. Well, to be able to do a parallel there, because they're all using different technologies, you can't run them parallel all in the same instance using the same robot. Do you want us to be able to spend those off and have them executed simultaneously across multiple different no robot servers? So, they have the ability to scale out that robot arm you, as I call them, or, you know, on demand is really critical so That's the infrastructure side of things.

On the process side of things, you know, the ability to get scalable is really around, you know, you know, not confining yourself, too.

No processes that are there because of what the technology dictates. And you hit the nail on the head. Because I've heard this with every single customer I've worked with is where a snowflake. We're unique. We do things differently. This is the hardest environment you've ever worked with, and, you know, we have problems that nobody ever has.

The reality is that, well, no two customers are the same. They all have the same kinds of challenges, and I think that's, you know, that's a very, you know, resilient statement to make across the industry, Everybody kind of has the same problems just differently. In a lot of it.

is, know, they've looked at technology solutions in the past and they're trying to figure out how do I force fit my business tasks into a technology solution?

And what ends up happening, the analogy I love to use, is it really is a square peg in a round hole was a big enough sledge hammer, You can make that go into that hole. The problem with that is all the splinters that come off is the business value that you lose as part of doing that. So we, while we don't encourage you to change your process, the tool itself shouldn't be rigid and flexible to prevent you from kind of letting the tool no more around your peg, if you will. And I think that's very key.

And that's one of the benefits of orchestration in general, is it doesn't come with a bunch of pre-conceived notions of, this is the best practice that we recommend and everybody's going to implement the same way.

We give you some Accelerator pack, some Starter Kit, some best practices.

But then it really at the end of the day is up to you to take those and, you know, translate that into your own business process, and then make sure that you're doing it your way, for how you need to do it.

Know, if you are using a mainframe terminal based after the application, you want to go, you know, add an user to it.

There's probably a right way and a wrong way, But there's probably three right ways. And your people are used to doing it the same, right way in, in, in your company, at different companies, adopted a different process. And was one of the things with Tollbooths analogy. I'm going to ... dresses, were not about re-inventing or forcing you to change your process to meet and go into an RPA tool. It really is.

How do I have a tool that's, that's flexible enough to automate what I'm trying to do and then will grow with you as you need changes as you mature in what you're trying to automate as you're trying to do more, more sophisticated advanced things. So, again, I would say a combination of a couple of things. one is, is leverage Agile, leverage kind of a crawl, walk run? You know, don't wait for it to be perfect before you start putting into place. Think small, and think modular, and start building things together. And then when you start looking at BPM, VPN is really, kind of the next extension.

If you think about, you know, Crawl Walk, Run, BPM certs is really the transition of that walk out into run, where you start wanting to spend together multiple RPA processes over a long period of time to do a business, A true business process. Think about ordering a server, right.

Ordering a server is not just about calling del up and saying, hey, I need a Box, get here tomorrow, It's around, well, is it approved, You know the order fulfillment process going through the right catalogs. And each one of these individual tasks has something you can automate with, either orchestration, the script, RPA, et cetera. But, how do I know, you know, kind of, bring these all together into kind of a master workflow. That is your business. That you can track the success. and completion of each one of these steps. So, you know, that ordered a server and provision. That business process could take 6 to 8 weeks, you're not gonna let an RPA process go 6 to 8 weeks.

You know, it's going to be, you know, tens, if not, you know, 20 or even 100 different discrete tasks underneath it, from our, no product perspective, That's the way that we're, you know, growing our space as well As, you know, we have our own Business Process Management module that sits on top of our RPA, you know, fully integrated between the two. So that you can have, as you grow beyond just, you know, task, and process, Now, you've got the business side, where you can do multiple RPA robots together and string them all together in a longer running process. Hopefully, that answers the question.

It does, it does that. So that you cover a lot of bases, because, as you mentioned, there were a lot of questions in my question, but that's fantastic, because that's the, you had the strategic component and the very practical component, which we really appreciate, Eric. Our time is up, and we have a number of wonderful questions from the audience. So, what I'd like to do is to ask you, what is the best way for the audience to reach directly? Is that is, there isn't a place where they can go to LinkedIn and look at what you do? Or is there a channel that they can use to learn more from someone like you and the and what you're doing in the industry? Yeah, no problem. So, first of all, we got our own webpage. We've got ... dot com slash RPA, and it's more of a product centric page. You know, the LinkedIn and it's actually something I'm still working on, is to actually build out my profile to be a little bit more on the RPA side. But, if anybody has any questions, I welcome, you know, sending SMS, send me an e-mail.

You know, it's Eric dot fisher at micro focused dot com, EIC. Got fi S HDR at micro focus dot com and be more than happy to funnel your question in the right place. The right direction. Get the right people involved. If it's not me, and, and as, we kind of build out our community, And we do have a community website at, you know, on, our, on our website, but we're still building that out as well with, with more more information for our customers, but in the short-term, certainly, send me an e-mail, and I'd be more than happy to answer any questions that were leftover.

Eric Fisher, thank you so much for being with us today. We really appreciate all the insights you provided in an RPA. Thank you, thank you. Thank you.

Ladies and gentlemen, this ends this session. I'm going to finish this portion of the, of the, of the conference, and when I do that, there'll be a short survey that will pop up. If you can give us some feedback, we appreciate that. And then we'll restart five minutes before the top of the hour, with, with another exciting session on RPA and intelligent automation. So, Susan, thank you.