Before an ERP project begins, one question must be answered honestly: does this sector actually have a standard process? In manufacturing, the answer is almost always yes — assembly sequences, inventory movements, purchase cycles are all defined and repeatable. In a hotel, a hospital, or a professional services firm, ask the same question and you quickly discover that nearly every step — from guest request to service delivery, from staffing a shift to closing the day — varies by person, by capacity, by season, and sometimes by hour. This is exactly where most ERP projects in service-intensive industries collapse: software is activated before operations are mapped on paper, and the system becomes an expensive record of chaos rather than a tool that reduces it.That claim deserves unpacking, because the problem is not simply one of project management methodology. In a service business, the concept of ‘process’ carries a fundamentally different meaning than in manufacturing. A textile factory in Gaziantep can describe the path from raw fibre to finished fabric in precise, measurable steps that can be optimised and repeated. A large resort property on the Aegean coast managing daily operations with 284 staff is solving a continuously shifting equation — morning occupancy changes, an afternoon group booking arrives, an evening private event is added. ERP works in this environment only under two conditions: either the process skeleton is clarified before software is deployed, or the project team includes someone who genuinely knows service operations from the inside. Without at least one of these, the project typically stalls at the accounting module and never moves further.In practice, the pattern I encounter most often looks like this. A general manager or owner has attended a trade fair demonstration, been convinced by the promise of seeing the entire business on a single screen, and launched the project. The needs analysis phase is either skipped entirely or delegated to the vendor’s standard questionnaire — a form designed around manufacturing and trading businesses, full of questions about bill of materials, production recipes, and shift scheduling. The questionnaire gets filled in, a requirements document gets written, and nothing specific to the property ever makes it into that document: real-time tracking of guest requests, maintenance work orders, inter-restaurant stock transfers, room status updates. The gap between what the document promises and what the operation actually needs is invisible until go-live, at which point it becomes very visible indeed.A properly structured needs analysis for a service business moves through three distinct stages. The first is mapping the process on paper — not just ‘how does accounting work’ but ‘when a guest checks in, which department needs what information and where does that information come from right now?’ Does front desk confirmation reach the restaurant, housekeeping, and technical services by telephone, by fax, or by a paper form passed from hand to hand? Without seeing these flows, choosing ERP modules is like planning electrical wiring before drawing the floor plan. The second stage is establishing data ownership. In service businesses, the same piece of information tends to live in multiple places in multiple formats. Guest preferences sit in a front desk notebook, a separate list held by the restaurant manager, and a different form in the sales office. Before ERP is installed, the organisation must decide where each piece of information will live and who will be responsible for keeping it current. Software cannot make that decision; management must. The third stage is identifying integration points before a single line of configuration is written. The existing accounting package, the payroll system, the reservation platform — how will they communicate with the new ERP? In 2008, these integrations are typically solved through file transfers and ODBC connections. For every integration point, the answer to ‘who exports what file, when, and where does it go?’ must be written down before the project formally starts.Now for the part that project teams most often underestimate: user resistance in service businesses is structurally higher than in manufacturing. A production line operator uses the system because the workflow leaves no alternative. A hotel receptionist, a restaurant server, a housekeeping attendant — these people are in front of guests, and looking at a screen is time taken away from service. Projects that ignore this reality discover six months after go-live that the system runs correctly but nobody uses it. Project design must therefore allocate a dedicated section to the user interface and to the time cost of data entry. If entering a completed room into the system takes more than a few minutes, the process has been transferred rather than designed. During a mid-size city hotel project in Izmir, we addressed this directly: every data-entry step was modelled on paper first, then tested by actual operations staff against prototype screens using real service scenarios. Four screen layouts were rejected before we accepted a fifth. That added three weeks to the project timeline. After go-live, system adoption stayed well above what the stakeholders had expected — because the tool matched the rhythm of the work rather than interrupting it.Management expectations also need to be calibrated clearly, and early. The typical expectation arriving at project kickoff is: ‘We will see everything on one screen.’ That expectation is legitimate, but it is only half the picture. The gap between seeing and managing is the most consistently overlooked dimension of ERP implementations. When the system is live, data appears on the dashboard — but interpreting that data, identifying meaningful deviations, and coordinating departmental responses requires a separate layer of organisational capability that software does not provide. If the general manager sees reservation revenue every morning but cannot read it alongside the cost structure that produced it, the value of the investment is halved. The human side of the process — who reads which report, who is accountable for which variance, how cross-departmental coordination happens — must be designed alongside the software configuration, not left to sort itself out after go-live.The success of an ERP project in a service-intensive sector reduces, in the end, to a single question: how well does the organisation understand its own operations before the software arrives? In a business that has mapped its processes, ERP is a genuine accelerator. In a business that has not, the system tends to preserve existing confusion in a more expensive format. If a project is still in its early stages, here is the most practical thing a decision-maker can do before choosing a vendor or signing a contract: set aside two weeks for the five most critical operational processes to be drawn out by hand, on paper, by the people who actually run them. The contradictions and ambiguities that surface in those two weeks will cost far less to resolve at that stage than they will as change requests billed against the implementation contract six months later.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 26, 2008. The English edition has been reviewed and edited by the author.