When an aviation company’s operations director tells you ‘we have a system, everything is logged,’ one question is enough: ‘Can you show me in five minutes which aircraft, under which contract, cost you money this month?’ The answer is almost always silence. The ERP is running, the accounts are reconciled, maintenance records are in order — yet real profitability per aircraft still lives in a manager’s head, buried in a spreadsheet, or simply nowhere at all. This is precisely where you begin to understand why ERP implementations in civil aviation so often come up short.My thesis is direct: aviation companies launch ERP with the maintenance and technical module, then defer contract and profitability management to ‘the next phase.’ This is not a deliberate strategy — it is fatalist postponement. You cannot fly without maintenance tracking, that is true. But building an ERP without first modelling your contract profitability is like insuring your factory equipment while having no idea what your product actually costs to make. The system appears to function, operations continue; you simply never know which contracts are building the business and which are quietly draining it.I observed this dynamic closely during a project at a mid-sized aviation company based in Ankara — a charter and private jet operator running a fleet of eight aircraft with 412 employees. The technical director was confident at the project’s outset that two things were already well defined: maintenance cycles and route scheduling. When we examined the customer contracts, the picture became considerably more complex. There were more than twenty-four distinct contract templates across eight aircraft. Some were priced on a per-flight-hour basis; others included monthly guaranteed minimums; some passed fuel costs to the client while others absorbed them within a fixed rate. The ERP’s standard maintenance module could not connect any of these structures to each other. The system recorded maintenance cost — but it had no way of knowing whether any specific contract was covering that cost.Resolving this required a conceptual step before any technical one. Until the definition of ‘profit centre’ is settled within the company, no module configuration will produce coherent results. In aviation, is the profit centre the aircraft, the customer contract, or the route? The answer varies across organisations, and ERP configuration follows that answer. In the Ankara project, a 14-week analysis period reduced the contract templates from twenty-four to four, assigned a cost centre to each aircraft, and mapped maintenance cycles against contracted guaranteed hours in a single unified structure. Without that work done first, every module risks becoming an isolated island of data.The most persistent practical difficulty is the data mismatch between finance and operations. The accounting team records flight hours as a billing unit; the technical team tracks the same figure as a maintenance threshold; the operations coordinator uses it for capacity planning. Three departments, three versions of the same data, and almost no one aware of the inconsistency until the ERP integration workshop forces a reconciliation. When this became visible in a single meeting, the company’s CFO said, ‘we already knew this.’ But knowing something and having the system expose and cross-reference it in real time are separated by exactly the distance that justified the project in the first place.The maintenance module itself is demanding enough on its own terms. Turkish civil aviation operates under mandatory inspection cycles set by the Civil Aviation General Directorate (SHGM); these combine hour-based thresholds (A, B, C and D checks) with calendar-based intervals that run simultaneously. If the ERP is not structured to track these independently per aircraft, reminders live in Excel, in a maintenance lead’s notebook, or rely on an experienced technician’s memory. For an eight-aircraft fleet this may be manageable. When the fleet grows to sixteen, the error margin without a system becomes operationally dangerous. The solution in this project was to configure each SHGM-mandated cycle as a separate time-and-hour combination within the ERP, generating automatic alerts 48 hours before any threshold was reached. That single feature provided enough justification on its own to earn organisational buy-in for the broader project.Personnel and certification management presents a parallel challenge. Pilot flight hour limits, valid SHGM-approved licences across all technical staff, and simulator training schedules are all data points that must be retrievable and verifiable during regulatory audits. Gathering this information separately from HR, finance and the technical department — then cross-referencing it manually — is both time-consuming and error-prone. When the ERP’s HR module flags certification expiry dates and renewal deadlines automatically, that information consolidates to a single point of control. In the Ankara project, configuring this module consumed roughly 46 percent of the total implementation timeline, and it was the area technical staff valued most when the system went live.Procurement and inventory management is a comparatively more straightforward component of aviation ERP, but one that should not be underestimated. Spare parts in aviation are simultaneously critical and expensive to hold. Keeping stock ties up capital; not keeping it creates operational risk. When the procurement module calculates reorder points automatically by combining minimum stock thresholds with supplier lead times, both unnecessary inventory and emergency sourcing costs decrease. As part of this project, spare part categories were systematically classified for the first time in alignment with SHGM requirements — and that classification restructured how purchasing priorities were handled from that point forward.The clearest lesson from civil aviation ERP work is this: a system built only around maintenance tracking is not a business management tool — it is a compliance log. Contract structure, profit centre definition and regulatory requirements must be modelled before the first module goes live; no amount of technical configuration after the fact will fill that gap. When the technical director who had carried ten years of operational knowledge in his head left the Ankara company eighteen months after the project concluded, the ERP held what he knew. The institutional memory had been transferred to the system rather than walking out the door. If your senior manager is telling you ‘maintenance first, contracts later,’ ask one question: when exactly is later? Because in most cases, it never arrives.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 5, 2008. The English edition has been reviewed and edited by the author.