Before launching an SCM project in food distribution, one question deserves a straight answer: how many product codes do you have — and how many of those can you actually define correctly? That was the first question I asked in late 2005, stepping into a large-scale food distribution and catering firm based in Ankara. The answer was sobering: more than 30,000 product codes sat in the system, yet a significant share consisted of duplicate entries, poorly defined variants, and items that had long since left the active catalogue. The company made daily deliveries to roughly 2,000 distinct points — hospitals, schools, institutional catering clients, hotel kitchens. The SCM software had been purchased, the go-live date was set, the project team was assembled. What was missing was the foundation.The thesis I want to defend here is this: most SCM projects in food logistics fail not because of software limitations, but because of data disorder and process ambiguity. Even when the right platform is chosen, launching without clean product master data and clearly defined delivery workflows simply reproduces the old chaos inside a new interface. This is a reality I encounter repeatedly in the sector but rarely hear discussed plainly.The first phase of the project was not technical setup — it was a data audit. Rather than reviewing all 30,000 product codes one by one, the operations manager and I agreed on three primary categories: dry goods, cold-chain products, and cleaning and consumable supplies. That classification alone was a small but meaningful breakthrough. Until that point, the company managed every product through a single undifferentiated list, applying the same stock management logic across the board. A chilled dairy product and a bag of dried lentils cannot be governed by the same rules. Shelf life, storage conditions, vehicle type, delivery priority — all of these diverge. Saying this in a meeting takes thirty seconds; restructuring the product master data to reflect it takes six weeks.The delivery point database told a similar story. Among the 2,000 active addresses, the share with incomplete or inaccurate records turned out to be considerably higher than anyone on the team had assumed. Some entries referred to institutions that had closed, others were the same address entered under different names across different contracts. The sales team had managed this information for years through paper order forms and telephone confirmations; the system was used almost exclusively to issue invoices, not to drive logistics planning. This is precisely where SCM earns its value: route optimisation and delivery scheduling only work with clean address data. A mathematically optimal route built on inaccurate inputs is simply the wrong route.On the integration side, a different kind of pressure emerged. The company’s accounting software and warehouse management system ran on separate platforms with no direct data feed between them. Bringing the SCM layer in meant building a bridge between those two systems. At the time, this kind of integration was typically handled through ODBC connections or scheduled batch file transfers — not real-time data exchange, but hourly or nightly bulk synchronisation. Failing to acknowledge this constraint upfront and build it into the project plan creates a predictable problem: users start asking why the stock figure on the SCM screen differs from the one in the accounting module, and there is no clean answer to give them. A comparable situation came up during a project with a food wholesaler in Konya; the integration delay effectively paralysed the order confirmation process for the first two months after go-live.User habits deserve separate attention. The operational team of 312 people had largely run their daily work through phone calls and paper forms. The SCM system now required them both to spend time in front of a screen and to relearn established workflows. The strongest resistance did not come from the least experienced staff — it came from the most experienced. The person who trusts the old method most is the one who pushes back hardest against the new one. If the training plan and migration schedule ignore this, the project ends up technically complete but operationally unadopted. In the logistics sector, this happens more often than the project documentation ever records.Management expectations also needed a clear frame from day one. Senior leadership wanted two things from the SCM investment: lower delivery costs and fewer customer complaints. Both were valid, measurable goals. What required honest communication was the timeline. Expecting meaningful cost savings from route optimisation before data cleansing and user adoption are complete is optimistic to the point of being unrealistic. The experience from this project showed that roughly 11 months passed between go-live and the first measurable operational benefit. During the first four or five months, what becomes visible is not efficiency — it is transparency: which vehicle is where, which delivery is behind schedule, which product’s stock turnover is lagging. That visibility is genuinely useful, but its effect on the cost line takes time to surface.For any food distribution or catering company preparing a comparable SCM project, I would set out three concrete steps before anything else. First, audit your product master data before selecting or installing software; do not migrate into the new system until duplicate codes, undefined variants, and inactive items have been removed. Second, geographically verify your delivery point database; every address with an error corrupts route calculation for that entire run. Third, define the integration method and its limitations with your existing platforms at the very start of the project — real-time feed or batch transfer, at what interval, with what latency — and document the answer before the first line of configuration is written. The Ankara food distribution firm followed these steps carefully and recorded a visible improvement in average delivery cost per route after 11 months. Those who moved faster skipped the groundwork and ended up maintaining both the new system and the old paper forms in parallel — which is the most exhausting way to run an operation, and the clearest sign that the project never truly finished.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 5, 2006. The English edition has been reviewed and edited by the author.