Do You Order Spare Parts Only When the Line Has Already Stopped?

Spare parts management for machinery before a line stoppage

Spare parts management for machinery keeps track of which part belongs to which machine, how many remain on the shelf, and who needs to reorder them before a breakdown occurs. You record the spare part that would halt production if missing, compare stock levels against lead times, and prepare a purchase proposal for the procurement team. The useful action is not filling the warehouse: it is spotting the gap while the supplier still has time, not when the line has already stopped.

The weak point in a production department is almost never the absence of a shelf. It is the fact that maintenance, warehousing, and purchasing update separate records. The technician notes the breakdown on a sheet of paper, in messages, or verbally. The warehouse counts parts when someone happens to walk by. Purchasing only sees the request when it is already urgent. What is usually missing is the code linking the machine to the spare part, the threshold below which reordering makes sense, the date of the last withdrawal, and the usual supplier. Without those fields the decision arrives late, even if that part had already been used before.

Why spare part reordering remains an emergency

Reordering remains an emergency when the minimum stock level is not recorded in the same place where maintenance logs the withdrawal.

A bearing, a gasket, or a circuit board leaves the shelf during an intervention. The person who resolves the breakdown returns to the line. The withdrawal does not update the quantity. The threshold, if it exists, sits in a spreadsheet that purchasing does not open every morning. The supplier's delivery time lives in someone's memory, until the person who remembered it is absent. At the next breakdown the drawer is empty and the line waits for a courier. Someone leaves the department to search for an equivalent code. Someone else calls the supplier without knowing whether an identical part is already on its way from a previous order.

You do not need a huge facility. A single department where spare parts are scattered across shelves, drawers, and a box of components kept "because they might come in handy" is enough. Someone with little time between interventions does not update the spreadsheet. The buyer does not see which codes have already stopped a production run. The two do not argue: they simply do not look at the same data.

Who discovers the missing part only when the line has stopped

This is the situation of someone who walks into the warehouse with the machine already switched off. The code is known, the supplier too, but the order is placed that same day. The time lost is not just the repair: it is the wait. A management system does not shorten the supplier's delivery time on its own. It can, however, show in advance that the code was below the quantity the department had decided to keep, and that the last withdrawal had not generated any request. The practical difference is the moment at which the gap is discovered.

Who keeps the parts list, stock levels, and breakdowns in separate places

Here the problem is one of readability, not memory. The machine's parts list sits in a manufacturer's PDF or in a filing cabinet. Quantities sit in a spreadsheet. The breakdown history sits in the technician's notes or in group messages. None of the three, on its own, indicates that a given code has already stopped that machine and that very few units remain. When systems do not communicate, a person acts as the bridge every single time. The signals are the same as those seen when business software systems do not exchange data: the same fact rewritten by hand in multiple places, with one version always more out of date than the others.

A stoppage does not originate from the part itself: it originates from the fact that stock levels, the parts list, and the breakdown history are not in the same place at the moment someone needs to decide whether to order.

How to identify which spare parts are critical for a line stoppage

A spare part is critical for a line stoppage if, when missing, production halts and there is no substitute in house nor a supplier who can deliver in time.

The complete parts list for a machine is almost always too long to be treated uniformly. An easy-to-find screw and a circuit board with a single supplier do not deserve the same attention. The useful work is separating codes that can wait from those that, if missing, hold up an already confirmed order. The price of the part is not enough to decide: an inexpensive component that stops the line weighs more than a costly spare part for which an equivalent already exists on the shelf.

This can be done without sensors and without connecting a program to the machine. It requires the data the department already produces when logging an intervention: machine, symptom, part replaced, date. To these you add questions that someone in the department can answer better than an anonymous spreadsheet.

• If this code is missing, does the machine stop, or can the batch be finished with an equivalent part?
• Is there only one supplier, or can the code also be sourced from another distributor?
• Is the lead time longer than the interval at which this part wears out or breaks?
• Was the last withdrawal recorded, or does the drawer empty itself without leaving a trace?
• Is the spare part tied to a single critical machine, or is it common to several pieces of equipment and therefore used up more quickly?
• Is there a stock level decided by the department, or is the right quantity simply what the person who placed the last order remembers?

Spare parts with long lead times and a single supplier

These are the first to highlight, not because they cost more, but because lost time cannot be recovered on the day of the breakdown. In the management system the field that matters is the procurement lead time, updated whenever a delivery arrives later than the supplier had indicated. Without that field the threshold is a number detached from reality: it can be high for a part the supplier ships immediately and low for a part that requires a long wait. A buyer seeing only the quantity does not know which of the two gaps is urgent.

Parts that block an already confirmed order

Not all machines carry the same weight. A stoppage on a production run with a date already promised to the customer weighs more than a stoppage on a backup piece of equipment. The production planner knows this. The spare parts buyer often does not, if in the management system the machine is not the same one that planning uses to indicate where the work flows. Here too, no connection to the equipment is needed: what is needed is a unique, shared machine code. Scheduled maintenance does not replace stock. A calendar-based intervention fails in the same way if the planned part is not on the shelf. Keeping deadlines visible, as when you do not want to miss maintenance deadlines, and having the spare parts for those interventions already reserved, are two records that need to be visible together.

What a stock and maintenance management system needs to connect

A management system that is useful for maintenance connects the machine's parts list, the quantity on the shelf, and the intervention history, and proposes a reorder without sending it on its own.

Off-the-shelf warehouse programs count incoming and outgoing items well. They often do not know the machine. An item code without a parts list becomes a generic part: you know that few remain, but you do not know which machine stops if they run out. Custom software starts from the department's process, not from the supplier's catalogue. This is the same reason why, in production, off-the-shelf programs hold back manufacturing SMEs when the actual work does not fit the standard fields.

The fields that are usually missing, and that change the working day for the buyer, are concrete. Without them the screen shows a balance and hides the decision.

1. Machine: a stable code, the same one used by both maintenance and planning.
2. Spare part: internal code, supplier code, and a description the technician recognises on the shelf.
3. Link: which spare part belongs to which machine, and whether production stops without that part.
4. Stock: quantity on hand, quantity already reserved for a planned intervention, threshold below which a proposal is prepared.
5. Movement: every withdrawal and every return, with date and intervention, not just a month-end balance.
6. Supply: usual supplier, observed procurement lead time, possible second supplier.
7. History: interventions in which that code was replaced, written by maintenance and readable by purchasing.
8. Proposal: a draft order, with quantity and supplier, awaiting confirmation from a person.

The quantity on hand does not equal the free quantity. If two parts have already been set aside for a planned intervention, someone looking only at the balance believes they are available. The threshold must be compared against what remains after commitments are deducted. It is set by whoever knows the machine, and revised when a part breaks more often than expected or when a supplier extends the wait. The software keeps the threshold visible and flags the deviation. It does not invent the threshold on behalf of the department.

The cycle closes when the goods arrive. Proposal confirmed, order sent, package received, balance updated: if the last step is missing, the next proposal is generated from stock that has already been replenished and someone orders twice. The same applies to returns. A part removed and put back on the shelf, if it does not re-enter the balance, leaves a phantom gap and a pointless request.

Where to start without stopping production

The first step is not loading the manufacturer's entire catalogue. It is choosing the machines that, if they stop, block an order, and for each of them the spare parts the department has already replaced or fears it will not be able to find. You transcribe the codes that currently live on labels, sheets, and PDFs. You count what is actually on the shelf, once, together with the people who use it. You write the threshold together with maintenance and purchasing. The shift does not stop: you test the real cycle on that slice, withdrawal, balance, proposal, and confirmation. If the proposal does not match what the person would have ordered, you correct the missing field before extending to the other machines.

Where the agent flags the reorder and where a person confirms it

An agent can read stock levels, withdrawals, and intervention notes and prepare a reorder notification, while sending the order to the supplier remains a human confirmation.

It is worth being precise about the type of automation involved. Connecting sensors to a machine, reading vibrations, or commanding equipment is industrial automation. It is not the work of a spare parts management system. Software automation takes a process that someone currently carries out at a computer, understands it step by step, and executes it on data that has already been entered: quantities, codes, email, spreadsheets, intervention notes. If the breakdown has not been recorded, the program does not guess it.

On that data an agent can remove repetitive work. It can compare the free stock against the threshold every time a withdrawal is recorded. It can bring together in a single notification the code, the machine, the last intervention, and the usual supplier. It can alert the buyer that a proposal is ready, rather than waiting for the technician's message. It should not send an order while the department has not yet checked the quantity, and it should not change a threshold used by everyone on its own.

The agent prepares the reorder proposal from data that has already been recorded. The order to the supplier is sent only after a person confirms it, for as long as that behaviour has not been observed and refined on the department's real cases.

Confirmation is not an obstacle. It is the point at which a duplicate order, a wrong code, or the purchase of a part the technician has already recovered from another machine is avoided. The person confirming checks four things: the internal code matches the supplier's code, the proposed quantity covers the threshold without depleting another machine, the part is not already on its way, and the intervention note explains why the balance dropped. On sensitive actions the person remains in the loop. The agent's autonomy can grow only where the department has seen that the notifications match what it would have done anyway.

The quality of the notes also matters. If the intervention record only states that something broke and was replaced, the agent has little to read. If the note specifies the machine, the symptom, and the replaced code, the next notification is more useful for someone who was not in the department that day. Text and management system data work together: the quantity field confirms the balance, the note explains the reason.

How Leomat builds software around the reorder process

Leomat builds custom applications and management systems that connect the data already used by the department, with agents that notify and a person who confirms sensitive actions.

The spare parts issue is not solved by purchasing a connection to the machine. It is solved when maintenance, warehousing, and purchasing stop rewriting the same facts in different places. Leomat designs and builds custom web applications and management systems, from the database to the interface, together with the environment in which the software lives: deployment, backups, monitoring, and ongoing corrections. Automations remove repetitive work. Agents act on business data and, for sensitive actions, ask for confirmation.

In reordering, this means starting from the process, not from a list of pre-built features. You look at who withdraws parts, who records the intervention, who currently passes the order to the supplier, and which systems do not communicate: management system, email, spreadsheets, documents. If a step is not worth automating, that is stated upfront. The agent can prepare the notification. Sending the order remains a confirmation, and autonomy grows only where the behaviour has proved reliable. No timelines are given before the process has been seen: you start with a small slice, put it into production, and judge it in the field.

Leomat does not do industrial automation. It does not install sensors and does not connect machinery. It builds custom software: management systems, integrations between systems that currently do not communicate, and agents that act on business data. What the system does remains tracked. The first conversation serves to understand the process and to respond with an approach, an architecture, and a realistic estimate, without inflated promises.

Frequently asked questions about spare parts management

The most useful questions start from a stoppage that has already been experienced: which code was missing, where it was recorded, and who should have reordered it beforehand.

How are critical spare parts managed to avoid stopping the line?

You start with the machines that block an order if they stop and the parts that, when missing, have no substitute in house. For each code you record the quantity on the shelf, the quantity already reserved, the threshold set by the department, the supplier, and the observed procurement lead time, not the one someone remembers verbally. Every withdrawal updates the balance and generates a reorder proposal, which a person reviews before it is sent. The management system does not shorten the supplier's delivery time. It moves the decision to the moment when the machine is still running and the code is already below the threshold. Without the link between machine and spare part, stock remains a number that does not indicate who stops.

Does spare parts stock management software replace the maintenance team?

No. The maintenance team remains the source of the withdrawal and the judgement on the part. The software prevents that judgement from remaining only in a message. The technician specifies the machine, the symptom, and the replaced code. The balance drops. Purchasing sees the same record, not a rewritten copy the following day. An agent can bring the fields together in a notification. It does not decide on behalf of the department whether a code is critical, and it does not send the order. The threshold is set by whoever knows the machine, and revised when recorded breakdowns or supplier delays change the picture. The program keeps the record. The department keeps the decision.

Can an agent order machinery spare parts on its own?

It can prepare the proposal. The order should not be sent until a person has confirmed the quantity, supplier, and code. The data it works with is what is already in the management system: stock, threshold, withdrawals, intervention notes. It does not read the machine and does not guess a breakdown that nobody has recorded. For sensitive actions, confirmation remains in place. Autonomy can increase only after the department has observed the notifications and corrected the cases where the code, quantity, or supplier did not add up. Until that verification has taken place, the agent notifies and a person decides. An automatic submission, without that check, risks a duplicate order or the wrong part.

Where do you start if everything currently lives in spreadsheets and messages?

You choose a small group of machines and the spare parts the department has already had to search for in an emergency. You copy the codes from labels and PDFs, count the shelf contents once, and write the threshold together with maintenance and purchasing. Then you test the real cycle: withdrawal, balance, proposal, confirmation, goods received. If the proposal does not match what the person would have ordered, you correct the missing field before expanding the scope. Loading the manufacturer's entire catalogue on the first day produces a full archive and a reorder process that is still blind. The small slice is judged in the field, without stopping the shift for a complete data load.

Is this management system industrial automation?

No. Industrial automation concerns machines, equipment, and factory robots. The spare parts management described here is a process carried out at a computer: codes, stock levels, notes, a message to the supplier. A program can connect those steps and remove the manual rewriting between maintenance, warehousing, and purchasing. It does not replace the person intervening on the line and does not connect to the equipment to detect a breakdown on its own. If the data has not been entered by someone, the software does not invent it. Sensors and connections to machinery remain outside this scope.

This post was produced with AI