Tu hoja de cálculo de inventario se romperá con 10k SKU
Con ~10k SKU, variantes y ubicaciones, una hoja de cálculo de inventario se vuelve lenta y propensa a errores. Los cuatro modos de fallo — y la ruta de migración a una base de datos.
El problema
Tu inventario vive en una hoja de cálculo. No porque alguien lo eligiera deliberadamente — era gratis, familiar y todo el mundo sabía usarla. Funcionó con 500 SKU. Funcionó, lentamente, con 2.000. Luego la línea de productos creció: variantes, colores, tallas, tres proveedores, dos almacenes, una tienda de Shopify además de una lista mayorista, y alguien empezó a llevar un registro de movimientos en una segunda pestaña “solo por historial”.
Esa hoja de cálculo es ahora la herramienta más cara de tus operaciones, y la factura aparece en lugares extraños. Los pedidos se sobrevenden porque dos personas editaron la misma cantidad a la vez. Hay stock en un almacén mientras la hoja dice que está agotado. El equipo deja de confiar en los números y empieza a recontar a mano. Nadie actualiza ya la hoja, porque actualizarla tarda demasiado y nadie cree el resultado.
Este artículo trata sobre el momento en que un inventario en hoja de cálculo se rompe: los cuatro modos de fallo, por qué ocurre alrededor de 10.000 SKU (no en el límite teórico de filas) y cómo es “lo real” cuando la hoja se sustituye por una pequeña base de datos con una interfaz fina y buscable.
Los cuatro modos de fallo
1. Buscar y filtrar se derrumba
Encontrar un SKU se convierte en un ritual. Pegas un código en el filtro, la hoja se congela varios segundos y te muestra tres filas — y una de ellas es la del variante equivocado, porque la búsqueda coincidió con el código del proveedor en una columna lejana.
Con 10.000 SKU y una media de tres variantes cada uno, solo los datos maestros son decenas de miles de filas y más de 20 columnas. Los filtros se recalculan sobre cada fila, y la gente deja de usarlos en silencio — memoriza una ruta alternativa o le pregunta a un compañero que “sabe dónde están las cosas”. Cada pregunta se convierte en una reunión.
2. Las ediciones simultáneas corrompen las cantidades sin avisar
Una cantidad en una hoja de cálculo es solo una celda. Dos personas pueden abrir la hoja, ver ambas stock = 40 y cambiarla — una a 37 tras una venta, otra a 52 tras una entrega. Las hojas resuelven el conflicto con “el último que escribe gana”, y nadie ve al perdedor. Sobrevive la edición que llegó al final, no la que era cierta.
En inventario esto es peor que en cualquier otra función, porque el bucle de corrección es lento. La cantidad errónea vive en la hoja durante días y genera puntos de reposición equivocados, promesas de disponibilidad falsas a los clientes y cifras erróneas en el lado de compras. Cuando alguien se da cuenta, la hoja y el almacén discrepan en un margen que tarda horas en conciliarse.
3. El recálculo de fórmulas convierte cada edición en una espera
Las hojas de inventario dependen de búsquedas de columna completa — VLOOKUP, SUMIFS, QUERY, IMPORTRANGE — para acumular cantidades y costes entre pestañas. Cada edición dispara un recálculo que toca decenas de miles de celdas. Abres la hoja y te quedas mirando un spinner; haces una edición y vuelves a esperar.
La solución que agrava el problema: el equipo agrupa las ediciones y las hace a última hora del día para no ver cómo la hoja se arrastra. Pero entonces los números solo están al día unas horas al día, y cualquier decisión tomada fuera de esa ventana se basa en datos obsoletos.
4. Las integraciones convierten la hoja en una foto del pasado
La hoja de cálculo rara vez contiene la verdad del inventario por sí sola — importa de Shopify, del almacén, de la lista mayorista. Cada integración es un paso manual: exportar un CSV, transformarlo, importarlo, esperar que los formatos cuadren. Cada ida y vuelta envejece al instante: la hoja es una fotografía del stock, tomada en el momento en que alguien pulsó “importar”.
En cuanto tu tienda depende de un inventario casi en tiempo real (disponibilidad pública, automatización de reposición, cumplimiento multi-almacén), la hoja deja de ser una herramienta y se convierte en un pasivo. Los comercios de Shopify lo notan primero: el inventario de la plataforma es en tiempo real, y la hoja que la acompaña es la única fuente de verdad que está garantizado que se equivoque.
Por qué se rompe alrededor de los 10k SKU, no en el límite
Los límites publicados son grandes: Google Sheets limita a 10 millones de celdas por libro y Excel llega a 1.048.576 filas por 16.384 columnas. Una lista limpia de 10.000 SKU cabe holgada en ambos.
El problema es que el inventario nunca es una lista limpia. Son datos maestros, multiplicados:
| Elemento | Filas o celdas |
|---|---|
| 10.000 SKU × 3 variantes cada uno | 30.000 filas de datos maestros |
| × más de 20 columnas (código de barras, proveedor, coste, precio, cantidad por ubicación, punto de reposición…) | Más de 600.000 celdas |
| 2 almacenes + Shopify + mayorista = 4 ubicaciones, cada una con su columna de cantidad | ×4 columnas de cantidades |
| Registro diario de movimientos, 10.000 SKU × 180 días de historial | 1,8 millones de filas |
| Fórmulas, formato condicional, tablas IMPORTRANGE encima | Cada recálculo recorre todo |
Un registro de movimientos solo — una fila por SKU y día durante seis meses — son 1,8 millones de filas, que no caben en Excel en absoluto. En Sheets se extiende entre pestañas, y cada búsqueda entre pestañas multiplica el coste de recálculo. La edición multiusuario y las integraciones se apilan encima de una hoja que ya estaba al borde.
La forma honesta de leer el “10k” del título: no es el punto en que el archivo deja de abrirse, sino el punto en que la precisión, la velocidad y la confianza de la hoja fallan a la vez — y cada solución improvisada agrava el siguiente problema.
Cómo es “lo real”: Postgres + una interfaz fina
Cuando un inventario en hoja de cálculo se rompe, la sustitución no es una hoja más grande. Es una pequeña base de datos relacional — PostgreSQL es la elección habitual — con una interfaz deliberadamente fina encima. El alcance es pequeño, que es la gracia: unas pocas tablas y un buscador ganan a un libro de 12 pestañas.
El modelo es inventario normalizado, que es una forma educada de decir que los datos se guardan una vez y se cuentan en todas partes:
products (one row per product: name, barcode, supplier, cost, price, status)
variants (one row per variant: product_id, sku, option values)
locations (warehouse A, warehouse B, Shopify, wholesale)
stock_levels (one row per variant × location: quantity, updated_at)
movements (one row per stock change: variant_id, location_id, delta, reference, at)Cuatro propiedades lo diferencian de la hoja de cálculo:
- Las consultas duran milisegundos a cualquier escala. Una búsqueda filtrada en una tabla de 100k filas es una consulta por índice, no un escaneo de columna entera. Nadie de tu equipo vuelve a esperar por los números.
- Las escrituras son atómicas. Una venta que descuenta stock en dos ubicaciones es una transacción — o tiene éxito o no lo tiene. No hay edición parcial ni colisión de “el último escribe gana” entre dos personas.
- El historial es algo inherente. Cada movimiento es una fila en
movements. Puedes responder “¿cuánto había el martes y por qué cambió?” — la pregunta que una hoja no puede responder sin una pista de auditoría que nadie mantenía. - La interfaz es un buscador, no una cuadrícula. Escanea un código de barras y ve el variante, sus ubicaciones, sus cantidades y sus movimientos recientes — en una sola pantalla. Tu equipo lee menos celdas, no más.
Esto no es un proyecto de gran empresa. Para una operación de 10k SKU, el desarrollo son unos pocos días de trabajo: las cuatro tablas anteriores, la importación desde la hoja actual y la pantalla fina. Las ampliaciones — sincronización con Shopify, alertas de reposición, órdenes de compra — se añaden después, una a una, sobre el mismo modelo.
La ruta de migración que no asusta a nadie
Salir de una hoja de cálculo no exige un cambio brusco. El patrón que funciona con un negocio en marcha es el mismo que se usa en cualquier migración de datos:
- Esquema primero. Define las cuatro tablas y carga una copia de los datos maestros en ellas — no en producción, solo en una base de datos de prueba.
- Importación con punto de control. La exportación de Sheets o Excel se valida fila a fila: los SKU inválidos, los costes que faltan y los productos sin ubicación se notifican, no se descartan en silencio. Arreglas los datos una vez en la hoja, reimportas y ves cero errores.
- Ejecución en paralelo. La base de datos corre junto a la hoja durante dos a cuatro semanas. Todos siguen usando la hoja; el equipo contrasta la base de datos contra ella. Cuando la base de datos es correcta en todas las comprobaciones, la confianza ya se ha trasladado.
- Corte. La hoja se convierte en referencia de solo lectura y luego en un artefacto de exportación. La base de datos es la herramienta que la gente abre por la mañana.
Una nota honesta: es el mismo viaje que trasladar cualquier dato de negocio fuera de las hojas, y el patrón general (incluido el truco de la ejecución en paralelo) está en Cuando Google Sheets deja de escalar. Este artículo es la versión específica de inventario: las cuatro tablas anteriores y el buscador son todo el punto.
Antes y después, en números
Un perfil concreto: 10.000 SKU, dos almacenes más una tienda de Shopify, 250 pedidos al día, cinco personas que tocan el inventario.
| Hoja de cálculo | Postgres + interfaz fina | |
|---|---|---|
| Responder “¿cuántas unidades de X hay en el almacén B?“ | 20–60 segundos de filtrado, y luego dudas | ~1 segundo, de fiar |
| Tiempo diario de conciliación de stock | 1–2 horas de contrastar | 10 minutos de revisión de excepciones |
| Dos personas editan la misma cantidad | Corrupción silenciosa de “el último gana” | Una transacción atómica, la segunda escritura espera |
| Historial de movimientos | ”En realidad no lo tenemos” | Cada cambio, para siempre |
| Precisión de disponibilidad en Shopify | Obsoleta hasta la última importación manual | En tiempo real al minuto |
| Mantenimiento mensual de la hoja | Continuo, no pagado, inevitable | Ninguno |
Lo importante de la comparación no es la tecnología — es que la versión en hoja de cálculo de esta operación ya no es una herramienta, sino un empleado a tiempo parcial cuyo único trabajo es mantener los números aproximadamente correctos.
Resumen
| Preocupación | Hoja de cálculo | Postgres + interfaz fina |
|---|---|---|
| Velocidad con 10k+ SKU | Segundos o minutos por búsqueda | Consultas en milisegundos |
| Ediciones simultáneas | Corrupción silenciosa de “el último gana” | Transacciones atómicas |
| Historial / pista de auditoría | Ninguno | Integrado en movements |
| Integraciones (Shopify, almacén) | Manuales, obsoletas al llegar | En tiempo real, vía API |
| Esfuerzo mensual | Mantenimiento infinito no pagado | Casi cero |
Si tu equipo sigue conciliando el inventario en una hoja de cálculo — o peor, ha dejado de confiar en ella y ha empezado a recontar a mano — la solución es una pequeña base de datos con un buscador, no una hoja más grande. Para los comercios de Shopify, el caso de los bundles muestra exactamente cómo falla la hoja bajo presión de pedidos: Corregir los SKU de bundles de Shopify sin caos en hojas de cálculo lo recorre con un patrón de automatización real.
Este artículo forma parte de mi serie sobre cuando las hojas de cálculo dejan de escalar y de la serie de automatización de Shopify. Si tu hoja de inventario ya es lenta, reserva una llamada de encaje de 20 minutos — analizaré tu configuración y te diré exactamente cuántos días, no meses, cuesta la migración.