De veinte hojas de cálculo a una sola base de datos

¿Por qué veinte hojas no son una base de datos?

Porque una hoja no sabe nada de otra. Las tres propiedades que faltan son siempre las mismas, y cada una produce un problema reconocible.

No hay identidad. En una base, un cliente es un registro con un identificador. En veinte hojas, un cliente es un texto escrito a mano, y “Constructora del Istmo”, “Const. del Istmo S.A.” y “constructora istmo” son tres clientes distintos para la máquina.

No hay reglas. Una celda acepta cualquier cosa: una fecha como texto, un monto con letras, un campo vacío donde el proceso espera un número. Los errores no se detectan al escribirlos, se detectan meses después, al sumar.

No hay relación. Para saber qué compró un cliente hay que cruzar a mano la hoja de ventas con la de clientes, y ese cruce lo hace una persona que decide sobre la marcha qué nombre corresponde a qué. Cada persona decide distinto.

La consecuencia práctica es la que vemos en todas las empresas que llegan así: cada vez que alguien arma el mismo reporte sale un número diferente, y con el tiempo nadie usa ninguno para decidir.

¿Cómo se consolida, en orden?

El orden importa más que las herramientas, porque los pasos uno y dos son del negocio y no de la técnica.

1. Inventario de lo que hay

Qué archivos existen, quién los edita, cada cuánto, y qué pregunta contesta cada uno. Suele aparecer algo que nadie recordaba y algo que ya nadie usa.

2. Decidir la fuente que manda, dato por dato

Es la conversación que define el proyecto. Para cada dato, un solo lugar manda: el cliente manda en la hoja de administración, el precio en la lista oficial, el inventario en el sistema del punto de venta. Sin esta decisión, consolidar es mezclar.

3. Modelar en serio, pero poco

Clientes, productos, ventas, y las relaciones entre ellos. En una pyme, eso suele ser menos de diez tablas. La tentación es modelar para todo lo que podría pasar algún día, y produce una base que nadie entiende.

4. Cargar, limpiar y unificar

Aquí aparecen los duplicados de nombres, las fechas en tres formatos y los montos con separadores distintos. La unificación de clientes la revisa alguien del negocio, siempre: hay pares que solo una persona de ahí puede decidir si son el mismo o no.

5. Validar contra algo conocido

La prueba que no se salta: el total de ventas del año pasado según la base nueva tiene que coincidir con el que la empresa ya reportó. Si no coincide, se averigua por qué antes de seguir, porque esa diferencia va a reaparecer en cada reporte.

Problema que siempre aparece	Cómo lo tratamos
El mismo cliente escrito de varias formas	Unificación con revisión humana, guardando el nombre original
Fechas en formatos distintos	Normalización, y una marca en lo que quedó ambiguo
Filas duplicadas entre archivos	Clave de negocio para detectarlas, no borrado a ciegas
Montos con separadores mezclados	Conversión con reglas explícitas y revisión de los extremos
Histórico con datos dudosos	Se carga con marca de calidad, no se descarta

Para esto no hace falta nada caro. Una base abierta como PostgreSQL, consultada el 27 de octubre de 2026, aguanta sin esfuerzo tablas mucho mayores de lo que cualquier pyme panameña va a generar.

¿Qué pasa con las hojas después?

Siguen existiendo, y conviene decirlo porque es lo que más tranquiliza al equipo que lleva años trabajando así. Lo que cambia es su papel: pasan de ser la verdad a ser una herramienta de captura o de análisis. El reporte se exporta a una hoja, se juega con ella y se bota.

Lo que no puede quedar es la captura doble. Si alguien sigue escribiendo la venta en la hoja y en el sistema, las dos verdades volverán a separarse en un mes. Esa es la señal de que el proyecto no terminó.

Nuestra opinión, de haber visto varias de estas: el error más caro no es técnico, es empezar a cargar datos antes de que el negocio haya decidido qué fuente manda. Produce una base que parece correcta, con la mezcla de dos verdades adentro, y eso es más difícil de arreglar que las veinte hojas originales.

El caso completo de un proyecto así está en migrar datos dispersos a una fuente única. Si lo que se está discutiendo es directamente reemplazar la hoja por un sistema, cómo se ve eso por dentro está en cuando Excel ya no da. La parte de limpieza, que es la que más tiempo consume, está en datos sucios. Y lo que hacemos con datos está en datos e inteligencia de negocio.

Lo que conviene recordar

• Veinte hojas no son una base porque no hay identidad, ni reglas, ni relaciones.
• La decisión que define el proyecto es cuál fuente manda para cada dato, y la toma el negocio.
• Modela poco: en una pyme suelen bastar menos de diez tablas.
• Valida contra una cifra que la empresa ya reportó antes de seguir.
• Las hojas pueden quedarse como captura o análisis. Lo que no puede quedarse es la captura doble.