Every plant has a toothache.
It's the problem everyone already knows about. The line that quietly loses a few points of throughput every afternoon and nobody can say why. The batches that get scrapped because the issue only shows up after it's too late to intervene. The asset that fails without warning, again, and takes a shift's output with it. The parameter that's set one way in one site and a different way in another, with no baseline anyone trusts.
You don't need a survey to find the toothache. Ask the people on the floor and they'll name it in seconds. It's the thing they'd fix first if they could.
That's exactly where to start — and it's the opposite of how most industrial data projects begin.
The usual approach is to try to describe the whole factory before answering a single question. Map every asset, define every relationship, get the complete model right, and then start pulling value out of it.
It sounds responsible. In practice it stalls. A complete model is a moving target — the plant changes faster than you can document it — and the effort is enormous. By the time you're anywhere near "finished," the urgency that justified the project has moved on, and the toothache is still there.
The problem was never that you had too little context. It's that you tried to build all of it at once, disconnected from any question worth answering.
Minimum Viable Context is the smallest amount of context you need to answer one real question well.
Not the whole plant. Not every asset and every signal. Just the handful of connections that stand between you and the answer to the toothache. If the question is "why do we keep scrapping batches on the night shift," you only need the context that touches that: the assets involved, the signals that move before a scrap event, the process steps in between. Everything else can wait.
This is a deliberately narrow scope, and the narrowness is the point. A small, well-chosen slice of context is something you can actually finish — this week, not next quarter. And once it's in place, it does something a half-built master model never does: it answers the question.
When you scope context to a single business problem, time to value collapses from months to days.
You're not waiting for a model of the entire operation to be complete before anyone sees a result. You pick the problem that hurts, build only the context that problem requires, and get an answer while the problem still matters. The value is obvious because it's tied to something the business already cares about — not to an abstract improvement in data quality that's hard to feel and harder to fund.
That early answer also earns the right to keep going. It's much easier to justify the next step when the last one just paid for itself.
Here's the part that makes this more than a shortcut: the context you build for one problem doesn't disappear when the problem is solved. It stays.
Solve the scrap problem and the relationships you mapped to get there are still in place. When the next question comes along — a slowdown on a different line, a reliability issue on a shared asset — you're not starting from nothing. You're starting from everything the last question taught you. Some of the context you already have carries straight over; you only add what's genuinely new.
So the model of your plant doesn't arrive in one heroic effort. It accumulates, one solved problem at a time, as the residue of work you were going to do anyway. Each answer leaves the ground a little more mapped than before. Over months, you look up and realise you've built something substantial — not because you set out to model everything, but because you kept solving the next problem in front of you.
The question to start with isn't "how do we model our whole factory." That question has no satisfying end, and chasing it is how good intentions turn into shelved projects.
The better question is smaller and far more useful: what's the one problem worth solving right now?
Find the toothache. Build just enough context to fix it. Let the rest follow.