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.

Close-up of an early visible-measure petrol pump: a glass cylinder inside a red iron cage, with numbered markers from 0 to 10 showing the volume.
A visible-measure petrol pump, where the customer watched the fuel being counted.Credit: "Hy-Red Gasoline Station pump" by Nyttend, public domain, via Wikimedia Commons
Two white city ferries moored at the Karaköy pier, choppy grey water in the foreground and Karaköy buildings and construction cranes behind.
Ferries at Karaköy pier, 2019.Credit: "Karakoy ferry pier, Istanbul (P1100291)" by Matti Blume, CC BY-SA 4.0, via Wikimedia Commons
The stone Galata Tower with its conical roof, seen from below against a pale sky, trees around its base.
Galata Tower, 2011.Credit: "Galata Kulesi - 01" by Carlos Delgado, CC BY-SA 3.0, via Wikimedia Commons

The case in four stages

  1. BeforeFuel sales and reporting varied between cooperatives, with fragmented manual reporting.
  2. DecisionStandardise sales, station workflows and reconciliation in one system, introduced in phases.
  3. SystemOne system for fuel sales, pump, tank and tanker processes, daily reconciliation and reporting.
  4. 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

Integration ArchitectureFuel-Station SystemsReporting DataControl Mechanisms

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

Fuel SalesStation WorkflowTank/Pump OperationsReconciliationOperational Reporting

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

Multi-Stakeholder ScopeDelivery PlanningRisk ManagementOperational ChangeEnterprise Coordination

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.