# Don't Boil the Ocean. Find the Case. > When you inherit two dozen disconnected systems, the instinct is to map everything before you touch anything. The faster path is to find the one thing your... Published: 2026-06-16 · Updated: 2026-06-23 · Topics: Data & Analytics, AI & Machine Learning, Digital Transformation, Enterprise · Author: Alan Wizemann When I describe the data problem we inherited at Southern Glazer's, people tend to assume I'm exaggerating it for effect, and I'm not. We had more than two dozen separate ERP systems (over twenty, accumulated over decades of growth and acquisition) and they did not talk to each other in any meaningful way. Dozens of teams across dozens of markets were each generating the same report off their own private island of data, and there was no single version of anything, for the simple reason that there was no single anything to begin with. The instinct in a room like that, the very natural one, is to panic into bigness. You need a master plan – you map every system, you define every field, you stand up a program office, and eighteen months later you allegedly have clean data sitting at the end of it. I've watched that exact movie play out more than once, and it usually ends with a roadmap nobody follows and a number on a slide that nobody in the room actually believes. There's also a real fear sitting underneath the paralysis, and it's genuinely worth naming out loud because it explains a lot of the freezing. This is operational data we're talking about. If you touch the wrong thing and a billing system goes dark for a month, that is somebody's job and somebody's livelihood, and everyone in the building knows it. So people understandably freeze, and the systems stay separate for another year, and then another. The first thing I actually did was lower the temperature in the room. We weren't writing to any of these systems at all – we were only ever reading from them, and that one distinction takes most of the genuine danger off the table, and it's remarkable how much it relaxes a nervous organization just to hear it said plainly. Then, instead of trying to map everything at once, we went and found one thing. In our business, everything moves in cases – wine, spirits, whatever it happens to be, at the end of the day it's a box of bottles – so the case became the atomic unit, the thing we'd nail down first. Not the whole catalog, not the entire chart of accounts, just the small set of questions about a single case: what is it, where does it sit, how is it costed, how does it move, what port did it come in through? Once we genuinely understood the case, it became the nucleus that everything else started to organize itself around, almost on its own. And that's the move I'd tell anyone facing this to make first. Find the smallest true thing your whole business is actually built on, the unit that everything else is just a combination of, and start there and nowhere else. We did get a head start from one piece of luck, which was that some of the acquired systems already shared a common data layer left over from an earlier merger, so we weren't quite starting from a blank page. We used that existing definition as a template and let the rest of the work radiate outward from it, and the lesson there is a small but real one: look hard for the standard that already exists somewhere inside your organization before you go off inventing a brand-new one nobody asked for. The part everyone wants to hear about, of course, is the AI, and it did matter, though not in the way the headlines would lead you to believe. We built our own transformation logic and let the systems learn the mapping themselves – what do you call this field, where is this data actually coming from, does this thing over here look like the same thing as that thing over there. The system proposed the matches, and a data analyst confirmed them, and that was the whole loop, start to finish. What would normally have been a year of people manually hunting through schemas became something a lot closer to a month. The thing that genuinely kept me up at night, though, wasn't the speed of it at all; it was trust. What happens when there's a hallucination on a number, and what happens if something maps wrong and nobody notices until it's already sitting inside a report that an executive is reading and making decisions from? So we built something deliberately, almost stubbornly simple: agents checking other agents' work, arranged in layers, and where the system wasn't confident in a match it flagged itself rather than guessing quietly. We landed at accuracy well up in the high nineties, and the part I genuinely care about most is that the places where it was wrong were already raising their own hand. A known error is something you can simply go and fix. It's the silent ones, the wrong numbers that look exactly like right numbers, that actually hurt you down the line. Here's the part that honestly surprised me. We built this whole thing for reporting – unglamorous, "can we please stop running the same report two dozen times across two dozen markets" reporting – and then the moment we had a normalized data set sitting cleanly across every market, a much bigger opportunity just appeared on its own. If the data is already clean and consistent everywhere, why not run every market on a single, modern ERP built right on top of it? That became the next phase of the work, and it was only ever possible because we'd done the boring, narrow thing first and earned the right to the bigger one. The normalization also exposed problems that nobody in the company had been able to see before – dead stock, inventory that should have been on a shelf somewhere and simply wasn't, the same product priced differently in two markets for no good reason anyone could actually articulate. None of that was hidden on purpose by anybody. It was just invisible, because everyone was only ever looking at their own island and nobody had the ability to look across all of them at once. Clean data doesn't only make the reporting faster; it shows you exactly where the money has quietly been leaking out of the business for years. And starting small kept paying off well after the initial build was done, in a way I didn't fully anticipate. Because we'd gone one field at a time, teaching it the pattern as we went, the system eventually started proposing the next field itself, and when someone added a new field somewhere down the line it could figure that one out too, more or less on its own. It self-regulated, in other words, without anyone going back to rebuild it. That's the quiet advantage the big-bang master plan never gives you – the thing you build actually learns how to extend itself, because you taught it the underlying pattern instead of just handing it the whole finished answer all at once. I've come to think the reason this is so hard for large organizations isn't really technical at all. It's temperamental. A master plan feels like progress, because it has phases and owners and a Gantt chart you can put up on a screen and present to a board, and starting with one single field feels almost embarrassingly too small to matter – right up until the moment it turns out to be the only part of the entire program that's actually working and producing anything real. The discipline is the same one that's quietly run good software for twenty years: break the thing into small, specific jobs, and do each one of them genuinely well. Ask a system, or for that matter a person, to do seventeen things at once and you reliably get confusion; ask for one very specific thing and you tend to get excellence. So when someone walks into my office and shows me the big subway-map plan with everything connected to everything, I ask the same question every single time. What's the one field we can normalize first? Prove that one out, and then go do the next one, and then the one after that, until the radiating-outward thing starts happening on its own. You don't get paid for the size of the plan. You get paid for the thing that actually works. --- Canonical: https://alanwizemann.com/articles/dont-boil-the-ocean-find-the-case