Control towers: who, what, why and how?
This article is based on a discussion among BestPractice.Club members with special thanks to our subject-matter expert, Alex Rotenberg :
1. Top takeaways
2. Full, anonymised transcript
3. Edited comments about how members are implementing control towers
Top takeaways
There's often confusion around control towers because it's a 'buzz word' that many technology vendors attach to their products. Also, it’s not new…John Gattorna first started talking about logistics control towers 40+ years ago;
A control tower is a collaborative environment where everybody knows the goal, has the information they need and know with whom and how to collaborate as they continuously design protocols to respond to disruption;
The role of control towers should go beyond being just transactional to providing leadership and direction to the overall supply chain with one of its products being actionable insights;
Suppliers’ ability to provide accurate real-time data and automated track & trace is increasingly a prerequisite. Beyond being able to answer ‘where’s my box?”, the next stage suppliers will need to prepare for is ‘what’s in my box?” to help manage the global flow of material
A first step is usually data consolidation but that can feel like ‘boiling the ocean’ so picking the right data is key. To that, you need to do two things: define the KPIs (at a high level) you want to improve; choose a scope and identify all the disruption points along that journey and thresholds that ought to trigger alerts;
It’s usually easier to start with logistics control towers as the processes are usually simpler and they’re focused on execution;
Then, it’s about building strategies to address each of these alerts, designing the collaboration between people so they can solve the problem in a systematic, repeatable way;
Collaboration is much easier if there are standardised processes as opposed to everyone having their own way of doing things which creates and reinforces the functional silo;
A clear use case of a control tower is to close the gap between plan and execution by helping integrate S&OP / IBP processes with tactical execution / S&OE
You DO need a good data layer but BI dashboards will only create anxiety, they won't fix the problem;
You MIGHT need a digital twin.
Full, anonymised transcript
JP Doggett Great. So thanks for everyone for for joining. I just wanted to kind of begin by setting the scope a little bit for this discussion. Quite often with visibility discussions, they're what I describe as “where's my stuff right now” visibility because there's some kind of disruption going on, the Red Sea or or whatever it happens to be.
So we might get into that, but I was hoping to take it a bit further into what you actually do about that visibility, how you handle it. Minimising that latency between detecting visibility in the first place to actually handling it so you can to minimise the negative consequences of disruption, but also doing that on a systematic ongoing basis and that's quite often when people talk about control towers.
We've done control tower discussions before and quite often people will have different concepts of what a control tower is and means. So I've asked Alex who I've got permission to call my “control tower guru” to shed some light on this before we get into inviting all of you to illustrate the challenges that you're facing within this scope.
Alex Rotenberg Yes. And that's very important. I will just explain why there is so much confusion. The reason control tower has lots of definitions and confusion around this is because actually the technology companies have all jumped on the bandwagon and they are all pushing their solutions and positioning it as a control tower.
You have all kinds of technologies that are positioned as control tower reporting tools, planning tools, logistic tools, warehousing tools, any technology company that wants to attract your attention will relabel and rebrand themselves as a control tower solution.
The second thing, the control tower concept is not new. It has evolved over around maybe 40 years, 50 years. John Gattorna was one of the first to talk about it, and he's a very famous supply chain guru and he talked about 4PL and logistic control towers, but in the meantime we have supplier control towers where people track their suppliers, risks and disruptions. And we also have planning control towers. So now people are very confused because all kinds of software companies and all kinds of areas are also joining the club of all the different technologies that you have. And so that's, that's where the confusion comes from.
But to keep it very simple, we can just refer to the name control tower. It has 2 words in it. The first one is tower, so if you go to an airport there is a tower there and there are a group of experts sitting in the tower. They have a good visibility of the airport. There are planes landing, there are planes leaving and basically what they are there for is to respond in real time to any disruption that happens. So if the catering is late for the departure of a plane, they have to reschedule.
The outbound planes, if there is a weather problem, for example mist, they have to distance the planes on the fly and therefore need a control tower. The most simple definition is basically that it's a collaboration, a virtual collaboration setting where experts are sitting together, they have the best possible visibility about disruptions, they filter the ones that matter out of the big list of issues that come up the whole time (and when at an airport, it never stops), you have a stream of alerts happening all the time and they have predefined and automated levers to respond to each. If they needed to invent a solution from for when there is fog or when there is a late catering, they would never be able to reschedule on the fly like they do.
As JP explained, reducing the latency by having all the experts working in a collaborative environment with the right information, with the right expertise and with the right protocols to respond very quickly to what's happening.
And the last thing I want to say is you can't build a control tower in one day because a control tower is a learning department. It's people from all kinds of places. If you go back to the airport, you have the people coordinating the landing of certain lanes, coordinating the arrivals of on certain lanes, coordinating certain catering luggage handling. There are a lot of different experts. They are not all sitting in the control tower, but they are all part of that control tower. And they collaborate to resolve the issues on the fly. Initially some of these issues are new and then people have to learn how to address them. But then what they do is they create a protocol to be able to repeat the same solution again. So that's the real simple definition of a control tower is that collaborative environment where everybody knows the goal, everybody has all the information they need to help each other. They know with whom to collaborate as they continuously design protocols to respond to disruptions.
JP Doggett Thank you, Alex. It sounds so simple when you explain it that way, but it obviously isn't. But there's a few of you that I know have been doing some work around this, so I'll come to you guys first and then come to others. So, DG, as you just mentioned in the chat you mentioned that you guys talk about a command centre. So is that just semantics… just a different set of words to mean the same thing, or does it have a different meaning compared to what Alex just outlined.
DG To a large extent it’s just the semantics. Similar to what you just outlined with the different versions of numbers and visibility, it’s about bringing it all together and not speak about a planning tower or 3pl whatever else you mentioned multiple control towers.
So we call it a command centre now, which is customizable to bring in any data or metric you would want to see in that. So it's a more customizable version of Control Tower, but I I think it's mostly semantics in that it brings in different data sets together and combines it to a workflow to take action together.
JP Doggett And could you perhaps explain a bit in terms of where you are on that journey with the control tower? Is it fully functioning, doing everything you want it to or there are still some capabilities that you're working on?
DG It's a capability we’re working on. So the concept exists, there are some demos around it as well. The real life application of that version is not there yet. I think there's some limited control towers existing, but what I've been talking about here is that the Command Centre is very much still a concept and we hope to bring it to life later this year.
JP Doggett OK, thanks very much. M, as I alerted you to earlier, I wanted to come to you quite early on because I know from previous discussions that what Alex described as that 4PL control tower visibility piece is definitely something you've been working on. But perhaps you could expand on that and recap that for everybody else as well please?
M Yeah. So we have four global control towers in India, China and US and then I guess a global orchestrator one in the UK that is providing leadership and direction to the rest of the supply chain. And I think in terms of focus it's for our inbound to manufacturing. So they're effectively coordinating the flow of components from our component suppliers globally and then converting that from purchase order data to activities within our manufacturers and then it becomes I guess a conventional transport control tower where they arrange transport of the goods and then provide the visibility as it moves from origin to destination.
What we're doing at the moment is part of a broader supply chain transformation. In our previous 4PL relationship XXX controlled all of the land side services and then we had outsourced transport arrangements.
What we found was that it was very fragmented, very siloed between their warehouse division, their central sort of services in terms of anything beyond, you know, the shed, the transport, the customs and duty services. And with the shape of our business and some of the changes that had happened in terms of how we became much more global and how we shared the production capacity in all of our plants globally.
So some of our plants make stuff for the other plants, which changes the model slightly, which meant that the kind of visibility that we needed to run the operation accurately and to be able to optimize it, meant that we actually needed integrated visibility.
So as part of, I guess, a broader change to support the overall business plan, we decided to change our 4PL and then to change the role of the control towers from being just transactional and moving the transport and procuring the transport to actually saying your responsibility - because of your perspective and because of what you can see - is to provide leadership and direction to the overall supply chain. And one of your products, in terms of the service that you provide to us as a customer, is actually insights. If we see better we can execute better, we can see opportunities, we can design our risks, we can be proactive in terms of how we go after the supply chain mission which is the highest service level at the lowest cost with the least amount of CO2, in the most tech enabled way.
So we are at stage two in terms of, I guess, a four stage process. So the first one was data consolidation. That's obviously cleansing the data. We’ve got 22 plants worldwide who buy and consume and order differently. So getting all of those to start to consume and give us the information in a standardized way so that we could actually make decisions on behalf of the whole, as opposed to doing things business unit by business unit. We've got the business on one platform now.
I think we had various different sort of production environments, so we're all now on the same platform, which means that some of the next stage stuff in terms of EDI, or systemic tie ups between the suppliers, our customs brokers, the logistics service providers, who sort of provide visibility, have started to sort of get in place.
We've changed some of how we're setting up our sourcing arrangements in relation to global transport: if you don't have GPS, you can't work for us. If you don't have the means to provide automated track and trace that isn't about jumping on a spreadsheet and sending it, you'll find that there aren't many opportunities to work with us because it's all part of the chain.
And the less human intervention there is to facilitate that, the easier it is for us to trust the data and to start to answer the central question that the business asks of its supply chain: when is it coming and where is it in the chain? And at what point can I make a production related decision about when I can sequence and plan my production line to make sure that I'm working in an as optimized a way as possible, in terms of what our core capability
We're getting to the end of when I have conversations with our 4PL, I sort of say right now you're concerned about where is my box. The next stage is for you to be concerned about what's in it and the sequencing of what's in that box, so that we can start to do the optimization stage in terms of how we manage the global flow of material. So that's where we are.
JP Doggett Thank very much for that. Has anybody else similarly got experience of implementing a control tower that you'd be able to share with us? Please just jump in or raise your hand or unmute.
S Hi, this is S from XXX. We've just embarked on a major transformation of the last two to three years and one of the aspects of that transformation is actually trying to implement a control tower. The end goal is to have the end to end supply chain visibility, but we've had to start internally. Our products, they're not continuous manufacturing. We don't have conveyors after conveyors running off the same thing making hundreds and thousands of products on a daily, weekly, monthly basis…these are pretty much bespoke products
One of the key things we've struggled with is trying to understand where things are: once things land in production, once the material has been kitted out, once the work orders have been raised, then trying to understand where things are in production.
We're still not quite there but what we're finding is simple data in terms of trying to understand the cost per unit, the quality, the MFR, the adherence time, the idle time and the internal KPIs, we are now beginning to get much more visibility.
A) we started to get visibility; B) we’re now trying to make sense of it in terms of what that data is actually giving us and then C) we're then standing up teams. There are different layers of reviews on daily, weekly, monthly, quarterly bases, and we're then trying to unpick ... you can have so much data that you could be drowning. We need to make sure that we have the right level of data which gives you what you need and that then should enable the right decision to be made whether we change it to our processes, changes to our supply chain.
We’re at early stages and we worked with external consultants and as external consultants they can promise the world, but then the reality is slightly different. So we just embarked on a journey where we embedded some solutions into our own internal supply chain and then we're looking to extend that with our key tier one suppliers.
JP Doggett Thanks. Thanks for that, S. I think there’s lots of recognition of your context there. So we'll look to see if we can pick up some of those themes in a sec but, before we do, I just wanted to invite anybody else. Even if you're kind of at the early stages of looking at a visibility control tower, what are the similar obstacles and challenges that you're facing that you'd like us to try and get our heads around during this discussion, please, please feel free to jump in.
J The first time I actually heard about the term control tower was when I was actually working on the Heathrow third runway project. So as Alex was saying, it's a control tower. It's you're thinking, it's just flying in planes and controlling those planes coming in. But actually the reality of the Heathrow control tower is, yes, you're making sure the plane's coming in, but you've got to worry about the people you've got to worry about. And it's pulling all that data together so they can have visibility in one room of everything going on within the site. And then I try to take that and implement it into my logistics control tower, looking at the complexities of how we bring things on site and how we manage the staff that we need in the contractors that we were going to need.
I understand where people are coming from, but I think ultimately it's just really dashboards and focus areas of where you know, just using the data you've got to kind of put it in a way that people can look at it quickly and get a snapshot of what is going on.
Unfortunately, I didn't get to do that whole project. It would have been great, but COVID hit and stopped the project, but I've been able to kind of take the concept of it into other areas where I've been to and I'm kind of doing that now at XXX where we're trying to look at all the aspects of all the touch points we have within the supply chain and how we can draw that data together, but and that's obviously really complex because we're pulling it from different systems.
But there are simple ways of kind of just making little flags of spotting things that are going wrong. It's not about looking at long lists of data, it's about spotting things that are going wrong and having an indicator just to say that something has happened. And particularly now with the Suez Canal thing, you know, we're starting to see that the lead times are just stretching slightly and just looking at the normal data, it's really difficult to see. But if you can organize your data properly, you can see those flags and then you can start to see and measure how those timelines are expanding as well. So it's kind of really critical to everything we're doing but I'm doing that in Power BI basically.
JP Doggett Thanks J. L, you put your hand up. Go ahead.
L Hi, everyone. Yeah, I think J just hit the nail there. We've got so many old systems we've got like one for buying all the parts, then we've got an accountancy system that we have to then raise APO on each one and transfer the data across so it just doesn't work properly. But we've just signed up, just signed up to a new system which does the whole lot. So we're just implementing that at the moment. Well, that's due to go live, hopefully at the end of April, beginning of May.
But I think we need to look at our data that goes across to make sure that we're not bringing old data that can corrupt reporting and stuff like that. So I think we need to get to a stage where we're bringing the correct data across so we can start fresh and just make it work. I think the control tower would work perfectly for us that that whole scenario would work.
JP Doggett Thank you, L. Thanks for that. I'm just actually trying to find the write up of the last session we did on control towers because what came out of that was to do kind of almost mini control towers around particular processes and have those dashboards and then kind of stitch all of those together somehow. Maybe I'll turn it back to you, Alex, if you can kind of give us a few thoughts on, you know, where do you start and how, how do you future proof it so that you know that you're you're heading in the right direction and can end up with an end to end control tower?
Alex Rotenberg Starting with connecting the data is the perfect way to start. But as you say, JP, if you start with the data part, you will probably end up with an ocean of data and then a big struggle to figure out how you make all these people we talked about collaborate. So instead of starting with the data, my experience is you need to start with two things actually. First of all, you need to start defining which KPIs you want to improve, which needle do you want to shift. And you need to have it almost at an executive level or at a more macro level. So you need to find the big needles that you are going to shift, whether you're going to optimize in that control tower and then based on the KPIs that you have selected, let's say you chose service, inventory and cost of suppliers or whatever you choose, you will have a certain scope of process that this control tower will cover.
We heard about one starting with transport and then they extend it to the plants. Others start their control tower in the supplier world and they want to see Tier 1 suppliers or they want to see tier one and Tier 2 and Tier 3. So it's all depending on which process you are going to cover in your control tower and which KPIs you want to affect and if you visualize how that looks that end to end process, whether it's Order-to-Cash that you are going to track or Procure-to-Pay or Plan-to-Deliver, whatever you choose as a scope, what you want is to find all the disruption points along that journey. So if you map a process like order to cash, there are a lot of disruption points where siloed departments are not really sharing the data effectively.
So you want to understand these breakpoints. If it's logistics, it's easy and that's why our control tower started in logistics, you send the transport over to the truck, then you can check if it leaves the warehouse at the source, if it's on its way, did it go through customs, is it's on its way to the plant, has it delivered the product…the milestones and everything that is critical for the success of that step is easy to track. So the logistic control towers that John Gattorna had in mind were easy to build because they are purely focused on execution and the process is very simple to map out.
You might have different journeys and so you might have like I had at Syngenta, when I implemented the control tower, you might have a bulk transport. You might have ocean transport, you might have different regions with different carriers and different setups. So of course even transport can be complex because you can have a lot of different scenarios that you need to track in that control tower.
So you need to choose the geography also the scope to start and learn and extend it. For example you start with road and rail in Europe and you say I want to reduce the transport costs and improve the on-time deliveries, right? So that's how you start the journey and I use logistics very consciously because it's the most simple one. But as many illustrated here on the call, very often it's a much larger process that we are talking about which involves suppliers, tracking the plans, how they collaborate. And so that’s a much broader process than just the transport process. But I think if you define the KPIs that you're improving and then you define the scope of the processes that you're going to cover, that's a way to create a boundary around what you need to collect because you want to see the disruptions on that journey, right? So that's the data that you are going to collect.
As soon as you have visibility about these issues, then it's about building strategies to address each of these alerts. So you're going to design alerts and you are going to design collaborations between people and you are going to ask them how they solve this problem.
When you have understood or mapped out how they solve this problem, that's a use case.
I will give a very simple one for a well-known retailer about a control tower for product recall. So imagine the product has a problem. There are probably three options: destroy it in the shop; bring it back to where it comes from, or do something else with it.
If you can automate these responses and manage all the product recalls, you can do it much faster than if every store has to figure out how to do product recalls. That's a typical use case and so after you define your KPIs, you define the process that you want to track and where the disruptions in the silos are creating problems to respond to issues.
The next thing, as I mentioned, is to define the use cases that you want to cover and, typically, advanced companies who want to do end to end things. Start with a few use cases.
For example, if a company wants to put a control tower in the markets to make sure all the products are coming on time to their distributors, they will have three first use cases: inventory deployment, expediting transport and rescheduling the production line, right? That could be the three first use cases and then they will document all the alerts that are related to on time delivery for that process the warehouse to the distributors and they will build the collaboration to address each of these three use cases that I mentioned and they might do them in sequence or they might leave it to the control tower to decide which option they choose.
There are different ways to do that, but that's how you start. Then you can add more and more use cases that they may experience is the fastest way to either broaden the scope within that process or you can start extending the process like code design does and add more and more use cases outside that process boundary, but always in a controlled way. I would say otherwise. It's not a control tower. It becomes chaotic.
JP Doggett Thanks, Alex. E, you've got your hand up.
E Yeah. Thanks. I just wanted to really just say, Alex, I think you're absolutely spot on…I think it's so important to start with the end state because otherwise what are you aiming for? And without mentioning the names of two rather large retailers that I've worked for and on both occasions where I've put in a slightly more localized control tower and there's lots of different descriptions of control towers, we can tell from the conversation this morning, just the different areas they they they require different approaches, but I I put in a couple of times control towers that involved not only the internal practises but also the the external stakeholders.
Taking Alex's point, I set those KPIs really clear but equally there are some of those KPIs that I knew that probably for the next 12 months. I couldn't get a hold of that data, but it didn't stop me from articulating that they were the KPIs and the effect that that had, particularly with the external stakeholders, which I really wanted to affect the most was that they started aiming for those KPIs even before we had the data to start driving the efficiency. I just knew it was something that needs to be changed, so effectively what I'm attempting to highlight here is that even if you don't have the data yet, as long as you've got a plan for bringing it in, don't delay broadcasting that. Have a really clear intention. The end state in mind.
Alex Rotenberg Thank you, E. Any other reactions or experiences about how to scope the control tower perimeter?
DG No, not on the scope, Alex, but can you elaborate a little bit about your collaboration aspects? Do you see that as highly structured?
Alex Rotenberg Yes. So I come of course with the Lean 6 Sigma Black Belt background. So when I worked for that chemical company where I created a logistic control tower across all their transport modes and to export the chemicals to the whole world, the first focus was to get visibility from all these exports and understand all the steps that this material flow was taking to get to their customers.
But then what I started to do is I designed a KPI dashboard for this, exporting the logistics, exporting that was in charge of taking the delivery at the plant and then getting it in the market to meet that order and to coordinate all the logistics, all the paperwork, everything that was required to to get the load in the right country, often from Switzerland or from the US. But so that was the scope. I designed standard work for every person in that control tower, so all export managers were going through the SIPOC process with steps, inputs and outputs. There were of course variants because you don't export a chemical to Iran in the same way as you export it to the US for example, from Europe, that's totally different. So there we have variations for the different logistics teams and there were variations also for how they collaborate with the transport companies we were working with, but what you want to instill is a kind of standard because as the Japanese say, and I'm in Japan right now, where there is no standard, there is no progress and as we discussed a lot on this call, you never get your control tower from day one. It's a continuous improvement journey where you extend the use cases, you learn, you collect the data you dashboard and you learn how to respond without latency.
You need to build it like a learning organization. You need to build it based on standard work that does two things. First of all, people are aligned with the KPIs that we mentioned. But second, when people are working with more precise procedures, it's also much easier to make them collaborate with each other than if everybody does it in their own way. So that's the simplification. That's accelerated my success at Syngenta, where I implemented that control tower.
DG So you are enabling or facilitating the standard collaboration, not the exceptional collaboration?
Alex Rotenberg The collaboration of the process maps that we were building was to improve these KPIs. But where the inputs and outputs and all the steps that they were going through in that control tower to resolve all the issues and all the touch points with all the departments where they had silo behaviour and problems, that's what we mapped out. And because the SIPOC is perfect for that because you have the inputs and the outputs and you know which critical inputs are broken, right? And it's always due to siloed behaviours.
DG Yeah. Yeah, I understand. Yeah. Thanks.
Alex Rotenberg Whenever you have a broken input in a process in a big company, 90% of the time it's because there are silos and they are not working towards the same goals or they don't share information properly or they don't collaborate properly..
JP Doggett Thank you, guys. G, you have your hand raised.
G Yeah, thanks. I have two questions. The first one is I acknowledge that different companies obviously had different effects of implementing a control tower that we have discussed so far. Have you had an experience of typical examples where companies are intrigued by a control tower functionality, but it doesn't necessarily add value?
The second part is. How do you manage the security aspect of having this fine, detailed information about where a truck is at any single point in time? Because there's probably several on this call that have quite expensive loads on these trucks and the risk that they might be ending up in the wrong hands, so to say.
Alex Rotenberg Very, very good questions. The important thing is to think beyond the control tower. So when you design a control tower, there are three dimensions that you need to think through:
The first one we talked about a lot very extensively, right? Which data do you need to track the right KPIs, which data do you need to see the alerts for the process that you have defined and which data do you need to respond to the alerts that you see right? Whether the reports, the information, the drill downs, the drill downs, the root causes that you need to be able to see, that's data.
But beyond that, you need to connect the processes, right? So you need a good data platform, but you also need to connect the process so you need to align the process across, for example, if you do Order-to-Cash, all the departments that are involved. Otherwise you're not going to succeed because as I mentioned at the start of this call, it's about collaboration between silos on a process that spans across several departments. And so to answer your question why people don't get value - and 90% of people building control towers don't get the value - is they choose the wrong technology to connect the data parts.
So if you do it with the BI tool, you're going to fail. Why? Because you're only going to see issues that you are not going to be able to respond to in the system. And so you will have anxiety because you will see more and more problems, but you will not have a way to solve it. The right technology is the one that allows you to see your KPIs and then when something is red or orange, you need to be able to do it in the system because otherwise you have this problem that we discussed that you have to go to many systems and then it's not standard work anymore because North America is using is using this system for other entry and this one, this one and the end, you get a mess.
So you need to find the right data platform and very often it's like a data platform is very light but sits on top of SAP instances and others. So you need to find that middle layer where you have these KPIs, the workflows to respond to them and all the information, drill down and understand the problems. So technology is important for the data.
The second reason why there are failures is the process, right? So if you choose a process within one function, the control tower is useless because for example, if you do a control tower from one factory, you can do that in a scheduling tool or in a production tool or an MES…they have the alerts. You can manage everything within the plants with that system. You don't need a control tower. The MES, the manufacturing execution system, or the OR the scheduling tool is already your control of that right. So if you choose the wrong process, too narrow and only with one function, we are going to fail as well.
Recommended by LinkedIn
And then the third thing is collaboration…you need to connect people. If they are not collaborating to solve the problems, you still don't have a solution, right? And we discussed it, how do you make people collaborate? Well, first of all, they need to have standard procedures to respond to alerts. That's clear. They need to have the same information. All of them need to see all the information about the alerts they are supposed to track and cover and to resolve.
But they also need to know who to work with for each of the problems. That needs to be codified so that they can work as a virtual team and find the best solution. I gave this product recall if the store manager doesn't know who to work within the control tower and which experts in that control tower will be able to guide him through that problem that he faces, the latency will not go. And so why do these initiatives fail is because they are not connected in terms of data, not connected in terms of processes and not connected in terms of people. One of the three. Otherwise you always have a benefit from creating that visibility because you remove friction from the processes, yeah. Does that answer your question?
G Absolutely. Thanks a lot.
JP Doggett We do lots of sessions around planning whether it's S&OP, IBP, choosing planning platforms…a lot of the same issues are coming up there, right? You know, how do you break down the silos? How do you get that collaboration?
What often happens is that people may get a better plan, but then quite often they're not really able to execute that plan. So nothing's materially changed. You've got a better plan, but the performance doesn't change.
A lot of energy and effort goes into the plan side of the equation so I guess my question to you, Alex, in particular or anyone else who you know on the call is how should supply chains be looking at planning and control towers in tandem because they ought to dovetail, right? Unless I'm misunderstanding something here?
Alex Rotenberg So you can build a very good control tower for logistics and get a lot of value from that as well. That's possible. You can build a very good control tower just to track your sourcing and make sure that you have visibility on inbound flows without having any planning involved and so tracking what's happening with your suppliers, that's very valuable.
But the most valuable types of control towers are control towers that address your end to end supply chain which is plan, source, make, deliver. And if you can add return then you have a world class control tower, right? If you can connect all the processes end to end for your entire company on the planning level and the execution level, then you have a world class company. But I don't know any that have it. Maybe Amazon is close to having that kind of control tower, but I'm not sure.
If you want to be a world class supply chain it's to connect planning to execution and how do you do that? Basically, within the same way as we have been discussing by breaking silos that prevent planning and execution to operate efficiently.
What are the main silos that you have in planning? In planning, you have a silo between the tactical planning which is S&OP and the short term scheduling and execution of it [S&OE], there is a silo because typically different planners do it and then they throw their problems over the wall.
So there is a lot of dysfunction because the whole horizon is not covered, but through a control tower, you have people focusing on the short term and people focusing on the S&OP. And so the people who make S&OP decisions, they throw them over the wall and then they are not feasible anymore and the short term schedulers and logistics people, etcetera, they do whatever they can to implement the decision that was that we were deciding S&OP. So first of all, if you want to build a control tower that is end to end you have to start with planning because it's an overarching plan, source, make, deliver and then you have to connect what Gartner calls Sales & Operations Execution, so you need to have a control tower that covers both horizons, right, the tactical horizon and the shorter horizon.
So that's why planning is so important as part of the control tower…it is the glue. It's the one that will allow people to execute what they plan for and understand the gaps between the plans and execution much faster. Plan, do, check, act is the loop that you go through right as a company.
M I think that's that's that's the problem we're trying to resolve in terms of the gap between planning and execution and what we're trying to do at the moment is provide a feedback loop so we see the implications…
We see a rolling 12 month view of what we intend to order from our suppliers and then as they execute that, we see the implication of that in terms of the activity in the supply chain, whether the inventory is going up or down, whether the rate at which we're consuming the inventory goes back, the rate at which the planners are doing planning related exceptions.
So it's not, “I can't see where it is, therefore I'm going to expedite it from from the supply base” and then we're using those insights to say, well actually if you look at your day's inventory, if you look at your supplier performance and then we make the control towers responsible for the transit time data that goes in goes into the planning parameters. So there's an actual tie up between how the control tower is operating in terms of how they manage lead times, transit times, you know their main KPI which is on time collection and then as frictionless a transit as possible. We're keeping that plan, the plan and the execution piece always together so that everybody can see the implications.
We don't quite have all of the you know the parties involved in terms of right now we're focusing on the planning guys because they effectively create the workload that drives the activity in the supply chain. What they haven't had as clear is the accountability of what those plans are, where we can say, listen, the day's inventory that you've created is X. The impact that's had on the supply chain is that we've, for example, had to go into outside storage. We've had to do this or we've had these levels of stock outs, you know that have affected these plants and then we refine that loop and and and check whether we've done better in the cycle.
But I think if you don't have that feedback loop back into the business which is you know the collaboration that you're talking about, it makes the whole process of having all of that data less relevant to what the business is trying to do.
Alex Rotenberg Exactly.
M I think when we started two years ago, we were sort of saying right now we are the deliver portion of the business and we have no influence on what's happening in the plan, but we're responsible for all of the costs and the associated exceptions that are related to that. In terms of the business, we'll say, well, we've spent so much in terms of working capital, why didn't we do X or Y Z? So we're providing that question that if you did this, here's the implication. So I think we're probably six to twelve months away from being able to say, right, here's the twelve month schedule, here's the modeling. What we've got is too much for the pipeline. What do we do, do we stagger, do we slow down, do we speed up?
Or do we have a conversation with the manufacturer or the supplier and say we're going to make a commercial commitment to this, but the sequencing of it and how it flows through the supply chain, we need to change what's the implication on you? And you can then have a sensible conversation with the rest of the business as to the implication of certain buying decisions, certain locations. I suppose the biggest use case that we've had at the moment is obviously the Red Sea issue created, depending on the supplier and the capability of the supplier, a four to eight week gap in terms of the inventory, which meant that you either had to expedite the inventory or slow down your consumption, or do something to make sure or add significant air freighting.
What we were able to do this time around, as opposed to Suez, is we saw the implication, we saw what needed to be air freighted and we actually did an air freight tender probably about four weeks before the initial air freight market spike happened. So we'd secured prices for preferential air freight for what are pretty heavy items, probably four weeks in advance of the market, taking a pricing position based on there being a shortage of containers and vessels being misaligned now because of the different routes around. So it's really useful from a risk management point of view as well, in terms of being able to say it isn't just the transactions, the execution of the transport, it's the ability to manage those significant exceptions much more efficiently.
Alex Rotenberg You said the most important thing: basically if you include planning what you do you move away from just resolving issues. And if you only have execution in your scope, you only resolve issues reactively. But as soon as you do planning like you say, you can be proactive. You can detect a problem like the Suez problem much earlier than the competition even. And it's therefore much cheaper and much faster to course correct and the damage is much less.
Yeah. So that's really what the control towers are about. It's really risk mitigation in the end.
JP Doggett Guys, I’m conscious of the time. So we'll wrap up in a second. I just wanted to come back to Alex. You began by explaining why there's confusion because there's lots of different technologies that are being associated with control towers. One of the technologies that seems to cause a lot of confusion is digital twins.
How necessary are they? Do you need a digital twin to have a control tower? Is that what you should ultimately be aiming for? What's your 2 minute take on that?
Alex Rotenberg Yes. So I'm working a lot with the energy industry right now. Obviously if you go to Shell, BP or an energy company, they have digital twins of their assets, right? They have IoT on their pipelines, on their refiners and they know everything that's going on at any time for safety reasons because they don't want casualties. They don't want problems so they track their physical assets. So when they are thinking about now - and that's very relevant to everybody here - if we want to really be much more agile and responsive to how we need to transition to biofuels and other alternatives, we need a digital twin of our supply chain…it's actually critical.
So if you want a supply chain control tower, you need a connecting technology that will connect all the data from all the processes that are in scope and that means a lot of systems, right? Because even if you work for a company, for example, who has three SAP systems, one in each region, it's a mess. You need a connector on top to build a digital twin. You need to have a unified data model to visualize your supply chain end to end. Otherwise you cannot track the supply chain end to end. It becomes too difficult.
JP Doggett OK, I do have another question which I haven't got time to ask, but we're planning to do something on cybersecurity for supply chain because I think the more you get these IoT and interconnection between different parties, the more you need to start thinking about your cybersecurity risks. I probably haven't got time to get into it now we’re one minute left on the call, but hopefully that makes sense. You're nodding, Alex, but hopefully that's kind of going to tie into this a little bit as well.
So I'll finish by just saying thank you very much to everybody for joining and participating. Thanks especially to Alex.
Edited comments about how members are implementing control towers
How is a control tower defined within your businesses?
Currently, there are two elements:
In the future, it will be a tool that provides end-to-end visibility with scenario planning capability to make changes live and see whether the decisions we’re taking are really shifting the dial.
---
We’ve collaborated with Gartner on some of the definition setting as it’s very important to get everybody aligned and to make sure we’re talking about the same thing. Based on the CORE framework or hierarchy with configuration at the top, then optimisation, response and execution as the base level, which is where a control tower, as we define it, sits.
What we call a ‘command centre’ is at that optimisation level and then the digital supply chain is at the top full configuration level to see how it all sits together.
What’s important is that the control tower can be fairly small, focusing on one kind of execution, whether deliver, warehousing etc. For example, we’re doing some pilots on temperature excursions with transportation having really controlled exceptions that could be linked to manufacturing quality issues. By the time you start connecting, that’s where the digital twin comes into place and you move from execution level to optimisation or, longer-term, configuration.
Another example is around planning sensitive parameters where the control tower monitors the execution of different lead times, adherence or other parameters and then maps that to a configuration that we integrate into our planning systems services for inventory optimisation and modelling.
---
We have a global set up with manufacturing on four continents. What we term our global control towers are really transport consolidation hubs that take all the flow from our suppliers and manage that into the business. We’re currently changing our global logistics which presents an opportunity to also change the scope of the control towers.
Under the new structure, the control tower will have leadership and direct responsibility for the entire supply chain as they effectively create the demand that goes into our downstream supply chain.
There are four or five steps to get to the optimum orchestration capability of the control tower starting with consolidating all the data such as purchase orders and manufacturing schedules and the flows that are part of that process. It’s a kind of master data schedule that has every possible unit SKU that would be entering our warehouses and into production, progressively going from base consolidation to end-to-end visibility.
At this level, we’re talking about dashboards, alerts and exception management based on a single integrated view. As we progress, we’ll add what we’re hoping would be an autonomous capability encompassing descriptive and predictive analytics with some kind of big data viewer that integrates multiple views that are not available from ERP, even if combined with our TMS.
Once that’s working, and external partners are integrated, stage four will be process orchestration combining internal and external collaboration, centralising planning elements and almost automating sales and operations processes, integrating that into things like space management, warehouse management, customs and duty…global trade type optimization. We see the control tower being where our physical supply chain meets our digital supply chain.
Because we currently operate in regional and country silos, a lot is falling between the cracks with exceptions that we’re looking to design out with the control towers. Right now, it’s transport management but, in future, it will be a global orchestration platform that allows us to make decisions from end-to-end and actually understand the knock-on implications, for example, for our emissions and all those kinds of things.
---
For us, it’s very similar. We’re starting with a supply visibility tool to cover purchasing through to delivery but which doesn’t do any capacity or logistics network management. We’re trying to leverage data which is already there so it provides SKU-level data on all of our products. We’re creating a Power BI dashboard in-house because the user interface of our forecast and replenishment tool isn’t that great. We’re generally planning to do everything in-house.
---
For us, although it’s outsourced, it’s as close to in-house as possible as it’s built around a strategic, long-term relationship with our logistics partner.
---
The second step is demand orchestration, aka demand smoothing or demand capacity planning. We want to create a tool that can manage the peaks and troughs of demand with the context of warehouse or logistics constraints. For example, visibility on containers, container contracts and pricing which have changed a lot over the recent past have an impact in terms of scenario planning.
That’s where the lines can get blurred…is this still a control tower?
---
It’s really important to make this distinction clear: one, you don’t want to duplicate efforts and capabilities but, even more importantly, if you have duplicate systems with different results, there will be confusion throughout the organisation.
---
The relationship between them is key: would you be able to update your demand plan from this demand capacity plan or should they stand completely separate from each other?
---
One of the ways we’re looking at it is actually updating the parameters into demand planning but not the demand plan itself. For example, demand sensing updates like PoS data from customer intimacy tools and publish those parameters but without generating a second, duplicate forecast.
On external manufacturing, the other aspect is controlling the execution layer. It’s about what kind of exceptions are flagged day-to-day with real time visibility and how to respond to them, rather than the holistic plan which we try to do in our planning environment.
---
We’re at an earlier stage but the key for us is that we have 16 autonomous businesses that must remain autonomous in their decision making but we want to make use of our scale to make informed decisions and find efficiencies. First of all, terms like ‘control tower’ are not generally understood so we keep it simple by talking about end-to-end visibility i.e. what we’re trying to achieve.
So, it’s a control tower in the sense that it allows the operating businesses to benefit from being part of a group whilst preserving their autonomy.
One of my key interests is, what elements do you bring into that control tower first? For us, we try to look at the key elements which are common across all of the businesses so that everyone stands to benefit and nobody feels alienated and picking areas which have got the least risk.
---
We’re at very early stages in that we don’t have anything in place yet. Similarly, we have 15, 16 different manufacturing operations all doing their own thing with different systems and standards so it’s important for us to understand what we want from a control tower. It’s interesting that there’s no single definition but, in essence, it’s about real-time execution monitoring across the end-to-end supply chain. In my mind, I would keep planning separate.
---
We too have 10 or 12 product-defined businesses which are autonomous, each with their own MDs, P&Ls. Although they make different things and compete in the market differently, they all consume logistics in exactly the same way: they all want to know ‘where is it?, when is it?, how do I get it on to a production line and how do I reconcile the costs that are unique to me through participating in a group process?’
Whilst supplier relationships are tied to the different production business units, we control the inbound manufacturing process. We’ve decoupled the planning element so each business unit still does the planning and purchase order creation but we, as the control tower, then take over in terms of the physical movement but at the point that they create the demand for suppliers to manufacture. That gives us a much earlier indication of potential issues in the supply chain. For example, we’ve got a better handle on lead times because we’re now interacting with suppliers whereas, previously, unreliable shipping was a big challenge for inventory management. We might have ordered 100k units but would only find out there’s only 90k at the point of receiving the goods…now we know at the point that they’re ready.
---
It’s a common problem: we have seven operating companies and around 4,000 stores and they all have different options and priorities. We have the advantage that they’re all using the same planning tool which helps with aggregating the data because there are customizations but there is a big challenge around data generalisation…putting all sales in the same bucket, putting availability under the same KPI because everyone’s got their own approach.
---
We have approached this by having common dashboards with common KPIs for demand, in-store availability, OTIF, waste etc. They’re not unified but all units in all regions are using the same dashboards. We can use them right down to the planner level so we can aggregate and disaggregate as we need to. The limitation is that we can’t see the interactions between them, for example, between forecast to service to waste. It’s also very slow due to the amount of data to process. It does save a lot of time, though, as it’s a self-serve tool.
However, it’s not dynamic and it doesn’t have exception reporting and no alerts so we have to figure out the issues. The next step would be to use these tools to make good decisions about influencing your parameters in the supply chain…the command centre element.
---
We’ve outsourced our global control towers to a company that has a lead logistics provider role so they have operational responsibility for the physical movement of goods and any transport related elements. The command centre elements are supply chain development responsibilities so they have to optimise more than just physical movements, also incorporating warehousing and related logistics services.
---
That’s the point: you can have a control tower for transportation or warehousing or manufacturing and then the command centre element brings together all those visibilities to optimise your end-to-end parameters.
---
A key challenge with consolidating the different purchase orders is the financial reconciliation of that which can get quite complex. But still, that’s against the clear benefits of solving a number of problems including customer service, better space planning, better compliance which we’re designing out instead of firefighting.
Why the apparent preference for in-house capabilities?
For us, it’s that data is really an extension of your organisation so there are both opportunities and risks in making that data available to other organisations. We took the view that we’d rather do that through a trusted relationship rather than multiple partnerships with visibility providers.
Also, that consolidation happens at the point closest to the physical movement of the goods we need to track.
---
There’s a practical point about not reinventing the wheel when it comes to software and platforms but agile development is important so that the order is crawl, walk, run. First, create the visibility, then drive the exceptions, then drive scenarios, impact assessments and recommendations before you start automating.
Also, having our own data science team who can go into whatever platform and test algorithms or certain use cases and adjust them accordingly is a critical requirement.
What about getting data from suppliers? There can be pushback due to the multiple demands to provide data on multiple platforms etc.?
Most of our stuff is moving across the border so there are already compliance requirements which we then apply an element of standardisation to. There are also incentives in terms of suppliers helping us to be able to pay them on time by having accurate and timely data.
It also helps to communicate more accurate and longer-range forecasts back to the supplier so that they can manage their investments, working capital and raw material supplies better. We’ve moved from 3-month to 12-month forecasts for tier one suppliers which helps avoid preventable problems later on as they can make sure they are properly set up to deliver. It helps that, in our case, actuals to forecasts are in the high 80s / low 90s which minimises the risks for the supplier and us.