The general manager of a Turkish optical retail chain with 168 branches told me something last month that I’ve heard, almost word for word, in at least a dozen similar projects: ‘The system is live, the integration is running, but the reports still don’t add up.’ I didn’t need a follow-up question. That single sentence tells you exactly where the project got stuck — not in the technology, but in the data flowing into it. Invoices are being issued, the e-Beyanname stream is connected, and the ERP modules are technically operational. Yet branch-level cost reports remain unreliable, stock reconciliation fails every week, and the head office can’t trust the numbers enough to make purchasing decisions from them. My central argument in this piece is straightforward and, I think, underappreciated: in multi-branch ERP deployments, data standardization must come before technical integration — not after, not in parallel without a defined framework, and certainly not as an afterthought left to the ‘go-live cleanup’ phase. Every project that reverses this sequence ends up stuck at exactly the same point: a system that runs, but whose output nobody trusts.Why does sequence matter so much? Because an ERP system is not smarter than the data you feed it. When 168 branches each maintain their own product code logic — which in Turkish retail projects is not a hypothetical but a near-universal finding — the system faithfully aggregates those codes and produces reports that are mathematically precise and operationally meaningless. The same product appears under multiple line items, inventory turnover calculations break down, and the procurement team makes decisions based on numbers that don’t reflect reality. At that point, people blame the software. But the software is doing exactly what it was configured to do. Garbage in, garbage out — this principle reveals itself with particular cruelty in multi-branch architectures, where the scale of the problem multiplies with every additional location.That said, I’ve also seen the opposite failure, and it’s worth naming honestly. In some larger retail rollouts, data standardization is treated as a prerequisite so demanding that the project never actually starts. A working group at headquarters spends months debating product taxonomy standards while branches continue operating with their existing habits. The standard becomes theoretically perfect and practically irrelevant. The real answer sits between these two extremes: a partial but firm data standardization framework established before technical go-live, covering at minimum the master data that drives shared reporting — product hierarchy, customer records, and cost center definitions. Once that foundation is in place, technical integration has something solid to build on.In the Ankara-based optical chain I mentioned, the field picture was this: roughly two-thirds of the 168 branches were not using barcode readers and were entering frame and lens codes manually. Each branch had developed its own shorthand naming conventions over years of independent operation, and reconciling those conventions with the central product master took considerably longer than anyone had planned. The project schedule had allocated three weeks to what it called ‘master data cleanup.’ It took four and a half months. During that period, the technical team waited, costs climbed, and executive patience wore thin. None of this was surprising — it was entirely predictable. A proper needs analysis at the outset would have surfaced this risk, incorporated the realistic timeline, and aligned expectations before the first line of configuration was written. Instead, ‘needs analysis’ had been treated as a module checklist exercise, and the result was a four-month surprise that damaged the project’s credibility with leadership before the system ever went live.What should a real needs analysis actually cover in a project of this kind? The first task is mapping what data each branch currently produces, in what format, and through what process. This isn’t a spreadsheet exercise — it requires at least one or two days of direct observation at a representative sample of branches. The second step is separating shared processes from branch-specific exceptions. In optical retail, eye examination records and prescription tracking are inherently local; centralizing them adds bureaucracy without benefit. Inventory movement and invoice flows, by contrast, must conform to a central standard — and drawing that line clearly before configuration begins prevents the system from being pulled in two directions at once. Third, the technical infrastructure must be mapped honestly. In 2009, asking how many of your 168 branches have a stable ADSL connection is not a peripheral question. An offline contingency plan for branches where connectivity drops regularly is not optional — without it, branch managers improvise during outages by deferring entries or writing transactions on paper and inputting them later, both of which introduce data quality problems that accumulate quietly until they’re visible in the numbers.The fourth element of a genuine needs analysis is a user habit map. What tasks does the branch employee perform today, and how? Which ERP screen comes closest to matching that workflow without requiring a complete behavioral overhaul? Projects that skip this question consistently underestimate post-training drop-off rates. When a system is configured without regard to how people actually work, training closes the gap temporarily, but old habits reassert themselves within weeks. The fifth and most politically sensitive step is making management expectations concrete. When the general manager says ‘centralized reporting,’ what does that mean in practice? Which metrics, at what frequency, at what level of granularity? Without a clear answer to this question before system design begins, the project is navigating without a destination.The sharpest communication breakdown in these projects tends to occur not between branch and head office, but between the project team and executive leadership. Branch managers adapt — they have to. But the general manager who launched the project expecting to trust the numbers within a few months of go-live, and who is still looking at inconsistent reports six weeks after delivery, loses confidence not in the data but in the entire initiative. Recovering that confidence is genuinely difficult. This is why the most important deliverable in a centralized ERP rollout for a branch network is not the software itself. It is a data maturity document, prepared before go-live, that specifies which reports will be reliable from day one, which will require a stabilization period, and which will depend on branch compliance milestones not yet reached. If that document exists at the start, expectation management is built on it. If it doesn’t, prepare to spend the next eighteen months in meetings titled ‘why don’t we trust the numbers yet.’Before launching an ERP project across a branch network of this scale, ask yourself three specific questions: how many distinct product code standards currently exist across your locations, how many branches experience regular connectivity outages, and which tasks does your average branch employee still handle on paper? The answers to those three questions will predict where your project will stall more accurately than any vendor demonstration or project plan. The technology is ready. The more pressing question is whether your organization’s data discipline is ready to meet it.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 17, 2009. The English edition has been reviewed and edited by the author.