Start with the Problem, Not the Methodology with Prem Krishna

Description: 

In this episode, Sam Lewis speaks with Prem Krishna, Global BPM Transformation Leader at IKEA. Prem's career has taken him from software development and management consulting in India, through operational excellence and supply chain leadership roles at Johnson & Johnson, to leading business process transformation in one of the world's most recognised brands. 

What makes Prem's perspective particularly interesting is that he does not see himself primarily as a process professional. He sees himself as a problem solver. Throughout his career, he has worked across industries including manufacturing, chemicals, pharmaceuticals, supply chain and retail, applying the same fundamental principle: understand the problem before choosing the solution. 

This is a practical and thought-provoking conversation about process, governance, continuous improvement and why organisations often focus on the wrong things when trying to solve business challenges. 

They discuss: 

• Why Prem sees himself as a problem solver rather than a process professional, and how that mindset has helped him work across industries from manufacturing and pharmaceuticals to retail and supply chain 
• The danger of starting with methodologies such as Lean Six Sigma, Agile, process mining or AI before fully understanding the problem you are trying to solve 
• Why organisations often blame process when the real issues are governance, ownership, decision-making and unclear responsibilities 
• The lessons he learned improving manufacturing operations, and how data, observation and systems thinking help uncover what is really happening on the shop floor 
• The difference between improving physical production processes and digital workflows, and why process mining has become such a powerful tool for understanding how work actually gets done 
• How he helped build a five-year cost reduction strategy at Johnson & Johnson, and why winning stakeholder support one conversation at a time is often the key to successful transformation 
• How AI is changing the way organisations operate, why it should be treated as a tool rather than a strategy, and what happens when you apply AI to a process that is already chaotic 

If you work in process management, transformation, operational excellence or enterprise change, this episode offers a refreshingly pragmatic perspective on how to solve problems, improve performance and create lasting results. 

Host: Sam Lewis, Director at bpmd 

Guest: Prem Krishna, Global BPM Transformation Leader at IKEA 

Transcript

0:01

Welcome to Working Process. We are Lemo Neil and some of the code deleted. You are accountable for improving how their organization actually works. If you need protests, automation, IT, enter architecture, data or operations, and you are accountable for turning strategy into execution. Across the organizations we work with, we get a lot of investment in teams and tools and programs and different software. You get dashboards built, processes model, programs launched, that doesn't always translate into real bits of tokens, into bottom line results, into something you can point your finger at and say, yeah, that's work. If you do a series about building a structured, data-led and outcome-focused approach to change, we're glad you're here. This is Work in Process. If you get any value from this episode, please subscribe. You will get a brand new episode before anyone else. The views and opinions of our guests are their own and do not represent those of the company. Hello and welcome to this episode of the Work in Process podcast. Today, we are really, really grateful to be joined by Pram Krishna, who is the global business process and capability development and business transformation leader at IKEA. He has had a really interesting career ranging from lean Six Sigma projects to large-scale five-year plans at Johnson ⁇ Johnson plants to drive operational efficiency. He has super interesting views on AI and where it's going. And he really likes to take the approach of limiting his jargon and bring some fantastic analogies for those who want to understand a little bit more about the process transformation world. I hope you enjoy the show. Pram, thank you very much for coming on the podcast. We're really pleased to have you with your extensive experience across a number of different organizations and the lots of different techniques in and around process transformation. Where I'd like to kick things off is given that you've started your career as a management consultant in India, doing operational excellence at Axo Noble, supply chain, lean six sigma at Johnson Johnson, and now your global BPM transformation at IKEA, how do you make sense of that journey when you look back at it? The way at least I see my journey is more like I'm a problem solver. So irrespective of the type of industry, irrespective of the type of role which I was playing, I try to understand the problem and then try to break that problem into again using lean six sigma approach, or like what is the root cause of the problem, how can I tackle those root causes to solve that particular problem. And then after solving, how I can sustain the result so that when no one is looking, process will still work and make things efficient and effective. And do you think looking at it from a problem-solving perspective has given you an edge a little bit rather than being too focused on the approach, the way the technique and stuff? Yeah, for me, first of all, I need to understand the problem myself. So whenever I try to or hear any problem, I try to understand why it is a problem for that particular individual, for which all the stakeholders are facing problem. Then I try to break the problem into more step-by-step approach because a problem could be, yeah, someone might be facing a problem, but other might still be seeing some kind of benefit. So why it is a problem for one kind of a stakeholder, but it's still not a problem for someone else. And then try to break it down into pieces like, oh, don't try to solve for everyone. Let's focus on what is the key problem uh faced by one set of individuals, and then what is the root cause of it, how I can tackle it. If I'm tackling it, is it going to impact someone else? Is it making it worse for the overall system? And then we always talk about system thinking. So not focusing on only one dimension, but if I'm bringing something, what all additional benefit it can bring to other parts of the organization? So is it making the overall organization better or worse? So that is something which always helped me. It is more like you can say Lego bricks. So you might be having a small, small, small Lego bricks. I will give it to you in front of you, and then I will say put it together. Different people will put it together in so many different ways. And everyone has some uniqueness to it, everyone has some advantage to it. If I will see five or six ways, I will be able to take advantage from each one of them and make it better. So instead of just focusing on one and creating and breaking and doing something else, how I can look into all the five or six things which people are doing and make it better. Yeah, we actually do that as an exercise in some of our team days where everybody has a little pack of Lego, and you just sort of take away any instructions, just let everyone build from the same amount of bricks. In general, like a lot of time in Sigma training, we used to also ask people, oh, draw pig. So different people used to draw pig in different ways, someone like looking from the horizontal or from the front, someone looking from the side, someone making pig so big, someone is making so small. But then we start giving instruction. Oh, this is what we would like you to draw. Make it more clear. And then when we start giving instruction, it is also making the problem statement clear for all the individual. And then after certain clarity on those problems statements, even without looking at each other's work, they are able to build a pick or create a pick which is similar looking. Yeah. Do you have any examples maybe of where you think in your career maybe the organization hasn't really kind of forgotten what problem it was trying to solve? Yeah, I can tell you an example. So a long time back, I was talking with a site manager of a manufacturing site, and he was very enthusiastic for Lean and Six Sigma program. And he came to me that Prim, I am going to support you. I want 10 black belt projects and five green belt projects and some more training around this kind of thing. I'm like, as a site director or a site manager, if you can give me the objective which you would like to reach, then I can help you better. Because I don't want after a year that his trust will be lost on me and people who are delivering those projects, right? So I was like, if you set the goal, then we will choose whether we will go and look into lean aspect, look into agile aspect, look into Six Sigma aspect, or we are going to do a normal project management lifecycle. So it will be helpful if we create a problem statement which have a very clear objectives, what you like to achieve, very clear what risk we see, so that I can help in solving that. When we are talking right now in a process world, almost every organization I have been to, irrespective of how much documentation they have, they say that we don't have a good enough process or our process is not working. But the main problem is not the process not working. Main problem is somewhere governance is a problem. So they are not able to take effective and efficient decisions in their governance. Some places people don't know where to find different things, what is their roles and responsibilities, and how their responsibility is going to deliver certain things to some other person. So those things are not clear. Then some other places there's a digitalization happening. So we are also looking into what is the process, how we are going to convert this process into a digital expect and workflow so that our system can follow. But people are just coming and saying that the process is not working. Process not working for two different individuals could be totally different. Yeah, very true, actually. I mean, it's quite an easy thing to blame as being the problem, but ultimately that means the business isn't working, right? In that section that the process represents. You hold Master in Black Belt in Lead Six Sigma, you have an MBA from Copenhagen Business School, a TOGAF Enterprise Architecture Qualification, you also have certifications in Signavio and process mining. So you have a lot of tools to choose from when you're trying to solve a problem. Could you explain maybe what a few of those things are? And then also which ones do you see as the most relevant today? And are any of them maybe not as relevant as they used to be? I think for me it is all these are the skill sets which help me in solving my day-to-day problem in my roles. And when I go and work with my stakeholder, I try to still focus on what are the values they would like to obtain. And then depending on that value part, I think about what tool sets I know and how I can utilize those knowledge and tool sets. For example, if I talk about MBA, in MBA, I got a chance to interact with people coming from finance, coming from operations, coming from marketing, so many different perspectives, right? So when you talk about problem, sometimes we become very narrow focused and look into how I'm going to save some cost and money and make things more efficient. But how it is going to impact in our sales, how it is going to impact in our culture and values, how it is going to impact in terms of transparency in the organization. So we sometimes forget because we become so narrowed in our problem solving approach. So that is something which I use on a day-to-day basis whenever I'm going and solving something around any of the problem. When I talk about lean and six sigma, irrespective of I'm running a Six Sigma or Lean project or not, but that taught me how to break the problem. Okay. So whenever there is a problem, I try to figure out how big the problem is, where I would like to be, what actually good looks like, so that I can measure from A to B. And then I try to figure out what are the root causes. Because as I told you earlier on the process, process itself is not a problem. But sometimes people say, oh, I don't like process, or process is making things more bureaucratic. I try to understand why it is making or creating certain problems for them. I try to understand what is the root cause for that. Maybe we are emphasizing our documentation of certain things, which is not necessary and which is also not the need of the organization. So figuring that out is very important, and that's something which I am using lean and Six Sigma. Then a lot of people are right now focusing on agile, for example. And I was talking with one person the other day. Again, in which kind of scenario can we use a normal software development lifecycle versus an agile scenario. If let's say you're working on a space station project where you need to launch a satellite to the orbit, you're not going to launch an agile project that, oh, let's launch the satellite and then we keep on fixing the bug on the go, right? So that is also the thing we need to understand. You need to develop your skill set and then use that skill set in different environments. All those things have been important and crucial for my journey. It is not one thing which is better than other. It is depending on the scenario, depending on the value which I am trying to drive, I might be using different skill set. And that's where I emphasize a lot on skill development. So when in general management is telling, they should not tell the solution that, oh, go use agile, go give me process mining. They need to understand what they are missing, what value they would like to drive, and then let the capability area develop those things with the help of skills and knowledge which they have from their own skill, plus also looking outside what other companies and organizations are doing. Yeah, you don't lead with the technology or the tool, lead with the problem and then go from there. Because ultimately, I suppose the business, do you find they don't care how you're going to do it in general? They just want to know that the problem will be solved. Many of the time, as soon as you see a problem, you already know this is what how I'm going to solve this particular problem, right? So that is uh also something coming as a human behavior part. And if someone is telling you something else, you start with a rejection before actually started looking and accepting it, right? So from that point of view, you don't tell the problem, you sometimes uh tell the solution that this is what I want you to solve me. And then you're not giving that person who you consider as a subject matter expert the full freedom and creativity to identify what else could be possible. So you're also restricting your mindset that this is the only thing which I need rather than go explore what is the best possible scenario. And you are the expert. Yeah, that makes sense. And something that I personally would find interesting, and I'm so I'm sure lost listeners would, is you are in the situation where you have really good understanding of lean six sigma and a black belt in a so, first of all, you know, when you're teaching people like the person in the factory that wants to be taught, how do you explain what that is in brief? In general, I try to avoid using any jargons. So, first of all, not everyone is a lean six sigma uh trained, right? So, oh, we are doing a defined stage, we are doing an improved stage, we are doing a measure. So I try to avoid that part. Then also, like some of the time people are like, oh, we are going to use fish bone because we need to do problem solving. Instead of that, just focusing on the simple words, how you can communicate with them, how they can actually understand and give them a chance to actually explain to you because they are the ones who are working on the factory day-to-day life. They understand what is going wrong. Maybe you can feed them with some information around data which you might have collected so that they can tell you why something went wrong on a particular day. I can give you an example. Actually, I was working in a manufacturing environment where we were having a quite fluctuation in terms of our productivity day by day. So instead of saying you need to work on this part or we need to make line more efficient, I was just showing them that your best day was on Thursday and you have reached to 20,000 units on that day, but on the next day, you reached only 14,000. And then just by showing this small data, they were able to tell what happened wrong on that day. Then they might say, Oh, we were having a shift change or we were having a line cleanup or something like that. Then you say, let's break it down into hourly. So during that eight hours of production of 20,000 units, they might be producing some hours, uh, 2,000, some hours, 3,000, some hours, 500. So what went wrong and what went good in those hours? We were not having a stoppage every hour, right? So breaking that down helps them in identifying what might have helped during the day. And I really like the concept of stand-up meetings and even in production environment where we keep on checking those things. Let's analyze that day itself rather than waiting one month down the line so that we can have the good practices and all the lessons learned from that day, list it down, figure out what actions we would like to take, and take those actions in the coming days. And when we've spoken previously, I asked you about the difference between more corporate sort of shared service processes, procurement, order management, and the contrast between focusing on improving those versus manufacturing production processes. And you mentioned that it's almost easier for the production stuff or the benefit of looking at production if it may be a little bit easier. So in those stand-up meetings, is that when maybe people were reviewing footage looking at where things have gone wrong? Yes, and that is also the thing. Like when we were doing analysis of production line, we heard, oh, this is the problem. Next day, we recorded some of those problems because we are running those production lines almost every day. Maybe the problem came or did not arise and those kind of things, but at least we were able to figure out that how either good looks like or what could have gone wrong. Then in production environment, as I already told you earlier, we can see product flowing. So you can see a raw material, raw material converted into some in-between product and then converted into a finished good. So you can see the flow. Sometimes it is also good that you look into backward flow because not all the raw material and in-between products which you are making is a value added. But the one which is at the end is the value added. So that is the most important one. So let's look to make that particular product, what all the steps are required. So it is always good maybe to walk the shop floor together with people who are actually working on the shop floor so that they can analyze and tell you the insight why something is needed, why those byproducts are like kept in a certain way, because there might be some regulatory requirement, there might be some other things, which is also needed. But you need to maybe look into how you're going to prioritize certain steps or others. However, when you talk about shared services, you cannot walk the shuffle, right? So that is something which is maybe behind the systems. And that's where I feel process mining and insight helps a lot because we have plenty of data. And when we try to create a process in a BPMN diagram, many of the time it does not show the reality. And with the help of process mining, you know how long each steps take, where delay can occur, where rework happens, and all those kinds of insight which is not visible in BPMN diagram at itself. Yeah, and I suppose that process mining is almost like looking back at the production line, isn't it? Yeah. So obviously, process models, even process models in a corporate setting, probably aren't referred back to on a day-to-day basis as a piece of information. People like videos and people like chatbots and stuff to help them understand maybe what to do next if they're coming up to a scenario that the creation of a purchase or the creation of a sales. Have you seen maybe like process management tools like Signalvia have much of an impact on the manufacturing process? And have you ever seen much of a connection between maybe that process analysis and the Six Sigma lean, or has it always been quite different worlds? I think it is not quite different world because many of the time people who are running these kind of projects are not the ones who are working on the shop flow, right? And then we can use Signavio from value chain diagram to B payment diagram to process insight to all those things for different purposes. For me, the number doesn't uh matter at all. It is important those processes are relevant processes. So even if you have 10 processes in Signavio or any B payment tool, but those should be uh the one which you can trust on, right? Because a process is of no use if no one is actually looking at it and no one understands it and it is not solving anyone's problem, right? So that is very important. So I'm also an advocate of just enough process. We don't need to have a too much of process, uh, otherwise, you will not be able to manage. Because you need to keep on updating those processes, keep it relevant, keep it useful for you. It can help you in making the decision and all those kinds of things. Then when we talk about the manufacturing environment, maybe when you look into manufacturing on the Shaw floor, maybe SignalView process diagram and those things might not be relevant for you at that time because people at ShawFloor cannot understand BPM and notation, for example. So you need to make it simple. Either make a very simple flow diagram, but again, on that level, you would also like to tell, oh, this step takes this much time. And some of the time you might need to go in for more detail. You might need to also attach a video how that particular step could be performed. You might need to keep those workflow work instructions very close to the operators where they are. And many of the places you will not be having access of going to a laptop and looking into Signal View pictures and diagrams. So for me, yes, it is important that you're documenting in a place where you can manage, you can govern, you can keep your document relevant. But then you need to also maybe sometimes have a hard copy or have a video on a screen or something like that. When I have to analyze between different manufacturing lines and which line is creating more problem, of course, different lines have a different kind of a speed. So it is not like even if you're producing the same product on multiple lines, but one manufacturing line could be from 80s, second could be from 2000, and then they have a different generation. So they might be having a different speed altogether. So you cannot say that, oh, this is faster speed, so everything is good here. Maybe that is cost effective. That's why you are keeping it. So from that point of view, you can generate a lot of insight and information by collecting the data with the help of your tool. What has been the best peak time for that particular line? What is the highest capacity and how you are performing around that capacity? So if the line can produce 20,000 units per day, are you actually producing 20,000 or are you producing only 10,000? So you can then compare against its own performance, analyze with the help of mining tools that where you have opportunities and how you can work on that particular thing, and then you can monitor it later on whether whatever you have worked on is sustaining or not. So that is something where I see that still, because you can always go and take the subject matter expertise and knowledge from the operators and people, production engineer, and people working on the shop floor, but then you can go back and look into the data, whether you can rely on those advice and expertise and knowledge or not, or you need to trigger something else. Yeah, that makes sense. We've drifted a lot into techniques and also problems you've solved in the past. To go back to the foundations of your career, your time as sort of in management consulting in India. What did you learn in those years? What role were you playing? What types of organizations were you working with? I had a big in computer science. So I started as a software developer, but slowly because of my interest, I moved into process because I like to see the flow. I like to understand the bigger picture and how. My work is actually contributing to that picture. So that was very interesting for me. But when I started as a management consultant and I started giving advices and working with the companies across different kinds of domains from telecom, from manufacturing, chemical industry, and all those kinds of things, I felt a little bit discomfort because I was like, oh, I'm not the subject matter expert. I don't have the knowledge and I don't have the expertise. And that's where this problem-solving approach, and when you talk about lean six sigma approach and all those things, actually help me a lot because we are not producing a new product every day. That was created by RD people like maybe hundreds of years ago. And we are producing the same thing even right now. So it's not that we are producing a new product every day, but how we can produce that product most effectively and efficiently, that is where we need to work on. And sometimes being a very technical, go into ingredient and all those kinds of things and forget the flow part. How to make these things more cheaper and efficient so that more people can afford it at a cheaper price and all those kinds of things. So that is what I learned. Then I identified that, irrespective of industry, I need to maybe understand one industry very thoroughly, how it works. So, for example, if I talk about any city, how a city is designed. In a city, you will have a building, you will have a schools, you will have hospitals, you will have roads, you will have so many things, right? And then people are living. Their kids might be going to school, they might be going to their office and workplace. In case of urgency, they will go to the hospital. They need certain roads. Then on those roads, of course, they will be chaotic. People will keep on going in any direction and any place, and if there is no rules. So to have the rule, we need to some kind of uniformity across so that people can understand. It should not take forever to read this is a red sign, you know that what red sign means, and then you have to stop there. It should not take that I need to have a work instruction what to do when it is red, and what to do when it is green, and what to do when it is yellow, right? So I started trying to understand those problems. And then when I started looking into any of other organizations, I tried, okay, when we talk about process, process is more like a road. I need to make sure that people are running and flowing and moving. When you talk about any of the digital products or technology and all those aspects, it is more for me like the infrastructure. So you need cars, you need buses, you need trains and all those kinds of things to make sure that people are running and moving. Then you collect data that this junction has a lot of traffic. So I need to maybe create a flyover so that people don't need to stop at the junction if they are not turning. So you start thinking and analyzing the data and solving the problem, not for everyone. Maybe not everyone is facing the problem. Maybe only some people who have to go and cross the junction in a straight line or in a particular direction are facing the problem. So I need to build a flyover which will take them without stopping at a junction, right? So I started analyzing that. Then I started understanding the industry, breaking that, trying to relate with the industry or problem or place what I can relate to. Then I tried, oh, if I am doing this kind of solution in that kind of scenario, then how am I going to solve here? So that's how at least I see my journey from a technical person who doing coding and all those things, converted into process person working in a first starting with an IT industry, then worked as a management consultant for different kinds of industry, then try to solve a problem in a chemical industry. Where actually, when I first went, I was like, Steep, people are talking about viscosity, pH value, and all those kinds of things, which was like a big buzzword for me. And it was very difficult for me to understand. And I was like, do I need to go back to my school books and need to understand what these parameters are and how these are going to affect the product and all those kind of things. Yeah. And I suppose that's always the way people bash maybe consultants and management consultants is you don't have the SME knowledge. But the idea is that you're blending your own personal expertise with their SME knowledge. I suppose you realized in the end that you didn't need to actually know about the pH levels and the viscosity because they knew that and they could bring that piece, yeah. In terms of your role now, how far have you supported the S4 HANA transformation at IKEA and what have you learned from that? I have not supported that much in IKEA, but in general, I am talking about the way any of these big softwares like SAP is designed. This will create a kind of a discipline for your entire organization. But when you are trying to create this discipline, you're also changing your existing ways. And sometimes people are a little bit afraid of that. And I can again take a very practical example. It is like living in a house with a continuous renovation. So you saw someone's house, you saw that, oh, this is going to look good, but you need to still live in the same house where you have some other kind of a kitchen, other kind of a living area, and all those kinds of things. You thought I wanted to go towards uh this kind of a modular kitchen which will suffice my future needs. But while transition, maybe your family members might be complaining what you have looked, why you are changing it, or it is creating a lot of chaos. And then if you don't have a support or you are not fully in it, then you might stop the construction and it will never give you the uh result which you would like to get right. Same thing happens a lot with respect to S4 HANA. One thing which I really like around this S4 HANA implementation is how much they are focusing on standardizing the processes. When you talk about source to pay, when you talk about plan to fulfill, when you talk about idea to market, when you talk about finance, record to report, these are not unique things. And almost all the organizations are doing these things. They might be doing a little bit differently at a very, very granular level, but on top level, things are quite similar. That means you can also compare and benchmark against each other. You can see whether you are doing better on certain aspects than others or not. If you not learn from others, then I think it will be very difficult for you to survive because there's a lot of innovations which is happening, and you might not be able to innovate all those things only within your own organization. I keep on taking examples from DHL, for example. When you scan things, you are able to see where your product is right now, which was not the case uh maybe five, ten years back. Some of the organization did not adopt it, some of the logistic company, and when I was working as a supply chain manager, they did not adopt it in this kind of way. So, of course, customer is not happy because now that is not good to have, it is must to have nowadays. So, from that point of view, it is very important that you learn from what is happening around the world in those domains and how we can adopt it. Why DHL is able to do it? Because they are also pushing their customers to have a barcode on their product from the first place. If you'll not have a barcode, we will not be able to track it. When I was a supply chain manager at that time, that was a challenge because our product was not having a barcode at the end. And at that time, DHL was like, although you are our customers, but we will not take your product because it does not satisfy your criteria. Then that means that we will be shipping a product for which we are not able to track it and it will be difficult to monitor it, then I will not be able to provide you service which you expect from us. We took some time to transition from having a product which was not having a barcode to have a product which will have a barcode because we felt like maybe right now we can survive with this, but in a long term, we cannot survive without having that kind of uh basic technology in place. I suppose the bar moved, so it's no longer acceptable. Actually, if I ordered something and I couldn't track it, it would give me a lot of anxiety, right? And I'd be really worried about where the hell is it, you know. Uh that used to be the norm. You know, you just hope it turns up. Whereas now I can see, you know, what exactly what depot it's in at what time and where it came from. Yeah, that's very true. So I'm from a place quite close to Coventry in the United Kingdom, and in the UK, in Coventry, the IKEA is like one of the biggest landmarks, and that probably goes back to its destruction in the war, so it's not the prettiest city, but the IKEA building is like really glamorous and it's massive, and like people love going there for a sort of a day trip almost. Why do you think IKEA's got it so right in terms of sort of maybe its customer experience? Because it feels like there's a very clear process to the way in which you buy something from IKEA. You scan, you order, and then you might pick it up at the final checkout, and then right by where your car is parked, but they also do a really good job of walking you through everything that they sell before you get to the final point to pay. They must have done some process working and around that. Do you know anything about that or is it not? In general, of course, there's one part is innovation. You have a lot of good ideas where you innovate and figure the things out that what will work for our organization. But how to do that consistently across all the IKEA retailers. So when you talk about McDonald's, irrespective of you are in Germany or uh India or US, when you go and order, you at least in your mind you think that you will receive the product or food in less than a minute or a minute kind of a time frame. You don't expect to have the food in 30 minutes, right? So that is the thing. You might innovate something, but to deliver it consistently across, then you need some kind of process. Otherwise, it will become just by chance. You might be delivering one time in one minute and second time in one hour, right? To make it consistent, you need to have some kind of process, some kind of approach which can help you in delivering the same results all the time. And that's something which when I took example of manufacturing, when I took example of other places, I took these videos and these examples to them. That guys, it's not me, it's you who's delivering this good result in this time frame. And how we can support you to deliver the same or even better result almost all the time. I understand that there could be something which is totally out of control, which we cannot manage, but let's look into what we can manage. For example, when you talk about machine broke down, how we can make sure that we will have a maintenance in the right time so that machine will break down less number of times. I'm not saying that it is going to break zero time, but how we can reduce the stoppages, whatever we don't want to unnecessary stoppages and all those kind of things. Yeah, that makes sense. In terms of going back maybe to Johnson and Johnson, you worked on their five-year strategy, reduced costs of products by maybe 50%, and you presented its ship there. Was that a massive moment, a sort of a big milestone in your career? Did you feel? And how did that go? And how do you think you managed to connect, I suppose, the operational info to drive? Yeah, it is basically looking into where we are actually spending the cost. So we started with it, and at that time I was quite new in Johnson Johnson. So I was looking into all the cost figures and all those numbers. And again, I was not the expert. I was just walking through with different people who were subject matter experts. These are the costs. Okay, I see a big number. If we need to reduce 50%, then this number needs to be moved to something else. Maybe probably a lower number. What we can do about it. And then they might be having certain ideas. Oh, this part, let's say, for example, maintenance, we are putting too much for maintenance, but what about predictive maintenance rather than corrective maintenance? So figuring those things out was important. Then we also talked about their own ideas, looking into their own set of process, not only looking into the numbers, where we can reduce. For example, we were doing too much of testing. How we can reduce maybe sample-based testing rather than looking into all the batches, maybe skip one batch, skip two batches. If in last five years we are able to perform at a 90, 90 plus level, can we skip some of the batches? We don't need to test then all the batches. Then we were reducing the sample cost and we were reducing the time and effort required for testing and all those kinds of things. So we started brainstorming around a lot of these kinds of ideas. We put it into our, you can say, idea sheet, looked into cost versus benefit analysis. Then these are the ideas which we had based on the existing volume. Then we also started thinking about what if we will increase the volume but do not increase the operational cost, then how we can increase the volume? Can we create some other product which follow almost similar life cycle but can be used for some different purposes? That is another thing which we looked into. Can we sell some of the intermediate products which we were producing, which could be reused by someone else? For example, we might be throwing it in the garbage, but maybe those intermediate products could be used by some other manufacturing company nearby. So we looked into all those possibilities, figured those things out, then it comes to stakeholder management. When you present these kinds of things to so many people at the same time, their natural instinct again denial, oh no, this is not possible. If it would have been possible, we could have done it a long time back. So instead of that, we tried to convince one stakeholder at a time before actually going to that leadership meeting where all the stakeholders were there. So we started talking with each stakeholder, try to identify the ideas and thought which they were having around our sites, so what challenges they are facing, and seeing what is their perception of our site, and then showing some of the ideas which can help in changing that perception, and then adding some more ideas, which might not be related to their perception, but is like first try to build a trust by saying that yes, we agree with your idea, and these are the things which we are going to solve, which can help in resolving the concerns which you have around our side. But we also identified some additional opportunities which can help us. Then showing cost versus benefit analysis, simply like, okay, if we are going to do this, by this time we will be able to achieve certain things. So creating that kind of a we call glide path, like how we are going to move from here to where we would like to be in five years, then also showing that these are the opportunities is totally without spending any additional effort. But in case organizations see that there is an opportunity in this site and they trust our leadership of the site management, how we can look forward and invest more in the site. Because some of the investment, for example, I was talking about preventive versus corrective maintenance. What if we will change the line and produce at a faster pace? Because now we are talking about producing more volume instead of adding an extra shift in the line, how we can reduce that part with maybe having a faster line. Or the machine is 10 year or 15 years old, there's a lifetime of that machine. So some of the machines were quite old. How we can replace those machines over a period of time and gain some of the benefit because we are not getting rid of the product at we will be still producing the same product, but how we can make the process more efficient across. So that is something which we looked at. That's really interesting. Was this like a centrally run program? So maybe could you describe where you were located geographically at the time and what was sort of the teams really you were in? So at that time I was located in Sweden, in Uppsala, and uh Johnson Johnson acquired our plant at that time. And I really like the kind of leadership which they have because they were giving us the direction. So they gave us we would like to reduce product cost by 50%. So that was a clear statement for us. And then they consider as a subject matter expert who can solve that and identify the opportunities which we have and tell what kind of investment we need and all those kind of things. So then we went and worked on that particular part and all those kind of things. And then when we presented, they challenged us to foolproof our solutions. So they are not solving it for us, they were not telling us uh what we should be doing, but they were telling, oh, you might have forgot uh to calculate return on investment on all those kinds of things, and how this return on investment looks quite long term, but why this is still needed, maybe because of safety issues, maybe because of some other reasons, maybe the money is not coming from this project, but it is kind of an enabler for other projects which we are having. So it helped us to think and go back and work on our drawing board why we thought of this approach in the first place. And that also helped us in creating a better plan. As many people say, even like there was a quote from Einstein: if he has one hour to solve a problem, he will take 55 minutes to create the plan and five minutes to actually solve. So that is something which we did over there. It was like working on a very, very concrete and clear plan so that irrespective of how we are going to run, we will achieve the success. Yeah. And when you were looking, Nareem, it was product development and production, it sounds like, but in sort of both. It was both. So, first, of course, uh to gain the trust from the management, something which is controllable for us. Because when you talk about efficiency and effectiveness of the plant, that is something which we can lead. But when you talk about selling more uh higher value or higher numbers to a customer or finding a new customer, it was outside the responsibility of the plant. It was by marketing team and sales team and all those people, right? So we were creating uh ideas. If the idea is successful, of course we can keep on producing, but it is only going to create more inventory if they are not able to sell it out, right? So it is also important that first we can put some plan which is more controllable so that we can gain trust and show the result, and also trigger a thought that if we can identify a customer, we as a plant are ready for that. We are prepared to deliver on those commitments as well. Our bottleneck is not at the plant side, but bottleneck is somewhere else. Yeah. Some people think projects are end-to-end when it's going from idea to launch, you know, plan to deliver, order to cash. Whereas yours was actually, in the end, you were considering from the very start of product development through to sales because it all they would create a bottleneck somewhere if you don't look across the whole thing. You will get different value through different end-to-end processes, but it is also like all the processes at the end are connected with each other, and then there could be a lot of other value which you will be getting from mixing these end-to-end processes with each other. So it is like kind of you are playing in an orchestra and people have a different skill. People might need to coordinate with different set of groups, but together, if they are not going to coordinate, it will not sound nice. So you might be practicing more with uh other guitarist or pianist, but at the end, you need to also practice with each other and make things efficient together. There was also like sometimes people work in their own silo. I had another example in the past. I was working at another Six Sigma project, and they were like, My responsibility is manufacturing. So we are responsible for producing as much as possible or whatever we have committed for the year or month. Then transportation was like, we would like to deliver full truck load. We don't want it to have a half truck or those kind of things because otherwise it will cost more. So they were like, we can only deliver when it is full truck. Then customer service was like, I need to say yes to the customer order. So I need to maintain the relationship. I know that it is a big customer and all those kind of things. So I need to maintain that. And then at the end, somehow, sometimes, like at least in that organization, manufacturing was like, we ship the product out from our manufacturing environment on time. Customer service, we took the order on time, but they are not following up on like whether the delivery was received on time or not. And logistic was like, we are just responsible for full truckload because the truck was not full, we were not delivering. And there was some clear gap, certain responsibility, which no one is accountable for, right? So, in which kind of scenario, who's going to take the decision? Is customer service going to say yes to all kinds of order or a particular set of order? Is logistic not going to be flexible at all in any kind of scenario that a customer with whom you have a very good relation or big customer or most paying customer is not receiving a very urgent order because of certain reasons. So, who is going to take those decisions? And my KPI is to have full truckload, but then you're missing certain things in between. And that is very important to bring the synergy between different flows. Otherwise, we will have flows, but again, you will not be able to make customer happy. Yeah, that's an amazing example, actually. So I'd like to just ask you a broad question, maybe on AI, given that it is undoubtedly changing how everything operates at the moment in businesses, and maybe the adoption isn't there yet in businesses, but I have no doubt that it will be. The amount is changing our day to day lives. There is a question around how it's impacting process management, but I think that that's probably the least interesting one. Maybe more just how do You think it's impacting businesses and how they run their processes from manufacturing to more the shared service corporate side of things? How do you think it's going to impact? See, first of all, right now, uh a lot of organizations are in exploration phase. And similar to as I told you about agile and other people are, oh, we need to have an AI. You are not going to have AI for everything. It also comes at a cost, right? So, first of all, what value you are going to deliver, you need to focus on that. AI is a tool or a skill or ability to deliver to that value. If you don't know the value, it will deliver something which is more chaotic. So if you will create a chaotic process and put an AI to it, it will just create more chaos. Then if you have the right skill set, I think AI is going to help in orchestrating. So I see a lot of in my own job things which I used to do manually and all those kinds of things. I'm using AI as a tool, and AI is becoming an orchestrator for me. So instead of me doing it, I'm asking AI to do it, and I'm actually able to do things way faster and maybe get more better results. As of now, we have not developed the AGI part. So cognitive thinking is missing. So human intervention is required for the critical places. So it is not like you will replace the human. Then when you talk about AI, again, it will come at a cost, and all these big tech firms are putting a lot of money to invest and put in all the tokens which we are consuming. And because of that, yeah, they are also not profitable. So, from that point of view, first of all, if we focus around the business problem, make sure that people have the skill set how to use AI. Then let people decide whether they are going to use their normal day-to-day way they have been working or they think AI could help in building this. And then don't just build AI because everyone is building. Because you believe in that this is the only right way to solve your way of working. So a lot of process mining and process insight tool is giving you information where your process problems are. And AI is becoming a new word. We used to have automation. See, when we talk about in a car, we do cruise control. It has been there for years, right? We talk about any automation. We have been automating things since long back. Now those automation things are more powerful, way more smarter and faster in delivering things. So it is not going to do uh only one set of activity, but the same thing earlier. We used to have only cruise control. Now we have autonomous cars which can drive by itself, right? So you you are building those capabilities where they are able to do multiple things which are closely connected with each other and solve it for you. So that's how I see it. It is not that we will start selling AI tools, right? Yeah. And I think when you talk about the value case, I often see in organizations there is an AI task force that is effectively a team running around looking to deploy AI wherever they can to whoever will say yes to, you know, rather than looking at it from everyone needs to know about this technology. Everyone needs to be aware of what it can do. And then when you're going to solve your problem, it's just another tool that you can call upon if needed. It's a powerful automation tool, effectively. Doesn't mean let's say if I talk about any regular organization, you don't want it to automate just because everyone is automating. Let's say if you have a challenge in the onboarding program, you can create an AI-based tool which is built on RAG system of AI. So basically, you have your own internal AI uploaded with all the in the internal information so that you just ask and then it will give you results. So instead of going and looking into BPM and diagram, you might ask and it will give you results. You don't need to look a thousand pages of document and where the process is. So it will make things more easy to search and find. So this is more like a LLM kind of model where you can, but then instead of me looking into the receipt from the supplier, automatically it is going to check whether that information is there, whether billing all those things are correct or not, and then revert back to the supplier that this information is incorrect rather than me keep checking each one of the things and manually doing it. There will be a lot of productivity improvement, which can easily be done with the help of AI if we would like to go in that part. But when you talk about creative task, when you talk about decision-making part, I think we are in very early stage on that. That's also good to hear. Thanks very much for coming on the show, Prem. I really appreciate your time and it's been a really fascinating conversation. From talking about improving processes on the shop floor and on the manufacturing floor to understanding, I suppose, how you've managed to go from your approach to pitching the five-year plan at Johnson ⁇ Johnson. Really fascinating the way that you kind of won over one site and made a small change there. The way in which you engage on that one site, I found really interesting the fact that you listen to them, what is their problem. Okay, right, we agree with you there. We think that there's a solution. And then here's some of our other ideas, rather than just going straight with here's all my ideas and all the new things you should be doing. So yeah, it's been really fascinating, and thanks very much for taking the time.