Por qué Excel y Sheets siguen siendo lo que te va a pedir tu jefe

Es 1979. Dan Bricklin es un estudiante de MBA en Harvard que odia una cosa con toda su alma: recalcular a mano las proyecciones financieras cada vez que cambia un supuesto. Sentado en clase, ve a su profesor rehacer a mano una tabla entera en la pizarra porque uno de los supuestos ha cambiado. Todas las filas que dependían de ese número hay que recalcularlas. Una por una. A mano. Bricklin piensa: si esto fuera una pantalla donde las celdas se recalcularan solas al cambiar un valor, me ahorraría horas. Y con esa idea, junto a Bob Frankston, programa VisiCalc: la primera hoja de cálculo para ordenadores personales.

Merece la pena precisar ese último matiz, porque hace la historia mejor. La idea de una rejilla que se recalcula sola no era nueva: había habido hojas de cálculo informatizadas en grandes ordenadores desde los años sesenta. Lo que VisiCalc aportó no fue el concepto, fue ponerlo delante de una persona que no era programadora, en una máquina que su empresa podía comprar. Ésa es toda la diferencia, y es la misma que explica por qué la hoja sigue viva cuarenta y siete años después: no gana la herramienta más potente, gana la que está en las manos de quien tiene la pregunta.

VisiCalc no era un programa más. Era LA razón por la que una empresa compraba un Apple II. Por primera vez, un directivo podía sentarse delante de un ordenador (computadora) y hacerse preguntas del tipo "si subo el precio un 10%, cuánto suben los beneficios" sin pedirle a nadie que recalculara. Podía cambiar un número y ver el efecto en cascada al instante. Eso, que hoy nos parece trivial, en 1979 era magia. Y cambió para siempre cómo se toman decisiones en una empresa.

### De VisiCalc a Lotus a Excel: cómo la hoja conquistó el mundo

La historia se puede contar en tres actos. VisiCalc (1979) demostró que la idea funcionaba. Lotus 1-2-3 (1983) la convirtió en un estándar corporativo: era más rápida, tenía gráficos integrados y corría en el IBM PC, que es el ordenador que los departamentos de IT compraban. Y Excel (1985 en Mac, 1987 en Windows) hizo dos cosas que Lotus no supo hacer: una interfaz gráfica con ratón, y una apuesta total por Windows cuando Lotus seguía atada a DOS.

Lotus 1-2-3 dominó los ochenta como pocos programas han dominado una década. Pero cometió un error estratégico mortal: tardó demasiado en saltar a Windows. Su primera versión para Windows es de 1991, cuando Excel llevaba ya cuatro años en esa plataforma y había definido cómo se sentía una hoja de cálculo con ratón. Para 1995, la guerra había terminado. Excel era el estándar, y Lotus pasó a ser una anécdota histórica.

Lo que nos importa de esta historia no son los nombres: es lo que revela sobre por qué la hoja sigue viva. La hoja de cálculo no ganó porque fuera la mejor tecnología. Ganó porque resolvió un problema universal: "tengo números y quiero ver qué pasa si cambio uno". Eso lo necesita el director financiero, la jefa de operaciones, el comercial que calcula comisiones y el fundador que hace su primer presupuesto. Ninguna otra herramienta ha conseguido esa universalidad en casi cincuenta años.

### Por qué la hoja sigue ganando hoy

Hay quien dice que "Excel es para principiantes" con el mismo tono con el que diría "un destornillador es para aficionados". Y se equivoca de la misma manera. Un destornillador no es inferior a un taladro: resuelve un problema distinto, y para ese problema es la respuesta correcta. Lo mismo pasa con la hoja de cálculo. No es que sea fácil (que lo es para empezar): es que tiene propiedades que ninguna otra herramienta replica.

La hoja de cálculo tiene cinco superpoderes que explican su longevidad. No son cinco funcionalidades: son cinco razones por las que un profesional con acceso a SQL, Python y un almacén de datos sigue abriendo una hoja cada semana.

1. 01.Retroalimentación inmediata. Escribes un número, la fórmula se recalcula. No hay que compilar, ejecutar, esperar un resultado. La distancia entre la pregunta y la respuesta es cero segundos. Eso permite pensar con los datos delante, no sobre los datos en abstracto.
2. 02.Superficie de manipulación directa. Puedes arrastrar, copiar, seleccionar un rango, colorearlo, insertar una columna auxiliar, borrarla si no funciona. No hay un lenguaje intermedio entre tu intención y la acción: para casi todo basta el ratón.
3. 03.Audiencia universal. Tu jefe sabe abrir un Excel. El director financiero sabe abrir un Excel. La persona de Recursos Humanos sabe abrir un Excel. Cuando entregas un fichero (archivo) .xlsx, NADIE tiene que instalar nada para verlo. Cuando entregas un script de Python, casi ninguna de las personas que esperan tu trabajo puede ejecutarlo.
4. 04.Formato y análisis en el mismo sitio. Puedes calcular un margen, ponerlo en negrita, añadirle un color condicional si baja del 20%, y enviarlo por correo. El informe ES la herramienta. En SQL calculas el número; después necesitas otro programa para presentarlo.
5. 05.Exploración sin compromiso. Abres un CSV, miras una columna, calculas un promedio rápido, lo borras, pruebas otra cosa. No has tenido que escribir un script, crear un fichero, nombrarlo, decidir dónde guardarlo. La barrera de entrada es cero.

### Dónde la hoja se rompe: los cinco límites reales

Dicho todo lo anterior, la hoja de cálculo tiene límites. Y no son los que la gente cree. El límite no es "un millón de filas" (ese es un síntoma). Los límites reales son situaciones donde la hoja deja de ser fiable o eficiente, y necesitas saltar a otra herramienta. Vamos a verlos uno por uno, porque cada uno te va a pasar al menos una vez en tu carrera.

1. 01.Volumen. Y aquí conviene no dar un número suelto, porque el umbral no depende solo de cuántas filas hay: depende de lo que haya EN cada fila. Cincuenta mil filas de datos planos no le molestan a nadie; cincuenta mil con un BUSCARV en cada una, sí. Hay tres cifras que no hay que mezclar, porque cada una es un límite distinto. El límite duro de Excel son 1.048.576 filas por hoja: pasado eso, el fichero simplemente no las guarda. Google Sheets no tiene límite de filas, tiene límite de CELDAS: diez millones en total y hasta 18.278 columnas, así que con veinte columnas te quedas en medio millón de filas y con cien columnas en cien mil. Y el límite práctico llega mucho antes que los dos: con unas cincuenta mil filas y fórmulas que recalculan en cascada ya notas la lentitud, y con cien mil y un BUSCARV por fila el fichero se vuelve inutilizable, con tablas dinámicas que tardan y ficheros que no caben en un correo. El que te va a doler es el tercero, no el primero. En SQL, cien mil filas es nada: una consulta sobre millones tarda milisegundos si la tabla tiene un índice.
2. 02.Repetición. Si cada lunes abres el mismo fichero, copias los datos nuevos, ajustas las fórmulas y generas el informe, tienes un trabajo que debería estar automatizado. Cada paso manual es una oportunidad para un error. Un script de SQL o Python hace ese lunes en tres segundos, sin errores, todas las semanas.
3. 03.Versiones y fuente única. informe_final.xlsx, informe_final_v2.xlsx, informe_final_BUENO.xlsx. Si hay dos personas tocando el mismo fichero, nadie sabe cuál es la versión correcta. Google Sheets resuelve parte de esto con la edición simultánea —un solo fichero, sin copias— pero no resuelve el problema de fondo: que la misma pregunta se pueda seguir respondiendo de dos maneras distintas en dos hojas distintas. Y hay una versión peor del mismo problema, que no se arregla con un solo fichero: dos personas parten del mismo export, cada una monta su hoja, y salen dos números distintos. No hay copias que reconciliar, hay dos cálculos, y ninguno de los dos es "el oficial".
4. 04.Auditabilidad. Alguien cambia una fórmula y el margen pasa del 22% al 28%. Si no lo ves, no lo sabes — y aquí hay que ser preciso, porque es lo que te van a discutir. Historial HAY: Google Sheets guarda el historial de edición de cada celda (clic derecho sobre la celda y te dice quién, cuándo, y de qué valor a qué valor), y Excel hace lo mismo con "Mostrar cambios" si el fichero vive en OneDrive o SharePoint. Lo que no hay es nada de lo que convierte un historial en una auditoría. No hay motivo: el historial te dice que la celda F42 pasó de 0,22 a 0,28, no por qué, ni quién lo aprobó, ni qué se decidió en la reunión donde se cambió. No hay revisión previa: el cambio ya está aplicado y el informe ya se ha enviado, mientras que en SQL puedes leer una consulta antes de ejecutarla. No se lee la lógica, se leen celdas: aunque veas los trescientos cambios de la semana, no verás "cambiamos la definición del margen", verás trescientas celdas. Y nadie lo mira: el historial es reactivo, hay que sospechar primero para ir a buscarlo, y nadie revisa el historial de una hoja los lunes. En SQL la consulta está en un sitio, se lee entera, se guarda en un repositorio con el motivo del cambio al lado, y otra persona puede revisarla antes de que se aplique. Ésa es la diferencia: no es que la hoja no registre, es que registrar no es lo mismo que poder responder "por qué este número es este".
5. 05.Cruce de fuentes. Necesitas cruzar la tabla de clientes con la de pedidos y la de productos. En SQL es un JOIN de tres líneas. En Excel es un BUSCARV anidado dentro de otro BUSCARV, con una columna auxiliar que nadie entiende seis meses después. Y si la tabla de origen cambia de formato, todo se rompe en silencio.

### El mapa de decisión: hoja, SQL o Python

La pregunta no es "cuál es mejor". La pregunta es "cuál es la correcta para ESTA situación". Y la respuesta depende de tres variables: cuánto dato hay, cuántas veces vas a repetir el trabajo, y quién tiene que entender el resultado. Vamos a convertir esto en una guía que puedas aplicar el lunes por la mañana.

Fíjate en que el diagrama no es una escalera. No es "empiezas con Excel, subes a SQL, y luego a Python como si fuera un ascenso". Es una caja de herramientas. Un analista senior con diez años de experiencia sigue abriendo una hoja de cálculo para hacer un cálculo rápido, igual que un carpintero con treinta años de oficio sigue usando un lápiz para marcar la madera antes de cortar.

### Casos reales: cuándo la hoja es la respuesta correcta

Para que esto no quede en teoría, aquí van tres situaciones reales donde un analista elige la hoja con total legitimidad:

• ▹El presupuesto anual. Finanzas te pide una proyección de costes para el próximo trimestre. Son 40 filas (una por partida), con tres escenarios (optimista, neutro, pesimista). La tabla dinámica no aporta nada. SQL no aporta nada. Necesitas una hoja donde el CFO (director financiero) pueda cambiar el tipo de interés y ver cómo cambia el resultado. Hoja de cálculo, sin dudarlo.
• ▹La investigación ad-hoc. Marketing te pregunta «oye, ¿cuántas ventas hicimos en Sevilla la semana pasada?». Son tres clics: abres el export del CRM (sistema de gestión de clientes), filtras por ciudad, filtras por fecha, y lees el total. Si tardas más de un minuto en abrir un script de Python para esto, estás perdiendo tiempo por purismo.
• ▹El prototipo de informe. No sabes todavía qué métricas va a querer el director de operaciones. Abres una hoja, pones tres columnas, calculas unos ratios, le enseñas el borrador en la reunión. Si le gusta, lo formalizas en SQL. Si no, lo borras sin haber invertido una hora en un script. La hoja es un boceto barato.

### Excel vs Google Sheets: cuál elegir

Hoy, la mayoría de equipos de análisis usan Google Sheets para el trabajo colaborativo y Excel para ficheros pesados o cuando necesitan funciones avanzadas (Power Query, tablas dinámicas complejas, conexiones a bases de datos). No es una guerra: son dos sabores de lo mismo, como Word y Google Docs.

• ▹Google Sheets gana en: colaboración en tiempo real (varias personas editando a la vez), acceso desde cualquier dispositivo sin instalar nada, historial de versiones y de celda sin configurar nada (en Excel eso exige que el fichero esté en la nube y suscripción de Microsoft 365), y conectores nativos a otras herramientas de Google.
• ▹Excel gana en: rendimiento con ficheros grandes (Sheets empieza a ir lento con 50.000 filas, Excel aguanta más), funciones avanzadas (Power Query, modelo de datos, VBA para macros), y compatibilidad con el mundo corporativo donde el formato .xlsx sigue siendo el estándar de intercambio.
• ▹En la práctica: usa Sheets para el trabajo del día a día que compartes con tu equipo. Usa Excel cuando el fichero pesa, cuando necesitas Power Query para limpiar datos, o cuando tu empresa te obliga por política de seguridad.

### La hoja como puente hacia SQL

Aquí está la clave que muchos cursos no te cuentan: la hoja de cálculo y SQL no son mundos separados. Son dos formas de hacer lo mismo: manipular tablas. Un BUSCARV es un LEFT JOIN. Una tabla dinámica es un GROUP BY con varias dimensiones. Un filtro es un WHERE. Si ya sabes pensar en una hoja, ya sabes pensar en SQL. Solo te falta la sintaxis.

Esta tabla no es decorativa. Guárdala mentalmente, porque cada vez que aprendas una función de hoja en las próximas lecciones, te voy a recordar su equivalente en SQL. Y cada vez que en SQL encuentres un concepto nuevo, lo voy a anclar a lo que ya sabes de la hoja. El aprendizaje no va de olvidar lo anterior: va de construir puentes.

Un aviso antes de fiarte de la tabla, porque la primera fila tiene un tablón flojo y conviene saber que está ahí. La equivalencia entre BUSCARV y JOIN es real, pero no es exacta: hay dos sitios donde se rompe, y los dos tienen que ver con qué pasa cuando la clave no aparece exactamente una vez en la otra tabla. Si no aparece ninguna, el BUSCARV deja la fila con un aviso y el JOIN se la lleva por delante. Si aparece dos veces, el BUSCARV escoge una y el JOIN te da las dos. Ninguna de las dos cosas da error, y las dos cambian el total. La lección de las búsquedas entra en el detalle de cada una y da la comprobación que las caza; por ahora quédate con la regla: antes y después de traducir, cuenta las filas. Si el número cambia, no has traducido, has cambiado la pregunta.

Y un matiz sobre SUMAR.SI que ahorra confusión, porque casi todo el mundo lo dice mal. Un SUMAR.SI suelto no es un GROUP BY: es un WHERE con una suma, una condición y un número. El equivalente exacto es SELECT SUM(importe) FROM ventas WHERE categoria = 'Bebidas', que devuelve una sola fila. Se convierte en GROUP BY cuando escribes al lado la lista de categorías distintas y arrastras la fórmula: ahí estás sacando a mano los valores únicos que el GROUP BY saca solo. Y esa tarea de "lista de valores únicos más un cálculo por cada uno", hecha con el ratón y sin arrastrar nada, tiene un nombre: tabla dinámica, y tiene su propia lección más adelante en este módulo.

### Lo que la hoja te enseña sin que te des cuenta

Hay algo más profundo que las fórmulas. La hoja de cálculo te enseña a pensar en tablas. Filas son registros (cada venta, cada cliente, cada pedido). Columnas son atributos (nombre, fecha, importe). Una celda es la intersección de un registro y un atributo. Eso es exactamente lo que es una base de datos relacional. Si has trabajado con una hoja, ya tienes la intuición que mucha gente tarda semanas en desarrollar cuando aprende SQL desde cero.

También te enseña a pensar en tipos de datos sin llamarlos así. Sabes que si sumas una fecha y un número obtienes otra fecha. Sabes que un texto no se puede multiplicar. Y probablemente te has topado con algo más raro: escribe =(43,1-43,2)+1 en una celda y te va a devolver 0,899999999999999, no 0,9. No es un error de Excel: es que el ordenador guarda los números en binario y hay decimales que en binario no caben exactos, igual que un tercio no cabe exacto en decimal. Excel disimula ese problema cuando el resultado se acerca a cero —por eso 0,1+0,2-0,3 sí da cero limpio, hay una compensación deliberada desde Excel 97— pero en cuanto te alejas de cero asoma. Todo eso son lecciones de tipos de datos, precisión numérica y redondeo que en programación se formalizan con nombres técnicos, pero tú ya las has vivido en la hoja.

### Resumen: las tres reglas de la hoja

Antes de cerrar, tres reglas que te van a acompañar en las próximas lecciones y en tu carrera:

1. 01.Si puedes responder la pregunta en menos de cinco minutos con una hoja, hazlo en la hoja. No abras VS Code por principio.
2. 02.Si vas a repetir el mismo análisis más de tres veces, automatízalo. La primera vez está bien hacerlo a mano. La cuarta, ya no.
3. 03.Si dos personas tienen dos versiones del mismo número, la hoja ha dejado de ser suficiente. Necesitas una fuente única de verdad, y eso es una base de datos con una consulta que cualquiera puede ejecutar y obtener el mismo resultado.