Electronic Kanban Architecture: Pull Replenishment, Loop Sizing, MES and ERP Integration for Lean Factories

Most factories that “go electronic” with kanban digitise the card and keep every bad habit of the paper loop. The card count was set years ago by a consultant, nobody knows how many cards are actually circulating, and the ERP thinks a container is empty while the line has already received it. An e-kanban system that only replaces cardboard with a barcode is a faster way to run the wrong loop size.

This matters now because the signal layer is cheap and mature. Bin weight sensors, RAIN RFID portals, scanners and wireless call buttons can raise an empty signal within seconds, and every major ERP has a kanban module. The weak link is the architecture between them: who owns card state, how loops are sized and resized, and how MES and ERP stay consistent.

You will leave with a reference architecture, a card state machine, the standard kanban formula with a worked and coded example, a Little’s Law sanity check, integration patterns for MES, ERP and suppliers, and a catalogue of failure modes.

What this covers: kanban origins and variants, e-kanban reference architecture, signal triggers, kanban loop sizing math, Python sizing code, MES and ERP integration along ISA-95 lines, supplier call-offs via EDI, dashboards, and what goes wrong.

Context and Background

Kanban is a Japanese word usually glossed as “sign” or “signboard”. The idea came out of the Toyota Production System, which Taiichi Ohno developed over roughly three decades after the Second World War. Ohno described taking inspiration from American supermarkets: the downstream process behaves like a shopper who takes only what it needs from a shelf, and the upstream process restocks only what was taken. Toyota’s own 75-year history records that a “supermarket method” was introduced in 1954 between its machining and machine assembly plants and later evolved into kanban, according to Toyota’s corporate history.

The same history gives a useful timeline for the electronic version. Toyota lists a call-out system introduced in the machinery plant of Koromo (Honsha) in 1953 and adopted at all plants by 1970. In 1995 a “Kanban reflection system”, described as a prototype of e-kanban, went live at its Canadian plant. The e-kanban system then rolled out to five vehicle assembly plants in 1999, to body manufacturers from 2000, and to all Toyota plants by 2002, per the Toyota production parts logistics timeline. Electronic kanban is therefore not a new idea. It is a quarter-century-old practice that most of industry has implemented badly.

The incumbent tool landscape has three layers. ERP suites carry kanban as master data: SAP, for example, models a control cycle that links a production supply area to a replenishment source, with the number of kanbans, the quantity per container and a replenishment strategy of in-house production, external procurement or stock transfer, as described in SAP’s kanban learning material. Manufacturing execution systems (MES) own the shop-floor side: line-side delivery tasks, milk runs and consumption backflush. Point solutions sit between them and supply the signal hardware, apps and supplier portals.

What is usually missing is a clear owner for the loop as a running system, with its own event log, metrics and sizing logic. That is the same gap OEE programmes hit when they compute availability in three places; the OEE architecture and MES data model guide on this site makes the case for one canonical event model, and kanban needs the same discipline.

E-Kanban Reference Architecture

An e-kanban system is a closed-loop pull replenishment service. Physical containers carry a card identity; sensors or scans raise an empty event; a loop engine validates it against a card state machine, creates the replenishment request in ERP or with the supplier, dispatches line-side delivery through MES, and recalculates loop size from measured demand and lead time.

Figure 1: Reference e-kanban architecture. Signal sources feed an edge gateway that debounces and deduplicates; the loop engine owns card state and the event log, fans requests out to MES, ERP and suppliers, and receives updated card counts from a loop sizing service fed by ERP demand history.

The figure reads left to right. Four classes of signal source converge on an edge gateway, which turns noisy physical observations into clean card events. The loop engine is the only component that changes card state; everything to its right is a consumer or a fulfiller of that state. The loop sizing service closes a second, slower loop: it reads consumption and lead-time history and proposes new card counts, which the engine applies only after approval.

Signals are observations, cards are state

The first design decision is to separate the physical signal from the logical card. A bin scale reporting 0.4 kilograms is an observation. “Card 17 of loop BRK-600 is empty” is a state transition. Mixing the two is the root of most e-kanban bugs.

Each trigger technology has a different error profile, so each needs a different conversion rule:

Scan-based triggers. An operator scans the barcode or QR code on the card when the container is opened or emptied. Cheap and explicit, but it depends on discipline; forgotten scans silently shrink the loop.
RFID triggers. A RAIN (UHF) RFID tag on the container passes through a portal or is dropped in an “empties” chute with a reader. No human action is needed, but read rates vary with metal, liquids and tag orientation, so the gateway must tolerate missed and duplicate reads. The RAIN RFID and EPCIS 2.0 traceability architecture covers reader-level filtering in depth.
Weight or bin-level sensors. A load cell or distance sensor detects when contents fall below a threshold. This suits small fasteners and consumables in two-bin systems. Vibration and operators leaning on shelves cause chatter, so thresholds need hysteresis.
IoT call buttons. A wireless button at the point of use. Fast to deploy and good for low-volume items, but the button carries no quantity and is easy to press twice.

The gateway’s job is to debounce, attach the card identity, and emit an idempotent event: a unique event ID, the card ID, the observed transition, the source, and a timestamp. Downstream systems should be able to receive the same event three times and act once.

The card state machine is the contract

The loop engine maintains a small, explicit state machine per card. The minimal set in SAP’s documentation is full and empty: setting a kanban to empty creates a replenishment element, and setting it to full posts the goods receipt. In practice the engine needs a few more states to see where time is lost.

Figure 2: Card lifecycle in the e-kanban loop engine. The main cycle runs full, in use, empty, acknowledged, in transit and received. Side paths catch cards that exceed their lead time and cards that stop circulating.

The useful additions are “acknowledged” (the source has accepted the request), “in process or in transit” (it is being made or moved), “overdue” (elapsed time since the empty signal exceeds the planned lead time) and “dormant” (no transition for N days). Each extra state gives you a timestamp, and timestamps are what let you measure real lead time instead of the planned value in master data. That measured lead time feeds straight back into loop sizing.

Rules belong on transitions, not in reports. An empty event for a card already in transit is rejected and logged. A received event for a card never marked empty triggers an audit flag, because it usually means someone skipped a scan. A card dormant for longer than a configurable multiple of its cycle time is a candidate “dead card”, which we come back to in the failure-modes section.

One owner of card state, many consumers

The second design decision is ownership. There are two defensible patterns.

In the ERP-centric pattern, the ERP kanban module is the system of record for card state. Signals post status changes directly into ERP, and MES and suppliers read from it. This minimises moving parts and keeps financial postings aligned with card movements. The cost is latency and flexibility: ERP status changes often go through batch interfaces, and adding states such as “acknowledged” or “dormant” means custom development in a system that is expensive to change.

In the engine-centric pattern, a dedicated loop engine, often part of MES or a standalone service, owns card state and the event log. It calls ERP to create replenishment elements and receives goods receipts back. This allows richer states, sub-second response and analytics, at the cost of a synchronisation problem between two systems that both think they know the card status.

Either works. What fails is the hybrid where ERP and the engine both accept status changes from the floor. The rule is simple: one writer per card state, every other system reads or is notified. If ERP must remain the writer for compliance reasons, the engine becomes a smart gateway that enriches and forwards events but never changes state on its own.

Where kanban sits in ISA-95

The ISA-95 standard (IEC 62264) splits enterprise and control integration into levels. Level 4 is business planning and logistics, which is ERP. Level 3 is manufacturing operations management, which includes MES and, explicitly, inventory operations such as moving and tracking material inside the plant. Kanban spans the boundary, which is why it causes arguments.

A practical split: the decision that a loop exists, how many cards it has, and who pays for the material is Level 4. The execution of each card cycle, line-side delivery, and the measurement of consumption and lead time is Level 3. The messages crossing the boundary are small and well defined: “replenishment requested for card X, quantity Q”, “goods receipt for card X”, and periodic “loop parameters changed”. If your plant exchanges ISA-95 data through B2MML, the XML implementation maintained by MESA, these map onto material and inventory-related transactions rather than onto production schedules. The ISA-88 batch control post on this site, physical and procedural models for S88 and MES, shows the same Level 3 and Level 4 split for recipes.

Walk-through: Kanban Loop Sizing, the Kanban Formula and Integration

A loop that is the wrong size is either a stockout generator or a warehouse in disguise. Sizing is where e-kanban earns its keep, because electronic events give you the measured inputs the paper loop never had.

The standard kanban formula

The textbook Toyota-style formula sets the maximum inventory in a loop equal to demand over the replenishment lead time, inflated by a safety factor:

n × a = D × L × (1 + s)

where n is the number of kanbans, a is the container quantity, D is the average demand rate, L is the expected replenishment lead time and s is a policy safety factor. This is the form given by Akturk and Erhun in their review of kanban design, published in the International Journal of Production Research in 1999 (vol. 37, no. 17), which describes it as “the Toyota formula” and uses s = 0.05 in its illustration. Rearranged for card count and rounded up:

n = ⌈ D × L × (1 + s) / a ⌉

Three practical points make this formula behave in real plants.

First, L is not the transport time on the routing. It is the full replenishment cycle: time for the empty signal to reach the source, queue time at the source, processing or picking time, transport, and receiving. In a paper loop, card collection runs alone can add hours. In an e-kanban loop the signal delay collapses to seconds, which is one of the few direct, mechanical benefits of going electronic.

Second, s is a policy number, not a physical constant. It absorbs demand variability, supply variability and the plant’s appetite for risk. Using a single s across hundreds of loops treats a stable fastener the same as a volatile harness from an overseas supplier.

Third, the rounding matters at low card counts. A loop calculated at 2.1 cards becomes 3, a 43 percent increase in inventory over the raw number. For high-value items, adjust container quantity before rounding cards.

A variability-aware alternative

Christoph Roser’s kanban formula series on AllAboutLean argues for building the count from its components: replenishment time, waiting in the supermarket, coverage for breakdowns, lot-size formation, customer batching and peak demand, plus a safety margin. That is the right mental model. A compact statistical version replaces the flat safety factor with a buffer scaled to demand variability over the lead time:

n = ⌈ (D × L + z × σ_D × √L) / a ⌉

Here σ_D is the standard deviation of demand per period and z is the service factor (1.65 corresponds to roughly a 95 percent cycle service level under a normal approximation). This assumes demand is independent from period to period and lead time is fixed; when lead time varies, its variance must be added. It is a modelling choice, not a law, and it is offered here as an illustrative alternative to the flat factor.

Python sizing code

The script below computes both counts for three loops and reports the days of cover each loop holds. All loop data is illustrative, chosen to represent a fastener two-bin loop, an external supplier loop and an internal cell-to-assembly loop.

import math
from dataclasses import dataclass

@dataclass
class Loop:
    part: str
    daily_demand: float      # units per day (average)
    demand_cv: float         # coefficient of variation of daily demand
    lead_time_days: float    # replenishment lead time incl. queue + transport
    container_qty: int       # units per container (one card = one container)
    safety_factor: float     # policy safety factor s, e.g. 0.10
    signal_delay_days: float = 0.0  # card collection / batching delay

def toyota_count(l: Loop) -> int:
    """n = ceil(D * (L + signal) * (1 + s) / a)"""
    lt = l.lead_time_days + l.signal_delay_days
    return math.ceil(l.daily_demand * lt * (1 + l.safety_factor) / l.container_qty)

def service_count(l: Loop, z: float = 1.65) -> int:
    """Variability-aware alternative: mean lead-time demand + z * sigma."""
    lt = l.lead_time_days + l.signal_delay_days
    mean = l.daily_demand * lt
    sigma = l.daily_demand * l.demand_cv * math.sqrt(lt)
    return math.ceil((mean + z * sigma) / l.container_qty)

def days_of_cover(n_cards: int, l: Loop) -> float:
    """Little's Law: average time in system = inventory / throughput."""
    return n_cards * l.container_qty / l.daily_demand

loops = [
    Loop("M8 bolt (bin)",          4800, 0.15, 2.0,  500, 0.10, 0.25),
    Loop("Harness A (supplier)",    320, 0.30, 5.0,   40, 0.15, 0.50),
    Loop("Machined bracket (cell)", 600, 0.20, 0.5,   50, 0.10, 0.10),
]
print(f"{'loop':26}{'toyota':>8}{'z=1.65':>8}{'cover_d':>9}")
for l in loops:
    n1, n2 = toyota_count(l), service_count(l)
    print(f"{l.part:26}{n1:>8}{n2:>8}{days_of_cover(max(n1, n2), l):>9.2f}")

Running it with Python 3 prints:

loop                        toyota  z=1.65  cover_d
M8 bolt (bin)                   24      26     2.71
Harness A (supplier)            51      54     6.75
Machined bracket (cell)          8      11     0.92

The interesting row is the machined bracket. With a half-day lead time the flat 10 percent factor yields 8 cards, while the variability-aware version asks for 11. Short lead times make the mean term small, so the variability term dominates, and a flat percentage under-protects exactly the fast internal loops that lean programmes like to shrink. The opposite happens on long, stable loops, where a flat factor can over-protect. Neither formula is “right”; the point is that e-kanban event data lets you measure σ_D and L instead of guessing them.

Worked example: hand-checking the harness loop

Take the supplier harness loop (illustrative numbers). Average demand is 320 units per day. The planned supplier lead time is 5 days, and the old paper process added half a day of card collection and fax batching, so L = 5.5 days. Containers hold 40 harnesses and the safety factor is 0.15.

Demand over the lead time: 320 × 5.5 = 1,760 units.
With safety: 1,760 × 1.15 = 2,024 units.
Cards: 2,024 / 40 = 50.6, rounded up to 51.

Now switch the signal to an RFID portal at the empties drop. The half-day collection delay falls to effectively zero, so L = 5.0 days. Recomputing gives 320 × 5.0 × 1.15 / 40 = 46 cards exactly. Five cards, 200 harnesses, leave the loop with no change in protection. That is the cleanest business case for electronic signals: inventory removed in proportion to the signal delay you eliminate, and nothing else needs to change.

Little’s Law as a sanity check

Little’s Law, proved by John D. C. Little in Operations Research in 1961 (vol. 9, no. 3), states that in a stable system the average number of items in the system equals the arrival rate multiplied by the average time each item spends in it: L = λW. For a kanban loop, the items are units of material, the rate is consumption, and the time is how long a unit sits in the loop.

Applied to the harness loop with 51 cards: maximum loop inventory is 51 × 40 = 2,040 units, and consumption is 320 per day, so the loop can hold at most about 6.4 days of material. The script reports 6.75 days because it uses the larger, 54-card variability-aware count (2,160 units divided by 320 per day). Average on-hand inventory in a healthy loop is lower, because some cards are always in transit. A rough rule of thumb: on-hand stock at the point of use averages roughly half a container plus the safety portion, while the rest of the loop is in the pipeline.

Little’s Law gives you a monitoring signal, not just a design check. If the e-kanban dashboard shows average cards in transit rising while consumption is flat, then W, the time cards spend in the replenishment pipeline, must be rising. That is a supplier or internal-logistics problem showing up weeks before a stockout.

Signal kanban, supermarkets and CONWIP

Not every loop is one card per container. Three variants matter for architecture.

A supermarket is a controlled store between processes where downstream withdraws and upstream replenishes, the pattern Toyota’s history credits as the precursor to kanban. In an e-kanban system the supermarket is a location with its own loops on both sides: withdrawal kanbans pull from it, production kanbans replenish it.

A signal kanban, sometimes drawn as a triangle kanban, is used where the upstream process has long changeovers and must produce in lots. Instead of each card triggering production, a signal fires when inventory drops to a reorder point, and the source makes a full lot. Akturk and Erhun cite work by Philipoom and co-authors from 1990 that used integer programming to set lot sizes for signal kanbans in multi-item, multi-stage settings. In software, a signal kanban is a counter with a threshold, not a card state machine, and it should be modelled that way.

CONWIP, for constant work in process, was introduced by Mark Spearman, David Woodruff and Wallace Hopp in “CONWIP: a pull alternative to kanban”, published in the International Journal of Production Research in 1990 (DOI 10.1080/00207549008942761). CONWIP uses a single set of cards for a whole line rather than per-station loops: a job can enter only when a card is free, and the card returns to the start when the job leaves the end. It suits high-mix lines where per-part supermarkets would explode in number. An electronic kanban system can host CONWIP with the same engine, because a CONWIP card is just a card whose loop spans a routing rather than a part number.

MES and ERP integration sequence

Figure 3 shows a single replenishment cycle for an external supplier loop with the engine-centric ownership pattern.

Figure 3: One e-kanban replenishment cycle. The sensor event becomes an empty card in the engine, ERP issues the supplier call-off, the supplier’s shipping notice and the goods receipt flow back, and MES dispatches line-side delivery before the card returns to full.

The sequence highlights three integration boundaries.

Edge to engine. Use a publish-subscribe transport such as MQTT or a plant message broker. The event payload is small: event ID, card ID, transition, source and timestamp. Quality of service and retries are handled by the broker; deduplication is handled by the engine using the event ID. If you already run a unified namespace, card events become one more topic tree.

Engine to ERP. This is usually a request-response API or an IDoc-style asynchronous interface. The engine sets the ERP kanban to empty, ERP creates the replenishment element (purchase order or scheduling agreement release for external supply, production or planned order for in-house, stock transfer reservation for internal moves, matching SAP’s three strategies), and returns a document number that the engine stores on the card. Goods receipt flows back as an event that moves the card toward full. In SAP’s model, emptying a kanban does not post a goods issue; consumption is backflushed or posted separately, which is a frequent source of inventory mismatch if nobody owns it.

ERP to supplier. For suppliers with EDI, kanban call-offs typically ride on just-in-time delivery messages. In UN/EDIFACT that is DELJIT, a message for conveying precise delivery sequence and just-in-time schedule requirements that supplements the DELFOR delivery schedule; in ANSI X12 the comparable transaction is the 862 shipping schedule. Advance ship notices come back as DESADV or X12 856. For smaller suppliers a web portal that shows open cards, lets them acknowledge, and prints labels with the card identity is often more reliable than forcing EDI onboarding.

Engine to MES. Once material is received at the dock or supermarket, MES creates a line-side delivery task, often a milk-run stop, and confirms when the container reaches the point of use. That confirmation, not the dock receipt, is what should flip the card to full. Otherwise the dashboard shows a full card that is still on a pallet 200 metres away.

SAP specifics worth knowing

Without endorsing a vendor, SAP’s documentation illustrates the design space well because it has carried kanban since R/3. Its control cycle bundles the production supply area, replenishment strategy, number of kanbans, container quantity and parameters for automatic kanban calculation. Its “event-driven kanban” variant creates a kanban only when a signal is triggered for a defined quantity, and deletes it when emptied, which suits sporadic demand that does not justify a standing loop. A “one-card” variant exists for cases where a single card triggers replenishment ahead of the container being empty. Other ERPs offer comparable constructs under different names; verify the exact behaviour in your release before designing around it.

Dashboards that drive action

A good loop dashboard answers four questions per loop, not forty:

Metric	Definition	Action when it drifts
Cards in circulation vs planned	Active cards / configured cards	Below plan: hunt dead cards. Above plan: unauthorised extras
Measured lead time p50 / p95	Time from empty to received, per card cycle	p95 above plan: resize or escalate the source
Stockout and near-miss count	Point-of-use empties with no full container behind	Any non-zero: review sizing and signal latency
Days of cover	Loop inventory / average daily consumption	Rising with flat demand: loop is oversized

The table is deliberately operational. Every metric comes straight from card transitions that the engine already logs, and every one maps to a decision. Avoid vanity charts such as total kanban scans per day, which rise and fall with volume and tell nobody what to do.

Capacity and cost of the platform itself

The software side of an electronic kanban system is small by industrial IoT standards, and it is worth saying so to stop over-engineering. A plant with 2,000 active loops averaging 10 cards each, cycling once per day, generates about 20,000 card cycles daily. With five to seven state transitions per cycle that is roughly 100,000 to 140,000 events per day, on the order of one or two events per second averaged over 24 hours, with peaks at shift change perhaps ten times higher (illustrative estimate). A single message broker and a modest relational database handle that comfortably.

The real cost sits elsewhere: sensor hardware per bin, RFID portals and tags, integration effort with ERP and suppliers, and above all the organisational work of auditing and resizing loops. Budget the integration and change management first, the servers last.

Trade-offs, Gotchas, and What Goes Wrong

Going electronic removes the physical friction that used to hide loop problems, and it introduces new failure modes of its own. Figure 4 pairs the common ones with the guard that catches each.

Figure 4: Six e-kanban failure modes and their guards. Most failures are state or data problems rather than hardware faults, and each guard is a rule in the loop engine or a recurring process.

Dead cards. A paper card falls behind a rack; an RFID tag is torn off; a container is borrowed for scrap. The loop silently shrinks until a stockout occurs. The guard is a dormancy timer per card, set at a multiple of the loop’s measured cycle time, plus a periodic physical audit that reconciles tags on the floor with cards in the engine. Paper loops never offered this visibility; e-kanban does, if you build the timer.

Duplicate and phantom signals. A wobbly scale crosses its threshold three times in a minute; an RFID portal reads a stack of empties twice. Without idempotent events and debounce, the source receives three call-offs and the loop inflates. Hysteresis on sensors, unique event IDs and state-transition validation in the engine are mandatory, not optional.

Stale loop size. The loop was sized for last year’s volume. Demand fell 30 percent, so every container now sits for weeks. Or demand rose and the line starts expediting. The guard is a scheduled resize run, monthly or quarterly, that compares the current card count with a recalculated one and routes material changes to a planner for approval. Never let the algorithm add or remove cards automatically on a high-value loop; a bad forecast should not reach the floor without a human looking at it.

Bullwhip from batched signals. If empties accumulate and are signalled in batches, the source sees lumpy demand that bears no resemblance to actual consumption. That is the bullwhip effect at plant scale. Electronic signals should fire per container, and small containers smooth the signal further. Mixing kanban with MRP-driven releases for the same part makes this much worse.

ERP and engine out of sync. The most expensive class of bug. The engine thinks card 12 is full; ERP still has it empty with an open purchase order, so the supplier ships again. The guard is architectural: one writer of card state, reconciliation jobs that compare states nightly, and alerts on any mismatch.

Supplier ignores the call-off. The DELJIT went out, nothing came back. Put a timer on acknowledgement and on the advance ship notice, and escalate before the card goes overdue.

Two honest limits remain. Kanban assumes reasonably level, repetitive demand; for engineer-to-order or highly seasonal parts, MRP or event-driven variants usually fit better. And no formula fixes a source whose lead time swings wildly; the card count needed to cover a p95 lead time that is three times the median becomes economically absurd.

Practical Recommendations

Start with loops, not technology. Pick a value stream with 50 to 200 loops, audit every card physically, and record the true count, container quantity and source. Most plants discover that 10 to 20 percent of cards are missing or duplicated; treat that as a hypothesis to measure, not a statistic.

Next, choose the ownership pattern explicitly and write it down. If ERP stays the writer, keep the engine thin. If the engine owns state, build reconciliation from day one.

Match the signal to the item. Two-bin weight or level sensors for high-volume consumables, scans or RFID for returnable containers, call buttons for slow movers. Do not buy one sensor technology for the whole plant.

Then use the data. After eight to twelve weeks of electronic cycles you have measured lead times and demand variability per loop. Recompute card counts with both the flat-factor and variability-aware formulas, review the outliers with planners, and apply changes in waves.

Checklist:

[ ] Physical card audit completed and reconciled with system counts
[ ] Single writer of card state documented
[ ] Idempotent event schema with event ID, card ID, transition, source, timestamp
[ ] Debounce and hysteresis configured per sensor type
[ ] Card state machine includes acknowledged, overdue and dormant
[ ] Measured lead time p50 and p95 per loop on the dashboard
[ ] Scheduled resize run with planner approval
[ ] Supplier acknowledgement and ASN timers with escalation
[ ] Nightly ERP and engine reconciliation with alerts

Frequently Asked Questions

What is e-kanban and how does it differ from paper kanban?

E-kanban, or electronic kanban, replaces the physical card’s journey with a digital signal. When a container empties, a scan, RFID read, weight sensor or button raises an event, and software creates the replenishment request in ERP, with the supplier or with an internal source. The pull logic is identical to paper kanban: nothing is replenished until something is consumed. The differences are speed, because signal delay drops from hours to seconds, and visibility, because every card transition is timestamped and can be measured, audited and used to resize loops.

What is the formula for calculating the number of kanbans?

The common Toyota-style kanban formula is n = D × L × (1 + s) / a, rounded up, where D is average demand per period, L is the full replenishment lead time in the same period unit, s is a safety factor and a is the container quantity. Lead time must include signal delay, queueing at the source, processing, transport and receiving. A variability-aware alternative replaces the flat safety factor with z × σ × √L, which protects short, volatile loops better. Either way, round up and review low card counts carefully, because rounding inflates inventory.

How does an electronic kanban system integrate with ERP and MES?

Usually ERP owns the commercial side, meaning loop master data, purchase orders or scheduling agreements, and goods receipts, while MES owns execution such as line-side delivery tasks and consumption. The kanban engine sits between them. It turns a floor signal into an ERP replenishment element, stores the returned document number on the card, receives goods receipt and delivery confirmations back, and updates card state. The critical design rule is one system writing card state, with the others reading it or being notified, plus nightly reconciliation to catch mismatches.

How often should kanban loops be resized?

Most plants review loop sizes monthly or quarterly, and immediately after known changes such as a new product launch, a supplier switch or a container change. The resize job recalculates card counts from measured demand and lead time, flags loops whose recommended count differs materially from the current one, and routes the change to a planner. Automatic resizing without approval is risky on expensive parts, because a forecast error flows straight to the shop floor. For cheap consumables, automated adjustments within tight bounds are reasonable.

What is the difference between kanban and CONWIP?

Kanban controls inventory per part and per loop, usually between a supermarket and a point of use, so each part number has its own card set. CONWIP, introduced by Spearman, Woodruff and Hopp in 1990, uses one card set for an entire line: a job enters only when a card is free, and the card returns when the job leaves the end of the line. CONWIP suits high-mix production where per-part supermarkets would be impractical. Both are pull systems, and the same electronic engine can run them.

Which triggers work best for e-kanban signals?

There is no single best trigger. Weight or level sensors suit high-volume consumables in two-bin systems because they need no operator action. RAIN RFID works well for returnable containers passing through a defined empties drop, if read rates are validated around metal. Barcode or QR scans are cheap and explicit but depend on discipline. IoT call buttons are quick to deploy for low-volume items. Many plants combine them, and every trigger needs debounce and deduplication before it changes card state.

Electronic Kanban Architecture: Pull Replenishment, Loop Sizing, MES and ERP Integration for Lean Factories (2026)