Picture a medical device company running an authorized service network across Turkey: offices in Istanbul, Ankara, Izmir, Adana, and Erzurum, with 284 field technicians visiting hospitals, clinics, and imaging centers every day. The central office learns what those technicians completed — and which spare parts they consumed — only through afternoon telephone reports. Management’s demand for an ERP system looks entirely reasonable from the outside. But look behind that demand, and the real problem is not missing software; it is that the work order process runs differently from branch to branch. ERP does not resolve that inconsistency — it merely records it. My argument is this: in field service networks, ERP deployed before process standardization produces nothing more than an expensive data archive.Field service operations present a structurally different challenge from classic inventory or finance ERP projects. In manufacturing, the process is fixed — the assembly line does not change, the invoice flow is predictable. In field service, the process travels with the technician’s toolkit. A technician in Istanbul may receive a work order on a tablet and pull parts from a small stock kept in the service vehicle. His colleague in Erzurum writes the same work order on paper and faxes it to headquarters on Friday. Both approaches can technically be captured in the same ERP screen, but you must first decide which one is correct before you touch configuration. As an implementation consultant, driving that decision before software selection is the single most critical phase of the project. When that decision is deferred, configuration layers pile on top of each other and project costs swell in ways no one anticipated during the tender process.The first real difficulty facing multi-branch service networks in Turkey when they enter an ERP project is determining whose voice shapes the requirements. Central management wants visibility: where is each technician, which work orders are open, what does spare-parts inventory look like right now. Regional managers want speed: open a work order faster, move without waiting for approval chains. Technicians do not say it aloud, but they want fewer forms to fill. These three demands contradict each other directly. The centre needs data for visibility; data requires forms; technicians avoid forms or fill them incorrectly under field conditions. Whichever of these three demands you place at the centre of your ERP configuration, you make it easier for the other two groups to abandon the system. In field service ERP projects, user resistance is the leading project risk — not the software.By 2012, mobile ERP access is no longer a technical aspiration; ERP clients running on Android and iOS tablets are a genuine option for field teams. Yet mobile access solves the connectivity problem, not the process problem. In a comparable project I worked on with a medical device service company, technicians initially began closing work orders through their tablets. Three months in, the work order closure rate stalled at 57 percent instead of the targeted 91 percent. The gap did not appear in system logs; it surfaced on-site. Some hospitals restricted tablet entry under security protocols. Others had technicians leave mandatory fields blank — ‘I do not know yet’ — and defer closure, which pumped dirty data into the system at a growing rate. A mobile ERP decision made without simultaneously designing the exact form layout and the maximum number of steps required in the field has no operational meaning.Integration points are where unexpected cost and delay accumulate in these projects. For a medical device service network, three integrations are critical: the real-time connection between the spare-parts inventory module and the field work order module; the synchronisation of customer records — hospitals and clinics — with CRM or the master customer database; and the automatic verification of contract or warranty status the moment a work order is opened. If any one of these three is incomplete, technicians consume the wrong part in the field, close billable work orders as warranty, or re-diagnose a problem they would have recognized immediately with access to service history. The majority of multi-branch service companies in Turkey request ERP proposals without including these integration points in the budget; they reappear later as ‘additional module’ or ‘custom development’ line items. Total cost of ownership (TCO) then exceeds the original approved figure by a margin that rarely surprises the consultants but consistently surprises the steering committee.Senior management expectations deserve a separate paragraph. Executives who approve an ERP project typically hold two expectations: first, ‘we will finally have real-time reports’; second, ‘the field team will stop filing paper forms.’ Both expectations are legitimate — but neither materialises in the first six months. Real-time reporting only becomes meaningful once data quality reaches a threshold; data quality only improves as user habits stabilise. Paper form elimination rarely happens abruptly; parallel operation — the old paper process running alongside the new system — is unavoidable for roughly three to six months. Measuring a field service ERP project’s success at month twelve rather than month eighteen is the most common reason ROI calculations fail. Setting this expectation clearly with management at project launch feels uncomfortable in the moment. It feels considerably less uncomfortable than sitting in a steering committee meeting at month fourteen discussing whether to shut the system down.For any executive considering an ERP deployment across a nationwide field service network in Turkey, three concrete questions are worth asking before signing a contract. First: does a technician in your Izmir branch close the same type of service call using exactly the same steps as a technician in your Ankara branch — or does each branch follow its own ‘this is how we do it here’ routine? If the answer is the latter, resolve the process divergence before touching ERP configuration; the software will not close that gap, it will calcify it. Second: during the portion of a field technician’s day spent on-site at hospitals or client premises, have you tested at which point they can realistically enter data into a system — and whether customer security policies might block a tablet entirely? Third: is your spare-parts stock managed centrally, drawn from regional warehouses, or carried in service vehicles — and is that structure compatible with the default inventory logic of the ERP module you are evaluating? If you have clear answers to all three questions, both your software selection and your implementation plan will sit on solid ground. If you do not, there is no urgency in signing a project contract. Spending one week in the field with your technicians before the project begins is the best possible use of the first portion of any implementation budget.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 14, 2012. The English edition has been reviewed and edited by the author.