Last year, the plant manager at a plastics and chemical packaging manufacturer in Gaziantep placed two questions on the table when he learned that his facility — 284 employees, mid-sized by Turkish standards — needed to integrate with the parent company’s SAP R/3 system based in Germany: ‘How long will it take?’ and ‘Who pays for it?’ The software had already been chosen, the process design had been finalized, and the project timeline had been set — all without a single person from the Gaziantep site at the table. The technical deliverable arrived in six weeks. The real problems started after that. My argument in this piece is straightforward: in multinational manufacturing companies, integrating a local operation with headquarters systems is far more often a corporate governance challenge than a technical compatibility project — and most integration failures trace back not to software mismatches but to role boundaries between headquarters and local management that were never clearly defined in the first place.When a multinational company’s Turkish manufacturing facility connects to the group’s global ERP infrastructure, it immediately confronts two distinct realities at once. The first is structural: the headquarters system’s data model, reporting logic, and accounting framework may not map cleanly to Turkish local requirements. A consolidated balance sheet aligned with IFRS may not correspond to Turkish Accounting Standards; the inventory valuation rules under the Turkish Tax Procedure Law may conflict with the FIFO or weighted average cost methods embedded in the central system. These are real, but manageable, technical gaps. The second reality — and the one far more commonly overlooked — is organizational: the local team typically does not understand what the headquarters system is actually there to serve, where their own contribution ends, and what the reporting expectations from the center genuinely require. This ambiguity turns the integration project into a structure that is technically complete but functionally suspended. In Gaziantep, that is exactly what happened: data was being entered, reports were being generated, but headquarters kept saying something was ‘missing’ — and the local team struggled to understand what.The requirements analysis phase in these projects is almost always underpowered — either too short or conducted with the wrong participants. Headquarters sends its technical specialists and process consultants; from the local plant, the accounting manager and perhaps the production planning supervisor are invited to the sessions. But functions like procurement, quality control, warehousing, and shipping are routinely excluded from those initial analysis meetings. Yet it is precisely in these areas that the most consequential integration decisions are made. How will raw material batch tracking work in a chemical packaging plant? Will the supplier invoice posting in accounting go out simultaneously with the purchase approval at headquarters, or will a local approval workflow run separately? These questions must be answered before the software is deployed. When they arrive later as ‘customization requests,’ both cost and schedule overruns become inevitable. Cutting the requirements phase does not accelerate the project — it only moves the problem forward in time.User habits represent one of the most consistently underestimated dimensions of any integration project. At the Gaziantep plant, roughly half the accounting team had spent years working with a local accounting package; they tracked inventory movements through self-built Excel templates they had refined over time. When the transition to SAP R/3 came, the training time allocated for these users totalled four days. Four days. Predictably, instead of adapting to the new system, the team found ways to preserve their existing habits — some pulled data into Excel first and re-entered it into the system; others left mandatory fields blank. In a manufacturing facility, this behavior directly compromises the reliability of every report the center receives. Measuring integration success by technical delivery alone — while user adaptation remains unfinished — is choosing not to see that the system is not actually working. The training plan must be designed in parallel with the project timeline, and on-site support should continue for at least two months after go-live in the production environment.As the number of integration points grows, management complexity multiplies. A typical multinational’s Turkish production facility must exchange data with the headquarters system at a minimum of four distinct points: production orders, material movements, financial consolidation, and purchase requisitions. For each of these four interfaces, the following must be documented in advance: what data, at what frequency, in what format, and who holds authority when a discrepancy arises. In practice, this documentation is often incomplete or simply never produced. At a textile dye and chemical producer, a mismatch between the cost center coding expected by the headquarters system and the production line definitions used locally resulted in a reporting error that took eight months to identify — and the root cause was not technical; it was a gap in the analysis phase. Establishing the data transfer protocol is only the first step of an integration project. The real work is ensuring that both sides derive the same meaning from the same data.The gap between management expectations and project reality is the most fragile point of all. Headquarters management tends to view integration completion as the moment the problem is solved. Local management typically experiences the end of the project as the beginning of new problems. This perceptual difference creates conditions for post-integration issues to escalate into political friction rather than being resolved systematically. The answer lies in defining a clear ‘operating model’ for the period after go-live: which reports will headquarters receive and at what frequency, which fields can local teams modify, and who holds first-response authority when a system inconsistency is detected? Producing written answers to these questions before the project begins extends the operational life of the integration — both technically and organizationally.The plastics packaging plant in Gaziantep still cannot fully answer those two questions left on the table — ‘How long?’ and ‘Who pays?’ — but at least it is now asking the right ones. When evaluating a local ERP integration project in a multinational, use this as your benchmark: when the project is complete, does the local team genuinely understand what the headquarters system requires of them? If the technical connection is live but the answer to that question is still ‘no,’ the project is not finished — the real problem has simply become visible.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 26, 2006. The English edition has been reviewed and edited by the author.