Traducido por Grafix
Comentario y análisis
Por Jane Mugford
En todas las industrias, uno de los mayores desafíos que enfrenta cualquier líder tecnológico es cuando una actualización de software debe ser completada. En el sector de la impresión, los beneficios potenciales de las nuevas características y mejoras se pueden sentir rápidamente con el mínimo cambio en comparación con el riesgo de cualquier polvillo radiactivo que puede ocurrir si una actualización va «mal». Para la tecnología web-to-print, una actualización que tiene defectos o errores puede afectar negativamente a sus clientes y causar altos niveles de frustración.
Para los sistemas de impresión MIS, una actualización que no va bien puede mandar a su organización en picada – incluso si es sólo por un par de días, el caos puede ser doloroso.
Así que, dado todo eso, ¿por qué molestarse? Te molesto porque sin lugar a dudas, las ventajas de las nuevas versiones son muy superiores a las versiones antiguas. Cuanto más tiempo permanezca en una versión desactualizada, más difícil resulta hacer actualizaciones del sistema, porque los saltos para mover su sistema hacia una conversión más actualizada tendrán un mayor riesgo y será más complejo. Suponiendo que se va a mantener a su empresa en un camino de mejoras continuas, ¿qué se puede hacer para mitigar el riesgo y garantizar la transición más suave posible de una versión a otra?
No vaya primero
Abogo fuertemente en contra de ser el primero en apuntarse a actualizar en el momento en que se lanza la actualización, no importa que tan tentadoras puedan ser las nuevas características y funcionalidades. Sugiero mantenerse a raya al menos un par de meses y dejar que los betas testers y otros impresores estén dispuestos a lanzarse primero. Sin duda, habrá temas que se desarrollan que impactarán a todos. Los desarrolladores están siempre a la búsqueda, y por lo general hay algunas versiones puntuales muy rápidas para corregir defectos después de que una versión principal se pone a disposición. Deje que algunas de estas versiones puntuales salgan primero y luego entre en la lista de actualización. Me gusta normalmente una ventana de 6 meses después de un lanzamiento importante para programar su actualización.
Ese plazo traerá mucha estabilidad a la nueva versión. Punto o versiones incrementales suelen causar una interrupción mínima y, a menudo añaden estabilidad a la nueva versión principal, por lo que recomiendan hacer aquellos dentro de una o dos semanas después del lanzamiento.
No te permitas quedar demasiado atrás
Así como yo abogo por no ser demasiado ansiosos por mejorar, también recomiendo no caer demasiado tarde. Usted quiere estar dentro de una versión de la versión principal actual. La razón de ser es que entre más espere y más «versiones principales» se atrasará y más difícil será actualizar. En este tiempo, también está perdiendo nuevas eficiencias y características potenciales. Conforme pasa el tiempo, el vendedor se hace menos experto en versiones anteriores así que algunos temas se hacen más difíciles de solucionar.
Considere la posibilidad de invertir en un servidor de ensayo / prueba
Aunque sé que el gasto adicional de un servidor de ensayo no debe ser evaluado a la ligera, el dinero que se puede ahorrar usted es tremendo. Un servidor de prueba permite realizar actualizaciones con una réplica completa de su base de datos en vivo y ver lo que algunos temas presentan – en la seguridad de un entorno no productivo. Los servidores de transición generalmente se ejecutan en el rango de $ 4,000- $ 5,000 dólares. Sin embargo, la capacidad de identificar problemas que impactan en un entorno de prueba, literalmente, puede ahorrarle miles una y otra vez.
A modo de ejemplo, digamos que usted es capaz de identificar en un entorno de ensayo que sus sistemas web-to-print y Print MIS ya no pasan la información clave correctamente. A continuación, puede trabajar con el proveedor (o proveedores) para resolver el problema sin afectar el medio ambiente actual. Suponiendo que esta revisión se tarda un par de semanas, ¿cuánto dinero habría costado si el impacto se hubiera realizado sólo en un entorno de producción?
Elaborar una lista de verificación de pruebas post-implementación
Cuando no esté bajo presión de una actualización, es necesario desarrollar una lista de control de todas las funciones y procesos clave que necesitan ser probados una vez completada la actualización. En esencia, estos son sus controles y equilibrios. Esta lista debe usarse cada vez que se enfrentan a una actualización importante y debe ser refinado con el tiempo. Aquí hay 3 ejemplos de ítems, tanto para web-to-print como Print MIS que creo que debe estar en las listas de verificación de todos:
Print MIS
• Posibilidad de imprimir informes posteriores de actualización (facturas, jobjackets, órdenes de compra)
• Los campos personalizados (en su caso) se muestran correctamente y pueden ser «por escrito».
• Comunicación bidireccional entre todos los sistemas integrados con el sistema Print MIS
Web-to-Print
• Capacidad para «revisar» una orden
• Posibilidad de enviar una orden al Print MIS con todos los metadatos relevantes y necesarios (si procede)
• Verificación aleatoria de al menos 10 productos en varias tiendas para una apropiada representación / presentación al cliente.
Si bien lo anterior puede parecer obvio, a menudo se pasan por alto o no probados en el caos de una actualización. Una parte de su lista de comprobación debe ser la lista de «mostrar tapones». Estos son los errores o temas que le hacen abortar una actualización y revertir a la versión anterior. Un ejemplo de esto puede ser el fracaso del sismtemaPrint MIS para recibir órdenes desde el sistema web-to-print. Si los tapones de la demostración se presentan después de una actualización, usted necesita ir a su plan de hacer retroceder como se identifica en el número 7 a continuación.
Cómprese el mayor tiempo posible
Aunque a nadie le gusta trabajar durante las vacaciones o fines de semana (seamos sinceros, la mayoría de nosotros lo hacemos de todos modos), Le recomiendo intentar mejoras en una ventana de tiempo en la que tiene la mayor capacidad de solucionar problemas y probar. Esto es especialmente cierto si usted no tiene un servidor de desarrollo. Mi recomendación es que usted no haga nada cerca al fin de mes. La interrupción puede ser demasiado dramática. También pienso que hacer mejoras finales en una semana o, idealmente, en una tarde de viernes es sabio. De esa manera usted puede tener el fin de semana para probar y estar listo para cualquier comunicación en la salida de sus equipos para el lunes por si los problemas se presentan. Esto también minimiza la interrupción de sus clientes, en especial para los sistemas web-to-print.
No se acerque a la actualización solo
Contar con un equipo en reserva para ayudar con las pruebas. Esta es una gran manera de tener expertos en la materia en las áreas clave de prueba. Ellos serán los mejores para ayudar a identificar problemas y determinar cómo trabajar alrededor de ellos.
Tenga un plan de reversión
Después de la actualización se ha completado y usted hace algunas pruebas, ¿qué va a hacer si un tapón se presenta? Un plan de reversión es como un seguro de viaje, que espero que nunca tenga que usar, pero que usted estará muy feliz de tenerlo en caso de que algo suceda. Pensar que esto podría no suceder es ingenuo por lo que necesita estar preparado. ¿Está preparado técnicamente para volver a la versión anterior? ¿Tiene documentación de cómo hacer esto? Este plan puede ser un salvavidas y le permite tomar una decisión inteligente cuando tenga que retroceder a la versión anterior, porque el riesgo de la organización que trabaja en la nueva versión es demasiado grande. Es necesario identificar quién tiene la autoridad para decir «estamos desplegando de nuevo». No necesariamente quiere poner la presión sobre la persona que en el momento está haciendo la actualización. Es más probable necesitar ser alguien del equipo de alta dirección – a lo largo de las líneas de la VP de Operaciones y debe decidirse antes de que comience el proceso de implementación.
Considere la Nube
Si usted está considerando un nuevo Print MIS o sistema web-to-print y hay una versión disponible / hospedada en la Nube, considérela seriamente. Esto toma toda la presión de actualización fuera de sus manos y plantas lo ubica firmemente sobre los vendedores. Con la nube todavía hay riesgos de problemas con una actualización. Sin embargo, cuando se trata de la versión de la nube, los problemas afectan a todos al mismo tiempo, lo que a menudo se aborda de manera rápida con los recursos de ingeniería de mayor jerarquía del vendedor.
Comunicar el plan de anuncio con antelación
La última cosa que necesita para hacer frente en un lunes por la mañana después de una actualización es todo el mundo llamando, enviando un correo electrónico o llegando a su oficina para decir «esto no funciona» o «no sé cómo hacerlo». Antes de la actualización, envíe la comunicación a toda la empresa para asesorar sobre el protocolo como una dirección de correo electrónico tipo de mesa de ayuda para la gestión de las preguntas e inquietudes. Además, designar un equipo (idealmente su equipo de pruebas), que ayude en todas las diferentes preguntas. La capacidad de identificar las tendencias y también priorizar los temas es importante.
Si bien ninguna aplicación siempre va perfectamente, hay muchas cosas que usted puede hacer para mitigar el riesgo. Si se toma el tiempo para planificar una implementación que está controlada y cuidadosamente ejecutada, cosechará rápidamente los beneficios de la nueva versión y reducirá al mínimo la interrupción del negocio y de sus clientes después de la actualización.
Fuente: http://bit.ly/1yybN6V