Estás evaluando invertir en un sistema y quieres saber si de verdad lo necesitas o si el dinero se va a ir a automatizar un desorden. Este artículo te da cinco señales concretas para distinguirlo antes de gastar.
Si esto describe tu situación, una llamada de 30 minutos aclara más que cualquier artículo.
La conversación casi siempre empieza igual: "necesitamos un sistema". Y a veces es cierto. Pero en buena parte de los casos que llegan, lo que hay debajo no es falta de software — es un proceso que nunca se definió y que cada persona ejecuta a su manera.
La diferencia importa porque el costo de equivocarse es asimétrico. Ordenar el proceso primero y después construir cuesta unas semanas extra. Construir sobre un proceso indefinido significa rehacer el sistema cuando por fin se defina, y eso cuesta el proyecto entero.
Estas son las cinco señales que usamos en el Discovery para saber cuál de los dos tienes enfrente.
Preguntas cuánto stock hay de una pieza. Almacén dice una cosa, el sistema de ventas otra, y el archivo de la persona que lleva el control una tercera.
Si las tres respuestas salen de fuentes distintas que nadie reconcilia, es falta de sistema: no hay una fuente única de verdad y cada área construyó la suya. Eso se resuelve con software.
Pero si las tres respuestas salen de la misma fuente y difieren porque cada quien cuenta distinto —uno incluye lo apartado, otro no, el tercero incluye lo que va en tránsito— entonces no falta sistema. Falta definir qué significa "stock disponible". Ningún software resuelve una definición que la empresa no ha tomado.
Preguntas quién aprueba un descuento por arriba de cierto porcentaje y la respuesta es "depende" o "normalmente el que esté". Eso es proceso, no sistema.
Un sistema puede aplicar una regla de autorización, pero no puede inventarla. Si metes un flujo de aprobación al software sin haber decidido antes quién aprueba qué, lo que va a pasar es que todos pidan permisos de administrador en la primera semana y el control quede igual que antes — solo que ahora pagaste por él.
Este es el caso opuesto, y es el que sí justifica construir. Todos saben exactamente qué hay que hacer, en qué orden, con qué criterio. El problema es que hacerlo requiere que una persona capture lo mismo en dos lugares, revise un archivo y mande un correo.
Aquí el proceso ya existe y funciona: lo que falla es que corre sobre trabajo humano repetitivo. Ese es el terreno donde la automatización tiene retorno directo y medible, porque el costo actual ya se puede contar en horas.
Hay un archivo con fórmulas, pestañas ocultas y una lógica que solo funciona si lo abre la persona correcta en el orden correcto. Cuando esa persona sale de vacaciones, el área se detiene.
Esto es señal mixta, y por eso es la más interesante. El proceso sí existe —está codificado en el archivo— pero vive en la cabeza de una sola persona. Lo primero es documentarlo; recién ahí se puede decidir si conviene construir un sistema o si basta con ordenar el archivo y darle respaldo.
La trampa es saltarse el paso de documentar y pedirle a un proveedor que "haga lo mismo que el Excel". Nadie, ni la persona que lo construyó, puede explicar completo un archivo de ese tipo en una junta.
Hay una licencia pagándose cada mes de un software que el equipo abrió tres semanas y abandonó. La conclusión rápida es que el sistema era malo. Casi nunca es eso.
Cuando un sistema no se adopta suele ser porque le pedía al equipo trabajar de una forma distinta a la que la operación realmente exige, y el equipo hizo lo lógico: volvió a lo que funciona. Eso es información valiosa, no un fracaso.
Antes de comprar el siguiente, vale la pena entender exactamente en qué punto la gente se salió del sistema. Ese punto es el requerimiento real, y normalmente ninguna herramienta comercial lo cubre — que es cuando construir a la medida empieza a tener sentido.
| Lo que observas | Qué indica | Qué hacer primero |
|---|---|---|
| Tres fuentes, tres números | Falta sistema | Definir la fuente única de verdad y construir sobre ella |
| Un número, tres interpretaciones | Falta proceso | Acordar la definición antes de tocar software |
| Nadie sabe quién autoriza | Falta proceso | Definir la matriz de autorizaciones |
| Proceso claro, ejecución manual | Falta automatización | Medir horas al mes y automatizar el flujo |
| El Excel que solo una persona entiende | Mixto | Documentar la lógica y después decidir |
| Sistema comprado sin usar | Requerimiento no cubierto | Identificar dónde se salió el equipo del flujo |
Se puede, pero es más caro y más riesgoso. Cambiar la forma de trabajar y la herramienta en el mismo momento hace imposible saber cuál de los dos causó cada problema. Cuando el proceso necesita ajustes grandes, conviene estabilizarlo primero aunque sea de forma manual.
En tiempo, normalmente semanas y no meses, porque casi siempre se trata de tomar decisiones que ya estaban pendientes más que de rediseñar la operación. En un Discovery ese trabajo va incluido: si el diagnóstico es que el problema es de proceso, el entregable es esa recomendación y no una propuesta de desarrollo.
Técnicamente casi todo se puede construir. La pregunta no es si se puede, sino qué pasa cuando la empresa tome la decisión que faltaba y el sistema ya esté construido asumiendo otra cosa. Ese rehacer es el origen de la mayoría de los proyectos que se van al doble del presupuesto.
Si los datos ya viven en algún sistema y el problema es moverlos entre ellos, es automatización. Si los datos no viven en ningún lado confiable, primero hace falta el sistema que los guarde.