# The Haystack Syndrome **Eliyahu M. Goldratt**  --- _Information is not input to the decision process. It is the output._ That reframe collapses most of what companies call "data strategy." Data is any string of characters describing reality. Information is the answer to the question asked. They're not the same thing, and confusing them is expensive. Companies collect oceans of data but remain starved of information because they never defined what question they needed answering. An effective information system doesn't start with data; it starts with the question, builds the decision procedure, then pulls the required data from a data system. Good [[Estimates]] follow the same logic: define what you need to know before reaching for numbers. Measurements are a direct result of the chosen goal. You cannot select a set of measurements before the goal is defined, which means organisations that measure everything before agreeing on purpose will end up controlling nothing. For Goldratt, the goal is to make more money, now and in the future. Three questions suffice: How much money is generated? How much is captured? How much do we spend? Everything else is noise, and noise is not merely unhelpful. It's actively misleading, the thing that makes [[Ratios]] dangerous when they multiply without discipline. --- **The throughput model replaces cost accounting with three global measurements.** Throughput (T): money generated through sales, which is selling price minus materials. Inventory (I): money the system has invested in things it intends to sell. Operating Expense (OE): money spent converting inventory into throughput. That's the entire framework. Net profit and return on investment can be expressed in terms of these three; so can cash flow. Value is realised at the moment of sale, not during production. "Product cost," "product margin," "product profit" are all phantoms. Net profit exists only at the company level, never at the product level, a truth that [[Cash and profit]] makes concrete. When deciding whether to drop a product, the right questions are: what is the impact on total throughput, and what is the impact on total operating expense? If the reduction in throughput is smaller than the reduction in operating expense, drop it. Otherwise the allocation games are masking the answer. "Tell me how you measure me, and I will tell you how I will behave. If you measure me in an illogical way, do not complain about illogical behaviour." This is not a clever saying. It is a design principle. --- **The Theory of Constraints gives the method.** Identify the constraint (the weakest link). Exploit it, squeezing maximum value without major investment. Subordinate everything else to it; non-constraints should serve the constraint, not optimise themselves. Elevate the constraint if needed. When it shifts, repeat, and treat the new state as an entirely new system. Most constraints are policy-driven rather than physical. The real bottleneck isn't the machine. It's the rule nobody questions. In dependent systems with variability, the distribution of outcomes is nothing like the Pareto principle. It's closer to 0.1% of variables determining 99.9% of results. Every local efficiency that doesn't improve the constraint is waste. The work ethic trap plays directly into this: "If a worker doesn't have anything to do, find him something to do" is the opposite of subordination. Non-constraints need protective capacity, not busyness. Dr. Ohno, inventor of Kanban, put it plainly: "Cost accounting was the one thing I had to fight all my life. It was not enough to chase out the cost accountants from the plants; the problem was to chase cost accounting from my people's minds." Changing a constraint changes everything. Go back to step one. ---