GESTKOR database
A retail maintenance system that had grown without an architecture: data duplicated across modules, and figures that did not reconcile between operations and invoicing. The brief was to rebuild the database entirely, from process analysis through to production.
- Role
- Data and process consultant
- Client
- Grupo Korus · GESTKOR system
- Duration
- 5 months, 4 milestones
- Sector
- Retail maintenance
The problem
GESTKOR runs the full maintenance service cycle across retail sites: locations, materials inventory, technician scheduling, site access permits, inspections, work orders, valuation and invoicing. Each of those processes had added tables to the database over the years, with no model tying them together. The visible symptom was that operational data and the final service valuation did not match. The cause sat further down: the same entity existed several times, in different formats, with no single source of truth.
How I approached it
Before touching a table, I mapped the processes. A maintenance system cannot be modelled from its existing schema — it has to be modelled from what the operation actually does, and only then does it become clear which entities are real and which were patches. I built the data flow diagrams with the people who run each process, and validated them before moving to the logical model.
- Data flow diagrams and conceptual mapping, validated with key users
- Entity-relationship model with a data dictionary
- Normalisation to remove redundancy and enforce referential integrity
- Programmed logic: stored procedures, triggers, analytical functions and indexes
- Full integration testing and performance tuning before deployment
The decision that defined the project
The client expected to start by building. I insisted the first deliverable be the approved data flow diagrams, with not a single table written. That pushed visible code back by a full month, and it is what made the rest viable: the validation sessions surfaced business rules nobody had documented — how it is decided that an incident is genuinely closed, when a material is reimbursable — and those rules ended up as constraints in the model rather than manual corrections afterwards.
How the engagement was structured
The work ran across four deliverables, each signed off by management: approved data flow diagrams, the logical model and data dictionary, the database built in a test environment, and production deployment with technical documentation. I included a thirty-day warranty period after deployment covering any deviation attributable to the design.
The schema detail, master tables and client data are covered by a confidentiality agreement. This page describes the approach and methodology, not the specific implementation.