Maersk Launches MAPS 3.0 Planning Engine as Multi-Agent AI Enters Supply Chains

The Analysis

I buy third-party logistics, planning-software seats and more consulting than I would like to admit, and my job is to turn the number on a slide into a number I can hold someone to. So when a carrier ships a planning engine and a factory reports 82 per cent, I read it twice, once for what it says and once for what it quietly assumes about who benefits.

The facts are thin, and thin facts are where the questions live. Maersk has released version 3.0 of the Maersk Advanced Planning System, developed by its Greater China team, combining mathematical optimisation, digital modelling and AI to generate logistics plans under volatile conditions. SAP is pushing multi-agent autonomous supply-chain tooling for automated supply and demand rebalancing. Schneider Electric reports an 82 per cent per-capita productivity gain at its Shanghai end-to-end lighthouse plant, with order delivery cycles 67 per cent shorter.

Three items, three very different kinds of claim, and a buyer has to sort out which of them he can actually use. The version number tells me almost nothing about my cost. The two percentages tell me a great deal about how vendors will try to sell me something.

Take the two numbers apart, because they are not the same kind of number, and treating them as one is the buyer's whole mistake.

82 per cent is per-capita productivity. That is output divided by headcount, a labour-efficiency ratio. It says the same people, or fewer people, produced more. It is an internal-plant metric. Its denominator is somebody's headcount and its numerator is somebody's definition of output, and both are set inside a factory that was built and instrumented specifically to be measurable.

67 per cent is order delivery cycle time. That is a duration, from some start point to some end point, and it says the elapsed time fell by two thirds. It is a lead-time metric, and it moves for entirely different reasons: smaller batches, more finished goods held near demand, better sequencing, or simply a cleaner order book.

Here is the part the media did not say. A plant can post 82 per cent on productivity and 67 per cent on cycle time at the same time, and those two results can pull in opposite directions for the buyer. Cycle time falls when you cut batch sizes and hold more finished goods closer to demand, and that raises per-unit cost. Productivity rises when you run longer, fuller, more standardised batches, and that tends to raise batch size and stretch cycle time. Schneider's lighthouse is showing both, which means its product mix and its automation were tuned to get both, in a plant the company itself selected to be the showcase. That does not make the number false. It makes it a testimonial, and a buyer prices a testimonial differently from an audited result.

The lighthouse word is doing a lot of work too. A lighthouse plant is not an average plant. It is a site that was selected, instrumented and staffed to demonstrate what is possible, and it reports at plant level, not at supply-chain level. The 82 per cent describes people inside one factory making things; it does not describe a purchase order moving between a supplier and a buyer, which is the thing I actually buy. When a supplier quotes 82 per cent at me, it is quoting a demonstration, and my operation is not a demonstration, it is a Tuesday.

Why now. Because the selling season for this is now. A carrier attaching a version number to a planning engine, an enterprise-software giant naming a category, multi-agent autonomous supply chain, and a manufacturer publishing a lighthouse figure are three moves in the same market: vendors need reference cases before buyers set next year's software and outsourcing budgets. That is not cynicism, it is the normal order of things. The number is produced by the party who benefits from the number landing well. When a manufacturer reports its own productivity gain, it is simultaneously the vendor, the subject and the publisher. The honest use of a number like that is as a directional claim, not as a fact about your operation.

Here is the buyer's actual problem. When a carrier's planning engine generates the plan and the quote, the plan is optimised against an objective function, and I did not write that function. It might be minimising the carrier's empty miles, or its network imbalance, or its asset turns, or the variance to a forecast it controls. All legitimate. None of them is my landed cost. The same is true of an autonomous rebalancing engine: it will rebalance supply and demand, and the question a buyer has to ask is towards what. Whose service level, whose holding cost, whose stockout. If the engine belongs to the carrier or the forwarder, then on the margin, when something has to give, the give is probably mine.

That is the layer a press release cannot reach. The pitch is that the algorithm plans better under volatility. The buying question is better for whom, measured how, and whether I can see the plan and the assumptions before I commit a year of volume to it. A model I cannot open is not a service, it is a black box with a price on it.

Can you take 82 per cent and demand it from your supplier? Under some conditions, yes; under most, no. You can use it as a target if your operation resembles the one that produced it: similar product structure, comparable batch sizes, similar order stability, similar automation. If your demand is lumpy, your SKUs are long-tail, your batches are small and your orders arrive by email on a Tuesday afternoon, then the 82 per cent was produced in different physics. The useful role of a lighthouse number is as a direction of travel and a benchmark for a trial, never as a clause.

The test is simple and a buyer can run it in a meeting. Ask the supplier three questions. What was the denominator, headcount or hours, and how was output defined, units or value. What was the measurement period, and what happened in the quarter before it, so you can tell whether you are looking at a level or a step. And what changed alongside the metric, did batch sizes, inventory or input prices move too. If the supplier cannot answer, the number is marketing, and you should price it at zero in the business case.

Now price the 67 per cent, because that one a buyer can actually convert into money if the conditions hold. I will make up the numbers, so replace them with yours.

Assume one category with an annual purchase value of 12 million dollars. Assume the current order-to-delivery cycle is 60 days, and the supplier cuts it 67 per cent, so 60 days becomes about 20. Assume that in steady state roughly one cycle's worth of purchases is locked in the pipeline at any moment, cash in goods ordered but not yet on the shelf. At 60 days, 12 million times 60 divided by 365 is about 1,973,000 dollars. At 20 days, 12 million times 20 divided by 365 is about 658,000 dollars. The difference, about 1,315,000 dollars, is working capital you release. At an 8 per cent cost of capital, my number, use yours, that is about 105,000 dollars a year of carrying cost you stop paying, if the cash actually leaves the balance sheet and does not simply become a larger finished-goods buffer, which is the trap.

The same 67 per cent, converted to safety stock: assume you hold 15 days of cover against the cycle. Cut the cycle to 20 days and, if lead-time variability falls with it, you can run 7 days, so 8 days of cover released, and on a 12-million-dollar category at cost that is about 263,000 dollars of inventory. Two conversions, one headline, and neither of them is the 82 per cent. The 82 per cent is the plant's number. The 67 per cent is the one that can reach your balance sheet, but only after you have confirmed the start point and the end point, because a supplier who measures cycle time from order confirmation rather than from purchase order is selling you a shorter clock, not a shorter cycle.

One distinction the 67 per cent hides is the difference between lead time and lead-time variability. A cycle that goes from 60 days to 20 on average is worth something, but the safety stock I hold is driven by how much that cycle bounces, not only by where it sits. If the mean falls and the variance stays, I release a little working capital and keep almost all my buffer, and the headline overstates the benefit. So before I bank the 67 per cent I want the distribution, not the average: what is the worst decile of the cycle, and did that move. A supplier who can only give me the mean is telling me he has not measured the part I care about.

Back to MAPS 3.0. The only hard fact I have is a version number and a description: mathematical optimisation, digital modelling and AI, generating plans under volatile conditions, built by the Greater China team. That is enough to ask the right questions, and here the questions are the product.

Which of my data feeds the engine, and who owns the output. If the engine produces my plan and my quote, do I get the plan and the assumptions behind it, or only the number. When the model changes, a new version or a re-tuned parameter, do I get notice, and do I keep the old behaviour for a committed period. And in a tender, if the engine plans better than a human, does the saving show up as a lower rate for me, or as a better margin for whoever is quoting. A version number is not a benefit. It is an invitation to ask what the version is optimised for, and a good buyer accepts that invitation in writing.

Version numbers have a cadence, and the cadence is the buyer's problem. If a system is at 3.0 in August, it will be at 3.1 or 4.0 inside a contract year, and each release re-tunes something. That is good news for capability and bad news for the stability of the thing you signed. So the question is not whether the version is better, it is what happens to my service level on the day it changes, and whether there is a freeze period and a re-baseline. Buyers who lock a three-year term around a version that ships every quarter are buying a moving target and calling it certainty.

The multi-agent part deserves its own caution. Automated supply and demand rebalancing sounds like a service to the buyer, and it can be, but a rebalancing engine always rebalances towards something, and that something is a set of weights someone chose. If the weights favour the operator's asset utilisation, the engine will fill my orders when it suits the network and hold them when it does not, and every individual decision will look efficient while my service level drifts. This is not an argument against the tool. It is an argument for asking what the objective function is before you let it near your order book, and for keeping a right to see the plan it produces for your account, not just the bill.

There is one ask that ties the whole thing together, and it is not a discount. Ask the carrier to run its engine under my objective, not its own, and show me the difference. Same orders, same lanes, weights set to my priorities, whether that is landed cost or transit stability, and the output compared with what the engine produces on its default settings. If the two plans are identical, then my interests were already the default and I have learned something useful. If they differ, I have just found the gap between its optimum and mine, and that gap is a number I can put in a contract.

Run the other way. Suppose the algorithm really is better and the buyer gets none of it, because the carrier captures the efficiency in yield. Then the value of the technology to me is zero on price and positive only on reliability, and I should buy it as a service-level commitment, not a discount. Or suppose the opposite, the tools are still early and the vendor is selling a roadmap. Then the 82 per cent and the 67 per cent describe a plant that was built to be measurable, and the moment I point my contract at them I am buying someone else's conditions. The condition that flips the conclusion: if your operation is standard, high-volume and stable, the numbers are a fair target and a one-quarter shadow run will confirm it. If your operation is not, the numbers are a story, and you should treat them as one.

The traps, in the order I have hit them. Writing a vendor's lighthouse number into your own KPI. You cannot control a supplier's per-capita productivity, it depends on its batch sizes, its automation and its mix, so you will be penalised for a number you cannot move. Write a KPI you can define and it can control: on-time delivery against a named window, order-to-dock lead time measured from a fixed start point, fill rate on the committed book, invoice accuracy against the agreed tariff. The second trap is accepting a smart plan without a shadow run. Run the supplier's engine in parallel with your own for a quarter, compare the plans and the costs on the same baseline, and only then decide. The third trap is letting the algorithm hold the data. If your volumes, your lane mix and your seasonality all feed the engine, make sure you can take them back, and that a model change does not quietly change the service you are paying for.

If any of this is going to be tested, design the test before the demo, not after. Pick one category with steady demand, one lane, one quarter, and write down in advance what you expect to change and by how much. Run the algorithm's plan and your own side by side on the same book, compare landed cost, lead time, variability and fill rate, and write down a decision rule now: if lead time does not fall by at least a number we agree, we do not extend. A pilot without a pre-committed decision rule is a demo with better slides.

There is also a procurement angle that gets skipped, which is what to put in the tender. If you are buying a planning or logistics service that runs on someone's engine, write the deliverable, not the technology. Say what lead time you need, from which start point, at what fill rate, with what notice before a model change, and with what right to see the plan. A supplier quoting an algorithmic advantage should be willing to commit to the outcome, and if it is not, the algorithm is being used to explain a price rather than to reduce one. Keep the term shorter than the technology cycle, because a tool that re-tunes every quarter does not fit a three-year lock-in.

None of that is a reason to refuse the technology. It is a reason to buy it the way you buy anything someone else's system touches: define the outcome, test it against a control, write the change rules, and keep the exit. The version number is not the product. The lead time, the fill rate and the variability are the product, and they are the only parts of this that show up on my profit and loss.

One more thing the version number implies. A planning engine gets better with data, and the data is mine: my volumes, my lanes, my seasonality, my pain points. Every plan it produces for me teaches it something about my business that it will also use for my competitors, unless I have agreed otherwise. That may be a fair trade, it usually is, but it should be a conscious one, priced and papered, not a footnote on an order form. A buyer who understands that the algorithm is only as good as the data he feeds it also understands when to feed it and when to hold back.

And the engine has to explain the decisions it takes about me. Not the mathematics, I do not need the maths, I need the reason: why was this order held, why was that lane changed, what would have to be different for next week to look better. If the answer to every question is that the model decided, then no one is accountable, and a service level without an accountable owner is a hope with a dashboard.

If I were buying, here is how I would sign. I would not buy a version number, I would buy a defined lead time and a defined fill rate, with an acceptance threshold and a service credit, measured from a start point I choose. I would ask for a shadow run in one quarter on a real category, the supplier's plan and mine on the same baseline, and make go or no-go depend on that, not on a slide. I would put a model-change notice period in the contract, 30 days, say, and a re-baseline of the agreed KPI after any change. I would contract for the right to see the plan and its assumptions for my own account. And I would refuse to write 82 per cent anywhere, because it is someone else's plant, and I cannot deposit someone else's plant in my bank account.

↑ Back to the key points

— By Grace Yang