Control towers - private member discussion
- reporting dashboards which track KPIs for different parts of the business at different levels
- data visibility platforms like data lakes that combine data from different tools
- transport consolidation hubs
- exception reporting systems which provide alerts
- scenario modelling and optimisation
- consolidate data & create visibility
- proactively manage exceptions
- drive scenarios, impact assessments and recommendations
- integrate internal & external partners
- converge & automate processes
- the risks (as well as potential benefits) posed by making extensive data available to external parties;
- not re-inventing the wheel when it comes to enabling technologies
- strategic data science capabilities to understand and adapt platforms and use cases
Sign up for monthly updates & session outputs
Tell us which sessions you'd be interested in joining
Transcript (edited & anonymised)
How is a control tower defined within your businesses?
Currently, there are two elements:
Analytical / reporting: dashboards tracking KPIs with the ability to view at different levels of the business
Operational / exception handling: for example, a recall or issue with sourcing a specific material. Set up a task force and build a control tower using a collection of Excel files to help make the right decision at the right time.
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.

Sign up for monthly updates & session outputs
Tell us which sessions you'd be interested in joining
Top SC Planning Best Practices...Digested
Real lessons learned distilled from a series of practitioner exchanges on...

Digital Transformation of Supply Chain Planning
Digital transformation has been on corporate agendas for some time already but, borne of necessity, tangible progress accelerated significantly since 2020. A silver lining of the pandemic may be that the business case is clearer so the focus has shifted towards implementing and scaling digitalisation initiatives.

Supply Chain Design Modelling and Analytics
Supply chain network (re)design used to come around every few years or so, often based on quite a high level view of customer segments and associated costs. Now, competitiveness and even business continuity relies on the capability to dynamically adapt network flows based on a much more granular understanding of cost drivers.

Volatility, Agility & Resilience: Next-Level Planning
Volatility, Agility & Resilience: Next-Level Planning
Volatility, uncertainty, complexity and ambiguity was already an increasing factor before the pandemic but, now, it is clear that we need the next level of demand forecasting, sensing, planning and execution.