La historia se repite con variaciones mínimas en decenas de laboratorios: alguien monta una hoja de Google Sheets para llevar las fórmulas del departamento porque el Excel de toda la vida vivía en el portátil de una sola persona y daba miedo. La hoja compartida es, sin exagerar, una mejora real. Todo el equipo ve lo mismo, no hay archivos duplicados enviados por correo, y los cambios quedan en un único sitio.
La primera ronda de desarrollo con la hoja nueva va bien. La segunda, también. El problema aparece casi siempre en la tercera, y conviene saber por qué antes de que pase, no después.
Por qué las dos primeras rondas van bien
Una hoja de cálculo — o Airtable, que añade formularios, vistas filtradas y algo de estructura relacional sobre la misma idea base — resuelve perfectamente lo que resolvía el Excel de un solo archivo, pero compartido: composición de la fórmula, columna de porcentaje, columna de coste unitario multiplicado por cantidad. Para un producto sencillo con pocas revisiones, es rápido de montar y cualquiera del equipo sabe usarlo sin formación.
Airtable añade una capa que Sheets no tiene de fábrica: tablas relacionadas (una tabla de ingredientes enlazada a una tabla de fórmulas), vistas por estado, y algo de automatización de formularios. Es una mejora real sobre el Excel puro, en la misma línea que ya cubrimos al hablar de las limitaciones concretas de Excel.
Dónde aparece la grieta
La tercera ronda de un desarrollo casi siempre implica una de estas tres cosas, y las tres son las que rompen el modelo de hoja de cálculo:
Comparar dos versiones. «¿Qué cambiamos entre la ronda 2 y la ronda 3?» En una hoja compartida, esto significa duplicar la pestaña, guardar la vieja con un nombre distinto y comparar a ojo, celda a celda, dos tablas que probablemente ya no tienen las líneas en el mismo orden. Con tres personas editando a la vez, ese «guardar la vieja» a veces no llega a tiempo.
Que el coste se recalcule solo cuando cambia el precio de un ingrediente. En una hoja, el precio del ingrediente vive en una tabla, y la fórmula lo referencia con una búsqueda (VLOOKUP, o una relación de Airtable). Funciona mientras nadie edita el precio a mano en la fórmula «solo por probar un escenario» y se olvida de deshacerlo. Con seis fórmulas activas usando el mismo ingrediente, un precio desactualizado en una tabla afecta a las seis sin avisar.
Que la fórmula aprobada no se pueda tocar por accidente. Una hoja de cálculo no distingue entre «esto es un borrador que estoy probando» y «esto ya se aprobó y se está fabricando con ello». Cualquiera con permiso de edición puede cambiar una celda de una fórmula en producción sin que exista ningún aviso, ninguna versión anterior recuperable, ningún registro de quién lo hizo. Es exactamente el problema que resuelve el concepto de revisión vigente e inmutable: una vez aprobada, no se toca — se clona.
El síntoma que confirma que ya se ha cruzado la línea
Cuando en una reunión alguien dice «espera, deja que miro en la otra pestaña» más de una vez, o cuando hay una pestaña llamada «FÓRMULA BUENA NO TOCAR» en mayúsculas, el sistema ya ha dejado de aguantar la carga que se le pide. No es una crítica al equipo — es una señal de que la herramienta y el problema han dejado de estar a la misma escala.
Lo que ninguna de las dos hace, aunque se les pida con cariño
Ni Sheets ni Airtable calculan automáticamente una tabla nutricional a partir de la composición, ni comprueban límites regulatorios por ingrediente, ni versionan una fórmula de forma que la anterior quede protegida mientras se trabaja en la nueva. Se pueden montar aproximaciones manuales a todo esto con fórmulas anidadas y disciplina de equipo — y muchos laboratorios lo hacen durante años — pero cada aproximación añade una capa de mantenimiento manual que crece con cada fórmula nueva, no que se resuelve una vez y ya vale para todas.
El punto medio que algunos equipos intentan: automatizaciones sobre la hoja
Antes de dar el salto a un sistema dedicado, es habitual que un equipo con perfil técnico intente resolver las grietas con más ingeniería sobre la misma hoja: scripts de Apps Script que copian la pestaña antes de cada cambio grande, fórmulas de comparación entre dos rangos, automatizaciones de Airtable que bloquean la edición de campos «aprobados». Funciona, hasta cierto punto, y es un ejercicio honesto de intentar aguantar con lo que ya se tiene.
El problema de este camino es que cada automatización nueva es responsabilidad de quien la montó, y normalmente es una sola persona. Si esa persona cambia de proyecto, se va de la empresa o simplemente pierde el hilo de por qué configuró aquello así, el resto del equipo hereda un sistema de parches que nadie más entiende del todo, y que se rompe en silencio la primera vez que alguien edita algo fuera del patrón previsto. No es una crítica al esfuerzo: es una consecuencia casi inevitable de intentar simular con fórmulas y scripts un modelo de datos que la hoja no fue diseñada para representar.
Cuándo tiene sentido quedarse
Si el laboratorio desarrolla dos o tres productos al año, con pocas revisiones cada uno y un equipo de dos personas que se sientan en la misma sala, una hoja compartida bien disciplinada puede aguantar mucho tiempo sin problemas serios. El límite no es un número de productos exacto: es la combinación de más gente, más revisiones simultáneas y más presión regulatoria (alérgenos, Nutri-Score, IFRA) lo que hace que la hoja empiece a fallar donde antes no fallaba.
La pregunta que merece hacerse cada seis meses no es «¿la hoja funciona?» — casi siempre la respuesta es sí, con matices. Es «¿cuántas horas dedica el equipo a mantener la hoja en vez de a formular?». Cuando esa cifra empieza a doler, es la señal, no antes.