El costo de un sistema que nadie usa

El proyecto salió bien. Se entregó a tiempo, funciona, no tiene errores graves. Seis meses después, la mitad del equipo sigue trabajando con la planilla vieja y el sistema se usa para tres cosas de las veinte que hace.

Esto pasa muchísimo más seguido de lo que se admite, y casi nunca se cuenta como lo que es: el fracaso más caro posible, porque pagaste el desarrollo entero y seguís teniendo el problema entero.

En corto: cuando nadie usa el sistema nuevo, el problema casi nunca es técnico. Las cinco causas, en orden de frecuencia, son que le da más trabajo a quien lo usa que a quien lo pidió, que se digitalizó un proceso roto, que se entregó todo junto, que los datos migrados eran malos y que nadie adentro lo empujó. Todas se pueden detectar antes de firmar.

Por qué es el peor de los escenarios

Un proyecto que fracasa técnicamente se corta a mitad de camino y algo se recupera. Uno que fracasa en la adopción se paga completo.

Y el costo no termina ahí. Se sigue pagando:

• La infraestructura, todos los meses, para un sistema que casi nadie abre.
• Las licencias por usuario de gente que no entra.
• El trabajo duplicado: quien carga en el sistema y además mantiene su planilla porque no confía.
• Los datos partidos en dos lugares, que es lo que hace que los números no cierren.
• El costo político: el próximo proyecto de sistemas va a arrancar con todo el mundo en contra, y con razón.

Ese último es el más caro a largo plazo y el que nadie presupuesta.

Cuánto cuesta realmente: la cuenta que casi nadie hace

El desarrollo es sólo la primera partida. Para dimensionar el costo de un sistema que no se usa, conviene sumar todo lo que sigue corriendo. Esta tabla es un esquema para que armes la cuenta con tus números, no una estadística:

La partida que más sorprende es la del trabajo duplicado. Si cinco personas dedican tres horas por semana a mantener la planilla vieja además de cargar el sistema, son quince horas semanales, unas sesenta al mes. En un año, el equivalente a más de cuatro meses de trabajo de una persona dedicados a sostener dos sistemas. Ese costo no aparece en ninguna factura, pero se paga.

Las cinco causas, en orden de frecuencia

1. Le da más trabajo a quien lo usa que a quien lo pidió

Es la causa número uno, lejos.

El sistema lo pidió la gerencia para tener visibilidad. Para lograrla, el vendedor tiene que cargar ocho campos por visita. La gerencia gana un tablero; el vendedor pierde veinte minutos por día y no gana nada.

No hay capacitación que arregle eso. Si el que carga no obtiene nada a cambio, no carga, o carga cualquier cosa, que es peor porque además ensucia el dato.

Lo que funciona es diseñar para que el que carga reciba algo concreto: que le arme el presupuesto, que le evite repreguntar, que le recuerde a quién llamar, que le calcule la comisión. Un sistema que le ahorra trabajo al usuario se usa sin que nadie lo obligue.

2. Se digitalizó un proceso que estaba roto

El software no ordena una operación desordenada: la congela.

Si el circuito de aprobación de un descuento hoy es "depende de quién esté", el sistema te va a obligar a definirlo. Si esa definición se hizo a las apuradas en una reunión, sin la gente que hace el trabajo, el sistema va a exigir pasos que en la realidad no se dan, y la gente va a esquivarlo.

3. Se entregó todo junto

Veinte módulos el mismo lunes. Nadie puede aprender veinte módulos el mismo lunes.

Lo que sobrevive es lo que entra de a poco: un proceso, que funcione, que la gente lo pida para lo siguiente. Un sistema que resuelve bien una cosa se usa; uno que resuelve a medias seis, no.

4. Los datos migrados eran malos

El primer día alguien busca un cliente y aparece tres veces. Busca un saldo y no coincide con lo que sabe. A partir de ahí, el sistema perdió: nadie va a apoyar una decisión en un dato que ya lo traicionó.

La confianza en un sistema se gana o se pierde en la primera semana, y casi siempre se juega en la calidad de la migración, que es la parte que más se apura. La nota sobre cómo migrar datos a un sistema nuevo detalla cómo hacerlo bien.

5. No hubo nadie adentro que lo empujara

Todos los sistemas que se adoptan tienen a alguien de la empresa —no del proveedor— que lo defiende, resuelve dudas, junta los reclamos y consigue que se arreglen.

Si esa persona no existe o no tiene tiempo asignado, el sistema queda huérfano el día que el proveedor se va.

Cómo se ve en distintos rubros

La misma causa se disfraza distinto según la operación.

• Distribuidora. Los vendedores no cargan los pedidos en la app porque es más lento que mandar un WhatsApp al depósito. La causa es la número uno: la app le da trabajo al vendedor y el beneficio lo recibe administración. Funciona cuando la app le muestra stock real, precios del cliente y le arma el pedido en menos pasos que el mensaje. Más en software para distribuidoras mayoristas.
• Clínica. Los profesionales siguen anotando en papel porque la pantalla de la historia clínica pide campos que no usan. La causa es digitalizar un proceso sin la gente que lo hace. Se resuelve diseñando la consulta con los médicos y empezando con lo mínimo.
• Constructora. El jefe de obra no carga avances porque en la obra no hay conexión estable. Es un problema de diseño: sin modo sin conexión, el sistema se usa a la noche, de memoria. Ver software para constructoras.
• Logística. Los choferes no usan la app de entregas porque les consume batería y datos, y el beneficio es de la oficina. Necesita que la app les resuelva algo propio: la hoja de ruta, la confirmación sin papel, el cierre de la jornada. Ver software para empresas de logística.
• Estudio contable. Los clientes no suben los comprobantes al portal porque es más fácil mandarlos por WhatsApp. El portal tiene que ser más simple que el canal que reemplaza, o integrarse a él.

Cómo saber si va a pasarte

Antes de firmar, contestá estas cinco. Son incómodas a propósito.

1. ¿Qué gana la persona que va a cargar los datos? Si la respuesta es "la empresa va a tener mejor información", tenés un problema.
2. ¿Quién de tu empresa tiene tiempo asignado para esto? No "quién está a cargo": quién tiene horas reservadas.
3. ¿El circuito está escrito, con sus excepciones? Si no, el sistema lo va a inventar.
4. ¿Cuánta historia vas a migrar y quién la va a revisar?
5. ¿Qué proceso entra primero y cuándo entra el segundo? Si la respuesta es "todo junto", cambiá el plan.

Las señales tempranas de que no se está usando

No hace falta esperar seis meses. En las primeras semanas ya se ven señales:

• Se sigue pidiendo "el Excel" en las reuniones, en lugar de mirar el tablero del sistema.
• Los datos se cargan en lote al final de la semana o del mes, en lugar de en el momento.
• Aparecen planillas paralelas que alguien mantiene "por las dudas".
• Las mismas pocas personas concentran casi todos los usos.
• Los campos opcionales están vacíos o llenos con un valor por defecto.
• Cada reclamo termina con "es más rápido hacerlo a mano".

Cuando aparecen dos o tres, conviene parar y preguntar a quienes lo usan, uno por uno, qué les resulta incómodo. Es casi siempre algo concreto y chico de resolver.

Lo que sí funciona

Empezá por donde más duele. El proceso que consume las horas del lunes. Si eso mejora, el resto se lo van a pedir a vos.

Que lo use el equipo antes de que esté terminado. Aunque sea feo, aunque falte la mitad. Los ajustes que salen de dos semanas de uso real valen más que tres reuniones de relevamiento.

Convivan un tiempo. Uno o dos meses con el sistema y la planilla en paralelo. Es trabajo doble e incómodo, y es la única forma de descubrir lo que nadie contó sin arriesgar la operación.

Medí la adopción, no la entrega. La pregunta a los tres meses no es si el sistema está terminado. Es cuánta gente lo abre todos los días. Si ese número es bajo, hay un problema que ningún desarrollo adicional va a resolver.

El presupuesto de un sistema tiene una línea que no cotiza nadie: las horas de tu equipo. Definir circuitos, revisar datos, probar, capacitarse. Es el costo más grande del proyecto y el único que no te factura el proveedor. Un sistema donde esa línea vale cero es, casi siempre, un sistema que después no se usa.

Plan de adopción en seis pasos

Si vas a encarar un proyecto, o ya tenés uno que no arranca, este orden funciona:

1. Elegí un solo proceso de arranque y definí qué mejora concreta debería producir, en horas o en errores evitados.
2. Designá un responsable interno con horas reservadas por semana, que sea de la operación y no de sistemas.
3. Escribí el circuito real, con las excepciones, junto a quienes lo ejecutan.
4. Revisá los datos que se migran con alguien que los conozca antes de abrir el sistema.
5. Arrancá con un grupo chico, juntá los reclamos durante dos semanas y corregí antes de sumar al resto.
6. Medí el uso semanal y definí cuándo se apaga la planilla vieja, con fecha.

Para el paso anterior a todo esto, la nota sobre por dónde empezar a automatizar procesos en una pyme ayuda a elegir el proceso. Y si el problema es que el sistema ya existe y no se usa, a veces alcanza con simplificarlo en lugar de rehacerlo.

Qué cambia cuando el sistema incluye automatización o IA

Los agentes de IA y las automatizaciones tienen el mismo riesgo, a veces amplificado: un asistente que responde mal una consulta frecuente enseña a la gente a no usarlo en la primera semana. Conviene empezar con una sola tarea acotada (por ejemplo, responder consultas de estado de pedidos), revisar las conversaciones reales y ampliar recién cuando el equipo confía en la respuesta. Más sobre ese enfoque en agentes de IA para empresas que automatizan de verdad.

Lo mismo vale para los tableros: si los números que muestran no coinciden con lo que la gente ve en su trabajo, dejan de mirarlos en pocos días y vuelven a pedir los datos por mensaje. Por eso conviene validar cada indicador con quien lo conoce antes de publicarlo.

Errores comunes de quienes ya pasaron por esto

• Obligar por decreto. Una orden de la gerencia consigue cargas, no buenos datos.
• Capacitar una sola vez. Las dudas aparecen cuando se usa, no en la clase.
• Sumar funciones para convencer. Un sistema que no se usa no mejora con más módulos.
• Culpar a la gente. Si nadie lo usa, es una señal de diseño, no de actitud.
• Echarle la culpa al proveedor sin revisar la propia parte. Los circuitos, los datos y las horas son responsabilidad compartida.
• No fijar una fecha para apagar lo viejo. Sin fecha de corte, conviven para siempre.

Preguntas frecuentes

¿Por qué un sistema que nadie usa es tan caro?

Porque el desarrollo se paga completo y el problema sigue entero. Además se siguen pagando la infraestructura, las licencias de gente que no entra, el trabajo duplicado y los datos partidos en dos lugares. El costo más caro a largo plazo es el político: el próximo proyecto de sistemas arranca con todo el mundo en contra.

¿Por qué la gente no usa un sistema nuevo?

La causa más frecuente es que le da más trabajo a quien lo usa que a quien lo pidió. Si el que carga no obtiene nada a cambio, no carga, o carga cualquier cosa. Las otras causas son digitalizar un proceso roto, entregar todo junto, migrar datos malos y que nadie de la empresa lo empuje.

¿Cómo evito que mi sistema quede sin uso?

Empezá por donde más duele, que lo use el equipo antes de que esté terminado y convivan un tiempo con la planilla en paralelo. Conviene también diseñar para que quien carga reciba algo concreto, como que le arme el presupuesto o le calcule la comisión. Un sistema que le ahorra trabajo al usuario se usa sin que nadie lo obligue.

¿Qué preguntas me tengo que hacer antes de firmar?

Cinco: qué gana quien carga los datos, quién de tu empresa tiene horas reservadas, si el circuito está escrito con sus excepciones, cuánta historia vas a migrar y quién la revisa, y qué proceso entra primero. Si la respuesta a esta última es "todo junto", cambiá el plan.

¿Cómo mido si el sistema se adoptó?

Medí la adopción y no la entrega. La pregunta a los tres meses no es si el sistema está terminado sino cuánta gente lo abre todos los días. Si ese número es bajo, hay un problema que ningún desarrollo adicional va a resolver.

¿Cuántos proyectos de software fracasan por falta de adopción?

No hay una cifra única y confiable para pymes argentinas, y conviene desconfiar de los porcentajes que circulan sin fuente. Lo que se observa en la práctica es que la adopción, y no la tecnología, es la causa más frecuente de que un sistema terminado no cumpla su objetivo.

¿Qué hago si el sistema ya está entregado y nadie lo usa?

Primero, hablá con quienes lo usan o deberían usarlo y averiguá qué les da trabajo de más. Después, elegí un solo proceso, simplificalo hasta que le ahorre tiempo a quien carga y relanzalo con un responsable interno y una fecha para apagar la planilla vieja. Rehacerlo entero es el último recurso, no el primero.

¿Quién tiene que impulsar el sistema dentro de la empresa?

Alguien de la propia empresa, con horas reservadas y autoridad para resolver dudas y priorizar reclamos. No puede ser el proveedor, porque se va cuando termina el proyecto. Si no hay una persona con ese rol, el sistema queda huérfano.

¿Cuánto tiempo tiene que convivir el sistema nuevo con la planilla vieja?

Entre uno y dos meses suele alcanzar para descubrir los casos que nadie contó sin arriesgar la operación. Lo importante es fijar de antemano la fecha de apagado de la planilla, porque sin fecha de corte conviven indefinidamente y se duplica el trabajo.

Si querés evitar este escenario desde el diseño, mirá cómo planteamos el desarrollo de software a medida, con entregas por etapas y uso real desde las primeras semanas: demo gratis en 24 h o agendá una llamada.