In State of Process Automation, Christoph Pacher talks to Samuel Farag, Solution Consultant at Frends, about the exciting topic of "lean automation".
The conversation sheds light on how to successfully implement a lean, low-maintenance automation strategy and the benefits this can bring to companies in various industries, including energy, retail and internal service providers.
Samuel Farag explains how Frend's iPaaS helps organizations to efficiently automate and integrate their processes and the role of a strategic approach. Learn more about the challenges and best practices in process automation and how Frends can help you achieve your automation goals.
Christoph Pacher: Hello and welcome to a new episode of The State of Process Automation. My name is Christoph Pacher and I'm delighted to have you with me again today.
My guest today is a Solution Engineer at Frends and today's topic is Lean Automation, how to successfully implement a lean, low-maintenance automation strategy. Hello and welcome, Samuel Farag.
Samuel Farag: Hello Christoph, I'm looking forward to the episode. Thank you very much for having me.
CP:Samuel, I'm pleased that you've taken a few minutes and I've now introduced you very briefly. You are a Solution Engineer at Frends, please tell us about yourself. What exactly do you do as a Solution Engineer at Frends and, of course, what is behind Frends?
SF: Let me start with what Frends is all about. It's an integration platform, in our case as a service. This means that you cover your entire integration needs on the platform, the entire life cycle of such an integration. In other words, we create the integration, we deploy it, we manage and monitor it from start to finish, right through to retirement, when there is perhaps a new integration or a new automation project. As part of this, I work with our customers to analyze their needs, define their requirements, demonstrate the solution, of course, and basically just act as a technical consultant in the automation or integration project that the customer wants to implement. Yes, to be at their side and support the customer.
CP: Super exciting and I'd say it's best to dive straight into today's topic, lean automation. Many people are probably thinking right now, okay, lean startup or something similar or lean in general. Would you like to tell us from your perspective, from your experience, what do you understand by lean automation?
SF: I have a very clear idea of lean automation, and that is the strategic application of automation technologies and processes, meaning that we make processes leaner, more efficient and more agile. I think that's well known and is nothing new, but that we also observe lean principles within these automation processes and remain true to them. That means things like creating a flow, making sure that the process is always value-adding and that we make it continuous and smooth.
CP: And I would also add that what you see in many companies, of course, is that they start with a tool such as robotic process automation, where many are also convinced, others less, others more, definitely has its raison d'être. But what I'm getting at is that these companies start with robotic process automation, for example, and they tend to think in the short term and see the quick successes, but don't even consider what actually happens when I have implemented 100 use cases, for example, and have automated all these use cases with robotic process automation. They forget that these 100 use cases are then also maintained, which means I don't have a lean approach because I'm actually creating a lot of work or a lot of maintenance work that I have to manage because I have automated processes and the more I automate, the greater the maintenance effort. So, in summary, a lean approach is to use the resources I have as efficiently as possible so that when I automate, I really get the greatest success in the end, right?
SF: Exactly. So one of the principles, as I actually heard you say in a previous episode, is that we want to automate processes that scale with the growth of the company. And a process like the one you've just mentioned, implemented with an RPA solution, scales very strongly with the company. The more it grows, the more such processes we would need in use. But the greater the overhead that these processes create. And if we say that companies didn't have a lean approach when they implemented this automation strategy, then that sounds like an accusation. But I think that automation projects usually start organically. You have a specific problem and think, okay, in the current as-is process that I have right now: How could I use a digital tool to help me with this? An RPA is of course very transferable because it helps us to manage the process in the same way as we currently do as humans, for example by the RPA going through the interface and creating the data there or completing the tasks. But we don't think about the process from the ground up, what is the input that I have, what do I want to achieve with this process and what should the output be, what should this output be used for? Because then we start to really perceive digital processes as such and rethink them. And then maybe I don't think about how I can get data from A to B with an RPA, but I think about, hey, these are both software programs that already have interfaces where the machines can communicate with each other technically. Why don't I use that and transform this semi-digital process into a completely digital process, which is then really just machine-to-machine communication, where no human has a hand in it anymore?
CP: I think we can actually imagine three scenarios, because there are companies that are still at the very beginning. In other words, they are just getting to grips with automation, have perhaps implemented the first use cases with robotic process automation, for example, and are seeing their first successes. This is the kind of company that is just starting out. Then, of course, there are companies that are already at an advanced stage. They have a send-off excellence. There are perhaps two or three employees in this Send-off Excellence. They have already automated some processes with various tools and are really driving the initiative forward. And then we have the third scenario. They are professionals.I recently spoke to Orhan, for example. Orhan Kotzsch is responsible for process automation at Bosch Mobility. But Orhan said that they have already implemented 1330 use cases. They also have a very colorful bouquet of various tools, but they really have them under control and can orchestrate them. I would classify them as professionals. Let's work through these three scenarios in detail, because there are of course different challenges everywhere and let's start with the beginners. What specific challenges do you see when it comes to automation?
SF: Yes, someone who is at the very beginning of automation and we don't even need to talk about an automation strategy yet. Because it's usually more about the concrete implementation of problems or challenges that you have right now, where you think to yourself, maybe I want to automate something here for various reasons, because I don't have the people or something similar, because the complexity is simply getting out of hand, whatever the case may be. In any case, you usually first think about what the case is. And then it often starts with, we need some kind of data. At the end of the day, a digital process is actually one that takes data from A to B, changes it or does something with data in any case. And one issue that usually comes up is data availability. They have different software, different systems in use, but don't know exactly how to access the data they need. Or the hurdle to accessing this data is too high because you may be using an old on-premise legacy system, because you don't have the internal know-how to communicate with different interfaces or similar. Or you have this case, you have two systems that you know well, but the systems speak a different language, be it a different interface or a different format, and you first have to be able to translate them. And that's where you start to think about, yes, how do I actually manage the case? And the actual functionality of the automation is often not the problem, it's more about all the other stuff. How can I actually create an environment in which I can automate?
CP: If we stay with the example of robotic process automation compared to integration, for example, I can of course also evaluate the use case, because you just said that there are short-term options with robotic process automation, because I can map the use case within a week, two weeks, three weeks, and on the other hand there is the option of integration, but this may take a little longer. How would you weigh that up or how do you generally see robotic process automation as a quick fix and, on the other hand, integration as a medium to long-term solution?
SF: Of course, my background makes me a bit biased and I'm a big fan of end-to-end integrations. Of course, RPA can't do that, but that doesn't mean that RPA isn't a legitimate tool that can help you tremendously with an automation strategy. But you have to consider the right context for each tool. And then you end up with the kind of best-of-breed strategy that is often talked about, where you use the best possible tool for each case you have in order to implement this case. It is often the case that you can get started incredibly quickly with RPA. The implementation speed here is of course enormous. Any user who can carry out the normal process can actually automate it with very little effort using RPA. It has to be said that the hurdle of writing an integration between the two systems is significantly higher. In terms of know-how alone, although we are now much more user-friendly here with no-code solutions, low-code solutions, than perhaps we used to be. But we also have the disadvantage that this quick fix is not so scalable. We then find ourselves in a situation where we realize, hey, that was cool, it brought us added value. We would like to do more with it. Then we get into the situation you mentioned at the beginning, where we create an overhead. Because all these processes that we create, we have to keep them up to date. We have to retain control over them. And at some point, the whole thing is no longer really sustainable. Then we basically have a shadow economy, instead of having overhead that deals with the processes that we manage. we now have overhead that deals with the processes that manage these processes. And whether I have three people who manage this task or three people who manage these processes, it doesn't really make any difference. Then I'm actually back to point 0.
CP: In other words, you observe that if you don't think in the medium and long term right from the start - let's stay with the company, which is still at the very beginning - you get rid of one problem and actually create the next problem with the solution.
SF: Exactly, we often see that and these are often the cases where people like me come in and then we are at the point of needs analysis or requirements definition, where you think about, okay, what is the environment like at the moment and how did you actually imagine it, what would the situation actually be like that we would like to have? And then you realize, hey, quick fixes are cool. They help you in a hurry. But if you really want to automate sustainably, then you also need a long-term strategy that focuses on sustainable values and sustainable opportunities.
CP: What do you perceive specifically? Because as you just described, when you work together with the companies and go into the analysis, you realize that there are two different worlds. One world is the way it is, the status quo, and the other is the way it should be from the companies' perspective. What do these two worlds look like in concrete terms and what does the gap between them look like?
SF: I think what you often see is that the complexity has been underestimated. That people have underestimated how their own IT landscape is set up. That it has been underestimated. How much do we want to automate? As mentioned, it usually starts with a small use case. You realize it's successful and want to do more and more. And then at some point you realize, hey, we're suddenly relying a lot on automation or digital processes here, but we don't really have the internal structure to be able to implement this sustainably. And that's where you need tools that can help you.
CP: In other words, they didn't think in the medium and long term in this situation. And now let's go one step further. Now we've talked about the situation of a company that is still relatively at the beginning. The next situation is the companies that have already implemented a few use cases. And they probably don't just have one tool in use, but a whole toolbox. Here again, the point is that a toolbox is good. Because of course I don't want to kill everything with one tool, I want to have a toolbox. The only problem is if my toolbox is untidy and overflowing, then I have no overview again and don't even know which tools are generally in use. Feel free to tell me about it. Let's start with an advanced company. What specific challenges do they have?
SF: Yes, they have the challenge that automation or the automation strategy has usually grown very naturally, as you mention. Different toolsets, perhaps even far too many tools, and at some point you realize that the subscription costs have somehow exploded, because you had the use case here and wanted to use the best possible tool for it and here another one and there again the best possible tool. And then there's a car, but it wasn't designed for sustainability from the start, it grew organically. And you often have to get to grips with the situation first. And you have to be able to find your way around the landscape. What is often missing in such companies are issues such as data consistency, consistent data availability, that there really is a governance model for data or for APIs, internal APIs and the like. So we have advanced automation processes but absolutely a uniform strategy that really speaks one language.
CP: And as you mentioned, growing organically is of course also a problem. Of course, it's strongly related to the size of the company and the different locations. So is a company perhaps only active in one location, or are there international locations? But if we take a company that operates internationally and has various locations, then it can or not only can it be like that, but it is very often the case that five different tools are used in Germany, for example, and five other tools in France. And in the end, as you mentioned, you have higher costs on the license side, you also have higher maintenance costs, you also have higher costs in terms of human resources, because of course I need experts for the individual tools everywhere. Are there any other challenges that you are observing here?
SF: Yes, absolutely. The point is that we find a very heterogeneous landscape that has grown organically. And that's not meant to be a reproach; these are natural processes that arise. Companies are dynamic, alive and always changing. It is quite natural that we will eventually reach a point where we perhaps need to straighten things out and agree on a common, homogeneous strategy and way of working. It is necessary to establish a clear strategy, to establish clear governance models and to take them to heart. I think it was mentioned in the last episode that you often end up with local versions of actual processes. Yes, you follow the process as it should be, but it's not 100 percent complete and it's not documented anywhere. And then there are things like data perhaps being obtained in a different way or processed in a slightly different way. And that creates discrepancies that, on the whole, lead to a lack of data consistency, which means we can't automate or can't automate properly. And this is where you have to summarize. In other words, consolidate what you have. You probably have to carry out another needs analysis. What do we actually need? And how do our processes not only run, but do we need these processes? What do we actually want to achieve with all these processes? Can we perhaps think in a completely different way and implement them much, much more efficiently, much more leanly? That's where we get to the point where we would consider really large lean automation projects in principle.
CP: And as you mentioned, it grows organically. Different tools are used at different locations. And I also looked at various studies beforehand. There are of course studies from various providers, there are studies from various management consultancies. Always on the subject of course of how many applications are in use in a company. Of course, this also depends very much on the size of the company. But the figures are between 100 and 900 applications in a company. And if you simply ask yourself the question, if I were to consolidate this, if I were to bring everything together, so to speak, and thus have fewer tools in use, what will that alone save me in terms of costs? Many companies could probably save a lot of money, right?
SF: Absolutely. The costs are of course enormous at this point. But perhaps it's not necessarily about things like license costs, but about all the overhead that this creates. To give you an example, we recently spoke to a company that has also grown quite organically, but has now experienced a strong investment in recent years and has grown very strongly through M&A. And with M&A-driven companies in particular, you have the situation that the acquired companies already have systems in place. And you still have to get there as quickly as possible to have a consistent way of doing things. We need this integration to synchronize from CMA to CAMB in order to at least have a common data basis. That we can turn everything upside down overnight. This idea is utopian and not feasible. In other words, we always have to live with this lively and dynamic environment. And we have to be able to integrate this environment. We do this by ensuring that the main processes that we have, to which we would then connect from the outside, so to speak, the step system that the purchased company may use, that we have established standards within our main processes, that we have clear governance models within these, and that we can then write the integration from the third-party system into our main systems. That's no longer a lot of work and then we can transfer these third-party systems bit by bit until we have everything in line again and then perhaps a new company is bought in, where the whole process starts again.
CP: And let's continue right now, because we've already talked a few times about lean automation and low-maintenance automation. So let's now assume that we are implementing precisely this strategy. You've also mentioned a few times that governance is important, you have to have a line and the like. And now we're really going into depth so that in the end it really is completely understandable, okay, I want to drive process automation in my company. How exactly do I go about implementing lean automation? What is the first step?
SF: By creating connectivity and interoperability, for example. These are now really big, great words, which I'm sure everyone can imagine a lot. A bit of fun in this post. Connectivity means connectivity. Do we have the ability to connect to our systems that I want to connect to? Yes or no? If we have different interfaces in the systems, then I need something that mediates between them. Do I have that? Do I have interoperability, for example, do I treat the same data in place A and B in the same way? If I have an API that gives us data, I have a consistent way of getting data out of my APIs, even internally. We often see this, for example, with external APIs, because the customer should have a good experience and the user experience of the API should be outstanding. And with internal APIs, we're just happy to have the data available, but don't really pay attention to the user experience. It doesn't matter whether a user is internal or external. The point is that they want to use this data, they just want to use it. That means creating interoperability. Then, of course, we have to establish and guarantee security and compliance standards, especially in complex hybrid environments. I may want to incorporate certain data that is available on an on-premises system in some way into a process that ultimately makes it available in the cloud or even externally. How do I ensure that access is secured at the beginning of the process without giving the end user access to my on-premises system at the end? So things like that, how can I manage a hybrid environment, how can I control it. That's what it's all about.
CP: And that is the first step. And step two, where many companies are actually already at, of course, because the entire system landscape has grown organically in recent years. I have a great deal of complexity and the question is, how can I manage it on the one hand and reduce it on the other.
SF: The point is that we want to master this first. In other words, we go there and think, do we have this interoperability? If not, then we have to create it. Even retroactively, so to speak. We are in a situation where we cannot simply replace every established system overnight. That won't work. But what we can do is connect them, for example, and then create an API for them across all systems that follows a constant model. In other words, we have built a small umbrella over our application, over our systems, which already establishes this interoperability, which already establishes this connectivity. Then we can take the next step of reducing the complexity here bit by bit, because the new setup allows us to do this for the time being.
CP: And what comes next?
SF: Yes, then you think, okay, now I have my systems connectable. Now I have my systems interoperable. Now I can start automating. And that's absolutely right. We've finally reached the point where we can do this in such large projects. I think about which processes I actually need in order to be able to map the business processes I want. I think digital processes are also business processes. I don't understand why we sometimes differentiate between them. Put them in an overall context and then I implement them. Sustainability means: we want modularizability within this implementation. If I write an authentication for system A, then I want to write it once and every process that uses it accesses this module and I don't write it. 500 times in 500 different processes. I want to be able to pack it up and reuse it. This allows me to reduce the complexity. Yes, I might then have 500 integration processes or automations, but they might only really consist of 10, 15, 20 individual modules and in between there might be smaller transformations or remapping of dates or similar. But that sounds much more manageable if I say, hey, you have 20 processes that you actually have to manage. So we create this modularizability, we parameterize them in the best way and then we can make them reusable. The second effect is that we can automate much faster, of course. If I can perhaps take semi-finished processes and only have to change them partially, or I have a completely new car but I know I can address the interface quickly. I have the main functions, I have them ready to go, I can just put them together and make minimal changes in between and I immediately have a new automation process, which means I can automate incredibly quickly. That's where we're heading. And that is lean automation, in which we also ensure that we act according to lean principles within the automation processes.
CP: In other words, if I can summarize this very briefly, if we were to imagine that we think in the short term, we introduce robotic process automation and we automate a lot of processes, as already mentioned, I get rid of one problem and create the next problem, because if I haven't approached it properly, then I will find it difficult to monitor, orchestrate and maintain the whole thing. But if I say I'm going to tackle the whole thing lean and I'm also going to build building blocks that are reusable, then that actually means that the more I automate, the faster I'll be at the next automation every time, because the likelihood is very high that I already have a building block that will speed up the next automation.
SF: Absolutely right. The more Lego bricks we have, so to speak, the faster and more beautiful we can build our Lego houses, to use a metaphor. But yes, absolutely right. Your RPA tool, which you may have bought in the beginning, is not for the cupboard and has to gather dust, but is used in systems that are perhaps difficult to access. We're talking about machine-to-machine communication, but that doesn't necessarily mean that all systems are easily accessible by machine. In other words, we might have an RPA bot that enters or retrieves data via our legacy system. But at the back end, this RPA is once again connected to our integration processes and therefore also to our automation processes and fits back into the overall standardized structure. That's exactly what we do with all the other parts. We use tools where they are really needed and where we can communicate with each other automatically, where we can automate, that's where we do it.
CP: I would like to talk about one more topic very briefly before we come to the last question, because what you also see in some companies is that they automate a process, regardless of the tool. But the automation is not really documented. In other words, it is done, but the question is, how was it done? And then the person leaves and in the end nobody knows how it was actually automated and it becomes confusing. And I have to work my way back in, think my way in, in order to understand the automation in general. How important is documentation when it comes to automation and not just how it has been automated, but how processes generally run again?
SF: That is extremely important. It's the classic. We have a senior developer who has been with the company for 15 years, knows the company like the back of his hand and automates back and forth diligently. This is the process wizard and he has the know-how. He has written beautiful code, but most of the documentation takes place in his head. If this developer leaves us now for various reasons, then firstly no one will have the ability to get these existing automations up and running again if they don't work. Nor are we likely to have the ability to actually implement further automation because we don't really know how we automated before. In other words, documentation is a very large part of a sustainable strategy. Sustainable means that we want to continue to build on it and we need documentation for that. As I mentioned earlier, we also want to consider digital business processes as fundamental business processes. In other words, we also want to give people from the business, from departments that are not necessarily IT, the opportunity to at least think about digital processes and understand what is happening there. Because then these people, who know their area best and are the experts, can think further, hey, what can I actually automate? Only then will they know what is actually possible. And that stimulates a bit of creativity.
CP: And now that we've come to the end, what's your top tip when it comes to making process automation leaner?
SF: Yes. That we take lean principles to heart.
It's a bit like going back to the roots. Meaning: we ask ourselves, hey, are we consistent? Do our processes actually create value? Is this process, which I think is generating added value, really necessary as it is?
Have I taken this process and simply transferred it to digital or have I thought about this process digitally?
These are actually the simplest things to come back to. It's usually the basics and the basic things that make the big difference. Because if we have a foundation that we build on, then it becomes increasingly shaky towards the top if this foundation is not solid. And then we come back to things like managing complexity, creating data consistency, ensuring security and compliance, and creating connectivity and interoperability.
CP: Samuel, that's a perfect ending. I now have a house in my head where the foundations are completely unstable and about to collapse. That definitely remains a negative memory and you definitely don't want that and that's why you should build a strong foundation so that the house stands for a very, very long time. At this point, that was a super exciting conversation. Thank you Samuel for being there. All the best.
SF: Thank you, Christoph. Thank you very much.