Manufacturers in the building materials sector who attempt to run ERP and CRM implementations simultaneously tend to finish with both systems half-configured and neither delivering reliable data. This is not a theoretical risk — it is a pattern I encountered across consecutive projects in Turkey. One case that crystallised this clearly was an eight-month engagement with a ceramic tile and plasterboard producer based in Kutahya, with 312 employees across production and sales functions. The firm wanted to modernise its dealer relations management, its production order tracking, and its financial reporting in a single initiative. By month four it was apparent that the three agendas were cannibalising each other. The real question in any such project is not whether to implement both systems, but which process must mature first before the other can stand on it.Building materials is a sector that makes the ERP-CRM intersection particularly complex. On the production side you have raw material intake, product recipes, yield loss tracking, and shift scheduling. On the customer side you have a regional dealer network with differentiated payment terms, seasonal campaign management, and volume-based rebate calculations. Even a basic ERP covering finance and inventory must connect these two worlds at the data level. When CRM is layered on top — bringing dealer visit logs, quotation conversion tracking, and customer segmentation — the configuration decisions multiply fast. Who owns the dealer code? Does the customer record in CRM inherit the debtor record from the general ledger? What happens to outstanding receivables when a dealer is reclassified? In the Kutahya project, none of these questions had been answered before go-live was scheduled, and each one surfaced as a blocker at a different point in the implementation.The pressure that produces this situation is entirely understandable in the Turkish SME context. Decision authority is concentrated at owner or general manager level. When the sales director and the production manager both arrive with their systems wishlist, the owner wants both resolved in one budget cycle, with one consulting firm, on one project timeline. The consulting partner, reluctant to push back on scope, includes both workstreams in a single contract. The project formally covers everything; the team’s actual capacity covers far less. In Kutahya, the configuration team was three people: one from the software vendor, one internal IT coordinator, and one part-time business analyst on loan from the finance department. Splitting that capacity across production order management, dealer master data, and accounts receivable reconciliation simultaneously meant that none of the three received the sustained attention needed to stabilise user behaviour. Data entry standards were inconsistently applied; dealer codes and customer accounts were mapped incorrectly in roughly a third of cases; production close-outs were being done partially in the system and partially on paper. By month nine there was no single output from which reliable management decisions could be drawn.The corrective step taken in Kutahya illustrates the principle clearly. CRM activity was suspended for six weeks. The team concentrated exclusively on production orders, stock movements, and the bank-cash reconciliation cycle. Once those processes were producing consistent data, the dealer master records could be cleaned and aligned against the general ledger customer list with far less effort than would have been required in a messy parallel state. The measurable outcome: average order fulfilment time fell from nine working days to five, and dealer-level yield loss cost was reported accurately for the first time. Both of these were precisely what the owner had listed as priorities in the original project brief. Neither was achievable without the other being stable first — but the sequence in which they were approached determined whether both could be reached at all.One important qualification is necessary here. The argument for sequencing ERP maturity before CRM activation does not apply universally. If a manufacturer is entering a high-pressure selling season with a fragile dealer network and competitors actively courting its key accounts, early CRM visibility may be strategically non-negotiable. In that scenario, the right answer is to open CRM in a minimal configuration — dealer contact records, visit logging, basic pipeline tracking — and run ERP on a separate, slower timeline. What must be avoided in either case is attempting to connect the two systems through shared data structures before either is producing clean records. Integration at the data layer should follow data maturity, not precede it. This distinction between ‘running two projects in parallel’ and ‘integrating two systems simultaneously’ is one that project sponsors in Turkey rarely hear clearly articulated before they sign the contract.For building materials manufacturers approaching a similar decision, three practical steps apply from the outset. First, prepare separate scope documents for ERP and CRM with separate data owners assigned before any vendor is selected; a single project document with a shared workplan makes capacity gaps invisible until they become crises. Second, resolve the dealer code and customer record matching logic on paper — using a spreadsheet or even printed lists — before either system is configured; this reconciliation done after go-live consistently takes three to four times longer than doing it beforehand and generates errors that persist for months. Third, define success criteria for the first six months exclusively around financial module accuracy and production order completion rates; sales analytics built on a correct financial foundation will arrive faster and more reliably than one pursued in parallel from a dirty data baseline.The building materials sector in Turkey carries enough structural complexity — seasonal demand peaks, regional dealer dependencies, raw material cost volatility, and tight working capital cycles — that an enterprise software project cannot afford to absorb avoidable implementation friction on top of that reality. The Kutahya team lost roughly five months to confusion that was created at the project design stage, before a single line of configuration had been written. The firms that come out of these projects with usable systems are not necessarily the ones that chose better software. They are the ones that asked the harder question earlier: which process, if left unreliable, makes every other output meaningless?
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 5, 2010. The English edition has been reviewed and edited by the author.