Base de datos GESTKOR
Un sistema de mantenimiento retail que había crecido sin arquitectura: datos duplicados entre módulos, cifras que no cuadraban entre lo operativo y lo facturado. El encargo fue rehacer la base de datos completa, desde el análisis de procesos hasta producción.
- Rol
- Consultor de datos y procesos
- Cliente
- Grupo Korus · sistema GESTKOR
- Duración
- 5 meses, 4 hitos
- Sector
- Mantenimiento para retail
El problema
GESTKOR administra el ciclo completo del servicio de mantenimiento en locales retail: ubicaciones, inventario de materiales, programación de técnicos, permisos de acceso, inspecciones, órdenes de trabajo, valorización y facturación. Cada uno de esos procesos había sumado tablas a la base de datos con el tiempo, sin un modelo que los relacionara. El síntoma visible era que la data operativa y la valorización final del servicio no coincidían. La causa estaba más abajo: la misma entidad existía varias veces, en formatos distintos, sin una fuente única de verdad.
Cómo lo abordé
Antes de tocar una tabla, mapeé los procesos. Un sistema de mantenimiento no se modela desde el esquema existente — se modela desde lo que la operación realmente hace, y recién ahí se ve qué entidades son reales y cuáles eran parches. Trabajé los diagramas de flujo de datos con los usuarios que ejecutan cada proceso, y los validé con ellos antes de pasar al modelo lógico.
- Diagramas de flujo de datos y mapeo conceptual, validados con usuarios clave
- Modelo entidad-relación con diccionario de datos
- Normalización para eliminar redundancia y garantizar integridad referencial
- Lógica programada: stored procedures, triggers, funciones analíticas e índices
- Pruebas integrales y afinamiento de rendimiento antes del despliegue
La decisión que definió el proyecto
El cliente esperaba empezar por construir. Insistí en que el primer entregable fueran los diagramas de flujo aprobados, sin una sola tabla escrita. Eso retrasó el código visible un mes entero y fue lo que hizo viable el resto: las sesiones de validación revelaron reglas de negocio que nadie había documentado — cómo se decide que una incidencia está realmente cerrada, cuándo un material es reembolsable — y esas reglas terminaron siendo restricciones en el modelo en vez de correcciones manuales después.
Estructura del encargo
El trabajo se estructuró en cuatro entregables con conformidad de gerencia en cada uno: diagramas de flujo aprobados, modelo lógico y diccionario de datos, base construida en ambiente de pruebas, y despliegue en producción con documentación técnica. Incluí un periodo de garantía de treinta días posterior al despliegue para cubrir cualquier desvío atribuible al diseño.
El detalle del esquema, las tablas maestras y los datos del cliente están cubiertos por un acuerdo de confidencialidad. Esta página describe el enfoque y la metodología, no la implementación específica.