Process Mapping Yourself Away From Organisational Complexity and Chaos with Michael Schank

Startups. If successful, they grow really fast. But most don't realize or accept the fact that what they scaling is chaos. Unclear workflows, half-used tools, decisions made on guesswork. And now in 2025, we all layering AI on top of that chaos. So what happens when you automate processes you don't really fully understand? Hey, what's going on everyone? I'm Mike Serias and this is Mastering Tech Growth. Every week we chat with industry leaders to bring you no-fluff tips on how to grow. If you enjoyed the show, make sure to subscribe and send me your biggest growth questions at masteringtechgrowth.com. I love to know what you're working on and what keeps you up at night. Joining me today is Michael Schunk. He's the founder of Process Inventory Advisors and the author of Digital Transformation Success book. I highly recommend the book if you're interested in the topic we're discussing here today. It goes into much, much more depth. For over 2 decades, Michael helped companies clean up the way they work so they can grow without the chaos. Today, he's going to walk us through his process inventory framework and break down simple steps most startups skip as a result creating messes they don't really realize they are creating, and explain how small bits of waste within the processes can actually have huge impact on growth. Welcome, Michael.

Thanks for having me, Mike.

It's going to be an awesome one and it's such a timely one, Michael, for me personally. So I'm launching a course or just helping businesses with Agentic AI, right? And one of the steps which I feel businesses don't really think well is that you need to really understand your processes first before you actually go into automation, right? So they instantly jump in it and they not even think about automation right now. Everyone's just like, let's just put AI, agentic AI. I heard great things. It's just going to solve all my problems. So it's a very, very timely episode, right? So I want to start with this. Quote from McKinsey: 70% of digital transformations fail, often due to lack of clarity in internal processes. So to kick us off, Michael, very simple question: how do you even start with that? Like, I'm a business owner, right? Like, how do I make sure I map this well?

So it's, uh, so I love that quote. I haven't heard that before. I've used the 70% before, but I didn't, I didn't hear the second part. That's brilliant. So, really what process inventory is, is identifying and documenting every single process your organization does. And how do you do that? You start with the top of your organizational hierarchy because you want to be complete and comprehensive in this inventory to capture everything, not just core processes, because any process can have impact on performance. But you start at the top of the organizational hierarchy and you ask a simple question. What is it that you do? And the leaders will say, I have a team that does this, that, and the other thing. Well, then you go down to their teams, you ask them what they do, and you keep walking that organizational hierarchy down until you get to individual processes. And then you go back up and you ask people to, uh, to attest to it via a formal email or some, some other electronic form so that everyone says yes, this is an accurate and complete representation of what we do. And that creates a taxonomy that represents everything that your business does. There's another aspect of it, which is data too. So there is a lot of data in our organizations in various unconnected data stores, like what systems do we use, what risks do we have, what vendors do we leverage, etc. So if you could take that data now and associate it with individual processes, you start to build a comprehensive repository of all operational intelligence from which you could drive transformation, automation, organizational performance, a whole host of things.

Okay, so you mentioned core processes, but we should map not only them but others. So is there a way to think about processes or label them in, in some unique way, like, you know, core main and then sub-items or something like that.

Sure, but I start with the, the inventory of complete first, and then you could put a tag of, of core processes, and you could define what that means, but they're typically customer-facing, revenue-generating things like that. And, and I do think they should get a good amount of attention, but it's the— it's, you know, sometimes the bureaucratic processes that slow things down. And you can't miss those.

So that's where I was actually going. So you mentioned you start at the top and you sort of go through the core processes and then you go within the teams, you ask them as well. Who does that? Is that like a dedicated, you know, head of process type of role or situation? Or is that more like a, I don't know, CEO or like operations person? Like who would actually run this?

Well, it depends on the size of the organization. For larger organizations, they may have a dedicated call it process capability or process center of excellence, where there's a number of people that are, that are, that are responsible for constructing this and then maintaining it. Because a big question I always get is, but my organization changes all the time. Yeah, that's fair. That's true. So you need a team that has some governance processes that, that every so often goes back out to the business and says, what has changed? Let's re— let's update this, get all the attestations again. But for smaller organizations, it could be a person or two that is, you know, this is just their part-time job, but they, they take on this, this responsibility, almost like an initiative or something. It's like an initiative or something. Exactly right. Um, the, the, the other key way to, to— so it's a, it's a process capability. The other key way to maintain it is to integrate it in, in every way that you run your business. So from how— if, if you have all your processes laid out, it can help you define strategy. By understanding what are strong, what are strong areas of your business, what are weak areas of your business externally, where are there opportunities and threats in the landscape so that strategic leaders are identifying where they put their finite change dollars to in an objective way.

Okay.

It can enable a transformation and the change process in general by being very clear on what processes need to change, And with all the data alignment I mentioned, once you identify the process, you know what technology is involved, what people are involved, what vendors. So now you can be very precise in what has to change, and that maintains alignment from the leaders that are saying, this is what we need to do, to those on the ground that are actually implementing the change. Operational excellence. So using this as a platform for identifying where there's waste and inefficiencies, not just at a process level, but at a 30,000-foot view level where you have redundant technologies or redundant teams where you have opportunities for streamlining or standardization or consolidation in something like a shared service or even an outsourced partner. Enterprise architects. So I think if you give technology folks more details about what the business does, then they could be clear in the IT strategies they define, how they govern technology, and they can anticipate the needs of the business so that you're not stuck in this this, this conflict between the business wants it now and IT's like, but that's not the right way to do it, which is always inevitable. And then last is risk and compliance management. So if you understand all your, your processes, you could identify what could go wrong and what the regulators are saying you need to comply with from a legal perspective.

That's a lot. That's a big map, Michael, right? Like, I'm just thinking about the size of organizations and I work for enterprises and when I think about all things we do has a lot of information. So how do you manage all of that? Are we talking about dedicated softwares to map out the processes, or is it just purely some type of like workflow type of tool where you just, you know, have, uh, buckets of processes and, you know, some arrows goes from this to that? Or is it more sophisticated than this?

There's— technology is definitely part of it depending on how big and ambitious you go with this. Um, there are process mapping tools out there like AERIS, GB Tech, Signavio. The— there's a lot out there, and the good news is it's a fairly mature market with, with really, okay, really great capabilities. Um, but that's one thing is just documenting your environment, and then you could add workflow on top of that as well, because once you know your processes, now you could start to draw connections. Um, you know, what is the end-to-end process, and where does one process hand off to the next? From the view of a value stream or a customer from a customer journey perspective.

Okay.

But you could do it with spreadsheets and Visio as well, you know, depending on what you're trying. In terms of your first part of your question though, is it doesn't have to be daunting. You know, you said you work for large enterprises. You could start with just one part of your business that maybe has some pain points or some strategic objectives they're trying to hit. Yep. And then do that one area and then demonstrate some success, take the story to leadership, and then grow it from there. And you don't need all the use cases that I mentioned. You could start with one. It's really just start small and then grow as the organization needs.

Okay, I love that. So you mentioned value stream, and I was sort of waiting a good moment to ask, so I feel like that's the moment, Michael. So the only real process mapping theory and practice I know, which is called value stream mapping, right? And it's really a big exercise, right? So our CTO in the enterprise I work for really loved that. So we did that a couple of times and it's just, it's a big thing, right? So we would come for about like 3-day workshops, right? So it would be 3 days in a row and you definitely need to have key decision makers within certain process verticals because they know the data which comes in, they know the data comes out, they know the lead times, how much they wait on, you know, dependencies and things like that. They know the process item times, so they can only give those answers. So it becomes like very expensive by its nature because, you know, you have all of these decision makers in a room for like 3 days. And then if you're trying to map a huge value stream, let's say, you know, you're going from, well, here's, uh, something we want, like, uh, go to new market, and then here's our service in those market. Like, that's a huge huge area to cover as a value stream. So it becomes basically a very, very big exercise. And then what it yields is a lot of information, you know, it's like hundreds— well, not hundreds, but probably tens of initiatives to sort of make all of that better, right? So you just mentioned a very good point, right? If you are team lead or you're some type of, you know, manager, or maybe even not, if you see some issues or you feel like you're having some issues, you can just map your process without without understanding what the value stream map is, right? It's just a general sort of situation where you come in and you ask the team, how do we do this? Which leads to the question, Michael, like, how do you— like, what questions do you ask? Like, let's say I want to do this. Like, I go to my team right now, how do I start this?

So I always start with do your homework, because I don't want to ever come in— because if I'm, if I'm doing this interview process, I don't want to come in with a blank sheet of paper because I don't think it's valuable for the stakeholders' time.

Right.

So I gather whatever, whatever information I can, whether it's org charts or other internal documents, and create a draft of it. And then when I, when I have the meeting, I lay it out in front of them and say, is this what you do? Or tell me, tell me what gaps or what I've gotten wrong, etc. And they say, change this, add this, whatever it may be. But then that's a very, very quick process. And, and I just want to draw one distinction. What I'm talking about is organizationally based processes. So I'm just tackling one organization or one team or or whatever that may be, how it ties to value streams, or value streams are end-to-end and they can cut across organizational units. So one group does one thing, they hand it off to another group. And but once— what I, what I typically see is, is people that do the value streams can't then drive it down to the lowest level of detail of what it— what a specific person does, what specific technology does.

Yeah.

So once you have this inventory, now you could lay out the stages of your end-to-end value stream and now plot what specific organizational processes do what. And that's a good way to get that high-level view of end-to-end, but then also drive it down to the, the lowest level detail if you have to do root cause analysis or, or solutioning.

Do I need to be part of that team to actually do this well? I'm just thinking from a perspective, how do I know that I finished going as deep as I should be to actually map out the process, you know what I mean? Like, if I'm talking with someone and let's say I'm not that domain expert of whatever that team does, I don't even know when I should stop going deeper in the sense of understanding a full process, right?

Yeah.

So I should be sort of like part of the team to do this well?

Uh, no, you could, you could do it. When I've, when I've done this with clients, I've done it in a federated manner. So businesses could do that do this themselves. So it doesn't have to be just the central team, but, but a central team's needed to define standards because everything— different organizations that, that create this, it all has to look and feel the same so that you could read a process inventory for any group without kind of having a decoder ring. So things like verb noun. So every process should be named with the action because that's what a process is. So, you know, submit payment or open account, whatever it may be.

Yep.

And then, and then I do want to draw one distinction to the difference between just process names and process models. In my view, just the names alone is really valuable, and, and that could be a quick thing to do because you're just asking people what they do. You're, you're listing the processes, and then you could come back later and say, okay, which ones do you need to know more about? And then dive into the the details.

Okay, I get that. What is, um, when you do this exercise, Michael, what is one thing in your experience, because you did that many, many times, like, does anything comes out in your mind when I ask what the people get most surprised about when they actually do this exercise?

Um, I don't know about surprise, but I think they're the most appreciative about just the transparency. Just like they get to see everything that their organization does and who does it and the resources that are leveraged. So I've had, you know, I've done this for organizations and years later they've called me and said, man, we're still using this. It's like really important and valuable thing. And I think there's, and we could talk about alignment, but I think that's one of the reasons why transformations fail is because of the chaos and alignment. And I think that there's a couple parts of that. There's vertical alignment. So from strategic leaders down to individual contributors, making sure that everyone is doing, you know, acting in accordance with what the strategic objectives are. And then there's horizontal. So having kind of peer teams that know how to work with each other better. So that's business working with technology, et cetera. And it's my assertion, and I've seen this many times, that like leadership doesn't really know what people do on their team that are, if they get, 3 or so levels down from their hierarchy, and they don't get the true story because they get a story that's crafted for them. But having this, this map laid out, they could go down to the details and understand, oh, there's a problem in a certain area, you know, inquire the team which is the specific process. And if they want to roll up their sleeves and get in the details, now they have the, the, the map to be able to do it.

Yeah, I love that. Um, I've been on the receiving end of both of these. Um, one thing which I For me personally, when I did my first value stream map, which surprised me most, and I feel like I've seen that a couple of times at least, when people realize the impact of lead time for some of the process items. When you are within the process, you just like, oh, we need to wait for this. Okay, well, okay, let's think something else we can do in the meantime. You don't like tangibly really understand the impact it has on the whole value stream. Because it's all downstream process, right? And then when you put it on paper, like 14 days, you know, like the stakeholders see that and they go like, well, that's not acceptable. And suddenly now they see that, right? Then suddenly now they can resolve that, that situation. And having that map is just so powerful. So I love it.

Oh yeah, I mean, it goes back to Lean Six Sigma principles, like overproduction in one step of the process that causes, uh, you know, buildup in the next step is— it's, it's wasteful. So Looking at the entire thing and understanding where the bottlenecks are gets you that streamlined end-to-end process, which, which could have a big impact on how you produce stuff and how you serve your customers and, and really having that outside-in view and inside-out view so that you could really streamline everything.

So how do you go about identifying waste within business processes? Is that simply do the exercise and see what the numbers are, or are there more like specific maybe questions or insights you can share about, particularly about identifying waste within the processes?

Well, I think if you look at a process inventory, you could start to see like, oh, like I see a bunch of things that are happening here, but I don't see a lot of value from it. And I see a lot of people. So you could just look at it. There's, there's other methods too. Like when I do a process inventory, since I'm capturing individual processes in each organization, I map it to a business capability model or a standard process model like APQC. But then because that gives me the thesaurus to my dictionary, so each individual process is the dictionary, but now I get to see like processes across different areas and I get to see like technology and other resources. And, you know, I was working with one client that had a, for instance, a centralized procurement group, but they gave a lot of their line of businesses latitude to do their own procurement. So you could have procurements in a number of different areas, and that obviously is not only more money spent, but that there's more risks of, you know, straying outside of procurement policies, etc. So now you could look at the entire organization and say, why do we do this thing in all these different groups? Like, does that make sense, or should we consolidate? So there's a number of different techniques, but what this does is gives you a map of the organization to analyze it from multiple different angles.

Things you're saying, Michael, and, you know, I'm getting like images. It's almost like, you know, it's coming back screaming at me, you know, the type of situation where I know within our businesses there's so many areas where we have inefficiencies simply because there's a big handover. But I think there's as well overlap of teams doing the same things. And when I think about why we're not doing this better, and we did value stream mapping and we have people sitting looking at processes, we don't have dedicated process excellence type of people, but everybody cares about being efficient. And one thing which comes out is that we don't really have enough time to concentrate to drive these process excellence type of situations. So my question would be, Is the conclusion I'm getting right now in my head is that without having dedicated people, you're unlikely going to be successful with this?

Um, you know, I wouldn't necessarily say it has to be a full-time role, but it has to be somebody that carries this, this responsibility. So it could be a, you know, depending on the size of your organization, you know, you, you started the conversation with, with startups, and if you're 10 or 15 people or person organization, you're not going to have a you know, 5-person team dedicated to this. But you could, you could identify somebody who does it kind of maybe on the side, and it doesn't have to be a big effort, but just having this map of what your organization does is, is really critical. And, and, um, you know, when it comes to startups too, you know, there's a natural evolution, and startups typically are focused initially on growth and revenue and building things.

Yeah.

Um, but there comes a point in time where, where margin really starts to matter. And that's where you have to look internally and saying, are we being the most efficient with what we're trying to accomplish? And having all these resources identified where you could align cost and other metrics really gives you the ability to think about how you're designing the organization and how it operates, as opposed to in many cases, things just evolve.

Yeah, which is reality for majority, to be honest. Yeah. This is such a rare situation when I meet founders of fairly successful startups where you can talk about processes and automation and they go like, yeah, you know, here you go, Mike, we have all of these maps and we already did the exercises. It's always very chaotic. It's almost like it's Wild Wild West. They just, there's a constant element of firefighting mixed with some type of strategic growth. It just feels like it's a nature of startup, right? That lack of maturity within those processes. So you talked a little bit about alignment, Michael. So I want to throw in that Harvard Business Review quote. "Misalignment between teams is a leading cause of strategic failure, often stemming from unclear processes and handoffs between the teams." So my question would be, Can you give us a picture of how, how work looks like? Maybe it's utopian picture, but how, how does the work looks like and how does the result looks like when you actually have aligned teams?

Yeah, so, so I think one of the, you know, Harvard doesn't, um, uh, mention this, but I think a lot of the root cause is lack of language. And if you've ever seen the famous tree swing cartoon, which which I use all the time in presentations, but it says this is what the customer wanted, this is what the product—

yeah, yeah, I do remember that one.

Yeah, that whole thing.

Yeah.

And, and it's because we all have different perspectives, and, and probably the biggest one is business and technology. Like, they speak different languages, so the level of communication of how they work is going to be different. But if you give them, you know, if you give them a process inventory, which essentially becomes a language, and now the business could say, I want this process as process updated with these requirements. Now the technology person can say, I know what technology it uses, you know, depending on level of depth, I know the APIs, what, what system logic is invoked, etc. Now you get clear communications between them. And I'm a big advocate for when you run a change project, you should scope your projects, i.e., project charter, by what processes are involved. Do requirements by each— what is the requirements for each process? Do your design, do your testing, because you should test each process, whether it's directly changing or being impacted, and do all your organizational change management. So create your procedures aligned to process, your training, your job aids. So that's one thing. And then I think the other thing is just being transparent about what people do. So, you know, we've all been in a situation where the team down the hall or another building, we kind of know what they do, but we don't know in detail. So we don't exactly know how to interact with them and how to leverage them. But if you make, if you create this process inventory and make it transparent to everyone, you say, I know exactly what they do and I know how I need to leverage them better.

You just gave me an idea. I'm going to go to some of the teams within the business and I'm going to be like, hey, I need to know how you guys work. We're going to do a process inventory right now because you mentioned the leverage and a couple of things popped in my head where my lack of understanding how they do things, I filled it with some probably biased opinions about what they do, which was wrong. Which led to not the best decisions. So this is a very, very strong statement we're making that as a team lead or a manager, if you really want to— if you work in big enterprises and you want to understand better how teams deliver value for the business, you could probably just walk in there and go, hey guys, do you have process inventory? And they might go like, no. And you can go like, well, let me help you to create this. There's a bunch of value to you and as well me at the same time.

Exactly. It's all about transparency and understanding.

Okay. Yeah, I do love that. All right, so, um, so I was saying that the execution of speed or efficiency is literally gained from the fact that we talk the same language, and that language effectively becomes our process inventory. And because we know how you work, you know how I work, by default we can expect some speed gains.

Yep.

Okay, it's just simple.

Oh, for sure, for sure. Yeah, because, because there's, you know, when you're working with a new team, there's a lot of feeling out and negotiating, etc. But if you can understand exactly everything that they do, you're like, hey, I need— can you do this thing that you do already? Or maybe they're, they're not doing something and say, hey, can you add a new process because here's a new need?

So, um, so I was just advocating over here to basically for every team to have their own process inventory and have it almost like Hey, if you wanna know how we produce value to the business, check this page out.

Yeah.

And it just becomes almost like a cultural health exercise to advocate as a, you know, as a business owner, as a CEO for the whole business.

Yeah. I think there's another angle to this too, which I think is important, which is the employees. So I'm big on accountability. And when you do this process inventory, I not only detail out every process, but I identify a named owner within the organization who's not only responsible for improving the process but executing on a day-to-day, um, uh, basis. The, um, and there's a lot of different innovation models that are coming out, like open innovation, where you use external sources like customers and the general public, etc. But then there's democratic innovation where you recognize that every employee has some level of expertise in what they do. And if you could tap into that, and now you could drive innovation in every process or product or everything, everything that, that you do within your environment. And that's— and you need two things to make that happen. You need accountability, which I think process inventory does at a detailed level, because if everyone's responsible for something, no one's responsible. But also, if you— if leadership could build a culture of of autonomy where they are encouraged to test new ideas, where there's an understanding that not everything will work, but we will reward the initiative. Then now everyone becomes an engine of innovation. And one of the things you need to do is you need to arm them with data and information. And that's what process inventory provides because now they get an entire understanding of the landscape, upstream downstream processes and how they could streamline things, uh, just to make the overall environment better.

I love that. I love that so much, Michael. Just so, so much ideas in my head right now. I almost forgetting all my questions. Well, you mentioned this, which I really love, and I don't know if that's your quote or someone else said it. You said if, if someone's responsible for it no one is responsible for it.

Exactly.

And I feel like this is Aiman, you know, that, that should be like something put on the wall because yeah, if someone doesn't own an item, no one's, no one's like have time or willingness to just go like, yeah, you know, I'll take that. It just becomes something which sits around everyone but no one really owns it. And if no one owns that process item, that means it's just gonna be bottleneck by default. Right?

Exactly. Okay, exactly. And, and, you know, it'll— it won't receive the attention. It may happen fast, sometimes it may be slow. And then leadership can't really put the metrics on it of what they care about in terms of success and health, etc. So it becomes really important.

Okay. So one thing which I've seen happen multiple times is that, okay, We have a workflow, we're doing something within the business. And when I say we have a workflow, we don't have a process inventory. We just, we just have something of how we produce value. Business wants more efficiency and they go in, we're going to buy this tool. And whatever is the tool, let's call it Tool X, you know, for sales, maybe it's like Salesforce. For some product people, maybe it's like Miro or some prototyping, Jira, Atlassian, you know, for project management, many, many tools. Like these are almost gospels. Like we know they exist, we all use it every day, but then you have a little bit smaller tools and someone goes on some type of like conference or event, you know, gets sold on it. They're like, boom, it's going to solve our problems, right? That happens a lot. And I want to read this quote from TechCrunch. Startup waste an average of 30% of SaaS spend, often due to unclear workflows or poor implementations. Which leads to this question, Michael, is like when you have a messy work processes, you don't really understand fully because you have not mapped that. What really happens when you're layering in tech on top of that?

Well, when you're purchasing new tools, the, you know, there's many questions you should ask, but one is what is it going to do for me? And if you can map it to what specific processes it's going to enable, then that, that gives clarity not only for the, the enterprise architecture team to design the architecture, but just to have clarity on what it does. But another question should be, do we already have this functionality in some other tool? Like, you know, especially for larger organizations, you know, you'll see one organization buy a tool where another, another organization already has it, when the natural question is, why can't you just use that? And if you don't if you don't have an understanding of what all the businesses have or what they do and what they leverage, then you're gonna miss a lot of those things. And ultimately the implications are that of that is a complex environment, which leads to lack of agility. So now it takes so much longer to implement a relatively easy change because you have so much complexity within the environment. And then it also means higher costs. That you have to carry on the bottom line.

Why is it still happening, Michael? It's like, I could give you a couple of examples which I know from very, very big businesses in e-commerce space, and then in my own space where the tools are being given. This decision has been made and the tool is being given to implement. And then you are on the receiving end. You are effectively, you know, a manager, a team lead, to receive the tool which is supposed to make your teams and everyone downstream life better. And then you go like, no one really asked me about the value this tool will give to me. I'm just being handed that. Like, why, why this is still happening like today?

Well, that's, it's a great, it's a great point because, because organizations have to do the work to really detail out what they do. And if you, now in the case you mentioned where someone's proposing a new tool, I would map it to the processes, not then before I even purchased it, map it to the process, build a business case, et cetera. But I would talk to each of those individual process owners and get their feedback. Like, how would you leverage this? Like, would this make your life better? And really before you even sign the contract to purchase it, now you have a good understanding of, if people are supportive, if, you know, the benefits it's gonna bring, et cetera.

That's no-brainer, like, to me, Michael. Like, I would go like, that's exactly what I would do. But at the same time, I can see things being differently and all done being differently. And I always ask this question, is this, are the sales teams so, so good of these tools that they just managed to convince the leadership just to buy it and just, don't worry about it, it's just gonna be excellent. We'll come in, we'll teach everyone over there. I don't know what they say, like, why, why do stakeholders buy into really expensive tools without really mapping the processes and having a chat with the teams?

And I'll give you, I'll give you another scenario which I, which I think is related to it, is I worked at one, one bank and they outsourced their mortgage servicing to a third-party provider, but it took, it ended up in years of just mess and chaos. And, and I think it really could have been solved up front if you would have mapped out for instance, every single mortgage servicing process and, and start to identify what's the metrics for each, SLAs, etc., and then put that up front in the contract. And there's regulatory obligations that they have to comply with, etc. But if they put that up front in the contract and now get the, the vendor to sign off, and these are the expectations and these are the financial penalties if you fail to perform, that, that whole mess I think would have gone away right up front. So you went and they dealt with that for 3 to 5 years or something like that. So, um, and that impacted ultimately their customers, which, which they had a lot of complaints. So yeah, you know, and now there's a lot of uses for this. Yeah.

And no one during that 3 to 5 years raised the question, should we just map the process? So yeah, just people.

So, and that's, you know, people, and you know, that's something I get all the time. Well, this is, it seems like a lot of work. Sure, yeah, but I always look at it, you're going to pay for your chaos. So you either pay for it upfront with an investment just to really just get organized, get your house in order, or you're going to pay for it down, down the road with 70% of transformations fail and the budget implications and timeline implications and the lack of functionality and the, the defects and the impact the customers— like, the— you really have to weigh, you know, every decision is not without a cost. And without doing something like this, you're you're most likely going to pay the cost.

Yeah, I mean, ultimately, a good running business will know really, really well what the process of their— of them producing value to the market is, and they will, they will know that so well that they, they will be able to make it a lot more efficient, either by automation or some other means, to get the margins better. And that you, you see that all the time. And as well, right now, in this, uh, almost like a gig economy, I want to call it, where you have domain experts, you know, offering knowledge and skills in a sense of like courses. If you go to talk with them, they all will have their processes of how they will help you, and, and that, that's going to be their secret formula. They will give you that process so you can take it and sort of implement, understand and implement, right? So ultimately everything ends up being a well-oiled process.

Yep.

Yeah, I love that.

That's how it should be for every organization, but unfortunately that's not the case.

That's not the case. Which is a very important question, is like, does the, you know, leadership, business ownership, uh, uh, boards, you know, do they not aware of it, or is it just a pure lack of, of, uh, knowledge, or they know but they go like, you know what, I think I can do better without the processes?

Well, one of the things I think, and I think it's a fault of the process management community, to be honest with you, is that I don't think that there's been a comprehensive way of how to do this. And I think a lot of, you know, when you think about an organization, they talk about people, process, technology. So if you ask any leader, is process important? 9 times out of 10, they're going to say, of course.

Yeah.

But I think in their experiences, you know, they've been involved in some process team that, you know, did some stuff but really didn't have an impact on the organization. So it's, you know, their perspective is, yeah, but it never really works out. And, and I've seen a lot of organizations, and, you know, I've worked in financial services and banking specifically, and, and, you know, mapping of risks and regulatory is, is huge. And they've started these massive programs but without a vision for how to do this, like, down to the detail. Like, how do you run these teams? How do you do governance? How do you create the models? How do you connect them together. There's a lot of things to answer in there, uh, and without that, that, um, that vision, then, you know, many of these things fail to deliver the value that they're expecting. And that's why I wrote the book, is because I, I think there's a gap in, in the conventional thinking for process management. And I've— and what I, what I lay out in my book is all the details for how to do this successfully at scale.

I love it. It's a great book. Again, People should buy it and go into it. I mean, we will not do the justice in the 60 minutes of this episode when it comes to the book. If you're really excited about the topic and the value it can bring, yeah, second shout, go get the book. So let's imagine now, Michael, that we are in a space with our business where we map the processes. Maybe we are small to medium enterprises, so we don't have that many of them, but let's say it's in the tens, right? So 10, 15, maybe 20. We have the maps, we know how things work, we know how Team A works, we know how Team B works. So we have that map, and the question someone asks right now is like, okay, well, how do I get efficiency within this? And the very first thing which comes to my mind is automation, of course. So how do you know which areas are ripe for automation?

Yep. So I have a friend who works at an automation consulting company, and his point, I think it's right, is that process discovery is probably the biggest value that can be added because a lot of organizations, they'll maybe do surveys of what processes to automate, but how do you know that that is indeed the right process? But if you could lay it out in a structured map, now you could say, okay, of all these processes, and you could put it to leadership, which ones are the biggest pain points? Which ones keep you up at night? Objectively, which ones have the, the worst metrics relative to what we're trying to— the value that we're trying to deliver? Now, now when you have that, now you could say— now you could rank them based on priority, and you're putting your automation dollars to what's really important. But then also, now you give the automation teams a wealth of information, because a lot of automation efforts have to start with current state analysis, like what is this thing, what does it connect to, etc. Now I'm leapfrogging that whole thing because I'm arming them with this information so they, they could take weeks or months or whatever it takes to do that current state analysis and jump right to solutioning because they have all the data at their fingertips.

So we're thinking effectively from the perspective of return on investment, right? So because we have the processes done, so our process inventory is there, We're choosing effectively the biggest pain points, the biggest value to our customers or to the market production, because we're going to be spending money with automation. So we just want to automate the processes which at the end of the day result back in, say, more revenue. And that's how we're making the choice. So it's just a pure return of investment, time investment versus how much value we're going to get back.

Exactly.

Okay. Is there any, um, Quality too.

I would think there's some level of quality and risk management involved with automation as well.

100%. So where I was going, trying to collect my thoughts, is that managing automation is a job by itself, right? So the more complex automation workflows you create, the more likely you'll need to sort of look at this all the time, right? And And that leads to sort of like a follow-up question. Is there a thing in Pattern where you go like, you know what, I wouldn't automate this because of just pure complexity or something like that?

Oh, sure, absolutely. Um, yeah, there's a lot of complex processes out there that absolutely can be automated, and that could mean less people. And we talked about quality. There's a lot of different reasons, but having that full map gives you all the details you need to choose what are the right processes.

Okay, right. So let's put AI into all of this.

I was waiting for that.

So let's just put some AI into it. So we have the maps, we have chosen our biggest pain points or biggest value production. So we have the workflows which we want to automate now, and some of these workflows require some decision-making, right? So, so this is what effectively AI agents or agentic automation is enabling at this point in time, is that within those workflows, instead of having these binary sort of situations, we can actually put in some LLMs, train them on, on particular areas of our business, and they will be able to make these decisions and, and automate these, well, fairly complex workflows, right? It's great. Sounds good on paper. In reality is actually a little bit, you know, a little bit more complicated. And the question and the quote I want to read is from MIT Sloan, which basically goes like this: AI delivers the biggest benefits when built on structured and consistent operational data, right? Otherwise, it amplifies inconsistencies. And the question is, how do you prepare or how do you gather your data so you can actually leverage that well?

Yeah, so it goes to— so I think process inventory is the anchor for it. The, um, so, and I mentioned, so once you have your process inventory, now you could collect all data about how you run your business and align it to a specific process. So a process uses, um, you know, a certain sales force or whatnot, and it has these people and it leverages these vendors and it it has these risks and controls, etc. But essentially what you're building is, is an entire kind of repository for how things work. And, and really it gets into, uh, digital twin. Um, so I don't know if you've heard of the concept of digital twin, but it's creating a model of your organization. Well, it, it got big in manufacturing and physical components. So there's smart factories out there, and what they do is they create a model of their factory or engine part or or whatever it may be, and they're using that to train AI on, on how things work. But in its— in the instance of a factory, now you have station 1 does this, station 2 does this, station 3 does this. Now AI knows exactly what's happening there, and they could put IoT sensors or any other kind of data collection feeds in it. Yep. And, and send that in, and now AI can understand, you know, can do analysis on that, do predictive analytics, do simulations, do data -driven decision-making, really help you with everything. So if you— but that hasn't translated into information-based businesses. So I came from financial services, there's nothing physical because people could be in any building, any part of the world, etc. So I think, I really think the anchor point for creating a digital twin is document your process, align the data, use that to train AI, and now start feeding data signals into that digital twin platform. So your defects, your customer complaints, your issues, your process mining data, your task mining data, whatever it is, now it all can be associated with what process it's describing, and now you could have insights into everything. But now that's where it gets into agentic AI as well. Is now— and, and I could think of a scenario, for instance, where I speak into my phone, I say, I want to add this functionality to my website. And in a multi-agentic AI environment, you have one AI that's just doing impact analysis. So it looks into this repository of information, it says, okay, what processes exist? What are they asking for? What's, what's needed? Um, what technology does this go on? What's the impact across the board, it hands it to another Agentic AI that goes into the source code repository, identifies what code needs to be created, um, develops the code, throws it to another one that puts it in your CI/CD pipeline where you do the code deployment, automatic testing, creates all your documentation. And then, you know, the, the user's coming in, you know, in a matter of hours or whatever it takes, and they're testing the new functionality. So that could take your development time from, you know, or deployment time for change from months to a matter of days or weeks. But I could think of a ton of scenarios: automated risk assessments, doing project planning for a large transformation where you get down, you know, if you feed in an estimating model, it could get down to how much time per each team and what's the duration, etc. So I think there's some really exciting stuff, but what you're doing here is now you're, you're training AI on what your business does and you're giving it that common language so it could resolve all, you know, any, any conflicts of information.

How realistic is that you can actually do this as a small to medium business, just cost-wise, you know, creation-wise, management of these agentic workflows?

Yeah, I, I would, I would think about it first of you don't necessarily have to do it for your entire enterprise. But there could be key areas where this is important, and you'll have to weigh the cost of doing it versus the value. But I could think of a lot of business areas that could certainly leverage this.

So is there like a readiness checklist you would think about, Michael, sort of going like, look, this is— first of all, we do the process, right? You know, do the process inventory, have the processes mapped out. Then second is identify your areas which are great for automation, which we talked about. So we have that as well. And now it's a question of like, okay, well, which of these are actually ready for Agentic AI? Which leads to this question, you know, are we actually capturing enough data to be even able to extract the value of such automation?

Yeah, I would, if I was an organization, I would do a test scenario first just to try it out. And I would focus on an area that is probably high cost in terms of number of resources, but it's not necessarily a lot of value where you could shift those, you know, because, well, AI is going to have an impact on, on people. I mean, I think we all know that, but you know, you could shift those people from manual and mundane and repetitive tasks and move them to customer-facing and value creation tasks and just generally get more value from your, your company as, as a whole.

How you say move, you mean replace them effectively with AI, agentic AI, so to get that function done and move them into something else. That's what we're saying.

Yeah, I mean, replace them. I would shift them to somewhere else in the organization that is more thought leadership and higher cognitive and higher value.

Okay, so yeah, that's— I mean, it's taking place even right now. It's just the acceleration of all the technologies. it's scary by itself. If you are in the market and you're seeing how, uh, Agentic AI moving, uh, it's just so easy to see that happening, uh, you know, fairly quickly, to be honest. So that being said though, there is an element of shiny AI object type of situation where everything is just AI now. Uh, you know, people want to buy tools. Someone mentions AI and problem solving, they like, yeah, here's, you know, take my money. So if I'm a business owner, how do I just not buy into that hype? Like, can I have some, I don't know, red flags or green flag type of situation where I can take my decision through a certain prism and go like, you know what, without something, I'm not going to be able to leverage that tool?

Yeah, I think there's the— there's, um, you have to think about what you're trying to get from it, um, and, and really think about the value and build the business case. Uh, I think you said it before, the key to AI is data. So if you give it garbage data that's confusing, overlapping, conflicting, then you're not really going to, going to get value out of it that, that you anticipate. So I think you— and then I think there's the, the practical data security of a lot of organizations are worried about their data, their proprietary data getting out to the environment. So there's a lot of things you have to look at. Um, but, but I do think Pandora's box has been opened and it is coming. And I've been skeptical about a lot of other technology advancements. Um, in, in some ways I think everything has value, but I think the hype didn't match up to the value that it actually provided. I think AI can, you know, I'm buying into the hype of, of what it can be. I mean, obviously there's going to be overstatements or whatnot, but But yeah, it's going to be a game changer in terms of how organizations operate.

Yeah, I buy into that as well. I mean, I do Agendiq AI by default, so I can see how everything is advancing. And we've been in a state of, you know, just sort of generative AI just giving us outputs where they all looked cool, you know, videos and audios and the text. We were really lacking decision-making and actioning. And, you know, with the GenAI where you can build the workflows which makes call for you and actions elements and you combine that into your complex workflows, that's basically replacing a role. You know, that's a proper digital employee. Like if you set it up and has been done in, you know, multiple big businesses, there's some very great use cases coming from, you know, Fortune 500 companies. So yeah, it's happening.

There's also value in modeling leveraging AI. So I talked about the, um, the interview process, uh, etc., and all the data alignment. Um, and I'm maybe a little bit biased because I spent a lot of my time in financial services and banking, but if you scan the, the headlines, you see a new bank getting hit with a regulatory fine or some consent order, etc. So they always struggle with, especially in industries where there's just a sea of regulation.

Yeah.

Um, what what do they have to do? And those regulations are essentially requirements on processes of what I have to do per what some certain law or regulator says. And if I have— and I've been doing this, and I think it's, it's like, it's, it's mind-boggling how, how efficient it is— but if I give it, AI, a list of processes and tell me what are my regulatory obligations and give you the risk statement and control statement, it gives me all of it. And, and now I've taken something that takes teams of people with first line of defense, second line of defense, third line defense, etc. And now I could, I could understand all the regulations for each process. Now I could give that to the, the process owner and the development team so that they could identify what controls are needed and implement those controls. But it could really change the game in terms of how I communicate with regulators, because a lot of these regulatory actions are not because of the big things that you see in the headlines. A lot of it is— and I was talking to a regular regulatory expert yesterday— it's when regulators come in and do an exam and they find out that you don't really have control of the situation, that you're making it up as you go along. So having clarity, um, uh, is important. And I think process inventory combined with AI helping you do all this mapping is, is, uh, is, is one good, uh, case study. Another thing is I was, I was Once I have an inventory of processes with the descriptions or whatnot, I could create requirements documents using AI, I could create test scripts using AI, I could create procedure documents. Really, alignment doesn't just go through the people, but it's all the, uh, knowledge. So if you align all knowledge, uh, to, to a process, and you know, you're going to go back and forth with people, you got to adjust these, etc., but now you could have a standard body of knowledge all aligned to process, which is incredibly valuable. And AI could be a big help for you creating that.

So you mentioned regulators, Michael, and I work for a regulated market as well, and we deal with regulators within every new market we enter. And one thing which is holding us back to fully utilizing AI is the hallucination element of it, right? So there's a real fear that we would take what they say give it as an answer. And then if they, you know, if AI hallucinated, the liability will sit with us, right? So you mentioned the use cases around financial markets, which again, it's very similar use case. What if, what if you're getting a, you know, a wrong answer?

Yeah, well, and I like to point out there's been some cases in the US, legal cases, where the lawyers used AI to find other cases to support their their arguments.

Yeah.

And the judge looks at it and says, um, all these citations don't exist.

Yeah.

Which is embarrassing for the, for the lawyer. And you get— I'm sure they got into a lot of trouble. It's, you know, I, I was at a conference and there was a someone that was talking about AI, and he said, think of it as your, your assistant. And if you hired an assistant today and he gave you a bunch of stuff, you wouldn't blindly pass it on to wherever you're passing on to, you would do some, some checks. And I think you still, you still have to check, you still have to validate, and maybe over time you could build trust. But I think you as the person and the owner of that task still have to take responsibility for what's in there. So this regulatory mapping that I mentioned, I would use it as a starting point. Um, you know, organizations in highly regulated environments have compliance teams and have legal teams that can double-check on it. Yeah, but, but it gives you a big leg up by giving that starting point. Maybe it's 80% complete, which is a huge value add from starting from a blank sheet of paper.

Yeah, trust but verify.

Exactly, exactly.

All right, let's go into rapid questions, Michael. So question, uh, quick, quick answer. We got about 10 which I want to squeeze in. Uh, perfect. What's a quick way to identify bottlenecks in the workflow?

Uh, just align the resources and understand, um, align resources and the metrics. So what metrics are slowing things down and where is it?

What metric do I care about when it comes to bottleneck? Is it just like the whole area being slow in the sense of like days, or am I looking— there's 5 people doing this, it should be just 1, or lead times? Like any specific sort of KPIs around bottlenecks?

Every process has its own context, so it really depends. But, okay, you know, it could be throughput time, it could be SLAs and responding, it could be cost and number of resources. If I have a lot of resources but things are really slow, then that's something to dig into.

All right. How do you ensure everyone follows a new process? So effectively, you looked at something, you mapped it out, it's poor, we improved it. How do we police this now into reality?

Oh, that's a, that's a good question. I think it's, um, it's a responsibility. So when I define ownership out of a process, I also— because process inventory structured, it's a taxonomy, and every node in that taxonomy has, has ownership, which means you don't just own your process. Your boss has some level of ownership, and their boss has some level of ownership. So I think it still comes down to local. Like, you— if you could define the metrics for every process now I could hold you accountable for hitting those metrics, but then your, your leadership is responsible and their leadership is responsible. So I think it still comes down to good management, but they're aided by more transparency.

Okay, clarity. I get you. Yeah, I do agree. You have to lead by example. I mean, yeah, it needs to come from the top. Uh, can a process be too complex, and what signs are there for complex being for process being too complex.

Oh sure, if you have a lot, um, so well, there's a, um, and I'm getting the name wrong, but, uh, Parkinson's theory, um, or I, I forgot exactly what it is, but it was a British naval, uh, historian who was studying the British Navy and the growth of the bureaucracy over time. And what he found is there's a period of decades where there was less wars and less need for ships, but the growth in the bureaucracy kept going up. So, and, and what that really states is that people like to have people report to them, and they like to have people to— so if you give people, and they, they advocate for budget, and they could get that budget without any kind of objective analysis from their, from their, their leadership. Um, so you could have areas where there's a lot of fat and overhead in terms of number of people doing things that aren't value-added. And I think that's the biggest reason why there's complexity. So I've been in some areas where, you know, you do the process inventory and you're like, you really don't do anything. And it's, it's really becomes a situation where the checker is checking the checker who checks the checker.

It's funny because it's true, but yeah, I've seen that so many times. Right. How do you maintain process compliance across distributed teams? And maybe that's the wrong word I'm using, compliance, but effectively when you have a handoff between the teams, this is where I see a lot of processes sort of, you know, breaking down. It's like, how do you make sure that that handoff is done in such a way that, you know, we have an efficient and healthy process?

Well, once you identify all the processes, you could identify what's the upstream downstream process. And now you can focus on what is the procedure for handoff, what's the, what's the SLA time, what's the, the format of whatever you're handing off, what's the quality expectations. You could really dig down into what you're expecting in that handoff. And, and now that level of insight gives you more visibility to, to be able to manage it.

Okay, so it's almost like APIs in a way, but it's Teams. But then we have an agreement, a contract of like what data I'm giving out and you tell me in what format you want to receive it and that just becomes our handover type of contract.

If I'm giving you a status report, here's my expectations for what's in it and the format and who reviewed it and you could layer on all that.

Okay. So we think that the feedback around these things when it comes to people doing the process items are critical then. Like we have to constantly be asking the question, is this working? Can this be better? How do you need your data? And similar questions. I don't see that happening that often. And I'm thinking now, am I doing this? Probably not. Yeah. I'm guilty on—

And the beauty of it is a lot of organizations will have a dedicated process re-engineering team or Lean Six Sigma or whatever they call it. But now if you make all the data transparent, you, and you make the accountability very strong, then now you're distributing it across everybody. Everybody should be looking at why is this working this way? How can I make it better?

Yeah. So it's such a simple question to ask, to be honest. And there's so much value in it. And I'm like, okay, why am I doing this? And it just comes back to just being busy. It's just like, just too busy to care about this, which is not good, right? You need to take a step back, zoom out. And, and really look at your process. I— yep, there's something I'm going to take from this episode. So thanks, Michael. Um, right, so, uh, scaling challenges, right? So I've seen this picture where, where startups raise money and, and, you know, the, the things just change like next day, right? Like one day they were like 40 people, they just raised money, 3 months later they're like 200, right? So that speed of growth really It's like, it's, you know, it's fun and it's great and it's a success story, but at the same time, it's very painful to get that business back into shape and operating through process and stuff. Like, how do you manage that change? Like, do you have any advice for founders?

I have a story. So I worked with, in my consulting capacity, where there was a spinoff from a global insurance company to another smaller US-based company because they just didn't think it was core to their business. And they went through that exact— so think of it as it's a startup with billions of dollars in assets and insurance assets. But, you know, one of the first things they did is they need— we need staff. So they just began, began just hiring, you know, tens, 50, 100 people, etc., but really didn't put a lot of thought in what they were going to do. So there's a lot of people running around with like chickens with their heads cut off. We're like, what are we doing?

Yeah.

And that wasted months and weeks and— or months and lots of dollars, etc., where it would be better just to lay out like, what is it that we have to do? Um, just— and that could be done in a matter of weeks by just a couple people. And then now assign specifically, we're hiring this person to do this thing. And you could, you could avoid, um, all that chaos up front.

So simple. So simple. When you think about it, I mean, in practice, I'm sure it's more difficult, but, you know, on paper and conversationally, it just seems so simple. But at the same time, people trip over this very often. What you just mentioned, Michael, do you align this like, do you start with the business goal? So effectively, you set business goal like a big vision, what we're going to be doing, what we're going after in the next like 3 years or 5 years. And from that point on, you just lay out the process and, and you go like, you know, here's how we're gonna sort of go after it. Is that like a good assumption, or is it more of like, let's do a process inventory, see how we're actually doing this, and then, and then put some OKRs on top of that?

If I'm starting with a, like, a startup type, type situation, yeah, you know what your products are. So I need to develop widgets, so I need to, to have a team that creates widgets. I know I need to sell the widgets, so I need people that, you know, can, can prospect clients and build a sales pitch and close deals, etc. I know I need internal, uh, stuff, like I need a finance team to keep, keep track of where the money is, etc., right? So I would start with those big buckets, like what are all the things we need, and then I would just keep going down those buckets and saying, you know, what, what's the next level and what's the next level until I get all the processes And if you're in a startup, you're not going to necessarily nail that, but that gives you an idea of everything you need that you could iterate on as you hire people, as you do things, as you see what works, what doesn't. And then it gives you the basis for being more intentional in how you grow.

I love that. Very, very healthy recipe of how to look at, at that point in time. All right, well, that was excellent, Michael. So many So many things you shared where my brain just escaped my body for a couple of seconds where I was just imagining situations in life and just thinking about like, okay, there's multiple things I could do better. So I grew from this episode. So thanks for that. And I'm sure our listeners did. If they want to learn more about your book, you, and, you know, other things you're doing, where can they find you? How can they get in touch with you? Get in touch with you?

Yeah, so first, the book is Digital Transformation Success. You can find it on Amazon. Yeah, so if you liked what we talked about, there's a lot of details in there. Um, LinkedIn, I post a lot about some of these concepts, um, so reach out to me and have a discussion. And, and I'll say this too, a lot of what I talk about is very theoretical maybe, or may come across it because people can't connect with it. I have created reference models that detail out this, so if anyone's really interested to see what it looks like, please reach out to me. And then I do my own consulting, so processinventory.com if you want to learn about my services or reach out to have a discussion.

Excellent. Okay, so we have a book, we have your LinkedIn, and we have your business URL. So all of that will be in the show. You guys tuning in live, of course, you know, you'll need to wait, but once that goes up, it will be in the show notes. Otherwise, put Michael Chunk in LinkedIn and you will find his name. And if, I mean, if you're listening live, you probably already, you know, have a link. Just click on it. Go, go have a chat. And for everyone having a value in the episode, make sure to subscribe. And if you have a friend which you believe right now is drowning in chaos, do share this episode with him or her. They will find value in this. And as always, guys, until the next time, stay safe and see you online.