Last week I was talking to a factory owner about how he saw workflow automation. One of his concerns was that the scanning activity (which is part of a sound automation solution) might drive higher labor cost because of the scanning, tracking and control across each stage of production.
He had three questions:
- What’s the effort to do manual scanning?
- Can we pull reliable log data from machines?
- Other than tracking are there any other benefits?
- How do we know that it doesn’t cost more in scanning than the benefit
What’s the current situation?
Unfortunately most factories run invisible production. Between printing and shipping – work just gets done (theoretically flawlessly with zero performance and operational issues – yeah right….). Work disappears between these process stages – you only “see” jobs at intake and dispatch. Everything in between relies on assumption.
Visible production means you can locate any unit, know who/what touched it, and understand flow and yield in real time. The difference isn’t cosmetic; it’s operational resilience and margin.
Why scan at all?
We believe that it’s a foundation element of good factory practice and increasing profitability. Our view is that scanning underpins eight outcomes that matter:
- Where production is at – location and status by unit, job, or batch
- Who/what is doing the work – operator and machine attribution
- Where error creeps in – stage, cause, and frequency
- Resilience – recover quickly when something fails
- Expedite control – rush paths without losing the rest of the order
- Quality handling – fail, rework, and rejoin the order cleanly
- Continuous improvement – hard data on bottlenecks, throughput, and top-performing people/machines
- Flexibility – jobs can be diverted and redirected in live workflow
Collectively, these put margin back into the business and deliver operational agility.
Three ways to create scan events
There are 3 ways to capture data at each machine/process stages:
- Machine scan events. Talk directly to devices and pull logs. As work moves through a cutter, press, RIP, or collator, capture the item identity and a timestamp (and, where available, machine metrics). Reality check: device logs are uneven across vendors, so plan for normalisation and fallbacks.
- Hand scanning. Use laser scanners to scan the Batch, Job, or Item, depending on the level of control required. A batch-level scan can infer all contained items — extremely low effort with high coverage when configured correctly.
- Mounted “light-field” scanning. Fixed scanners read anything passing a beam. This can cover human tasks or machine outputs. As with hand scanning, choose Batch/Job/Item based on the decision you need to make at that point. I have written in the past that this technique is a great way of making “dumb” machines smart.
The important thing to note is that scanning itself can be constructed to be almost zero cost activity.
Finding the right balance
The right balance is to scan at every process stage, but vary the granularity and the method. Use item-level scans only where decisions or risk require it (quality gates, branching routes, ship). Elsewhere, batch or job-level scans keep the workload light while maintaining end-to-end visibility. Combine machine events where they’re trustworthy with human or mounted scans where they aren’t. Keep the rule simple: no work moves without a state change.
In my experience, you only achieve a highly resilient workflow when each stage produces scan data. That’s how you know where every unit sits, how fast it’s moving, and where profit is leaking — every hour of the day, across every shift.
We implement this method in our own platform, but the principle is vendor-agnostic. If you want examples of stage definitions and where to go batch vs job vs item, I’m happy to share.
