Gas infrastructure indicators

The context

Seven years in public gas infrastructure in Córdoba. Other people built the works —that side is in End-to-end works management—; my job was knowing the state of everything and making it reportable to the organisations financing it, under their standards.

The network takes in trunk pipelines, distribution branch lines, pressure regulating stations and industrial connections. Every asset has its own cycle: it gets designed, tendered, built, commissioned, operated.

The problem

The data existed, but split across inspection, administration and operations — each area with its own cut-off dates and its own definition of progress.

When two areas reported different progress for the same job, it was almost never a data-entry error. It was that each one understood “progress” differently. That observation set up everything else: the problem was not about tools.

What I built

• Data model and indicators. Defining what gets measured, at what granularity and against what baseline. The underlying decision was to measure physical progress by kilometre of route signed off by inspection — not by kilometre welded, which runs ahead of reality, nor by payment certificate issued, which lags it. It is the only unit that exists in all four disciplines at once.

• Physical and financial progress, kept apart. 40 % of pipe laid is not 40 % of budget spent. The gap between the two curves is the information, not an error to be corrected.

• The IDB / IFC standard. Reporting under a multilateral organisation’s standard shapes the whole model: what gets recorded, with what supporting evidence, and how it is demonstrated. This is the part that sets you apart — plenty of people do Power BI, very few have reported under these rules.

• ETL and dashboards. Ingestion from source systems with SQL, published in Power BI and Tableau. It is the same craft I had been doing since the warehouse in 2013, now over 12,000 km of network.

Outcome

The monthly report to the financing organisations went from 10 working days to 2. Not because assembling it was automated —though it was— but because with a single definition of progress there was no longer a reconciliation round between departments before anyone could write the first line.

That changed the question in the monthly meeting: from “which of these two numbers is the right one?” to “why did this job slip?”. The second one is the only one you can decide anything from.

---

⚠ Before publishing: confidentiality

The network’s operational data belongs to your employer, not to you, and this repository is public: whatever you push stays in the git history even if you delete it later.

What is yours is the method — the model, the indicator definitions, the reporting architecture.

• Screenshots with synthetic or aggregated data, never real operational figures.
• Tell the how, not the values it produced.
• The scale figures already public on your GitHub profile (12,000 km, 150 stations, 500 connections) are fine for context.