Cómo saber si tu empresa ha superado Excel
Seis síntomas que indican que una hoja de cálculo dejó de ser una herramienta y pasó a ser un riesgo operativo, y qué hacer con ella cuando ocurre.
Respuesta corta
Una empresa ha superado Excel cuando la hoja de cálculo ha dejado de ser una herramienta de análisis para convertirse en el sistema donde ocurre la operación. Los síntomas son concretos: varias versiones del mismo fichero circulando, una sola persona que sabe cómo funciona, datos que se teclean dos veces, ausencia de histórico fiable, imposibilidad de controlar quién ve qué, y errores que se descubren semanas después. Con dos o tres de estos síntomas el riesgo ya es operativo, no teórico.
Excel no es el problema
Conviene decirlo antes de nada, porque este tipo de artículos suele empezar atacando la herramienta: Excel es extraordinario en lo que hace. Para calcular, explorar datos, prototipar una idea o resolver algo puntual no hay nada más rápido ni más flexible.
El problema aparece cuando una hoja deja de ser una herramienta de análisis y se convierte, sin que nadie lo decidiera, en el sistema donde ocurre la operación: donde entran los pedidos, donde se controla el stock, donde se calcula lo que hay que fabricar.
Ese salto casi nunca se toma como decisión. Se llega a él por acumulación.
Seis síntomas
1. Hay varias versiones del mismo fichero
presupuestos_v3_final_REVISADO.xlsx. Si esto te suena, el síntoma ya está
ahí. En el momento en que dos personas necesitan trabajar a la vez sobre los
mismos datos, la hoja compartida deja de tener una única verdad.
2. Solo una persona sabe cómo funciona
Las fórmulas encadenadas, las macros y las columnas ocultas se acumulan durante años. Quien las construyó entiende el conjunto; el resto ejecuta pasos que no puede verificar.
Es un riesgo doble: nadie se atreve a tocarla por miedo a romper algo, y si esa persona se va, la empresa se queda con un sistema que no sabe operar.
3. El mismo dato se teclea más de una vez
El pedido entra en la hoja, luego alguien lo pasa al ERP y después aparece en un informe. Cada transcripción es una oportunidad de que las versiones dejen de coincidir, y no hay nada que avise cuando pasa.
4. No hay histórico fiable
Una celda se sobreescribe y lo anterior desaparece. Cuando alguien pregunta por qué se cambió un precio, quién lo cambió o cuándo, no hay forma de saberlo.
Para un proceso operativo, la trazabilidad no es un lujo: es lo que permite resolver una incidencia con un cliente sin tener que fiarse de la memoria de alguien.
5. No se puede controlar quién ve qué
O una persona tiene acceso al fichero entero —incluidos márgenes, costes o datos de otros clientes— o no tiene acceso a nada. No hay término medio.
6. Los errores aparecen tarde
Una fórmula arrastrada mal, una fila insertada donde no tocaba, un formato de fecha que se interpreta al revés. Nada de eso avisa. Se descubre semanas después, cuando ya ha contaminado un pedido, una factura o un inventario.
Cómo medir el coste real
Antes de decidir nada, conviene ponerle número. Tres preguntas concretas:
- Horas al mes. ¿Cuánto tiempo dedican las personas a mover, transcribir y cuadrar datos entre la hoja y el resto de sistemas?
- Errores. ¿Cuántas incidencias del último año tuvieron su origen en un dato mal introducido o desactualizado, y qué costó resolverlas?
- Dependencia. ¿Qué pasaría la semana que viene si la persona que mantiene la hoja no estuviera?
Sin estas tres cifras cualquier conversación sobre presupuesto es una discusión de opiniones.
Qué hacer cuando la respuesta es «sí»
Sustituirlo todo de golpe rara vez es la mejor opción. Lo que suele funcionar es acotar:
- Identificar el proceso más costoso, no el más visible. Suelen ser distintos.
- Construir solo esa parte, dejando el resto en la hoja mientras tanto.
- Migrar los datos con criterio: casi siempre hay que limpiar antes de mover, y ese trabajo se subestima sistemáticamente.
- Conectar con lo que ya existe —el ERP, la tienda— para no crear una isla nueva.
- Ampliar el alcance solo cuando la primera parte esté en uso real.
Y una comprobación honesta antes de empezar: si el proceso todavía cambia cada mes, o si lo que falta en realidad es decidir cómo se trabaja, el software no es lo primero que hay que resolver.
Sobre el autor
Oscar Blanco
Fundador y responsable técnico de MUROSOFT
Desarrollador fullstack con más de una década construyendo software para empresas. En MUROSOFT analiza el proceso antes que la tecnología: qué se hace hoy, qué cuesta y qué merece la pena automatizar. Trabaja de forma directa con quien va a usar el sistema, sin capas intermedias entre el problema y quien lo resuelve.