Where AMRs Fit in Kitting, from BOM to Assembly

Kit K-01 / Work order W-01 / BOM Rev A / Completeness pending. That record is a process illustration, not a live order or a customer case. It shows the thing this article is about: a kit is not a transport task, it is a set of parts that must arrive at an assembly station complete and in the right version. Where a mobile robot fits is decided by which link in that chain it actually closes and which links remain with people and other equipment.

Define the kit that must arrive

The unit of delivery here is one assemblable kit, not one transport run. Record the kit ID, the work order, the BOM version, the quantities, and the assembly destination. SKU-based replenishment supplies parts to keep a line fed; a kit gathers the specified parts for an assembly and tracks them as one unit. The full range of line-side logistics is not re-expanded here.

The kit as a unit is what the state table below tracks. Every state transition is about the completeness and version of that unit.

Separate picking, checking and transport responsibilities

A capability that is easy to assume and hard to verify is the idea that transport also means picking. It does not. Mark, step by step, what people, fixed equipment, the identification system and the AMR each perform.

Picking. Who or what selects and places the parts into the kit carrier.
Checking. Who verifies the physical parts against the BOM.
Transport. Who moves the completed carrier to the destination.

"Transport complete" never proves that all parts were picked automatically or that all parts were identified. Whether a supplier's offering includes picking or verification has to be checked in the original configuration, because those are per-product questions, not line-wide assumptions.

Load identity and how a physical load matches a task connect to matching the physical load to its task identity, which handles read zones and identity matching at the load level.

Release a kit only under a defined completeness rule

Before transport, a kit needs a business gate that can be explained. Distinguish four things that are often merged: the system has picked the parts, the physical parts are loaded, the check has passed, and release is allowed. The default complete-kit flow releases only after completeness. If the customer permits partial delivery, that must be an explicitly authorized business state, not a silent equivalent of complete.

The state table is a design suggestion, not an API enumeration that any supplier already supports.

State	Entry basis	Permitted next action	Release / review owner
Picking	Work order, BOM version and kit ID established	Pick and record what is actually loaded	Picking party
Verification pending	Picking step done but physical parts not yet verified	Check actual parts against the BOM	Assigned verifier
Ready	Defined completeness and version rules met	Request transport for this kit	Customer-designated release role
Shortage hold	One or more material items unmet	Replenish, or enter an explicitly authorized partial-delivery flow	Material / planning owner
Revision review	A related BOM change affects this kit	Review, reconfigure, or approve a substitute	Engineering / production authority
Transport accepted	The transport system accepted a task associated with this kit ID and BOM version; departure is not yet confirmed	Monitor the assigned task or apply the defined cancellation/reconciliation procedure	Transport system / operations
In transit	A departure or movement event is recorded for the assigned kit and task, with its time or event association	Track the kit to the destination station	Transport system / operations
Arrived, not accepted	Arrival is recorded but the station has not confirmed receipt	Check station, sequence and version	Assembly receiver
Accepted	The receiving check passed for this kit and version	Release it to the authorized assembly step	Designated receiving role
Return authorized	A return reason, destination and responsibility are recorded	Start a controlled return task; track its movement separately	Designated receiving / return role

Hold a shortage without losing the kit identity

A shortage is a state, not an ad-hoc resend. Keep the parts already loaded, the missing items, the handling responsibility and the release condition together on the kit record. When the missing parts arrive, record which kit and BOM version they still correspond to, so a short kit is never released twice.

Use the kit ID and BOM version to associate the shortage record with the physical carrier. Prevent a duplicate release by checking the current release state and any active transport task before authorizing another one, then reconciling canceled or interrupted tasks under the agreed process. Identity makes those checks traceable; identity alone does not enforce them.

Reopen affected kits when the BOM changes

A BOM change is not a single line rename. Check which material items in current kits the change affects, how already-released or in-transit kits enter review, and who approves a substitute. Do not require every line of BOM text to stop the line; define the action by the impact.

If the change affects a kit already in transit, record the review instruction for the destination station and the receipt gate. Changing the database version number alone does not protect the physical kit.

Match the arrival to the assembly sequence

The physical arrival and the business receipt are different events. Check the station, the work-order version and the sequence. Record arrival, acceptance and return separately, because a kit can arrive at the wrong station or for the wrong sequence and still be physically present.

Route scheduling and fleet-size planning stay with their own topic; this section only connects the kit to the station it must serve.

Compare AMR assistance with the work that remains

The process choice follows from the roles and the exception load, not from an assumption that robots handle everything. Compare the present flow with an AMR-assisted candidate across errors, waiting, transport labor, returns and work-in-progress input. Record the same fields along each of the three scenarios below.

The three scenarios are complete illustrations used to check the flow, not site cases.

Normal. K-01 / BOM A → Picking → Verification pending → Ready → Transport accepted → departure or movement recorded for that kit and task → In transit → Arrived, not accepted → Accepted after station check.
Shortage. K-02 / BOM A → Verification pending → Shortage hold → Replenish and re-verify → Ready. If partial delivery is authorized, record its scope separately; the kit does not jump to an ordinary complete state.
Revision. K-03 / BOM A already Ready → related BOM B change notice → Revision review → check affected items and reconfigure or approve → re-verify under BOM B → Ready. If already in transit, record the review instruction for the destination station and the receipt gate; a database version change alone is not enough.

Differences from SKU-based replenishment belong with line-side replenishment for electronics assembly, and station sequencing in mixed-model production sits with line-side sequencing in mixed-model production.

Pilot the transport leg only after picking, completeness checks and shortage handling have named owners. An application assessment can start from the kit-state map, the proposed transport legs and the exception workload. AIsirRobot can help organize the application questions; the process comparison must still show which work remains with people and which capability is actually included in the proposed system.