IBP Transformation: There is No Perfect Time.
Welcome to this S&OP MasterClass from Perito Consulting. These MasterClasses have the purpose of diving into Integrated Business Planning and Supply Chain Planning in general, hopefully giving you some good inputs on the way.
Today’s topic is IBP Transformation. For many, transforming the supply chain and demand planning has been on the agenda for years. In this episode, we adress why companies comtemplate and offer advise on getting started.
This episode explores why businesses fail to start a transformation of their supply chain planning and why companies are too slow in the implementation phase. They end up dismissing the benefits, because they want their master data to be perfect before developing further on their current solution.
This is a mistake according to expert and COO of Perito Consulting, Benjamin Obling. In this episode, Benjamin explains the common behaviors of companies when contemplating a transformation, and how to move past the fear of imperfect data.
Your host is Søren Hammer Pedersen, Chief Commercial Officer at Perito Consulting, who will guide you through this interesting topic of getting your IBP process started despite your doubts.
In This Episode
Listed below are the most essential timestamps from the episode to make it easier for you to find the topics that interest you.
01:49 Defining integrated business planning (IBP) and Sales and Operations Planning (S&OP)
03:05 Why are companies waiting to make an IBP transformation?
05:04 How to handle your messy master data
06:13 Automating your master data
09:48 Integrating Multiple ERP systems into one IBP
12:33 Implementing too slowly and what happens
15:10 Can an implementation be too fast?
21:37 Engaging your board of directors
24:32 Different cultures across your supply chain
29:56 Criteria for success when implementing an IBP
34:07 The supply chain crisis and withholding an IBP transformation
Hello, everybody. Welcome to this S&OP Masterclass from Perito Consulting. In these masterclasses, we are diving into Integrated Business Planning and the whole supply chain planning topic, picking up topics that we hear in the market, we hear from our clients, we hear from potential clients, and trying to give our perspective and our experience on that.
And today in the studio, I’m lucky enough to be joined again by my very good colleague, Benjamin Obling, who is the COO in Perito Consulting and has more than 20 years of experience implementing Integrated Business Planning and working with supply chain planning in general. Welcome, Benjamin.
Thank you. And thank you for having me.
And today’s topic is all about data and speed when we implement IBP or try to implement IBP in companies or see it out in the market. And the reason for picking up this topic is twofold. One is that when we talk with potential clients, they face sometimes two obstacles. One being maybe that they never get off the ground, never get started, waiting for the perfect time. And the other being that they do start an implementation or a transformation in their supply chain planning, but it’s not really kicking off. It’s taking too long and the organization tire out. So, those are the two topics that we are trying to dive into today.
But before we get started, Benjamin, just for the sake of also the listeners out there, could we just briefly define Integrated Business Planning in relation also to S&OP and so forth so everybody knows what we’re talking about there?
Yeah, absolutely. I would say, the very short definition is it’s like an S&OP sales and operation planning plus. So basically, adding the financial aspect. So making sure that we are here making a full end-to-end Integrated Business Planning in the sense we are able to look at the strategic level, looking three, four, five years out, having financial impact of that. What is our demand scenarios? How does that look? Supply, capacity, factories, et cetera, all the way down to the tactical level, looking at the shorter horizon and all the way down to the operational level, being able to supply the ERP systems with the data they need to create orders and order handling, et cetera, on the very short-term. And making that inter-transparency is the Integrated Business Planning.
Yeah. So really making that one common plan for the whole company so we don’t have the demand planning, the supply planning, like silos, but really working together across the whole company.
Exactly, and being able to see the financial impact of those plans.
Yeah, brilliant. So, let’s dive into today’s topics. And I think what we hear typically when we picture a company, they want to do something in their supply chain planning, they’re trying to make this transformation. One thing we often hear is that we are waiting for something we’re not getting started. We are waiting for the data side of things, those companies that really never get to that starting point of the project. What’s your experience with that?
Yeah, there can be many elements that is causing this sort of waiting position to be there. So one could be like you say, the data. Our master data is not perfect. We know the lead times are not perfect. Our lot sizes, the routes, the footprint, it’s not completed. We don’t have it mapped out for all the materials. It can also be on the capability side. So you have the people around it. Okay, we don’t have the right competencies at this point in time. We are trying to recruit or trying to build on existing competencies, but right now it’s not perfect.
Or it could be, yeah, we’re just going into a new ERP system, or we just got this new ERP system, or we just acquired a different company, or we know we have a buy and build strategies or we’re going to buy multiple companies and multiple ERP systems. How do we integrate all of that? So, let’s wait until we all have SAP, S/4HANA or we all have Dynamics, et cetera. And the problem is that we never get to that situation. That’s basically our take on this. So we need to get started because we’ll never have this perfect timing.
Yeah. One question could be, have you ever experienced a company coming in that had perfect data?
No, no, certainly not. No, no, no. There are certainly differences in how professional different companies are with their data and how serious they take it, et cetera, but it’s never perfect. It doesn’t exist.
No. So if you’re sitting with that feeling and it’s a quite natural feeling, looking into your master data and think, “Okay, we can never do anything with this.” What’s your recommendation for that planning department sitting there with those master data? How do they work with that and still making the transformation?
Yeah, so they can be different. Of course there can be a cleaning process. Okay, let’s start and take the most important ones. And that’s really the priority. That is the key driver or key enabler here. So, if we try to fix, let’s say we have 10,000 different items or 10,000 different customers, et cetera. We need to update some master data. Okay, let’s take our … okay, where do we sell the most? So basically, looking at the 80/20 rule and then say, “Okay, let’s start from the top and see with the biggest impact. So maybe we have a long tail of items or customers, et cetera, where we know it’s kind of a mess. But okay, we got to live with that and we got to take it if it sort of takes off and starts to sell more, et cetera. Okay, then we’ll correct it.” So, there can be some one way of handling it.
It can also be like, automating is another lever, another trick we can use. So basically looking at, if you have a lot size problem, we don’t know exactly what our minimum order quantity is. Then instead of again, going through all of your items, adjusting that and so on, which is a long process, taking out a lot of manning time, et cetera. Instead, we can to some extent automate that, basically looking at what is your historical purchases, removing the highs and the lows and take an average of that or median, et cetera. Then you can go a bit detailed into how do you then actually calculate it. But basically you can calculate it and have that as a supporting point, which can also guide the company to where do you need to change it?
Okay, so if I hear correctly, your recommendation here would be not to wait and not to start a crazy manual update that probably never gets done, but more to include it in the transformation project and just get started, basically, and fixing basically the problems as you hit them down the road.
Yeah, because your IBP project will basically it’s going to require all of those data, of course, because it is data driven, should be data driven, et cetera. So you need to adjust it. You need to get down to that level, at least on the big ones, the big impacts. But that will basically be revealed during the process because you’re going to see that you’ll have some extreme safety stocks being calculated because lead times are completely wrong or the lot sizes look very wrong, so your capacitor calculation doesn’t work at all because you have change over time, et cetera. And that’s going to be pretty obvious quite fast. And that also means then you can start to prioritize, where do we need to do those changes? Where do we need to look in order to change the master data?
And then it is possible. And then you get from a master data problem, a total mess of a giant list of tasks that you need to do with a lot of items, et cetera, then down to, “Okay, let’s start by resolving these 50 lot sizes that are completely off. Okay, let’s go through those.” Give it to the planner. Spend an hour every week or whatever. And then basically start to fix it. Or let’s say, “Let’s start at the starting point where we just look at let’s upload the average lot sizes, the average purchases we’ve had and use that as our lead time or as our lot size, et cetera, then we have a starting point.”
So, it’ll actually get easier also when you’re included, because you also can use the automation to highlight those where to start kind of things.
Absolutely. I think automation is key in this because you also got to acknowledge that it will never be perfect. Of course, it’s quite typically in a stage where, okay, we need to get to a better stage. And that’s what you’ll do as part of the project. And then when you arrive at that stage, you’ve also got to acknowledge, it’s not perfect either. So really there you need the automation. And the automation being either you calculate the master data or the data that you need automatically, so you have some logics that you assign to the different data points that you need. So you actually don’t need to maintain it at all. That’s a lucky stage. Or you use it to create alerts and exceptions. So the limited time you do have for changing master data, that you do that on the critical parts, the critical customers, the big ones, et cetera.
So basically, the conclusion here is that there will never be a perfect time in terms of master data. So you need to get started unless you want to get hurt in your business, basically. Because if you wait, just wait and wait and wait to make the transformation that you want, well, you’ll never get there.
No, exactly, exactly. And that goes for master data as we talked about now. It also goes for the ERP systems. So basically you might have, let’s say one or two ERP systems. Now you’re planning to change it or you’re planning to purchase, or just purchased another one that you want to integrate into another company, that you want to integrate to have one company, et cetera. And again, here it’s important that you have the capability that your IBP can look across multiple platforms, across multiple companies and multiple ERP systems. Because then you start to train the users and let’s say, meta tool that you actually put on top of your transactional ERP system. And in that sense, they can work with the existing ERP being fully integrated with that. And slowly, when you then start to integrate the new ERP system or go to the new platform or the new ERP system or integrate a new company, basically your IBP platform will look the same and it will copy all the historical data from the different ERP systems, group it together. And you can basically continue as if you were not changing ERP systems below.
Yeah, so very simply said that we are putting IBP on top of your existing data system, your ERP system. And we really don’t care which ERP system you have, because when you change it out, we will just point the string in another direction and still get the data that we need or you need for your implementation.
Yeah, exactly, and that’s also easier said than done, obviously. And it’s a very hard requirement that you need to put up to your IBP software, that it needs to be able to do this. Because if it’s very closely linked to the ERP system, say, “Okay, we need to take the master data from this field or this field. And it needs to be from this table, et cetera, in the different ERP systems, then you obviously can’t do this.” So you need to be able to take all of the data, put it into a middle layer, you could say, without being too technical. And then you basically map the data from there on. So you have a mapping point or interface where you interface your different ERP systems into one connecting point and then you connect that to IBP software. And then you’re able to change the different ERP systems because you have the same interconnecting point here. But that’s an important requirement, especially if you’re changing ERP systems and companies are, on average. I think it’s on average, like every seventh year or so on average that we see that, and then you have companies acquiring other companies on top of that.
Yeah, so no reason to not get started, basically.
Yeah. Good. Let’s isolate that and say, okay, now we convinced those waiting that they should start. That’s one point. But another very interesting topic for me is the ones that actually do get started. And maybe to give some perspective on why I think this topic is very relevant. We talk and I talk to quite a number of companies who have started this journey, transforming their S&OP, their supply chain planning, but have done it for a very long time. So they started a transformation project, but 2, 3, 4 years down the road, they haven’t really gotten it off the ground. They had really big plans, but it hasn’t really succeeded for them. And they’re now looking to, okay, how can we restart it again? And that’s, of course, not a good situation to be in. So maybe to start that topic, talk a bit about when you start this, why is speed in the implementation process actually, for your perspective, a critical thing to have?
Yeah. You could say one is obviously the results, getting to the results. Because the IBP project, as such, again, is not like a goal in itself. It’s a lever in order to achieve some business impact that we want to achieve. So of course, the faster you are in implementing in a solid way, the faster you’ll also get to the results, basically. And the results being we’ll have a higher customer service level. That means we’ll have a higher revenue, higher gross profit. We will reduce our inventories, if that’s the case. So we have a lower working capital. We can optimize the balancing of our production capacities. So that basically mean we might avoid purchasing new production lines. We might avoid over time, et cetera. So basically all of these upsides that you have from the IBP yield, basically get to those upsides faster. So in itself, that’s a good say. That’s the very short reason why speed is super important.
Other reasons, of course, being to get the buy-in from the organization. Because if you have a project team, they’ll be sitting in a project room. It’s all going to be very fun and cozy for a very long time in that room. But it’s basically, if it stays in that room and it doesn’t live in the company and gets out there, it’s going to be very difficult along many months down the road when you go out to the organization, to get that buy-in of why is it that we need to do this, et cetera. So certainly speed there is off the essence.
And devil’s advocate might be then on the other hand saying really, but is speed always a good thing? So we just plug in the switch and then we’re up and running. How do you see, can it be too fast, basically, is your other side of the coin, of course.
Yeah, it certainly can. It certainly can. And that’s the problem. It’s always about balancing in everything we do in life. But you could say it certainly can go too fast. And one of the risks is, of course, that are major requirements in the company, so understanding of the business that you miss, that your implementing something where you think you’ve got hold of everything and you know how the business works, and then you’re basically just missing out on very important stuff. So one example could be, if you have critical components for your spare part, if we are in the aftermarket business as another episode of this, and you have non-critical. If you miss out on that and you just treat that as one, you might see that, “Okay, we are too low on critical components and we are too high on noncritical components,” for example. So that could be a business requirement that you lose out on.
And another, probably more important element is the people side of it that we also didn’t address in the, when is the perfect timing of getting started? That you need to have people within the company, of course, that can take on the role in the IBP process, who can understand how does the process work? How does the tool work? What is the data? How is the integration with the ERP systems? To some extent down to the very detailed level, but also on the conceptual side. So it’s super important that you have the right people in place, and you give those people the time. And that’s where it can be too fast. That you give those people the time to actually understand and take in what is the new IBP process? Because IBP is not a small thing. It’s not a just switch on and implement and put up the box and somewhere in the corner and then go.
No. So if we agree on that, we need to have this IBP, we know we need to have it in a certain timeframe, meaning that it can’t be these two, three, four years down the road. How would you start that? You would still put in a solution that covers the entire IBP process basically, but how would you approach it so you don’t end up four years down the road?
I would be sure to, in the beginning, be sure to know where do we want to end, even though that might be a very long journey or can be a long journey. But where do we want to end? And can the process, the capability, the tool that we are implementing, the integration we are looking at, can that support the whole journey? But we’ll not start with the whole journey. And then we’ll start one place. We’ll take a pilot, maybe, or it could be an end to end, so both demand inventory supply on a smaller area. It could be like, let’s start with demand planning and let’s get that up and running. Then we go to supply planning or vice versa, depending on where do we have the larger pain in the organization. So where can we deliver some results fast?
So basically, splitting the elephant into smaller pieces and eating it from there. But knowing from the beginning, we want to go all the way, but will not start to specify a space rocket, space shuttle, in the first workshops. Because then we might end up in this situation where now we finally have this IBP process, we want to build everything. We want be able to do anything that we’ve always wanted to and always desired. So, we specified all and will not implement, we will start to implement, but will not go live until we have the perfect solution. Because that’s really when you get trapped in the free/four years spending tons of consulting money, and you’ll probably also lose most of your internal project team along the way and so on.
From sheer frustration.
Yeah, exactly, exactly. And it sounds crazy and stupid, but this happens. And we know from surveys that this is actually more common than the opposite.
Yeah, so a red flag in your implementation, if your project manager is looking for a new job, then you probably should do something different. Okay. But when we then break it down a bit more in the sense that we have this plan now for starting the implementation of IBP or this transformation, it would be naive not to think that we wouldn’t hit some obstacles along the way. We made this perfect plan. In our opinion, we all know something will shift along the way. We will get wiser. Something will happen down the road. Could you elaborate a bit on some of the typical obstacles you see companies facing or meeting down the road and maybe also how to mitigate some of them?
I would say one really key element here is, of course, to have the right people in place, both in terms of the project team. So if you need external consultants, those being the right person, but that’s secondary. The most important part here is really the people that you have internally in the company. Can they support the process? Do you have a call team who have the time dedicated to actually do this and focus on it? And also, do they have the experience so that they don’t have to know everything about the company, because you can’t be so fortunate to have people like that. Sometimes that’s the case, and that’s great. But you need to have people who can, when they are in doubt, they know who to ask, who to go to, so that we make sure that we cover all the requirements and make sure that we know what is really important, super important, what is less important? So I would say the people side really being key here.
From the data side here, we’ve talked a bit about the master data obviously being super important and transactional data. So that could be what is sales actually? Maybe that’s clear, but you’ll have a lot of definitions that you need to work with during the team. And there you need to have the right people in order to determine that.
One thing I have stumbled upon that seem quite important, actually, for the success and the speed of the implementation, was actually before you start to define some very concrete results that you basically know which low hanging fruits you’re going to show the board first down the road to get that engagement into and support to the project. Any thoughts on that from have you any experience in sense as well, that being important?
So, one approach that we often use is basically to have an assessment in the beginning. So, you sort of look at, okay, what is the planning capabilities we have now? What is the forecast accuracy? How is the inventories? How well are they balanced? How does the supply look? And then basically make an assessment of, where do we see the biggest improvement potential? And that you could say one, you could call it a trick in order to get buy in. But it’s also a trick to get to the results faster. Because if you can really see, you can improve forecast accuracy in this area, for example. Okay, why not start with Germany or South America or whatever, if that’s a demand region where we can see, okay, here we can really improve accuracy. Let’s go there, have the business impact, that’s the positive side. But we’ll also have the buy-in and we have that as a showcase for the board, for the C level, but also for heads of planning and planners, et cetera, to show them, okay, this really does work.
And then there might be other areas where, okay, it’s not really making a huge difference here. Okay, so we don’t want to start there, but of course included because we need an end to end.
I think actually that’s, from my perspective, a very important advice in the sense that I’ve stumbled upon cases where companies have made transformation projects, but they forgot to lock the baseline in the implementation. And that meant when they were nine, 12 months down the road and the boards or other people said, “Okay, what have you improved?” Well, basically that answer was, “We don’t know for sure, but we have improved.” And many boards don’t like that answer in the sense. So it’s very, I think getting the base right in the beginning so you know where you’re improving from is also a very sound advice here.
Yeah, absolutely. And then I could say maybe coming back to the speed, because you also want to show the improvements so you have something that is comparable to the baseline. Because it can also come up in a situation if it takes a lot of time, that the world has actually changed so much that it’s not really comparable. So we want it to end up with X percent of forecast accuracy in one world. Now we have COVID or we have a disruption in different ways, it’s actually possible to reach X percent. But you need to be able to bridge that of course, and sort of separate out where do we have the impacts and where do we see that?
Another thing I hear quite a lot that I hope you agree that people sometimes forget is, when we are sitting in Denmark at the moment, of course, having our Nordic perspective here on things, but still running a lot of global implementations. What I hear from both clients and potential clients is that it’s crucial to remember that culture is different, geography is different, things work differently. So having that respect for that in the implementation project can be very vital. Have you any experience on that on your projects?
Yeah, absolutely, and I agree. And that can both be across companies, but certainly also across departments in different companies. So you’ll have supply chain thinking in one way, so supply chain in Germany versus sales in South America, or vice versa. So you can have just as big cultural differences there actually. So, being very aware about how is this understood and also understanding what are the different concerns and when is it an important concern and when is there, maybe, a different agenda if we are in that environment? Maybe someone doesn’t want the transparency that we are trying to create. Okay, how do we work with, how could that transparency actually also help and assist that person or that department in that country in their day to day business? So I think being very, you could say always being of course humble to towards the business and different cultures is obviously the good advice here.
And then taking in, basically listening, hearing, what are the requirements, what are the concerns? Because quite often they are actually valid concerns. Maybe they’re raised in a way that doesn’t sound like a valid concern, but you still need to find your way of, okay, there is actually something here that we need to take into account because otherwise we are not covering what we should in the process.
So, it’s really vital to have that. We are still making a core of an IBP project, but it needs to take in account those local differences, how the different companies we might have within our group is working and how the company and the geography in terms of different cultures.
And it sure gets pretty difficult sometimes because you do want to have that transparency across. You do want to have one, one tool, one set of data. So that’s sort of our starting point. And then you sort of get into a department, a country, a region, et cetera, where you actually see, okay, we actually need to do this in a different way. So how do we make sure that we are still aligned with our total IBP process, but we can still support this business special requirement that we have. And when is it something where say, “Okay here, we would only do it to get the buy-in okay. Then we don’t want to do it. We want to explain why we don’t want to do it. But in other cases, we actually do make this a bit more complicated and include this requirement, but still in this end-to-end platform.” That’s certainly easier said than done. But is a balancing where it’s important then to link the single user group, the single users of the system in the different countries, with the steering group, with the management to understand, okay, when is this something we need to spend more time on because it makes sense, or when do we need to spend time on explaining why we don’t do it?
So, if I hear you correctly, we need to have a lack of better word, some stakeholder management, both on the operational, tactical, and strategic level here to make sure that we really have people with us and have all their input basically on all three levels along the way when we implement and have that respect for that.
Yeah, absolutely, absolutely. Because you basically have the two sides of the problem is that if you don’t listen and you just go ahead, there will be some important business requirements that we miss out on, and then the solution doesn’t work. And then if we’re too kind, basically, and we sort of take up all the different requirements that we’re going to solve everything, it’s going to be super complicated and we are going to end up in a mess at the end where we can’t fight our way out of that level of complexity because we want to get the buy-in completely. So we need to be somewhere in a sweet spot between those two and operate. And that’s especially a problem or a challenge when you have a, you could say, less perfect timing which is then our conclusion. That’s all the time. It’s less perfect. But if you have multiple ERP systems scattered, a scattered system landscape and organizational landscape and so on, that is even a higher challenge of ours.
I think a very interesting point in the sense that I think many people, not because they’re bad people, but they will have the approach that we just need the buy-in from the CEO because then we get the decision we want, and then we are running with the project. And that is absolutely correct, in my opinion. You will get the project approved and you will get started, but it might not work in the end.
No, no, no.
So, a very, very important point to have in your implementation plan as well.
Yeah, yeah, yeah.
So basically, your message here is that it can be done quite quickly. It can be done, but you need to take these factors and obstacles into account that we have. Maybe also briefly touch upon when we then succeed here, because that is the end goal here. From your perspective implementing these integrated business planning, what can companies achieve there both on the maybe short and a bit longer horizon here? Why should they both get started and get it done quite quickly in your opinion?
Yeah, I could say one element is obviously the tangible impacts of the business. So, basically the profit and the derived profit is then the higher revenue will get because we have a higher service level. We have a higher gross profit because we have the right balanced inventories and production, et cetera. Reducing inventory levels, obviously being another, reducing changeover time, reducing temporary workers, et cetera. So that’s sort of the more classical, tangible impacts that is basically the most important ones.
But other achievements here can also be that you have a new single way of working across a complicated organization. So if you have multiple organizations, multiple ways of working even within the same organization, you can very different ways of working different data sets, et cetera, that you get sort of one way of working one set of numbers, which is super, super important and can save a lot of time and a lot of discussions about data. Okay but is it 24? Is it 26? I have done this and when I do this X strike and when V look ups in Excel and whatever. And then you have the different data sets around and you spend time discussing data sets instead of discussing about different scenarios and financial impact and outlook and strategic decisions and so on. I think that way of working and the methods, getting that aligned at across the business is certainly also an achievement which is less tangible, but certainly also important.
Yeah, super important, I think. And I think, although summing up on some of that, I think it’s so important to be aware of when you’re standing there looking at that huge transformation mountain, really tying up that. There are these approaches that can help you get through it relatively fast. But with those results you say, so you can actually lower the complexity with the overview and transparency that you get out of this, I think that’s a very good benefit to get out of it.
Yeah, absolutely. And I think one of the enablers that is quite important is what we call agile data transformation that you could say especially when you have different ERP systems or when you have master data, transactional data, et cetera, that are questionable and there are things we need to change, having an agile way of transforming the data. So, it might sound a bit nerdy and detailed, but basically what that means is that when we have this low-quality data, we have multiple systems, it’s getting complex in that way, we need to be able to extract the data from the ERP systems, fully automated, et cetera, and then we need to transform that data before we put it into our IBP system. And when we do that transformation, we need to be able to add some business logics to it.
So, this very specific example of being on the lot sizes, if lot sizes, minimum order quantities are complete crap and we can’t use it at all, okay, can we automate it? Can we look at the historical orders? How are they looking? Can we look at the historical production orders? What is the lead time on our purchase orders? What is the actual lead time we’ve had from different vendors? How can we automate that and how can we, in an agile way, transform the data automatically? And in that way we can actually see, we can compensate for a lot of the messy master data that we have out there because we basically add logics on top of it, removing all the manual work.
Wow, so getting easier, even easier to get started, basically.
Using the automation. I can see time is running here. But one final question that I think is very interesting is that a lot of companies have experienced, not a lot, all companies have experienced the supply chain crisis and of course the pandemic here. Has that made it even worse to wait, basically standing, staying waiting for the perfect data with slow implementation, things like that? Or has it been a good idea, basically, to wait with the situation we have and we’ll have in the future years?
Yeah, I think we can see from our clients at least, that we have been able to get them through the, or they have been able to get through the crisis quite well and that the speed of adapting to the new world has been super crucial. And if you need to start with the IBP implementation and then you get the agility and then you have a supply chain crisis and you’re standing in front of that sprint that you need to do, then you’re in a pretty bad shape. But if you have the tools and the IBP process implemented already, then you are able to swop quite fast. And what we’ve seen is lead times varying a lot, being super important to include, suddenly changing sourcing routes, et cetera, but being able to do that within days, super critical.
Looking at the demand plans, increasing, decreasing demand, making rapid shifts and so on without having a large process in the company where we need to discuss data and someone extracted two days ago and they made this V look up and they have blah, blah, back to the problem, then you won’t be able to make that agility of basically saying, “Okay, we have all of these changes here, demand plan changes, lead time changes, sourcing changes, new production, et cetera, and we need to be able to see the impact of that in our IBP tool pretty fast, so that’s within days. And we need to export it to our ERP system and have the operational level working accordingly also within days. How do we do that?” And you’ll not be able to do that or not a lot of companies anyway will be able to do that without having the proper supporting set up for it.
Okay, exciting stuff. But I can see that we are shortly running out of time here. I think to sum up, I think it’s very interesting that there will never be a perfect time.
So, you might as well get started. But the good news, of course, being that with the right approach and the robots and the automation, you can actually come quite far, quite fast if you have the right approach and the respect for the obstacles you will meet along the way and of course be able to mitigate those. Very, very interesting. Thank you very much, Benjamin, for coming into today.
And also huge thanks to all the listeners out there. Really appreciate you listening to our podcast here today. If you like what you heard, please subscribe. That’s probably something on the screen you can push, and otherwise you can go into our website. You can find all our S&OP Masterclasses in there. And of course all the information you might want to know about Perito Consulting. So again, thanks for tuning in, and we hope to see you to the next S&OP Masterclass here in Perito Consulting.
Want to know more?
“…Through our partnership with PERITO, we can leverage our core competencies much better and improve our collaboration with the global sales organization. We now have one unified and much more accurate Bang & Olufsen’s demand outlook.”
Jacob Frederiksen, Sr. Director, Planning & Operation, Bang & Olufsen
Want to see the system live?
– Get a short demo video directly to your mailbox