#6 Q&A Session on AI, Low-Code, Intelligent Automation and RPA

Welcome back to another episode of the Process and Automation Podcast with the Automation Guys. We have recently asked our podcast audience and Clubhouse members what questions they have for us on the topic of process, AI, RPA, and intelligent automation. And thanks a lot to all of you for sending them in. Arno and I have picked 5 of your questions and we will go through them now and find answers to them. So let's get started. So the first question we have here comes from our podcast listeners. So why should I even care about Robotic Process Automation? Arnold, do you want to, do you want to take this one?

Yeah, I'll grab this one, Sascha. Thank you. And thanks for all of our listeners joining today. So why should you care about robotic process automation or RPA? I think that is a very good question. And, you know, and I spend a lot of time speaking to, to managers and business owners about this topic. And my conclusion is that, you know, every business should care about robotic process automation because, well, first of all, you know, it is the fastest growing software technology out there. If you look at, for instance, UiPath, which is one of the world's leading RPA vendors, their market value is around $10 billion. If you look at them 5 years ago, you know, it's in the millions. So it's a rapidly expanding part of the automation business. And I guess secondly, you know, it increases a company's efficiency and also productivity dramatically because, you know, it directly affects the bottom line of a business when you start automating processes. You know, we always look at automation and, you know, one of the things that we look at is the ability for automation to put scalability in your business. And what that means is that when you install RPA, or robotic process automation, or software bots in your business, you can scale your business without actually going out to hire more people. And that obviously affects your bottom line, because if you scale your business outwards and you don't have to increase the size of your HR team, your finance team, that's got a direct link to the bottom line of your business. So the question is, if we look at RPA and how to implement it, how do we do it? And I think if you look at people, working inside a business, we believe that everybody should do only meaningful work, and we can take all of the repetitive mundane work away from staff and pass that to a digital workforce. And also, you know, we, we call these software bots or, or robots to allow the human counterparts to actually focus on meaningful work. Like normal workers, digital workers is like a new team member, and you can train them to do tasks and activities in different software applications. They can do these as part of a process. So really, you have to look at this sort of workforce and train this workforce. And, you know, by training I mean, you know, you use a sort of a software to configure your robotic sequences. And example might be, you know, to copy data from one spreadsheet to another spreadsheet. And that just eliminates the, you know, the need for a sort of a human sort of colleague to do that. And that human colleague can actually concentrate then on doing more impactful work and meaningful work that's more valuable. Like, you know, for instance, talking to customers or doing important work, which is really more complicated than some of the mundane work, you know, that we could pass to a robot. So, you know, we always say, you take the robot out of the human, you know, by deploying RPA. And I think that that's really true. So what we want to do is we want to free up workers from this type of robotic work. And it's very important because, you know, it delivers immediate benefits to your organization. And in my opinion, you know, it's definitely worth to understand that this whole RPA concept a lot better.

So yeah, that's very good. Yeah, definitely one, one really good question. Thank you very much for that one. So the next one I received is from Clubhouse. We had a recent session and there was a really good question because we talk about low-code a lot, low-code RPA, low-code enterprise applications. So what is the difference between between low-code and no-code. So yeah, I can take this one. So yeah, low-code is a very attractive visual approach to software development. So very attractive actually to the business itself, because Forrester did recently did a study and found out that low-code development is up to 20 times faster than the traditional software development. When I speak about traditional by traditional software development, I mean sort of really the old one, what everyone thinks about when you talk about software development, writing lines of code and sitting in the basement eating pizza all day and thousands lines of code on screens. So this is what we call traditional software development. And yeah, traditionally we also think this is a very time-consuming activity and with our IT departments, yeah. They generally struggle to deliver software for our business needs in an adequate timeframe. So if Forrester says 20 times faster, low-code is 20 times faster, it is definitely very attractive for businesses, especially. Yeah, they're not even developers. If you would like to do traditional software development, they're not even developers available because of our skill shortages. COVID, Brexit, IR35 might be all the reasons for that, but this is another topic. So yeah, so low-code really enables that rapid development and deployment of business applications. No need for really that writing that, that lines of code. And yeah, you basically draw it like, like a flowchart. So this is how you could imagine the low-code. So you draw how the process works, you drag and draw drop how your user interface should look like. So this is the main concept of low-code. But at the same time, we're not talking about no-code here. So it sounded like no-code maybe if we just draw and drag and drop. But low-code gives us as well the flexibility to extend what we need to do with code if we need to. So there's lots of movement in that field at the moment. Yeah. Yeah, I know.

Yeah, yeah, no, I totally agree. I think for me that it fundamentally just boils down to how quickly can you put something meaningful in front of a business user to solve their problem and make a, you know, an immediate impact on their sort of day-to-day working life from ideation of a particular solution to a problem to actually putting something in front of somebody that's gonna save them that 3 hours a day. And I think that that's the great sort of benefit of low-code because you could look at a lot of problems with inside a business and quickly formulate, you know, solutions and using these sort of accelerators, these Lego blocks to assemble a solution, right? To be able to quickly and rapidly provide that solution to somebody, you know, to solve that problem, that real-life problem.

Yeah. And on the other side, the no-code, yeah, it's slightly different. It really gives some really non-coders, non-technical people, you just need some, maybe some logical capabilities in general. Yeah, the ability to to put all these business applications together fast, but you are more confined in what you can do. So there's a more structured approach how you can do user interface, how you can do certain steps in the process, because yeah, you're not writing code, so you have to take the modules as they are, as they come, like the Lego bricks you mentioned. You only have them, you only can use what is available in Lego, so you can build lots of things with it, but you can't suddenly do something completely different with that Lego brick. So it's a bit like, I would say, like building a website these days. So I recently looked at website building again and yeah, you just drag and drop and you take it as it is, but you, you, yeah, you come to business results very quickly. So there's a need for both, I guess, and could be a good starting point for lots of business to look just no-code, no-code, and then later on maybe evolve into low-code if there's more capability in the business. Yeah, on the other side, yeah, the vendors are working actually very hard on producing more and more of these Lego bricks for us. So further down the line, even with no-code, we get further and further and further so that every, every, really every business, small business, enterprise can, and department can develop. Apps really, really fast.

So I've got a question for you, and this might be the 6th question. I know we've all— we've only want to cover 5. Okay, this is the end of traditional development, and where do you see— because I think people listening to this podcast might be thinking, well, this is too good to be true.

Yes.

Is this— is this the end of, you know, JavaScript and CSS and C#, C++? I mean, what's your view?

I think to a certain extent, yes, because as I mentioned, I mentioned this, this was the website. It was absolutely fundamentally important to, to, to deal with CSS, HTML, and all that kind of stuff. And nowadays you can really just focus on, on your business outcome, on the, on the outcome of that website building. So you can, it's still there. It is hidden from you. You can interact with it, but the need for it gets Yeah, it's less important. So if someone has built their career on being a stylesheet guru, yes, there might be a requirement. If we are not getting to the point we want to get with the no-code capabilities or low-code capabilities, then we have to bring these experts in, and then they will be quite, quite expensive and they're very specialized. But generally, some of the skills we currently have, they will sort of become a commodity and So they will be abstracted even when we look at the AI kind of stuff. Now we have low-code AI, low-code, no-code AI, that kind of stuff we can use straight away out of the box. So some of that skill set is indeed not required anymore going forward.

I think if I sort of may answer my own question as well, in my opinion, I think it's just the shift of balance between where you should spend your time and what type of tools you use to solve problems. So in my mind, it seems silly to crack open, you know, Objective-C++ to solve a problem, a business problem that you want to take to market very quickly. So you need a tool that you could rapidly deploy a solution without actually going into that code interface because it's, it's simply not the right fit for the profile of the picture or the profile of the problem that you want to solve. Yeah, exactly. And, you know, that being said, sometimes it is necessary to go into lower level, you know, coding and perhaps create that interface, the API interface to do something quite specific. But it's almost that shift in percentages where I'm seeing that more and more as low-code becomes mainstream, rather people reaching to these traditional coding techniques, you know, sort of 60% or 70% of business application development that we certainly get involved with is low-code. The remaining is still traditional development, but it's the right amount. You know, just to solve specific problems, that's perhaps outside the reach of low-code, and that is something that you need to break into, you know, conventional coding, right?

Yeah, and it takes a lot of convincing, I guess, on the, on the more traditional side. So we, we indeed compete with, with traditional developers when it comes to projects. So if we, if we suggest a low-code approach, yeah, we, we really have to convince the IT director to, to make that shift. And that, yeah, they, they, when you bring that kind of stuff in, you have to really balance on the people side as well, because yeah, they will get really unhappy if you do the drag-and-drop programming suddenly and they are not really required anymore. But I think that's how it is really, things are moving forward.

So what's this deal with this concept of a citizen developer then?

Yeah, so that basically means, yeah, we give the power to sort of everyone in the business, or pretty much everyone who wants to build an app, to build an app. And this is quite exciting. So whatever problem they see, whatever the idea they have to improve their business in their department, they then have the power to do it. But With that power comes also, I think, the sort of the downside. So if there's not enough communication within the organization that you suddenly have this low-code power and you're building all these applications, if there's no communication to the IT department, at some point that might produce issues because with these low-code tools you build fast, you might build as well quite crucial, quite important applications no one knows about. Out.

Yeah, yeah, like strategic things. I guess there is a degree of, of sort of governance that needs to be thought about when you roll these types of applications out.

Indeed, yeah. So that's absolutely key, key there for, for large-scale things. If it's just a pilot implementation and they really want to try something out, not so important, but as soon as it becomes, as you say, strategic, absolutely key. Otherwise, the low-code journey is over sooner than you think.

Well, I highly doubt that. I think low-code is here to stay. I think it's becoming more popular. I think even hardened developers that we encounter on a day-to-day basis is starting to realize.

With growing pressure on organizations to to operate at digital speed, low-code development has emerged as an opportunity to more quickly transform. How do you know if it's right for you? So if you're forced to accelerate operations, improve the customer experience due to continually evolving expectations, visit our website theautomationguys.net and download our low-code guide and learn all about the secret of low-code success.

That low-code is actually quite a powerful tool in their armament. And, you know, there's still scope for traditional development, but I think in, in, in a world, in the world we live in, it is, you know, based on connectivity, connecting systems up. And I, I do, I do still think that there is a a need for sort of traditional conventional development to create these interfaces to join systems up. But if you look from a process and a user interface perspective, there is absolutely no need to start carving or creating your interfaces using conventional coding, right? Because it's so easy to use drag and drop and create really rich experiences link stuff up, connecting to those existing APIs, injecting your workflow processes, linking that all up, and really doing that at pace, right?

Yeah, you mentioned meaningful work. So why should a developer be outside of that? So at some point it can't be that meaningful anymore for, for that developer to, to do stuff which can be done with drag and drop. So I think even on that level, they at some point will start to appreciate what is available.

Yes, that's right. So that sort of leads us to question number 3, and I believe this was also asked inside Clubhouse. And this is, I think, a demystification again between, you know, what are the differences between generic automation, RPA, and hyperautomation? And, you know, I think these are new terms and buzzwords that's popping up everywhere on the analyst reports, the Forrester, the Gartner reports, and it's really valid questions. So I think it's probably worth looking at each of these terms separately. So, you know, if we start with automation and look at the term automation on its own, I personally would say it's, generally speaking, performing tasks that were previously required by humans that's done without human intervention. So repetitive type things where we can do something, there's no human intervention involved. And that's basically what we see as automation. And I think if we look back at the Industrial Revolution in the 18th and the 19th century, you know, we transfer more and more of these tasks, you know, from, from people to machines. And it's no different in the automation world we're living today. But, you know, obviously it's not an industrial scene. It's more in a kind of a business settings. So, so in a nutshell, I think that's a good analogy. So now that we've looked at, you know, what automation is, let's look at the next one in the question. You know, what is robotic process automation, or in short, RPA? So in my view, RPA focus really on the, on a set of standardized rules-based and repetitive processes that typically, you know, have a high volume of work, you know. So it means that human activities are taken over by, you know, so-called software robots or bots. And these bots can be basically used 24 hours a day, 7 days a week, within your business. So RPA is really just a means to train a software bot to do these repetitive things. And then finally, the last question with inside, you know, this whole looking at the difference between automation, RPA, and hyperautomation is really, you know, what is hyperautomation? And I think Hyperautomation goes a bit further where it combines machine learning, you know, with intelligent business process automation suites or your traditional IBPMS, RPA, and process mining, and also, you know, other progressive automation tools. You know, bringing more intelligence into this whole mix means that robotic process automation can now, you know, fully automate very complicated business processes. So we could achieve close to full end-to-end automation capabilities. So Hyperautomation is particularly successful when all of your production service and business processes are viewed holistically and coordinated with each other. And that's a very huge potential for your business when you do the implementations correctly. And you should never forget that you also need to manage the change inside your organization. As when you install all of these automations with inside your business, there is ultimately going to be an impact to how humans work going forward and what sort of work we will do with inside a business surroundings or business setting.

Yeah, indeed. So it can be quite scary. So if you talk about robots, people have very quickly this Terminator or these other things in their mind and they think, oh damn, what is coming next? So effectively, you would destroy an impactful project if you don't invite all the people beforehand. Yes, indeed. So, so the next question we received: can RPA in conjunction with AI be the solution for previously inefficient processes? I think that's, that's a good question. So looking at inefficient processing, can RPA with AI help? I think it's more sort of a generic general question and an answer. So you could say yes, no, because it really depends on lots of things. So the first question here should be really where do the inefficiencies really come from? So if we— so you probably heard about the phrase, if you take an inefficient process and you automate it, you have an automated inefficient process. So that's sort of the same kind of stuff we first have to uncover. So there could be lots of reasons why a process is inefficient, or maybe technology is not even the answer to it. I think that's very important to remember. Although we love to do implementations, very often the improvements can actually be outside of technology. So yeah, the reasons for an inefficient process could be actually quite diverse. So we have seen Generally, that responsibilities are not really clear within the process. So if you look at automation, at some point the responsibilities are sort of blurring a little bit because everything is done by processes. But in general, you could have lots of inefficiencies because of people are not working very well with each other on a normal level. Maybe some information is missing, and for let this process to run efficient as possible, documents are missing, data is missing, And yeah, generally, yeah, all these errors which can happen in the process. So yeah, so there could be this level of inefficiencies. So I would say, yeah, once you have tackled these, or you identified these inefficiencies, I think you should look at— so we would identify these inefficiencies as well with process mining. We covered that in a couple of podcasts and Clubhouse discussions earlier. So that could actually uncover a lot of these inefficiencies if you're not really sure where they are. So, but generally speaking, if you know the inefficiencies, RPA and AI not necessarily are sort of the magic pill, isn't it? So you still have to then go back to the drawing board and really understand that process. How do you really want the process to work? And Yeah, and then make, make these changes potentially with RPA and maybe bring in AI to identify a few, few things automatically, read contacts, read documents, read contact data out of emails, all that kind of stuff. So, so when you, when you're redesigning your process, maybe these technologies are the right thing. I would definitely address this, this kind of project was making small changes first to see if that RPA and AI can actually improve efficiency. And then if you see the results are actually as you expected or are better, then repeat that kind of cycle and scale from there. But so yeah, out of just like that, I wouldn't say RPA or AI is is the answer, but it can be the answer, and you have to test it in your environment.

So I think it's, it's more a case of evolution than revolution.

Yeah, absolutely.

And I think part of the evolutionary journey is really to, to try out these, these technologies. Um, first of all, understand what they're capable of. Um, try them out to, to to solve high-priority problems and then really evolve it iteratively to embed it more within your business and also bring more progressive technologies into the frame. There might be future progressive technologies that further provide better capabilities for automation that's yet to be sort of rolled into the kind of the mainstream usage. So I think there's never going to be a time where you can just, I guess, sit and design these things. I think you kind of need to get your hands dirty and try these things out and see what works. And, you know, I think as long as these technologies are meaningful, they provide business benefits, you know, continue to do it, continue to pursue that goal, right?

Absolutely. Yeah, I think this is the key thing. So I had a discussion recently as well. So what is the potential value we can get out of it? What is the value? What is the value? So this is the key thing. We sometimes, we are, yeah, obviously we breathe all that stuff day in, day out. It's in our DNA. We absolutely fascinated about it, but it doesn't mean everyone is, as long as it doesn't really bring that tangible value and benefit.

So the next question is, we received this via one of our podcast listeners, and they wanted to know, you know, when we talk about digitalization of business processes within companies, you know, what exactly is that about? It's a very interesting question. Digitalization of transformational processes within companies, in my view, has started in many businesses, but it's not yet completed because I think it's ever-evolving. It's something that doesn't have a particular endpoint. And, you know, my view, I think you can look at digitalization from two angles, you know, both from within side, the internal sort of mechanics of a business or internal view of a business, and also externally. So internally, you know, digitalization is where, you know, organizations are developing IT structures that expand their network, their interfaces, you know, they make data available, and, you know, they are reducing the cost of individual processes, you know, by accelerating or further automating them. And then also from an external view, these are the sort of the disruptors in the market competitors in fintech, healthcare, HR tech, property tech. And these people are looking for new channels to engage with customers and changing customer requirements by leveraging this sort of digitalization of processes, right?

All right, so that's, yeah, I think this is on the agenda for most businesses for the next coming years. It always, over the last years, always has been on the agenda and it will never go away, as you say. So it never has really an endpoint. And yeah, so yes, exactly.

And I think that's the external-facing part of it where, you know, it's, it is trying new things, trying new methods. And internally, you know, obviously providing those data interfaces that you can connect to, to overlay, you know, some of these progressive technologies to automate processes.

Great. Yeah, perfect. So I think this brings us to the end of our today's podcast. We, we have covered the questions from, from our podcast listeners and Clubhouse. So yeah, feel free to join us weekly on Clubhouse every Tuesday at 4, or submit your suggestions as you have done before. So it's fantastic to get so many questions coming in, and we are really keen on getting answers for you on all of them. So subscribe to our podcast, and thank you for listening. Unfortunately, that's it again. With this episode of the Process and Automation Podcast. If you like this episode, please give us a 5-star rating and don't forget to subscribe to this podcast so you don't miss any upcoming episode. We hope you will tune in next time, and until then, let's automate it.