Hace unas semanas atrás, discutía con un cliente sobre la necesidad o no de realizar la actualización del ERP a nuevas versiones. El cliente alegaba que con su versión estaba cubierta la funcionalidad y necesidades requeridas en ese momento, y por tanto era innecesario una actualización que pusiera en riesgo su estabilidad. Claro está que el origen de la conversación no era la actualización sino sobre su innecesario servicio de mantenimiento, según él. Este tema ya se había tratado en varias ocasiones, pero discutir conmigo sobre este tema solo puede ser en los términos del alcance del mantenimiento, nunca sobre sobre ‘Mantenimiento sí / mantenimiento no’. Y uno de los puntos claves en este aspecto son las actualizaciones.
Desde mi punto de vista, los clientes no deben quedarse descolgados de nuevas versiones. Las nuevas versiones aportan mejoras funcionales, de seguridad, de rendimiento, tecnológicas, legales, etc. Si bien es cierto, que aquel cliente con mayor nivel de criticidad (o inseguridad), podría demorar las actualizaciones un tiempo con el fin de evitar poner en riesgo su entorno. En cualesquiera de los casos es conveniente actualizar, si bien en el segundo caso, deba esperar a un nivel de aseguramiento de la calidad (QA) en un estado más maduro. El soporte de las versiones antiguas no puede ser indefinido, por lo que tarde o temprano habrá que realizar la actualización.
Por supuesto, si el cliente solicita una versión en un nivel de madurez inferior por requerimientos funcionales por ejemplo, podría actualizarse a una versión QA, aunque en este caso mi recomendación sería hacerlo en un entorno de pruebas y/o pre-producción.
Hay otros condicionantes sobre el tipo de versión a instalar en el cliente: dependiendo del tamaño de empresa, asimilación de nuevas funcionalidades por parte de los usuarios, disponibilidad de testers en la empresa, existencia de early adopters en la empresa, etc.
En algunos clientes, se recurre a packs de actualizaciones con una frecuencia elevada. Lo que podría considerarse como un signo de inestabilidad, puede ser todo lo contrario, denota que es un producto muy vivo y a la vez que aporta alguna nueva funcionalidad y extensión, va corrigiendo los bugs que va detectando los usuarios. Hay productos cuya política es totalmente la contraria, lo que puede provocar en el cliente la sensación de que los bugs no se solucionan, o que deben esperar meses (años inclusive) para ello. En este aspecto es importante diferenciar las actualizaciones importantes de aquellas menores, que normalmente no poseen criticidad alguna, debido a que suelen ser pequeñas ampliaciones de funcionalidad y corrección de errores.
En cualquier caso, los riesgos se minimizan enormemente si el cliente está dispuesto a que se liberen las actualizaciones en un entorno de pruebas previamente y donde se pueda testear fielmente. Si se logra esto, el impacto del cambio se minimizará.
Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly |
|