During a consulting engagement at a machine manufacturer in Konya, I watched the plant manager open two separate Excel files every morning — one populated with work orders manually exported from the MRP system, the other filled with weekly barcoded production counts from the shop floor. He then merged both into a third spreadsheet and typed the result into the ERP stock module by hand. The company employed 312 people, produced roughly 380 product families per year, and had a system in place. But the system was not working — the data flow was broken. That is the real issue: connecting MRP and production data collection to ERP is not a question of technical wiring. It is a question of data quality and process maturity. Any integration project that ignores this will accelerate the dysfunction already present in the operation, not resolve it.MRP — Material Requirements Planning — functions as an independent calculation engine within the ERP production layer. Starting from the master production schedule, it computes what materials are needed, in what quantity, and by when. Production Data Collection (PDC) is the mechanism that brings the shop floor’s actual time, quantity, and scrap data into the system: barcode readers, weight terminals, counter-based sensors, or operator entries at a touch terminal. When these two layers communicate correctly with ERP’s finance and stock modules, the picture is clean: a work order opens, material reservations are created automatically, the shop floor records production, costs are calculated close to real time, and inventory updates without manual intervention. Reaching that picture, however, requires answering several foundational questions first.The first question is whether the existing Bill of Materials (BOM) reflects reality. In the Konya case, roughly a third of the BOMs had not been updated to reflect recent engineering changes. MRP uses these records as its calculation base, so its output was systematically wrong. Wiring PDC data into an ERP running on outdated BOMs is like delivering the wrong order on time — the process appears efficient while the output remains flawed. The second question is whether work centers are properly defined and capacities are current. ERP assigns work orders to work centers and loads against declared capacity. If those definitions have not been updated in two years — a situation I encounter regularly in manufacturing environments — capacity planning stays theoretical. The third question is the most overlooked: is the shop floor culture ready for data entry discipline? Many PDC projects stall not because of hardware problems but because operators treat the terminal as extra work and supervisors do not enforce it, because they themselves do not trust the system’s output.On the technical architecture side, the integration involves three distinct layers. First, the MRP engine generates work orders and ERP creates the corresponding material reservations. Second, the PDC system captures shop floor records — completed quantities, scrap, downtime — and passes them upstream. Third, both layers write into ERP’s stock and cost modules. In Turkish manufacturing environments at this time, the most common approach was either an ERP vendor’s own production module with native PDC connectivity, or a lightweight middleware layer executing scheduled or near-real-time synchronisation jobs between the PDC database and ERP. Either way, the critical configuration decisions are the same: which data flows in which direction, at what frequency, and when a conflict arises between planned and actual figures, which value takes precedence? These are management decisions that must be made before a single cable is connected.The most common mistake I see in these projects is defining the scope as ‘activate the production module and connect the barcode readers.’ What should happen first is a process walkthrough of the work order lifecycle on paper: from sales order to production release, material withdrawal, operation recording, quality sign-off, and warehouse receipt. At every step, two questions are asked: who does what, and when does that information enter the system? Every gap or delay visible on that map will survive the integration and continue causing problems on the other side of go-live. In a comparable engagement at a metal fabrication facility in Gaziantep, this mapping exercise revealed that the production approval step had no system counterpart — ERP was updating stock theoretically while quality rejections did not reflect in real time. Identifying this took six weeks; correcting it took two. The full integration project closed in 14 weeks, and inventory deviation at monthly count dropped substantially — the plant manager described it as ‘monthly stocktaking is no longer the crisis it used to be.’Managers in this position face two simultaneous pressures: the ERP vendor says ‘connect the system and the data will flow’; the finance team says ‘costs are still calculated by hand, this is unacceptable.’ Both pressures are legitimate. The sequence, however, is wrong when the technical work precedes the data work. The correct order is: clean the data first — update BOMs, validate work centers, confirm routing sequences. Then select and install PDC hardware. Finally, configure ERP production module parameters to match the actual data flow. Projects that reverse this sequence typically invite the same consultant back within six to nine months. Allocating roughly a third of the integration budget to process definition and data remediation — before any coding begins — recovers its cost in under half the time compared to a purely technical first pass.Was the Konya plant manager still opening Excel when the project closed? He was — but for verification, not out of necessity. When I asked whether he trusted the MRP output, he said: ‘As long as the BOMs are right, yes.’ That single sentence captures the real success criterion for this kind of project: not the system itself, but the trust placed in the system’s inputs. If you are a production manager or operations director evaluating an MRP-to-ERP integration, start with one honest question: how much do you trust your current data? If the answer is ‘not entirely,’ begin with a data maturity assessment — not a technical integration proposal.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 26, 2012. The English edition has been reviewed and edited by the author.