Good morning everyone and a very warm welcome to this webinar on Sales and Operations Execution. Beyond Firefighting, how SNOE turns decisions into execution. We're super excited to have so many people tuning in, ready to spend an hour with us diving into a topic which we of course find super interesting. Today we'll be zooming in on a challenge that a lot of companies face. We have established SNOP processes, we have aligned plans and tactical decisions that are well defined. But when the decisions hit operations, they seem to lose their impact. Instead, we're faced with short term changes, unclear priorities and lots and lots of firefighting. This is where SNOE comes in. SNOE is the layer that connects tactical planning with operational reality. It is a structured decision making process which allows teams to respond to short term changes. And which enables well thought through trade offs and prioritization even close to execution. So today's theme is really rather simple. How do we move from a paradigm of reactive firefighting to structured cross functional execution? A quick introduction to who we are. My name is Michkel and I'm joined here in the studio today with my good colleague, Niklas. Hello. Today we work at Implement with Supply Chain Planning and Operations Excellence. And of course at Implement we have quite a broad range of different types of topics that we work with within this domain. As an example, we work with SNOP implementations, we work with planning operating models redesign, inventory optimization and a lot of other topics. But one topic that keeps popping up which is more and more relevant is SNOE. Many companies actually already do parts of SNOE today. So it's not that the topic of SNOE is really new, but it's more that we see an increasingly urgent need to have a much more structured approach around operational planning and execution. Some of the questions that we often hear is, why do we still have all of this firefighting if we have a well established SNOP process? How come prioritized are clear at the management level, but unclear in the execution? And why do our planners have to spend so much time manually aligning across functions? These are exactly the types of questions that we want to explore today. But first, let's have a quick look at the agenda for today. We'll start with a bit of an introduction and a self-assessment. This is an opportunity for you all to actually reflect a bit on where are you on the SNOE journey today. So hopefully that'll get some thoughts going. And then we'll jump into our viewpoint on SNOE. This is what we believe must be in place for a well functioning SNOE setup. And specifically here we'll look at three different topics. We'll start with diving into what are the different SNOE decisions and handovers look like. Then we'll have a look at the actual SNOE process itself. What does a good process look like? And then we'll go into the business rules, which is how we formalize decisions to actually enable SNOE in practice. Then we're also very pleased to have with us in the studio today, Rone Anstensen from Otero, who will share some practical experience on how to actually work with intuint planning and organization. We'll also have a Q&A. So if you do have any questions as we go along, please feel free to put them in the chat, either for me and Niklas here or for Rone, and we will take them at the end. Finally, we'll do a quick wrap up and we'll talk a little bit into how to actually get started with SNOE. First, we'll start with a quote. SNOE is not MPS. It is a weekly reality check that forces the plan to meet the world as it is. This is a key distinction. Many companies already have a master planning process today. We create the production plans, we check the capacities, and we release something into execution. But SNOE is really more than just generating the plan itself. SNOE is a structured decision forum for questions like what has changed since we last made the plan, what demands are now more or less important, which supply constraints have come up since we last reviewed the plan, and so on. So it's important to emphasize that SNOE is not just the planning activity itself. It really is a cross-functional decision-making process where we get together sales, manufacturing, procurement, finance maybe even. We get everybody together to align on what does the reality look like. The symptom of a missing SNOE process is really our plans fail, not because of a lack of effort, but because there is no structured way to translate our decisions into execution. So let's try to just position SNOE in the overall planning hierarchy. We have here the planning pyramid, which I'm sure a lot of you have seen before. At the top, we have the very long-term strategic planning. This is footprint analysis, strategic market entries, and so on and so forth. A very ad hoc process with a long horizon. Then we have at the next level the typical SNOE or tactical planning process. This is looking at the midterm, and we often have a very clearly defined monthly cadence. This is where we look into rough cut capacity planning, make buy decisions, product introductions, and so on. At the bottom of the hierarchy, we have the short-term operational execution or operational fulfillment and execution. This is typically a very short-term focus. So maybe looking a couple of weeks into the future, and it will be based on day-to-day things, because we need to account for all of the stuff that happens on a daily basis. That means that in between, we have SNOE. SNOE is more a short-term operational alignment process. It will typically run with a weekly cadence, and it will look at 2 to 13 weeks out. The main objective of SNOE really is to convert the tactical plan into a feasible and prioritized plan that we can actually execute. So if we break that down a bit, there's three goals that we can identify here. One is we must translate the consensus demand into a constrained forecast. That means we can no longer assume that there are no constraints. We must actually turn the forecast into a constrained forecast. Then things also tend to change in the short-term. That means we must account for any new demand supply gaps that exist. And finally, it's not sufficient to just create a constrained forecast. We must actually have a prioritized feasible plan. The simple analogy here is if SNOE identifies a mountain up and head, and the decision is, do we build a tunnel or do we go the long way around? Then SNOE is taking the decision to go the long way around, removing any branches or rocks that are in the way, and making sure that executions can run smoothly. Good. Before we go any further, we would like to invite you to reflect a bit on your own SNOE maturity. So please go to minty.com and enter the code or use the QR code here. And let's address a couple of questions here. We've chosen these four dimensions. So the first one is tool support. Low tool support means that we do our planning in Excel today. We have manual analysis and so on. But high maturity here means that we actually have an engine that can do end-to-end optimization. The decision and handovers, if we are very low in terms of maturity here, it'll be unclear how we have different handovers. Whereas if we have high maturity, then we have clearly defined rules and clearly defined handovers. The focus and horizon, if maturity is low, is lots of firefighting. We don't look too far out into the future. Whereas if we have high maturity here, we have very clearly defined decisions horizons. And finally, for the organization, of course low maturity means silo-based planning and execution. Whereas a very high maturity level here would be end-to-end ownership across the value streams. Good. So we'll wait a bit for some of the answers to pop in here. I see there is a few already coming in. And we can see already now from the responses that it's a bit of an uneven distribution here, which is also what we would expect. Some companies are rather far in the SNOE journey. Others are only just getting started. And I see we have more than two thirds that have replied now. Let's take a couple more minutes and see where we land. Okay. I think we see the general picture here. Again, as I mentioned before, it is a fairly uneven distribution. Some seem to be quite far. Others are quite early in the SNOE journey. It seems the averages here also indicate exactly that. We do land at somewhere between we're just getting started and we have a very mature process. But I think it is important to emphasize that it also indicates that we are probably at very different stages of the SNOE journey here. Of course, SNOE maturity is not just about having a weekly meeting for SNOE. It depends on a lot of factors such as the organizational setup, the tool support, how well we've defined the decisions in handovers, and so on and so forth. And that actually brings us into the five areas of our SNOP viewpoint. Thank you, Michael. So, looking into the backbone of SNOE, we have identified five areas that needs to be established before you have a well-established SNOE. First point that Michael also mentioned is the decision and handovers. It's crucial to have these clear decision and handovers across the different steps in the planning hierarchy. Last, it is a weekly cross-functional decision -making process that are well-established, and we have the key stakeholders as part of that. Third, we have the whole business rules aspect. Business rules are prerequisites for cascading decisions and also making it into a system dynamic decision-making process. The fourth is when you get a little bit more mature, you have tools and systems that can support your planning and making planning much easier for you going forward. Lastly, we have the whole planning organization, where we believe that planning organization must be end -to-end focused when we're looking into SNOE planning. Today, we will focus on the first three. So, decision handovers, process and business rules. And then, we will have a talk with owner around how they established their whole planning organization in Oterra. So, first, moving into the decision and handovers. SNOP must be separated from SNOE with a clear decision handover, is our view on this. And how does that look? We have an illustrative example of where different decisions are layered out in the whole planning hierarchy. It is important to clearly define what decision needs to be made in the different horizons and on what level these decisions need to be made. If you look into the SNOP horizon, here we usually are at a product family level. We are looking into months and we are looking into the future, three to 24 months ahead. Here, we make some decisions depending on the lead times. For example, should we increase the warehouse capacity based on the new outlook we have? The whole new product introduction and allocation and so on. If you look into a set of the decisions that are made in the whole SNOE horizon. Here, we talk about should we pre-built to level load our production so we have enough capacity to actually produce according to the demand. And also, trying to remove all the constraints before it actually hit the operational planning layer. When you go into operational planning layer, here we have some decision levers and some different decisions we can make here. More on a day to day basis should we utilize overtime in order to actually execute that SNOE plan we already established. And here we also establish what time a day should we actually produce what the SNOE plan stated. And note in the SNOE cycle, here we usually looking at skew and on a weekly bucket level. Moving into how this can look into the different handovers that are needed. Here, once the different decisions have been made, it's important that the decisions are handed over and further detailed in a specific horizon. And as you can see, there are different processes that happen in the different horizons. Like in SNOP, we have the portfolio review, we have demand review, supply review and balancing and so on. And here we end up with the executive SNOP. If you look into the handovers that is between SNOP and SNOE, here there's something like the whole executable actions into SNOE where we look into segmentation, the inventory target settings and so on. All these decisions have been made in SNOP in order to have the right service levels. And then we need to make sure that our parameters also reflect this into the SNOE. When looking into the SNOE, here we are more short term focused. We are looking into shelf life planning, short term supply review, replenishment planning and so on. And there also need to be a clear handover from SNOE into operational planning. And here we need to do a feasible master production plan. So this, the plan we receive from SNOP, then we convert it into SNOE and make sure it's feasible and executable and constrained according to what is actually executable at the operational planning layer. So here you need to make sure that that master production plan can actually be executable at the shop floor. Please, you can note here on the slide that both in the handover from SNOP to SNOE, we have the whole allocation part and the same will also happen from SNOE into operational planning. There can be different allocation principles you need to take. In the SNOP, when you do allocation rules, it's more if you are long term constrained. And here you can start introduce constrained forecast and balanced plan. If you can see, all right, we will not be able to catch up on the demand we have here in the near future, then we simply go in and constrain the plan. And making sure that we have the right priorities to the right customers. In SNOE, it's more short term constraints. So constraints that are no longer than four weeks ahead. So here it's more leveled out in the master production plan. And this leads us to how does that actually, how does this actually translate into how the weekly process looks like. And the SNOE process is an SNOE is a weekly cross functional decision making process. And that's key to note down. Because when we look into this illustrative weekly SNOE flow shown as a game board, this is an example of where we see these are the key elements that needs to be part of a SNOE weekly process. So these will of course be adjusted according to the company's need. Our take is that we need all these roles as part of the SNOE process. Both the sales team, the commercial side, we need the demand planners, we need the supply planners and most likely also more people. I will now walk you through the key elements of the SNOE process. If we start with the demand planning part. So demand planning is usually happening in the SNOP process where we look more long term ahead. But that is needed in the SNOE process to do short term adjustment. If we know that the forecast we already put in is not correct anymore and we need to adjust it so we don't produce accordingly. And this is also what we call demand sensing. Looking into the next part of the game board is the supply planners element. Here we convert the monthly SNOP plan into a weekly SKU level master production schedule plan. Here we create the MPS plan where we convert it from monthly to weekly buckets and from a group level into a SKU level. So we become more detailed and more accurate on when we are doing the planning. And of course we are also doing a more constrained plan so the plan we are creating is feasible on what can actually be executed. Here we also talk about response planning. So if we see constraints we solve them. And we also go in and update the existing MPS plan if we need to adjust it according to new reality checks. Then we have the actual SNOE meeting. This is the meeting where all stakeholders meet where we both have commercial sales as part of it. Here we discuss the supply situation, the demand fulfillment and agree on the SNOE plan of actions and if there need to be any actions after this meeting. And this leads us to the next point. So the output of the SNOE meeting can either be a happy flow and this is usually when we have no constraints. So the plan we have created is all good and then we go ahead and execute it and do the handshake. And then there is also the escalation route. The escalation route is where we have supply constraint situations. And here it is important to note that when we have these constraints that needs to be taken different actions depending on what the constraints are. And please note the escalation routes can happen, can be considered in different situations as part of the weekly SNOE process. And this can be run in different modes. When we look into the different modes in SNOE we do not always operate in the same mode. The setup depends on the actual supply demand situation. And that changes often when we meet different constraints and we need to make harder decisions. The first one is no major constraints and this is where we go through the happy flow. This is a more stable rhythm with stable supply and demand. If we look into the next mode it is the constraint mode. The supply situation is tighter. Prioritization becomes more active. Traders become more visible. And decisions often move closer to the cross-functional SNOE throne. So this is where we go through the escalation route area of the supply chain process. And here we start discussing some of these things. Last one is the crisis mode. This is when disruption is high. Cadence typically increases. Management attention is stronger. Prioritization becomes more intense to protect customers, operations and business performance. So the key message here is that actually that as strong SNOE is adaptive. The process stays the same but cadence, decision rights, prioritization, intensity shifts when develop constraints increases. And this leads us to the next area which is the business rules. Here you can turn these decisions into actual business rules so you don't need to have the meetings over and over again if it's the same decision that comes out of it. Thanks Niklas. So as Niklas mentioned we're moving on then to the third area here which is indeed business rules. Business rules are what allow decisions to actually cascade all the way from the technical planning or SNOP layer through SNOE and finally into execution. Business rules matter because if we cannot define the rules behind our decisions then we cannot hardwire them. And if we cannot hardwire the rules then we cannot automate them. We'll get back to what hardwiring means in just a moment. But that also means that business rules are not just documentation. They are actually the functional bridge between management intent and planning decisions and finally operational execution. Let's try to make that practical. When we talk about business rules we're really talking about any sort of agreed principles that are there to guide recurring planning and execution decisions. So there's lots of examples about business rules. It could be customer prioritization, could be allocation principles, inventory policies and planning concepts and so on. But business rules really help us to answer very simple questions such as which customers do we prioritize if supply is constrained? When and how do we pre-build inventory? When should we accept or reject short term demand changes? And in the SNOE context this is really key because the time horizon is very short. Decisions must be fast and consistent and we cannot continue to escalate because of the short time that we have available. We must formalize the decisions. In other words, without clear business rules what ends up happening is we have the same discussions over and over every single week. And this is actually what creates firefighting. Let's talk a bit about how business rules are actually created in practice. I mentioned the concept of hardwiring before and we'll try to dive into that with a concrete example here. Let's imagine that we face a supply constraint of some sort and we do not have enough available supply to satisfy all demands. What typically happens in a situation like this is the issue is initially identified in the operational or execution layers. And then it is escalated either to some kind of an SNOE or SNOP forum or even to top management. And we decide how to best allocate the available supply. If this is not a one time thing then repeated decisions tend to be formalized over time as rules. And the idea here is of course we don't want to take the exact same decisions over and over every single week. So we need to ask ourselves if we escalate an issue can we actually formalize this as a business rule. And the third step is when we have the business rules defined these are then cascaded downwards and they are what allows the business rules to actually be or you could say the decisions to be embedded throughout processes tools and so on and so forth all the way down into execution. One important thing to note here is hard wiring is not just about removing the human judgment altogether. It is much more about actually allowing human judgment to be reserved for where it really matters. That is for true exceptions and things that indeed do need to be escalated but actually automating the same repeated decisions. We have here a concrete client example of what a business rule might look like. In this case it's a customer prioritization framework and do bear in mind of course the actual priorities here are very dependent on industry strategy and potentially other contextual variables as well. But the general principle here is broadly applicable. So the idea behind a customer prioritization framework could be how do we best allocate two different demands under supply constraints. We of course want this to be in place so that it's not about who shouts the loudest, who came first and so on and so forth. In this particular case the example is we allocate first to the strategic customers. These would be our bread and butter customers so we must satisfy the demands for these particular customers. Then we have contractual obligations which is of course also important if we fail to meet our contractual obligations. We may incur fines or other penalties but they are not our bread and butter. Then we have the strategic markets which could be an important link in a commercial strategy. But again it is a bet and not something that takes priority over the two first categories. Finally in this particular example we have portfolio considerations. So maybe we have ideas to expand platforms but this actually takes the backseat compared to the first three categories. In all examples of course strategic management overrides are still an option. Rules are not there to remove management responsibility. Rules instead should clarify what is it that can be decided automatically in the process. Who has the mandate to follow it and so on. And also what must be escalated to ultimately a management decision. That is to say business rules are there to make the prioritization transparent and repeatable but allowing for some flexibility. A final note on business rules. Business rules. We must convert business rules into something that can be digitalized and there is a couple of reasons for that. It is helpful to think of business rules as a type of Excel formula. So if we can say if certain conditions are true then this is the decision logic that applies. We have a good business rule. The reason for this is in order to digitalize business rules we need to actually translate the rules themselves into planning parameters. Master data specific planning logics and so on and so forth. This is of course key because if we cannot do this then the system side cannot support the business rules that we've otherwise agreed to. If you're doing an APS or advanced planning system implementation you know the importance of being able to digitalize the rules. But this is also becoming increasingly important if we want to leverage AI in planning. We simply cannot do this unless we have the rules in a state that they can be digitalized. And this we need before we start automating. Good. So, so far we focused on the handovers between SNOP and SNOE. We've talked a little bit about the weekly cross functional SNOE process itself. And finally we've talked about the business rules that enable the SNOE process. Now we'll shift our focus a bit from concept to practice. SNOE is of course also very much about organization roles and end to end ownership. And to bring that perspective to life we have with us our guest speaker Rone from Otero. So we'll take it over to the interview. Hello and welcome to the comfortable chairs here. First of all we would like to use your case Rone to show how companies can work with SNOE in practice. Starting with organization and process. To start with could you briefly introduce your company and explain why you decided to start this SNOE journey. Sure. So, so Otero is a producer of natural colors for the food and beverage industry. We employ 1,300 people. We have about 12 different production sites. And our supply chains are very sort of all the way from farming of crop to we have a collar that we are ready to ship to our customers. It's a very business to business environment. And before I said supply chains. We have one supply chain but we have a ton of different value streams within that supply chain increasing the complexity. So what were the biggest planning challenges you were facing before you got started with this whole SNOE journey here. So as I said we had, no we do have, we have a supply chain that is relative to our size. Has a lot of manufacturing sites. Our products typically is sourced from a site that is close to where that raw material is available. It's produced, stabilized in a site. Then it's brought to another site for further processing, finishing, enrichment. And from that site it's distributed. So most of our products will visit two of our sites along each journey. And before we started this we had a very decentralized setup with local supply chains doing their very best to move products forward. To fulfill according to, replenish according to forecast, fulfill according to demand, etc. But we had no global function. We had no global oversight. Or at least very little global oversight. And so we ended up having a lot of sub-optimized plans where of course a site is favorizing. You could say they're direct customers and they're trying their best with the visibility they have to manage the demands, right? But because we didn't have a global end-to-end visibility or responsibility, we lost a lot of those nuances. So that was a key challenge and the key reason why we had to do something different. Makes sense. So what was the first concrete step you took to address this challenge here? It was quite clear from when I joined that we needed to rethink how we approached the supply chain. It was one of my tasks as well to establish a global supply chain function. And so I think for me number one was to envision sort of where do we want to be sometime in the future. And part of that was to put in place an organization that actually has this end-to-end responsibility. Now we're not a company that just goes and we hire people, we add a leg of an organization somewhere. So it meant that we had to analyze what should we, you know, we know what we want to start doing, what should we now stop doing, and how do we think that's sort of going to even out over time each other, right? And leave us in a better place. So we started saying, you know, this is the blueprint, this is where we want it to be. And then basically we took some bold moves in the organization and thank God we did that when we did. And when you say thank God you did that when you did, what does that mean actually? Well, we had, so, so Oterra as a company is facing huge growth opportunities. Not to go into a lot of the details on natural colors, but we have a market in the US that's converting towards natural colors. And, of course, that leaves us with huge opportunities for growth. Those opportunities are also challenging because that's a, it demands us to rapidly scale up and to change some quite big opportunities. to really win those opportunities instead of leaving it on the floor for our competitors to pick up. And so, because we have these supply chains that are sort of intertwined and relying on multiple sites and sources around the world. We, because we did this change in organization, then when this started to, when we really started to face this conversion and it started to be, come closer to execution. When these, you know, big potential projects, sales opportunities came closer. Then we actually had someone that we could put in front of, you know, a value chain responsibility, making sure that we had all the way from, you know, a delivery date to a customer. We mapped back the supply chain to figure out when do we have to source? How much do we have to source? So we, we had a, you could say a global plan that we could use to instruct locally what they have to do and when they have to do it. And I think since, since last year, maybe, maybe end of last year in the fall, that's really started to show that, that because we have this, you know, a little different perspective and a little different ownership in, with our network planners. So they, they, they start to really provide the benefit here. Yeah. So now you have a person instead of a local person. Yeah. Just focusing on the site. What do we need to produce? Now we have a person looking across. Yeah. Yeah. The whole network saying, all right, we have this big order for this specific value stream that's taken all right all the way from where it comes from, the ingredients, all the way to the customer. And then they can track and make sure that that order actually get delivered according to. Yeah. And that they, we, we, we take appropriate decisions along the way, right? So we are not, we are not, if we are in short supply, we are not saving product for a safety stock over here. If we have a customer over there, right? Makes sense. So what has surprised you the most positively about this new ways of working? If you can put. I think I mentioned it already a little bit, right? But, but I think we, so we, we, I mean, the process you showed earlier in the, you know, there's no e process. We, we are, that's where we want to go. And, and we, of course, we have our own version of, of how we think that's going to look like for Otero. But we're nowhere near running that weekly cycle, you know, to perfection. So we are still in, in early maturity. But I think we are just because we, we changed our perspective and, and our responsibilities throughout the organization. That alone gives us just, I think, a different way of, of, of looking at, at our planning. And, of course, we want to mature in the process and we want to, we want to get to a place where we have very clear weekly drum beat. But because of the, you, you showed the, you know, the, the, the green, the yellow and the, the red, the different modes, right? I think we, we've had cases with each of our, you know, planner, responsible for the, for the different groups of, of products we have, where they have gone into constraint mode. To constraint mode or even some of them in crisis mode. And so if we didn't take that step when we did, I think we would have failed miserably in, when, when these disruptions sort of came, right? Makes sense. So looking ahead, you talked a little bit about it. What do you see as your natural next steps for Otero? So I think we, you know, gradually we, we will mature and we will continue to learn a lot by just being in this mode and, and, and having a different perspective on, on how we, how we manage the, the value streams. We, we, we don't have a lot of system support. I would like us to spend less time fiddling around with numbers and more time making decisions. We, we, we, we are not, we are not in a strict sort of weekly drum beat. I would like us to, I think we would benefit from, from having more, because that would force us to also prepare, you could say material in a different way. So I don't think it's strictly needed. It can be forced a little bit, can feel forced a little bit. I don't think we want to take it that far, but, but, but those are some of the things that of course we should, we should be working on that. Makes sense. So wrapping up here, if you had to give one piece of advice to other companies starting a similar journey, what would that be? Yeah, I think, I think we, you can stay, don't stay in design mode for too long, right? I think it's, it's a, it's a clear pitfall that you don't dare to take the, the step ahead. I think for us, we, organizing in this way where we have, you know, end to end responsibilities anchored globally, that meant that we had to remove some responsibility from some other functions. And there was a clear concern in the company that, you know, when, when those people were no longer having those, those, those tasks or those responsibilities, something would break. What actually happened is that, you know, nothing broke. Business continued. We just, we just had, you know, what we did, you know, back then locally, maybe some of it for good reasons, right? But maybe some of it, we didn't have to do. Makes sense. Any longer. Yeah, makes sense. And so I think that's, for us at least, that was what sort of enabled us to, to move a little quicker on, on the organization. Yeah. So I think the key message here is that you can actually do significant process, progress in your S&E by just starting with the organization and having that end to end focus before you start doing all the other things as well, implementing a system, designing an optimal process and stuff like that. Yeah. At least for us, right? Yeah. Because for us, it was the, we had a clear, you could say purpose. We had a clear reason. We knew this is, this is missing. And because that is missing, we, we have a worse delivery performance. We have more inventory. We have a worse service to our customers, et cetera, et cetera, right? We have a lot of manual coordination across the supply chain of different people trying to figure out what the others are doing, right? So I think it's, it's very important that you get clear on what, what are we trying to solve for, right? We, you know, don't just reorganize, implement SNOP if you don't have a very clear idea about what you're trying to improve. Makes sense. On that note, I will round it off here. And now it's time for you to ask questions in the chat. And I would like to invite Megel into the room here and then we'll answer some questions. Technical issues. All right. Welcome, Megel. Thank you. To these cozy chairs here, together with Rone. First questions from the crowd here is, does SNOPE require the input plan being fully unconstrained and SNOPE being the process introducing the constraints? I think actually you already commented a bit on that earlier, Nicholas, and I think that's a good point. Depending on the types of constraints that we're facing, we may want to introduce the constraint planning already as part of the tactical planning. And that's the case, right? If we're faced with very long term constraints and especially constraints that affect, let's say, multiple product lines and so on as well. Because there we need to take tactical decisions indeed about how do we best pre-allocate available supply. That should then of course fit into the operational allocation as well. But then we actually end up constraining the plan as part of the tactical planning. Thank you. And then we have another question here. In case of multi-sourcing, when do you take decisions about production sites? And this can of course be a hard decision to make across production sites. And usually when you have advanced planning tools, order based tools, these can actually help you finding the right capacity, which production site has the right capacity and then it will actually make the decision for you. But if you don't have these planning tools, then there's a manual task checking each production site on what production site actually has the capacity needed. Do you have any add-ons to that, Ming? No, I think again automating the decision, it requires that we have a tool which is capable of actually simulating these things. But again, there should be some definition of what's the general strategy when it comes to multi-sourcing. Perhaps we have a preferred supplier, but then in certain conditions, there's a backup supplier that we can activate. Then last question here around the forecast. Do you run short-term forecast adjustments before evaluating materials availability and capacity evaluations? And I can add on that as part of the process walkthrough. What is meant by the short-term forecast adjustment is that if you know the reality has changed compared to when we create the forecast that the deal didn't go through or stuff like that, then you need to adjust the forecast so it's reflecting the actual reality. So we don't start, maybe we already have pulled in inventory, but then we don't pull in even more inventory or produce even more according to that forecast. So it's a matter of adjusting the forecast if the reality has changed. And then of course if the reality hasn't changed, then you don't do any forecast adjustment. Then we have a question for you, Rone, here. If you could go back, would you start with the organization first or would you start with the process or even the system? And if so, why? I think I already answered a bit of that in our dialogue, Niklas. But, you know, so no, I would not do that. I would definitely start with it. I think it's probably very company dependent. What makes sense? Again, what are you solving for? What are you trying to achieve? But for us, definitely it made sense to not spend a lot of effort in system support. Spend some effort in process because we kind of wanted to design, you know, this is where we are heading. This is what makes sense for Otero. So there's some design decisions that fit together. And then spend a lot of time in making sure that we actually have enough resources, enough people focused on, you could say, owning our supply chain. Maybe we don't have enough people owning our network planning or tactical planning as it is today. Maybe we need even more. But I think it's also just testament that what we are doing really matters and really works, right? We see a clear benefit in it. And I think you've also emphasized the role of end-to-end ownership, establishing that end-to-end ownership. And H4O-Tera, it's crucial. And, you know, before we had that, we were relying on pure system support to, you could say, yeah, we were relying on the systems to be coordinated globally. But again, because there was no oversight, then you have decision makers, you know, in each step of the way that is maybe not always coordinated in, you know, why are we doing as we are doing. And I think that set up, you could probably succeed with, but that would require you to have really high maturity in rules, you know, in what are you able to do as a planner and different stages of the process, right? So, for us, it makes sense to be a little bit more agile, flexible, and put human, you could say, thought into the supply chain. That's the idea. But also then an example of we've identified, here is the main gap, so to speak, when it comes to actually aligning execution with the decisions taken. We need the end-to-end ownership, and this is a good starting point, even if it's not the full picture. Even though it's not perfect, and we don't have the full picture, and we are not looking at something over here, but we are picking the most important value chains. It's, yeah, it's done miracles for H4O-Tera, the last half year, year, yeah. And then another question for you, Rune. Can you elaborate a bit on the responsibility of a network planner at Oterra? I think we, so, I can try. I might miss nuances, right, because it's a little bit on the spot, but I think, you know, for us, the responsibility to me, is that as a network planner, you need, so there's sort of, you know, responsibility, but you're also empowered at the same time with that responsibility. So it's not like you are solely responsible for the delivery performance of your pigments. Our product families are pigments, product families. You're not solely responsible for the back orders or for the inventories, right? It's not like a joint effort, but it's important that because you, I'm looking at the network planners and saying, you know, how are we doing on this product? Are we, you know, in control? How are you working with making sure that we get into control? So they have, you could say, a lot of responsibility in that sense, but also a lot of empowerment to actually go to the respective sites and say, you know, I need you to stop doing this. Or I need you to produce more of this or, for me, it's really important that global oversight, global coordination sort of goes hand in hand with actually being able as a planner to take those decisions, try to steer it in that direction. Yeah, so it's a lot about this stakeholder management in general, that they coordinate with all the stakeholders in the supply chain network. Right now, where we are in our maturity, it's a huge part of it. And again, that's, you know, did we have more system support? Then maybe part of that could have been done through, you know, invisible, through systems, you know, that could steer the plans in a different way. But we're not, we're not there and I actually think it works pretty well, what we're doing. And then the last question here, how do you avoid that, is no e-meeting becomes just another meeting in the whole meeting cadence here? Maybe you, Mikkel, can you? Yeah, I think that's a tricky one and maybe you also have some perspectives on that, Rone. Of course, it's very important that the objective of the meeting is clearly articulated. It's not an information sharing session, it is a decision forum. And if there are no decisions taken out of the SNOE meeting, then it was likely not a productive SNOE meeting. That, of course, requires quite a few things. Of course, there needs to be some alignment up front. We need to have the information available and have maybe taken some considerations concerning different scenarios beforehand. But the SNOE meeting at the end of the day is a decision making forum and that I think is the main criteria. And this is what you strive towards, right? But I would say if you find yourself in having the meeting for the sake of having the meeting, then either you didn't have, you know, either decisions happened somewhere else, which could be fine. You know, maybe you had a different process in place that, you know, runs a little bit differently. It's not called SNOE, but it's called management something, right? Decisions tend to be taken over there. Maybe that's okay. Maybe you then figure out in your process, do I want to use that meeting? Do I, you know, how do I feed that meeting with relevant information if that's the case? So that could be one scenario, right? And I think if you, I don't think there's no ease for all, right? I don't think we- Also back to the escalation second. If things are relatively stable, then there's no meeting. Then maybe you don't really need it. You know, you just, you can suffice with an MRP. You could just produce according to that, no problem, right? But I think where it becomes strong is when you have those, when there's something to discuss, and the decision is a dilemma or a trade-off between some things in the horizon that is relevant for SNOE, right? Those decisions will have to be taken somewhere. So either it is facilitated through SNOE, it's facilitated somewhere else, or worst case, it's just, you know, it's just a warehouse operator that picks one product over the other product or, you know. So, so, so, so, yeah, it's a, I don't think there's a one size fits all formula for how you, how you set it up. If it doesn't work, you need to change because then there's a reason why it doesn't work, right? Absolutely agree. Yeah. That's true. And that's why the process also needs to be adaptive according to how it fits into the company in general. So, is there a need in an SME meeting? Maybe not if it's just produced according to the MRP and we have infinity capacity and so on. But if you, if you tend to have a lot of firefighting now, back to your… That is the topic. Then, then this could be, you know, this could be one of the initiatives that you could start up, right? And then figure out how, how do I then, because the trick is, okay, so how, how, how fast do I need decisions to happen? Is it like a daily thing or is it a SNOP type, you know, monthly thing? Can I wait a quarter? And typically a week is a good, you know, it gives us enough time to actually assess and analyze the, all the different, you know, data or, or analyze, understand the situation well enough. To then be prepared in a meeting to take an informed decision, right? Whereas, and, and with still some speed in the decision process. Yeah. On that note, I would like to say thank you Rune for joining us today. It has been an absolute pleasure for you. Likewise. In the studio. And then we will just do a quick wrap up. Great. So thanks a lot for asking a really good questions. As we wrap up here, a natural question to ask is, of course, where do we start? And we have already touched a little bit upon it. And the general recommendation is don't try to design the perfect SNOE setup from the get go. SNOE is a journey. From a practical point of view, where you could start is where the gap is the widest, so to speak. If we consider the journey in general, what we do is we move from functional decision making towards cross functional decision making. And we do so across the planning hierarchy. So lots of SNOP decisions that we take today are generally speaking very cross functional. We do tend to look across the supply chain when we talk about tactical planning. But the actual execution tends to be, on the other hand, very functionally oriented. What we want to do with SNOE is push the little needle between functional decision making and cross functional decision making. But the extent to which we do it is, of course, wholly dependent on our situation. That means that although the role of SNOE is fairly clear, we do want to lower the functional barriers in enabling end-to-end decision making. The actual starting point, it depends again on the context. We can work on the process. We can work on the organization. We can work on the planning tools. We don't need to solve everything all at once. So we need to start instead with a clear pain point. For example, the prioritization framework or, as an example, the rules. We start small. We create the clarity. And then we scale. Of course, we could continue to talk about SNOE all day. But we'll close here with the key takeaway. SNOE is what allows us to create faster, clearer execution based on the tactical decisions that we've taken. We've discussed the handovers, the process, and the business rules. And we've sat down and discussed a little bit the organizational aspect as well. SNOE, it's important to emphasize, should not just be another planning meeting. It must be a decision meeting which helps us to actually stop the firefighting, make structured decisions, and prioritize consistently. We'd like to thank everybody for tuning in and for engaging with us here. And also thanks to Rune for volunteering to be a part of the interview here. If you are curious to hear more, please do not hesitate to reach out. We'd be more than happy to, of course, continue the conversation after the webinar. Thank you very much. Thank you. Thank you.