Cuándo dejar la hoja y saltar a SQL o Python

Es lunes. Son las 7:45 de la mañana. Carlos lleva tres años como analista de operaciones en una empresa de logística de 400 empleados. Cada lunes, antes de que llegue nadie, hace lo mismo: abre el sistema de gestión de almacén, exporta los datos de la semana en un CSV, lo pega en una hoja de cálculo que heredó de su predecesor, ajusta cuatro fórmulas, y genera el informe semanal de entregas a tiempo que el director de operaciones revisa a las 10. El proceso tarda entre 40 y 55 minutos, dependiendo de si algo se descuadra. Hoy, algo se descuadra. El CSV tiene 142.000 filas en vez de las 65.000 habituales, porque han abierto un nuevo almacén. Excel tarda 35 segundos en recalcular. Una fórmula de SUMAR.SI.CONJUNTO apunta a un rango que no llega a las nuevas filas. El porcentaje de entrega a tiempo sale un 4% mejor de lo que es. Carlos no lo sabe todavía.

La historia de Carlos no es excepcional. Es el día a día de miles de analistas que mantienen informes críticos en hojas de cálculo que han crecido más allá de lo que la herramienta puede gestionar con seguridad. Y el problema no es que la hoja sea mala — ya hemos visto que es magnífica para muchas cosas — sino que hay un punto de inflexión donde deja de ser suficiente. Reconocer ese punto es una habilidad profesional que define al analista que da el salto de junior a mid.

En la primera lección de este módulo mencionamos cinco límites de la hoja de cálculo. Ahora vamos a abrir cada uno de esos cinco, meterle las manos dentro, y entender exactamente cómo se manifiesta, qué riesgos tiene, y cuál es la solución. No hay teoría abstracta: cada síntoma viene con una historia, un diagnóstico y una receta. Y al final, la historia completa de Carlos — cómo pasó de ese lunes a las 7:45 a un sistema que se ejecuta solo a las 6 de la mañana sin que nadie tenga que hacer nada.

### Los cinco síntomas: el diagnóstico completo

Piensa en estos cinco síntomas como los niveles de alerta de un hospital. El primero es una molestia que puedes ignorar un tiempo. El último es la sirena que suena en urgencias. Pero la clave es que no se presentan solos: se acumulan. Y cuando se acumulan, cada uno amplifica a los demás. Un fichero lento que además se actualiza a mano cada semana y que además tiene dos versiones y que además nadie entiende las fórmulas es un sistema a punto de romperse.

### Síntoma 1: El fichero tarda en abrir

Cómo se manifiesta: abres el fichero y aparece la barra de carga. Haces scroll y las celdas tardan en pintarse. Cambias un filtro en la tabla dinámica y Excel se queda "pensando" durante 10, 20, 40 segundos. El ordenador no está roto: es que la hoja de cálculo está procesando datos en un motor que no fue diseñado para ese volumen. Excel tiene un límite físico de 1.048.576 filas, pero el límite real está mucho antes. Con 50.000 filas y fórmulas que recalculan en cascada, ya notas la lentitud. Con 100.000 y un BUSCARV por fila, el fichero se vuelve inutilizable.

El riesgo no es la lentitud en sí — es lo que la lentitud provoca. Cuando un fichero tarda 30 segundos en recalcular, dejas de explorar. Ya no pruebas "a ver qué pasa si filtro por esta región", porque cada prueba cuesta medio minuto. El análisis se empobrece: haces lo mínimo para sacar el informe y te vas. Además, la lentitud a menudo esconde el error silencioso: una fórmula que apunta a un rango fijo y no se amplía al crecer los datos funciona rápido (porque calcula sobre menos filas de las que debería), así que el número sale mal pero rápido, y nadie sospecha.

La solución: SQL. Un motor de base de datos (como DuckDB, PostgreSQL o BigQuery) está optimizado exactamente para esto. Cien mil filas es trivial. Un millón es rutina. Diez millones con un índice adecuado tarda milisegundos. No hay rango que ampliar, no hay recálculo en cascada, no hay fichero que pese 200 MB. Escribes SELECT SUM(importe) FROM ventas WHERE region = 'Sur' y el motor te devuelve el número al instante, sin importar cuántas filas tenga la tabla.

### Síntoma 2: El mismo informe cada semana

Cómo se manifiesta: tienes un ritual. Puede ser cada lunes, cada día 5 del mes, o cada viernes a las 4. Abres un sistema, exportas datos, los pegas en tu hoja, ajustas las fechas de las fórmulas, compruebas que nada se haya descuadrado, generas el PDF o el PowerPoint, y lo envías. El proceso tarda entre 20 minutos y una hora dependiendo de la complejidad. Y lo repites. Semana tras semana. Mes tras mes.

El riesgo tiene dos caras. La obvia: cada ejecución manual es una oportunidad de error. Copias un rango mal, te saltas un paso porque es viernes y tienes prisa, pegas en la pestaña equivocada, o se te olvida actualizar la fecha del título y el informe de abril dice "marzo". La menos obvia pero más dañina: no puedes irte de vacaciones. Si enfermas un lunes, no hay informe. Si cambias de trabajo, quien te sustituya tardará semanas en entender tu hoja. El conocimiento está atrapado en tus manos, no en un sistema.

La solución: Python (a menudo combinado con SQL). Un script de Python puede hacer exactamente lo que haces tú cada lunes: conectarse a la base de datos, ejecutar la consulta SQL, formatear el resultado, generar un fichero Excel con colores condicionales, y enviarlo por correo. Y lo hace en 5 segundos, sin errores, a las 6 de la mañana, todos los lunes del año. Cuando llegas a la oficina, el informe ya está en la bandeja del director. No has tenido que hacer nada.

### Síntoma 3: Dos versiones del mismo número

Cómo se manifiesta: estás en una reunión y alguien dice "la facturación del trimestre fue de 4,2 millones". Entonces otra persona dice "no, fue de 4,1 millones". Los dos tienen razón... en sus respectivas hojas. Marketing filtró por fecha de pedido; Finanzas filtró por fecha de factura. Marketing incluyó las devoluciones como negativo; Finanzas las excluyó. No hay forma de saber quién tiene razón sin sentarse a comparar fórmula por fórmula, celda por celda.

El riesgo es político antes que técnico. Cuando dos departamentos presentan números distintos sobre lo mismo, se pierde la confianza en los datos. El director ya no sabe a quién creer. Las reuniones se convierten en debates sobre "de dónde salen tus números" en vez de debates sobre qué hacer con los números. Y lo peor: cada vez que alguien copia la hoja para "hacerse la suya", crea una nueva versión potencialmente divergente. Las copias se multiplican y la verdad se diluye.

La solución: SQL contra una fuente única. Si Marketing y Finanzas ejecutan la misma consulta SQL contra la misma base de datos, obtienen el mismo número. No hay copias. No hay versiones. No hay "mi hoja". El dato vive en un solo sitio y se consulta desde ahí. Si hay que aplicar un filtro distinto (fecha de pedido vs fecha de factura), ese filtro está escrito en la consulta y cualquiera puede leerlo, cuestionarlo y entenderlo. La discrepancia ya no es un misterio: es una decisión explícita y documentada.

### Síntoma 4: Una fórmula que nadie entiende

Cómo se manifiesta: haces clic en una celda que muestra "22,4%" y en la barra de fórmulas ves algo como =SI(Y(INDICE(Datos!$B$2:$B$9999;COINCIDIR(A2;Datos!$A$2:$A$9999;0))>0;INDICE(Datos!$C$2:$C$9999;COINCIDIR(A2;Datos!$A$2:$A$9999;0))<>"");"ok";""). Esa fórmula la escribió alguien que ya no está en la empresa. Funciona. Da un número. Pero nadie sabe exactamente qué condiciones comprueba, por qué están esos rangos fijos, ni qué pasa si los datos cambian de formato. Y lo que nadie se atreve a decir en voz alta: nadie se atreve a tocarla por miedo a romper algo.

El riesgo es doble. Por un lado, el bus factor (el número de personas que pueden desaparecer antes de que un proceso se detenga) es uno. Si la única persona que entiende la fórmula se va, el informe se convierte en una caja negra que produce números sin que nadie pueda verificar si son correctos. Por otro lado, la fórmula acumula rigidez: nadie la mejora, nadie la adapta a los cambios del negocio, nadie le añade las condiciones nuevas que harían falta. El informe se queda congelado en la lógica de hace dos años.

La solución: SQL o Python, según la complejidad de la lógica. Una consulta SQL con comentarios (-- filtro las ventas posteriores a la fecha de corte) se lee como un párrafo. Un script de Python con nombres descriptivos (margen_bruto = ingresos - coste_producto) se entiende sin necesitar a quien lo escribió. Ambos se pueden versionar con Git, lo que significa que si algo cambia, hay un historial que dice quién lo cambió, cuándo, y por qué. La lógica deja de estar escondida en celdas y pasa a estar escrita en texto legible.

### Síntoma 5: Cruzar más de dos fuentes

Cómo se manifiesta: necesitas un informe que combine datos de clientes (un fichero), pedidos (otro fichero) y productos (un tercero). En la hoja, eso significa un BUSCARV que trae el nombre del cliente al pedido, otro BUSCARV que trae la categoría del producto, y quizá un tercero que trae el coste del proveedor desde otra pestaña. Cada cruce depende de que las claves coincidan exactamente, de que las columnas no se hayan movido, y de que los rangos estén bien definidos. Si cualquiera de esas tres cosas falla, el cruce se rompe en silencio: la celda muestra #N/A o, peor, devuelve el valor equivocado.

El riesgo escala exponencialmente con cada fuente adicional. Dos fuentes son manejables con un BUSCARV cuidadoso. Tres fuentes ya requieren columnas auxiliares y lógica anidada. Cuatro fuentes son una pesadilla de mantenimiento donde cualquier cambio puede romper un cruce que está ocho columnas más a la derecha sin que nadie se entere. Y cada vez que una de las fuentes cambia su formato (una columna nueva, un nombre diferente, un dato más), hay que actualizar todos los cruces a mano.

La solución: SQL, sin discusión. En SQL, cruzar tres tablas es exactamente esto: FROM pedidos JOIN clientes ON pedidos.cliente_id = clientes.id JOIN productos ON pedidos.producto_id = productos.id. Tres líneas. Se lee de arriba abajo. Funciona igual con 100 filas que con 10 millones. No depende de la posición de las columnas. No se rompe si añaden filas. Y si una clave no coincide, puedes elegir qué hacer (LEFT JOIN para quedarte con todas las filas aunque falte el cruce, o INNER JOIN para quedarte solo con las que cruzan). Esa flexibilidad no existe en BUSCARV.

### Caso real: Carlos y el informe del lunes

Volvamos a Carlos, el analista de operaciones con el que abrimos la lección. Su historia es representativa porque acumula los cinco síntomas de forma gradual, como suele pasar en la realidad. Ninguna hoja se rompe de golpe: se deteriora poco a poco, hasta que un día el deterioro es visible para alguien que importa.

Contexto: Carlos trabaja en LogiRapid, una empresa de mensajería con 40 rutas de reparto y un almacén central. Su informe semanal mide el porcentaje de entregas a tiempo por ruta, por conductor y por franja horaria. El director de operaciones lo usa para decidir dónde poner un segundo turno y qué conductores necesitan refuerzo. Es un número que mueve decisiones de personal y de coste.

Año 1: la hoja funciona perfectamente. El CSV tiene 30.000 filas semanales. El fichero se abre en 3 segundos. Las fórmulas recalculan al instante. Carlos copia-pega el CSV nuevo cada lunes (síntoma 2, pero todavía no duele), y el informe está listo en 20 minutos. Nadie se queja.

Año 2: abren una segunda ruta de reparto nocturno. El CSV crece a 65.000 filas. La hoja tarda 12 segundos en recalcular (síntoma 1 emergiendo). El proceso del lunes ahora tarda 35 minutos porque tiene que esperar recálculos. Carlos añade tres columnas auxiliares con BUSCARV para cruzar las rutas con las zonas postales (síntoma 5 incipiente). La responsable de calidad monta su propia hoja con "los mismos datos pero filtrados distinto" (síntoma 3 plantado).

Año 3: abren un nuevo almacén. El CSV salta a 142.000 filas. La hoja tarda 35 segundos en abrir (síntoma 1 crítico). Carlos ha construido una fórmula de 180 caracteres que combina SI, Y, INDICE y COINCIDIR para clasificar los retrasos por causa (síntoma 4: nadie más la entiende). Y ese lunes descubre que el rango de SUMAR.SI.CONJUNTO no llega a las filas nuevas: el porcentaje de entrega a tiempo del nuevo almacén no se contaba. El informe llevaba tres semanas mostrando un rendimiento mejor del real. El director de operaciones había pospuesto una contratación porque "los números van bien". Los cinco síntomas están activos a la vez.

La transición: Carlos convence a su jefe de que necesita dos días para "arreglar el informe". Lo que realmente hace es reescribirlo desde cero con las herramientas correctas. El primer día escribe una consulta SQL que extrae las entregas de la semana de la base de datos del sistema de gestión de almacén. La consulta ocupa 22 líneas, tiene comentarios que explican cada paso, y produce exactamente la misma tabla que antes salía de copiar-pegar el CSV. Pero sin límite de filas, sin rangos fijos, y en 400 milisegundos.

El segundo día escribe un script de Python de 45 líneas que: ejecuta la consulta SQL, calcula los porcentajes por ruta y conductor, aplica formato condicional (verde si está por encima del objetivo, rojo si está por debajo), genera un fichero Excel con exactamente el mismo aspecto que el informe anterior, y lo envía por correo al director de operaciones. Lo programa para que se ejecute cada lunes a las 6:00 de la mañana.

El resultado: el lunes siguiente Carlos llega a la oficina y el informe ya está en la bandeja del director. No ha tenido que hacer nada. El director no nota ningún cambio en el formato — sigue recibiendo su Excel con colores. Pero detrás, los cinco síntomas han desaparecido: no hay fichero lento (SQL procesa las 142.000 filas en medio segundo), no hay proceso manual (Python lo hace solo), no hay versiones divergentes (todos consultan la misma base), no hay fórmula opaca (la lógica está en 22 líneas de SQL comentadas), y no hay cruces frágiles (los JOIN reemplazan a los BUSCARV).

### La anatomía de la transición: qué cambia y qué no

Hay un concepto clave que quiero que te lleves de la historia de Carlos: la transición no es un reemplazo, es una redistribución de roles. La hoja de cálculo no desaparece del flujo de trabajo. Lo que cambia es QUÉ hace cada herramienta. Antes de la transición, la hoja hacía todo: almacenar datos, calcular, cruzar fuentes, formatear y presentar. Después, cada herramienta hace lo que mejor sabe hacer.

Fíjate en algo crucial del diagrama: el entregable final no cambia. El director de operaciones de Carlos sigue recibiendo un fichero Excel con colores condicionales que puede abrir, filtrar y reenviar. La diferencia está en lo que hay detrás. Antes, detrás había una persona haciendo trabajo manual propenso a errores. Ahora, detrás hay un sistema autónomo que produce el mismo resultado sin intervención humana. El stakeholder no necesita saber que hay SQL y Python debajo. Solo necesita que su informe llegue puntual y correcto.

### La migración no es un evento: es un proceso gradual

Otra lección de la historia de Carlos: no intentó migrar todo el primer día. Lo hizo en orden de impacto. Primero resolvió el problema más crítico (la extracción con SQL, que eliminó el error de rango). Después automatizó (Python). El formato y la presentación los dejó igual. Si hubiera intentado rehacer todo de golpe — nuevo formato, nueva presentación, nuevas métricas — habría tardado dos semanas en vez de dos días, y el director habría dicho "me gustaba más como estaba antes".

1. 01.Fase 1: Sustituir el copiar-pegar por una consulta SQL. Es el cambio de menor riesgo y mayor impacto. Los datos vienen de la base de datos directamente, sin pasar por un CSV intermedio. Eliminas el síntoma 1 (volumen) y reduces el riesgo del síntoma 5 (cruces frágiles).
2. 02.Fase 2: Envolver la consulta en un script de Python que genera el fichero final. Eliminas el síntoma 2 (repetición manual). El script hace en 5 segundos lo que antes tardaba 40 minutos.
3. 03.Fase 3: Programar la ejecución automática. El script se ejecuta cada lunes sin que nadie intervenga. Eliminas la dependencia de una persona (parte del síntoma 4).
4. 04.Fase 4: Compartir la consulta SQL con los demás equipos. Todos usan la misma fuente. Eliminas el síntoma 3 (versiones divergentes). Y la consulta, con sus comentarios, es legible para cualquiera (elimina el resto del síntoma 4).

En cada fase, el entregable sigue siendo el mismo: un Excel con el formato que el director espera. Lo que cambia es cómo se produce. Y en cada fase, el proceso es reversible: si algo sale mal, puedes volver al paso anterior sin que nadie lo note. Esa reversibilidad es clave para que tu jefe te deje hacer la transición sin nervios.

El resultado final de las cuatro fases es un patrón de trabajo profesional que vas a ver en todos los equipos de análisis serios: extraes con SQL, transformas con Python, y presentas en hoja o dashboard. Cada herramienta en su sitio. El siguiente diagrama muestra ese flujo completo — es el cinturón del analista que ya ha dado el salto.

### Los tres pasos que hunden una migración, y que nadie cuenta

Hasta aquí has visto cuándo migrar y en qué orden. Falta lo que de verdad decide si la migración sale bien, y son tres cosas que no aparecen en ningún curso porque no son técnicas. Son de oficio.

La primera: comprobar que los números nuevos son los viejos. Antes te he dicho que la consulta de Carlos produce exactamente la misma tabla que su hoja, y no te he dicho cómo lo comprobó. Así se hace: se ejecutan los dos procesos EN PARALELO durante dos o tres ciclos —dos o tres lunes, en su caso— y se comparan los resultados número a número, no "a ojo". Nada de sustituir el viernes y rezar. Y hay que documentar las diferencias que salgan, aunque parezcan pequeñas, porque cada una es una decisión escondida de la hoja vieja que hay que entender antes de tirarla.

Prepárate para lo que va a pasar en esa comparación, porque pasa casi siempre: cuando los números no coincidan, el que estará mal será el ANTIGUO. Es literalmente lo que le pasó a Carlos, con el rango de SUMAR.SI.CONJUNTO que no llegaba a las filas nuevas. Y ése es el momento más delicado de todo el proceso, porque no es técnico: es político. La tentación es decir "lo veis, la hoja estaba mal". No lo hagas. Acabas de demostrar que el informe con el que se han tomado decisiones durante años tenía un fallo, y si lo presentas como una victoria personal convertirás a quien lo mantenía —que puede ser tu jefe— en el culpable. Preséntalo como lo que es: el proceso nuevo encuentra cosas que el anterior no podía ver. Con esa frase tienes a esa persona de tu lado. Sin ella, la tienes enfrente el resto del proyecto.

La segunda: decidir qué se hace con la hoja vieja. Si el fichero se queda en la carpeta compartida y sigue calculando, esto es lo que va a pasar, y es cuestión de semanas: alguien que estaba de vacaciones lo abre por costumbre, saca un número, y ese número no coincide con el del proceso nuevo. Has vuelto al síntoma 3 —dos versiones del mismo número— pero ahora contra un zombi que nadie mantiene, y es peor que antes porque el zombi tiene el aspecto del informe oficial de toda la vida. La retirada tiene tres pasos: dejar el fichero en solo lectura, renombrarlo con un aviso claro (algo tan tonto como "OBSOLETO — usar el informe automático" delante del nombre funciona), y moverlo a una carpeta de archivo. No lo borres: guárdalo, porque durante un tiempo vas a necesitar volver a mirarlo para explicar una diferencia.

Y la tercera, que es el bloqueo real de casi todo el mundo que lee esta lección: ¿qué haces si no hay ninguna base de datos? Toda la migración que te he contado asume que existe un sitio donde consultar con SQL. Y el caso frecuente de un analista junior es el contrario: no tiene acceso a nada, solo tiene ficheros que le manda alguien por correo. La buena noticia es que no necesitas una base de datos ni permisos ni pedirle nada a sistemas.

DuckDB lee un CSV como si fuera una tabla. Es un fichero ejecutable que te descargas, no un servidor que haya que instalar y administrar: no hay usuarios, no hay puertos, no hay que abrir un ticket. Le apuntas a tu CSV y le escribes SQL encima. Y no es una versión de juguete: aguanta ficheros que Excel no abre, y es exactamente el motor con el que has estado practicando SQL en este curso. Así que el "no tengo base de datos" deja de ser un bloqueo: tu carpeta de exports YA es tu base de datos, solo le faltaba alguien que le hablara en SQL.

1-- Sin instalar un servidor, sin permisos, sin pedirle nada a nadie:
2-- consultar directamente el CSV que te acaba de llegar por correo.
3SELECT
4    ruta,
5    COUNT(*)                                        AS entregas,
6    ROUND(AVG(CASE WHEN a_tiempo THEN 1 ELSE 0 END) * 100, 1) AS pct_a_tiempo
7FROM 'entregas_semana.csv'
8GROUP BY ruta
9ORDER BY pct_a_tiempo;

### La hoja sigue en el cinturón

Quiero insistir en esto porque va contra la narrativa de muchos cursos: aprender SQL y Python no convierte la hoja de cálculo en una herramienta obsoleta. La convierte en una herramienta mejor utilizada. Un analista senior con diez años de experiencia y dominio de SQL, Python y tres herramientas de visualización sigue abriendo una hoja de cálculo cada semana. La usa para prototipar un cálculo rápido, para presentar un resultado a alguien no técnico, para explorar un CSV pequeño antes de decidir si merece un script. La hoja es la servilleta del analista: rápida, barata, sin compromiso.

Lo que ese analista senior NO hace es forzar la hoja para cosas que no puede hacer bien. No cruza cinco tablas con BUSCARV. No mantiene un informe semanal a mano. No construye fórmulas de 200 caracteres que solo él entiende. Sabe dónde termina la hoja y dónde empieza SQL. Sabe dónde termina SQL y dónde empieza Python. Y sabe que a veces la respuesta correcta es "esto se responde con un filtro en 10 segundos, no necesito ni abrir la terminal". Ese criterio — saber elegir la herramienta correcta para cada situación — es exactamente lo que separa a un junior de un mid.

### Resumen: las tres ideas que cierran el módulo

Has terminado el módulo de hojas de cálculo. Sabes escribir fórmulas, construir una tabla dinámica, limpiar datos en una hoja, y ahora reconoces cuándo la hoja se ha quedado corta. Vamos a cerrar con tres ideas que te acompañan a partir de aquí:

1. 01.Los cinco síntomas son tu sistema de alerta temprana. Fichero lento, informe repetitivo, dos versiones del mismo número, fórmula que nadie entiende, cruces de más de dos fuentes. Cuando detectas dos o tres juntos, es momento de añadir herramientas al cinturón.
2. 02.La transición es gradual y reversible. No migras todo el lunes por la mañana. Empiezas por el paso que más duele (normalmente la extracción de datos con SQL), mantienes el entregable igual, y vas añadiendo capas. En cada paso puedes volver atrás.
3. 03.La hoja no es una herramienta que se abandona: es una herramienta que se reposiciona. Pasa de hacerlo todo (mal) a hacer lo que mejor sabe (presentar, explorar, prototipar). SQL y Python no la sustituyen: la liberan.