Installing ERP (Enterprise Resource Planning) software does not automatically fix a broken process. When I say this, most managers look surprised. The software vendor delivers a polished presentation, hands over a reference list, and you assume that once the program is installed everything will fall into place. What I see in the field is usually different. The system goes live, but the earlier chaos simply moves faster. That is precisely why I am writing this: the Burgmann project made me live that reality firsthand.The company was a mid-sized manufacturer based in Bursa, with 167 employees, producing machinery parts and sealing elements. It also had a trading arm, handling domestic sales alongside export orders. Two distinct operations ran in parallel: the factory side managed production orders, raw-material receipts, and semi-finished goods tracking; the trading side managed customer orders, invoicing, and collections. Each side ran on its own paper forms, its own ledger books, its own accounting entries. When management said ‘we want to see everything from a single point,’ the project began. It sounded entirely sensible. But as soon as I got inside the work, I realised the situation was considerably more tangled than it first appeared.Before the project formally started, we held a standard requirements meeting. The accounting manager, the sales coordinator, the factory foreman, and the general manager all sat at the table. Each person wanted something different. The accounting manager said ‘I want to track invoices.’ The factory foreman said ‘I want real-time visibility into raw-material stock.’ The sales coordinator said ‘I want to see customer balances quickly.’ The general manager said ‘I want a profit-and-loss summary on my desk every morning.’ Every one of those requests was legitimate. But nobody in that room asked ‘how do we actually do these things right now?’ I had to ask. The answers were revealing: each department recorded data in its own notebook, according to its own rules. There was no shared recording system. The warehouse keeper entered incoming materials in one ledger; accounting posted the same movement to a separate card. The same item appeared in two places with two different quantities.This is where the critical decision point arrives. Before touching the software, the recording rules had to be agreed upon. If we had launched the ERP installation without doing that work first, the program would have collided two conflicting data streams and management would have received contradictory reports. I have seen exactly that mistake in similar projects. A factory manager once told me: ‘We installed the system and every report shows a different number. We no longer know which one to believe.’ The program was not at fault; the data fed into it was inconsistent. This is the clearest proof that software cannot perform miracles. Software gives you faster, more organised information — but for that information to be correct, you must first decide what to record and how to record it.On the Burgmann project we did not ignore this problem. We spent the first six weeks on data and process cleanup. We defined which items would enter the system under which names. We simplified the raw-material receipt form so that the warehouse keeper and the accountant used the same item code. We deduplicated the customer master: the same customer appeared in some records as ‘Koc Makine’ and in others as ‘Koc Mak. Ltd.’ The program would have treated those as two separate customers, and collections tracking would have collapsed entirely. This cleanup looked tedious, but it was the most important work done before any module went live. In the field, I have seen most companies that skipped this phase either abandon the system a few months after installation or say ‘it was useless.’ The problem was never the program.Once the software was installed, we ran into another unexpected obstacle: user habits. The warehouse coordinator had kept the same ledger book for ten years. When the program screen appeared in front of him, he continued writing in his notebook alongside it. ‘I entered it on screen already, I will also write it down, no harm done,’ he said. That is a deeply human reaction. Trusting something new takes time. Breaking the habit required a clear management position: ‘From now on the program is the only record. Nothing goes in the notebook.’ The double-entry continued until the general manager stated this explicitly at a staff meeting. The success of a software project very often depends not on the technical installation but on exactly these kinds of management decisions.In the end the project reached the results management had wanted, though it took longer than anyone initially forecast. Stock discrepancies fell sharply within the first three months. Collections tracking improved; the accounting manager could answer ‘who owes how much’ on the same day. Matching invoices against dispatch notes (the document confirming goods have been sent) moved from a manual daily task to a system-generated check. These were real, tangible gains. But reaching them required a specific sequence: first understand the process, then simplify it, then move it into the program. The order mattered.If you are about to start a similar project today, here is my suggestion: before you install anything, spend two weeks asking only process questions. Who writes what, where, and when? Who receives what from whom? Which document triggers which step? Once you write the answers down, the order in which modules should go live becomes obvious on its own. Managers in a hurry say ‘let us install it first and fix it later.’ But fixing things later always costs more than getting them right at the start. The Burgmann project taught us that. A program installed on top of confusion does not reduce confusion — it gives confusion a faster engine.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 5, 2002. The English edition has been reviewed and edited by the author.