Why does adding more modules make the project run longer? A machinery manufacturer in Eskişehir — a mid-sized industrial equipment producer with 284 employees serving both domestic and export customers — found itself asking exactly that question. Contracts had been signed, software licenses purchased, the project officially launched. Yet eleven weeks in, every single meeting still opened with the same question: ‘How exactly do you handle this today?’ That question looks innocent. In practice, it is the most dangerous early warning sign a system implementation project can produce.My position is clear from the outset: when building from zero, process maturity determines success far more than software selection. Many sales managers and ERP consultants push back on this — ‘good software brings good process with it,’ they say. That is not wrong, but it is incomplete. Good software systematizes a defined process; it does not invent an undefined one from scratch. In the majority of Turkish SMEs, production, sales and procurement workflows are not formally documented — they live in the heads of senior employees. Enter a project without recognizing this and the implementation transforms into a process discovery expedition, with the integrator’s invoice running the whole time.In the Eskişehir case, the underlying problem was this: production planning, stock reservation and purchase approval logic worked three different ways in the minds of the factory manager, the procurement officer and the CFO. Who approved what, under which conditions a purchase request locked to a sales order, at what production stage semi-finished goods entered the accounting ledger — none of this existed in writing. The company had operated this way for fourteen years and things ‘worked.’ But the gap between ‘working’ and ‘documented, measurable operation’ is precisely what produced those eleven weeks of circular meetings.At that point the project structure had to change fundamentally. While software installation continued, a parallel process mapping exercise was initiated. A four-day intensive workshop was held with one representative from each of the four departments: production, sales, procurement and finance. The output was not a slide deck — it was simple flow diagrams showing ‘how it works now’ versus ‘how it should work’ for every key process. Without those diagrams, the software team had no basis for setting configuration parameters. The platform’s flexibility, marketed as an advantage, was actually amplifying the ambiguity: every configurable field reopened the question ‘how do you want this to work?’Once the process maps were in place, implementation speed increased noticeably. After purchase approval steps were defined, the ERP approval-flow module was configured in three days — the same topic had been in open discussion for six weeks prior. On the finance side, e-Invoice (e-Fatura) integration had already been prioritized because of GİB mandatory compliance requirements, but the accounting team had no consensus on which cost center to tie to which order type, so the finance module had been sitting idle. With the process clarified, that integration was completed in two weeks. The project ran fourteen months in total against an original nine-month estimate. The extra five months were spent almost entirely on process discovery, with a smaller portion on technical revision cycles. A pre-project process maturity assessment would have recovered most of that time and cost.So what is the core lesson? Before signing an ERP contract, I recommend asking one question: can every step from purchase request creation to payment approval be described in a written document right now, or does that knowledge exist only in two people’s heads? If the answer is the latter, the highest-value investment before software selection is a three-to-four day process mapping workshop. The cost is a small fraction of a single software license; the probability of preventing project failure is substantial. A wrong software choice can be corrected later by switching platforms. Undefined process creates a recurring daily invoice after go-live — reports produce inconsistent outputs, stock closings do not reconcile, accounting and production operate in parallel realities that never meet.The Eskişehir manufacturer did eventually go live. Production orders were linked to sales orders, purchase requests entered an approval workflow, e-Ledger (e-Defter) GİB compliance was achieved and field teams gained real-time stock visibility through mobile access. An internal measurement six months after go-live showed order fulfillment time had shortened by 46 percent — a result attributable to process clarity, not to any particular software capability. If the management teams reading this are still starting with the question ‘which ERP’, I would suggest asking ‘are our processes documented’ first. Signing a software contract before getting that answer is drafting architectural plans on land without a foundation survey.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 26, 2017. The English edition has been reviewed and edited by the author.