A production manager at a metal casting facility in Kayseri said something I have not forgotten: ‘We installed the ERP, but we still have no idea what is happening on the shop floor.’ The company had committed serious budget to the project, finance and procurement modules were live, and the accounting team was satisfied with their reports. The production floor, however, might as well have existed in a different universe. Shift-end data was collected on paper slips and manually entered by an accounting clerk — a process that regularly stretched to a 48-hour lag. Management learned what was produced yesterday by waiting until the end of today. This pattern is the single most consistent structural failure I encounter in manufacturing ERP implementations across Turkey, and its solution is not technical. It is methodological.The value of an ERP project is not measured by the moment the system goes live. It is measured by whether the system receives real production data in time to matter. As long as manual entry persists, ERP becomes a lagging record of accounting history rather than a live instrument for operational decisions. This distinction sits at the heart of project success. No matter how well an ERP system is configured, it cannot support meaningful management decisions without a functioning data feed from the production floor. In mid-sized Turkish manufacturers, this problem is routinely deferred — finance first, production later — and that ‘later’ almost never arrives on its own.Shop floor data collection creates value along three distinct dimensions. The first is capacity visibility: which machine ran for how many hours, how long was it idle, what caused the stoppage? Without this information, production scheduling remains an exercise in educated guesswork. The second is inventory accuracy: when the system shows a theoretical work-in-progress figure that bears no resemblance to what is physically in the warehouse, procurement decisions are systematically distorted. The third is cost variance tracking: the gap between standard cost and actual cost can only be closed when work orders are updated with real production outcomes. If any one of these three dimensions has a gap, calling the ERP ‘integrated’ is a stretch. Defining these three questions up front determines the actual scope and architecture of any production data collection investment.A metal parts manufacturer in Eskişehir — 287 employees, mid-range precision components for the domestic automotive supply chain — was forced to confront exactly this situation. Eleven months after ERP go-live, the procurement team was still saying they did not trust the stock figures. When we traced the root cause, the average lag for closing production work orders in the system was 3.5 days. The system was always reflecting a reality that was three and a half days old. The first intervention was simple: barcode-printed work order cards at each machine, paired with small terminal screens, so that operators recorded completion at the moment a job finished rather than at shift’s end. This reduced the data entry lag from 3.5 days to under four hours. The second step placed barcode readers at semi-finished goods movement points, eliminating manual inventory updates entirely. Together, these additions consumed less than 8 percent of the original ERP project budget — and they fundamentally changed what management could actually see.A caveat belongs here, and it is a real one. This approach is not a universal template. In Eskişehir, the gains were possible because the production processes were sufficiently repetitive and standardisable. In a custom machinery manufacturer in Ankara — where every work order is unique and job complexity varies sharply — the same barcode terminal solution was plainly insufficient. That project required a task-level progress logging model, rebuilt from scratch around the way their engineers actually recorded work. Complexity of process and scale of customisation change what a viable solution looks like. Consultants who ignore this and prescribe the same architecture across different environments are the reason projects fail to generate value. The question is not which solution is best in theory but which one matches the actual process structure in front of you.For the Monday-morning question — what to do first — a concrete sequence helps. Begin by measuring the actual lag between a production event and its reflection in the ERP system; this figure is almost always larger than management suspects and almost always invisible until someone looks. Second, identify which single data point carries the highest decision impact: is it stock accuracy, machine availability, or scrap rate? Third, design the simplest possible data capture mechanism for that one point — one that does not require operators to change deeply ingrained habits in one step. Fourth, run a pilot on a single production line or a single shift; absorb the failure modes there, not across the whole plant. Only after a pilot demonstrates a measurable difference should the rollout expand. Between a large infrastructure investment and a small disciplined pilot, the pilot nearly always wins when shop floor culture has not yet shifted — large investments made before habits change are the fastest way to spend money on shelf-ware.The real value of an ERP project surfaces not on go-live day but on the day production data begins flowing consistently. The procurement manager at the Eskişehir facility said that once he trusted the system’s stock figures, he could identify and reduce over-ordering patterns he had been running defensively for years. That was not a software achievement. It was a decision quality improvement made possible by data discipline. If the production manager in Kayseri were asked the same question today, the answer would be different — not because the software changed, but because the question has to change first. The right starting point is not ‘is the ERP installed?’ It is ‘is production data actually flowing?’
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 14, 2014. The English edition has been reviewed and edited by the author.