Production management software: you are planning on cycle times nobody ever measured

The flange order looked like the best job of the year: two thousand parts, a customer who pays on time, a price built on the cycle time the management system had carried for six years, four minutes per part. The final figures said six and a half minutes, because the cycle left out the two setups, the first part inspection and the tool change. The owner, forty five people in the province of Vicenza, found out once the batch was finished that the best job of the year had broken even, and that the last thirty quotes had been built on that same cycle. It is the problem production management software is supposed to solve, and it almost never solves it on its own.

If you recognise the scene, this article gives you the real cost of producing on numbers that are not yours, the single number that decides whether a system like this will actually help you or become one more terminal operators avoid, the three different things vendors all sell under the name MES, how data leaves the shop floor without stopping the shop floor, the real price ranges between a product, the module of the management system you already own and a custom system, and the threshold in euro beyond which the arithmetic changes.

I have been writing software since 1999 and I have seen shop floors from the inside in very different companies: contract machine shops with twelve machining centres and three hundred active part numbers, plastic moulders who live and die by setups, fabrication shops that work to drawing and never make the same part twice, food companies where batch traceability is a legal obligation. I also built and sold a professional software product used by many different companies, so turning what happens outside the office into a number is a problem I have had to solve, not just describe.

What I have learned, and no vendor says during a demonstration, is this: in a manufacturing SME the number that matters is not how many parts you make, it is how far the cycle time recorded in your management system is from the real one, setup included. If that gap is large, everything you build on top of it, finite capacity planning, the colourful Gantt chart, product costing, does not solve the problem: it makes a false number precise.

What production management software is, and what it is not

Production management software is the system that knows four things your management system does not know on its own: what every machine is doing right now, how much time every operation of every batch really took, what needs doing tomorrow and in what order, and which materials and which batches ended up inside every part shipped. It answers a single question, every day: are we producing the way we thought, and if not, will we notice in time to move something.

On the market it goes by many names, and the confusion suits the people selling it. MES, meaning manufacturing execution system, production software, the production module of the ERP, advanced planning, scheduling software, production data collection, machine monitoring, Industry 4.0 platform. These overlap only in part. Knowing which one you need is half the negotiation already, because prices differ by an order of magnitude.

The difference between saying what to do and knowing what happened

The management system you already have almost certainly knows what to do. It has the bills of materials, it has the routings, it releases production orders and computes material requirements. That is a lot, and it is why so many companies get this far and stop. What it does not know is what happened after the order was printed and carried to the shop floor. For the management system a production order is open or closed: in between there is darkness.

That darkness is where the questions live that the owner asks the shop floor supervisor every morning. How far along is the German customer order. Why is machining centre three stopped. How many good parts came off the press yesterday. Can we ship on Friday. What did the last batch of that part really cost us. The supervisor usually answers well, because he is good at the job. The problem is that the answer lives in his head, and a head does not add up, does not compare against the quote and goes on holiday in August.

This is not a flaw in the management system. The management system records intentions, while running a shop floor means deciding on facts, and the difference is all about time. A cycle that is twenty per cent wrong, if you find out at the first batch, gets corrected in the next quote and perhaps renegotiated. If you find out after six years, you have produced thirty wrong quotes and you do not know which ones.

The three families of companies looking for it, and looking for different things

Make to order and engineer to order. Fabrication shops, machine builders, contract machine shops with small batches and changing part numbers. Here the problem is the cost of each order and the delivery date, because every job differs from the last and one person prices it from memory. The value lies in costing by order and in capacity planning. Vendors talk to them about machine efficiency, and miss the target.

Repetitive batch production. Moulding, bar turning, series machining for automotive or appliances. Here the problem is machine yield and setup cost: the same parts come back every month, and every lost minute multiplies across thousands of pieces. The value lies in machine monitoring, OEE and order sequencing.

Companies with a traceability obligation. Food, pharmaceuticals, medical devices, certified automotive suppliers. Here data is not only for working, it is for proving: which raw material batch went into which product batch, who processed it, with what parameters. The cost of not having it is a recall you cannot narrow down, and which therefore has to cover everything.

The three families buy products with the same name and use different parts of them. Before you watch any demonstration, decide which family you are in, because it is the only thing that makes two quotes comparable.

The real bill: what producing on numbers that are not yours costs you today

This is the calculation almost nobody does, because none of these items has a line in the accounts: they are margin that never formed and capacity you do not know you have. My reference is a contract machine shop turning over eight million euro, forty five people of whom thirty on the shop floor, twelve machines between machining centres, lathes and an assembly line. It is a very common size among the people who write to me.

Orders priced on wrong cycle times

This is the largest item and the least visible. Suppose a third of revenue, about two and a half million, runs through part numbers whose cycle is underestimated by twenty per cent, because it was written for the part and not the batch, or when the machine was new and the operator was someone else. If machine and labour weigh thirty five per cent of the price, twenty per cent less on that thirty five is seven per cent of the price. Seven per cent of two and a half million is about one hundred and seventy thousand euro a year of margin you think you make and do not.

The damage does not end there. If some cycles are underestimated, others are almost always overestimated, and on those parts you quote high and lose tenders without knowing why. The result is an order book that drifts towards the jobs where you lose money, because those are the ones where you look most competitive. It is the most efficient way I know to grow revenue and shrink profit with a clear conscience.

Setups nobody manages

On a shop floor without planning, the supervisor decides the order sequence in the morning, looking at the urgent jobs. That is reasonable and expensive, because the sequence that respects urgency is rarely the one that reduces changeovers. One extra setup a day on twelve machines, at three quarters of an hour each, adds up to almost two thousand hours of capacity a year. Not all of it is money, because a machine that is not saturated costs nothing extra standing still. It becomes money when you pay Saturdays to recover it or send a job to a subcontractor: between twenty and sixty thousand euro a year in a company that size.

Stoppages nobody records

Here the arithmetic is different, because the loss does not arrive every year but all at once. In SMEs that never measured it, overall equipment effectiveness, the figure called OEE that multiplies availability, speed and quality, usually sits between forty and sixty per cent. The owner usually estimates it at around eighty. The difference between the two is capacity that exists and cannot be seen: micro stoppages, waiting for material, an operator running two machines, quality control arriving half an hour late.

That invisible capacity turns into money the day the shop floor looks saturated and the company decides to buy a new machine. Three hundred thousand euro of machining centre depreciated over seven years is about forty five thousand euro a year, spent to solve a problem that perhaps could have been solved by looking at where the existing machines were standing idle. I am not saying the new machine is always wrong. I am saying that without stoppage data you cannot know whether it is.

Late deliveries

Late delivery costs in four ways: Saturdays paid to catch up, express transport, penalties when the customer wrote them into the contract, and the highest cost of all, which nobody measures, the customer who next time asks another supplier for a quote too. The first three usually sit between fifteen and forty thousand euro a year. The fourth you discover when that customer buys less and nobody can say why.

Planning rebuilt by hand

The supervisor spends two hours every evening on a spreadsheet deciding the next day. Someone from the office walks to the shop floor three times a day to ask where an order stands, because a customer has phoned. That is between four and six hundred hours a year, between twelve and twenty thousand euro, done by your most valuable people in the most demoralising way there is: rebuilding instead of deciding.

The total, for an eight million euro company, sits between eighty and three hundred and thirty thousand euro a year, and no company takes all five items at their maximum. The range is wide because the real variable is not size: it is how varied your mix is. A shop that always makes the same ten parts sits at the bottom, a shop working three hundred parts in small batches sits at the top. Before reading on, do the sum with your own numbers, even roughly, on a single sheet. If your total is below thirty thousand euro a year, software is not your most urgent problem, and further down I tell you what is.

The cycle time gap: the number that decides whether the project makes sense

If I had to keep a single number from this whole article, it would be this one: how far, in the median, the cycle time recorded in the management system is from the time production really takes, setup included. I call it the cycle time gap. It decides everything, because every function of production management software, from quoting to planning to product costing, multiplies that number by something else.

How to measure it in one day

Take the ten part numbers with the highest revenue over the last twelve months. For each one, find two numbers. The first is the cycle time recorded in the management system, adding up the operations, in minutes per part. The second is the real time of the last three batches: actual machine hours and labour hours, setups included, divided by good parts. If you already have production declarations, you will find it there. If you do not, you will find it in the shop floor job sheets. If you do not even have those, time the next batch of each part with a stopwatch, from the first setup to the last good part. The difference between the two numbers, divided by the recorded time, is the gap for that part. The median of the ten is your number.

If declarations are already in a database, the measurement is a query. This is the form I use on SQL Server. The table names in your system will differ, the substance will not:

-- Gap between recorded cycle time and real time, on the ten highest revenue parts
WITH Revenue AS (
    SELECT TOP (10) PartNumber, SUM(Amount) AS Total
    FROM InvoiceLines
    WHERE InvoiceDate BETWEEN DATEADD(MONTH, -12, GETDATE()) AND GETDATE()
    GROUP BY PartNumber
    ORDER BY SUM(Amount) DESC
),
Actual AS (
    SELECT PartNumber,
           SUM(RunMinutes + SetupMinutes) * 1.0
             / NULLIF(SUM(GoodParts), 0) AS RealMinutesPerPart
    FROM OperationDeclarations
    WHERE EndDate BETWEEN DATEADD(MONTH, -6, GETDATE()) AND GETDATE()
    GROUP BY PartNumber
)
SELECT r.PartNumber,
       c.CycleMinutesPerPart,
       a.RealMinutesPerPart,
       (a.RealMinutesPerPart - c.CycleMinutesPerPart) * 100.0
         / c.CycleMinutesPerPart AS GapPercent
FROM Revenue AS r
JOIN StandardCycles AS c ON c.PartNumber = r.PartNumber
LEFT JOIN Actual AS a ON a.PartNumber = r.PartNumber
ORDER BY GapPercent DESC;

The line that matters is the division by good parts. A one hour setup on a batch of fifty parts adds one minute and twelve seconds to every part, while on a batch of five thousand it adds almost nothing. That is why cycles written for the part are right on large batches and wrong on all the others, and batches have been shrinking for twenty years. Parts that come out with an empty gap are the ones with no declarations, and that is information already.

Three clarifications, because the measurement is easy to distort without meaning to. Count good parts, not parts produced: scrap is time spent and not sold. Do not exclude batches that went badly because they look like the exception: if one batch in three goes badly, the exception is the rule. And do not choose the parts yourself because you know they are in order: revenue chooses the ten parts.

In SMEs that never measured it, the result almost always lands between twenty and forty per cent. The gap is not random: it nearly all goes in the same direction, because real time is longer than recorded time. The reason is always the same. Engineering wrote the cycle looking at the drawing and the machine program, meaning the time the chips are flying. Everything that happens before and after is missing from the cycle: setting up, measuring the first part, waiting for the trolley, changing the insert.

The four thresholds, and what you can do at each

Below ten per cent: you have the numbers. You are in a minority, and your problem is not measurement but sequence. Here a planning system pays for itself quickly, because reordering jobs by setup family on reliable times produces real capacity. You can skip much of what follows and go straight to choosing a product.

From ten to twenty five per cent: right on average, wrong on the single part. The quote holds on the yearly total and loses on new parts, small batches and rush jobs, exactly where margins should be highest. What you need here is costing by part, not planning. Once real times flow back into the cycle, the gap falls on its own within a few months.

Above twenty five per cent: fantasy prices. You are selling on invented numbers, and every advanced function built on top is money spent in advance for a result that will not arrive. The sequence is forced: measure first, then correct the cycles, then plan. Anyone proposing to start from scheduling is selling you the part with the lowest return.

No cycle at all: you do not know. This is the normal situation for anyone working to drawing, where the estimator guesses the time from memory. The first job is not buying software, it is writing cycles for the parts that repeat, usually the twenty per cent of part numbers that absorb eighty per cent of the hours. A spreadsheet and three weeks are enough.

The practical rule is only one: before buying software that tells you what to do, buy a way of knowing what happened, because a plan built on times that are thirty per cent wrong is precise and false. If your gap is large, you do not have a planning problem. You have a measurement problem, it is cheap to fix, and without fixing it nothing else works.

How data leaves the shop floor without stopping the shop floor

Data leaves the shop floor in three ways: the operator declares it, the machine sends it, or both together. This is where a project lives or dies, and where almost nobody looks during selection, because demonstrations show dashboards. Dashboards are the easy part, the consequence of data that arrives. If data does not arrive, the dashboard is an empty screen nobody opens after three months.

Operator declaration, connected machine, or both

Operator declaration is the oldest method and the one that works everywhere. A terminal or tablet at the machine, between three and eight hundred euro of hardware per station, where the operator declares start and end of an operation, good parts, scrap and the reason for a stop. It is cheap and it tells you why things happen. On when, it is imprecise, because the operator declares when he remembers.

The connected machine is the precise method. Recent CNC controls expose status and part counters through standard protocols such as OPC UA or MTConnect, and connecting them costs little. Older machines need a small device reading the electrical signals, between five hundred and three thousand euro per machine depending on age. The machine knows exactly when it is stopped. It does not know why.

The hybrid method is the one that almost always wins: the machine says when, the operator says why. When the machine stops for more than a few minutes, the terminal asks for the reason and the operator picks from a short list. It is the only way to get both the precision of time and the explanation of the stop, which are the two halves of OEE that matter for decisions.

The six conditions that make collection workable

Declaring takes ten seconds, at the machine. If the terminal sits at the far end of the floor, near the office, the operator declares when he walks past it, meaning at the end of the shift, all at once and from memory. The data looks good and is reconstructed, which is worse than missing data because you make decisions with it.

The code on the work order is scanned. Order, operation and part number are not typed: a barcode or QR code printed on the work order is read. Every field typed by hand on the shop floor is an error waiting to happen.

Eight stop reasons, not forty. Breakdown, waiting for material, waiting for operator, setup, quality check, planned maintenance, no orders, other. With forty options "other" always wins, and stoppage analysis turns into a chart with a single bar.

The machine says when, the operator says why. Connecting a hundred parameters per machine is a frequent mistake: the money goes on the connection and nobody looks at the data. Status and part counter are enough for the first year.

Good parts and scrap are declared at each operation change. If scrap is counted at month end in the warehouse, you no longer know which batch and which machine produced it, and the data cannot correct anything.

The operator gets something back. If the terminal shows his own time against the cycle and the next jobs in the queue, he looks after the data because it is his too. If the system is only a control tool, after a month it becomes a chore and quality collapses.

The test worth more than three demonstrations

Before signing, take the most senior operator on the floor, not the youngest and keenest. Put the terminal of the product under evaluation in front of him and ask him, wearing gloves and with a stopwatch running, to declare the start of an operation, a stop for waiting on material and the end with three scrapped parts. Then ask him to correct a wrong declaration. If the first operation takes more than fifteen seconds, or the correction is impossible without calling the office, that product will not make it onto your shop floor.

The machines you have already paid to connect

There is a detail worth money. Many Italian SMEs bought machines in recent years with Industry 4.0 incentives, and one of the requirements was interconnection with the factory information systems. Often that machine is interconnected on paper and nobody reads its data. You have already paid for that data, and it is the cheapest starting point you have. On what a configuration change means for the incentive, the final word belongs to your assessor and your accountant. The technical side, meaning how machines, SCADA and MES talk to each other with .NET and OPC UA, I described in this guide to SCADA and MES integration.

MES, planning and requirements: three different things with the same name

MES, planning and material requirements are three distinct disciplines that quotes lump under one heading, with three different prices and three different returns. Having one does not mean having the others. And the order in which you buy them decides whether they work, because each one runs on the numbers the previous one produces.

Execution and costing: the MES in the strict sense

The MES captures what happens on the shop floor: operation declarations, good parts and scrap, machine status, stoppages with their reason, real times against cycle times, and in many industries batch genealogy. In the ISA-95 classification it sits halfway between the machines and the ERP, and it is exactly the piece missing from the darkness I described earlier. It is the function to start with, always, because it is the only one that produces real numbers. What it does not do: tell you what to do tomorrow.

Planning and scheduling: what to do, and in what order

Finite capacity planning, which vendors call APS, takes open orders, the capacity of each machine and the cycle times, and proposes a sequence that meets delivery dates and reduces setups. When it works it is the function with the most visible return, because it turns hidden capacity into real capacity and gives you delivery dates you can promise. It needs one thing many companies lack, though: reliable cycle times. On times that are thirty per cent wrong it produces a beautiful Gantt chart the shop floor ignores from day two, and rightly so.

Bills of materials, routings and requirements: what you already have

Bills of materials, routings, material requirements calculation and the release of production and purchase orders almost always sit in the management system you already own, in the module called MRP. The problem is rarely that it is missing. The problem is that the routings inside the MRP were written years ago and nobody updates them, because nobody has the real times to update them with. Buying a second MRP to solve this is money wasted: what you need is the MES that feeds it real numbers.

Traceability, when it is an obligation and not a choice

In some industries the MES is not an optimisation, it is how you meet an obligation. In food, article 18 of European regulation 178 of 2002 requires you to know who supplied every raw material and to whom you delivered every product. In medical devices, European regulation 745 of 2017 introduced unique device identification. In automotive, customers certified to IATF 16949 require batch traceability from suppliers as a contractual requirement. I am not a compliance consultant, and the final word on these obligations belongs to yours. What I can tell you is that manual traceability holds until the first recall. At that point the difference between recalling one batch and recalling three months of production lies entirely in the system.

The buying order is therefore almost always the same: execution first, then planning, while requirements you usually have already. Almost everyone does the opposite, because planning is the part that looks best in a demonstration.

How much production management software costs: product, module or custom

There are three routes with three different economics. The figures below are the ranges I see in Italy for companies turning over between two and thirty million euro. They show the order of magnitude and do not replace a quote.

The production module of the system you already own

This is the route to evaluate first, and the vendor of your management system is the first phone call to make. Many Italian management systems have a production module, and if bills of materials and routings are already there, enabling it costs between eight and forty thousand euro in licence and setup, or a subscription. The advantage is that cost does not enter the system twice. The limit is almost always shop floor collection, which in these modules is often a screen designed for the office: run the senior operator test on it before signing.

The specialised subscription product

It costs between forty and one hundred and fifty euro per machine or station per month, depending on how many functions you enable. Setup, meaning machine connection, configuration, master data and training, runs between fifteen and sixty thousand euro, and the heaviest item is connecting old machines. For twelve machines and twenty stations the first year usually lands between forty and eighty thousand euro. It is the right route for most SMEs below twenty million, and I say so even though my interest lies in saying the opposite. The advantage is not the price: someone has already solved the problems of your industry and you inherit the solutions.

The custom system

It starts at thirty five to seventy thousand euro for the core: declarations at the machine, machine status, costing by order and by part, integration with the management system. It rises to one hundred and eighty thousand with finite capacity planning and batch traceability. Annual maintenance runs between fifteen and twenty per cent of what you spent, and it belongs in the budget from day one. It makes sense in three cases. When the way you produce is your competitive advantage and you do not want to bend it to a product. When machines are many and varied, and no product connects them all without customisation that costs more than the subscription. When the management system you have works, perhaps twenty years old and nobody wants to touch it, and the problem is building around it rather than replacing it. That last case is the one I see most often, and it is where a custom system costs less than people expect.

The threshold, in euro

The practical rule I use is this: below thirty thousand euro a year of expected total spend, subscriptions and customisations included, the product or the ERP module almost always wins. Above that, the sum needs redoing, because at that level five years of subscription reach the cost of building and the difference is all maintenance, which you pay either way. In the chart the break-even point falls around year four. At that point a variable that is not economic matters: how much your company will change in five years. If you expect to double your machines or enter an industry with traceability obligations, the flexibility of a system of your own is worth the premium. If your way of producing has been stable for ten years, the product is the rational choice. The full reasoning on when building beats buying, on numbers, is in custom software development.

Integration with the management system: who owns the bill, the routing and the order

Production management software lives between the management system and the machines, and the question that never appears in quotes is who owns each piece of data. The cost of a batch is born in three different places. The order is born in the management system, time is born on the shop floor, consumed material is born in the warehouse. If you do not decide beforehand who owns each one, you will have three different numbers for the same batch and spend meetings arguing about which is right instead of what to do.

The three decisions to make before signing

Where the production order is born. Almost always in the management system, which knows the customer, the bill of materials and the requirement. The MES receives it and does not create it. There must be one single place where the order is born and where it closes: an order closed on the floor but open in the management system produces phantom requirements, and the opposite produces parts nobody knows they have.

Who updates the routings. This is the most valuable decision, because it is what makes the cycle time gap fall. The system collects real times, proposes an update when the gap on a part crosses a threshold, and engineering approves. Automatic updates without approval are a mistake: one bad batch rewrites the cycle, and the next quote becomes expensive for no reason. Ask the vendor how this loop works, because many products collect real times and then leave them in a report nobody reads.

Where the actuals go back, and when. Time and scrap must flow back into the cost of the order, and consumed material must be issued from stock. You can issue as consumed, operation by operation, or at the end of the batch. As consumed, stock is always right but it takes discipline on the floor; at batch end it is simpler but for a few days stock is wrong. Decide beforehand, because it changes the work of the people on the floor. The warehouse is the half of the problem many overlook, and I covered it in warehouse management software.

How to ask a vendor

Do not ask whether the product integrates with your management system, because the answer is always yes. Ask three concrete things. Which data flows in which direction and how often, for instance whether orders arrive every minute or once a day. What happens when an order is changed in the management system while it is already in production. And who pays if next year the management system vendor ships a new version and the exchange format breaks. The answers to these three questions, written into the contract, are worth more than twenty pages of features.

If the management system is old, written years ago in Visual Basic, in Access or on a server nobody dares switch off, the temptation is to replace everything. It is almost always wrong, because you risk stopping accounting to fix production. You build an exchange layer, well defined tables or interfaces, and the old system keeps doing its job until the right moment comes to replace it.

How to choose production management software in three weeks

Production management software can be chosen well in three weeks: one on your numbers, one on demonstrations, one testing on the shop floor. A long selection does not produce better choices, it produces more defensible ones. This is the method I use with clients, made of real work and not of waiting.

Week one: your numbers

Measure the cycle time gap on the ten parts, as described above: one day. Cost out the five loss items with your own figures, even roughly: half a day. Then follow a real work order from the customer order to shipment, and write on a single page who touches it, where it stops and how many times someone copies a figure by hand. It is usually the document that opens the most eyes, because two steps turn up that nobody knew existed.

Then choose your five scenarios. Not features: scenarios. For example: the operator declares an operation with three scrapped parts and a stop waiting for material; the machine stops and the system asks for the reason; the owner sees on Monday morning the ten parts with real time against the cycle; an urgent order arrives and the system says which deliveries slip; a customer asks which products a raw material batch went into. Five, not twenty.

Week two: demonstrations, done properly

Ask two or three vendors to show you those five scenarios, in the order you decide and with data that resembles yours. Do not let the salesperson drive the demonstration, because the script is built on the strengths of the product. The most informative moment is when you ask for something off script and watch the reaction. Someone who knows the product tells you straight away that it cannot be done and how to work around it. Someone who does not promises, and then files a development request.

The questions to ask everyone are always the same, so you can compare them. What the third year costs in total, with the machines and people you will have in three years. What connecting your two oldest machines costs, with make and model. What happens if you stop after two years, in what format your data comes out and what that extraction costs. Who runs the implementation, someone who knows your industry or a generic technician. And whether you can speak to two companies like yours without the salesperson present.

Week three: the shop floor test

One machine, one shift, one real operator, with the product that came first. Not a demo in the meeting room, but the senior operator test done seriously, plus a day of real declarations compared in the evening with what the supervisor knows. If the two numbers match in the evening, you have found your product. If they do not, you have discovered where the problem lies before paying for it.

The three things to fix before buying anything

There are three jobs that cost little, take a few weeks and without which any production management software delivers half its value: separating setup in the routings, cutting down the stop reasons, deciding who declares and why. They come first, not later, because later the project has started and nobody goes back.

Routings with setup kept separate. Every operation of the main parts needs two distinct times: setup time, paid once per batch, and time per part. Without this split no system can compute the cost of a small batch, and no planning can see that grouping two orders saves an hour. It is a job for engineering together with the shop floor supervisor, on the twenty parts that absorb the most hours: one week, and it is worth more than half the software.

The stop reasons. Eight options, decided together with the shop floor, written in words operators actually use. Choose them by looking at where you think time is lost, because those are the items you want numbers on. A reason nobody picks after a month gets removed, and an "other" picked too often means one is missing.

The decision on who declares, and why. Production data exists to run the shop floor, not to monitor people, and that needs saying clearly before starting. There is a legal side too. In Italy, article 4 of the Workers Statute regulates tools that can result in remote monitoring of employee activity. A system recording who worked on which machine and for how long can fall under that rule, which in some cases requires a union agreement or an authorisation from the labour inspectorate. I am not an employment adviser: talk to yours before buying, not after, because it changes how the system is designed and not only what gets signed.

I will add a way of starting that is a choice rather than a job: one pilot cell, just one, with two or three machines and a shift leader who does not hate you. Run everything there for six weeks before extending. Companies that start on the whole floor at once end up back on paper work orders at the first difficult month. The second attempt is much harder, because by then everyone in the company knows the thing did not work.

If your total for the five items was below thirty thousand euro a year, here is your most urgent problem: these three jobs, not the software. Do them, repeat the measurement after three months, and only then look at products.

Where to start

You start from a small first release, because a production management system is not an IT project: it is a data collection project, and data collection projects succeed when they ask little of the people on the shop floor. The first release that works is almost always this. Work orders with a readable code. Declaration of start, end, good parts and scrap for every operation. Status of the three or four busiest machines. A single report that on Monday morning shows the twenty main parts with real time against the cycle and the stoppages of the week broken down by reason. Nothing else.

With that scope you are running within a few weeks with a product, in two or three months if you build custom. From then on you can repeat the cycle time gap measurement every month on the same ten parts. If it falls, the project is working. If it does not, the problem lies in collection or in the routing update loop, and no extra feature will fix it. Everything else, finite capacity planning, full traceability, connecting every machine, gets built on data you can trust. It costs less, because by then you know what you really need.

In the end, the flange owner bought nothing for the first two months. He had the ten parts measured, found that six had cycles underestimated by more than twenty five per cent, and repriced three customers before choosing any product. The software came later, and it worked because it had real numbers to run on.

If you are doing this sum right now and want to know which side of the threshold you are on before spending anything, send me two pages: the path of one of your work orders from customer order to shipment, plus the two numbers from the test, the cycle time gap on ten parts and the total of the five items. In half an hour I will tell you whether yours is a product problem, a problem for the module of the system you already own, or a custom one. When it is an organisational problem I will tell you that too, because a client who buys the wrong thing comes back angry. You can ask for a consultation to do that sum together, or see how we approach legacy software modernization.

If you are still framing the problem, two readings sit around this one. Cost control when you work to order, which is the same problem seen from the office rather than the floor, is in job costing software. Breakdowns and machine maintenance, which are half of OEE, are in maintenance management software.