En esta nota (9 secciones)
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.
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.
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.
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 saber si va a pasarte
Antes de firmar, contestá estas cinco. Son incómodas a propósito.
- ¿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.
- ¿Quién de tu empresa tiene tiempo asignado para esto? No "quién está a cargo": quién tiene horas reservadas.
- ¿El circuito está escrito, con sus excepciones? Si no, el sistema lo va a inventar.
- ¿Cuánta historia vas a migrar y quién la va a revisar?
- ¿Qué proceso entra primero y cuándo entra el segundo? Si la respuesta es "todo junto", cambiá el plan.
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.