Muchas renovaciones de software terminan convertidas en una presentación de novedades: cuántas funciones se agregaron, qué versión salió, qué pantalla cambió o qué capacidad nueva apareció durante los últimos doce meses. Hay algo extraño en obligar a una plataforma que ya resuelve correctamente un problema a inventar novedades todos los años para demostrar que todavía merece existir. Un sistema crítico no necesariamente es mejor por hacer veinte cosas nuevas. Puede ser mucho más valioso porque durante todo ese tiempo funcionó, acompañó la operación, respondió cuando aparecieron dificultades y evolucionó justo donde realmente hacía falta.
Dos organizaciones compran exactamente el mismo software. En la primera, el proveedor implementa la herramienta, capacita al equipo y prácticamente desaparece hasta el momento de renovar. Durante el año, las dudas se resuelven entre usuarios, aparecen procedimientos paralelos y algunos problemas terminan convirtiéndose en costumbres. En la segunda, el proveedor permanece cerca, atiende incidencias, observa cómo trabajan las personas, corrige dificultades, acompaña cambios y utiliza lo que aprende de la operación para mejorar el producto. Doce meses después quizá ninguna tenga una lista espectacular de nuevas funcionalidades. Solo una puede decir que recibió durante todo el año algo más importante que una licencia.
Mantener software y mantener una capacidad son cosas distintas. El soporte no debería significar únicamente aparecer cuando algo se rompe. También debería implicar entender cómo está funcionando la herramienta dentro de la realidad del cliente, ayudar a resolver fricciones y convertir esas experiencias en aprendizaje para el propio producto. Allí ambos lados ganan: la organización recibe acompañamiento, continuidad y una plataforma cada vez más cercana a sus necesidades; quien la desarrolla obtiene algo que ningún laboratorio puede ofrecerle, evidencia real sobre cómo su software se comporta cuando entra en contacto con personas, procesos, excepciones y problemas que nunca aparecieron durante el diseño.
Este modelo también cambia la responsabilidad del proveedor. Cobrar una renovación anual no puede convertirse en cobrar simplemente por seguir disponible. Si durante doce meses existe una relación de soporte, debería ser posible mostrar qué problemas fueron atendidos, qué riesgos se redujeron, qué mejoras surgieron, qué aprendió el producto, cómo se acompañó a los usuarios y qué cambió en la operación gracias a esa relación. La continuidad deja de descansar sobre una cláusula contractual y empieza a depender de algo mucho más exigente: demostrar durante todo el año que seguir juntos tuvo sentido.
La conversación de renovación debería comenzar de otra manera. En lugar de preguntar qué funciones nuevas trae la siguiente versión, podría empezar con algo mucho más difícil de maquillar: durante estos doce meses, ¿sintió la organización que este software y las personas que lo sostienen le ayudaron realmente a trabajar mejor? Si la respuesta es sí, probablemente no haga falta inventar una revolución cada año para justificar la continuidad. Si la respuesta es no, quizá ninguna lista de funcionalidades debería salvar el contrato. Un buen software empresarial se parece menos a un producto que compramos una vez y más a una capacidad que decidimos conservar mientras siga aportando valor.
