Casi ninguna empresa decide gestionarse con Excel. Lo que pasa es otra cosa: alguien abre una hoja para resolver un problema concreto, funciona, y tres años después esa hoja tiene catorce pestañas, la tocan cinco personas y contiene una macro que solo entendía alguien que ya no trabaja aquí.
No es un fracaso de nadie. Es lo que ocurre cuando una herramienta buena se usa mucho más tiempo del que se pensó. La pregunta útil no es si Excel está bien o mal, sino en qué momento deja de salir a cuenta.
¿Cuándo deja de compensar el Excel?
Cuando lo que cuesta mantener la hoja —corregir errores, coordinarse para no pisarse, recomponer lo que alguien rompió sin querer— empieza a pesar más que construir algo que haga ese trabajo solo.
Eso no se nota de golpe. Se nota en señales sueltas que llevan meses ahí:
- Dos personas no pueden trabajar a la vez sin pisarse, así que se turnan o mantienen copias.
- Hay una versión buena y otras cuatro de las que ya nadie se fía del todo.
- Alguien dedica horas cada semana a copiar datos de la hoja a otro programa, o al revés. Ese trabajo no produce nada: solo traslada.
- Los errores se descubren tarde. Una fórmula que se arrastró mal, una fila insertada donde no tocaba, y el número que llevabais mirando tres semanas estaba mal.
- No podéis dar acceso parcial. O ve toda la hoja, con márgenes y costes incluidos, o no ve nada. Así que no se la enseñáis a quien la necesita.
- Nadie sabe quién cambió qué. Y cuando hay que averiguarlo, no hay forma.
Si reconocéis tres o más, la hoja ya no es la herramienta: es el problema.
¿Qué se gana de verdad?
Tres cosas que una hoja de cálculo no puede dar por mucho que la trabajes: que varias personas operen a la vez sin pisarse, que los datos se validen al entrar, y que quede rastro de quién hizo qué y cuándo.
Que se pueda trabajar en paralelo. Una aplicación está pensada para que diez personas hagan cosas distintas al mismo tiempo. Una hoja compartida, no.
Que el error no llegue a entrar. En Excel cualquiera escribe «Madríd» o una fecha en un campo de importe. En una aplicación, ese campo no lo acepta. Se acaba una familia entera de errores que hoy corregís a mano.
Que quede registro. Quién creó el pedido, quién cambió el precio, cuándo se marcó como entregado. No es para vigilar a nadie: es para poder responder cuando un cliente pregunta qué pasó.
Que cada uno vea lo suyo. El comercial ve sus clientes, el almacén ve sus albaranes, la dirección lo ve todo. Con permisos de verdad, no ocultando columnas.
Y que hable con lo que ya tenéis. Es lo que más se subestima: que el pedido llegue a facturación sin que nadie lo teclee otra vez. De eso va buena parte de una integración entre sistemas.
¿Qué se pierde?
Flexibilidad inmediata. En Excel añadís una columna en diez segundos; en una aplicación eso es un cambio que hay que pedir, desarrollar y desplegar.
Es el coste real de esta decisión y conviene mirarlo de frente. Se compensa de dos maneras, y las dos hay que negociarlas antes de empezar: dejando configurable lo que sabéis que va a cambiar —tarifas, estados, tipos de documento— para que no dependa de nosotros, y acordando cómo se piden y se priorizan los cambios pequeños, para que no se conviertan en una cola de tres meses.
Si a la empresa le va bien precisamente porque cada semana se inventa una forma nueva de trabajar, una aplicación os va a apretar. Merece la pena saberlo antes.
¿Se puede migrar sin parar la empresa?
Sí, y es la única forma sensata de hacerlo: por fases, conviviendo con la hoja hasta que la aplicación cubra el proceso entero.
Nadie apaga el Excel el primer día. Lo que se hace es coger el trozo que más duele —normalmente el que más manos toca— y llevarlo primero. Ese trozo funciona en un entorno real, la gente lo usa de verdad, y solo cuando está asentado se pasa al siguiente.
Tiene una ventaja que no es menor: si a la tercera semana descubrís que el proceso no era como lo habíais contado —y pasa más de lo que parece— lo corregís ahí, no al final.
¿Qué pasa con los datos que ya tenéis?
Se migran. Y en ese momento sale a la luz todo lo que la hoja escondía: duplicados, fechas en tres formatos distintos, y campos que significan una cosa u otra según quién los rellenara.
Esto sorprende a todo el mundo la primera vez, así que mejor decirlo pronto: la migración de datos no es un trámite del final, es parte del proyecto. Una hoja tolera que el mismo cliente esté escrito de cuatro maneras; una base de datos, no. Alguien de vuestro lado va a tener que decidir cuál de las cuatro es la buena, y eso no lo puede decidir quien programa.
La parte buena es que ese trabajo se hace una vez y a partir de ahí los datos están limpios.
¿Cuánto se tarda?
Entre seis y doce semanas para tener la primera versión en producción, contando desde el diseño de pantallas hasta que el equipo la usa a diario.
El plazo depende menos de cuántas pantallas tenga y más de con cuántos sistemas tenga que hablar. Una aplicación que vive sola se hace rápido; una que tiene que cuadrar stock con el almacén y facturas con el ERP, no.
¿Y cuándo no hace falta salir de Excel?
Cuando la hoja la usa una sola persona, cambia poco y nadie decide nada importante a partir de ella. Ahí una aplicación es gasto sin retorno.
Hay más casos en los que decimos que no: si un programa del mercado cubre vuestro proceso, compradlo —será más barato y estará antes—. Si el problema real es que nadie tiene claro cómo se trabaja, una aplicación solo va a automatizar el desorden. Y si nadie de dentro puede dedicar tiempo a explicar el proceso, el proyecto no va a salir bien por mucho presupuesto que tenga.
Excel es una herramienta buenísima. El problema nunca es la hoja: es pedirle que sostenga algo para lo que no está hecha.
Si has reconocido tu empresa en la primera lista, eso es exactamente lo que hacemos: software de gestión a medida construido sobre el proceso que ya tenéis. Y si al hablarlo vemos que no os compensa, os lo decimos.