NivaarExam PrepOfficial exam papers ↗

04-For-A1 Forest Engineering Operations · May 2014

Question 3 of 8: Does Improving One Machine Improve the Whole System?

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

EGBC National Exam — Forest Engineering, 04-For-A1 Forest Engineering Operations, May 2014. Open book; any non-communicating calculator permitted. 3 hours. Eight essay questions of equal value (20 marks each); the instructions call for any FIVE to be answered for a complete 100-mark paper.

Reference texts: Heinimann, Forest Operations Engineering (harvest-system classification, machine functions, systems productivity); FPInnovations/FERIC technical reports and the FERIC machine-rate (proforma) costing method (equipment cost analysis, time-and-motion productivity studies); Sessions (ed.), Forest Road Engineering Guidebook (forest transportation context); BC Ministry of Forests guidance and the BC Forest and Range Practices Act (Canadian regulatory and operational context).

Question 3: Does Improving One Machine Improve the Whole System? (20 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Not necessarily, and in general only if that machine is the system's bottleneck. A harvest system is a chain of machines connected in series (felling → extraction → processing → hauling), and the throughput of any series chain is governed by its slowest link, not by the average or the fastest link — the same systems-theory constraint (Theory of Constraints logic) that applies to any production line. Improving a machine that is not the bottleneck simply increases the size of the buffer (a growing pile of bunched trees, an idle machine waiting for wood) in front of the next, still-limiting machine; it does not change how much merchantable wood leaves the system per hour.

Illustration — full-tree system. Suppose a feller-buncher can bunch trees fast enough to support 30 m³/PMH of system throughput, the grapple skidder (constrained by a long skid distance and rough ground) can only extract 18 m³/PMH, and the landing processor can handle 25 m³/PMH. The skidder is the bottleneck: system output is capped at 18 m³/PMH no matter how fast the buncher runs. Doubling the buncher's felling rate does not raise system output at all — it only builds a larger inventory of bunched, unextracted trees at the stump (tying up working capital in standing/felled wood and potentially creating a fire or windthrow hazard) while the skidder continues to feed the landing at the same 18 m³/PMH. Conversely, an investment that raises the skidder's rate to, say, 24 m³/PMH does raise system throughput, because the skidder was the true constraint — up to the point where 24 m³/PMH exceeds the landing processor's 25 m³/PMH capacity closely enough that the processor becomes the new bottleneck, after which further skidder gains again yield nothing until the processor, too, is upgraded.

This has direct practical consequences for capital allocation: a company should measure the productivity of every machine in a system, identify the current bottleneck empirically (not by assumption — the bottleneck can shift with terrain, season, or stand type), and direct improvement investment (a faster machine, additional shift capacity, better operator training, preventive maintenance to raise utilization) at that constraint specifically. Spending capital to speed up a non-bottleneck machine is, in system terms, wasted investment; the money would have been better spent adding a second unit of the bottleneck machine, shortening its cycle (e.g., relocating a landing to shorten skid distance), or raising its utilization through better scheduling and maintenance. The one partial exception is a machine improvement that also reduces variability (not just average rate) at a non-bottleneck station, which can still help by smoothing the buffer feeding the true bottleneck and reducing the bottleneck's own starve/block idle time — but the throughput ceiling itself is still set by the bottleneck's average rate.