A factory can have stock in the warehouse and still stop a line because a part is missing at the point of use. A request may be made verbally but never assigned; the wrong revision may arrive; a rush delivery may bypass the normal route. A line-side parts replenishment instruction system should connect the consumption signal to picking, transport and confirmed receipt at the correct rack. It should make the physical outcome and the transaction record agree.
This guide is for manufacturing teams planning a deployment in Thailand or another Southeast Asian plant. It covers rack and container design, two-bin and min/max triggers, execution ownership, ERP and MES interfaces, failures, cost evaluation, RFP requirements and FAT/SAT evidence. It does not assume that buying software alone prevents shortages.
Define the boundary of the line-side replenishment process
The process starts when a defined point-of-use rack or container needs more material. It ends when a usable part of the correct item, revision, quantity and applicable lot reaches the designated rack and the receiving person confirms it. A request appearing on a screen is not completion. Neither is a warehouse issue transaction if the box is still on a cart. If the method exchanges containers, the empty-container return and full-container placement also belong in the process.
The scope differs from a general electronic Kanban design, which covers the wider conversion of withdrawal and production signals. It also differs from warehouse pick-face replenishment, which refills a warehouse picking location from backstock. Here, the destination is the production line’s point-of-use rack and the signal originates from line consumption. The same platform may support all three jobs, but each needs its own business key, owner and evidence of completion.
Toyota’s history describes how the supermarket method and Kanban connected downstream withdrawal with upstream replenishment. It is a useful process principle, not a software specification or a promise that a particular stock level will work in every plant. Map the physical withdrawal and replacement loop first, then decide how the digital instruction will support it.
Walk the line and reconcile physical racks with master data
Start at the point of use. Record the line, station, rack, item, revision, standard container, quantity unit and supply route. Two racks with the same item can be separate destinations. A location code in ERP may not match the label operators actually see. Confirm every code against the physical rack, and assign an owner to update that mapping after layout changes.
Observe changeovers, trial builds, alternative-part approvals, quality holds, weekend restarts and shift handovers as well as normal production. If an obsolete revision remains on a rack, simply stopping replenishment is insufficient: someone must remove or quarantine the box. If a delivery is placed in an aisle because the rack is full, a delivery scan should not silently close the task. For lot-controlled items, check whether a new box placed in front of an older one breaks the required consumption sequence.
A useful survey sheet includes line and station; rack ID; item and effective revision; unit and container quantity; repacking rules; lot or serial requirements; trigger; required-by time; source location; delivery route and frequency; receiver; and exception owner. Name the source of truth for each master-data field. “ERP owns the master” is too vague if MES owns the rack map and the warehouse system owns bin addresses.
Select two-bin, min/max or order-linked triggers by item
A stable, containerized consumable may suit a two-bin method. Moving the empty container to a return position becomes the request signal; the remaining container covers demand until replenishment arrives. A large, expensive or sporadically used part may need a measured min/max threshold or an order-linked request instead. The plant can use several methods, provided that every item has one unambiguous trigger and a defined override.
Set thresholds from observed route frequency, pick time, travel time, receiving time, demand variation and shift coverage. The minimum should cover demand during the relevant replenishment lead time and the variation the plant chooses to absorb. The maximum is constrained by rack capacity, storage conditions, working capital and mixing risk. Store the rule by item, destination rack and effective period, with approval and revision history. Do not copy a supposedly universal safety-stock number from another facility.
For two-bin operation, decide whether the scan happens when the last part is removed or when the empty box is returned. Specify how a missed scan is detected. A level sensor also needs validation: box geometry, metal reflection and manual refills can misread. Permit a controlled manual correction. A sensor reading is a candidate for a replenishment event; it is not automatically a final inventory balance.
Treat request, pick, transport and receipt as one state machine
The minimum states are requested, accepted, picking, picked, in transit, received, exception and cancelled. For each transition, assign an owner, permitted action and evidence. Can a line operator change quantity after acceptance? Does a change after picking create a separate delta request? Is a return after receipt a correction or a new transaction? Without these rules, every department can show “done” while the physical rack is still short.
Record a request ID, line, station and rack; item and revision; quantity and unit; required-by time; priority; reason; source; timestamp; and requester. A simple “urgent/normal” flag does not tell a route planner which stop has the tighter deadline. Define whether required-by time comes from remaining stock and consumption rate, a supervisor’s decision, or a comparison of both. Store time zones explicitly and test shifts crossing midnight.
The pick instruction should show source location, handling unit, container ID, quantity, substitution permission, quality status and lot-selection rule. Ask the picker to scan both the source and the material or container. Where needed, confirm the label against the physical contents before loading. Barcodes make data capture faster but do not correct a wrong master-data mapping. GS1 barcode standards provide identification structures; the plant must still decide which key and attributes are mandatory for its material and traceability obligations.
The transport task should show route or vehicle, load position, planned departure and destination rack. Siemens positions Opcenter Intra Plant Logistics around material movement between warehouse and shop floor, replenishment and transport execution. That product description is evidence that the function can be supported by an intralogistics platform; it is not evidence that a particular configuration will match this plant’s labels, shift coverage or receiving procedure. Demonstrate those scenarios with real containers before selection.
Separate “the driver placed the box near the line” from “the line verified and received the box.” At receipt, scan the rack and container together, then compare item, quantity and request. Decide who may receive on behalf of an absent operator and how that approval is recorded. If a request is fulfilled by multiple boxes, link each physical movement to the same request without losing quantities. If one box serves multiple requests, preserve the allocation by request.
Make racks, terminals and labels usable on the shop floor
More rack space is not always the answer. Extra mixed boxes can increase searching and wrong-part risk. Define supply-side and use-side access, box orientation, empty-container return, obsolete-part quarantine and visible rack IDs. Test labels under the actual lighting, dust, oil, gloves and scanner distance. If workers use Thai item names and engineering uses English, retain the item code as the stable identifier and show suitable names in the interface.
Specify the scan sequence. Rack then container then quantity detects a different error at a different point from request then container then rack. Try the workflow with one hand, gloves and night-shift lighting. If the terminal buffers events offline, show the unsynchronized status and prevent duplicate registration after reconnecting. If offline work is not supported, document the paper or telephone fallback and the owner of later reconciliation.
Decide whether mixed lots in one container are permitted. If the rule is one lot per container, the system needs a hold or split procedure when a mixed box appears. GS1’s Global Traceability Standard frames critical tracking events and key data elements. Apply that idea to receipt and movement: identify what moved, where, when, under whose custody and for what process reason. A raw scan log is not necessarily proof that the business event was completed.
Give shortages and wrong deliveries named recovery owners
A red alarm cannot produce a missing part. Classify exceptions by cause and next decision: no warehouse stock; book stock without physical stock; quality hold; wrong item or revision; picked but missing in transit; delayed route; full rack; receiving quantity difference; or network outage. Give each a first owner, delegate, communication path and rule for whether limited production may continue.
For no warehouse stock, purchasing or planning checks supply and permitted alternatives; the line leader decides whether to stop or resequence. A warehouse operator should not substitute another item without the required approval. For a wrong delivery, record rejection, quarantine, a replacement request, return movement and inventory correction separately. Simply returning the task to “open” loses the whereabouts of the wrong box.
Measure delay against the required-by time, estimated remaining container coverage and next route. A task that can ride the normal route and a task needing direct delivery should not share one undifferentiated alarm. After recovery, retain who checked what, which state was restored and which cause should be prevented from recurring.
Define ERP, MES and warehouse responsibilities by transaction
ERP often owns purchasing, planning, valued inventory and accounting movements. MES may own production orders, operation status, consumption and line execution. A warehouse system may own storage and picking. Existing deployments differ, so list the source of truth, event origin, commit point and receiving system for each transaction instead of deciding by product name.
| Transaction | Possible origin | Acceptance question |
|---|---|---|
| Production order and required parts | ERP or planning | Did MES receive the effective revision? |
| Line-side request | Bin scan, terminal or level signal | Was one request ID issued without duplication? |
| Warehouse pick | Warehouse terminal | Was physical quantity and lot verified? |
| Internal transport | Driver terminal | Who has custody of each container? |
| Line receipt | Rack and container scan | Does the physical delivery match the request? |
| Consumption and valued inventory | Agreed MES/ERP event | Are posting and reconciliation complete once? |
Keep request IDs distinct from container IDs and transport message IDs. A request may be split across containers; a container may be allocated to more than one request. Message retry is not a business correction. Define what happens if ERP reports technical receipt but not an inventory posting, or if MES has a receipt that ERP does not. The ERP–MES interface error and replay guide explores that boundary in detail.
An empty-bin sensor event is a request candidate, not the moment when valued inventory must move. Warehouse issue, line receipt and actual consumption are separate facts. Set the accounting point according to the plant’s ERP practice and reconcile it with MES use. Validate quality-hold and revision rules at the interface so a successful scan does not release unusable material.
Keep physical custody visible during outages and changes
When a network, terminal, ERP interface or warehouse service fails, business owners must decide whether the line stops or continues under a limited manual procedure. A numbered paper form or restricted fallback terminal should capture request, pick, physical transfer and receipt. “Enter it later” is insufficient: the online queue may create the same request again after recovery.
Reconcile requests committed before failure, requests received but not committed, paper requests and boxes moved without an electronic record. Preserve the paper reference as the origin ID on later entry. Offline devices should retain device identity and event sequence as well as local time. An unacknowledged line receipt is “outcome unknown,” not automatically “not delivered”; do not dispatch a second identical box until custody is checked.
Master-data changes can cause similar failures. An old rack label may remain after a layout change, or MES may accept an alternative item before ERP does. Before publishing a new mapping, compare it with open tasks. Decide whether those tasks continue under their original version or are cancelled and reissued. Keep the reason and approval for changes so an incident can be reconstructed.
Evaluate cost and effect with a measured baseline
Separate software licenses or development from rack alterations, labels, scanners and tablets, wireless coverage, charging, migration, master-data cleanup, ERP/MES/warehouse interfaces, training, FAT/SAT, night-shift support and maintenance. Existing devices still need validation for scan range, environment and spare coverage. Do not accept a universal price or payback claim without an agreed scope and the plant’s own baseline.
Measure material-wait downtime, emergency runs, telephone chasing, wrong-item and wrong-rack events, point-of-use stock, pick and transport effort, receiving discrepancies and unresolved exception age. If production volume or product mix changes, compare per-item or per-request measures alongside totals. A labor saving in logistics is not a net benefit if operators must perform disproportionate extra data entry.
Timestamp request creation, acceptance, pick start and finish, departure, arrival and confirmed receipt. These points reveal whether delay is in picking, route assignment or line acknowledgment. A system may initially show more requests because informal phone calls become visible. Interpret request count together with capture coverage and on-time completion.
Put one traceable replenishment case into the RFP
Supply the line, rack and item scope; routes; language needs; existing systems; network conditions; labels; and lot or serial requirements. Replace the vague requirement “replenishment screen available” with a case that follows one request from its trigger to its receipt and records each key and handoff. Ask vendors to separate standard capability, configuration, custom work and manual steps in their estimates.
Use the same demonstration data for a normal two-bin cycle, min/max trigger, order cancellation, split delivery, wrong item, quality hold, warehouse shortage, night-shift delegate and reconnection after an outage. Assess whether the next owner can understand and act on each exception, not just whether the demo finishes quickly. Use real item codes and label samples because lot and revision rules vary by plant.
The data-interface specification should include item, rack, container, lot and order masters; update order; missing data; acknowledgments; retry and duplicate controls; corrections; cancellation; audit and retention. Compare deployment options against the needed shop-floor response and continuity procedure under actual network conditions. Record the capability of the proposed configuration in the contract and acceptance criteria, rather than relying on a future product roadmap.
Use FAT and SAT to accept both physical and digital results
In FAT, define expected results before each normal and failure test. Scan one empty bin twice: does it create one request? Cancel a production order after picking: what happens to a box already in transit? Apply a quality hold after a pick: can delivery be stopped? Drop an acknowledgment and retry: is stock issued only once? Save screens, event logs, inventory records and operator instructions for each case.
In SAT, use the actual line rack, label, terminal, normal route, emergency route and night shift. Try a wrong-rack placement, a full rack, an obsolete-revision container during changeover and an offline scan that synchronizes later. Define acceptable times from the line’s measured consumption and stoppage impact. An arbitrary universal response time is not a valid acceptance target.
Pick a request ID and reconstruct the trigger, physical warehouse scan, custody transfer, line receipt and ERP/MES result in chronological order. Test who corrects a discrepancy and whether the original record remains visible. During early operation, reconcile open requests with physical containers daily and refine exception rules before widening the item scope.
Stage rollout and assign ownership
Begin with items that repeatedly cause shortages or emergency runs and have a clear rack and manageable container unit. Survey the physical process and baseline first; then clean rack, item and container masters; design request and receipt; implement interfaces and exceptions; run FAT; run SAT; operate a limited scope; and expand after the data and owners work. A business owner should approve the exit from each stage.
Production owns required-by time and receipt criteria; logistics owns picks, routes and delivery; warehouse owns source locations and physical stock; quality owns lot holds and substitution; IT owns interfaces, access and recovery; planning owns demand and order changes. Name an executor, exception decision maker, configuration approver and daily reconciliation owner separately. Add shift and weekend delegates.
After go-live, review racks that always need emergency runs, items that trigger too early and recurring root causes. Change container quantities and min/max values using both shortage risk and space or handling costs. Keep the change history and the affected measures. The system remains useful only while its records still explain the real replenishment work.
Allocate routine routes and emergency deliveries deliberately
Correct requests still overload logistics if each one becomes an individual fastest-route trip. Measure route times, load capacity, stop sequence and walking distance to the point of use. Assign requests to a planned route based on required-by time, estimated remaining stock and expected arrival. When several lines need the same scarce item, name the planning and production owner who decides allocation; do not let the software’s sort order silently decide who stops.
Handle a changed quantity differently before departure, after departure and after arrival. Before departure, a picker may be able to amend the load. After departure, changing the destination requires updating both the physical label and the driver’s task. Decide whether to deliver the original box and return surplus, or recall it in transit. Confirm the driver saw the change and the line saw the revised arrival. Overwriting only the database status leaves an outdated instruction on a handheld device.
Set a specific condition for an emergency trip, such as the normal route missing the required-by time, and retain the reason. If a rack constantly needs emergency service, examine its container quantity, trigger, route timetable and lead-time master. A target to reduce emergency-trip counts alone may drive staff back to unrecorded phone calls. Review correct route assignment, valid urgency, on-time receipt and workload together.
Preserve information needed for shop-floor decisions and recovery
The request list should show item, rack, required-by time, remaining container coverage, current state and next owner, rather than only a red/yellow/green flag. A picker needs source location and lot; a driver needs container and destination; a line receiver needs expected arrival and open receipt. Keep role-specific views without hiding the data needed to resolve a case. Align displayed names with the languages used on the floor, while the item code remains the stable key.
For each state change, retain operator, device, time, old and new values, reason, container ID and request ID. Separate rights to view, amend quantity, approve substitution, close a receiving discrepancy and correct inventory. Define night-shift delegates. Retention periods should follow the plant’s incident, customer traceability, quality and accounting requirements. A request ID should retrieve its related events and ERP documents. Test restoration of one actual history from backup; a “backup succeeded” message does not prove that the factory can explain who received a box.
Train with physical exceptions and control the cutover
Training should explain why an empty box returns to a defined position, why the rack and container are scanned together, and where a rejected part goes. Rehearse a wrong item and a network outage with warehouse, transport, line, quality and planning staff. Use the shop-floor language in procedures and the same terms on screens. If the only training is a sequence of buttons, employees may revert to calls when the first exception occurs.
During parallel paper and digital operation, declare which source creates the official request. If a paper card and screen independently issue tasks, the line can receive twice. At cutover, list open paper requests, boxes already dispatched and boxes awaiting receipt, then reconcile before accepting new digital tasks. Use the same list for rollback, and prevent the online retry queue from reissuing boxes handled on paper. In early operation, inspect labels, scanner failures, device charging and rack mappings daily; record each field fix as a controlled master-data or procedure change.
Frequently asked questions
Is line-side replenishment the same as electronic Kanban?
They overlap but are not identical. Electronic Kanban broadly transmits withdrawal or production signals. A line-side replenishment instruction must follow a specific point-of-use request through warehouse pick, internal transport and verified receipt. A factory may retain paper Kanban and digitize only route execution and receipt.
Should we choose two-bin or min/max replenishment?
Consider consumption stability, container suitability, item value, storage conditions and measured lead time. Two-bin provides a clear empty-container signal but an oversized bin ties up stock and space. Min/max allows finer control but depends on reliable quantity capture. Pilot representative items and compare workload and shortage exposure.
Can larger safety stock replace the system?
More stock may absorb some variation. It does not fix wrong items, wrong racks, missing requests, quality holds or obsolete revisions. Measure the cause of shortages first; separate variability that needs a buffer from failures in communication or execution.
Must ERP and MES be integrated from day one?
The minimum depends on which system owns orders, items, racks, lots and valued inventory. A small pilot can validate request, pick and receipt with limited masters. Production use affecting inventory or consumption needs an agreed interface or reconciliation procedure to prevent double entry and undetected differences.
How should we estimate implementation cost and benefits?
Fix the line, item and rack scope; device and network needs; interface rights; labels; shifts and maintenance. Compare plant-measured material-wait time, emergency trips, wrong deliveries, point-of-use stock and operator effort before and after deployment. A generic saving percentage or payback period would not be reliable for a specific plant.
Summary: close the loop at the rack
A line-side parts replenishment instruction system works when it connects a reliable consumption trigger to the correct pick, a visible movement and confirmed receipt at the right rack. Select two-bin, min/max or order-linked rules by item; define ERP and MES commit points transaction by transaction; and prove exception recovery with physical FAT/SAT scenarios. The result is a process that can explain where each requested container is and who must act next.
If your Thailand plant is still mapping its point-of-use racks and routes, contact TOMAS TECH at the planning stage. A focused review of a few items can establish the request-to-receipt boundary before you compare system proposals.
