The spreadsheet that became a system

This article follows What 68 sawmills told us about their data. That one was the diagnosis; this one is what I did with it. It contains no code and no data from any plant: it describes a method and a specification. The full documentation — method, system concept and diagrams — lives in the case-study repository.

A problem I had already seen solved

Before moving into technology transfer I spent four years at CMPC Maderas, the sawmilling business of one of Latin America's largest forestry companies, first as shift supervisor and then as process engineer. There, dimensional control was routine: you measured, you logged, and you adjusted the machine when variation went out of range. In 2017 I moved to a technology-extension project run jointly by the Chilean Forest Institute (INFOR) and the Manufacturing Technology Extension Centre of Universidad de Concepción (CETMA): hired by INFOR, based at CETMA. We started visiting small sawmills, and what struck me was not that they measured badly. They measured, sometimes well, and the reading was useless because it arrived late and without context.

The problem had two halves. One of method: what to measure, where, against which tolerance. One of flow: how to get the reading into the record without passing through paper, with the information that makes it useful. I started with the first.

The method, in a spreadsheet

We were a team of four on that project. In November 2017 I built an Excel workbook with macros to test the method with the plants; I refined it with the observations of colleagues and production managers, and maintained it myself through the following stages, at CETMA and at INFOR. It was not a product; it was a prototype to argue with production managers over real numbers. What it fixed:

• Four control points per piece, two at each end no more than 5 mm from the edge, and at each point thickness on both faces (upper/right and lower/left) plus width. The measuring order was fixed, so that two inspectors produced comparable records.
• Nominal versus target. The nominal size is what the product is sold as; the target is what the sawmill must actually cut so that, after drying shrinkage and planing, the piece ends up within tolerance. The workbook derived the target from the nominal according to the piece's destination (green lumber, green or dry finished product) and compared every reading against the target, not the nominal. An obvious distinction for anyone who has run a sawmill, and surprisingly absent from the records I was finding.
• Context on every record: cutting machine, line, cut number, product, market, surface grade, destination process, inspector, date. Without it a standard deviation is a number; with it, it is a specific machine that needs adjusting.
• The outputs a plant manager cares about: standard deviation per machine and per cut (the control chart proper), a histogram of deviation against the tolerance band, "hit rate" — the share of readings under, within and over size per control point — and a box plot per machine. Four views, none decorative.

The VBA macros did nothing sophisticated: they appended each control to the record base, cleared the form and, with advanced filters over a named range, copied each machine-and-cut subset into the worksheet of each chart; the calculation logic lived in the formulas. It was a data pipeline written in Excel, and that is the part I find most telling today: the value was not in the tool, but in having defined what gets recorded, what gets derived and what gets shown.

From workbook to specification

With the method proven, the bottleneck was the flow again: someone still wrote by hand and typed later. When that project ended I stayed on at CETMA, and in December 2018 I wrote the concept of the system that should replace the workbook, in three steps:

1. Capture. A digital caliper with a data output, connected to an Android phone. The reading reaches the phone without anyone writing it down.
2. Attributes. The mobile app asks for the context — machine, cut, product, market, inspector — once per batch and attaches it to every reading. The inspector only measures.
3. Analysis. Records go up to a web platform that computes what the workbook computed: standard deviation per machine with severity alerts, histograms against the tolerances of Chilean standard NCh 2824, under- and over-size per control point, box plots. Plus a second module for grade classification, with a Pareto of rejection causes.

That concept was the technical basis on which the centre formulated a CORFO Technology Diffusion Project, awarded to Universidad de Concepción in 2019 and run from 2020 with CORMA. With the project awarded, in 2019 I returned to INFOR and took no part in its execution.

The decision that determines whether it reaches a small company

At INFOR the sector diagnosis — the 2019 report from the previous article — confirmed with data what the workbook had shown in a handful of plants: 79 % of the sawmills that controlled dimensions did it on paper, and 43 % wanted to adopt technology for more efficient quality control. The same concept then served to specify the dimensional-control module that INFOR implemented with an external developer. I coordinated the hiring and the initial stage of the development, and the workbook's calculation logic — the formulas and the macros — was ported into the system: the module did not take inspiration from the tables, it inherited the method and a good part of its implementation.

And there a choice had to be made. Integrated solutions existed, hardware and software from a single vendor, technically sound and priced beyond the reach of a 20,000 m³/year sawmill. The alternative was to separate the two: standard, open-connection, low-cost Bluetooth calipers — the plant's only investment — and a free application with all the logic in the software. It is an architecture decision disguised as a purchasing one: put the intelligence in the part that can be updated and distributed for free, and leave the instrument as an interchangeable peripheral.

INFOR owns that family of applications for small sawmills and maintains it today at controlmaderainfor.cl. I do not speak for its later evolution or its code, which is not mine; I do for the method and the starting specification, which are the work described here.

What still holds

• Prototype the method before the system. The workbook took weeks and allowed arguing over real numbers; a system would have taken a year and argued over assumptions.
• Context is captured once, not with every reading. That is the difference between a record someone fills in and one nobody does.
• Open hardware, intelligence in the software. I would do it the same way with any shop-floor capture system, and it is exactly what I do today with cameras, drones and inference queues: the sensor is replaceable; the data flow is the design.

And one more thing, personal

The workbook is only the anecdote. What actually changed my path was the environment: two years of technology-extension work visiting dozens of small companies, watching the same gaps repeat — data on paper, software that did not help, decisions without information — and finding that the tools I had were not enough to solve them. I did not program then in today's sense: I automated with Excel — formulas, advanced filters, named ranges and VBA macros that saved each control and refreshed the charts — and the workbook is precisely the point where that tool runs out. That is where the change started: I learned Python during my master's thesis and, since then, I have built the systems those plants were missing. What I do today with data, computer vision and systems integration has that origin.