View our schedule of industry leading free to attend virtual conferences. Each a premier gathering of industry thought leaders and experts sharing key solutions to current challenges.View Schedule of Events
Courtesy of Blueprint's Tony Higgins, below is a transcript of his speaking session on 'From Pilot to Enterprise-scale RPA: How to Amplify and Accelerate the Business Value of RPA to Build a Thriving Enterprise' to Build a Thriving Enterprise that took place at BTOES From Home.
As companies adopt an ‘automation first’ mindset and the demand for enterprise-wide automation continues to grow, business and technology leaders grapple with how to most effectively—and efficiently—plan and organize automation approaches and deployments and scale across the enterprise.
The good news for the enterprise is that wherever you are on your automation journey, there are footprints to follow to help leaders chart the best path from initial RPA pilot implementations to large scale, enterprise-wide deployments.
In this session, Blueprint CTO Tony Higgins will share how to rapidly and effectively scale RPA enterprise-wide to unleash the full value that process automation brings, create significant bottom-line impact, and design your business for long-term resiliency, including how to:
Thank you very much, as I appreciate it. And thank you all for joining today. Hope you find this presentation valuable for you. So what I'm going to do in the 30 minutes I have are 35 is briefly just introduce myself a little more. And the company I work for give you an overview of what we're what I'm going to run through today and then dive right into it. And really the basis for my presentation is a sort of stereotypical RPA evolution, what we have seen on the ground for real, and how companies tend to evolve and the patterns that we're seeing. And then, the realizations that they have along the way, lessons learned, if you will. And then transition into also, how we've seen people solve some of those challenges they bumped into, or some speed bumps. So if you will summarize, and then we'll do a Q and A as Jose headset. So once again, I hope this will be of value to you.
Let me just dismiss my little dashboard and we'll jump into it. So real quick, blueprint the company, so just allow me to briefly introduce the company I work for, so you better know who's speaking to you today.
Blueprint's been around for around a decade. We've always been focused on analyzing business needs or opportunities, defining solutions for them, and then driving them into implementation cycles. So we are a product company. We do this on a large scale for larger enterprises globally, and by that, I mean, very large initiatives with lots of inter-related parts, or, conversely, lots and lots of smaller initiatives with lots of cross dependencies that need to maintain alignment with some overall business strategy. And then, of course, everything in between our platforms used for process automation, optimization, transformation, work. And that includes RPA, but not limited to that, and that, of course, is the focus of today's session.
As for me, thank you, Jose, for the intro. Real quick, my early days, developing a variety of actually military systems for about 12, 15 years, and then I moved to large-scale, commercial IT systems development. After that, shifted into the product and services space. Primarily focused on tools and technology for, excuse me, for technology, development, and transformation, doing all this over 35 years in the tech space now. And currently, I'm the CTO of Blueprint so I head up our product team from vision right through to delivery and success into our customer base.
So the presentation today, again, is about what we've seen, what we're now seeing in the marketplace, primarily about our customers. I mean, they're the ones we spend most of our time with, obviously, and I can hopefully relate what they've gone through. These are just some of them, just to give you a sense by industry. And it's about what's worked and what hasn't worked. So it's not specific to any industry. Although the industries we mostly serve are like financial services, banking, insurance, pharmaceuticals, tend to be the more regulated industries so they have a lot more constraints they need to deal with. But as you can see, we also have customers in hospitality, transportation, manufacturing. So it's pretty horizontally applicable if you want to use that term.
Real quick, these are the results of a survey we conducted during an automation event last December with companies like the ones you just saw in attendance. From this survey, the majority of customers, if you log, I mean, they had bots that numbered less than 10, which a lot of folks on that event, I recall, was kind of eye opening.
So what I want to do right out of the gate is just ask you, folks, what, how many bots has your organization actually implemented and has in operation? To your knowledge, roughly speaking. So, Jose, are you able to open that poll?
The poll is live. So please go ahead and take your votes. Yeah, I can't see itself. So that's great. So, thank you. Yeah, this one, of course, shouldn't take too long, Just a single choice, Just another NaN or so. More people respond.
Terrific! We have almost everybody. Alright, why don't We want their faults right now? OK, I'll let you close it off when you fail.
We'll close. We'll give you another NaN. Take your vote, and we'll close the poll.
Tony, are you able to see the poll results? I cannot. So, maybe you can just really, Alright, I'll relay them to Tony. So, we had 54% of the respondents there were no said that there were none implemented. Wow. And then we had 20%. That said we had 1 to 5 bots, 4%. 6 to 10, 13%. And 11 to 50, And the 11% had over 50, So more than half had none and then 20%, 4%, 13, and 11%.
Yeah, So, I mean, you know, obviously, not exact for the last poll we've taken, but kinda been in line, basically giving you a sense of, you know, how mature is this space at the moment? And, you know, a sense of the challenges that people are facing, trying to actually implement and advance this. And this is very much in keeping, again, with what we've seen. So, once again, hopefully the presentation I go through today will be relatable to a lot of folks.
So the pulls down, Jose.
Yes, it is. We can see your screen and presentation. Wonderful, thanks, OK. So after working with many of these companies, and can whose whose names you saw earlier, we have distinct patterns when it comes to their adoption and evolution over time of RPA. And, of course, we hope we can learn from their experiences.
So the way we very typically see things is, right at the beginning, Somebody, somewhere in the organization was the catalyst, and may have started themselves. Or with a small group to explore process automation. And we've seen it almost equally on the business side, or the IT side, to be honest. And for many, they started a few years ago, and inevitably, back then, I mean, it was probably Blue Prism, because they were one of the only players in town. But of course, today, there's a much, there's a much broader set of vendors to choose from. These individuals would jump in tremendous optimism and excitement. Of course, it's something new. And they knew themselves or through discussion discovers processes that looked like they'd be very amenable to be automated. They felt they knew it well with a few conversations, and then their focus very quickly. We turn to, you know, the technology for implementation, because they hadn't done it before.
So, after learning the technology, what we've witnessed and many times for conversation, the first thing that hits them as in spite of all the glowing articles and marketing literature, you actually do need a degree of technical skill, to make a meaningful automation. There's an investment you need to make. So the promise of just anybody randomly sitting at a keyboard and doing this isn't exactly correct. And after getting through those initial learning hurdles for the technology. Now, let's say they've made an automation that actually functions, does what they hoped it would do. Again, sense of excitement and joy and pride, and what they've built. And they can, of course, imagine the possibilities. Gosh, what if we had hundreds or thousands of these automated giant swaths of the company's operations. Then came a range of reality checks. Este went down the road of showing it back to the stakeholders.
And this is when the exception start to come out in the surface once once people start to see things they can think of, all the different exceptions. So things that happen only in certain situations, that they missed one automating because everybody thinks happy path first. There's first one, then. Another one comes in after making these changes again.
We assume we have it haven't nailed up, but then they discovered some users performing the same task, but doing it a little differently in alternative ways.
So, of course, this requires some exploration as to Why are they? Why are different people doing it differently, the same work?
Is one right, and the other wrong is one better, or they just different, then need to look at it and say, you know, Conversations at a higher level, why are we even doing this process? Is there, Is there a better way entirely, should we be in a realm of thinking transformation, and then there was the discovery that the process was making some decisions to comply with, presumably, with some business rules or policies. So, the variations happening with different people doing it differently. It really warranted double checking. If we're gonna automate this, we better make sure we understand what those rules or policies are, because we're going to be actually embedding them into code, essentially, into a bot. So, go, so that root causes them to go back to the actual rules or policies, to see what they really said, to make sure that we're compliant.
And, at some point, all of this became enough work, and enough detail that they had to capture it in just about every single case, They made a document.
And the label, more often than not was PDD sometimes BRD. We've seen or BDD, different names, but, but, in essence, it's the same. It's basically, we need a vehicle, or a package to capture all of this information, so it's not lost. So, in summary, this first level of reality, check It all turned out to be a little more work than we anticipated when we first got into this. And even after all, those conversations, they had a sinking feeling. They didn't get everything. So then came the conversations. Those were the stakeholders or business, folks. Like, Now, we have a conversation with some of the more technical folks. Because this is going to get deployed. It's going to be operating.
And things got even more involved. So they, in many cases, we're trying to figure out how all this RPA stuff is going to fit into their world. At the same time, the first thing that surface with scrutiny about the data being accessed. That's the first thing everybody thinks about and being pushed into systems, as any of its sensitive, to what degree, power, where's it being stored or transferred? We need to authenticate. So, you know, credentials, how are they going to be handled? Where single sign on doesn't apply? How's it going to be triggered or schedule? A whole range of technical errors could, of course, happen. What are we going to do in each and every case?
So when they end, yet, another document was created to capture all of this information. This was often had a label of STD, or we saw people put this temp more technical information in the original, just had one document regardless. And then even more documents start to pop out ... more technical implementation information. And again, where there's no volume of information, we need to keep it somewhere. People turn to documents traditionally.
So armed with this information now and take a breath, we plow ahead to get a functioning process built now focused on working out the kinks, so, demonstration scheduled. Again, we bring in the broader audience businesspeople IT people to see, you know, introduce them to the new digital co-worker, if you will. Having learned a great deal with eyes wide, now, hopefully more wide, open, proudly demo the bot, but as the business people want to be sure all the possibilities are covered, Of course, they come with another list illicit nobody's ever seen before. And comments, like, well, you never told us that. And responses, like, well, sorry, we thought about afterwards. But regardless, this can't go out until we know this is handled. And that's just very classic.
So then, they think of a couple of cases weren't even on their list during the session. So long story short, very quickly. We realize we have need for a validation step that's more formal, yet another document. Then gradually, 1 by 1 more objections start to come out. Things like more on the operations side, because people are starting to think of that. What about business continuity, disaster recovery, reporting, logging, what about the responsibilities for running this, and an escalating things? And what's the change process? We know things are gonna change. In fact, we already know there's a regulatory change coming that's going to have an impact on this. All of this starts to add up, and we see even more documents.
So, let's fast-forward a year. Let's say we have a handful of bots developed in production, We have established roles. Things seem to be functioning, OK, and we've settled down and got a degree of stability.
But the realizations, in summary that we've had if we just boil it up, is that there's a lot more technical skill required than we first imagine, and by that, I mean, you know, course, we need to learn the tools, we wouldn't dream of doing this in retrospect without training, of course. And there's a range of proficiency levels. Those with more technical inclinations seem to ramp faster and could do more elaborate things with the automation. There's more documentation. I think we made that point then there, than we imagined there would be, there's more process and people involved than we than we initially thought.
And one of the bigger ones is maintenance and changes is way more burdensome than ever imagined what they're realizing, as they're now in the software business, right?
So, after establishing a foothold, that's almost what I'd call phase. one of what we see with these organizations as they then sail into even more headwinds. And some of these very stereotypical ones are the success of actually deploying digital workers or bots at the beginning, and being able to measure and demonstrate improvement.
Of course, that's going to catch the attention of senior levels. So like any new technology, RPA goes through a hype cycle, senior staff are certainly not immune to this. It sometimes feels like, you know, they feel, there's a default assumption, you can just hit a big repeat button and get similar gains and just keep hitting it to get scale.
So there's expectations and you could say unreal that and accompanying pressures of course that we need to scale this initial success and do it quickly.
So having learned the lessons mentioned previously, these people that are doing the automation imagining, what it would be like now, to try to scale all this with the processes. And all these things they've learned, it kinda makes it shiver. Of course you have to now explain and educate others why this isn't necessarily as easy as it looks.
We also have more people stepping up more people who feel they have a say. Or genuinely. Should have a say it's broadening out to more and broader processes. Means bringing in new people and stakeholders that weren't there initially from office functions, lines of business, where the process live. But you also have to automate more of the business with other stakeholders now, needing to have a, say, like, security, legal, marketing, compliance, risk, and the list goes on.
So those are a couple of things. Another one we learned is evolving roles and organizational need. So roles tend to evolve as these pressures grow. We've seen an equal measure where RPA started within the business, with a few innovative people wanting to try automation. And then it grew, and we've seen that be kind of pushed into IT. We've seen it start in IT and largely remain there. So we've seen several patterns, but the one we most see as islands of automation popping up, each learning on their own with different approaches, and sometimes even different tools.
And now on our customers what we're seeing is kind of an evolution of trend towards centralization, which I guess shouldn't be surprising due to a number of factors increasing need for security and compliance, of course, reconciling cost, but also the assumption that this is how you scale.
Another thing we're seeing is Agile pressure.
So automation initiatives tend to start out in a very waterfall project type, but now we're seeing pressure or desire to shift to more agile product approaches. Some see it as welcomed others, see it as an imposition. But, regardless, I'm going to speak a lot more on this shortly. Another thing that we see is, Discovery of more processes to automate becomes a challenge. I mean, in the early days, of course, We pick all the low hanging fruit. Those for which. It was painfully obvious automation could deliver benefit and they were well suited, but, but now, those are gone. So we need to hunt for processes which may not look like they'll return as great, and probably are more complicated and harder to automate.
So delivering on these expectations become harder, and when they're hardwired automated often translates into harder to maintain. So we're just snow plowing, you know challenges down, further down in the cycle as well. And lastly, like I said, the ever growing documents. I mean, these results and even more information that translates into more sections of documents for more documents on the whole, more information to be analyzed, recorded, considered when things change. So now what I'm going to do is transition to explain how we've seen companies help kind of address these issues and get around them, or get ahead of it. And with limited time, I'm just going to focus on these bottom four.
So, before we go into that, let me just take one more quick poll, and Jose may bring it up. It's basically, what are the biggest challenges that you have faced with ARPA E's introduction and evolution.
So the poll has been launched, please go ahead and take your, select the options that apply.
The first options' funding or budget for RPA, identifying RPA opportunities prioritizing RP opportunities, organizational, and rule changes to support RPA, and maintenance overhead, go ahead and start taking the pulse. We're collecting the responses right now.
And I believe, I say, this is a multiple choice, and, so you can pick like, the top three, if, if, if you like. Yes, it looks like you can. So, good, We have about 50% voted at this point. And I can give you another NaN here, and we'll close the poll.
Excellent, most of you have voted already. So, I will close the poll and launch.
Again, I can't see how, really, Tony. Maybe they're, just curious. The top, the very top one, the biggest challenge facing with RPI RPA, was organization and rule changes to support RPA. So, that org structure to support the RPA implementation. The second way, that was 43%, the second one was 41% on identifying RPA, opportunities the right ones to work on, and then the third one was the funding or budget for RPA.
Wow, fascinating, OK.
Yeah, and again, not not misaligned with what we're, what we're seeing out there, as well.
And, of course, this is not the only lestrade, there's others, but, OK, very aligned with what we're saying. So thank you all for that. So, real quick, let me go through these. So evolving roles and organization. Of course, this, just on itself, This was our number one, I mean, it could be a whole presentation under itself, obviously. But has mentioned the most common things we've witnessed as RPA, starting small area disbursing into what we'd call islands of automation, not tightly connected if at all with automation specialists, let's say, being parachuted into business units and then evolving, eventually do more of a consolidation Center of excellence notion. I'm not gonna say that's the best trajectory, I'm just saying. That's what we see most of the time.
So, where things need to start, in our opinion, as knowledge, of course. So there's that kind of the two ends of the spectrum are centralized or a federated approach to organization and governance. So Gardner has a great chart describing these. It's on the screen now to help determine which is the best for where you are in your life cycle. So, regulatory compliance, clearly, in a centralized model, that's going to allow you to apply more rigor to that and make it easier to do delivery at speed. And a federated model, people are more autonomous out on their own, closer to the action, if you will, and are able in general, to deliver faster. If you have a low appetite for risk, again, you'll want a centralized kind of control, outward, model, operational model.
Traditional Sarah shared services is, of course, beautifully suited to more of a centralized governance model, whereas fusion teams, multi-disciplinary people involved, tend to be, again, more autonomous automated units, delivery maturity. Just like application development is moving from project to product, It's considered product as a more mature approach, and that tends to be found more on the federated. And if we're just starting out, as I said, the trend we're seeing is more people pulling back and consolidating and centralizing, and that's, again stereotypical of just starting out. And then citizen developer as the skills grow, they can become more autonomous, injected into those fusion teams, and and be able to do it on their own. So, again, these are just ways to double click on those two spectrums Of course. There's everything in-between.
Again, you can have different combinations of these, But those are a couple of things to think about. In terms of roles, I think it's important to consider them in layers like strategic, tactical, operational, regardless of whether it's central or federated. So for example, at a strategic level, you want roles that focus on the overall vision for process improvement, or at least for RPA. But I'd suggest even more broadly, since RPA isn't the answer to everything, ultimately. So it absolutely needs to have a business focus. And a mindset. Titles vary dramatically, But these are some of the typical ones we see at the tactical level, the focus needs to be on driving the desired business outcomes to fulfill that strategy.
So here you're going to find roles like those listed here. Again, the titles vary, but couple here to note are the automation, architect and and the navigator. So, the architects, really a horizontal or matrix function, specially in the federated model, where they reconcile redundancies across the different groups and come up with common solutions to common problems. It's really what architecture is, standardization, re-use, and so on. Automation navigator, That's a role that Gartner is promoting and is supposed to be a specialist in finding or discovering the best opportunities for automation. I have to admit I've never seen anybody with this title or role, what I've typically seen it's a combination of process owners, SMEs, and VA's doing that work.
And then at the operational level I think it's pretty self explanatory the practitioners of build and operate the automations and ensure they function. So again, regardless of the organizational structure, centralized, federated, and titles are going to vary, but these are the kinds of roles that we have seen in place. And the one thing that we see most often in successful orgs is certainly, putting in place. these three levels to not do this means, again, the Upper levels missing. Mean, you're kinda rudderless and the bottom level, of course, is obvious. We're not gonna get many effective automations built. So.
The next thing I want to look at is applying agile principles quickly. So Agile has evolved as a way to improve the situation of delivering complex custom software. So I'm not going to cover all the Agile principles. There's actually 12 of them, but instead I want to focus on one in particular, and that's the ability to break work down into individually. Demonstrable or demonstrate a bowl pieces. If you can't do that, you can't do Agile, full stop.
So you define design, build one small piece of the time. You're able to demonstrate it. You do it in a rigid time box, fashion, like sprints, let's say. And in this way, within a predictable timeframe, you can see the results of your work as you go. So it enabled. By that, I mean, everybody can see the results, so it enables you to spot really early if things are heading in the wrong direction. And also, we'll let you accommodate changes more easily, because they can come in on any of the sprint cycles. So there's lots of goodness associated with it. Now in RPA, we've seen it be applied. This be applied a couple of ways in terms of splitting up work. one that I'd call scenario based, and the other, I'd call function based.
So with scenario based, you build the happy path. And that's basically a story.
Or if it's a lot more work, you can have it as a higher level entity, called an Epic, but it's, this is our first piece of work we're going to try to tackle. And then, each alternate path is done as separate work items.
OK, so this is let us show how it works and we can grow it, but we grow it by the different, full cycle paths. So that's one way we call scenario based. So another way we've seen it done is functional breakdown. So this allows multiple specialists to work together to create the scenarios, maybe like 1 or 2 people really good at the AI components. So they really focused on those functional aspects in our co-workers, or colleagues work on some of the other components. Just for example, So again, each has pluses minuses. Not necessarily know. There's no right answer. Depends on your situation. But there are options and alternatives like I showed now, in terms of technology or tooling to aid this process. This diagram you see here is actually a shot from our Product Blueprint. And some of the technology that can be applied is. we can take this diagram and automatically translated to user stories.
So, for example, if I take this portion of the process, this is a story. So, this is one of many stories generated for that process end to end, so that's one of the beauties of technology. We can all work together collaboratively. Imagine what the process should be, and then literally hit a button, and we can translate it into a work item backlog that RPA developers can execute on if we're using Agile principles.
And, by the way, these stories would then be transferred over to Jira or similar tools, to facilitate, know, that development cycle. The other one, discovering processes to automate, in terms of discovering processes to automate. You need a couple of things you need to know, or a few things, rather, You need to know what the processes are and whether they're suited to be automated. Not all are having metrics, because that's the only way we can baseline. So, at the end of the day, we can measure to know, have we had an improvement? And hopefully all the alternatives as well, like I mentioned earlier, so, there's technology existing that can help with this as well. one of our technology partners, there's other tools out there, but one of them is Fortress IQ. So, just to pick as an example, they're able to continuously record the work being done, unemployed desktop supply data analytics, to surface and expose how people are doing their work, In other words, the processes they're doing.
So there's really good things about this. I mean, it records work at a very detailed level, like mouse clicks and keystrokes. We get screenshots and every single action, so we can see precisely what it looked like. And because we're recording many workers, we see all those variations and alternatives for how people are doing the same piece of work just differently. So we get the variations, and lastly, we get the metrics. How long does it take to do the work, and how frequently is it done? So it tends to be way more comprehensive than you'd ever get going around manually, you know, doing spot interviews and things like that. It's also very unbiased because we're recording actual data. Like, actually, what happened?
These tools are obvious for use and RPA, since RPA is about having digital workers, take on the mundane tasks human are doing, But mining tools are another source of current state process information.
That's also valuable if you're looking to broaden automation, certainly beyond RPA as well.
So what mining tools do they record the event logs of the enterprise applications.
So while the data here's more coarse mining tools, they're able to capture activity that does not involve the human interface. So, in a sense, it doesn't really it. The mining tool doesn't really care. who's at the keyboard Or even if there is a keyboard.
In other words, it can capture activity originating from external facing customers who you've, you know, exposed a UI to, as well as internal workers. Or siss even system to system interactions can be logged that don't even manifest himself on the user interface anywhere. So it's complimentary. I would say to the task mining tools. So, the Discovery or task mining technologies, exposed detailed test. The mining tools expose broader processes in which those tasks take place, but even these together can't provide the complete picture while they do a good job at capturing what actually happened. They can't tell you what should have happened or why things happen. For example, there may be steps we do in a process purely to comply with regulatory obligations, but these tools can't tell you that there could be countless other reasons. Things are done, like standards, policies, rules, or even contractual agreements that we have with customers or vendors. So these Y's are very important.
If you don't comply with them, there could be material implications, but they need to be known as well and they together constitute the current state, how things are done today and why they're being done.
So this is one sorry, I'm going to transition now to dealing with document overload but it marries up with the last one. It's one example of the last problem I want to talk about, which is the doc overload. So ultimately, what we're trying to do was develop, you know, robots using any one of the platforms available. I just spoke about the different technologies to expose the current state, tass, mining, process, mining.
If we gather up all those relevant rules, policies, regulations, agreements, et cetera, then we'd have a pretty solid representation of current state from which to design the new process.
Now, as I showed earlier, what generally happens today and indeed, is promoted, by pretty much all the RPA vendors is to produce documents, PDD's, STDS, and there's lots of templates available for that.
But there is technology I'm going to show mine up there obviously, so NSS. In essence, what this is doing, is pulling people out of those document containers instead, meant digitize and manage that information in a platform.
So, the value here is each piece of information managed, independently version, discussed elaborated Some call it, digitizing the RPA documents, that can all literally be done for RPA development, but also beyond, and all the documents in it, like .... And certainly all the change requests as well. So, it's pulling it out of documents, putting it in a platform that can manage it. People can come in and even if they're desperate or, you know, distributed and collaborate in these online platforms, with inline discussions, review, sign offs, and so on. And if you actually need a document, they can be generated automatically.
So, looking at all the pieces I've introduced to solve these problems, it kinda looks like this. So this is the type of infrastructure. it exists today, in different technologies to focus on, the best opportunities for automation, clearly define them, taking into account all those constraints, like regulations, and controls, and rules, et cetera. And it actually is preventing many of the barriers that today is holding back organizations from scaling their RPA initiatives.
So, that's what I wanted to show you today. I just got a couple of seconds to summarize, how to organize. roles for scale was one of the fundamental questions. Somewhat of a role change, obviously, Since, hopefully, organizations are shifting to a more continuous improvement regimen. The co model tends to be the right approach as you move along those tracks. But I think eventually everybody is going to end up with a federated model.
Leveraging Agile, there's different ways you can slice and dice it, as I presented, but agile principles just makes sense in the long run, and it represents a more mature practice, very aligned with product delivery. And I think, again, everyone's gonna get there eventually reducing document overhead. I mean, there's technologies like ours that exist today. This is just an easy win, in my opinion.
And we're seeing, I'm seeing personally, our customers benefit from that breaking through the scaling barriers, because of it finding automation opportunities. Again, there's tremendous energy around the new technologies for process and task mining, it's evolving very rapidly. Analytics vendors are coming into the space, even BPM, vendors, even the RPA vendors. So there's a lot of pent up demand as our survey showed and a lot of fascinating technology that's really helping to solve that problem. And then all of this, in my opinion, really needs to position you for more broad automation, beyond RPA, because there is certainly life beyond DARPA with lots of other approaches as organizations get more mature.
So that's what I wanted to show you today. Be happy to pass it to Jose to facilitate questions.
So many terrific. Well, what a great presentation. Thank you very much for that. And, that you can go ahead, Tony, and you turn off the screen so that we can see you full on. There were lots of questions that came on during, during your presentation. And the and thank you everybody, thank you, the audience for that. And thank you ..., who also came in as a co organizer and provide a lot of great answers in real time.
But I'm gonna, I'm gonna start with a question, one of the questions, that touches on what you talked about last, which has to do, with the typical business processes, there, are considered for automation. You have such a great experience across so many different industries now, on what you see being automated most often. But the question is really about what framework or approach do you use when you go into an organization and you're trying to identify what will create the most value in the shortest time and simplest means through an RPA implementation. What is your thought process? How do you address that with a new client?
Yeah. I mean, the first thing, when trying to identify them everything, you have to get very clinical everything, boils down to the numbers, At the end of the day, you know, why are we doing this, right? It isn't a hobby, hopefully, it can be fun. But that's not the primary objective. Right? It's, we need to make material business improvement.
Right? So it all comes down to business value that tends to often be, you know, cost, revenue, risk, et cetera. But not always. There's more things, businesses value than just, you know, straight up our oil dependence. But anyway, you really, really need to anchor it in that. So, what is the business value that we're trying to drive and then go back?
And how are these processes contributing to that? And it might just be on the cost side of the equation, which everyone kind of runs to first, oh, my gosh, look at the cost, this could save, But again, it may not be that may open the doors to new opportunities as well, right?
Shortening supply chains and all sorts of different transformational objectives. But cost against tends to be the first one, that's the easiest one to communicate. But no matter what it is, you gotta have the metrics, you have to baseline it, which honestly, is why I'm so excited about those discovery technologies. We don't make herself discovery technology. But just looking at that and judging from the poll that to me, as you need objective data, right, about how is work being done now, only then with that stake in the ground, can I assess what the improvement is going to be? So that that's just candidates for, you know, big returns or significant returns or delivery of value? The other lens you have to put on it is how amenable is this to be automated?
Right? So for example, I don't know, Maybe my cost of sale is I'm a product company. Maybe cost of sales is really high. Boy, these enterprise sales reps really cost a lot cheat. What if I could replace them with a robot? That's probably one of the most human activities you're ever gonna apply, right, With building relationships. You can't, it's not going to happen. It's just not suited to be automated. So, there's that. There's those two lenses or perspectives, right? What is the, you know, what's the business value of doing this? How hard is it to do it? Put those together, and then the last lens, I'd put on it, because we're dealing with large enterprises.
That risk equation, this may be very risky. I may be dealing with lots of customer data. That might be huge Privacy issues, if there's a breach. Oh my gosh, I can't even imagine. I mean, we could literally has put companies out of business, right? So, what is the risk around this, or, heaven forbid, we're in an industry that that's talking about safety, critical systems, right? So there, there can be huge risks, as well. That's largely industry dependent, but, but, but we deal with those industries as well, so it's kinda those three lenses, Business value. Mean, how amenable is it to be automated? Do I have the technology today, or am I just going to waste a month only. To find, you know, maybe a year from now we could do it, and then the risk side. So, those are really the lenses that I put on.
one of the, one of the other questions that came on had to do with best practices related to collaborating with links, six Sigma teams. And if you think about continuous improvement teams and organizations, I'm not sure with you, if your engagements, what proportion of those organizations have a robust continuous improvement program already in place. Talk a little bit about, if, you know, if there is an interface between what you do with those continuous improvement teams, or if they tend to work on of the, the question hints, at, the, he has experienced the personal pose. The question on, on, on this being often disconnected, and then I wonder about your experience on working with .... Improvement teams that may already take place in the organizations you work with. Yeah. I mean, there's certainly, you know, everybody has the right attitude. The right objectives, they want to do the good thing. They want to have the, you know, the textbook continuous improvement Regiment in place and we all have the visions, right?
But, it's really how to get there, and I fall back on really basic principles, and I know, you know, call me biased, I work at a product company, a lot about technology. But, you know, I'm more about customer success, and that always involves those classic three pillars, right, of People, Process, and technology. And we're talking about an evolution and maturing an organization. You have to mature those three dimensions, and sometimes, you know, one of them gets ahead of the other than the other has to catch up. So I think in terms of process, and standard, and theory, and philosophy, I mean, we have six Sigma, We have others as well. I think that's, you know, very laudable and makes sense. And a lot of thought went into it and we have lots of Validation. That's great people. We, from the poll, we need to have an organizational structures at Central Federate, whatever that has to catch up.
Honestly, in this area: I do think the technology had been behind, I don't think availability of technology has been behind, but I think implementation of technology in a lot of large organizations, they just know. It tends to be the mass majority. They're a little slow to adopt, versus some of the very small, digital companies, If you want to call it. That. Which are now becoming very big digital companies, and they're doing that because they have speed because they have that technological foundation. So, I think that's the leg of the stool that does need to be brought up and, and it's kind of, I won't go back but it's kinda that last picture I painted today where we have Discovery. Finally, we have wonderful technology to really expose, and turn the light bulb on. So I can see what my people are doing. For work, I have a platform like ours, which can take that and all this complex information draw the relationships. So I can see, you, know, alignment with strategy to find a solution.
Then go to RPA, or, quite honestly, I alluded to it. Our platform drives more than RPA, There is more, but RPA is one that makes the new current state.
Then I apply these technologies, again, to measure it.
How did we do, There's, your, There's your loop. So, the technology exists today. You can automate a Continuous Improvement Regiment, then layer on six Sigma then have your roles hopefully evolving to federated. Now, I have a machine. So, we're seeing customers really, you know, accelerating toward what I just described. I have yet to find one that's, you know, a perfect example of it, But they're all moving very quickly. And looking forward to pretty soon. You know, we're going to have some great case studies.
Very good, there's, there's a question here from Jonathan Tony, that, he wants you to talk a little bit more about the cultural aspects of implementing RPA. That, People side of it, all. The way from, you know, maybe fear of, job loss, by, Implementation of RPA. To choose to just cultural adaptation, to new way of working in the way of thinking, A new way of using technology, really, just talk more broadly about your experience with the cultural challenges of implementing RPA. Why have you have you seen the field?
Yeah, I mean, any change is a challenge, right? Full stop. And if, if the more rapid change the more child, the more anxiety, the more, Oh my gosh, How are we going to do this? Because many change regiments or programs in the past where all well thought out Well planned. We're going to execute this over, you know here's our five year plan, I mean that doesn't exist, right? Technologies, cash coming in so fast! There's also a fascinating generational change as well. Again, we work with large enterprise, right? So we have people, you know, still been there for their career, right? You know, maybe have pensions, although I don't know many people with those anymore. But, and in that mix, you have those folks, and then you have people fresh out of school, right? And every minute of every day isn't some kind of technology, and they're so proficient with all of it, right?
So you're seeing this spectrum of proficiency level, and I think those who are more proficient with, they're not technologists, right? They're not necessarily engineers or programmers, but their users of technology and very proficient at it, right? They have far less anxiety. They're kind of saying, well, why? Where are the robots come on? Hurry up. But, so that dynamic is playing out as well.
But, you know, there's nothing I can say to stop the anxiety other than, you know, I'm obviously an older guy. I'm certainly not anxious about it. A lot of the folks I know aren't. No, but as we go through, at least we have the models that I've been talking about, and I think we also have what I call those digital companies to learn from. I mean, not very often do you have a model of a solution just sitting there and you can observe it. And it's, you know, Amazon, Google, Apple, go through all the digital companies. And then there's digital companies in every industry popping up and growing rapidly. I mean, there's a blueprint or a prototype for how to do it. Everything from organizational structure and roles and applying technology. Right. And that can be applied, right, Cross industry as well. So I think, you know, not knowing is probably the biggest worry.
But again, look at these companies and you can see the future of your financial services company, of your insurance company, and so on. Very good. Toni, unfortunately, our time is up. It's been a real pleasure to have you here and share your wisdom with us. Thank you so much for not only sharing that with us here, but really helping accelerate this industry for the benefit of all of us. So thank you so much for spending your time with us today. It's my pleasure. And thank you, all. Take care. Have a great day.
Thank you, ladies and gentlemen. We'll be ending the session soon. And the next session was started at the top of the hour. Please go back to any of your reminder e-mails received received directly from the customer care at GoToWebinar GoToWebinar dot com, and click the join webinar link. Again, to rejoin the next session, we look forward to seeing you. There will relaunch that session five minutes before the hour. And in that session, you do not want to miss the session. We're going to have the global head of the RPA and conversational AI from Nokia presenting to us on the proprietary AI algorithms for mobile networks.
And there'll be a fascinating presentation, and I hope to see all of you in a few minutes, When, when you, when we close the session, there is a, instead of closing the overall window for the webinar, if you close the session window, there will be a popup box. That, if you click on the close button, that blue button, and that popup box, there will be a very short survey. that comes up. That asks you for feedback on this specific session. So, if you could take a minute just to write a couple of things on them, we really appreciate your feedback. So, thank you. We'll see you again in a few minutes.
Chief Technology Officer,
Tony Higgins is the Chief Technology Officer at Blueprint Software Systems where he oversees product development efforts to bring Blueprint's technology vision to life, within a philosophy of continuous innovation.
With over 20 years’ experience leading digital teams, he has been instrumental in driving the vision and evolution of Blueprint’s Enterprise Automation Suite, a modern and intuitive tool for scaling process automation initiatives to enterprise scale.
Tony has a broad base of software delivery skills and experience ranging from start-ups to global enterprises. He is passionate about building technology that helps teams to rapidly optimize, automate and digitally transform their organizations.
Search for anything
November 9, 2021
11:00 AM - 12:00 PM ET
January 13, 2022
1:00 PM - 2:00 PM ET
January 27, 2022
1:00 PM - 2:00 PM ET
View our schedule of industry leading free to attend virtual conferences. Each a premier gathering of industry thought leaders and experts sharing key solutions to current challenges.View Schedule of Events
Watch On-Demand Recording - Access all sessions from progressive thought leaders free of charge from our industry leading virtual conferences.Watch On-Demand Recordings For Free
Courtesy of DC Government's Ernest Chrappah, below is a transcript of his speaking session on 'Going Digital To Enhance The Customer Experience' to ...
Courtesy of 's Anu Senan, below is a transcript of his speaking session on '' to Build a Thriving Enterprise that took place at Enterprise ...
Courtesy of Tasktop's Dr. Mik Kersten, below is a transcript of his speaking session on 'Project to Product: Driving Digital Transformation Insights ...
Courtesy of Nintex Pty's Paul Hsu, below is a transcript of his speaking session on 'Improve employee productivity during and post-COVID by ...
View our schedule of industry leading free to attend virtual conferences. Each a premier gathering of industry thought leaders and experts sharing key solutions to current challenges.View Schedule of Events