WEF Adds 16 Global Lighthouse Sites for AI-Driven Supply Chain Excellence

The Analysis

Sixteen sites went onto the Global Lighthouse Network on 19 June, and the announcement puts the membership at two hundred and thirty-eight. The three use cases the release names are predictive maintenance, demand forecasting and autonomous quality inspection. That is the whole factual payload, and I want to be plain about how thin it is. No throughput figure, no labour number, no scrap rate, no payback. A list went from two hundred and twenty-two names to two hundred and thirty-eight, which is arithmetic, not evidence.

So let me model it before somebody models it for me. Think of your plant as a queue. Jobs arrive, they wait, they get served, they wait again, they leave, and what your customer feels is the sum of those waits plus the work. Cycle time equals waiting plus service. Of those three use cases, one attacks the loss of a server, one attacks the size of the batch you release, and one attacks how long a human stands looking at a part. Those are three different purchases and only one of them touches waiting, which is where most of your cycle time actually sits.

What the list is genuinely good for is telling you where practice is heading. Three problem areas, repeated across sixteen plants admitted in one round, chosen by people who spend their year inside factories. That is a hint worth an hour of your attention. It is not a forecast of anything at your site, because every member was selected before anyone measured it, and selection is not a detail you wave away.

Start with the only number we were actually given. Sixteen added to two hundred and twenty-two is growth of about seven per cent in a single intake round, and sixteen as a share of the new total is roughly six and a half per cent. I can do both sums in my head and neither one pays for a single accelerometer. A membership count rises because the people running the programme decided to admit more members. Your throughput does not move because a committee met.

To treat any of this as evidence I would need three numbers that are not in the release: how many plants were assessed, how many of their deployments were quietly shelved part way through, and what happened at the plants that tried and stopped. Without them you are looking at survivors only. I have walked enough plants to know that the pilot switched off in month four never makes it onto the tour route, and the version of the story that gets told is always the version after the messy quarter was edited out.

Here is the practical consequence. Every percentage you ever hear quoted about these sites was measured on somebody else's equipment, with somebody else's product mix, somebody else's maintenance history and somebody else's labour rate. It is a claim, not a fact about your operation. My rule is simple and I have never had cause to break it: no external percentage enters a decision document until it has been restated as counts on my own line, over a period I chose, with a denominator I can see.

Now the translation into your four accounts, because that is where a list like this either earns something or does not. For cost, all three use cases attack operating expense and none of them touches your freight bill, your tariff exposure or your energy contract. For lead time, only inspection sits directly on the service term of the queue, so only inspection can shorten cycle time on its own. For compliance, the automated inspection case creates a recordkeeping obligation you do not have today: if a machine decides a unit is defective, you need a traceable record good enough to defend a customer claim and, for anything regulated, good enough to show an auditor. For inventory, forecasting moves the most money, because every point of forecast error you remove is buffer you either release or redirect.

Take predictive maintenance first, and take it as a decision rather than as a technology. The decision it replaces is this: do we stop this machine now, or do we run it to the next planned window. Today that decision is usually made by a planner working from a calendar route sheet, or by nobody at all, which means the machine decides when it fails. The latency that matters is the gap between the first physical sign of trouble and a work order being raised and scheduled. Measure that today, in hours, before anybody shows you a dashboard.

Then ask who carries the miss. If the model flags a bearing and nothing happens for eleven days until the machine stops anyway, the failure is not in the algorithm, it is in the handoff. Put a name against that handoff. In every deployment I have looked at, the role that actually determines the outcome is the maintenance planner who has the authority to pull a machine during a production week, and that person almost always has the least spare capacity in the building. If the answer to who acts on the alert is nobody in particular, stop before you buy anything.

The control design is not complicated and it does not need a statistician. Keep planned-preventive maintenance on comparable machines in the same cell for the whole trial, change nothing else, and compare unplanned downtime hours per thousand machine hours between the two sets. Randomise at the machine level where you can, and record the reason at the time of every stop, because six weeks later nobody remembers why a line sat idle on a Tuesday. Set the stopping rule in writing before the first alert fires. Mine would read like this: if unplanned downtime in the pilot set is not at least twenty per cent below the control set over eight consecutive weeks, or if alert precision falls below twenty-five per cent for two consecutive weeks, we revert to calendar-based service for that cell and we write down what we learned.

Demand forecasting is the same template with different nouns. The decision it replaces is how much to order and where to put it, and the latency that matters is plan refresh latency: how long from a real change in demand to a changed purchase order. If your forecast is rebuilt monthly and your demand moves weekly, no model will save you, because the bottleneck is the calendar, not the arithmetic. Fix the refresh rhythm first and you get much of the benefit for the price of a meeting.

The right control here is a holdout set. Pick forty of your two hundred and forty active items, chosen across fast and slow movers, leave them on the existing method, and score both sets weekly on weighted absolute percentage error, on bias, and on the two numbers the business actually feels: stockout events and expedited freight spend. Pre-register the primary metric. If you let yourself pick the metric after you see the results, you will always find one that flatters the model, and I say that as somebody who has caught himself doing it.

The measurement trap is worth spelling out. Forecast accuracy is not the goal, it is a proxy. The goal is inventory turns and service level, and accuracy only matters to the extent it moves them. A model can be more accurate on average and worse where it counts, because it is the tail of the error distribution that triggers expediting. Score the ninety-fifth percentile of absolute error on your top twenty items, not the mean across everything, and write that number on the same page as the accuracy number.

Automated quality inspection is the one I would look at hardest, and not because it is the most glamorous. It sits on the service term, so it is the only one of the three that changes your cycle time directly. If inspection currently takes nine seconds per unit and your line produces a unit every one and a half seconds, inspection is your constraint and everything upstream of it is queueing. Speeding up inspection in that situation does exactly what queueing theory says it should: it shortens the line behind the station, and nothing else you do matters nearly as much.

The decision it replaces is binary and human: is this unit good. The latency today is operator reaction time plus the walk to the reject bin, and afterwards it is the cycle time of the station itself. The person who carries the miss is whoever signs the release of a lot, and in most plants that signature has never been questioned because it belonged to a person with twenty years of experience. Move it to a model and you have changed who is accountable for escapes, without necessarily telling them. Write the accountability down before the first shift runs.

The record obligation is the part that bites later. Human inspectors absorb the edge cases and remember them; a model records a score, and a score without an image and a version is worthless eighteen months later when a customer asks why eight hundred units shipped with a scratch pattern. Retain the input, the decision, the model version and the operator who overrode it, for a period matched to your claims window. If you cannot retain images for that long, you do not have an audit trail, you have a log file.

Now three sums, with every assumption stated so you can argue with it rather than with me.

Assume a production cell of twelve machines. Assume each machine loses eighteen hours a quarter to unplanned stops, so the cell loses two hundred and sixteen machine hours a quarter and eight hundred and sixty-four a year. Assume one machine hour of downtime costs six hundred and eighty dollars: four hundred and twenty of lost contribution plus two hundred and sixty of recovery, expediting and rework. Current annual cost of unplanned downtime is eight hundred and sixty-four times six hundred and eighty, call it five hundred and eighty-seven thousand dollars. Assume the deployment costs sixty thousand dollars once for sensors, integration hardware and installation, twenty-five thousand a year for software and support, and forty hours of extra line stoppage at an assumed contribution of one thousand nine hundred dollars an hour, which is seventy-six thousand.

Year one costs about one hundred and sixty-one thousand. To justify that you need to remove about twenty-seven per cent of current unplanned downtime hours in year one, and about four per cent a year thereafter. Anything less and the money was better spent on a second maintenance technician and a torque wrench.

Assume that within that cell you have one hundred thousand machine hours a year of telemetry and that four tenths of one per cent of machine hours are followed within forty-eight hours by an unplanned failure, so four hundred real events. Assume the model catches seventy per cent of them, two hundred and eighty events, and that avoiding one costs one thousand one hundred and fifty dollars of downtime, recovery and scrap avoided. Gross benefit is three hundred and twenty-two thousand dollars. Now the precision assumption, which is the one that decides everything.

At eight per cent precision the model flags three thousand five hundred events to find those two hundred and eighty; assume each investigation costs one and a half technician hours at sixty-two dollars loaded, ninety-three dollars. Three thousand five hundred investigations costs three hundred and twenty-five thousand five hundred dollars, and the programme is three thousand five hundred dollars underwater before you paid for the software. Break-even precision is about eight per cent. At twenty-five per cent precision the flag count falls to one thousand one hundred and twenty, investigation costs one hundred and four thousand one hundred and sixty dollars, and the net is about two hundred and eighteen thousand. Same recall, same data, wildly different answer, decided entirely by how many false alarms your technicians will tolerate. That is why the acceptance threshold has to be written before the pilot starts, with the maintenance planner in the room and not in the demo audience.

Assume two hundred and forty active items with average weekly demand of one hundred and eighty units and a six week replenishment lead time, targeting ninety-five per cent availability so z is one and sixty-five hundredths. Assume weekly demand standard deviation is approximated by your forecast error expressed as a share of the mean. If weighted error today is thirty-two per cent, that is fifty-eight units of standard deviation per item per week, and safety stock comes to roughly two hundred and thirty-three units per item.

If a model brings error to twenty-six per cent, standard deviation falls to forty-seven units and safety stock to roughly one hundred and eighty-nine. That is about forty-four units per item released, roughly ten thousand five hundred units across the line, which at sixty dollars unit cost is about six hundred and twenty-eight thousand dollars of working capital released once, plus eighteen per cent carrying cost, about one hundred and thirteen thousand dollars a year thereafter. Now the counterweight. Assume a stockout event costs one thousand four hundred dollars in expediting, lost margin and service credit.

One hundred and thirteen thousand divided by one thousand four hundred is about eighty. If those two hundred and forty items see more than roughly eighty additional stockout events in the year, the entire carrying benefit is gone and you have paid to make your customers angrier. That single threshold deserves more attention than any accuracy number anybody will show you.

Assume nine thousand units a day through inspection over two hundred and fifty operating days, two and a quarter million units a year, at nine seconds of manual visual inspection per unit. That is twenty-two and a half labour hours a day, about three people per shift on a seven and a half hour effective shift and six across two shifts, and at an assumed forty-six thousand dollars fully loaded each, two hundred and seventy-six thousand dollars a year. Assume automated inspection runs at one point six seconds a unit, four labour hours a day, roughly two people a year and ninety-two thousand dollars, saving one hundred and eighty-four thousand in labour.

Assume two hundred and ten thousand dollars of capital, thirty thousand a year of support and forty-five thousand a year for half a vision engineer to curate labels and retrain. Year one is about one hundred and one thousand dollars negative, year two onward about one hundred and nine thousand positive. Two sensitivities decide whether that holds. Assume escaped defects cost ninety-five dollars each and baseline escape is one tenth of one per cent, so two thousand two hundred and fifty escapes a year; every additional one hundredth of a percentage point of escape is two hundred and twenty-five units and twenty-one thousand three hundred and seventy-five dollars.

Assume false rejects cost six dollars of rework each and baseline false reject is one point two per cent, twenty-seven thousand units and one hundred and sixty-two thousand dollars a year; pushing false rejects to two per cent costs another one hundred and eight thousand. Put those together and the threshold writes itself: keep the combined increase in escape and false reject cost under one hundred and nine thousand dollars a year, or the labour saving has been spent buying defects.

What I would actually do, with dates, starting from this week. By 26 June, pick one of the three areas, only one, and pull twelve weeks of your own logs into a single sheet: stops with cause codes, forecast versus actual by item, inspection outcomes including re-checks. No supplier number is allowed in that sheet. By 10 July, write down the decision each candidate system would replace, the latency you measure today, and the named person who acts on the output and carries the miss. Through the week ending 4 September, run the chosen candidate in shadow mode with the output visible but not acted upon, and score it daily against the hand-written baseline.

On 18 September, hold the go or no-go gate on the single pre-registered metric, with the person who owns the handoff in the chair. If it passes, scale one cell or one item family at a time with no more than twenty per cent of volume moving per week. From the week beginning 21 September, review alert precision, holdout accuracy and rework cost every Monday and revert any cell that misses its threshold for two consecutive weeks inside twenty-four hours.

Do the cheap things first, because most of what looks like a technology gap is a housekeeping gap. Three months of clean failure logging, with cause codes agreed by the people who fix the machines, will usually tell you where your downtime actually comes from, and a Pareto chart on that data routinely shows two failure modes accounting for half the hours. Switching preventive maintenance from calendar intervals to run-hour intervals costs nothing and captures a meaningful share of what predictive maintenance promises. Moving inspection upstream to where the defect is created beats inspecting faster downstream. Rebuilding forecast refresh rhythm from monthly to weekly costs you one recurring meeting. Do all four, measure for a quarter, and then decide whether there is still a gap that only software can close.

The traps cluster in predictable places. Demonstrations run on curated data with single-line product runs, and your line changes over eight to twelve times a shift, so insist that any acceptance test includes changeovers and the messy first hour after a restart. Accuracy claims are defined by whoever reports them, so always ask which errors counted, over what window, against which baseline, and whether items with no history were excluded. Integration rarely gets budgeted honestly: assume, and test it, that plumbing, master data and permissioning will take somewhere near half the effort and a good part of the calendar. Models drift as product mix and season shift, so the result you validated in July is not the result you will get in November, which is why the weekly review matters more than the launch.

Class imbalance catches maintenance teams by surprise: if real failures are four tenths of one per cent of machine hours, you have very few positive examples to train on, no matter how much telemetry you have collected. Finally, and this is the one that quietly costs the most, the people whose judgement is being automated are the people whose cooperation you need to measure anything at all, so bring them into the design before the first purchase order rather than after it.

None of this is an argument against the technology and I do not want it read as one. Sixteen plants got admitted for doing something well, two hundred and thirty-eight are in the network, and the three problem areas are the right three. What I am asking for is that you treat the membership count as a hint about where to look and not as a business case. Pick the one station where your queue is longest, measure it with a stopwatch, write the number down, and let that number be the thing you argue about for the next quarter.

↑ Back to the key points

— By Ravi Chandran