Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Supplier lead time watcher series ~6 min read

A supplier lead time watcher on AWS for a few dollars a month

A supplier says five working days. The last eleven orders took four, five, five, six, five, nine, six, seven, twelve, eight and nine. Nobody noticed the second half of that list, the reorder point is still set for five days, and in about six weeks something is going to run out on a Friday. This post walks through a small system that notices on order seven.

a man in an apron looking at a phone
Photo by Ali Mkumbwa on Unsplash

Key takeaways

  • Measure lead time from your own records, never from the supplier’s quote.
  • Separate internal delay (approval, sending) from external (supplier to door).
  • Report a distribution and a high percentile, not an average.
  • Drift matters more than any single late order.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: purchase order timestamps turned into lead time distributionsThree boxes across the top sit outside the AWS account. On the left, Purchase orders, with the dates they were raised, approved and sent. In the middle, Goods received, with dates and quantities. On the right, Whoever reorders, who needs a number. Each connects by an arrow to the AWS account container below. Purchase order timestamps flow down into the account. Receipt dates feed in. A percentile and a trend go back out. Inside the AWS account are three components in a row. On the left, the Clock, recording five timestamps rather than two. In the middle, the Distribution, computed per supplier and per product. On the right, the Drift watch, looking for slow change rather than one late order. A note at the bottom says five timestamps rather than two is what separates their delay from ours.AWS ACCOUNTPurchase ordersraised, approved, sentGoods receiveddates and quantitiesWhoever reordersneeds a numberClockfive timestamps,not twoDistributionper supplier,per productDrift watchslow change,not one late orderPO timestampsreceipt datesa percentile and atrendFive timestamps rather than two is what separates their delay from ours.
Fig 1. Three things outside the account, three pieces inside it. The first box is the one that makes every later number attributable to somebody.
  • Management
  • Analytics
  • People

The number nobody should use

Every supplier has a quoted lead time, it appears on their website and in their terms, and it is a commercial statement rather than a measurement. It usually describes their best case, or their case in a normal month, or what they said three years ago when the relationship started.

Meanwhile the business already has the real data: a purchase order with a date on it and a delivery note with a date on it, for every order ever placed. Nobody has ever subtracted one from the other systematically, and that subtraction is most of this system.

What runs (the inside)

  • The clock. Records the five points in a purchase order’s life and computes the segments between them. Part 2.
  • The distribution. Builds the observed spread per supplier and product and reports the percentile that matters. Part 3.
  • The drift watch. Detects gradual slippage against a small number of observations. Part 4.

One purchase order, end to end

One purchase order measured at five points from raising to receiptA horizontal row of five boxes joined by arrows. Raised: first of August. Approved: fifth of August, four days, ours. Sent: fifth of August. Acknowledged: sixth of August. Received: fourteenth of August, nine days, theirs. A note says thirteen days door to door, four of them were us, and that distinction is the system.ONE PURCHASE ORDER, FIVE TIMESTAMPSRaised1 AugApproved5 Aug -- 4 days, oursSent5 AugAcknowledged6 AugReceived14 Aug -- 9 days, theirsThirteen days door to door. Four of them were us. That distinction is the system.
Fig 2. The same purchase order as one line. Without the middle three timestamps, this order is simply thirteen days late against a five-day promise, and the conversation goes badly.
  • App integration
  • Machine learning
  • Front-end & mobile

In plain words

Somebody raises a purchase order on the first. It waits four days for approval because the person who signs is away. It goes to the supplier on the fifth, they acknowledge it on the sixth, and the goods arrive on the fourteenth.

Thirteen days from raising to receiving. Nine from sending to receiving. Eight from acknowledgement to receiving. Which of those is the supplier’s lead time depends on what you are going to do with the number, and having all three is what lets you answer both questions: how long does the supplier take, and how long does it take us to get something.

The reorder point needs the thirteen, because that is reality. The supplier conversation needs the nine, because that is theirs. Conflating the two produces either a supplier meeting where you are wrong about the facts, or a reorder point that assumes approval is instantaneous.

Design rules that shaped every decision

  • Measure from your own records. The quoted lead time is an input to nothing.
  • Five timestamps, so internal and external delay are separable.
  • Working days, not calendar days, and the supplier’s calendar where it differs.
  • Report a percentile with the distribution beside it, never an average alone.
  • Never automatically change a supplier or a reorder point. Produce evidence.
  • Say the sample size next to every number. Four orders is not a distribution.

Why this shape

Lead time problems are slow. A supplier does not go from five days to twelve overnight; they drift over a couple of quarters as their own supply chain tightens, and every individual order looks like a one-off. The failure is entirely one of memory, which is what makes it a good fit for a small system and a bad fit for a person.

So the design is heavily weighted towards recording carefully and comparing over time, and deliberately does nothing automatic at the other end. A supplier relationship is not something to adjust with a threshold.

The next four posts walk through each piece: how lead time actually gets measured, why the average is the wrong number, how slippage gets caught, and how it turns into a conversation. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts