When I walked into a mid-sized flour and pasta manufacturer in Konya last year, the owner had two requests: replace the existing accounting program with an integrated enterprise resource planning system — ERP for short — and finish the whole thing in six weeks. The company employed 312 people, ran eight product lines, and tracked inventory with handwritten stock cards. The owner’s urgency made sense. But I did not say yes in that first meeting. The most important thing field work has taught me is this: an ERP consultant creates value not from technical knowledge but from the ability to ask questions the client has not thought to ask yet. That one principle determines whether a project succeeds or quietly collapses under its own weight.ERP software is, in plain language, a business computer system that connects accounting, inventory, purchasing, production, and sales under one shared database. Think of it as replacing five separate notebooks kept by five separate people with one notebook that everyone reads and writes at the same time. One person’s entry immediately appears on everyone else’s screen. This sounds straightforward. It rarely is. In the Konya factory, the purchasing officer had spent years writing each supplier invoice by hand first and then re-entering it into a separate program. Nobody had questioned this double-entry habit because nobody had identified it as a habit worth questioning. I asked about it on day two. That question alone saved three weeks of configuration work later in the project.This is where the consultant’s real job begins — and it is not where most clients expect it. Companies starting an ERP project almost always ask the same question first: which software should we buy? The question that should come first is different: which of our processes must we fix before any software can help us? Skipping the second question to hurry toward the first is how ERP projects earn their reputation for running over time and over budget. In Konya, I spent three weeks on the analysis phase alone. I mapped not just the purchasing, production, and inventory flows but specifically where information stalled inside each one. The finding was straightforward but had never been measured: more than half of all purchase orders began as a spoken request between colleagues, and the time between that conversation and a written record ranged from two to four days. No one had counted this before because no one had thought it countable. A consultant in the analysis phase works less like a software specialist and more like a process detective.After the analysis comes the harder part: telling the client which habits must change. The factory owner wanted every purchase order to require approval from three separate people. His reasoning was reasonable — he wanted control. I showed him what that would look like inside the system: each order would sit waiting an average of two days, and when the approval chain backed up, the production floor would stop waiting for raw materials. We argued. In the end, a single approval covered routine purchases and a second sign-off applied only to orders above a set value threshold. That compromise looks small on paper. In practice, the time from order creation to confirmed receipt dropped by more than half compared to the old system, and the backlog of pending approvals shrank to near zero within the first month of go-live. A consultant who says yes to every client request never reaches that outcome. Saying no, said with a clear reason and a proposed alternative, is sometimes the most useful thing a consultant does.User habits deserve their own section because they are the part of every ERP project that gets the least preparation time and causes the most trouble after go-live. Introducing a new computer system to a team that has worked the same way for ten years is less like installing hardware and more like teaching a new language to adults who already speak perfectly well in their own. The warehouse supervisor had looked at stock cards every morning for years; now he needed to look at a screen. The accountant reached for the old program out of habit every morning for the first two weeks. These are not failures of intelligence — they are the natural friction of change. In Konya I divided the training into two phases: accounting and purchasing staff first, warehouse and production teams two weeks later. Sessions ran with five people at a time. I demonstrated on screen, had them take notes by hand, and deliberately let them make mistakes and correct them rather than correcting errors myself. One warehouse supervisor said in the first week that the program was smarter than him. By week three the same person caught a data entry error before I did. Training is not a presentation. It is a repeated practice, and the consultant who treats it as a one-afternoon event is setting up the client for a painful month after go-live.Integration points are the part of ERP projects that experienced consultants treat as a priority and inexperienced ones treat as a detail. In this factory, the accounting program ran separately from a production tracking spreadsheet, and bank statements were entered manually into a third file. When the new ERP system went live, these three separate information flows had to connect cleanly. For the bank data, we used an ODBC connection — a technical bridge that lets two programs share structured data without manual re-entry. For production tracking, rather than adding a separate module that the team would need ongoing support to use, we extended the existing inventory module in a way the internal staff could maintain themselves. That last decision reflects a principle I hold to in every project: the exit plan is as important as the entry plan. Before the project ends, the client must be able to run the system without the consultant standing behind them. Dependency that extends beyond go-live is not a sign of good consulting. It is a sign of incomplete work.The most common misunderstanding about ERP consultants is that deeper technical knowledge produces better project outcomes. Technical knowledge matters — without it you cannot configure the system or solve integration problems. But the variable that most reliably separates successful implementations from expensive failures is not technical depth. It is the willingness to spend real time on analysis before touching configuration, to say no to scope requests that will damage the final result, and to treat user training as the last mile rather than the last afternoon. The Konya project took eleven weeks instead of six. The system runs today. Purchase records are complete. Inventory is tracked on screen rather than on paper. The owner was impatient in weeks two and three and grateful in week eleven. Before your next ERP project begins, ask yourself one honest question: are you ready to buy software, or are you ready to fix your process? If the answer is only the first one, the software will not help you.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 29, 2002. The English edition has been reviewed and edited by the author.