Here is a paradox worth examining: as enterprise software budgets grow in Turkey, complaints about customization keep growing alongside them. A company purchases an ERP system, then six months later says ‘it did not fit us,’ and dozens of custom .NET modules get deployed. Three years pass. Maintenance costs exceed license costs. Upgrading to the next version becomes nearly impossible. By 2013, this scenario is not an exception in mid-sized industrial firms — it has become something close to a standard story. The source of the problem is not the quality of the ERP package or the choice of .NET. The real issue is simpler and harder to fix: requirements analysis never concluded before the project started. The purchase decision was made, the consultant sat down for technical design without seeing real shop-floor processes, and the development team wrote whatever the client asked for. The resulting system runs — but nobody asks the more important question: ‘Were these processes correct in the first place?’At a mid-scale machine manufacturer in Kayseri — 312 employees, producing mostly lathe and milling equipment, directing roughly half of its export volume toward the Middle East — the right conditions emerged to ask that question seriously. The firm initiated a consulting engagement eight months before its planned ERP go-live. In the first session, the production manager said: ‘The inventory module does not work — we run material requirements planning in Excel.’ The reflexive response would have been to treat that sentence as a software problem. It was not. The firm’s production orders ran across four different paper formats. Each shift supervisor maintained a personal ledger. Scrap figures leaving production never fully reached accounting. The problem was not the inventory module; it was the absence of any disciplined data entry habit. If the ERP had gone live without touching this layer, the new system would have become a digital copy of the old chaos.Requirements analysis at this point surfaced a distinction that matters enormously in hybrid projects: the difference between process problems and structural gaps. A process problem is solvable within the system — existing steps are simplified or resequenced and carried into configuration. A structural gap, by contrast, must be resolved before the software can function at all — and the resolution requires an organizational or policy decision, not a technical one. In the Kayseri case, scrap recording, shift handover, and material approval flows all fell into this second category. More than three weeks were spent running workshops on these three points alone, with the production manager, shift supervisors, and the procurement lead in the same room. Only after those sessions produced a written, agreed-upon process definition did ERP configuration decisions follow. Without that document, deciding what to write in .NET is genuinely impossible — because you do not yet know which data you need.In ERP plus .NET hybrid design, the most common mistake is leaving the boundary between the two layers undefined. What does the ERP package handle? Standard processes, accounting integration, reporting infrastructure, and database integrity. What does the .NET layer handle? Industry-specific business rules, reporting interfaces, or integration bridges that the ERP cannot solve — or would require disproportionate license and configuration cost to accommodate. The boundary is that clear. In practice, it rarely stays that way. A production monitoring screen that already exists in the ERP gets rewritten in .NET because ‘the interface was not liked.’ An order approval flow that could be built inside the ERP’s workflow engine becomes a custom .NET service because the consultant is not fluent in that module. Each such decision quietly increases the total cost of ownership (TCO). The invoice usually arrives three years later, at the next version upgrade.In a textile export firm in Gaziantep I encountered the opposite pattern. The company had started its .NET project before completing ERP setup — a classic ‘run both tracks simultaneously’ decision. The .NET team wrote against a data model that was not yet finalized. When the ERP went live, tables were renamed and field names changed; 46 queries on the .NET side stopped working. Repairing those 46 queries consumed an effort that would never have existed had the sequencing been correct from the start. The estimated cost: roughly four months of development capacity, redirected from new features to damage repair. The lesson here is managerial, not technical: parallel development is safe only when the dependency map is fully defined and the ERP data model is frozen. Otherwise, a change on one side topples the other like dominoes.How did this understanding translate into concrete decision criteria in the Kayseri engagement? Three rules were formalized at the project outset. First: .NET development does not begin until the ERP configuration is complete and has produced at least four weeks of data in a live environment. Second: every module to be written in .NET must carry documented proof that no standard ERP equivalent exists; if an equivalent is available, adopting the standard module is mandatory. Third: all .NET services operate through a published data layer exposed by the ERP; direct table access is prohibited. Over the following 11 months in production, these three rules visibly prevented two critical maintenance incidents. The support team confirmed that ERP update patches did not break the .NET layer because every service’s dependency on a specific ERP object was visible in documentation before any change was applied.To a manager about to start an ERP plus .NET hybrid project, the first conversation I would ask for is not about technology selection, license comparison, or integration architecture. Put two documents on the table first. The first is a process map — not the idealized version, but what actually happens, not how the system is supposed to work but how people work around it today. The second is a structural gap register — a clear separation of which problems require a software decision and which require an organizational one. If those two documents do not exist, the architecture meeting should be postponed. Without them, even a technically sound design ends up serving the underlying disorder. Three years later, the complaint arrives: ‘The system did not fit us.’ The system did exactly what you asked. The problem was that you did not yet know what you needed when you started asking.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 29, 2013. The English edition has been reviewed and edited by the author.