Guy Nadivi: Welcome everyone! My name is Guy Nadivi and I’m the host of Intelligent Automation Radio. Our guest on today’s episode is Robert Hutter, Founder and CEO of FireStart. FireStart, for those not familiar, focuses on process modeling, documentation, and enterprise workflow automation in the mid-size market. This sort of holistic approach to automation is something we haven’t really dived into yet on the podcast and we don’t get a chance to talk much about the mid-sized market either, which is expected to be booming for automation. So having Robert on gives us a chance to kill two birds with one stone and hopefully learn some new things about both of these areas. Robert, welcome to Intelligent Automation Radio.
Robert Hutter: Hello everyone. Thanks for the invite.
Guy Nadivi: Robert, can you please share with us a bit about the path you took that led you to launch FireStart, and how you came up with that name?
Robert Hutter: Yeah, sure. So I originally started FireStart back in 2008, together with a colleague of mine. And from my professional background, I’m a software engineer, so I started software engineering and started building applications in the markets. And whenever we came across customer problems and we tried to fix them in the applications we were building, the process was always a very key element of the architecture and the fulfillment of the requirements in the end. But it always was a very hard topic to tackle. And since I was always a big fan of a model-driven approach and how to tackle problems and we have a fast track to building solutions, that was kind of the core idea why we started FireStart, to really have a platform that on the one hand can help you keep the governance on your process development on the business side, but makes it a lot easier in the translation to the automation and the IT architecture involvement. And with that in mind, how did we come up with the name? So we wanted to have something with emotional attachment and fire is a very emotional element that everybody knows, and usually has a very positive attitude towards, and it also has a little destructive element in it, which at some point you need, because very often you have to tear down old-fashioned mindsets and silos in order to let new processes and agility grow. And that’s also a major part in the name. And the third part, it’s like the “Start” is like, we want to get in production quickly. So it’s not about beating around the bush with the process, but the process is a core element, but you want to deliver results in a very fast fashion. And that’s like getting up to speed very quickly that also reflects in the name.
Guy Nadivi: So process architecture and governance are big parts of what you do at FireStart. Why are those such important elements in building a lasting automation strategy?
Robert Hutter: In general, whenever you want to build something, you should have a plan before you start building. Just like as an example, if you want to build a house you’re not starting right away building it and then see where you end up, but you would want to have a decent plan before you start building that gives you an idea how it looks, that gives you an idea how expensive it will be, or will it fall apart? And that’s a major element in efficiency on delivering the right results because if you have a plan before you start building it, you also have a better expectation about the results. And then once you have a plan, you can repeat the process. You can build multiple houses on the same plan that you have initially designed, and then it’s worth spending more time on the plan, so the better the execution, you can just get better and better and faster and faster. And this is why very often have the feeling that when you don’t have a proper process governance and process strategy in place, you very often end up in dead ends and you are kind of reinventing the wheel each time and you have nothing you can build upon. And processes are very heavily dependent on usually, so they’re not living side-by-side. But you build processes on top of other processes and therefore, you also need to manage the governance and translation between process changes, which is very essential if you want to make business process automation a part of your digitalization strategy. And it’s about all the segregation of duties. So you might have somebody doing the design, you have somebody else doing the cost calculations. You have somebody else doing the actual building the house. So process architecture is also about having segregation of duties, but that at the end of the day, everybody can collaborate on working together as a team, creating the results. And this is also what process management and workflow automation, it’s about getting people together so that they actively can work as a team in the whole engineering process.
Guy Nadivi: So you’re talking about a process-first approach, which of course makes a lot of sense, but I’m curious, what other approaches have you seen in the market?
Robert Hutter: Well, in my opinion, process is pretty much the most critical asset that you should start, where you want to build a design upon. And from the other approaches I’ve frequently seen in the last years, either they are very application-centric, let’s put it that way. So usually you start trying to squeeze an architecture into one application. And you always start with the boundaries of your application in your process design, which is…since a process is mostly a natural element that lives beyond a single department or beyond a single application, a very bad approach, because it already constrains you in the way, the creativity you can imagine about how this process could look and feel in the end. Another approach is very, let’s say data-centric or document form-centric, where everything is around the document that you’re processing and that is like the key artifact that you’re managing in the process. But then it’s very often hard to imagine parts of the process where it’s just about communication, where it’s just about collaboration, where not a single document is involved at all. And so I would always try to also start with a people-centric approach because when you do process design and you do automation, it’s mostly about making the day-to-day work of people easier to complete and to accomplish and to get satisfied in the work they do. And so I would really enforce a people-centric approach and start with the process design first, like a process-first approach and then on the second-hand, talk about data integration, talk about application design. But the process should be the core asset to start in the architecture and design.
Guy Nadivi: We’re hearing more and more about process mining and other AI-based discovery platforms being deployed as part of digital transformations. Robert, what role do you foresee process mining will play in enterprise workflow automation.
Robert Hutter: It’s definitely a topic that is very much picking up and it’s just like a technology that you can use to answer a very simple question, which is what is the current status in my day-to-day business, with the processes that we already have in place and that we already run on specific applications? And as easy as that question might sound, hardly any company is really familiar with what’s really going on in their applications. And either you bring in a lot of external consultancy or you have internal development teams that start analyzing to find out what the status quo is. And that, of course, takes a lot of time and is also very resource intense and costly, just to find out what’s going on in my processes. And process mining at the heart, is technology that can really shorten the time from, to understand what the current status quo of your processes is and to really raise the full visibility on the processes. And not like the PowerPoint. Nice to have visibility, but really like the brutal hard day-to-day facts about which variations you have in place, you never imagined that they could be in place. And it’s just like a good starting point to get the full truth of your process, so that you actually find in a quicker and more efficient way, where to tackle the problems. So you might find some variations of the process that you don’t want to have because they would violate maybe data privacy rights. And then you can start working with RPA and workflows to get rid of this unguided processes and bring in more structured and guided processes in place, so that at the end of the day, from the many thousand variations you might have, you can come down to the dozens of design variations that you want proactively establish at your company. And process mining just makes the fast ramp up for this first discovery phase – what’s going on in my process world today.
Guy Nadivi: Now, speaking of RPA, what is the difference between enterprise workflow automation and robotic process automation?
Robert Hutter: Yeah, it’s a term that very often gets mixed up in the market from my experience and they sound similar, but they’re heavily different topics, in order what problem do we tackle with them? So when we talk about enterprise workflow automation, we come from a organization or company perspective. And the goal here is to create process standards where all the applications and users are aligned to the corporate guidelines, so that the process runs as smooth and efficient as possible and also fulfills the enterprise requirements. The product process automation starts from the end user to tackle automation problems from a personnel perspective. So you would want to… Robert is always doing the same repeating tasks, so we try to build a software robot that can help Robert doing his job better. But it works in this scope from a individual perspective and it usually also works in the governance of the individual user. So I’m personally responsible for building the robot, for maintaining the robot, for phasing out the robot, if not needed anymore. So it’s in my personal governance. If we talk about enterprise workflows, the whole governance is a lot more difficult and complex because you need to have multilayer architecture. You need to have staging in place. You need to deal with data access and security. So you might end up in a conflict because the company wants to have standardized processes, and the user would maybe want to have highly individual requirements fulfilled with his robots. So in a ideal world, these should originally work hand-to-hand together and so that you can have the individual flavor and the enterprise standards combined in one automation strategy. And think of it like if you compare Excel sheets with SQL server. The one is like holding the governance on the corporate data, making the access available for the users, but it’s one single point of truth, where people can go and pick up the data in a governed and maintained way. Excel sheets, at the other hand, I would like to have my personal calculations and work with the standardized data, but with my personal pie charts that I just like, and nobody else. So I can change the Excel look and feel in my personal flavor, but I would work with the corporate data and standards that the SQL server provides me. And this is how enterprise workflow and RPA should be seen as technologies that just fulfill different requirements that automation needs.
Guy Nadivi: Robert, there’s a lot of talk these days about low-code/no-code automation and the rise of citizen developers as a result. When will orchestration tools be simple enough to use, that they’ve democratized automation for the masses?
Robert Hutter: Yeah. The markets, as you said, there’s like heavy code, low-code/no-code, as a way how to approach our technology problems or application engineering problems. Of course, heavy code is not the way to go because this is where we come from. It’s complex. It causes a lot of maintenance and a lot of costs on top. On the other hand, the other extreme, no-code is very much hitting the roof too quickly, when tackle more complex process problems. So ideally the way we want to tackle problems is a low-code approach, which applies to the 80/20 rule. So let’s say 80% of the engineering you can do with involving business users in certain parts of the process and just doing like the last mile, the last 20% for specific more complex parts of the process, where you actually need to go to a coding level. But in that combination, you have both scopes on how to tackle a problem in a meaningful resource usage, to engineer the solutions that you want to have. And I would definitely see low-code as the future because like the citizen developer approach, with the end goal, every citizen developer can do automations and application engineering on his own. I wouldn’t see that this should be the goal to reach because we already came from excellent macros and you know where we ended up with that one, and you see like the similar risk here, that it’s at the end of the day about engagement, that different stakeholders can do different parts of the engineering process. But at the end of the day, it’s for a citizen user, I would say. And the more understanding a citizen user has from the engineering process, the better he can be involved in the whole requirements, engineering, and testing, and roll out of the solutions. But it’s not necessarily that I see as the big goal that these users should be the one engineering the process. Maybe as an example, if you pick a manufacturing customer. So there are professionals coming into assembling a production line from electricity, from manufacture, putting the right pieces of the machinery together, with the goal that the workers then working in the process are perfectly aligned with every step to do in the process. And the same applies to process engineering. You need to have engineers, you need to have architectures, that know their profession in order to make the whole design right and that everything fits perfect. But it’s a profession and you need to bring professionals into the process because you don’t want to have the workers, every worker building his own assembly line, so that he needs to have all the knowledge because he will not be able to have all the knowledge to do that. And this is the way how I would see it.
Guy Nadivi: Getting back to enterprise workflow automation. Can you share results from one or two of the more interesting enterprise workflow automation projects you’ve worked on?
Robert Hutter: Yeah, sure. So we had really a lot of different customers and errors in the last two years, ranging from big corporates to really small businesses, applying BPM and workflow automation. Maybe one from the larger enterprise cooperates. We had a really successful project at a very large retail company with about 30,000 people worldwide, where they really had the need of applying a unified workflow strategy along the company, so that people are really harmonized in the way they are engaging in processes and just be more efficient in the way they work it. And it was actually a pretty cool project. We, from zero to production, had about two weeks to really roll out the first workflows for about 500 users involved. And there was literally no announcement, no training involved. And once we kicked off the project, the first two projects, which were about, I think one of the cases was HR onboarding, they had around 200 onboardings a month that they needed to schedule. And on the other hand, the second use case was the contract management with their suppliers because they have about 4,000 suppliers, where they need to do regular updates on the contracts they have. And these were the two use cases we rolled out. And the funny thing was like, after the rollout, the customer turned completely radio silent for about two months. So we had no feedback about how it’s working, what is the feedback? And then after two months, I got the call from the project manager that was leading the project. And I just approached him, saying, “Hey, how’s it going? What is the feedback?” And then he paused. And the first thing he told me was like, “Oh, it’s so cool. It’s so cool. I have to tell you.” And this was really just a very good memory because it really, the whole emotion spread out of him and you really could see the emotional attachment to the solutions we have built. And it really rolled out like clockwork. And they already had, after the first two months about another 20 projects in the pipeline that came from the business users with a lot of problems. They haven’t really figured out how to tackle them. But with that approach they really had a complete different way of thinking and how they tackle now, other problems. And we doubled the speeds of the processes within the first two months. The engineering effort was a fraction of multiple of 10, versus the heavy code approach they used to have. So they used to code everything on top of SAP, which was the core ERP backbone system. And now with the more agile process driven approach and FireStart, they virtually brought down the efforts and speed with a multiple of 10, which is pretty huge. And over time they rolled out, I think now, they are at 100 plus projects they executed on our platform. And they are a super happy customer for us for many years. And this was really very cool to see how our core technology and principles could be applied so successful on such a huge organization. On the other hand, we had a small customer in Switzerland, which is the Funk Insurance Group. They are managing a lot of processes regarding insurance management for the clients. And their biggest pain point was always that they were super dependent on the vendors with every little process change. They always had to go to the vendor and kind of begging for a change. And it was super expensive for every little process step that they turned. They would get an invoice with a couple of thousand euros for the adaption of the process. And that was kind of what was really frustrating for them. And then they got in touch with FireStart, installed the platform. Then they didn’t really know for one or two months how to tackle it because they had no experience. And then they called us. “Okay, we will lock ourselves up for a week. We will even change the building and we will do nothing else, then work our knowledge in FireStart and align our internal users on this newer way, to approach.” And after that one week, they were 100% up to speed, to do every process development and change completely on their own. Not with us involved, not with a partner involved. They kind of really got the freedom back to be 100% in the driver’s seat of their own process engineering. And this is also like a feeling, if you’re always dependent on whatever, it kind of frustrates you because you always have to, the feeling that you need to go back for something. And that’s especially the frustration that you mostly see in the business side, that IT resources are limited and there’s a lot of lost in translation effect and that causes a lot of frustration on both sides. And it’s really cool to see this freeing up the process and getting my freedom back and my process design was implemented on a small customer that literally had no IT experts, or software engineering experts in the team. It was mostly driven by the organization development department. And that was another thing, like really cool project, at the other end, on typical customer sizes that we address.
Guy Nadivi: Cool stuff. Given your experience with enterprise workflow automation, what do you think are going to be some of the biggest disruptions we’ll see in the next one to three years, with respect to automation, AI, and other digitally transforming technologies?
Robert Hutter: Yeah, of course, AI is currently the big thing in the market, since the technology is evolving that much and really at a incredible speed, which is amazing. And it will kind of freely enable a lot of predictability in the engineering. So if you think about predictable outcomes, predictable resource allocations for a specific process. So the better you can predict a certain future state, the better you can start now aligning towards it with your process adaptions. And I think in that regard, AI will play a massive role in how much predictability you will get into your process design. And on the other hand, data, the amount of data sets available is also massively exploding. You see a lot of data platforms popping up that really can provide your data as a service. And that again, in combination with AI, super powerful. And as we already discussed process mining. I would see process mining as a key technology in that space, helping in the translation from the raw data to the more intelligent process insights, that you can then again take as a starting point for initiating enterprise workflows, initiating robots to do the right job in the right timing and getting the state of predictability, is key in that regard. And I think a third thing that I would see in the future is in general, the way how you approach process design. Because from the history, it was mostly somebody who knows the process, designed the process, in order that other people can use it and run the process. And I think it’s always like the adaption always comes from the design part. So always the process manager has to be involved to adapt the process. And with that technologies, I think that will also be more self-aligning and kind of self-adapting, so that the process designer will start building the process design on top of just watching people doing the work. And with people adapting the work, it will have an implication on the process design and the change that will help in the background. So I think it will really reward the whole way, like learning by doing and by people changing their behavior, it will also change the process design in the backbone and therefore be a lot more self-adapting to changing to new requirements in the market.
Guy Nadivi: Robert for the CIOs, CTOs and other IT executives listening in, what is the one big must have piece of advice you’d like them to take away from our discussion, with regards to implementing enterprise workflow automation at their organization?
Robert Hutter: The first piece of advice would be that whatever you do, start with the people in process first approach, because this is like the foundation to bring out successful outcomes of whatever you do. Then second advice would be don’t shoot for this. Like everybody should be able to fully do automations because it’s like there are professionals that should build the architecture, bring in automations and there are business users or citizen users that should consume the solutions with the least complexity. And this is the way to go. Remember that enterprise workflow automation and robotic process automation are at the end engineering disciplines. So you should also tackle the problem like you would tackle any other engineering problem, thinking about architecture, thinking about abstraction, thinking about reusability and thinking about the overall strategy behind it. And really value the process. It’s the most relevant asset in your company. It what separates you from other competitors and peers in the market and it’s the most relevant asset that will define the success or failure of your organization. And coming to a famous quote from Charles Darwin, “It’s not the strongest, the most intelligent ones that will survive. It’s the ones that are most adaptable to change.”
Guy Nadivi: Wise words. Always good to end on a note about evolution, which is very applicable to our field. Looks like that’s all the time we have for on this episode of Intelligent Automation Radio. Robert, it’s great hearing about an automation company focused on the mid-size market because it not only reflects the growing reach of automation, but also the growing opportunity for companies such as yours, with a unique solution. I think that bodes well for everyone and I thank you very much for sharing your insights with us on the podcast today.
Robert Hutter: Thanks a lot for the invite. It was a pleasure.
Guy Nadivi: Robert Hutter, Founder and CEO of FireStart. Thank you for listening everyone and remember, don’t hesitate, automate.
