Where is the value in process mining? A conversation between Roots Automation co-founders John Cottongim and Chaz Perera
The following is a transcript of a conversation between Chaz Perera, CEO and John Cottongim, CTO. The respective Roots Automation co-founders lend their expertise and thought leadership around a relatively new technology that is quickly becoming a buzzword: process mining.
Last week, I was chatting with a partner at a large advisory house, and we got into a conversation around process mining. The point she was making is that her company is making a relatively large investment into that technology. And it made me think, what sort of value could this technology build for for companies that deploy it? I thought it would be interesting for us to share our points of view - so starting with you, what do you think about the space? What do you think about the tech and how it's leveraged?
Clearly, it's been a growing and changing field. I don't know, it's probably really only been four years that the industry has really started to dig in to this. The initial take I always had on this was that process mining is most valuable for probably the largest firms in the world - the firms that have a hard time getting a hold on everything that they do. At the more mid-size enterprise firms, the heads of operations probably have a pretty good idea what processes are happening, where they're spending money, where they're outsourcing, where they're in stores, and the complexities of their processes. So, they more or less already know where the challenges are. Within the larger enterprises, this can be more difficult. But otherwise, I'm a little skeptical that most firms will need such tools.
It's interesting. What I like most about the technology is that it can get you to the quote-unquote "happy path" relatively quickly. You could make an argument that a good BA could do the same thing within a few hours. That said, there's some nuances that the technology will identify that the BA may not necessarily surface within a single conversation. But in my opinion, the real challenge is around exception handling and exception processing, because humans have a tendency to take all of those things offline: making decisions, having a conversation about it, agreeing on a game plan.
The end result - what is reflected in the system - is just the outcome. And I think that's a real challenge.
Sometimes it's counterintuitive, but when you hear people wanting to apply this technology, they're often wanting to apply the technology to find that complexity to go solve those challenges. Why isn't everyone following the same process? Why are there so many exceptions? But the reality is that the world is messy, and what you're finding is not really an automation opportunity because of the complexity. What you're finding is where, in your world, there's a high degree of variability combined with decision making. Likely, there's high amounts of offline processing that's happening - in the employee's head, in group conversations, that sort of thing. Which then leads me to think that the real value that we're going to find in process mining is where there's not complexity. So if you hit your head against the wall trying to automate super complex tasks, you of course, say, "Right, let's find where it's more straightforward?" Because the straightforward processes are probably areas that you already know about, right?
The thing that I have always told people is that great areas to start automating are areas that are named after the thing that they do. So when we're talking about the accounts payable team... well, I already know what that team does, right? But if you're talking about 'corporate finance,' I don't know what that would means in the context of day-to-day processes. So that's a very challenging place to to automate. Often, I think that the the 30,000 foot view of how we view these processes is to laser-focus on a set of activities, and that team is probably the team that can leverage automation technology the best. Correlate that with how much you're spending in those areas with those teams, and honestly, that's the 80/20 principle there, right? That's gonna get to the center of mass and tell you what you should be looking at and what you should be diving deeper into, and then how you can do that from a business analyst perspective, or a technology perspective.
You know, maybe there's some more wiggle room there, and I don't think these technologies are panacea by any means, but that's how it's branded.
Yeah, for sure. I mean, the other thing that's interesting here is thinking in the short term versus the long term. In the short term, I do see this technology essentially being highly coupled - or at least closely coupled - with an RPA solution so that you can at least use this technology to build your base RPA.
Challenging that though, most business processes start with semi-structured data. And this uncovers the elements of the process, the variables that drive that process, etc. Because it could be in a PDF, it could be in an email - you're not sitting there, highlighting what you're about to leverage. You're just saying, "This is what I need." And how do you close those gaps?
Yeah, you're now talking about over-the-shoulder monitoring, as well, which brings in another level of complexities, and most of them are this corporate culture and interpersonal type of complexities. How much we watching people to be able to scrape what they're doing on a click button type of level? To be able to then perhaps, try to start to build up an automation?
The reality is that the goal of building automation is, of course, the happy path. Around 10% to 20% of the effort and the assessment testing and making this automation robust and resilient to the variety of things that come up - the process challenges - that's really the result. So I can see it giving people the initial lift. At the very low end of the complexity scraping attachments and getting them to a repository - you know, that can probably do it because to a fair extent, it always happens the same way.
But if you're not trying to categorize those attachments and respond to them in some sort of fashion, now you've received a lot of pieces that are challenging the code-based RPA that technologies today really require. Ask folks why they do what they do, and frankly, they don't always have that written down or ready to go, and so interactions are valuable.
Sometimes, even if you get several subject matter experts to sit down, you'll get different answers to the same problems, the robotic aspects of this exercise.
I'd really argue that it's very challenging to just assume that the most frequently used solution is the best solution. And I think that's a bit of a trap, and I think that your best teammates are likely doing something above and beyond or different than what the average person is, and that's why it's only happening 10% of the time, despite the fact that is the thing that you want annually. Well, that's just not going to come out in the data.
So gathering the data is great, having the data is super important. But then inspecting and introspecting on what this all means, I think it's still a very human centric activity. Then, understanding its place and automation in part or in full around the interactions, then what's the best experience for the people on the outskirts of that? Probably not a data exercise. That's UI/UX. And again, very, very human centric.
When we discuss this topic with prospective partners, data mining often comes up. As you say, it's a four year old technology and it'll do some amazing things in the next four years. But some of the tried and true ways to understand your business process are still applicable today, and likely acceptable.
Yeah, if you're an organization that feels like you've automated 50% to 60% of the low-hanging fruit that is out there today, and you want to continue to try to push and find the next 20% to 30%, then I think it could make some sense for your organization if, again, you're one of the bigger companies out there, and you have one of the more successful automation programs out there. But if you're just starting out, there are more simplistic, more tried-and-true ways to get at that initial sense of value.
Instead, focus on how you can build a good practice around this. What does it feel like? How do the users engage with it? How are they going to respond to it as they train, and will they help that automation program succeed? I think those are the core aspects of it. And if you did all that, you can dive a bit deeper as this technology matures. I'm sure it'll continue to help expose some of the less obvious ways the technology can impact organizations. That's how it's evolved over the years. It's a good journey, very AI-centric. I look forward to seeing what they come up with.
Awesome. Thanks, John!