Network Change Registry
Traceable, consistent network-change history, feeding the KPI programme that cut external complaints by 15%.
Details abstracted to protect client confidentiality.
Context
In a mobile network, configuration changes land daily, from many hands. Without a single record of what changed, where and when, every performance investigation starts with archaeology, and undocumented changes surface later as customer complaints.
My role
As Analytics & Planning Engineer at Ooredoo, I designed the internal database that centralised network-change tracking, and built the network-performance KPIs and reporting on top of it.
Approach
- Mapped how changes were actually being recorded across teams, and where history was being lost.
- Designed a SQL schema that centralised change tracking: one registry, controlled fields, one consistent structure.
- Built network-performance KPIs on Oracle DB, read against the change history.
- Automated the dashboards and reporting with Python, Pandas and Power BI, so the numbers arrived without manual assembly.
Governance decisions
- One registry, not many spreadsheets. A single source of truth for change history is the precondition for every other control.
- Controlled fields. Consistent structure and constrained values cut errors and duplicates at the point of entry, the cheapest place to fix them.
- Traceability as the product. Every change carries enough context (what, where, when) to be found again; troubleshooting becomes lookup rather than recollection.
- Documentation inside the workflow. Recording a change is part of making it, not an afterthought to chase later.
Outcome
The KPI programme this fed cut external complaints by 15%. Change history became traceable and consistent, documentation improved, and errors and duplicates fell: the quiet, structural work the visible number depended on.