It was a flour and pasta manufacturer in Konya, central Turkey — 284 employees, two production lines, and a warehouse supervisor who started every morning by looking at a handwritten list and calculating stock in his head. The accountant worked through a pile of invoices at the end of each month, entering each one by hand. Neither of them saw this as a problem. It was just how things worked. When I arrived to install the ERP (enterprise resource planning) system, my first instinct was to focus on the technical setup. I was wrong about that from the start.An ERP system brings together different parts of a business — accounting, stock, purchasing — into one shared software platform. Information that used to travel on paper enters the system once, and everyone sees the same number at the same time. It sounds straightforward. In practice, nothing about that project was straightforward. The technical installation took two weeks. The full project ran for eight months. Most of those eight months were spent not on software, but on people.My argument here is blunt: ERP projects fail not because of the software, but because the company never built the habit of keeping clean records in the first place. If stock has never been counted consistently, if invoices sit unprocessed for days, if supplier information is scattered across different scraps of paper — then installing even the best program available will only make the mess more visible. A computer records exactly what you put into it. Bad data in, bad reports out. Understanding this was the single most important thing that first project taught me.In the first week at the factory, I found that the accountant had entered the same supplier under three different names. One entry read ‘Karadeniz Gida’, another ‘Krdnz Gida Ltd.’, a third simply ‘Karadeniz’. All three were the same company. The system treated them as three separate suppliers. When the manager pulled a supplier payables report, the numbers did not add up. He called me over: ‘There is a bug in the program.’ There was no bug. There was a data entry inconsistency that had been sitting unnoticed for years. Cleaning up just the supplier records took three full days. And that was a small piece of the overall problem.The warehouse presented a different issue. The last full stock count had been done about eighteen months earlier. Some items sitting on the shelves had no record in the books. Some items listed in the records were not on the shelves at all. Before entering anything into the system, I needed to know what was actually there. If we entered wrong figures, the system would generate wrong purchase recommendations. The factory manager framed this as a software problem. It was not. The physical stock and the paper records had never matched properly — that gap had simply been tolerated. The program made it impossible to ignore. Blaming the software was easy. Explaining this clearly to the manager was harder.User resistance was a separate challenge entirely. The warehouse supervisor refused to open the program in the first week. ‘I have been doing this job for twenty years,’ he said. ‘Why would I need to look at a screen?’ That was a reasonable kind of pride. But the entire warehouse operation lived inside his head. What would happen if he were sick for a week? Management had never asked that question. The program forced them to. I did not argue with him about it. Instead, I sat next to him for a week and entered his own handwritten lists into the system together, line by line. When he saw that the program’s numbers matched his paper, he started to trust it. By the second week, he was opening the system himself. The lesson was simple: resistance usually comes from fear — specifically, the unspoken question of whether the system will make the person irrelevant. No technical explanation addresses that fear. Sitting next to someone and working through their own data does.On the management side, the expectations were different again. The owner had commissioned the system and wanted to see ‘the reports’ by the end of the first month. Which reports? Stock levels, supplier balances, monthly cost summary. All of those were technically available. But they were not yet meaningful. Meaningful comparisons require at least a few months of accumulated data. I told him this directly: ‘You are seeing accurate numbers now, but to compare this month against the previous one, we need at least three months of history in the system.’ He did not want to hear that. But it was true. By the end of the third month, the monthly cost comparison showed something he had never noticed before: the factory was buying the same raw material from two different suppliers, and one was charging roughly fifty-seven percent more than the other. He had been paying that difference for years without knowing. That was the first moment the program demonstrated real value to him — not in the installation, but in the data that had finally been cleaned and accumulated.That project left me with three things I still believe are true. First, needs analysis comes before software selection. Which information lives where, which process runs on paper, which person carries critical knowledge only in their own head — all of this must be mapped before any installation begins. Skipping this step is like building walls before laying a foundation. Second, data cleaning is the least glamorous and most necessary part of any implementation. Supplier names, product codes, stock counts — if these are entered into the system without being verified, the manager will stop trusting the software within three months, usually permanently. Third, every user needs to be shown specifically what the system does for their own work. General presentations about efficiency do not build trust. Sitting down with someone’s own numbers does.On the last day of the project, the warehouse supervisor said something that stayed with me. ‘I did not want this program when you first came,’ he said. ‘Now I wish I could check the stock before I even get to work in the morning.’ Remote access to a system from home was not something available in a factory like that at the time — but the feeling behind the words was real. The program had become his tool, not a foreign object someone else had installed. That is the clearest sign that an ERP project has actually worked: the moment a user stops thinking of the system as the consultant’s problem and starts thinking of it as their own.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 20, 2001. The English edition has been reviewed and edited by the author.