From Red Tape to Innovation Engine: How This CEO Is Disrupting Business Process Management
Kumar Dattatreyan: Hi, everyone. Kumar Dattatreyan here with Agile Meridian and the Meridian Point. Today we're joined by Liam O'Neill. He's a managing director of BPMD, a London-based boutique consultancy that's revolutionizing how companies think about business process management. Far from the bureaucratic stereotype, Liam and his team work with major brands like Lego, BBC, and Sony to make processes a catalyst for innovation rather than a roadblock. I like hearing that. What sets Liam apart is his approach to embedding agile principles into business transformation, creating sustainable change that doesn't require years of consulting dependency. He's here to share how organizations can break down silos, accelerate digital transformations, and turn process ownership into a competitive advantage. So without further ado, let me bring Liam to the stage here. Hi, Liam. How are you doing?
Liam O'Neill: Hi, I'm doing really well. Thank you for that lovely intro. Absolute pleasure to be on your show. Thank you for having me.
Kumar Dattatreyan: Yeah, I'm happy to have you on the show. It's been a while since we had our last conversation, so I've been looking forward to this for a while. So, Liam, when most people hear about business process management, and myself included, they think bureaucracy and red tape. You've built a practice that's really the opposite of this. Can you tell us a little bit more about your practice and what you've done that's different?
Liam O'Neill: Yeah, absolutely. So I've been in the process space for a little bit over ten years now. When I first came in, I was very much working in that traditional process management kind of environment. It's creating models to support quality teams and to help with a little bit of training, help with creating some clarity on how things work. But that wasn't helping the businesses we were working with. It was maybe solving a point problem. Maybe helping one person manage onboarding. Maybe I'll get to a point where you've got an idea on what needs to change. But that wasn't delivering results for businesses. Being clear on a process is great, but we need to solve it. Businesses needed to take that and actually do something with it. Carry that issue, that target state process through into a realized vision, a better way of working. And break down a little bit of those silos of the traditional BPM teams sitting in a little ivory tower and not interacting with actually engaging in the change. That's something in recent years we've been really working hard to break, to get a process out of this quality box, out of this hidden part of the business and get them to really engage, not just in the shaping of change, but in the actual delivery of it.
Kumar Dattatreyan: Interesting. You mentioned silos and sort of bringing your teams out of their boxes. What does that look like in practice?
Liam O'Neill: Yeah. So I think everyone's familiar with the problems with those really tricky cross-functional handovers in some of your core end-to-end processes. Procurement, going from your buyers to your logistics teams into your accounts payable, and the same for order to cash. So everyone talks about these functional handovers, and everyone knows they're a little bit tricky. But the same goes for your change teams. You've got the same challenge when you've got a data team and a process team and then a PMO team. There's handovers between them, and there's a lot of crossover redundancy. You've got a data team saying, these are the insights, these are the plants that are a little bit behind, these are the sites that need to go a little bit faster, these are things we need to change. Process team doing a similar kind of exercise, maybe a bit more bottom up and talking to people to find issues. But then there's going to be a handover to the teams that have to go and deliver change via an agile project management team, be it the actual business itself, wherever it may be dependent on the nature of that change. And same way you have it in the rest of the business. These team handover points, things get lost. Things fall down and things slow down. And that's one of the biggest barriers to actually using process in a productive way and being able to actually affect change in a way that really moves the dial as opposed to just some pretty models and some pretty dashboards that no one uses.
Kumar Dattatreyan: Yeah, that's a good way to put it. So you mentioned in our last conversation that traditional change projects often fall into a black hole. And I think that's what you're referring to here, right? After the handoff. So what are some specific breakdowns you see when organizations try to implement digital transformations? And how does your approach prevent those failures?
Liam O'Neill: So I was working with a logistics company a little while ago, and this was kind of remember time flies a few years. And we were doing the traditional process piece, you know, looking at order to cash, modeling that out, finding the improvements, the changes, the innovations. And we had this really good momentum. Everyone in the business was really engaged, excited about how we could shape what the future of business was going to be. But then the handover to the PMO team slowed everything down. They had different expectations, massively different expectations on what they were going to receive. And the process team had different expectations on what they needed to give over. And there was this breakdown. The PMO team weren't sure what they were actually going to be delivering. The process team thought they'd done a great job. And this massive disconnect meant that all that goodwill, all that momentum was lost because there was a, I think it was about six months or so before delivery started going anywhere. And what that did was, it highlighted you can't have these disparate change teams who aren't involved. You need to have that continuity through the delivery cycle. The people who are creating the change, the data teams, the process teams, the enterprise architecture teams, there needs to be some continuity. That same vision of what needs to change, needs to carry through into the actual delivery element. And that's not just where the PMO sits abstract to the business. You need really structured business engagement as well. Ultimately, we're the ones who have to live that change day to day. So we need to be engaged in a structured way. I think we'll maybe go into that in a little bit more detail later, but I think process ownership at a really granular level is a really interesting concept here, but we find to be really effective.
Kumar Dattatreyan: Yeah, we are going to get into it right away, actually. You've adapted the Scaled Agile Framework for business transformation. Scaled Agile Framework has been used in lots of different contexts and building physical, cyber-physical systems, building software, of course, digital transformations, and you're using it in a unique manner. I wonder if you could talk about that a little bit.
Liam O'Neill: Yeah, definitely. I wanted three things. I wanted there to be urgency behind the change. I wanted to be really clear who needs to talk to whom and when. And I wanted to start with all the bureaucracy and just get things going, get an MVP prototype, a minimal possible change, rather than trying to create this massive vision of what the end state needs to be and work to that. So get people moving, be clear on who needs to do what, and don't let perfect be the enemy of great. So what we did was, obviously, we've worked with a lot of IT companies, a lot of process work is in support of digital transformation. So I was familiar with the Scaled Agile framework, and I'd seen that applied in a lot of IT contexts. And I liked some of the ideas, the sprints and the engagement, the way you have an increment and that backlog and that feeds in, were just ideas that helped to address I thought some of those challenges. And the sprints were going to create that artificial urgency. I did adapt Scaled Agile a little bit and brought in change owners. It was very close to line with process owners, so it was real clear business accountability. And we didn't let this, you know, it was a project initiation form this company had. We wanted a really detailed view of what the end state looked like, and we scrapped that. We said, let's get moving on. What we think that end vision can be, and that will evolve as we go through this. So one of the key drivers here was to try to affect that. And we launched it, and we tried to keep as true to the Scaled Agile framework as possible initially. But quickly, we saw some elements of it weren't quite working. Working with predominantly business stakeholders, a little element of IT, and some of the words from the terminology, people just weren't understanding. User stories, backlog, even sprints, some of these terms weren't familiar to the people we're working with working with business stakeholders not IT stakeholders and why is it a backlog why is it not my list of projects my project portfolio um why is it a sprint why is it not a two-week delivery room why is it user stories why can't we just call these projects issues and really make that terminology something that they were familiar with and that was one of the biggest drivers of actually getting good engagement, making it something that people could engage with. They understood it was something that felt natural and native to them. So we started with Scaled Agile, and then we adapted it for the organization, made it something they could properly engage with.
Kumar Dattatreyan: Okay, so Scaled Agile is the framework you used in order to introduce change. So you use this more of a method to proliferate the change, I suppose, through the organization, right, at different layers of the organization. So it's interesting. And so rather than product owners, you had sort of change owners, if you will, and you're implementing small changes in an iterative, incremental manner. Have you heard of the Lean Change Institute? I think it's called the Lean Change Institute.
Liam O'Neill: I can't say I have. No, please tell me a bit more about it.
Kumar Dattatreyan: Yeah, there's a guy, Jason Little, who is sort of, he has this whole framework that's just around lean change. You know, just how do you do change in a way that's iterative, incremental, kind of like what you've used with Scaled Agile, sort of using elements of that to run change in the organizations that you serve or not run change, but to make change happen, right? In an effective manner. And so these lean change principles are very similar to what you are trying to do. Very similar, actually, there's a whole sort of set of frameworks, I guess, frameworks and patterns around that, that you might find really interesting. I encourage you to take a look at that.
Liam O'Neill: Definitely. Yeah. The one really interesting angle that I perhaps didn't touch on there is in the process world, there's this one really interesting, so with the agile approach we took, we wanted really clear business ownership and I'm sure this, this link building, uh, lean change has some elements of this, but we wanted really clear business ownership to delegate some of that authority into the business and getting that real business engagement was one of the biggest challenges and doing that in a structured way. So it's not all bottlenecks at heads of function. So I think one of the most useful adaptations of framework we did was bringing in a really interesting concept from business process management, which is that of process ownership. So having really clear accountability for how a process runs sitting in the business. There's kind of two tracks of process owners. This is what you see as part of major ERP transformations. We've got a process owner who's essentially a product owner. But when we talk process owners, when a lot of business process professionals talk about it, it's a little bit more of a granular role. Quite a detailed process, like managing accounts receivable, inbound billing, managing customer disputes for a specific region. Quite a granular process. That's quite a granular owner. A head of function minus one, maybe minus two. Someone in the business who's still quite senior has the ability to drive change and the authority to do that, but they're responsible for how that process runs. That concept pulled into the scaled agile world worked really well. They could see which processes would be affected by the disparate projects and get really clear ownership and accountability for each of those packages of change. So it wasn't a case of trying to find the head of function and get their time. or running around just trying to find one or two people who might be interested in supporting. Instead, we had a really solid framework for saying, this change is this person's responsibility, and then holding that person to account for making that change happen.
Kumar Dattatreyan: That's interesting. So these people, these roles exist, or is that something you had to make part of the change that you were responsible for?
Liam O'Neill: Yeah, so with process ownership, like I said, there's a concept of it being a discrete role, which is basically product management. Fine. In massive global organizations, that can make sense. In my view, that's essentially a product owner at that point. But this process ownership role, the delegated one in the business where you're forcing people to take accountability for how a process works, that shouldn't be a discrete role. Someone needs to be in the business, if not doing the process, at least closely affiliated with it to understand it and how it works. And that can't be this discrete role. It has to be someone like your accounts receivable lead, like your logistics manager, like someone who has a practical role. And this is an extra hat they wear. There might be some additional responsibility in terms of documenting and holding accountability for process performance and supporting some system change requests. But really, it's just an evolution of that existing role. As an accounts receivable lead, you're responsible for accounts receivable. And process ownership is just an evolution of that formalization of some of those, formalization of some of that delegation of authority into that person.
Kumar Dattatreyan: Yeah, that makes sense. So the people already exist, but they may not have the full purview of what their role should encompass. And so what you're doing is sort of saying, hey, as the accounts receivable lead, or the whatever the role is, you own the entire process from beginning to end. And so it's really an understanding of the sort of the full value stream, if you will, of that process, you know how to start and all the different pieces and parts to it, where tell me about ownership, what does that mean they if something goes wrong somewhere midstream, and it's being processed by some clerk. You know, what what is the what is the role of this process owner and helping that person fix the issue and and so on? And I don't know. That seems kind of important that that if this person owns a process, what does that really mean? The sort of people that work the process report to this person or how does that work?
Liam O'Neill: Yeah, so in kind of traditional process world, the one that sits in a little quality silo, a process owner is someone who just signs off on the SOP, on the model, on the documentation. But that doesn't move the needle at all. Ownership shouldn't be about ticking a box on an SOP or filling a form in for an audit prep. It should be about, like you said, taking accountability for that process, making sure it's working. So the process owner role does have that element of being responsible for defining how the process works, but more importantly, they should be responsible for the performance of that process. One of our clients, we've actually gone through the entire process operating model, every process in the business, about six hundred level three processes, and each one has a process owner. And each of these processes has a couple of KPIs, or PPIs, Process Performance Indicators. And those are right now being tied into those process owners' job profiles, tied into their performance management cycle. So if you're an accounts receivable lead and doing a great job, all your team love you, fantastic. But if your accounts receivable process is broken, then you're not doing a good job. You need to be held to account for how your process is working. And this company is tying all of these PPIs into the formal performance management for each of these roles, which is a really good way of forcing that accountability into the business. Now, in terms of does it mean they manage everyone in that team? No, it's not about organizational design. It's not about levels of hierarchy necessarily. And process ownership also doesn't work if there isn't the requisite delegation of authority. You're holding people to account for how this process works. They need to approve the changes. They need to be empowered to make those. So if every single change has to run through the head of function or CXO, then that's not going to work. You're holding them to account for something they can't control.
Kumar Dattatreyan: Right, right. Makes sense. So it's a delegated sort of responsibility. There's one person that has responsibility for the process. And of course, each person that's part of this process, they have ownership as well. But the overall sort of ownership resides with this one person. It's interesting. I have to think about that some. As I'm percolating, I might come up with a question. But I want to switch to, you know, sort of major system integrations like SAP, S/4HANA, What role should BPM play in these types of implementations?
Liam O'Neill: Yeah, so I think a lot of the SAP landscape and major ERP changes, obviously, historically have been very IT driven. SAP as a company was very IT driven. And what it means is when you get business engagement, you might get a shopping list of requirements that are just off the top of people's heads. People work very hard to put these requirement shopping lists, but ultimately you're relying on people thinking about what they do day to day. We're going to default to the most standard tasks. They do the most painful ones and focus in on those. They're not going to necessarily explain the whole process. We're not going to think cross team. We're not going to think exception. So, you know, with big shopping list requirements, you generally don't get a business too engaged either because it's difficult to get excited about a shopping list of requirements that you hand off to your IT team. And what that ends up with is these massively customized systems that cost a fortune take forever to test and even longer to roll out that don't deliver on ROI and I think SAP recognized this a little while ago the market's starting to recognize it so SAP actually acquired a process management tool uh Signavio a really really good tool fantastic cross modeling tool really strong process mining tool And the reason they did that was that they saw they were getting away from the foundation of the business. SAP was very much in keeping with the German stereotype. It's built on process, built on a structured way of working. But over time, it evolved into this IT-centric organization that was growing arms legs feet and every other appendage you can imagine so the idea was by Signavio try and shape all the major SAP transformations around process being clear on what you're doing and building to fulfill that rather than building unnecessarily and impractically what does that look like okay I'm sorry I do have to keep pausing for a drink it's a heat wave in the UK so I must apologize I've gone bright red like a tomato I uh I mean, a little bit of a sauna box right now. But practically, what does it look like? There's a big role to play in initially setting a baseline. What is your performance today? Where are things working? Where are some fundamental challenges? What regions, plants, and categories are going to be problematic issues that need to be resolved through the transformation? So you set a baseline of the data, of the process, as it works today. Then there's a really important piece of shaping and understanding of what you're doing today, what the system will allow you to do tomorrow, and then engaging the business to define that future way of working. Ideally, limiting customization to those really important areas, making sure you're not redesigning a wheel, you use what's out of the box, what the system can offer you, make sure you're not creating something that's already covered by standard functionality, keeping that development cost and tech debt down. And there's a really powerful element here of actually getting the business engaged and shaping that future way of working, signing off on the future state process. And then using that to drive your requirements, using that to shape what you're going to be customizing, shaping for your organization specifically, driven by the process rather than driven by a shopping list coming off the top of people's heads in the business.
Kumar Dattatreyan: Yeah, that makes sense. And that is a massive piece in enabling change management at the backend as well, of course. And I suppose that you want to iterate through these requirements or these business processes, right? And so an agile way of implementing something like this would make sense. Do you see resistance in implementing big systems like this BPM systems into using agile and how have you responded to it?
Liam O'Neill: Yeah, so with these big programs, sometimes with the major ones, there's still a lot of organizations that work in a waterfall way for the major ERP program. You know, fine. But a lot of the work we do is in the optimization post go live, where you've got it live the system, they've managed that horrible jump from ECC to S/4HANA, and the business hasn't broken. Yeah, a bit bruised. It's not broken. But we're not seeing the ROI they expected. You had a vision for an automated future, a fantastic new system that's really going to carry you forward. And I think that's really the space of those agile improvement cycles. And using data to, again, prioritize what you need to focus on fixing. It's not about the most painful pieces, but the bit that's damaging the business the most. Where are the most problematic issues in the environment? And then using data to shape that, find those main problems, and then using an Agile cycle to begin to shape and deliver improvements on those and doing that continuously. It's not okay to go live with a system once and then not touch it for fifteen years. You need to do that continuous engagement in shaping and improving that way of working. So definitely that optimization piece is a massive role for Agile. Some of my clients are now doing the blended Agile delivery, but it smells very much like waterfall to me sometimes in that ERP implementation. Much more about the optimization space where it's really valuable.
Kumar Dattatreyan: No, that makes a lot of sense. One of my clients is going through an SAP S/4HANA implementation and it's it's it's this this is the struggle. It's trying to get all the requirements and of course, the very waterfall and this part of the organization is anyway, they don't see how agile can help. So It's enlightening. It's sort of refreshing to hear your take on it. So hopefully someone from there is listening as we are speaking about this. All right. Let's see here. Yeah. I mean, just one other note on that. One of the interesting things we're trialing with one of our clients right now is we're really struggling to get agreement on the requirements. Yeah. So we're not going to get agreement on requirements. We're going to sign off. The business is going to sign off the target way of working, the target process. All the important information gets locked in the process, and then they never see the requirements. That's managed by the solution architect's client side. So the business is really happy they've shaped a way of working. They don't need to get into the detail of a specific detailed user story, a specific technical requirement, whatever that is. Instead, all that's managed by the solution architect. All that they need to do is sign off, this is the way we want to work. And so far it's, we've seen good results from that really good business engagement. It's cut out a lot of the challenges we were having in terms of getting people to engage in a productive way, instead of just saying, we want to copy what we're doing today.
Kumar Dattatreyan: Yeah. Makes sense. Makes sense. All right. So I want to focus maybe on you a little bit, right? So you've grown your company quite a lot in the last couple of years, thirty-five percent year over year by focusing on upskilling rather than creating dependencies. You know, in your industry, it's usually multi-year engagements. Right. So how do you balance rapid value delivery with sustainable business growth?
Liam O'Neill: Yeah. And historically, what we've done a lot of work with is setting up BPM teams and implementing tools like Signavio and getting them going. But those have been those teams that operate in a little silo. And they've done good jobs in supporting audits and supporting with onboarding and those little point projects. But it's not been that grand ambition to go and support major transformation, deliver real results. And one of the things we're really promoting with the companies we work with now is to, from the get-go, not have BPM be a small piece of the puzzle. Instead, have it to be a tool that brings together all the change makers in the organization, enterprise architects, data intelligence, PMO, agile teams, continuous improvement, change management. All of those teams are trying to change your business, move it forward in a positive way. And sometimes you'll kind of operate like loggerheads. So what we're doing with organizations now is when we start working with them, we'll build that BPM capability, but right away, try to integrate it with all the other change makers so they can pull together effectively. And from the get go, we said, let's do a program that's actually going to deliver results for the business. It's not okay to go in and model some processes, build a dashboard, because that's not useful. Choose a problem and solve it. Get an ISO audit passed. Take a problematic process, recruitment, or order to cash, whatever it may be, and fix it. Not just define a future state process, but carry it all the way through to having that realized future way of working. So that you move from these small, twenty, thirty thousand UK pound implementations, which don't have long-term value to the business, to bigger programs, which are creating much more value for the business, just by carrying it through all those different capabilities, all those different change makers, through to an actual result.
Kumar Dattatreyan: So using BPM as a wedge into the business, right? So you're taking a process and sort of using it as a way to bring the people that work around that process together and implement the change. And that way you're sort of changing the organization one little process at a time. It seems very disruptive. And it seems like sort of like a very Kaizen way of changing an organization. Small changes, but built up over time, it can yield a significant change overall. So pretty, pretty interesting. So looking ahead with AI and Gen AI engines becoming more prevalent, some are questioning whether we still need traditional process modeling. What's your take? How does BPM evolve to include AI into its tool chest, I suppose?
Liam O'Neill: Yeah, there's a lot of similarities with the automation wave of a few years ago. I think AI is going to be much more disruptive. It's got a lot more long-term potential, but there's some similar implications and requirements that emerge in the enterprise space as what we saw when RPA came to the fore. And it's an opportunity to dive in. Some companies just jump straight in and start shaping up these workflows using Zapier, N8N, whatever it may be, and building those agentic bots. And that's fine. You might solve a point problem. But I think you've got to understand the broad enterprise context. What is the overarching end-to-end process? Where across that do we have that biggest capability gap where we need to move forward to keep up with markets, keep up with demand to be strategic, and then prioritize those areas for where you start to develop these innovation solutions. And then when you do actually get to it, you need to understand the business context around it. You can't just have an AI agent sitting in a silo doing all the work on its own. That's not going to be effective. What it needs to be is support. It's a team member. It's an accelerator. It works in conjunction with your team. So you need to know what the handover is to it, who's going to be using that outcome, who's going to be working with it, monitoring what comes from it, and then bringing that back into the business. So understanding the business process, understanding the way you used to do it, being really clear on where you need to prioritize to bring it in, and understanding the way you're going to be using it moving forward becomes more critical than ever. And one of the things I've been playing about with a little bit, I don't know, have you heard of the system Lovable at all?
Kumar Dattatreyan: No. No.
Liam O'Neill: So it's my current little hobby. It's ChatGPT, but you give it prompts and it builds your system.
Kumar Dattatreyan: Oh, interesting.
Liam O'Neill: Yeah, I thought it sounded too good to be true. And maybe enterprise scalability isn't quite there yet. It's very good for building a little proof of concept. But if you feed it requirements, it can start to shape up that system for you. What I've been playing with is feeding it target state processes and seeing if it can build a solution based on that. And whilst I don't think it's quite there yet, the technology, it can do a really good job of starting to form what those systems can look like. And this space is evolving so quickly that give it a few years, I'm sure this is where a lot of AI enabled development is going to be, where it's about giving natural language requirements, understanding your business, process how you want to work, feeding that in, and then using that to build and adopt a new system moving forwards.
Kumar Dattatreyan: That sounds really interesting. You just say it was called Lovable?
Liam O'Neill: Lovable, yeah.
Kumar Dattatreyan: Okay, I'll have to check it out. I use a lot of different AI tools, but I hadn't heard of that one yet. Very cool. Well, what have I not asked you, Liam, specifically about BPMD and sort of some of the things that you have experienced over the past few years in the industry?
Liam O'Neill: Yeah. I think you've covered a lot of ground. It's been a good conversation.
Kumar Dattatreyan: Yeah. I'd like to maybe switch to a couple of personal questions just about you and, you know, if you're okay with that.
Liam O'Neill: Yeah, absolutely. Fire away.
Kumar Dattatreyan: All right. Favourite beverage, coffee, tea or something else?
Liam O'Neill: Tea. It has to be tea.
Kumar Dattatreyan: Tea, like cream tea with scones and, you know, clotted cream and all that good stuff or just, you know,
Liam O'Neill: No, it's, we call it builder's tea. You got a teabag, you dunk it in until it's a murky brown, splash of milk and you're done.
Kumar Dattatreyan: Wow. Beautiful. All right. So I, from our prior conversation, I understand you used to play rugby. And so my question is what requires better strategy: reading the field in rugby or reading organizational dynamics in consulting?
Liam O'Neill: Well, I was what's called a prop forward, which is the fat child who runs in a straight line and gets tackled by the other fat children. So not much strategy went into my position. So I think I'll have to go with organizational dynamics.
Kumar Dattatreyan: All right. Sounds good. So you've had quite the year last year, right? You became the company director. You got engaged. You had your first child. Congratulations for that. You bought a house all while taking over during COVID, so I guess the last few years. What's the most important lesson that intense period taught you about leadership under pressure?
Liam O'Neill: I think the biggest lesson for me is to slow down. When there's a difficult challenge, a difficult proposition, something that's going to be stretching and pushing you, you don't go with a snap answer. You have to collect the information, be aware of what's going on, talk to people you respect, get their input, and then use that to shape your opinion. Your gut can be really helpful, but sometimes slowing down and just taking in all those other environmental factors help me make such a better long-term decision.
Kumar Dattatreyan: Yeah, I like that. Absolutely. All right. You kind of covered this, but I'm curious what you might say. In thirty seconds or less, will AI make business process consultants obsolete or more valuable, and why?
Liam O'Neill: In the short to mid-term, more valuable. In the long term, maybe obsolete. In the short to mid-term, we need understanding of business and enterprise to be able to embed AI effectively. In the long term, I think there's just this crazy potential that we have no idea what the future of working is going to be. So to say something's going to be obsolete or not obsolete, I think at the moment it's all best guess.
Kumar Dattatreyan: Yeah, yeah, it makes sense. All right. Well, we are about out of time, so I'm going to call it an end here. It's been really a pleasure having you on the show, Liam. It sounds like you're doing really well with the business, and hopefully the viewers of this show got some value out of it. And how can they reach you if they have questions about business process management, about sort of implementing the ideas that you've talked about here?
Liam O'Neill: So if you have any questions whatsoever about process management, if you've got a team and you're looking to bring them into the modern age, if it's something you're new and exploring, just reach out. More than happy to talk you through that. The best way to reach me is on LinkedIn. I'm quite active on there, posting a couple of times a week. So that's Liam O'Neill and the company's BPMD if you are searching for us.
Kumar Dattatreyan: All right. Sounds great. Well, thanks again. And look forward to having you on again. Maybe we can dive deeper into one aspect of what we talked about.
Liam O'Neill: Thanks so much, Kumar. It's been an absolute pleasure. Cheers.
Kumar Dattatreyan: All right. Take care. Bye-bye.
