Cambios improvisados

Una proceso de Gestión de Cambios maduro permite la realización de estos con confianza y minimizando las posibilidades de error. Pero incluso cuando algo se complica proporciona una forma de volver a la situación previa y un aprendizaje para hacerlo mejor en otras ocasiones.

En este artículo utilizaré una entrada del conocido blog de Wardog donde se plantea en tono jocoso la situación provocada por un consultor especialista en “vender humo”.

Sin embargo, lo que me interesa en este caso es que en el artículo se realiza un cambio muy importante en la infraestructura que soporta los servicios de TI de una organización que, a su vez, sostienen los procesos de negocio. Este cambio se realiza sin ningún tipo de análisis previo riguroso y siguiendo sin más la moda del cloud como solución mágica que vale para todo. Resumiendo, el cambio termina siendo un desastre de proporciones épicas.

Analizando el cambio desde un enfoque ITIL echo en falta, por ejemplo, todos los puntos que en Proactivanet se rellenan en la pestaña investigación del formulario de RFC y que al rellenar nos obliga a hacer una reflexión seria sobre el cambio que queremos realizar.

Por ejemplo, no hay un plan de roll-out y menos aún de back-out. Incluso ante un cambio de tal magnitud no se ha definido un plan de pruebas. Podemos ver cómo se inicia el cambio (lo que formalmente sería la entrega) sin tener en cuenta las limitaciones técnicas:

[...] Giro una pantalla de mi PC y le señalo una cifra. 1097 días, 16 horas, 22 minutos, 11 segundos para completar la transferencia. [...]

Ni tampoco el impacto en la actividad de negocio:

[...] Y por supuesto, después habría que establecer el corte de operaciones hasta que se sincronizasen los cambios que la gente haya hecho en el intervalo en los servidores de Suprakillminds. [...]

Tampoco hay unos objetivos claros que permitan definir unos criterios de aceptación. Podemos ver como sobre la marcha se van improvisando el dimensionamiento de la nueva capacidad:

[...] Que estaba yo pensando, MKII… que si en lugar de dimensionar todo a 2.5x, dimensionamos a lo que tenemos ahora mismo y le ponemos un poquito más, qué sé yo, un 20% como mucho no nos quedará algo más acorde con lo que necesitamos? [...]

E incluso si dentro del alcance se incluye toda la infraestructura o sólo los servidores:

[...] MKII desaparece en un departamento y aparece a los pocos segundos con un papel en la mano con el precio del dimensionamiento para los servidores. Obviamente, mucho más asequible y se lo entrega a $Hyperboss que lo coge y lo mira rápidamente. [...]

Por supuesto, la relación coste-beneficio no se considera en ningún momento, aspecto bastante importante y que debería ser el resultado del análisis de cualquier cambio.

La lectura del artículo de Wardog garantiza risas aseguradas, pero en nuestro interior todos deberíamos reflexionar si nuestra organización de TI tiene prácticas “peligrosamente parecidas” a las que se mencionan.

José Luis Fernández Piñero