They never used it. The system was excellent; every module had been configured, data had been migrated, training had been delivered. Yet eight weeks after go-live at a 312-employee metal fabrication and machinery manufacturer in Konya, most of the shop floor was still consulting old Excel sheets, and some staff had quietly returned to paper forms. The project consultant said there were no technical issues. The HR manager confirmed that training was complete. So where exactly was the problem? Right there, in the blind spot that most ERP projects would rather not look at: the software was ready, the people were not.In digital transformation literature, the phrase ‘human factor’ gets mentioned frequently, yet it almost always functions as a footnote — something remembered after the technical scope has been signed off. The underlying mistake is this: mindset change is not a separate problem to be solved by a change management program bolted on at the end; it is the project itself. Any project structure that treats these two things as sequential is building its own failure into the design phase. This sounds obvious, but the pattern across hundreds of ERP implementations in Turkey is remarkably consistent: the overwhelming share of the budget flows toward licensing, infrastructure, and technical consulting, while change management gets a marginal line item, if it appears at all.Turkey’s context in 2022 sharpens this problem considerably. Under record inflation, procurement decisions are already under pressure; for a mid-sized manufacturer, cloud ERP subscription costs are denominated in foreign currency and shift every month. In this environment, the management board feels intense pressure for the system to ‘work immediately,’ but paradoxically that same pressure shortens the time and budget allocated to change management. The ‘get results fast’ reflex takes over: modules are pushed live on a compressed timeline, user readiness is substituted with a few town halls instead of a systematic program. In the Konya firm, that was precisely what happened: the final four months of a fourteen-month project plan had been squeezed into six weeks under currency pressure and management impatience. The technical schedule held; the human schedule never started.How does habit change actually work? The core insight from behavioral science is this: an established habit does not change through new information; it changes through new repetition. A training session that teaches ‘click this button now’ does not rewire the muscle memory of an accounts payable clerk who has spent five years entering the same Excel column. Change happens when that person repeats the new behavior inside their actual workflow, when errors are corrected in a safe environment, and when the body learns that the new system is less effortful than the old one. That process takes months, not days. Here is the practical rupture point most projects miss: standard training teaches the system, not the job. A warehouse supervisor may know how to enter a purchase order in the ERP. But when a supplier delay complaint arrives, does she know which module to navigate, how to flag it in the system, and what output to present to her manager? Training teaches clicking; it does not teach the workflow. That gap is precisely the line separating the employee who uses the system from the one who routes around it.Resistance management is usually misdiagnosed. The phrase ’employees are resistant to change’ is, in most cases, a polite way for management to externalize its own communication failure. When you look at the actual sources of resistance, the picture is different: fear of uncertainty (what happens if I make a mistake in the new system?), status anxiety (I was the expert in the old system; in this one I am a beginner), and workload perception (right now I am carrying both the old job and the new system — is this temporary?). None of these three sources can be resolved by a meeting or a message telling people not to resist. At the Konya firm, a late-stage intervention that addressed exactly these sources produced a measurable shift: one ‘system champion’ was designated per department, those individuals were given protected time and tools to support their teams, and errors during the first six weeks were treated as learning data rather than performance failures. System utilization climbed from twenty-three percent to seventy-one percent within eight weeks. Not a single line of code had changed.A real caveat belongs here: the system champion model does not produce the same result in every organization. For it to function, two conditions are non-negotiable — visible, consistent sponsorship from senior leadership, and genuine time protection for the champions themselves. A champion operating under the unspoken expectation of ‘keep your production targets and teach the system’ has almost no room to do either well. In Turkey’s SME ownership culture, the owner’s implicit expectations routinely override formal role definitions; any change program designed without confronting that reality will look excellent on paper and collapse on the factory floor. Before designing a competency development program, the question that must be answered is: what does this owner actually reward, and what does she make invisible? That answer reveals the real architectural constraint of the program.Return to that Konya factory. Today the system runs; inventory discrepancies have dropped by forty-eight percent, and delay notifications are now generated automatically from the ERP. But reaching that outcome required an unplanned change intervention four months after go-live, which added cost and delay that nobody had budgeted for. The result is good; the process was unnecessarily painful. The lesson is not subtle: leaving change management until after technical delivery is as rational as calling the fire brigade after the building is complete. Before approving the software budget at your own company, ask two questions plainly. Does the organization have the institutional resolve to protect the change timeline against ownership impatience? Is there a project sponsor with enough standing to hold that line? If honest answers to both are not immediately available, the software decision can wait a little longer.
This article was originally published in Turkish by Gökhan MERCANOĞLU on May 9, 2022. The English edition has been reviewed and edited by the author.