When you join an energy trading company as an ERP consultant, there is almost always a moment in the first week when the finance manager says something like: ‘We already have a computer program — we just want something a bit better.’ That sentence, as familiar as it sounds, tells you everything about the real problem: nobody has yet defined what ‘better’ actually means in operational terms. That was precisely the situation I encountered at a mid-sized wholesale energy distributor based in Ankara, a company with 312 employees handling fuel procurement, dealer network management, contract administration, and tax reporting across four loosely connected applications. The ERP project had been initiated to fix this fragmentation, but the software had been selected before the processes were mapped. That sequence is the single most common reason energy sector ERP projects lose momentum within six months.Energy trading has a particular operational intensity that sets it apart from manufacturing or retail ERP implementations. A single bulk fuel procurement transaction involves a supplier invoice, a warehouse receipt, a letter of credit or bank guarantee, and a VAT liability — all of which need to resolve simultaneously in the accounting ledger. On the sales side, dealers receive goods on credit, operate under individually negotiated discount structures, and accumulate periodic volume bonuses that are calculated at month end. To manage this complexity properly, the ERP system’s procurement, sales, and finance modules must work as a genuinely integrated unit: when a purchase order is raised, the budget commitment must hit the financial tables immediately; when goods move, stock valuation and cost of sales must update without manual intervention. Without this integration, what you have installed is an expensive replica of the old program.My core argument is this: in process-intensive sectors like energy trading, the quality of the process definition work done before the software goes live determines far more of the project outcome than the software selection itself. Whether you choose SAP, Microsoft Dynamics NAV, or a capable local solution, if the procurement approval hierarchy, the sales contract logic, and the finance integration rules have not been documented and agreed upon before parametrisation begins, the implementation will drift into perpetual scope creep. At the Ankara company, our first action for this reason was not a software demo — it was a series of process mapping workshops. The demo was pushed to the second week.When we examined the procurement process, the most critical gap was immediately visible: the approval hierarchy existed only as unwritten convention. Purchases below 50,000 TL were cleared by the procurement manager; anything above that went to the general manager. But this threshold was interpreted differently in three separate departments. No written policy document existed. Before the procurement module could be parametrised with approval workflow rules, the company needed a single, signed approval policy that everyone recognised. Reaching that agreement took six working days and surfaced a genuine management disagreement between department heads that had apparently never been addressed openly. This is a pattern worth noting: ERP projects in companies with strong informal cultures tend to expose organisational problems that were invisible as long as everything lived in people’s heads and spreadsheets.The sales and receivables side presented a different challenge. The company sold to dealers on credit terms, applied contract-specific discount rates, and calculated quarterly volume bonuses manually. The finance team was producing a bonus reconciliation spreadsheet each quarter that contained 67 line items for a single large dealer — a task that consumed two to three working days and carried real error risk. The ERP sales module can automate this calculation entirely, but only when dealer-level price lists and discount rules are encoded as clean, consistent parameters. The problem was that existing dealer contracts were inconsistent: some ran to twelve pages with bespoke conditions. The most significant decision we made during the process definition phase was not a technical one — it was the business decision to consolidate all dealer arrangements into four standard contract categories rather than replicating every historical exception in the system. This created short-term friction with the sales team, but it was the only approach that would produce a system maintainable beyond the first year.On the finance integration side, the most technically demanding step was chart-of-accounts mapping. The company had operated for years using a sub-account coding structure designed by its long-standing external accountant. The structure was consistent with the Turkish Uniform Chart of Accounts framework but followed a proprietary internal logic at the sub-account level. Mapping this to the ERP’s standard account structure required a series of accounting decisions: which sub-accounts would feed which cost centres, how aged receivables would be bucketed across time intervals, and how foreign currency transactions would post to exchange difference accounts. These questions were answered in thirty-two working sessions with the finance manager and the external auditor. It was the slowest phase of the project and also the most valuable — because every ambiguity resolved at that stage was an ambiguity that would not resurface as a posting error six months after go-live.The practical conclusion I draw from this project is straightforward. If you are running an ERP implementation in energy trading or any sector with comparable transaction complexity, commit the first four to six weeks of the project exclusively to process clarification: write down the procurement approval policy, standardise the sales discount structure, and map the existing chart of accounts against the ERP’s default structure before a single parameter is set. Skipping this phase does not shorten the project — it causes a second, larger project to begin roughly six months later when someone says ‘we need to change the system.’ At the Ankara company, the combined process definition and parametrisation work took nine weeks. The implementation phase that followed ran with noticeably fewer disruptions than anyone had expected. The finance manager, who had wanted ‘something a bit better,’ ended the project with something that actually worked. That is a different thing entirely, and it starts well before the software is installed.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 11, 2007. The English edition has been reviewed and edited by the author.