Fuel Automation System
- Type
- Enterprise case study
- Employment context
- Former employment, delivered with teams
- Employer
- Tarım Kredi Teknoloji
- Period
- April 2023 – April 2026 (period of employment)
- My role
- Led product and delivery on the employer side: roadmap and prioritisation, MVP scope, and coordination of the UAT, pilot and live stages across operational and technical stakeholders.
- Domain
- Fuel Operations
- Team
- Designed, built and tested by the in-house software, analysis and testing teams, with requirements from fuel operations and cooperative stakeholders.
- Evidence
- Figures are drafts awaiting approval. No screenshots or internal architecture details are shown.
Enterprise project undertaken during my employment. The platform is owned and operated by the respective organisation; my contribution is described below.
This is a case study of an enterprise fuel automation system delivered through Gönenç Türkekul's former employment at Tarım Kredi Teknoloji. The system manages the sale, reporting and daily reconciliation of fuel sold to farmer members through a cooperative network, and standardises station, pump, tank and tanker workflows. The page explains why reconciliation was hard, what the team delivered, which details are not claimed and his specific responsibilities in scope and delivery planning. The system belongs to the organisation that runs it.
Fuel for cooperative members
Cooperatives in the Tarım Kredi group sell fuel to their farmer members; the CV describes this network as 1,100 cooperatives. Each sale involves station equipment such as pumps and tanks, tankers deliver fuel, and every day the sales have to be reconciled and reported. The group's technology company, where I worked, delivered the software that manages this process.
How fuel sales worked before
Fuel sales, reporting and reconciliation across cooperative operations needed more standardisation, automation and visibility. Reports were not produced in one consistent way across locations, which made the data harder to compare and to rely on at group level. Much of the reporting was fragmented and manual, and data inconsistencies were a known issue.
The problem to solve
The group needed one system that records fuel sales in a standard way, supports the daily work at stations and produces reconciled reports that mean the same thing in every cooperative. It had to align three things that rarely fit neatly together: physical equipment at stations, business rules for member sales and daily reconciliation.
What the system covers
The team delivered a system that standardises fuel station workflows, tanker and pump processes, daily reconciliation and reporting, with control mechanisms for operations teams. This page describes the scope at a high level. Which integrations reached production at each location, and how devices are connected, are not published here.
Capabilities in scope
- Fuel sales recording
- Station, pump and tank workflows
- Tanker process tracking
- Daily reconciliation
- Standardised cooperative reporting
- Operational control mechanisms
My role and the team's
The in-house teams designed, built and tested the system, with requirements from fuel operations and cooperative stakeholders. I led product and delivery: setting priorities across many stakeholders, defining the first scope, planning how the system moved through testing and pilots to live use, and keeping equipment, business rules and reporting needs in one plan.
My part
- Product roadmap and prioritisation
- MVP scope definition
- Coordination of UAT, pilot and live transitions
- Aligning operational and technical stakeholders
The team’s part
- System design, development and integration
- Requirements analysis
- Testing and release
- Operational input from cooperatives
Trade-offs and constraints
Fuel systems touch physical equipment, money and regulation at once, and each depends on the others. Planning therefore had to treat station equipment, business rules and reconciliation as one chain of dependencies. A phased path through user acceptance testing and pilots, rather than a single switch-over, was the way to manage that risk across many sites.
Coverage and intended value
Figures from the sources
1,100
Cooperatives in scope
Draft awaiting approval
- Documented coverage
- Covers fuel sold to farmer members in 1,100 cooperatives, according to the CV.
- Intended value
- cooperative reporting in one standard format, fewer data inconsistencies, clearer visibility over sales and reconciliation, and less fragmented manual reporting.
What I learned
Reconciliation is where operational truth shows up. If the numbers do not match at the end of the day, the cause is usually upstream: in how sales were recorded, how equipment reported or how a rule was interpreted. I learned to work backwards from the reconciled report and to agree data definitions before building screens.



The case in four stages
- BeforeFuel sales and reporting varied between cooperatives, with fragmented manual reporting.
- DecisionStandardise sales, station workflows and reconciliation in one system, introduced in phases.
- SystemOne system for fuel sales, pump, tank and tanker processes, daily reconciliation and reporting.
- ChangeCooperatives report in one standard way, designed to reduce data inconsistencies.
Drawn route of the case. The platform belongs to the organisation, so no screens are shown.
Technical, operational and managerial
Technical
The system sits between station equipment and group-level reporting. Integration architecture covers how sales and equipment events reach the system; reporting data covers how they become reconciled, comparable reports. Device-level integration details are deliberately left out of this page.
Operational
Daily work at a station includes selling fuel to members, handling pumps and tanks and receiving tanker deliveries. At the end of the day, sales must reconcile. The system standardises these steps so that each cooperative records and reports them the same way.
Managerial
Cooperatives, operations teams and technical teams each had a stake in the system. I worked on scope and priorities, planned delivery in phases and treated equipment, rules and reporting as linked risks. Changing how many sites report is an operational change, not only a software release.
Questions answered
What does fuel-sales automation coordinate?
It connects the sale of fuel to members with station equipment such as pumps and tanks, tanker deliveries, daily reconciliation and reporting. The aim is that every sale is recorded once, in a standard way, and flows into reports that mean the same thing everywhere.
Why is daily reconciliation difficult?
Because it depends on everything upstream. Sales records, equipment readings and business rules all have to agree. When sites record data differently, reports cannot be compared and differences are hard to explain. Standard recording is the precondition for clean reconciliation.
What was delivered and what remained pending?
The published sources describe standardised station workflows, tanker and pump processes, daily reconciliation, reporting and control mechanisms. They do not detail which integrations reached production at each site, so this page does not claim that every planned integration went live.
What was Gönenç Türkekul's role?
He led product and delivery on the employer side: roadmap and priorities, MVP scope, and coordination of testing, pilot and live stages with operational and technical stakeholders. The in-house teams designed, built and tested the system.
Facing a similar change?
If your organisation is planning a change like this one, I am glad to talk it through.