When I began working with a mid-sized restaurant chain in Ankara — seven branches, 127 staff, a catering arm on top of the core operation — the general manager had three separate Excel files open on his screen. One tracked weekly sales, one kitchen costs, and one the daily cash close for each branch. None of them spoke to the other, and pulling all three together into a single table took roughly three hours every week, every week of the year. The chain was not lacking in software: two separate applications were already running. The problem was that neither talked to the other, and neither reflected what was actually happening inside branches where staff had been left to enter data however they saw fit. The argument I want to make here is this: in multi-branch food-service operations, data-centralisation projects are not primarily technical integration problems — they are process-standardisation problems. Any system deployed before that standardisation is done will reach a dead end within the first month.It is worth being precise about what ‘centralising data’ actually means in this context. A restaurant or catering operation generates three distinct data streams simultaneously: sales data (which table, which item, what time, which payment method), product and stock data (which ingredient was consumed, how much waste was recorded, what arrived from suppliers), and financial data (cash-close figures, receipts, the split between cash and card, refunds). When these three streams are kept in separate places the result is a striking blind spot: the business knows its daily revenue but not its actual margin. Matching a given day’s sales against that day’s ingredient consumption is only possible when all three streams flow into the same system. At the Ankara chain, that match was made only at month-end, after an accountant spent a week manually reconciling separate tables.The real difficulty at the start of the project was that management saw software procurement as the solution rather than the starting point. This perception is remarkably common. Within the first week on site, though, I noticed something that made the software question secondary: every branch’s cashier was recording the same product under a different name. In one location, the item was ‘meatball plate’; in another, ‘main course — meat’; in a third, it had been entered as a price only, with no product name at all. If an integration project is launched without correcting this first, the central system will collect data but will not be able to produce meaningful reports, because the underlying data is internally inconsistent. For this reason, the first four weeks of the project were devoted not to technical installation but to building a single, standardised product and menu list. Every menu item used across all seven branches was compiled into one master list, assigned a code, and every branch was moved to work from that code list. Without this step, no system produces sustainable data.Once the integration points were mapped, the technical picture became considerably clearer. At the time, most mid-sized restaurant chains in Turkey were running two separate systems: a point-of-sale application for table management and cash, and an accounting package — typically LOGO or Netsis — for finance. Data flow between the two was almost universally absent; the accountant would manually key the daily cash report from the POS into the accounting system each morning. In our project, the solution was to connect both systems to a shared database via ODBC, so that the end-of-day POS close wrote automatically to a common table from which the accountant could pull reports directly. The catering side of the business required a separate module because catering involves advance orders and a different invoicing cycle from walk-in dining. Trying to run both models through the same cash-desk logic would have produced a different kind of confusion. Mapping integration points correctly always comes before the technical build.Realistic expectations about user habits matter more than most project plans acknowledge. Getting the system working across seven branches meant working with seven separate teams and seven sets of ingrained habits. A meaningful share of the cashiers — around %45 of the front-of-house staff — had never used a standardised product code before. Training sessions were held, but the more decisive factor was whether branch managers personally took ownership of the system. For the data to stay clean, each branch manager needed to sign off on the daily close report themselves. This approval step was added partway through the project, after it became clear that some cashiers were treating incorrect entries as something to be fixed later rather than prevented upfront. Once the approval step was in place, the error rate dropped noticeably. As the general manager put it: ‘I finally trust the numbers coming from the branches.’ Software does not make decisions. The people using it do. That sentence was the most durable lesson from the whole engagement.After the central reporting system went live, the chain’s management saw branch-level profitability clearly for the first time. Two of the seven branches were generating strong revenue but showing net margins below the chain average — because their kitchen waste rate was significantly higher than the others. This had been invisible before, because sales and ingredient consumption had never been matched. The decision that followed was to change the kitchen supervisor in both locations and move to weekly rather than monthly waste tracking. What made that decision possible was not the software. It was the structure of the data. For anyone managing a similar operation, the question worth asking before the next software purchase is straightforward: do the figures coming from your different branches actually speak the same language? Is the same product recorded under the same code everywhere? If the answer is uncertain, resolving that uncertainty will deliver more value than any new application installed on top of the current disorder.
This article was originally published in Turkish by Gökhan MERCANOĞLU on February 7, 2009. The English edition has been reviewed and edited by the author.