Gestión de Problemas: tus clientes se merecen una explicación (razonable)

Leo en The Opposite of Luck una entrada sobre un informe de análisis forense realizado para determinar la causa raíz de un incidente producido en el Complejo Tecnológico Fisher Plaza de Seattle y que dejó KO las webs de varios clientes alojadas allí.

El informe completo (en inglés) puede leerse aquí.

Como los chicos de The Opposite of Luck, aplaudo la transparencia con la que Fisher Plaza ha manejado este incidente, sobretodo como deferencia a sus clientes, que realmente merecen una explicación; al fin y al cabo, Fisher Plaza provee servicios de housing y hosting, ese es su negocio: el cliente tiene derecho a saber por qué ese servicio ha fallado de forma tan catastrófica.

De igual forma, tus usuarios tambien se merecen una explicación cuando un servicio IT de los que prestas se cae; no tienes que redactar un informe de 12 páginas para cada problema que analices, pero lo que es inaceptable es encogerse de hombros y decirle: “estas cosas pasan…”. 

Cambios urgentes: WTF???

Perdonad si soy ordinario, pero es que han pasado muchas cosas idiotas en mi oficina últimamente: por fin hemos inaugurado nuestra herramienta de Service desk, después de 9 meses de diseño y rediseño (el tiempo medio de implantación en otros clientes de 1 a 2 meses). Aunque inicialmente la ventaja de esta aplicación es que es ITIL compliant por lo que ayudaría a la adopción de procesos ITIL, el jefe del departamento ha decidido, ehrm, redefinir algunos conceptos de ITIL, especialmente algunos relacionados con la gestión de cambios y de SLAs.

Para empezar, ha creado un nuevo tipo de cambio: el Cambio Urgente. No tiene nada que ver con las emergencias, sino con la urgencia. ¿Qué es un cambio urgente? Un cambio que debe ejecutarse lo antes posible. Pero no a causa de una emergencia. Por ejemplo: un project manager quiere desplegar una nueva versión de su aplicación “Tal”, y lo quiere ahora. Esta nueva versión no resuelve un problema grave de la versión previa ni añade una funcionalidad o un requisito que el negocio necesita por imperativos legales o de cualquier otro tipo ni por cualquier otra razón que se te pueda ocurrir para elevar un cambio de emergencia porque, y este es el problema, no es una emergencia. Generalmente, se tratará de una fecha de entrega demasiado cercana y un project manager poco inclinado a asumir la responsabilidad del retraso de la entrega (para qué asumir la culpa cuando tienes a los de Sistemas y su gestión de cambios que “no desplegarán hasta la semana que viene porque nuestra petición ya no entra en el CAB”).

Donde yo veo una ardua resistencia a seguir el dictado que un marco de buenas prácticas da, mi jefe y sus colegas creen que han tenido una idea genial porque con los cambios urgentes pueden demostrar que están orientados al cliente. Y una mierda. Es pura cabezonería.

Y además, ¿qué narices? ¿¡¿De todos los libros de ITIL desde v1 hasta v3, dónde leches han leído ellos ese invento de los “Cambios Urgentes”?!?

Cómo sobreponerse a la aplastante inercia de la realidad en 4 pasos: paso 2

El paso 1 trataba sobre crear el contexto para el cambio, prepararse para que el cambio ocurra definiendo qué debe cambiar y por qué. El paso 2 trata de determinar a quién le importa realmente (o debería importarle) el cambio y por qué. En muchas conversaciones con compañeros en varias empresas en las que he trabajado, existe un “ellos” difuso y étereo involucrado (a veces incluso un “ellos” explicito y concreto): los procesos no pueden cambiarse porque “ellos” no nos dejarán, o porque alguien que ocupa un puesto determinado de mando no permitirá que el cambio se ejecute. En el paso 2 hace falta establecer un enlace entre el comportamiento (“qué”), la razón por la que debe cambiar (“por qué”) y quién necesita entender que el cambio es necesario. Así de simple… aunque si realmente fuera tan simple, no habría ninguna inercia a la que sobreponerse, ¿no?

Leer más…

Los mecanismos alrededor de esa cuestión incluye hacer llegar la información correcta la persona indicada en el momento preciso, que es lo que determinamos que debía cambiarse en el paso 1 y las razones por las que debe cambiar. Sin contexto, sin razones sólidas y concretas, nadie sensato querrá cambiar nada, porque apoyandolo en justificaciones débiles esos deseos de cambio pueden ser considerados un capricho. Por eso mismo, con contexto, nadie sensato se opondrá a cambiar. En casi todas las empresas en las que he trabajado, mis compañeros culpabande la inercia corporativa a la poca voluntad de cambio de la Dirección, cuando el problema a menudo era que no se había tenido en cuenta a la persona adecuada para crear el contexto, o que la información precisa no se había entregado a la persona que la necesitaba. Y además, no sólo se trata de hacer llegar esa información a la gente adecauda, sino asegurarse de que esa gente tiene intención (o se les puede convencer de que lo hagan) de usarla. En un artículo de Gartner (Use a ‘Friendly’ Approach to Organizational Change and Application Process Improvement”), sugieren trabajar primero con los amigos porque eso ayudará a que el consumidor de la información se incline a usarla, así que conviene no desperdiciar la oportunidad de predicar al respecto si una conversación frente a la máquina del café deriva en el rollo de “necesitamos un cambio…”.

Crear diagramas del contexto y hacer análisis RACI (Responsible, Accountable, Consulted and Informed) son puntos clave, y algunos pasos podrían ser:

• Primero: considerar el proceso en cuestión
• después, considerar al consumidor del proceso y cómo evaluará los resultados
• finalmente, considerar al proveedor del proceso y cómo evaluará los resultados; aquí se puede incluir a los consumidores directos y a los proveedores (y sus jefes)

Esto es básico: es crucial llegar a la mayor parte de altos directivos (aunque en otros casos el objetivo del cambio serán los cargos intermedios). A veces ocurre que las personas que ejecutan un proceso y sus jefes reconocen el contexto para el cambio, pero la necesidad de cambio no se ha mostrado de manera explícita a los que pueden (y deben) dirigir el cambio. En cualquier caso, en este punto sólo hablamos de la persona que debe aprobar o dirigir el cambio, sea cual sea su cargo.

En el paso 3, si se ha conseguido la atención de los que deben dirigir el cambio (y como es muy mala idea escalar un problema sin acompañarlo de una solución), se debería definir de manera precisa qué hay que cambiar (y no vale decir simplemente “los procesos”…).