Sawmill Production Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the recovery definition get skipped in scoping?

Nearly every mill project we are asked to quote starts with a request for recovery reporting, and nearly every one assumes recovery is already defined. It is not. Ask three people at the same mill how it is calculated and you will get three answers that differ on whether green or dry volume is used, whether trim allowance is included, whether planer downgrade counts against recovery or against grade outturn, and whether chip and residual value enters the calculation at all.

None of those answers is wrong. They are simply not the same number, and a system that automates the current calculation without settling the definition produces a figure exactly as disputable as the one it replaced.

This is specific to sawmilling because the unit of measure changes identity along the line. Logs are scaled, green lumber is counted in nominal dimensions, kiln drying shrinks it, and the planer produces a tally in graded pieces. Comparing the last number to the first requires a chain of conversions, and each mill does them slightly differently.

The fix is to fix one volume model first and derive everything from it. Every measurement point converts into a canonical unit with an explicit, documented rule, and every reported figure states which basis it uses. It sounds administrative and it is the single highest value thing the project does, because every later analysis depends on it. Expect the first weeks of reporting to trigger arguments about definitions. That is the work happening, not the project failing.

What goes wrong when you bring historical production data across?

Mills want a year or two of history so the new reporting has something to compare against, and that is where the volume model gets tested for the first time. Historical data in a sawmill is not one dataset. It is optimiser shift summaries, green chain tallies, kiln charge sheets, planer grade tickets and a stack of scale tickets, produced by different systems and different people, none of which agreed on a basis.

The specific failures are predictable. Shift summaries carry a total that cannot be decomposed, so you can load the aggregate and never attribute it to a log class. Kiln records identify a charge but not its composition, so the history contains no path from planer grade back to the sawline. Load all of that without deciding what each figure means and you have built a database that reproduces the current confusion at higher resolution.

The fix is to accept a clean break rather than pretending the history is comparable. Convert what genuinely maps to the new volume model, mark everything else as legacy with its original basis recorded alongside, and be explicit that period-on-period comparisons cross a definition boundary. Mills that insist on restating three years of history usually spend more on the conversion than on the reporting, and the restated numbers still get argued about.

Why do optimiser and scanner integrations break after launch?

The richest data in the mill is inside the machines. Your primary breakdown optimiser knows the scanned geometry of every log, the solution it chose and the theoretical yield of that solution. The edger and trimmer know their own decisions. Getting that data out is real work, and keeping it flowing is a separate problem.

Vendors expose data differently and vintages differ within the same mill. Some installations expose a database that can be read, others provide a file drop, and older machines may need the vendor involved to open an interface at all. So the first breakage is that the integration is quoted as one item and is actually three or four unrelated pieces of work, one per machine centre. The second breakage arrives later: a machine gets a software update during a shutdown, the export schema changes or a field is renamed, and the acquisition layer either fails silently or starts recording a shifted value. Nobody notices for weeks because the numbers still look plausible.

The fix is an acquisition layer that validates structure as well as content, alarms on a shape change rather than tolerating it, and keeps the raw capture alongside the normalised event so a mapping can be corrected and the period reprocessed. The payoff is worth the discipline: comparing theoretical yield against actual green output tells you whether the sawline is achieving its own solutions, which is a maintenance and setup question rather than an optimisation question, and it is the most actionable number in the mill.

What happens when kiln charge composition and pack identity are not covered?

This is the gap where most sawmill data projects stop, and stopping here means the most valuable analysis in the mill never happens. A kiln charge is built from whatever packs are available, which routinely mixes production from several shifts and sometimes several days. After drying, the identity of what went in is largely gone. Any attempt to attribute planer grade outturn back to a log class or a shift then runs into a mixing problem nobody solved.

Grading is where the value of the board is actually decided. If you cannot connect the grader's decision back to the sawline and the log, you cannot improve either, and the grade outturn conversation stays unresolved indefinitely.

What works is tracking charge composition at pack level, so a charge is a known set of packs each with an origin shift and log class, and grade results at the planer are attributed proportionally back through the charge. That is an estimate rather than a certainty, and an honest estimate beats the current position of no answer at all. It normally requires pack level barcoding or tagging, and introducing that is a project on the floor as well as in the software. Budget for the tagging, insist on it for a few weeks until it becomes habit, and accept that the data quality you get afterwards is entirely determined by this decision.

Should you build custom or configure what you already own?

Keep buying optimisation from USNR, Autolog or BID Group Comact. Their scanning and solution software is the core competitive technology in your mill and no software house should be attempting to replace it. If your problem is that primary breakdown is making poor decisions, that is an equipment and setup conversation with your vendor, not a data one.

If you are a small custom mill cutting to order, do not build at all. At low throughput with short runs, a spreadsheet and a tidy scale ticket file give you an adequate recovery picture, and the money belongs in the saw or the kiln. We would tell you that before quoting.

The build case starts around tens of millions of board feet a year with a varied log supply, and it strengthens when two or more of these are true: recovery is compiled by hand and different people compute it differently, optimiser data never leaves the machine, planer grade outturn cannot be traced back through the kiln, log purchasing runs on price rather than realised value, or you operate more than one mill and cannot compare them because each defines its terms differently.

How do hidden costs get into the quote?

A first release covering the canonical volume model, acquisition from your primary breakdown and edger or trimmer optimisers, green output capture and recovery reporting by shift and log class runs $70,000 to $150,000 across 12 to 18 weeks in our delivery experience. The full platform adding kiln charge composition, planer grade attribution, log purchase reconciliation, downtime capture and finished goods inventory runs $180,000 to $420,000 phased over 6 to 14 months.

The costs that get missed are these. Machine centre count multiplied by vendor count, because each acquisition is its own piece of work and a mill with three vendors is not one integration. Pack level identification, since attributing grade outturn through kilns requires it and introducing barcoding carries hardware, labelling and training that sit outside the software line. Species and grade rule variety, because a mill running several species to different grading rules carries substantially more configuration than a single species mill. Whether log purchasing data sits in an accounting system with an interface or in a drawer of scale tickets. And multi site rollout, where scaling and grading conventions differ between mills in the same group.

What holds the number down is phasing. Start at the sawline and the green chain. Recovery from log to green output is achievable quickly and it pays for the kiln and planer work that follows.

What separates a build that works from one that fails here?

The builds that work settle the definition before they write the report, and they get a supervisor to care about the data on the floor. The builds that fail automate an undefined number and add a tablet nobody uses.

Downtime is the clearest test of that difference. Most mills record stop reasons on a clipboard. The version that works derives the duration automatically from machine state and production flow, and asks the supervisor only to classify the gap on a tablet at the line. Duration comes from the machines, cause comes from the person, and the resulting analysis is not arguable. That split is the general pattern for everything you capture from the floor: never ask a person for a number a machine already knows.

When you interview a developer, ask how they will define recovery. If they take your existing definition without asking which basis it uses, the system will produce a number as disputable as the current one. Ask how grade outturn will be attributed through a kiln charge that mixes shifts, and if the answer avoids the mixing problem, expect the build to stop at the green chain. Ask which optimiser and scanner systems they have read data from, by vendor and vintage,. Ask what they need from the floor, and be suspicious of anyone who says nothing. Then settle ownership in writing before kickoff. At Digital Heroes the client owns the repository and the infrastructure accounts from the first commit, and since the volume model encodes how your mill defines its own performance, owning it is the entire point.