When I first engaged with a 285-employee automotive spare parts manufacturer based in Kayseri, the company was running on two separate systems: the factory floor used a production-specific tracking program, while the commercial unit managed orders and stock movements in a standalone accounting package. Data exchange between the two systems happened through Excel files, and every month-end the finance manager spent two full days manually reconciling the figures into a consolidated report. In our opening meeting, the general manager said, ‘Let’s build one system that connects everything.’ Almost everyone in the room — myself included — assumed this was a technical project. It was not. The real obstacle turned out to be the conflict between the production manager and the sales director over whose priorities would govern the system. Until that conflict was resolved, no ERP implementation could deliver lasting results.The standard business case for a unified ERP architecture is straightforward: data in one place, consistent reports, lower error risk. That case holds — but only under one condition: the two operational worlds, manufacturing and commerce, must agree in advance on shared data definitions. In the Kayseri project, the factory tracked inventory in kilograms; the commercial team quoted prices and confirmed orders in units. Before a single line of configuration was written, the conversion rule between these two measurements should have been documented and signed off by both sides as a formal process agreement. Instead, the project started with a shared assumption that ‘production knows, sales knows, so the system will figure it out.’ The system, of course, did not. When the first invoice was generated, each department blamed the other. The software kept throwing error flags, consultants worked weekends on-site — but the root cause had nothing to do with code.This is the thesis I want to state plainly: the biggest barrier to unifying manufacturing and trade in a single ERP architecture is not technical integration — it is organizational priority conflict. And resolving that conflict before the project begins is a far more important decision than choosing which software to buy. Consultants typically use requirements analysis workshops to build feature lists. What those sessions should actually produce is the answer to a single question: ‘When a sales order and a production plan clash, whose decision prevails?’ If that question cannot be answered clearly, the software will pay the price — but the company will issue the invoice. In Kayseri, we asked that question in week four. The system went live 14 months later, and nearly all of the first eight months of delay was spent chasing that single undefined decision.On the technical side, there were genuinely two integration points that required careful design. The first was the trigger flow between work orders and sales orders. Production-specific systems plan against capacity; the ERP commercial module generates delivery schedules driven by customer dates and contractual commitments. When these two timelines meet in a single database without a documented priority rule, the system will attempt to honor both and produce inconsistent outputs. In Kayseri, the solution was a workflow rule that held a sales order in a pending state whenever it demanded more than a defined capacity threshold — production approval was then required before commitment was confirmed. Once this rule was encoded into the ERP workflow, scheduling conflicts disappeared. The second integration point was cost accounting: the factory calculated standard costs per production run, while the commercial unit priced against actual landed cost. When both methods coexisted in the same module, month-end closings produced figures that neither side trusted. The fix was to turn the monthly cost reconciliation process into a mandatory control step inside the ERP itself; the finance manager now uses the system’s own report as the closing document rather than a manually assembled spreadsheet.User adoption deserves its own discussion, because most ERP projects quietly collapse here long before anyone admits it. In Kayseri, the shift supervisors on the factory floor had tracked production using paper forms for years. The factory manager trusted those forms — ‘paper doesn’t lie,’ he told me during the second site visit. For the first three weeks after go-live, paper forms and the new system ran in parallel. This parallel period meant reassurance for the manager and extra workload for the operators. After eight weeks of parallel operation, the factory manager agreed to retire the paper — because the system was now automatically generating the shift productivity report he used to compile manually every morning. The lesson is simple: you get users to adopt a new system by making their existing habit faster, not by demanding they abandon it entirely. Managing executive expectations required a different kind of balance: the general manager wanted a single consolidated report, the sales director wanted real-time inventory visibility, and the production manager wanted a capacity load graph. None of these can be served by the same report — but all three can be satisfied independently through properly designed role-based dashboards. Achieving that takes no extraordinary technical skill; it takes sitting with each stakeholder and asking, ‘What question are you trying to answer today?’From a total cost of ownership (TCO) perspective, a unified ERP architecture almost always comes out cheaper than maintaining two separate systems with a manual data bridge between them. In Kayseri, when we calculated the combined cost of two software licenses, two maintenance contracts, and the staff time devoted exclusively to managing data transfers between the systems, the annual figure was substantial. After the unified ERP went live, that cost dropped by 46 percent — but only from year two onward, because year one was absorbed by project and training expenses. When building the ROI case for senior management, the most credible approach is to show year one as negative and measure the return from year two. Any consultant who presents a first-year payback promise is either optimistic to a fault or has not done this type of project before, and the client will discover which one by December of that year.If you are preparing a unified ERP proposal for any company running manufacturing and commercial operations in parallel, here are three things to complete before you show a single software demo. First: run a half-day process mapping session with both the production and commercial teams in the same room, follow the question ‘what happens when an order arrives?’ step by step, and document who makes each decision at each stage. Second: list every data definition conflict — unit of measure, product code structure, pricing method — and produce a written reconciliation protocol for each one, signed by both department heads. Third: allocate at least 25 percent of the project budget to training and parallel operation, not to software licenses. I have not seen a single ERP project that skipped these three steps and succeeded in practice. In Kayseri, we worked through all three in sequence. The system runs today, and the finance manager no longer opens Excel on weekends. That may sound like a minor detail. For her, it is anything but.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 26, 2010. The English edition has been reviewed and edited by the author.