When you set out to implement an integrated ERP system from shop floor to shipping, the first problem you encounter is not software selection. The real question is this: which process are you actually automating? In a mid-sized metal parts manufacturer based in Konya — 312 employees, six production lines, both domestic and export customers — a project I ran last year demonstrated once again just how expensively this question gets ignored. Management had initiated the ERP project to improve coordination between production planning and dispatch. Before the project was complete, we had spent half our time on process redesign — because automation does not magically fix a broken process; it simply runs that process faster.The central argument here is this: in integrated ERP investments that span production to shipping, the primary cause of failure is not the software — it is insufficient process maturity. If needs analysis and process mapping are not completed before the software conversation begins, even the best ERP will not deliver the expected value. This is not a problem unique to SMEs; mid-sized and large manufacturers fall into the same trap. But the invoice hits harder in an SME, because the budget leaves no room for error.What we found during the process mapping phase in Konya was entirely typical. Production planning, order management, and dispatch were each running on separate, disconnected spreadsheet logic. Purchase orders had been entered into the ERP, while production orders were recorded in a separate table. Semi-finished goods inventory was not tracked in real time; the warehouse supervisor conducted a physical count at the start of the morning shift and forwarded the results to the accounting team by email. The average delay in that information flow was four hours. Shipping documentation came from a separate accounting module, and the dispatch note was filled in manually from a template. Understanding this arrangement before the system went live was more critical than the implementation itself. Because buying modules without knowing which data you are moving into ERP is like building a roof without a foundation.How, then, should integration be structured? Along the process from shop floor to shipping, the critical data points are: work order creation, raw material issue, semi-finished goods movement, quality approval, packaging, and shipping document generation. Ideally, all six of these points should be closed to manual intervention — or at minimum subject to controlled exception handling. In the Konya project, only work order creation and shipping documentation were integrated in the first phase; the intermediate points were deferred to phase two. That was a deliberate decision. Pushing all modules live simultaneously, without first transforming user habits, generates resistance and creates fertile ground for critical errors. Delivering full system training to all 312 employees at once was neither operationally nor financially sustainable. In the phased rollout, production floor operators worked exclusively with the work order screen for eight weeks while the other modules were prepared in the background. During that period, the user error rate fell from 48 percent in the first week to 13 percent by the eighth. That figure demonstrates numerically that user resistance is a project variable that must be managed with the same rigour as technical integration.Management expectations deserve an honest discussion. Most manufacturers assume that once the ERP project is complete, inventory accuracy will automatically improve, shipping delays will disappear, and reporting will become real-time. The conditions required for each of those three outcomes are quite different — and none of them can be achieved by installing software alone. Inventory accuracy requires data entry discipline. Even after ERP goes live, if the door to manual intervention stays open, the system gradually becomes contaminated. Shipping delays most often originate in the supply chain rather than production planning; ERP cannot manage that chain, it can only make it visible. Real-time reporting depends entirely on data quality. In the Konya case, the most debated issue during the first six months was reports that failed to reconcile — not because of the software, but because the same product code had been defined differently across departments. Without standardised product codes, reports are unreliable; that work must be finished before ERP is purchased.From a technical integration standpoint, there are a few things worth noting for metal manufacturing in 2016. Barcode-based work order tracking has reached a reasonable cost point; readers installed on the production line combined with simple terminal screens make operator-level data entry feasible. Mobile ERP access has become a practical option for warehouse and shipping teams — approving dispatch notes or checking shipment status from a tablet is no longer the exclusive territory of large-scale systems. But these technological possibilities need to be positioned as tools, not objectives, within the project design. In Konya, the barcode system was activated in month nine. The first eight months were spent on data standards and user habits. Had the barcode system been deployed in month one, it would have had no foundation to stand on.One more thing should be said plainly: this project succeeded because specific conditions were in place. Had the general manager not been an active participant, module-by-module resistance could have stopped the project in its first month. Without the production manager and the accounting director reaching agreement on data standards, product code alignment would have been impossible. Had the project manager been someone from inside the company rather than an external consultant, daily operational pressure and integration work could not have been managed in parallel. When any one of these three conditions is missing, field observation suggests that roughly 62 percent of comparable projects run over budget within the first six months — and most of that overrun comes not from software costs but from the process reconstruction work. ERP does not design the process. It carries a process that has already been designed. The manager who understands this from day one is the manager who finishes the project.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 2, 2016. The English edition has been reviewed and edited by the author.