Electronic Kanban | RFP and 90-Day PoC for Thai Factories

The first decision in an electronic kanban implementation is not the device or cloud product. It is the pull rule: what event creates demand, who replenishes what quantity from which source to which destination, and whose acknowledgement closes the loop. Merely moving paper cards onto a screen replaces a missing card with an unacknowledged alert; it does not remove the causes of shortages, over-replenishment or inventory differences. This guide helps manufacturing, logistics and IT leaders in Thailand turn kanban systemisation into an RFP, a proposed 90-day PoC, FAT/SAT acceptance evidence and a controlled rollout.

The decision first | Digitise only after defining the closed pull loop

An electronic kanban is not simply a digital card. It manages a stateful replenishment loop with an explicit trigger, quantity, source, destination, acknowledgement, exception path and audit trail. Separate three kinds of truth before selecting a product:

1. Physical truth — where the container or part actually is and whether it is usable.
2. Inventory truth — the quantity, lot, allocation and quality state held by ERP or WMS.
3. Signal truth — whether a replenishment request is issued, acknowledged, assigned, in transit, arrived, cancelled or in exception.

If the e-kanban service creates its own full inventory ledger, it can become a second ERP or WMS. If ERP alone is forced to represent every second-by-second shop-floor condition, it may not provide the field state or outage behaviour operators need. The starting point is to name a system of record for each fact and design reconciliation for duplicate, delayed and cancelled events.

Paper kanban is not automatically inferior. It can remain the better choice where variability is low, routes are stable, transaction volume is small, abnormal conditions are obvious and integration or remote visibility adds little value. Digitisation becomes more compelling when loops cross buildings or suppliers, signal volume is high, lead time varies, cards go missing, or the business needs remote monitoring, reconciliation and audit evidence.

What electronic kanban means | Connecting Toyota’s pull principle through events

Toyota describes the Toyota Production System through the two pillars of jidoka and Just-in-Time. Its official explanation defines Just-in-Time as making only what is needed, when needed and in the required quantity. It also explains the downstream process taking what it needs from the upstream process, which replenishes what was taken. Kanban coordinates that quantity and timing.

Digitising this principle therefore means connecting the fact that generated pull demand with every subsequent state. A minimum e-kanban event needs the following elements.

“Scan the empty box and issue a replenishment order” is not a complete design. Define what happens when the same container is scanned twice, connectivity fails after the scan, stock is unavailable at the source, a substitute is needed, quality blocks the item, or the material arrives before the electronic acknowledgement.

Map the current loop before systemising kanban

Before writing an RFP, select one representative item and walk its full loop. Observe normal shifts, breaks, night work, period-end demand, schedule changes, shortages and quality holds—not just the official procedure discussed in a meeting room. Capture the following in one current-state sheet:

• part number, revision, substitute relationship and quality state;
• container ID, pack type, standard quantity and partial packs;
• line-side supermarket, point of use, maximum and minimum containers;
• source, route, milk-run cycle and cut-off time;
• trigger, issuer, scan location and movement of the paper card;
• acknowledgement points for receipt, picking, departure, arrival and line use;
• entries made in ERP, WMS, MES, spreadsheets and paper forms;
• shortages, wrong parts, damage, holds, returns, substitutions and expedited runs;
• manual work when connectivity, devices, printers or labels are unavailable; and
• daily reconciliation time, correction authority and approver.

Look for places where the signal and material diverge. An operator may remove a card early, batch several cards, ask the warehouse by telephone, or the route driver may replenish from experience. Each behaviour has a reason: inadequate container sizing, the wrong milk-run frequency, invisible quality holds or late schedule changes. Copying the workaround into a screen does not fix its cause.

For a broader view of routes and material movement, see our Thailand factory intralogistics improvement cases. When planning volatility drives unstable replenishment, use the Thailand production-planning simulation guide to separate planning decisions from execution signals.

Separate the signal system of record from the inventory system of record

ISA-95 provides a technology-neutral model for enterprise and control-system integration. Level 3 covers manufacturing operations management, while Level 4 covers business planning and logistics. It does not prescribe an e-kanban product, but it gives stakeholders a common language for discussing the boundary between ERP, MES and control.

The following responsibility split is a product-neutral starting point.

Create an event contract rather than a screen-by-screen interface list. For a “container consumed” event, define the producer, required fields, correlation ID, event time, receipt confirmation, duplicate rule, cancellation, retry, retention and owner. State whether e-kanban may continue when ERP is delayed, whether a WMS quality hold stops assignment, and whether an MES schedule change recalculates unstarted signals.

Idempotency is essential. Receiving the same event twice must not issue two replenishments. An out-of-order event must not corrupt state. Cancellation and reissue must remain traceable. “Real-time integration” alone says nothing about consistency under delay, duplication or loss, so the RFP must test failure behaviour as well as normal speed.

Identification and capture | Choose barcode, QR or RFID from the work

GS1 explains standards through identify, capture and share, and lists barcodes and RFID as data carriers. It also describes GTIN for products and services, GLN for parties and locations, SSCC for logistics units, and GRAI/GIAI for assets. These are useful options where globally unique or cross-company identification is required; they do not mean every internal e-kanban must use a GS1 key.

Choose capture technology from the object, distance, contamination, shielding, misread risk, relabelling, cost, maintenance and partner-sharing requirements.

Barcodes can encode identifiers and attributes such as serial, batch, lot and date. However, placing too much changeable information on a permanent container label creates stale data after master or assignment changes. A strong default is to scan a persistent ID and retrieve current attributes from the system of record, while caching only the minimum required for controlled offline work.

OPC UA spans sensors, control systems, MES and ERP, and defines information, message, communication and conformance models. It supports Client/Server and PubSub and can therefore be one integration option for machine or edge events. It is not a mandatory e-kanban protocol. Adopt it only where existing assets, latency, security and maintenance capability justify it, and still define the business meaning of each event.

Electronic kanban as a work-instruction system

A binary open/closed flag is too weak when e-kanban drives logistics work. The following states are a proposed example and must be adapted to the plant.

For each transition, define who can perform it, what they must scan, which conditions allow it and which state follows. Manual quantity changes require before/after values, a reason and approval. An emergency run should not be hidden outside the process; model it as an exception route with limited authority and later reconciliation.

Views should also follow roles. Line operators need the next action and abnormalities; logistics teams need priority and route; supervisors need ageing and escalation; administrators need masters, interfaces and audit. A single dashboard for everyone usually increases information without improving decisions.

Offline and exception design | Decide what must not continue

Wireless dead zones, failed devices, a cloud outage, ERP downtime and printer failure must be expected in a Thailand factory. “Offline supported” is not enough. The design must say which transactions continue, continue conditionally or stop. Allowing every inventory-changing action offline increases conflicting work on the same container.

A useful proposed classification is:

1. Continue — cached master data and unused IDs exist, and conflict risk is limited.
2. Conditionally continue — supervisor approval, quantity caps and a defined zone allow a controlled manual form.
3. Stop — quality release, substitution approval, conflicting stock updates or an action requiring live authorisation.

A manual fallback record should contain issue time, container, item, quantity, source, destination, reason, recorder, approver and a unique temporary ID. After recovery, do not bulk-enter it blindly. Compare it with existing signals, sequence, physical material, inventory and quality state. The objective is not to ban paper but to make emergency paper controlled and reconcilable.

At minimum, test these exceptions:

• scan the same code repeatedly on one device and on two devices;
• disconnect just before and after issue, acknowledgement and arrival;
• create shortage, quality hold, substitute and partial-container cases;
• receive route change, priority change, cancellation and reissue out of order;
• lose a device, exhaust its battery, force-close the app and shift its clock;
• stop the printer and leave an old label in circulation after reprint;
• send delayed, duplicate and invalid messages from ERP or WMS; and
• reconcile physical material, signal state, inventory and interface queues after recovery.

Recovery is complete only when there are no unexplained unsent events, duplicates are resolved, exceptions have owners, downstream ERP/WMS/MES processes are complete, and the daily physical reconciliation can be explained.

Inventory visibility requires definitions before colours

Define the denominator and clock before creating red, amber and green dashboards. For “late”, distinguish issue-to-acknowledgement, acknowledgement-to-departure and departure-to-arrival. For “short”, distinguish physical shortage, unallocated stock, quality-available stock and insufficient containers for outstanding signals.

The following operational views are proposals. Thresholds must come from the site’s own baseline, not from an external benchmark.

Using individual throughput as the dominant KPI can encourage premature acknowledgement and hidden exceptions. Use the data first to improve signal design, routes, container quantity, masters, plans and supply capacity. Where logs are linked to individuals, clarify purpose, access, retention and permitted use with the responsible teams.

Electronic kanban RFP | Make every requirement answerable and testable

The RFP should be the first draft of acceptance testing. Give every requirement an ID, priority, response format, assumption, limit, evidence type, PoC case and contract destination. Require suppliers to classify support as standard, configuration, customisation, third-party, out of scope or roadmap—not merely “supported”.

Define disqualifiers before scoring. Proposed examples include creating duplicate replenishment from a duplicate event, permitting silent deletion of audit logs, having no method to reconcile after an outage, lacking standard data export or refusing to disclose support end conditions. Adapt the severity to supply, quality and information-security risk, and do not allow points elsewhere to offset a critical failure.

Compare total cost, not only licences. Separate devices, scanners, tags and labels, printers, wireless improvements, edge equipment, interfaces, master cleanup, migration, testing, training, on-site support, cloud, monitoring, maintenance, change and future sites. This article deliberately supplies no market price or savings benchmark. Require quantities, unit prices, one-time/recurring cost, required/optional scope, volume assumptions, currency/tax and price-escalation rules.

Thailand BOI’s official material on upgrades toward smart and sustainable industry includes eligible categories related to automation, digital technology, software/IT systems and cloud services under stated conditions. That does not mean an electronic kanban project automatically qualifies. Confirm the current activity, investment, timing and evidence requirements with BOI and qualified advisers before relying on an incentive.

A proposed 90-day PoC | Build rollout evidence, not a product demo

The schedule below is a proposed validation framework, not an external standard or a result guarantee. Adjust it to shifts, seasonality, replenishment cycles and interface scope. The objective is to test the riskiest assumptions under production-like conditions.

Proposed days 0–15 | Baseline and freeze the pilot loop

Limit scope to one line, one supermarket, representative items and shifts. Measure current signals, shortages, emergency deliveries, missing cards, reconciliation differences, route cycles and work time with written definitions. These values are the plant’s own baseline, not an industry benchmark.

Freeze the pull rule, containers, source/destination, states, exceptions, manual fallback, system boundaries, test IDs and acceptance authority. Include partial packs, substitutes, quality holds and plan changes—not only easy items.

Proposed days 16–30 | Connect data contracts and the minimum solution

Agree the system of record for item, container, place, user and route. Connect event contracts between ERP, WMS, MES and e-kanban. Configure correlation IDs, duplicates, cancellation, retry, monitoring and retention. Put devices, permissions, labels, Thai UI and audit settings under configuration control.

Proposed days 31–60 | Run normal, peak and exception work in the field

Thai operators use actual devices, labels and routes from trigger to arrival. Include shift start, return from breaks, plan changes, simultaneous demand, shortage, wrong part, substitution and return. Measure not just averages but queues, long-tail ageing, rescans and supervisor calls.

Proposed days 61–75 | Break it deliberately and recover

Inject connectivity loss, ERP downtime, delayed/duplicate/out-of-order messages, device loss, printer stop, bad master data and unauthorised actions. Verify that risky work stops, permitted work is constrained, recovery causes no duplicate replenishment and manual records reconcile.

Proposed days 76–90 | Assemble evidence and make the rollout decision

Link requirement IDs to test IDs and preserve input, expected result, actual result, logs, screens, physical checks, executor and time. Give unresolved items a severity, workaround, owner and due date. Use the proposed decisions “scale”, “conditional scale”, “retest” and “stop”, based on an acceptance committee’s evidence rather than demo impressions.

Proposed scorecard and TCO worksheet

The weights below are proposals, not an external standard. Reweight them for the plant’s supply, quality, audit and support risks. Critical disqualifiers should remain gates.

Build TCO by quantity, unit price, implementation period, steady state, refresh year and added sites. On the benefit side, avoid an unsupported single “inventory reduction” percentage. Decompose expedited freight, shortages, searching, manual entry, reconciliation, card reprint and difference investigation into observable time, count and cost. Record baseline, PoC value, formula, measurement period and exclusions together.

FAT and SAT acceptance cases | Verify an evidence chain

FAT normally validates configuration and integration in a controlled environment; SAT confirms performance in the Thailand factory with actual networks, devices, routes, shifts and operators. Adapt contractual names and scope, but cover at least these cases.

Counts and response thresholds must be proposed from observed baseline and peak design. Avoid unsupported universal targets such as “always under two seconds”. Define measurement point, population, percentile and allowable exceptions separately for issue, list refresh, printing, integration and recovery.

The evidence pack should include requirement/test traceability, configuration and master versions, device and label version, input, expectation, result, logs, executor, time, difference, correction, retest and approval. Confirm that one correlation ID traces demand through arrival and the necessary inventory or production follow-on event.

Extend electronic kanban to automated line supply in stages

Introducing e-kanban does not require an immediate move to AGVs, AMRs, automated storage or direct machine dispatch. Stabilise signal quality and exception handling with human transport first, then add transport-task conversion, route allocation and equipment interlocks.

Keep the replenishment request separate from the transport execution task. One request may be split across transports, one route may consolidate multiple requests, and equipment failure may transfer the task to a person. Relate request, task and container IDs and define when responsibility changes.

A proposed rollout sequence is one line and shift, all shifts on that line, adjacent lines, multiple buildings, external suppliers, and finally transport automation. At every stage, use gates such as no unresolved critical failure, complete reconciliation, tested fallback and trained operators. The stages and timing are proposals and must follow site dependencies.

Proposed 30, 60 and 90-day operating gates

These are proposed review points, not statutory or standards-based deadlines.

• Proposed day 30 gate — remove the main causes of unacknowledged signals, long ageing, duplicate scans, manual forms, interface errors and differences.
• Proposed day 60 gate — tune containers, routes, alerts, permissions, training and support procedures from evidence.
• Proposed day 90 gate — decide whether to scale, continue conditionally, redesign or stop.

Every gate should state scope, period, population, exclusions, baseline, proposed target, actual result and open risks. Consistent definitions matter more than impressive percentages. Integrate change control as well: ERP/WMS/MES versions, edge settings, device OS, application, printer, label, wireless, permissions and masters can affect one another. Retest representative work and outage recovery before deployment.

Common failure patterns

Copying each paper card directly to a screen

This loses tacit batching, anticipation and emergency communication. Walk the current loop and redesign normal, exception and failure transitions.

Giving e-kanban a duplicate inventory ledger

Quantities drift from ERP/WMS and correction ownership becomes unclear. Separate signal and stock and agree correction rights and reconciliation time. The Thailand WMS implementation guide provides more detail on the warehouse side.

Treating real-time integration as the only success criterion

Normal speed does not prove integrity under delay, duplicate, loss or reverse order. Require failure injection and correlation-ID reconciliation.

Prohibiting paper fallback

The line either stops or unofficial notes appear. Define controlled manual IDs, approval and post-recovery reconciliation.

Using dashboards to monitor individuals

It encourages gaming and hidden exceptions. Use measures to improve routes, signals, masters, plans and supply capability, while governing personal data use.

Demonstrating only the happy path in the PoC

Production failures involve shortage, quality hold, substitution, outage, label error and plan change. Deliberately create them and prove safe stop, fallback, recovery and reconciliation.

Electronic kanban implementation checklist

Before RFP

• [ ] Separate physical, inventory and signal truth.
• [ ] Define trigger, quantity, source, destination, acknowledgement, exception and audit.
• [ ] Observe the paper loop in normal, exception and failure conditions.
• [ ] Assign records of truth across ERP, WMS, MES, edge and e-kanban.
• [ ] Define container, item, place and logistics-unit identification.
• [ ] Decide continue, conditional-continue and stop actions for outages.
• [ ] Specify Thai UI, labels, training and local support.
• [ ] Attach evidence, score and PoC cases to each requirement.

During the proposed 90-day PoC

• [ ] Freeze baseline definition, population and period.
• [ ] Use real items, containers, routes and operators.
• [ ] Test duplicate, delay, reverse order, cancellation and retry.
• [ ] Test shortage, quality hold, substitution, remainder and emergency.
• [ ] Test outage, failed device, stopped printer and interface downtime.
• [ ] Reconcile manual fallback after recovery.
• [ ] Do not offset a critical disqualifier with score points.

Before production rollout

• [ ] Keep one inventory and signal system of record per scope.
• [ ] Name cutover, degraded-mode, stop and rollback owners.
• [ ] Approve acceptance evidence and unresolved items.
• [ ] Name decision owners for proposed 30/60/90-day gates.
• [ ] Document conditions for the next line and next site.
• [ ] Confirm data export, contract termination and support life.

FAQ | Electronic kanban and related systems

Is electronic kanban simply a way to eliminate paper cards?

Paper reduction is a possible outcome, not the essence. E-kanban connects trigger, quantity, source, destination, acknowledgement, exception and audit as a controlled state transition. Keeping paper can be rational for a small, stable and visually controlled loop.

Where should kanban systemisation start?

Choose one loop that is important but not existentially risky, contains representative exceptions and has clear sources, destinations and owners. The easiest loop tests too little; an enterprise-wide loop makes causes hard to isolate.

How does a work-instruction system differ from electronic kanban?

A work-instruction system allocates a broad range of production and logistics tasks. E-kanban specifically represents downstream pull demand for replenishment. In practice, a signal often creates a logistics task, so related IDs and ownership boundaries are required.

Is e-kanban enough for inventory visibility?

No. It shows signal ageing, while ERP or WMS may own available quantity, allocation, quality hold and physical adjustments. A useful view reconciles signal, inventory and physical truth at the same cut-off.

Are RFID and AGVs mandatory for automated line supply?

No. A barcode and human milk run may be adequate. Consider RFID where bulk or contactless capture creates value, and AGV/AMR where stable transport tasks and safe exceptions exist. Select technology from the loop and acceptance case.

Can a 90-day PoC guarantee benefits?

No. Ninety days is a proposed framework, not a guarantee. It creates evidence under the site’s baseline and production-like conditions so leaders can scale, conditionally scale, retest or stop.

Should the investment assume BOI incentives?

No. BOI materials include conditional categories, but eligibility depends on the individual activity, investment, timing, evidence and current rules. Verify it independently and keep the operating business case separate.

Summary | Electronic kanban succeeds when signal, stock and material reconcile

Electronic kanban implementation is not measured by the number of paper cards converted to screens. Define the trigger, quantity, source, destination, acknowledgement, exception and audit as a closed pull loop. Separate signal ownership from inventory ownership and reconcile both with physical material. Retain paper where it is the simplest reliable control and digitise loops with cross-building complexity, variable lead time, high volume, lost-card risk or audit needs. Make the RFP the first version of acceptance testing, and use a proposed 90-day PoC to test duplicates, outages, shortages, quality holds and recovery—not only the happy path. Roll out only where the evidence is complete.

TOMAS TECH supports manufacturers from current-loop mapping and ERP/WMS/MES boundary design through RFPs, Thai-language PoCs and FAT/SAT evidence. You can contact us even at the concept stage, when the product is undecided or when the first question is where paper kanban should remain.

References

• Toyota Motor Corporation, Toyota Production System: https://global.toyota/en/company/vision-and-philosophy/production-system/
• Toyota Motor Corporation, Virtual Plant Tour / Pull System: https://global.toyota/en/company/plant-tours/production-system/
• ISA, ISA-95 Standard: https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
• GS1, How GS1 standards work: https://www.gs1.org/standards/how-gs1-standards-work
• GS1, Identification keys: https://www.gs1.org/standards/id-keys
• GS1, Barcodes: https://www.gs1.org/standards/barcodes
• OPC Foundation, OPC UA Part 1 Overview: https://reference.opcfoundation.org/specs/OPC-10000-1/4
• Thailand Board of Investment, Measure for Industrial Upgrades towards Smart and Sustainable Industry: https://www.boi.go.th/upload/content/Smart_and_Sustainable_Industry.pdf

*This article is a general implementation guide based on public information available on 8 September 2026. The 90-day PoC, 30/60/90-day gates, weights, thresholds, stages and test volumes are proposed examples—not legal requirements, external benchmarks or benefit guarantees. Confirm regulatory, contractual, security and investment decisions with your responsible teams and advisers.*