Last month I worked with a textile company in Gaziantep. They had installed new software to handle their accounting and inventory. The computers were on the desks. The program was loaded. The authorized reseller had finished the setup and left. But when I walked into the office, I saw paper ledgers on the tables. The warehouse supervisor was still filling out handwritten stock cards. The accountant told me she used the program ‘sometimes.’ The company employed 312 people; roughly one in eight worked in the office. The number of people actively using the software was fewer than five. This picture was an exact copy of what I had seen at many firms across Turkey. The problem was not the software. The problem was that nobody had actually learned to use it.My argument in this article is simple: buying an ERP (enterprise resource planning) program completes less than half the job. The real work is getting people to make that software part of their daily routine. Think of it this way — a shopkeeper who buys a new cash register does not start serving customers before learning how to operate it. ERP is no different. Issuing an invoice, reducing stock, opening a purchase order — all of these require new habits. Those habits do not form on their own. They must be taught, repeated, and checked. A technician installs the software; a consultant gets people working with it. Mixing up these two roles pushes a project into trouble from the start.The first thing I did at that Gaziantep textile company was ask who was supposed to do what. Who enters incoming stock in the warehouse? Who opens purchase orders? Who closes the accounts at month end? These questions sound straightforward. But when I asked them, everyone looked at each other. Nobody knew for certain. The reseller had finished the installation without defining roles and responsibilities, and then moved on. Yet in any software project, the question of ‘who enters what, in which screen, and when’ must be settled before the setup is complete. I call this a ‘user map.’ Without that map, training becomes noise — everyone hears everything but nobody learns their own job clearly. At the textile company, we drew up the user map and started training from scratch with the same material. This time, each person learned their own piece of the work. Within three weeks, all stock entries had moved into the program.Another common mistake is treating training as a one-time event. The reseller or consultant comes in for a day, explains things for two hours, and leaves. The handouts stay on the table. The screen goes dark. Two days later, nobody remembers what was covered. The truth is that an adult needs to repeat a new task at least four to six times before it becomes a habit. At the Gaziantep company, we held six sessions spread over three weeks. Each session ran between forty-five and sixty minutes. We always began by reviewing the work done in the previous session, correcting mistakes together, and then moving on to the next topic. Running training this way — in short, spaced intervals — turns the software from ‘something distant’ into ‘the tool I use every day.’ Yes, this approach takes time. But it costs far less than returning to the same firm six months later because the staff drifted back to paper. Cutting training short to save money is, in my experience, the most expensive mistake a project can make.What about the managers? The owner or department head’s attitude toward the software shapes how staff use it, directly and immediately. If the owner still asks for paper reports, staff will not bother learning to generate reports from the program. If the manager keeps saying ‘send me an Excel file,’ the accountant will never open the reporting screen. I saw this at a food wholesaler in Izmir. The company owner had embraced the new accounting software, but the warehouse manager was still printing out the stock list on paper every evening. Why? ‘Because the boss wants it this way,’ he said. When I asked the owner, the answer was: ‘I don’t know the program, so I can’t check it.’ This is a critical point. Managers do not need to operate the software themselves — but they need to know it well enough to say ‘check the program.’ A short, focused introduction for them makes the rest of the project much easier. At the Izmir company, I spent one afternoon with the owner, covering only the stock view and summary report screens. The next day he told his team to stop bringing him paper. The warehouse manager opened the program the following morning.One more thing worth saying: the same training does not work for every firm. A team of eight in an accounting office and a warehouse with over a hundred staff members need different paces and different methods. With small teams, working one-on-one is practical. With larger groups, the more realistic approach is to train one ‘key user’ first and then position that person as an internal trainer. The key user should be someone who picks up the program quickly, is willing to answer colleagues’ questions, and is trusted within the team. Choosing the right person matters. At the Gaziantep textile company, we identified a young woman in the accounting department as the key user. Over the three-week process, she learned her own work and helped the two colleagues sitting beside her. After the project ended, when new questions came up, the firm did not need to call me — she handled them. A consultant’s job does not finish at handover; it finishes when the firm can walk on its own. Buying the system is a starting point. Getting people to use it is the actual work. Confusing the two wastes time and money for everyone involved.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 23, 2003. The English edition has been reviewed and edited by the author.