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

Cuando un cliente contrata a una compañía como la mía un servicio de outsourcing de su departamento TI, siempre llegan con preguntas sin contestar o problemas que necesitan resolver, raramente piden que mantengamos las cosas exactamente como están alegando que su organización y sus procesos funcionan perfectamente. Después de todo, cada organización tiene puntos dolorosos y casi todos los jefes y directivos intentan mejorar sus organizaciones…

Seguir leyendo…


En el curso de la relación con el cliente, sugerimos cambios que pueden usar para mejorar la forma en la que hacen ciertas cosas, para mejorar los problemas reportados; y es entonces cuando nos despliegan el abanico de tópicos y excusas que incluye:

• “Las cosas no funcionan así aquí”
• “Intentamos algo parecido hace unos años, pero no funcionó…”
• “La realidad aquí es que…”

“Realidad”… la realidad, basicamente, define “lo que es”, o al menos, la forma en la que se percibe que es, pero, abstrayendonos, la realidad es una combinación de políticas y procesos escritos y de patrones de conducta implícitos, que no están escritos, pero que definen la forma en la que la organización piensa y actúa, lo que podríamos llamar modelos mentales. La realidad es real, y con la realidad viene la inercia, que es la tendencia de una organización a continuar como está. El cambio es difícil a todos los niveles, tambien a nivel personal, y la inercia de la organización puede pisotear muchas ideas nuevas.

Cómo sobreponerse a la aplastante inercia de la realidad? Empecemos por el paso 1.

Paso 1: define la realidad, qué va mal y cómo puedes demostrarlo

Muchos procesos de cambio comienzan definiendo “lo que es”, o sea: la situación actual, como en la Mejora Continua del Servicio de ITIL, en el que el primer paso sería contestar a la pregunta “¿dónde estamos ahora?”. Estos marcos de trabajo empiezan midiendo el desempeño de la organización de forma que les permita compararlo después en una escala de rendimiento, y poder realizar un gap analysis para evaluar la distancia entre el “donde estamos” y el “dónde queremos estar”. Se definen y se usan indicadores clave de desempeño (KPI) que determinen qué hay que mejorar y evaluar después la mejor forma para cambiarlo, o detectar proactivamente cuando el rendimiento de un proceso empieza a degradarse.

En cualquier caso, estos procesos verticales proactivos están implantados en organizaciones que son ya mucho más maduras que sus competidores y que están al tanto de la necesidad de seguir madurando. El contexto para el cambio ya existe en ellas y aprovechan la ventaja competitiva que les brinda la situación; ¿qué pasa con la mayoría de organizaciones (españolas o no)? El contexto para el cambio no existe en ellas y la necesidad de cambio sólo surge como reacción a un disgusto, que puede ser un gran cliente cancelando su contrato o el fracaso de un proyecto plurianual y multimillonario… o cuando un partner le dice a la organización que debe ser mejor “o si no…”.

El contexto para el cambio es crucial, pero muchas organizaciones no lo crearán porque no tienen KPIs o marcos de trabajo que les proporcionen mediciones, porque existe una gran diferencia entre “lo que es” y “lo que está mal”; esta diferencia se debe mostrar y explicar muy claramente a la Dirección, y la única manerla de hacerlo es en su lenguaje, con mediciones y con cifras; si no las hay, el gap analysis quizás sea útil. Y si no existe nada de nada a lo que agarrarse… siempre se puede apuntar a los puntos dolorosos (temor a catastrofes, quejas de clientes, perdida de contratos, ridículo público, escándalo en la prensa, mala imagen de la compañía…).

Existe otro factor común en estas organizaciones: las cosas se hacen de cierta manera pero nadie sabe ciertamente por qué ni desde cuándo, e intentar cambiar eso te puede volver loco; intentar cambiar comportamientos implícitos, no escritos, los que están fundamentados en el “aquí lo hacemos así” es, de lejos, mucho más difícil que cambiar procesos explícitos (es decir: escritos). Así que poner por escrito cómo se hacen las cosas, aunque se hagan mal, es el primer paso para intentar cambiarlo. Esto forzará la revisión de los procedimientos y procesos empleados en la empresa y conducirá a la reflexión sobre ellos a los agentes implicados. Este paso, desde luego, suele generar rechazo por parte de los que ejecutan esos procesos porque se sienten fiscalizados, interrogados sobre su trabajo y su desempeño. Y están en lo cierto, pero el objetivo no es condenarles, simplemente dejar claro qué se está haciendo mal y crear la ocasión para mejorarlo.

Así, los pasos cruciales para crear el contexto para el cambio requieren correlacionar los resultados actuales con el comportamiento, y el comportamiento con la causa. Resumiendo:

• evangeliza y muestra los datos del desempeño actual de la organización como si fueran los 7 pecados capitales; puedes dar el empujoncito que necesitan a los que ya piensan dentro de la organización que es el momento del cambio; si la organización es del mundo TI, sin duda, hazte apóstol de ITIL y confía en su reputación -es merecida.
• pon por escrito los procesos tal y como se ejecutan a día de hoy; eso obligará a los agentes implicados a revisar cómo se están haciendo las cosas y contemplar la realidad tal cual es; sin duda, eso les llevará a desear el cambio
• asusta a la Dirección; muestrales a dónde puede conducirles la falta de madurez de la organización; hablales de catastrofes destruyendo el centro de datos y parando el negocio durante semanas (no sólo terremotos o atentados terroristas: una tubería rota sobre el techo del CPD ya es una catástrofe); hablales de salir haciendo el ridículo en “5 Días”, de clientes eligiendo a otro proveedor; especialmente, de esos clientes fieles durante años que finalmente deciden no renovar su contrato…

Muy pronto aquí, el paso 2: a quién le preocupa (o debería preocuparle) el cambio y por qué.

El Jurado Español tiene un veredicto: ITIL V3 no es lo bastante bueno para nosotros

Hace un rato, he recibido un mail de un centro de formación TI ofreciendo cursos de ITIL V2 Practitiioner, parcialmente subvencionados por la Generalitat de Catalunya. Estoy hablando sobre cursos de “Service support” y “Service delivery”, ya sabeis, todo ese rollo de ITIL V2. O sea, espero que quede claro: es V2 de lo que se habla, en ese mail, ni rastro de V3 en ninguna línea de ese correo.

Insisto tanto en lo de que solo hay cursos de ITIL V2 porque en España se ha establecido la opinión general de que V2 es mejor que V3, aunque nadie sabe decir exactamente por qué.

Después del salto, las tonterías justificaciones más comunes para apoyar semejante afirmación…

Hay quien dice que ITIL V3 “está orientado para proveedores de servicios, para empresas de outsourcing y tal, para las grandes, eso es para HP o IBM”. Eso es absurdo. Todos estos, cuando empezaron a leer algo sobre ITIL, se saltaron las líneas donde claramente dice que ITIL es un marco de trabajo orientado a procesos donde el departamento TI se convierte en un proveedor de servicios para la compañía, sin importar si es interno, un outsourcing, un co-sourcing o lo que sea? Es más, se generaliza extendiendo el calificativo “proveedor de servicios” a cualquier persona, proveedor, departamento interno, unidad, lo que sea, que ofrezca un servicio o producto al departamento TI o al negocio.

Bien, lo que esta gente quiere decir en realidad es que están, más o menos, acostumbrados a ITIL V2, a la terminología, los procesos, las interrelaciones y, lo que es más importante, los clientes (y los clientes potenciales) se estaban familiarizando con la versión 2 y su glosario. Así que en España estamos ahora vendiendo V2 como si lo hubieramos descubierto hace sólo 3 o 4 años (aunque eso es cierto). Y la sensación que tengo charlando con compañeros y colegas es que en España, ITIL V2 caería en la 4ª fase del Hype Cycle (según la definición de Gartner del Hype Cycle -y si Gartner se interesara un poco en España): estamos adaptando un marco de trabajo que está, de hecho, quedando obsoleto a nivel mundial a raíz de la publicación de ITIL V3 en mayo de 2007 (de eso hace 2 años ya).

Bien, así que parece que ITIL V3 no es lo bastante bueno para los españoles; mejor nos quedamos con nuestro cómodo y agradable ITIL V2, no? Tonterías. En España, la mayoría de los procesos ITIL adoptados pertencen al área de Service Support: Service Desk y Gestión del Incidente y del Cambio, gestión de Problemas, gestión de la Configuración. Pero, eh! Espera! Todos esos procesos se han mantenido en V3! Espera, porque además, se han desarrollado y mejorado notablemente, especialmente la gestión de la Configuración (la auténtica revolución de V3, además de introducir el concepto “estrategía”, es el paso de la CMDB de V2 al Sistema de Gestión del Conocimiento del Servicio, sus CMDB federadas, etc.). Por qué, entonces, todas las tiendas de servicios TI como Abast, T-Systems, Osiatis (la mía, incluso), están ofreciendo productos basados en ITIL V2, sin considerar las mejoras que V3 ofrece? Porque creen que es pronto; creen que los clientes no lo comprarán. Porque no sabemos venderlo. Porque en España, si ITIL V2 estaría en la cuarta fase del Hype Cycle, ITIL V3 ni siquiera se ha colado en el ciclo.

Mi hipótesis: todos los involucrados en la cadena de producción de Gestión de Servicios TI (clientes, proveedores, consultores, etc.) andan peleandose con uno de los conceptos que introduce V3: Estrategia del Servicio (Service Strategy); y esa es una de las novedades más importantes que presenta V3; es lo que convierte a ITIL V3 en una poderosa herramienta de Gobierno TI. La Estrategia del Servicio es el eje alrededor del cuál gira el ciclo de vida de los servicios TI, decide las inversiones que se harán planeando el desarrollo y la mejora a medio y largo plazo de los servicios TI alineandose con la estrategia de la empresa y sus objetivos; dirige el diseño de arquitecturas y servicios, su orientación, establece las pautas generales que guiarán la gestión de TI, construye los raíles sobre los que ha de avanzar el área de TI en la compañía y cómo enlazarán con el negocio, que es, en definitiva, el único objetivo de ITIL: alinear (y realinear de manera continuada) los objetivos de TI con los objetivos del negocio.

Y me da la impresión de que esa es otra línea que demasiada gente se saltó, cuando leyeron lo de ITIL…