I was working with a mid-sized textile manufacturer in Gaziantep when the scene stopped me cold. The software vendor had translated everything — menus, buttons, error messages, even the print headers on reports. The accountant could read every word on the screen. But she refused to enter data. ‘This program does not know our business,’ she said. She was right. Making software speak Turkish and making it understand how business actually works in Turkey are two completely different things. Confusing the two is the single most common reason ERP (enterprise resource planning — a system that connects all departments of a company into one platform) rollouts fail before they get started.My thesis is simple, and I think it is still widely misunderstood: ERP localization is three separate jobs, not one. The first is language — screens, reports, messages in Turkish. The second is regulatory compliance — the Turkish Commercial Code, the tax authority’s invoicing rules, the chart of accounts structure that local accountants actually use. The third is process fit — the real workflow of that specific sector, the habits of the users, the expectations of the owner. If you approach these three as a single task and finish when the menus are in Turkish, the project will hit a wall in the first week.In that Gaziantep factory — 284 employees across weaving, dyeing, warehouse, and accounting — the software vendor installed the system, ran a two-day training, and left a Turkish user manual. Within the first two weeks the system effectively stopped. The invoicing module did not support the sequencing rules that Turkish commercial practice required at the time. The accountant could not separate cash-sale invoices from term-sale invoices in the flow the program offered, and she said entering them the program’s way would break her reconciliation. She was correct. Fixing it required written correspondence with the vendor’s local representative, two rounds of fax exchanges, a face-to-face meeting, and three weeks of waiting. The problem was never the language. It was a module built without sufficient knowledge of how Turkish accounting actually works.Process fit is the subtler and, in my experience, the more damaging gap. It is invisible until something breaks. The stock module in that program tracked materials by product code. Reasonable design. But the warehouse clerk in Gaziantep identified every incoming roll of fabric by colour and bale number. When he said ‘Bale 47-B, red,’ he knew exactly what he meant. When the screen showed him ‘SKU-00391’ he drew a blank. He tried to memorise the codes for a week, gave up, and went back to writing everything in a notebook. That was not a training failure. It was a mismatch between the data-entry logic of the program and the real operational language of the warehouse. You have two options when this happens: adapt the process to the program, or adapt the program to the process. Either choice is defensible. Making neither choice and hoping the gap closes on its own is not.Needs analysis — the step where you document what the business actually does today before touching any software — is almost always rushed or skipped. The vendor’s team visits for a few hours, speaks with the manager, asks which modules are needed, gets a list, and leaves. The real information sits on the accountant’s desk, in the handwritten notes the warehouse foreman keeps, in the pricing logic the sales manager carries in his head. None of that surfaces in a two-hour meeting. In Gaziantep I joined the project after installation had already started. The first thing I did was sit with the accountant and go through every invoice type the company issued. There were four: cash, deferred payment, consignment, and sample. The program at baseline recognised two. Identifying that gap took one afternoon. Correcting it took months of back-and-forth with the vendor. Had someone done this analysis before the contract was signed, the correction would have been a specification item, not an emergency.Owner expectations are another pressure point that is rarely managed well. The owner expects that the day the program is installed, the reports will run and the business will become cleaner. This is understandable — he has paid for the software, he has given up two days of his team’s time for training, and he wants results. The accountant wants to see her old customer balances in the new system. The sales manager wants his weekly revenue report. Delivering all of this simultaneously on day one is not possible. In Gaziantep, migrating the old customer balance data alone took 6 weeks, because the same customer had been entered under three different name variations in the paper ledgers over the years. Until that was cleaned up, the accounts receivable module was unreliable. The distance between what the owner expects on installation day and what a realistic timeline actually looks like is one of the most consistent reasons projects stall halfway through.That Gaziantep factory eventually got the system running. The invoicing module was restructured to match Turkish accounting logic. The warehouse data-entry screen was adapted to the bale-and-colour system the warehouse team already used. And the owner accepted — after an honest conversation — that the first two months were a stabilisation period, not a results period. If you are planning a similar project, I have one question worth sitting with before you schedule the installation day: have you written down, word for word, exactly what this company does on paper today? If the answer is no, I would suggest postponing not the installation date but the contract signing date.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 11, 2001. The English edition has been reviewed and edited by the author.