The first three days a consultant spends in a textile label factory tend to follow a familiar pattern. The production manager opens a notebook, sits down, and starts listing. ‘We have ten different production techniques,’ he says. ‘Thermal transfer, woven, jacquard, printed flex…’ While you listen, a small alarm goes off somewhere in the back of your mind. Because each technique is not just a name — it represents a distinct raw material flow, a different work order logic, and a separate quality control checkpoint. ERP software does not see ten techniques. It sees three or four shared process patterns that happen to run across those ten techniques. The remaining six or seven live in an unnamed corner of the system, or they never make it in at all. At a mid-sized label manufacturer in Corlu — running woven, print, and thermal transfer lines simultaneously with 295 employees — I spent the final quarter of last year trying to answer exactly this question before a single configuration screen was touched: how many of these ten techniques could genuinely live inside ERP? The answer was six. And finding that six took the most valuable four weeks of the entire eleven-month project.Here is the thesis, stated plainly: implementing ERP in textile label production is not a test of whether the software understands your techniques. It is a test of whether you have decided which of your techniques can survive on digital data. Companies that skip this step almost always return six to nine months after go-live with the same complaints — ‘the system doesn’t see some products,’ ‘work orders won’t match,’ ‘inventory is inconsistent.’ When you trace these symptoms back to their root, the same cause appears every time: the system was configured without a process analysis. Three criteria determine whether a technique belongs in ERP: is raw material input measurable and repeatable; do the work order steps follow a standard sequence; and can quality control output be expressed as a number. Any technique that cannot answer yes to all three will remain outside the system’s field of vision, regardless of how many modules you purchase.At the Corlu factory, the needs analysis phase ran each technique through these three criteria one by one. The thermal transfer line passed every test: a roll of raw material in, defined heat and pressure parameters, output count, and waste rate — all of it transferable to the system without ambiguity. The jacquard woven line cleared the first two criteria but stalled on quality control. Colour alignment in jacquard design was evaluated as ‘good,’ ‘acceptable,’ or ‘reject,’ and converting that three-tier judgment into a measurable indicator required building a measurement standard in the workshop first. Writing those standards consumed four weeks of the eleven-month timeline. ERP did not create this problem, and it did not solve it either. It simply made a long-standing ambiguity visible. The factory had always known how to evaluate colour alignment; nobody had ever written it down. Before moving it into a system, it had to exist on paper.On the integration side, the practical obstacle that most textile SMEs in Turkey face in this period involves the connection between ERP and the mandatory e-Invoice and e-Ledger systems. The GIB-mandated e-Invoice framework and the ERP sales module can technically be linked, but the product coding specific to the label sector introduces friction that generic implementation guides do not mention. Label products are almost always produced to customer specification. This means each order carries a product definition that is slightly — or significantly — different from every other. Bridging the internal ‘custom production code’ in the ERP stock module with the standardised goods-and-services code that GIB requires for e-Invoice is not a one-time setup. It needs to be reviewed for each new customer segment. Firms that do not plan for this discover it in the first week after go-live, when they cannot issue an invoice. Management describes this as ‘the system is broken.’ The system is not broken. The configuration is incomplete.User adoption is almost always framed as a training problem. Give people enough instruction, the logic goes, and they will use the system. In a rhythm-dependent environment like label manufacturing, this framing is wrong. A thermal transfer operator opens an average of 73 work orders per shift, each tied to a production cycle of four to eight minutes. For that operator to update ERP at every work order, entry time must stay under 45 seconds; otherwise they stop entering and real-time production data stops flowing. At the Corlu factory, we tested this directly. The initial configuration produced an average entry time of two minutes and ten seconds. Bringing that down to 48 seconds required simplifying the user interface, mapping frequently used codes to shortcut combinations, and closing several fields with auto-fill rules. Without this optimisation, the database would not have reflected actual production. It would have reflected whatever the operator managed to enter during a spare moment — delayed, fragmented, and unreliable. The production efficiency figures reaching management reports would have been the product of neither the system nor reality.TCO (total cost of ownership) analysis in a multi-technique sector like label manufacturing can be genuinely misleading when standard calculation templates are used. Software licence and consulting fees represent only the first ring of the total investment. The real weight accumulates in the second and third rings. The second ring is process standardisation cost: for which techniques will measurement standards be written, who will write them, how long will that take, and how will operations be affected in the meantime. The third ring is data migration cost: the human hours and external support fees required to transfer existing product, customer, and inventory data — typically living in Excel files and paper records — into the new system. In the Corlu project, the combined cost of these two rings reached approximately 57 percentage points above the software licence value. In other words, the company spent roughly half again as much on process preparation and data migration as it spent on the licence itself. This ratio is not surprising. What is surprising is that it was not calculated in advance. Consultants who do not press on this question create a budget gap that surfaces mid-project, when the options for managing it have narrowed considerably.By the end of the eleven-month project, the production manager at that factory acknowledged that six of the ten techniques had been genuinely integrated into the system. For the remaining four, a bridge solution was built: a simple manual tracking form feeds consolidated data into ERP on a weekly basis. It looks like a half-measure. But those four techniques accounted for roughly eight percent of total production volume. Building full integration for that eight percent would have approximately doubled the project’s total cost. The return calculation did not support it. The decision criterion here is straightforward, but it is rarely stated out loud: carrying every technique into the system is not thoroughness — it is waste. Before your ERP project begins, ask yourself how many production techniques you have, and how many of them generate ninety-two percent of your output. That answer defines the real scope of your project. For everything else, find a simpler and faster solution — and make that decision at the start, not when the project has already consumed half its budget.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 14, 2017. The English edition has been reviewed and edited by the author.