- \n
- Map the process, then measure the hours at each machine.<\/li>\n
- Changeovers, short stops and waiting call for different projects.<\/li>\n
- Pick the automation pilot on the loss that really dominates.<\/li>\n
- Measure before and after with the same rules and instrument.<\/li>\n<\/ul>\n<\/div>\n
Understand the current cell before automating it<\/h2>\n
Maryland MEP, the Manufacturing Extension Partnership center that supports manufacturers across Maryland, published Automating Small Batch Production: Process Innovation Strategies for Maryland’s Specialty Manufacturers<\/a>. The article describes the pressures specialty manufacturers face, the technologies that suit low volumes (collaborative robots, flexible manufacturing systems, smart sensors and analytics) and a set of practical steps. The first of those steps is process mapping, introduced with a clear principle: “You must fully understand your current operations before you can automate them.”<\/p><\/blockquote>\n
The article then recommends starting with a single pilot, such as automated material handling, proving the return, and training the existing workforce to program and maintain the new equipment. It also points to the cost of switching between custom products and to the downtime that changeovers create. This article does not repeat that method. It adds one practical layer to the mapping step: a measured time baseline at the machine, so that the pilot is chosen on the loss that really dominates, and its result can be checked afterwards on the same basis.<\/p>\n
Why a process map is not enough on its own<\/h2>\n
A process map shows the sequence of steps, the handoffs and the queues. It rarely shows how many hours of a shift each machine spends cutting, waiting or being set up. In small-batch production, that distribution is precisely what decides whether automation will pay off, and it is where perception and reality diverge most.<\/p>\n
- \n
- Changeovers are underestimated.<\/strong> Teams usually remember the standard setup time, not the full window from the last good part to the first good part of the next batch, including program loading, first-part checks and adjustments.<\/li>\n
- Short stops are invisible.<\/strong> A machine that pauses for 20 seconds to clear chips, wait for a part or reset a door interlock never appears in a manual log. Repeated dozens of times a shift, these stops can weigh as much as one long breakdown.<\/li>\n
- Waiting is spread across causes.<\/strong> Waiting for material, for an operator who runs two machines, for a program, a fixture or a quality release is often recorded as “idle” or not recorded at all.<\/li>\n
- Averages hide the mix.<\/strong> In a high-mix cell, one product family can carry most of the setup time while another runs almost unattended. A plant-level figure does not show this.<\/li>\n<\/ul>\n
Each of these losses calls for a different answer. A cobot that loads parts addresses waiting for an operator. Automated material handling addresses waiting for parts. Neither shortens a changeover that is mostly fixture adjustment and first-part approval, and neither removes short stops caused by chip evacuation or part presentation. That is why the hours need to be measured before the solution is chosen.<\/p>\n
![\"Four-step](\"https:\/\/teeptrak.com\/wp-content\/uploads\/2026\/11\/teeptrak-mdmep-en.png\")
<\/figure>\nA five-step time baseline on the current machines<\/h2>\n
- \n
- Pick the machines the project is meant to change.<\/strong> Usually the constraint of the cell, plus the machine that feeds it. Measuring a non-constraint machine can show a large gain that never reaches shipped output.<\/li>\n
- Define the time categories with the team.<\/strong> Running, planned changeover, unplanned stop, short stop, waiting (split by cause: material, operator, program or fixture, quality release), planned downtime. Write down where each category begins and ends, for example that a changeover runs from the last good part to the first good part.<\/li>\n
- Measure automatically over several weeks.<\/strong> Cover the full product mix and every shift. Two or three days often catch an unusual week, and a week without the longest setups gives a misleading picture.<\/li>\n
- Qualify the stops at the machine.<\/strong> Operators assign a reason to each stop when it happens, from a short list. The duration comes from the measurement; the cause comes from the people who saw it.<\/li>\n
- Convert the result into hours per week and per product family.<\/strong> Hours speak to the finance team and to the automation supplier better than percentages, and they make the expected gain of each option directly comparable.<\/li>\n<\/ol>\n
The output is a simple table: for each machine, how many hours per week go to each category, with the OEE that results. That table becomes the first page of the automation business case.<\/p>\n
Reading the baseline: which loss calls for which project<\/h2>\n
The table below links the dominant loss to the type of project it usually justifies. It is a reading guide, not a rule: the right answer still depends on the parts, the volumes and the team.<\/p>\n
- Define the time categories with the team.<\/strong> Running, planned changeover, unplanned stop, short stop, waiting (split by cause: material, operator, program or fixture, quality release), planned downtime. Write down where each category begins and ends, for example that a changeover runs from the last good part to the first good part.<\/li>\n
- Short stops are invisible.<\/strong> A machine that pauses for 20 seconds to clear chips, wait for a part or reset a door interlock never appears in a manual log. Repeated dozens of times a shift, these stops can weigh as much as one long breakdown.<\/li>\n
- Changeovers are underestimated.<\/strong> Teams usually remember the standard setup time, not the full window from the last good part to the first good part of the next batch, including program loading, first-part checks and adjustments.<\/li>\n