Qué determina el costo de mejorar un proceso (y cuándo no vale la pena automatizarlo)

Es la primera pregunta de casi toda reunión y también la peor respondida del sector. La respuesta honesta incomoda: el costo de mejorar un proceso rara vez lo determina la tecnología que se usa al final. Lo determina el estado en el que están el proceso y los datos que produce.

Cuando una empresa pide una cotización, casi siempre imagina que está comprando una herramienta. En la práctica está comprando tres cosas distintas, y la herramienta es la más pequeña de las tres. Las otras dos son las que mueven el precio.

Antes del precio va el criterio

Ningún proceso se toca porque sea posible tocarlo. Se toca porque hay un número que debe moverse: horas de trabajo administrativo, tiempo de respuesta, errores de captura, ventas que se pierden fuera de horario. Si nadie puede nombrar ese número, la conversación sobre presupuesto es prematura — no porque falte dinero, sino porque no hay contra qué medir el resultado.

Los tres componentes reales del costo

1. El estado del proceso y de sus datos (aquí se define casi todo)

Si la información que el proceso necesita vive en hojas de cálculo inconsistentes, en correos o en la cabeza de tres personas, ese trabajo previo de ordenamiento y estructuración es el proyecto. Lo demás viene después y suele ser la parte más corta. Si en cambio ya tienes un sistema con datos limpios y accesibles por API, te saltas la etapa más cara.

2. Las integraciones

Una herramienta que solo conversa es barata y sirve de poco. Una que consulta inventario real, agenda una cita o genera una cotización tiene que hablar con tus sistemas. Cada integración es trabajo: entender la API ajena, manejar sus fallos, mantenerla cuando el tercero cambia algo. Si el sistema con el que hay que integrarse es antiguo o no tiene API, el costo se multiplica.

3. La operación, que no termina el día de la entrega

Es la parte que casi nadie presupuesta y la que decide si la mejora sobrevive. Un proceso automatizado hay que operarlo: monitorearlo, corregirlo cuando el comportamiento se desvía, ajustarlo cuando el negocio cambia. Cuando hay modelos de por medio se suma además un consumo que crece con el uso — bajo por consulta, pero real. Un proyecto que no presupuesta esta etapa no está comprando una mejora: está comprando una demo con fecha de caducidad.

Entonces, ¿cuánto cuesta?

Cualquiera que te dé una cifra sin conocer tu proceso, tus datos y tus integraciones está inventando. Lo que sí podemos decir con honestidad es cómo se ordenan los escenarios de menor a mayor:

Cuándo el costo no se justifica

Hay tres casos en los que decimos que no, aunque el cliente esté dispuesto a pagar. Cuando el proceso se ejecuta pocas veces al mes, el ahorro no cubre el mantenimiento. Cuando el problema se resuelve con una regla simple, una automatización tradicional es más barata, más predecible y auditable. Y cuando no hay datos, porque entonces el proyecto real es otro.

Lo que sí puedes exigir en una propuesta

Independientemente del proveedor, hay tres cosas que una propuesta seria debería tener: un indicador operativo concreto contra el cual se va a medir el éxito, una evaluación explícita del estado de tus datos antes de prometer nada, y el costo de operar la solución además del de construirla. Si falta alguna, la cifra que te dieron es un deseo.

En Indicium el descubrimiento no es una cortesía comercial previa a la venta: es la primera etapa del proyecto. De ella sale un activo que se queda contigo aunque el trabajo no continúe con nosotros — el proceso documentado, los criterios de aceptación, el alcance y la ruta de evolución. Con eso sobre la mesa, la cifra de la etapa siguiente deja de ser una estimación y pasa a ser un compromiso. Y también decimos que no cuando corresponde: en nueve años hemos rechazado proyectos donde la tecnología no era la respuesta.