Hay una asimetría en todo proyecto de software que explica la mayoría de los fracasos: el proveedor mide el éxito en la entrega y el cliente lo mide en el uso. Son dos momentos distintos, separados por semanas, y entre uno y otro casi nadie está mirando.
El equipo que construyó ya está en el proyecto siguiente. El área usuaria todavía no cambió su forma de trabajar. Y en ese hueco es donde los sistemas se abandonan.
El mes que decide todo
Lo que pasa en las cuatro semanas posteriores a una puesta en producción es previsible y siempre parecido.
Semana uno: entusiasmo y quince dudas chicas. «¿Dónde se pone el número de comprobante?» «¿Por qué no me deja guardar?» Ninguna es grave; todas son urgentes para quien las tiene.
Semana dos: aparecen los casos que no se contemplaron. El cliente que paga en dos monedas, la devolución parcial, el pedido que se factura a un tercero. Siempre hay tres o cuatro, y siempre son los que más ruido hacen.
Semana tres: el punto de quiebre. Si las dudas de la semana uno se respondieron rápido y los casos de la semana dos tienen al menos una respuesta provisoria, la gente sigue. Si no, empieza a volver a la planilla «solo para esto».
Semana cuatro: se consolida lo que haya pasado. El sistema quedó instalado en la costumbre, o quedó como una obligación que se cumple a medias.
Recuperar a alguien que volvió a la forma vieja cuesta bastante más que haberlo sostenido, porque a la desconfianza técnica se le suma la sensación de haber perdido tiempo.
Las cinco cosas que hay que dejar hechas
1. Una fecha de apagado de lo anterior
Mientras la planilla siga accesible, va a competir y va a ganar, porque la costumbre no se discute. La fecha se acuerda antes de la puesta en producción, no después, y con la persona que puede hacerla cumplir.
No tiene que ser inmediata. Puede ser a los treinta días. Lo que no puede es no existir.
2. Un referente del lado del negocio
Alguien del área que sepa explicar el sistema a un compañero. No que sepa usarlo: que sepa enseñarlo, que es una vara distinta y bastante más alta.
Esa persona es la que responde las dudas de la semana uno sin que haya que escribirle al proveedor, y es la que defiende el sistema cuando alguien propone volver atrás. Un sistema sin ese referente depende de un externo para todo, y eso no se sostiene.
3. Las excepciones declaradas
Las tres o cuatro situaciones que el sistema no cubre. Escritas, con el acuerdo de cómo se manejan mientras tanto y quién lo hace. Si quedan sin declarar, cada una arrastra a todo su proceso de vuelta al método viejo.
4. Práctica con datos propios
La capacitación que funciona no es una demostración: es la gente haciendo su trabajo real en el sistema, con sus datos, acompañada. Dos horas de eso valen más que una jornada de presentación.
5. Una forma de medir el uso
Cuántas personas lo abren por semana, cuántos registros se cargan. Es un dato barato de dejar y casi nadie lo deja, y sin él la adopción es una impresión: «me parece que lo están usando».
Con el dato, la conversación del mes tres es concreta. Sin el dato, es una discusión de percepciones que gana el que habla más fuerte.
Cómo se cotiza esto
Acá está la parte difícil, porque el acompañamiento posterior aparece como un extra y compite mal contra un competidor que no lo incluyó.
Nuestra posición es que no es un extra: es parte de la entrega. Y cuando el presupuesto no da, la decisión correcta no es sacar el acompañamiento — es achicar el alcance del sistema y dejar el acompañamiento adentro. Un sistema más chico que se usa vale infinitamente más que uno completo que nadie abre.
Esa conversación con el cliente se da una vez y define el proyecto: «Con este presupuesto puedo hacerle las cinco pantallas y dejarlo instalado, o hacerle tres pantallas y quedarme un mes acompañando la puesta en marcha. Yo le recomiendo lo segundo, y le explico por qué.»
Cuando el equipo es interno
Un equipo interno tiene una ventaja y una desventaja frente a un proveedor externo.
La ventaja es que no se va: sigue en el edificio y puede acompañar sin cotizar nada. La desventaja es que nadie le reserva tiempo para eso, porque el proyecto ya figura como cerrado en la planilla y el equipo ya tiene asignado el siguiente.
La solución es la misma que para el externo, con otras palabras: al comprometer el proyecto, comprometer también las cuatro semanas posteriores. No como disponibilidad informal, sino como carga de trabajo reservada. Un equipo que no reserva ese mes lo va a gastar igual, apagando incendios, pero con la sensación de estar atrasado en otra cosa.
La resistencia que no es resistencia
Cuando un área no adopta un sistema, la explicación que circula suele ser que la gente se resiste al cambio. Es cómoda porque no obliga a revisar nada del sistema, y casi siempre es falsa.
Lo que se lee como resistencia suele ser una de estas cuatro cosas, y todas son racionales:
- El sistema es más lento para su tarea diaria. Si cargar un pedido lleva ocho clics donde la planilla llevaba dos, la persona que carga ciento veinte pedidos por día no se resiste: está midiendo bien.
- Le quita una información que necesitaba de un vistazo. La planilla mostraba todo junto; el sistema lo reparte en tres pantallas. Para quien tenía que mirar tres datos a la vez, eso es una pérdida real.
- La expone. Un sistema deja registro de quién hizo qué y cuándo. Para alguien acostumbrado a resolver informalmente, eso cambia su situación, y nadie lo va a decir en voz alta.
- Nadie le explicó por qué. Si la persona no entiende qué problema de la organización resuelve el cambio, lo vive como una molestia impuesta, y tiene razón en vivirlo así.
Las tres primeras se corrigen con cambios concretos en el sistema. La cuarta se corrige con una conversación de diez minutos que casi nunca se tiene. Ninguna se corrige insistiendo.
Qué se hace cuando ya pasó
Si el sistema ya está entregado y el área volvió a la planilla, insistir no sirve y recordar que existe tampoco. Lo que funciona es tratarlo como un proyecto nuevo y chico.
Se elige una sola tarea, la más frecuente del área, y se hace que en el sistema sea claramente mejor que en la planilla: menos pasos, menos datos que cargar, el resultado a la vista. Una sola. Cuando esa tarea migra, arrastra a las demás, porque ya nadie quiere tener los datos en dos lados.
Intentar recuperar todo de una vez fracasa siempre, por el mismo motivo por el que fracasó la primera vez: pide un cambio grande a gente que está ocupada.
La pregunta que ordena todo
Antes de dar por cerrado un proyecto, hay una sola pregunta que conviene hacerse:
¿Alguien dejó de hacer algo que hacía antes?
Si nadie dejó de hacer nada —si la planilla sigue, si el correo sigue, si la libreta sigue—, el sistema no reemplazó nada. Se agregó. Y un sistema que se agrega sin reemplazar es trabajo extra para todo el mundo, por más bien construido que esté.
Esa pregunta, hecha a las cuatro semanas, dice con precisión si el proyecto terminó o si solo se entregó.
Vea cómo trabajamos o escríbanos si tiene un sistema entregado que no terminó de arrancar.
