Why does a trucking firm make worse profitability decisions the more data it collects? Consider a mid-sized carrier based in Kayseri, central Turkey: 312 employees, 78 tractor units and dozens of routes running simultaneously every day. Fuel, driver allowances and vehicle depreciation are all tracked in separate ledgers. Revenue gets recorded. Costs get recorded. But when the month closes, nobody can say clearly which route made money and which one quietly drained it. The ERP project enters at precisely this point — and management buys the system expecting it to resolve everything at once. Understanding exactly where that expectation breaks down is the real starting point of this conversation.Integrating ERP with logistics operations is not, at its core, a software installation project. It is first and foremost a project to clarify how the firm prices its services. This distinction matters enormously, because most Turkish trucking companies do not actually have a consistent answer to that question when an ERP engagement begins. Is there a fixed rate per tonne? A sliding tariff by distance? A customer-specific agreement negotiated years ago by the owner? If these answers are not consistent and documented, the system can collect perfectly clean data and still generate reports that lead nowhere useful. In my experience, every project that skips this clarification phase arrives at the same complaint by the third month: ‘the system is not working correctly.’ The system is working fine. The underlying logic was never defined.The concept of pre-shipment profitability analysis is still relatively new thinking in Turkey’s road freight sector in the mid-2000s. Most firms understand their margins only retrospectively — after the trip is completed, after the month is closed. The genuine value of a logistics ERP module lies in estimating whether a given shipment will be profitable before the loading decision is made. To do this, the system needs to bring several figures together into a single calculation: the vehicle’s fuel consumption coefficient by age and load weight, the route distance and toll costs, the driver’s daily allowance, the probability of waiting time at the loading or delivery point, and the customer’s payment terms. Held in separate modules, these figures mean nothing individually. Combined into a pre-shipment margin estimate, they turn a dispatcher’s instinctive judgment into a documented, auditable decision. In the Kayseri case described here — a representative scenario based on similar engagements — after this structure was built, analysis showed that 53 of the 312 shipments taken in one month would have been declined had a margin threshold been in place. The truck capacity and driver hours committed to those runs could have been redirected to more profitable loads that were turned away that same period.Load optimization is another area where ERP’s role is frequently misunderstood. The system does not generate a perfect loading plan automatically. What it does is give the logistics supervisor the information needed to make a sound decision rather than an approximate one. Seeing vehicle capacity, weight limits, delivery sequence and cargo documentation status on a single screen takes the calculation out of the supervisor’s head and places it on verifiable ground. Working with the freight department of a textile exporter in Gaziantep illustrated this vividly: the senior dispatcher was making good decisions by instinct, but none of those decisions were costing themselves. Once the system was in place, the first clear finding was that the margin difference between a fully loaded trailer and one running four tonnes short was far larger than the team had assumed. That ‘gap’ was invisible because it was never measured. Load optimization for this reason requires capacity utilization tracking before it requires route planning; you cannot optimize what you cannot see.The integration point that causes the most persistent trouble in practice is the disconnection between the accounting module and the operations module. In most ERP implementations, these two are built by different teams at different times. Finance configures the ledger logic; operations configures the trip management screens. Without a deliberate bridge between them, the firm begins living with two separate versions of its own reality — one in the books, one in the yard. A concrete illustration: a trip closes as profitable in the accounting module because revenue exceeded direct costs. But the same trip caused the next available load to be missed because the vehicle was delayed at the delivery point by six hours. That missed revenue is an opportunity cost that sits in neither module unless someone has specifically mapped the connection. Building that link is technically straightforward in most ERP platforms available in Turkey at this time — it requires a join between the trip completion timestamp in the operations module and the next available load window in the dispatch queue. The difficulty is not technical. It is definitional: the project team must agree that ‘trip completion’ and ‘trip profitability’ are not the same event.The most stubborn practical obstacle is user habit. Logistics supervisors and dispatchers have spent years working with paper trip sheets, and then with Excel files they built themselves. Transitioning to ERP screens is not only a matter of learning new software — it means dismantling routines that feel faster and more familiar than anything unfamiliar can feel in the first weeks. In the Kayseri engagement, eleven weeks after go-live, roughly half of trips were still being recorded on paper first and then entered into the system afterward. The data was real but it was never timely, which undermined the entire purpose of the pre-shipment calculation. The solution was not enforcement. It was redesign. The ERP input screen was restructured to mirror the paper form the dispatcher already used — same field names, same sequence, same mandatory minimums. The user did not feel they were learning a new system; they felt they were filling in the same form on a keyboard instead of with a pen. That small shift in framing reduced the parallel paper process significantly within four additional weeks. The lesson is that an ERP consultant who designs input screens based on what the user should do rather than what the user currently does will lose the adoption battle regardless of how well the underlying logic is built.The right question to ask at the start of a logistics ERP engagement determines everything that follows. Not ‘which module should we implement first?’ but rather ‘which decision are you making blind right now?’ If the answer is ‘I do not know which loads to accept,’ prioritize the pre-shipment margin module. If the answer is ‘my vehicles are running partially empty but I cannot explain why,’ start with capacity utilization tracking. If the answer is ‘the month-end numbers never reconcile,’ build the bridge between operations and accounting before touching anything else. A system of any size or sophistication will only report chaos more quickly and more precisely if the firm’s pricing logic has not been agreed upon before implementation begins. That is the one condition no software vendor puts in its proposal, and the one condition that decides whether the project delivers anything of value.
This article was originally published in Turkish by Gökhan MERCANOĞLU on February 1, 2005. The English edition has been reviewed and edited by the author.