El punto débil de DevOps

Hace algún tiempo leí el libro The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, una novela muy inspiradora al respecto del uso de las técnicas Lean en el mundo de las operaciones IT y su fuerte relación con el mundo del desarrollo y DevOps. Como novela es entretenida, explica y ejemplifica los conceptos fundamentales y es un cuento de hadas, donde todo va de acuerdo a lo que el guionista ha pensado y desemboca en un fantástico final feliz. Desde luego, no creo que sea necesario recordarles a los lectores que lo que pasa en esos mundos imaginarios no siempre se parece a la realidad y al contrario que en el mundo de Fantasía, a este otro lado a veces las cosas no son tan maravillosas. (Nadie piensa que los lobos hablan después de leer Caperucita, verdad??)

En un momento del libro, el protagonista está reflexionando al respecto de cómo acelerar el ritmo de pasos a producción en el equipo de desarrollo (se han puesto el objetivo de conseguir diez –si, 10- despliegues al día) justamente para seguir los consejos que daba el equipo de Flickr en su conferencia de 2009. Parte de esa reflexión le lleva a decir la frase

 

Until code is in production, no value is actually beign generated, because it is merely WIP stuck in the system

o sea… hasta que el código no está en producción no se está generando realmente valor porque es únicamente WIP atascado en el sistema

Claro, el paralelismo con el libro de Service Operations de ITIL® y el sentido de que no es hasta este momento cuando realmente se entrega valor al usuario del servicio es directo… pero mi reflexión posterior me llevó un poco más adelante: recordé aquel post que había escrito al respecto de que en realidad el valor de un servicio no es como dice ITIL® el equivalente a Utilidad x Garantía, sino que debemos incorporarle un factor más: el uso.

Así, pues, y siguiendo con la reflexión, tanto da que seamos capaces de hacer 1, 10 ó 100 despliegues al día, que si el usuario no es consciente de lo que pasamos a producción y no es capaz de usar las nuevas funcionalidades que estamos incorporando, en realidad IT habrá generado su parte de valor pero si damos un paso atrás e intentamos encontrar dónde está el valor aportado/generado por el negocio no lo encontraremos: así, mi propuesta de modificación a la frase es

Until code is properly USED to GENERATE the EXPECTED VALUE, it still will be WIP stuck at any other point of the system

o sea.. hasta que el codigo no sea USADO de forma adecuada para GENERAR el VALOR ESPERADO, seguirá siendo WIP atascado en cualquier otra parte del sistema.

Intenté contactar con Gene Kim, el autor del libro, a ver qué opinaba del tema, pero es un hombre ocupado y no he conseguido llamar su atención… pero sí que hubo otra persona que dio su punto de vista: Byron Miller opinó al respecto diciendo que en el fondo todo lo relacionado con formación, cambios culturales y modificación de procesos debe ser también considerado WIP.

Vamos a ver si soy capaz de explicar hasta qué punto es importante esto: dentro de las metodologías ágiles (Scrum, XP, etc.) hay un aspecto que es fundamental y es lo que llaman la definición de “HECHO”. Sin esta definición no funciona nada… y es algo que está aquí para arreglar gran parte de los problemas que tenemos en las TIC.

Es necesario que todo el equipo que participa en la cadena de valor del servicio llegue a un consenso al respecto de qué significa decir que una petición del cliente esté HECHA. Históricamente, cada uno de los diferentes silos que participan en la entrega de esta petición ha interpretado como HECHO el momento en que lo da por terminado (según su visión especializada de las cosas) y lo pasa al siguiente elemento en la cadena. Así, el analista da por hecho el análisis cuando lo pasa a desarrollo, el desarrollador da por hecho el código cuando lo pasa a QA Testing y toda la división de desarrollo da por hecho el programa cuando lo entrega a producción.

Pero la cosa no debe de ser así. Todo el equipo, completo, debe tener una definición común de hecho. ¿Cuándo está hecho el evolutivo? ¿Cuando entrego a Ops? ¿Cuando lo despliego? ¿o cuando he conseguido que los usuarios lo usen adecuadamente?

Desde el punto de vista del negocio, claramente el evolutivo está hecho cuando entrega el valor prometido y eso sólo se hace mediante el USO, por lo tanto HECHO incluye también la formación, el cambio cultural, la modificación de los procesos de negocio, etc etc etc.

Así que, desde luego, todo ese aspecto soft de la entrega de servicios forma parte del WIP.

Ahora vamos a darle otra vuelta de tuerca a todo esto. Si pensamos en la teoría de las limitaciones, la propuesta de Goldratt dice en parte que dado un sistema, siempre existirá un cuello de botella. Es más, resulta que cualquier mejora que pretendamos aplicar al sistema debe de ser directamente sobre el cuello de botella, ya que si actuamos antes el resultado será un atasco monumental a la entrada del cuello de botella; y si actuamos después nos encontraremos con que no servirá de gran cosa puesto que será la limitación actual del sistema la que no esté entregando suficiente “ritmo” a las piezas que se encuentran detrás de ella. Así, cualquier mejora introducida en el sistema si no es en el cuello de botella, o bien no tiene efecto o bien contribuye a empeorar el rendimiento global del sistema.

Ufff… esto es complicado, pero va cogiendo sentido!

¿Qué pasa cuando agilizamos el desarrollo y no agilizamos los pasos a producción? Pues que se produce un atasco monumental en los PaP, y eso provoca… que la gestión de cambios es “el malo”, el que no deja pasar las cosas a producción, el que es un freno para la organización. Y qué pasa cuando agilizamos también el paso a producción? Que nadie se explica cómo puede ser que no se usen las nuevas funcionalidades de las aplicaciones y que cuando se usan el equipo de soporte y apoyo funcional no da abasto (hemos movido el atasco a otro sitio).

Si juntamos una definición de HECHO con visión completa, en la que el evolutivo está hecho cuando se está usando y está generando valor a la organización, con la “prisa” por adoptar metodologías DevOps que nos permitan hacer diez despliegues al día, nos encontraremos con que ahora el cuello de botella es el usuario, que no es capaz de absorber tanto cambio de forma continuada o la organización no permite que el usuario dedique el tiempo necesario a formación para ser capaz de absorber los diez despliegues al día.

En mi opinión, el ejemplo más claro de esta situación es el mundo de las Apps, en las que se despliegan (no 10 veces al día, pero hay algunos que despliegan al menos una vez al mes) nuevas funcionalidades que son documentadas en un pequeño “Read-Me” o similar que nadie se lee. El resultado? Pilas de nuevas funcionalidades que nadie usa… waste por todas partes porque no se está entregando valor con ese código desplegado, pero un equipo de desarrollo orgulloso de haber conseguido los hitos previstos.

De esa forma, todo vuelve a girar alrededor del “activo más importante de las empresas”: las personas. Las personas son la pieza sobre la que no tenemos capacidad de automatización y por lo tanto será el elemento que siempre será nuestro cuello de botella y sobre el que debemos trabajar en primera instancia, porque de lo contrario lo único que estaremos haciendo será cambiar el atasco de sitio (práctica muy habitual en las organizaciones estructuradas por silos, donde no hay una visión de conjunto: “yo ya he hecho mi parte… el resto no es cosa mía” y donde, además, se ponen objetivos por cumplimientos parciales)

En fin, todo esto ha sido una reflexión provocada por un párrafo en una novela… así que es probable que esté profundamente equivocado. ¿Tienes experiencias al respecto? ¿Trabajas en una empresa DevOps y nos quieres contar cómo transmites todo el cambio a la comunidad de usuarios?

¡Usa los comentarios, por favor!

Postdata: Ops! Por cierto… si somos capaces de hacer diez despliegues al día de correctivos, adelante!!! La comunidad de usuarios y los equipos de soporte lo están deseando! Es decir, todo este discurso es válido cuando el cuello de botella es el usuario por su ritmo de adoptar/asimilar/aprender las nuevas funcionalidades que estamos desplegando. Pero si hablamos de demanda fallo, el discurso es completamente distinto!

Visión sistémica en el outsourcing – o nos crecen los enanos

Llevo varios meses trabajando con diversas empresas que se encuentran en una situación de outsourcing con múltiples proveedores. Cada una tiene sus características, sus situaciones especiales, si carácter; pero eso sí, hay algunos detalles que son factor común. Uno de estos puntos en común es la dificultad que tienen para gobernar los contratos con proveedores de servicios que están trabajando en diferentes áreas.

Cuando una empresa se plantea externalizar parte del trabajo que se realiza debe tomar una primera decisión: ¿por dónde pasamos las tijeras?  ¿cómo “troceamos” el modelo de provisión de servicios al cliente interno para asignar partes de este trabajo a terceros? Básicamente, hay tres respuestas a esta pregunta:

Opción 1:  trocear por servicios – Se le asigna a un proveedor la entrega de un servicio completo, extremo a extremo, hacia el cliente interno. Es una práctica muy poco (o nada) empleada en IT, pero sí que se ve en otras áreas de negocio, donde se le llama Business Process Outsourcing o BPO.

Opción 2: trocear por funciones – Se le asigna a un proveedor la ejecución de una función (un grupo de personas con un cuerpo de conocimiento específico). Esto es lo más habitual en el entorno de IT, y así vemos a terceros realizando “Gestión de Infraestructuras”, “Gestión del puesto de trabajo”, “Gestión de Aplicaciones”, etc.

Opción 3: combinar las dos anteriores con un reparto regional – Cuando la empresa está localizada en múltiples sedes o en diferentes países, se puede realizar una aproximación en la que se asigna una función o un servicio por región geográfica (por ejemplo, la “Gestión del puesto de trabajo” para la región de “Sur de Francia”)

Una vez tomada la decisión, viene la siguiente fase: la creación de los contratos; aquí ya se empieza a diversificar el asunto, y normalmente serán los responsables de las diferentes funciones (del área TI interna) quienes definan los requerimientos para estos procesos de externalización, resumiendo en pliegos o RFPs las necesidades y las primeras guías de cómo se va a gobernar la ejecución del contrato (aparecen los primeros indicadores, los primeros borradores de niveles de servicio y de SLAs, etc)

Si nos fijamos bien, en este momento del proceso comienzan a sentarse las bases de lo que será en el futuro el “nuevo modelo de prestación de servicios” de IT a su cliente (a.k.a. “el negocio), y aquí es donde comienzan a sentarse las bases de los futuros problemas de gobernabilidad: lo que en una primera fase fue la definición holística de un modelo ahora se ha traducido en una contratación por partes y de ahí viene el título de este post: es necesario mantener una visión sistémica del conjunto y es necesario transmitir esa visión sistémica a la contratación por partes.

¿Nunca has tenido la sensación de que gobernar tu departamento de IT se parece a una partida de Whacka-Mole?

Básicamente, la sensación viene producida porque cuando aprietas en un sitio, el problema sale por otro lado… y la razón simplemente es que, a pesar de que en la superficie los contratos con tus diferentes proveedores sean inconexos, por debajo están conectados; entre ellos, con nosotros, con los clientes, con las personas; formando una intrincada red de túneles por las que se mueven los topos, los enanos, los problemas, el dinero y siempre aparecen por donde menos te lo esperas.

Es por esta razón por la que debemos adoptar una visión sistémica, de sistema, de todo lo que ocurre en este entorno.

Yo creo que el mejor ejemplo que se puede dar para entender esto es poner un caso simple: una empresa que tiene un equipo interno de Sistemas (que se encarga de la gestión y administración de las infraestructuras, sistemas operativos, máquinas, middleware como las bases de datos o los servidores web, comunicaciones…), un proveedor externo que se encarga del soporte al usuario y otro proveedor externo que se encarga de la gestión de aplicaciones.

Aquí vemos un sistema formado por 3 componentes (a gran escala) que colaboran entre sí para entregar un conjunto de servicios TI al cliente y que se ven regulados por una serie de contratos. Veamos cómo son estas reglas de juego (simplificadas en aras de que se comprenda bien el ejemplo, claro!)

EQUIPO	RESPONSABILIDAD	OBJETIVOS
SISTEMAS	Mantener las infraestructuras en marcha con los niveles adecuados de capacidad y disponibilidad	Disponibilidad de los Sistemas Rendimiento de los sistemas
SOPORTE	Atender las incidencias y peticiones de los usuarios	Resolución de incidencias en plazos Ejecución de peticiones en plazos
GESTION APPs	Mantener y evolucionar las aplicaciones de negocio	Cumplimiento de plazos y presupuestos de desarrollo

Ante esta situación, si pretendemos gobernar el sistema mediante el uso de indicadores y SLAs nos encontraremos con que:

1. A pesar de tener una correcta disponibilidad y rendimiento de los sistemas, los usuarios pueden estar completamente descontentos (es necesario incorporar una figura que vele por el servicio extremo a extremo, independientemente de las 3 funciones que tenemos en el ejemplo)
2. El proveedor de soporte… ¿cómo nos factura por el servicio? Evidentemente, es justo que a mayor carga de trabajo nos pueda facturar más; sin embargo, la mayor carga de trabajo puede ser generada en otras de las funciones (que, en el caso de Gestión de Aplicaciones es otro proveedor al que no le interesa lo más mínimo reducir la carga de trabajo de Soporte)
3. El proveedor de desarrollo, ¿qué objetivos tiene? Cumplir plazos y ajustarse al presupuesto. Simplemente eso.

Así, en este ejemplo vemos rápidamente que la tarea del CIO será hacerse con un martillo y comenzar a golpear enanos que le irán creciendo eternamente… cambiará 1, 2… hasta 7 veces de proveedores y seguirá con el martillo porque la causa no es una incompetencia del proveedor, sino un sistema diseñado para fallar. Apretará al de soporte, pidiéndole que resuelva en plazos y el de soporte hará hasta que los números se lo permitan. El de desarrollo cumplirá plazos y presupuestos, pero a costa posiblemente de producir desarrollos de baja calidad que llenarán al SAU de llamadas o que malgastarán los recursos de sistemas hasta tener que ampliar máquinas una y otra vez. Ahorraremos en un sitio, pero los costes se irán a otro lado.

¿Y todo esto por qué? Porque los objetivos individuales van en contra de una visión de conjunto. Al tener objetivos individuales en cada contrato, estamos rompiendo la visión de sistemas y estamos primando la creación de silos verticales. Además, no nos engañemos: el objetivo de cada uno de los proveedores de servicios será siempre, salvo contadísimas excepciones, “barrer para casa”, así que o imbuimos la visión sistémica desde el principio, en el propio diseño de “por dónde paso las tijeras” y añadimos esa visión en los contratos y en la operativa diaria, construyendo equipos focalizados no en el cumplimiento de indicadores parciales sino en la entrega real de valor al cliente, o estaremos toda la vida dándole golpetazos con un martillo a los enanos que nos crecen por todas partes. Por ejemplo, podríamos:

1. Hacer co-responsable al proveedor de desarrollo de las implicaciones de su software en soporte y en sistemas.
2. Hacer que el proveedor de soporte sea co-responsable de la mejora continua de las aplicaciones y los sistemas.
3. Hacer que el equipo de sistemas sea co-responsable en la definición de arquitecturas y estándares para apoyar al equipo de desarrollo.
4. Hacer que todos tengan responsabilidad sobre indicadores globales de servicios extremo a extremo.
5. Establecer responsabilidad transversal de la entrega de servicios entre las diferentes funciones.
6. Establecer, como decía Walter en una de las presentaciones del itSMF Catalunya 2011, un único indicador: satisfacción del cliente. Perder un poco el foco en el cumplimiento de SLAs y poner el foco en lo que nos importa: el cliente

Ya lo decía Jim Womack en una de sus últimas conferencias: EL problema es que el poder y el control se ejerce verticalmente, cuando el valor al cliente fluye horizontalmente. ¡¡Gestionemos la horizontal!!

El ITGI presenta el informe GEIT

Este fin de semana el IT Governance Institute (ITGI) ha presentado su cuarto informe global sobre la situación del Gobierno de las TIC. Está basado en una encuesta realizada sobre 854 directivos tanto de unidades de negocio como de IT de 21 países y en 10 sectores diferentes con lo que la amplitud y globalidad del informe están garantizados.

Las conclusiones más importantes que presenta el informe son:

• El aspecto al que más importancia se da es el de la creación de valor a través de las inversiones en TI. Los aspectos más problemáticos son el incremento de los costes y la falta de personal.
• Hay una correlación entre la ubicación del CIO en la jerarquía corporativa y la proactividad que presenta el área TIC.
• La importancia del Gobierno de las TIC: sólo un 5% de los encuestados no lo consideran importante.
• Las prácticas de outsourcing siguen siendo predominantes.
• El auge del cloud computing: alrededor del 40% de los encuestados se plantea utilizar la nube para servicios de misión crítica.
• La contención del gasto se convierte en prioridad.
• La utilización del social media tiene poco impacto.

Dado que es la cuarta edición de este informe, una de los aspectos más interesantes es poder ver la evolución desde el año 2004 de las diferentes preguntas realizadas en el informe, como podemos ver en esta gráfica que muestra la penetración de los diferentes estándares y marcos de trabajo.

En conclusión un informe interesantísimo si quieres estar al día de lo que se cuece en términos de IT Governance y si quieres tener material para pensar al respecto de cómo está tu organización en estas cuestiones.

Puedes descargarte gratuitamente el informe de la web de ISACA en este enlace

El último del año … y va sobre Valor

Mucho se oye hablar sobre el valor que aportan las TIC, mucha tinta (digital) se ha gastado y en los foros hay más de una discusión al respecto… ¿Qué valor aportan las TIC?, ¿Cuanto valor aporta un servicio? ¿Cuál es el valor real de las inversiones en TIC?

Muchas preguntas con muchas respuestas, pero a mi últimamente me ronda una idea en la cabeza: me da la sensación de que hay una respuesta a todo esto que va más allá de las respuestas tradicionales.

Hace mucho, mucho tiempo, cuando estaba recién egresado de la Universidad, me dedicaba a hacer programas en Clipper. Por aquella época era normal (aún sigue siéndolo, pero menos…) que mis hermanos me preguntaran si yo sabía usar un programa de contabilidad, o hacer un plano con el AutoCad o cosas así.. claro, ante la respuesta de “Pues… la verdad es que no!” siempre decían lo mismo: “Pero tío.. tú no eres informático?”

Al principio trataba de explicarles a qué me dedicaba en concreto, pero era complicado así que un buen día me salió la metáfora perfecta:

mira, brother… yo en realidad no soy mecánico; no tengo ni idea de coches ni de motores: sólo me dedico a fabricar llaves inglesas.

¿Se preguntarán los fabricantes de llaves inglesas cuál es el valor que aporta su herramienta?

Una de las grandes aportaciones de ITIL V3 es la definición del valor que aportan los servicios TIC en términos de Utilidad y Garantía. Utilidad –aquello para lo que sirve el servicio – y Garantía – en qué términos lo entregamos –

Así que la llave inglesa aporta valor en el sentido en que puede apretar y aflojar tuercas en un rango de X pulgadas y en el sentido en que puede aplicar una fuerza Y sin romperse ni doblarse ni malearse su material.

¿Y si utilizo la llave inglesa para hacer palanca para abrir una botella de cerveza? ¿No me aporta valor? O si la uso para clavar un clavo, para separar dos ladrillos mientras busco el metro, para rascarme la espalda…

En fin, que la llave inglesa no sólo me aporta el valor que pensó el fabricante que yo necesitaría, sino que me aporta todo el valor que mi imaginación como usuario de la herramienta sea capaz de sacarle.

Si llevamos este razonamiento al mundo de las TIC, veremos que una cosa es el valor que yo, como “fabricante” o “proveedor” de servicios aporto a mi cliente al ajustarme a sus necesidades declaradas, y otra cosa muy distinta es el valor que aporta al negocio el uso correcto, adecuado e incluso innovador e imaginativo de las herramientas que IT pone a disposición de los usuarios.

En conclusión, el valor que las TIC aportan al negocio se compone de la provisión adecuada de servicios TIC unida a un uso adecuado y exigente (que saque el mejor partido posible) de esas herramientas/servicios; y esto nos lleva a otra situación interesante: el VALOR no es una cuestión del Departamento de Informática, porque el USO no está en sus manos, sino que está en las manos de las organizaciones (departamentos, áreas, etc) de usuarios (que no siempre coinciden con el cliente).

Así, la aportación de valor al negocio es una cuestión cultural y organizativa… CORPORATIVA.

Feliz Año Nuevo!

La Gestión Financiera de las TIC - Presupuestos

En lo que se refiere a la relación con el Cliente, hay tres herramientas que son la columna vertebral de cualquier modelo de Gestión de Servicios TIC: la Gestión de la Demanda, que permite responder a la pregunta ¿Qué quieres que te dé?, la Gestión de Niveles de Servicio, que responde a la pregunta ¿Cómo quieres que te lo dé? y la Gestión Financiera, que responde a la pregunta ¿De cuánto dinero dispongo para hacerlo?.

En este último punto, aparecen tres grandes prácticas o subdivisiones, totalmente relacionadas unas con otras: la Gestión Presupuestaria, la Contabilidad de Costes y finalmente la Gestión de la Facturación.

Nos centraremos en este artículo en las dos primeras, porque la facturación requiere una visión completamente diferente.

Cualquier CIO de cualquier organización del mundo se enfrenta periódicamente al reto de preparar los presupuestos del periodo siguiente. Para ello, se encuentra con que hay unas condiciones de contorno especiales: por una parte está el paquete necesario para “mantener el negocio como hasta ahora” (lo que los angloparlantes llaman el business as usual) y por otra parte está todo el paquete necesario para acometer la variación (mejoras en los servicios actuales o nuevos servicios a construir), por lo que todas las entradas provenientes de la Gestión de NIveles de Servicio y de la Gestión de la Demanda son especialmente importantes en este momento.

Pero también existe una condición administrativa importante, que es la que obliga a que el presupuesto del área TIC se pueda combinar con el resto de presupuestos de la organización para que la alta dirección pueda disponer de una visión completa y agregada de las previsiones de gasto e inversión en la compañía. Esta necesidad es la que provoca que se requiera de un paquete estandarizado de partidas presupuestarias que serán comunes a todas las unidades organizativas.

Es precisamente esta necesidad de agregación corporativa la que provoca que los presupuestos TIC suelan tener una estructura “artificial” que no facilite especialmente la gestión de la operativa económica del departamento y por lo tanto el CIO se ve en una situación en la que o bien mantiene una “doble gestión” o bien se mueve por intuición en un terreno peligroso.

Trabajando de esta manera, los presupuestos tienen tienen la misma estructura en todas las unidades de negocio, lo que le facilita la visión a la alta dirección, pero para que el CIO pueda articular una correcta Gestión de Servicios es necesario que el presupuesto adquiera una dimensión adicional: la de los servicios. Cuando conseguimos esta segunda dimensión, de repente nos damos cuenta de que tenemos en nuestras manos una de las herramientas más potentes que proporcionan las metodologías de gestión para objetivizar y racionalizar la relación con el cliente.

La gran contrapartida que tiene esto, es que no basta con sólo realizar un presupuesto; luego, a lo largo de todo el año será necesario realizar un seguimiento del presupuesto, lo que significa que entra en juego el segundo subproceso de la Gestión Financiera: la contabilidad de costes. Será necesario que durante todo el año vayamos realizando una contabilización de cada uno de los gastos que se realicen y los vayamos distribuyendo como costes directos o indirectos a cada uno de los servicios, de manera que esto nos permita responder a la gran pregunta: ¿Cuánto te ha costado cada servicio? (que es mucho más interesante que "¿Cuánto me cuestan las TIC?)

Teniendo esta información, ahora podremos tomar decisiones importantes (de reducción de costes, de continuar la inversión, de actualización o renovación tecnológica…) con criterios objetivos y de acuerdo con la estrategia corporativa: hemos construido, casi sin darnos cuenta, una de las principales herramientas de alineación y estrategia del área TIC.

PS: Dedicado a todos aquellos que me aprietan para que siga escribiendo, a pesar de lo que me está costando últimamente. ¡¡Gracias!!

Subcontratando el riesgo

Tanto el blog de Joseba Enjuto como el de Javier Cao tienen un sitio preferente en mi lector de feeds, así que he podido leer en estos días un par de artículos muy interesantes: Caracterizar un Servicio, de Joseba y una reflexión generada por este primer artículo llamada La Subcontratación del Riesgo de Javier.

En ambos artículos se habla de la componente de riesgo que hay en la externalización y Javier acaba con una frase matadora:

Por que de lo contrario, cuando el Responsable de Seguridad vaya a comprobar qué ha pasado, podrá encontrarse al Steve Urkel de turno diciendo ¿he sido yo? y la cabeza a cortar será la que quien contrató un servicio inadecuado.

Es decir, que no se puede subcontratar o externalizar "a lo loco", sino que siempre debe quedar una capa de control y supervisión dentro de la propia organización para garantizar que se realice un seguimiento adecuado de lo que se ha contratado fuera.

Aquí (como en tantos otros sitios) COBIT nos puede ayudar. El Objetivo de control de alto nivel DS2 indica que se deben gestionar las relaciones con terceros. Fijémonos qué nos dice en la descripcion del OCAN

La necesidad de asegurarse de que los servicios proporcionados por terceros cumpla con los requerimientos del negocio requiere de un proceso de gestión apropiado. Este proceso se cumple mediante la correcta definición de roles, responsabilidades y expectativas al respecto de los acuerdos con terceros, así como revisando y monitorizando dichos acuerdos buscando su efectividad y cumplimiento. Una correcta gestión de estos servicios minimiza los riesgos asociados a proveedores poco efectivos o productivos.

Ajá! Una correcta gestión de los servicios minimiza los riesgos asociados a los proveedores... vamos bien. ¿Y los objetivos de control detallados?

DS2.1 Identificación de las relaciones con proveedores. Básicamente, mantener un catálogo de proveedores "homologados" con información al respecto del tipo de proveedor, solvencia, significatividad y criticidad.

DS2.2 Gestión de la Relación con proveedores. Asegurarse de que el proceso de gestión de relación con proveedores está en marcha para cada uno de los proveedores de nuestro catálogo.

DS2.3 Gestión del Riesgo de proveedores. Identificar y mitigar los riesgos relativos a la capacidad del proveedor para continuar prestando los servicios de una forma segura y eficiente.

DS2.4 Monitorización del rendimiento de proveedores. Establecer un proceso que monitorice la provisión del servicio para asegurar que el proveedor está cumpliendo con los requisitos de negocio actuales y continúa cumpliendo los acuerdos contratados y los SLAs establecidos, así como para asegurar que el proveedor sigue siendo competitivo en el mercado

Por último, el modelo de madurez va (como siempre en CobiT) desde el 0-Inexistente hasta el 5-Optimizado, donde y a modo de ejemplo vemos que el nivel 1-Inicial indica

La dirección es consciente de la necesidad de establecer políticas y procedimientos de contratación. La medición de los servicios es informal y reactiva. Las prácticas dependen de la experiencia de los individuos o del tercero

y el nivel 4-Gestionado indica

Existen criterios formales y estandarizados para la relación con terceros, incluyendo planificación, costes, facturación, responsabilidades. Las cualificaciones y riesgos de los proveedores se analizan periódicamente. Los requerimientos de servicio están alineados con los del negocio y existe un proceso que permite analizar el rendimiento del proveedor. Se tienen en cuenta los costes de transferencia y se han acordado KPIs y KGIs

Asi, vemos claramente que CobiT nos ayuda, no sólo a ser conscientes de que es importante mantener una capa de control que nos permita asegurar que cuando se cede un trozo de los servicios TIC a un tercero, éste se va a comportar como hemos acordado, sino que tambien nos ayuda a establecer estos controles.

Por último, recordar que CobiT es un marco de mínimos donde vemos los controles mínimos que debemos establecer.

Mapping ITIL V3 with Cobit 4.1

ISACA ha publicado el documento de mapeo entre ITIL V3 y Cobit 4.1; es el resultado de un trabajo que era bastante complicado de hacer, ya que como en los demás documentos de mapeo, se intenta realizar un análisis de cómo se referencia cada uno de los objetivos de control detallados de Cobit en ITIL V3 y para poder hacer esto el equipo de trabajo debe tener grandes conocimientos de ambos extremos de la comparación.

En este estudio ha habido varias cosas que me han llamado la atención: lo primero es la evolución que ha habido en la metodología de realización de estos estudios: si miramos el documento de mapeo de ITIL V2 con Cobit 4.0 (fechado en Enero de 2007) veremos que el nivel de detalle al que se ha llegado en este nuevo análisis es mucho mayor y que ya no es tan absoluto como antes (en el de V2 se analizaba si un objetivo de control se cubre o no, booleano, blanco o negro); sin embargo, ahora hay una escala en la que se habla de cubrir "mucho, poco o nada" un objetivo de control.

Otro de los detalles que me ha parecido interesante es ver de forma gráfica la evolución de ITIL en cuanto al nivel de cobertura a las necesidades de un departamento IT. Si miramos los mapas de cobertura veremos que ITIL V2 cubría una pequeña parte de Cobit (sobre todo en la parte de Deliver and Support, como era de esperar) mientras que la cobertura de V3 es mucho más amplia

fuente: ISACA

Por último, me llamó la atención ese "agujero" que quedaba en DS... ¿qué pasaba con DS7, que no estaba cubierto?; así que me fui al manual de Cobit a buscar qué era el DS7 y me encontré con una gran sorpresa:

DS7 Educate and Train Users

Impresionante! Según este análisis, ITIL V3 no cubre en ningún aspecto la formación del usuario final. Y al menos por lo que yo he leído, es prácticamente cierto, salvo porque en alguna parte del Service Transition se habla de formar a los usuarios y en V2, en alguna parte de la Gestión de Versiones también se habla de la formación de usuarios. Pero desde luego no es algo a lo que se le preste una atención especial sino que se menciona "de pasada".

¡¡Qué gran carencia!! Visión de servicio? Tratar al usuario como a un cliente? Hacemos de todo para asegurar unos servicios de calidad y no nos acordamos de formar a los usuarios en el uso de los servicios?

Aquí me viene a la cabeza la definición de Mark Toomey sobre el Gobierno de TI y la nueva norma ISO 38500:

Las TIC son una herramienta del negocio. Es responsabilidad del Negocio determinar cómo, cuándo, dónde y porqué utilizará la herramienta y es responsabilidad de IT proporcionar la herramienta que satisfaga estas necesidades.

Pero no sólo estamos hablando de entregar una herramienta que satisfaga las necesidades, sino que también hemos de garantizar que quien ha de usar la herramienta sabrá sacar el máximo partido de ella; y no ya sólo por una visión egoísta del tema, en cuanto a que a medida que los usuarios estén más y mejor formados, menos problemas tendremos en IT (en soporte funcional, técnico o en peticiones, por ejemplo) sino que cuanto más y mejor estén formados los usuarios más partido podrán sacar de las herramientas que les proporcionemos y podrán aportar mayores eficiencias gracias al uso adecuado de las TIC.

Formar a los usuarios es una gran inversión, pero ITIL V3 se olvidó de ello.

Acto de presentación del 191 de Novática

Ayer, día 14 de Mayo del 2008, se hizo un pequeño acto en el Ateneo Barcelonés para la presentación del número 191 de Novática,  dedicado al Gobierno de las TIC.

Fue un acto muy agradable, con cuatro presentaciones y unas 50 personas en una sala de la dimensión adecuada para que no diera sensación de agobio ni de vacío.

Las presentaciones fueron, por orden de aparición:

• Didac López: Presentación de la revista y del trabajo realizado
• Antonio Valle: El estado del arte en el Gobierno de las TIC
• Aleix Palau: El estado del Gobierno de las TIC en España
• Tomás Roy: El punto de vista de un usuario en una gran entidad (Generalitat de Catalunya)

No me cansaré de decirlo: el 191 de Novática hará historia. Historia por la calidad de los contenidos, por la difusión que se ha hecho y se hará de la revista y por una aproximación menos (mucho menos!) techie a la profesión desde ATI y desde Novática.

Hoy me llegaba un mail de un amigo... sus palabras literales:

Yo fui para que me dieran la revista, ahora tengo en mi poder una mítica Novática 191 :)

La versión en inglés de este número de Novática se puede descargar ya aquí, y la versión en castellano se podrá descargar en breve aquí.

III Congreso Interacadémico 2008

Ayer se celebró el III Congreso Interacadémico en la Universidad Carlos III de Madrid. Por los comentarios que he oído, el congreso fue todo un éxito tanto de asistencia como de organización y calidad de las presentaciones.

Desde aquí, mi más sincera felicitación a todos los participantes.

Tenía previsto ir a dar una ponencia sobre un caso de estudio al respecto de cómo definir un Plan Estratégico de Sistemas de Información utilizando conceptos extraídos de metodologías y marcos de trabajo estándares como ITIL V2 y V3, CobiT o Six Sigma pero finalmente me fue imposible asistir.

Aprovechando que el amigo Jorge, de Sistemas Decisionales, estaba por allí con su ponencia sobre Agile BI Governance, le pedí el favor especial de que diera la ponencia por mí y él, como es un jabato que no le tiene miedo a nada, allá que se plantó.

Las presentaciones estarán colgadas en la web del itSMF España, y yo he colgado la mía (bueno, ahora ya de Jorge) en el espacio colaborativo para usuarios registrados.

El número 191 de Novática

En algún momento anuncié en este blog que estaba participando en el equipo editorial de Novática para producir un monográfico sobre IT Governance que tendría que mostrar el estado del arte en este tema.

Pues bien, el número 191 de Novática ya está aquí. En estos momentos debe estar viajando desde la imprenta a tu casa o a tu oficina y el próximo día 14 de Mayo se hará una presentación de este número en un breve acto cuya convocatoria es la siguiente:

Es un placer invitaros a la presentación de la monografía sobre IT Governance del número 191 de la revista Novática, que tendrá lugar el próximo miércoles 14 de mayo en la sala Verdaguer del Ateneo Barcelonès.

La AGENDA de la sesión será:
1. Presentación de la monografía de IT Governance.
2. Estado del arte de los modelos y marcos referencia de IT Governance.
3. Situación de IT Governance en España.
4. Presentación del punto de vista de un usuario de una gran institución.

Datos generales del acto:
Fecha: 14/05/08
Horario: de las 18.30 a las 20 h.
Lugar: Sala Verdaguer, Ateneus Barcelonès
Carrer de la Canuda nº 6
08002 Barcelona
Inscripciones: secrecat@ati.es / 934125235
Esta misma información la encontraréis en:
http://www.ati.es/article.php3?id_article=924

Esta monografía ha sido un auténtico reto, tanto dentro de la trayectoria habitual de Novática como de organización, ya que hemos podido contar con estrellas nacionales, el Grupo de Trabajo del itSMF España que firma uno de los artículos presentados o Jorge Fernández entre otros y estrellas internacionales como Jan van Bon o Rob England (más conocido como The IT Skeptic).

Si puedes asistir al evento, creo que será una oportunidad interesante de ver otras aproximaciones al Gobierno de las TIC desde una entidad con tanto peso como ATI. Y si no puedes, haz lo posible por conseguir un ejemplar de la revista porque será un bombazo.

Desde aquí mi más sincero agradecimiento a todos aquellos que han hecho posible la publicación del número 191 de Novática y a aquellos que me dieron la oportunidad de participar en el equipo editorial.

Nuevo estándar ISO para el Gobierno de las TIC

Hace un poco más de un año, en Noviembre del 2007, Jan van Bon pasó por Barcelona y dio una conferencia en un evento del capítulo Catalunya del itSMF España. Durante esa conferencia dejó caer que se estaba cocinando un nuevo estandard para el Gobierno de las TIC a partir de un estándard australiano que no debíamos dejar de revisar porque estaba en modo Fast-Track para convertirse en una norma ISO.

Como el tema me llamó la atención, hice un poco de búsqueda de información hasta que pude echarle un ojo a la norma australiana: la AS8015-2005 y publiqué en este blog un post en el que explicaba los contenidos de esta norma.

Bueno, ha pasado un año y medio y el nuevo estándar verá la luz el próximo 22 de Mayo en Holanda (cómo no!) donde bITa Center ha organizado un evento de presentación donde se explicarán los contenidos de la nueva norma ISO/IEC 38500 - Corporate Governance of Information Technology.

Aún no he podido leer la nueva norma, pero Mark Toomey (uno de los promotores de la norma) ha explicado en algunos foros las bases principales de la norma:

1. Es una versión corregida y aumentada de la norma australiana AS8015-2005
2. Define seis principios para "el buen gobierno del uso de las TIC": Responsabilidad, Estrategia, Adquisición, Rendimiento, Cumplimiento y Comportamiento Humano (los mismos 6 principios presentes en la AS8015)
3. Establece las tareas que se deben implementar en el Sistema de Gobierno (ojo!): Evaluar, Dirigir y Monitorizar el uso actual y futuro de las TIC para el cumplimiento de los objetivos de la organización.

Uno de los comentarios más interesantes es al respecto de la aproximación "de fuera a adentro" que hace esta visión del Gobierno: estamos hablando "del uso que se hace de las TIC" y no "de la provision que hacemos desde las TIC hacia 'el negocio'".

IT is a tool of business. It is the job of business to determine how, when, where and why it will use the tool – and it is the job of IT to then deliver the tool that fulfils the need. In too many organisations, the business abdicates its role to IT - and wonders why IT does not get it exactly right. In some organisaitons, having abdicated its own job to IT and been dissatisfied, the business then either abdicates its role further – outsourcing supply and trying to outsource its own responsibilities as well – or trying to take on the delivery (supply) role of IT.

The new ISO standard is actually an umbrella that spans both demand (what the business is responsible for) and supply (what the IT department is responsible for). This should help organisations be more clear about what is happening when they do an ITIL of other supply side initiative, and it should help with clarifying what’s not covered by such projects.

 

Por último, otra de las perlas de Mr. Mark es al respecto del concepto de Sistema de Gobierno, algo que sonar, me suena feo... pero que con la explicación de Mark suena mucho, pero que muchísimo mejor:

But “system” is also a fundamental concept. When we think of a system, we think of a set of processes, performed by people with appropriate skills and training, operating within some sort of an organisaiton or control (or authority) structure, and with supporting tools and technology. A Governance System comprises all of these elements, and to get the right system means that work must be done to design and implement that system. Corporate Governance of IT does not merely “happen” – it must be planned and implemented. And once implemented, it must be improved on an ongoing basis to ensure that it continues to be effective, efficient and acceptable.

Crónica del evento bITa Center 2008

Como ya había comentado anteriormente, el pasado día 6 de Marzo se celebró en Madrid el evento Mejores Prácticas en la Gestión de TI 2008 organizado por bITa Center.

Asistí a 5 presentaciones y a la mesa redonda, y me perdí 2 de las presentaciones a las que quería asistir, una por error y otra por despiste. Pero el día dio para mucho: me encontré con mucha gente conocida, varios del itSMF, otros de clientes y entre ellos, volví a tener un buen rato de charla con Jan Van Bon (siempre es más que interesante charlar con este hombre).

La primera presentación fue la de Michael Nieves, coautor del libro Service Strategy dentro del set de ITIL V3. Tengo que decir que como presentación fue un poco aburrida, pero hubo un par de cosillas que me llamaron la atención:

Primero, que la clave en la estrategia de servicios está en encontrar lo que realmente significa valor para nuestro cliente.

Segundo, una interesante comparación entre el sentido de estrategia entre ITIL V2 e ITIL V3.

Tercero, la estructura organizativa que plantean

 

Luego asistí a la presentación de Jan Van Bon, autor de varios libros, como el de IT Service Management , and introduction based on ITIL. Este hombre lleva varios años peleando por un modelo más simplificado y homogéneo para la Gestión de Servicios TIC y precisamente este fue el contenido de su presentación: el Strategic Alignment Model Enhanced (SAME).

Tengo que decir que comulgo bastante con las ideas de Jan, así que muchas de las cosas que se explicaron en esa presentación ya han sido comentadas de una u otra manera en este blog.

Primero, una explicación para hacer hincapié en que ITSM no es lo mismo que IT Governance, vaya.. que no es lo mismo Gobierno que Gestión.

Segundo, una perla sobre esto mismo: si quieres CONTROL debes separar al que dice qué se debe hacer del que lo hace. Eso es segregación de funciones (simple, pero contundente).

Tercero, el modelo SAME: simple, con sólo 6 procesos, manejable... tiene todos los ingredientes para ser algo realmente aplicable. Yo lo voy a seguir de cerca.

Para continuar, venía una presentación que prometía ser muy interesante de Jan Sonneveld sobre el modelo de benchmarking que se está proponiendo y potenciando desde el itSMF Netherlands, pero durante la parada del café me lié a hablar y a hablar y se me pasó la presentación.

Después de comer y de mucho charlar, vino la mesa redonda en la que participaron José Manuel Ballester, Francesc Muñoz, José Antonio Esteban, Victor Hervias y Miguel García. Aquí empezaron por dar cada uno una breve opinión sobre cuáles serían los puntos calientes del próximo año, y también salieron algunas ideas importantes:

Nuestro interés es convertirnos en un socio capaz de aportar a la compañía en Desarrollo Estratégico, que no en Planificación Estratégica. (Aquí se ve la voluntad firme de participar en la ejecución de la estrategia corporativa).

Nuestro interés (otro de los participantes) es conseguir definir cuál es el papel de las TIC en el negocio, ya que se nos ve como "un mal necesario".

El proceso de toma de decisiones se divide en tres grandes bloques: Quien y Cómo las toma (esto es Gobierno) y Qué decisión se toma (esto es Gestión)

En la agenda del CIO debe estar el conseguir que los temas de IT Governance estén en la agenda del CEO.

En esta mesa redonda hubo una parte importante del diálogo orientada a ver cuál es la verdadera situación  del CIO dentro del organigrama y a qué papel debe jugar en la organización.

A continuación estuve, por error, en la presentación de Wojciech Szczupak, de LastMinute.com . Digo por error porque la presentación llevaba por título Gestión de Problemas - Alguien voló sobre el nido del cuco ¿O no? y en realidad a esa hora tenía pensado asistir a la ponencia de Quint sobre estrategias de Sourcing que debía ser mucho más interesante; pero me había sentado en primera fila y no quise desanimar al ponente saliendo a medias de su explicación, asi que ahí me quedé viendo cómo era la gestion de incidencias y problemas en LastMinute.com

Al final de la tarde, cuando ya parecía que no podía quedar mucho de interés por contar/escuchar, vinieron dos presentaciones que se revelaron de lo más interesantes.

La primera, una presentación preliminar de los resultados de la encuesta Gestión de Servicios TI en España 2008, ya anunciada en este blog y promovida por el itSMF España, bITa Center e IDG. Los resultados (con una muestra pequeña y poco representativa) fueron más que interesantes, y como primicia las puedes descargar desde AQUI.

Atención:   Esta encuesta estará abierta todo el año, así que "cuantos más seamos más reiremos". Si no has participado, ya tardas!!

Y por último, la presentación que sin parecerlo, sin haberme llamado lo más mínimo la atención, resultó ser la mejor presentación de todo el evento: Conectando con el Negocio, de Juan Ignacio Rouyet. Este hombre pasó por encima de un tema importantísimo como es la apreciación del valor aportado por las TIC a la organización, no se hizo pesado, dijo unas cuantas cosas interesantes y, sobre todo, sembró la semilla del pensamiento en los asistentes: ahora hay que pensar en lo que, entre bromas, dijo.

Las TIC son un catalizador para generar valor, no un generador de valor en si mismo.

Es necesario habilitar mecanismos de "contabilidad" para los aspectos intangibles, como la Información o el Conocimiento.

En la entrega del premio al CIO más innovador del 2008 hubo una gran ausencia. El premio fue otorgado a Outi Nyström, la Directora de Sistemas de Información de CIRSA, pero el mal tiempo impidió que pudiera llegar a Madrid a tiempo de recoger el premio, así que me quedé sin saludar a esta gran profesional con la que tuve el gustazo de trabajar en una implantación de ServiceDesk hace años.

Como resumen, diría que me lo pasé bien, que aprendí algo, que disfruté charlando y comentando con varios conocidos y que en general la jornada estuvo bastante bien.

¿Estuviste? ¿Qué es lo que más te gustó?

¿Alineación con el Negocio, Integración con el Negocio o Simplemente Negocio?

El amigo Jorge, de Sistemas Decisionales, me tira el guante en el post anterior y me propone escribir un post a partir de un título y propone este título en concreto, basado en el extracto del libro IT Service Management, strategies that workcomentado en el post anterior.

Durante mis años de profesión, cada vez más me he dado cuenta de que el trabajo de consultoría (o quizás de asesoría como prefiero yo llamarlo) ha hecho de nosotros en realidad unos agregadores/transmisores de conocimiento: cuando te preguntan ¿cuántos años de experiencia tienes en esto? en realidad te están preguntando ¿en cuántos clientes / proyectos / sectores has trabajado?.

¿Por qué eres más valioso cuanta más experiencia? Porque en realidad en este trabajo la relación con cada uno de los clientes es simbiótica: ellos piensan que aprenden de ti, pero en realidad eres tú el que estás aprendiendo de ellos una barbaridad y luego acumulas y transmites ese conocimiento a cada nuevo cliente al que vas.

De todos estos clientes, hay dos que me vienen "al pelo" para este artículo. Uno de ellos, escéptico y crítico como el que más, decía

Y todo esto de ITIL, Cuadros de Mando, métricas y mejora continua, ¿por qué?. ¿Acaso los de RRHH nos dan un SLA sobre la contratación de nuevo personal, o un cuadro de mando con indicadores sobre sus procesos de provisión de personal? ¿Acaso los de contabilidad y finanzas nos dan una definición clara de los servicios que proporcionan al resto de la organización? ¡NO!

Lo que ocurre es que en esta profesión tenemos un complejo de inferioridad tan grande, que tenemos que estar demostrando continuamente lo que valemos y para qué servimos...

 

Otro de ellos, pragmático y práctico me decía en una primera visita, cuando tenía que tratar de entender a qué se dedicaba la empresa:

No, si nosotros somos como cualquier otra empresa, nada raro: como en todas partes, hay unos que venden, otros que hacen lo que se vende y otros que controlan y gestionan para que todo funcione bien. Esas son nuestras tres direcciones generales: Ventas, Operaciones y Finanzas.

En estos dos comentarios de estos dos clientes de los que tanto he aprendido, está la clave de la pregunta que planteaba Jorge: la idea de que haya un "negocio" y un "nosotros" o de que la cosa esté en cómo nos relacionamos "nosotros" con "ellos" es totalmente errónea además de perjudicial.

Cualquier empresa u organización, en realidad es un "nosotros" y por eso los chicos de RRHH no se plantean "la alineación del departamento de RRHH con el 'negocio'" ni los de contabilidad se plantean 'integrarse' en el negocio. ¿Pero qué tontería es esta? Cada una de las funciones, actividades, roles, puestos de trabajo de una organización sirve para algo, debe servir para algo, dentro del complejo engranaje de la empresa y si no, lo que ocurre es que estamos tirando el dinero y/o el tiempo. Así, tan integrado con el negocio está el chico del almacén, como la telefonista, como de Director General y el CIO: todos son el negocio, y si no lo son, es que sobran.

Ahora bien, hay que recordar que esto no son más que palabras: En realidad, cuando se habla de "alinear las TIC con el Negocio" lo que se quiere decir es que no se debe permitir que los objetivos que mueven al Departamento de Informática de una organización sean diferentes o no estén alineados o simplemente no tengan en cuenta los objetivos de toda la organización, y que cuando se habla de "Integración con el Negocio" lo que se persigue es dar a entender la necesidad de que las unidades de la organización, las que ejecutan los procesos de negocio y utilizan los Servicios TIC como herramienta para almacenar, procesar y publicar la información de la que dependen o se basan estos procesos de negocio se integren, participen y definan exactamente sus necesidades, a la vez que el área TIC vigile y piense en cómo mejorar e incrementar la funcionalidad o el uso que se le da a estos Servicios.

Esa es la gracia de todo esto: la visión holistica del tema

Libro: Service Management, strategies that work

Poco antes de Navidad, un amigo me comentó de pasada que se estaba leyendo un libro, que se lo había comprado pensando en encontrar material sobre Gestión de Servicios TIC y que le había sorprendido muchísimo encontrarse con una excelente documentación sobre IT Governance.

Coincidió por esas fechas que unos pocos de los lectores de este blog se decidieron a comprar algún que otro libro en la Biblioteca GobTIC, así que me cayó por Navidad un cheque-regalo de Amazon para gastar y pensé que estaría bien dedicarlo a este libro.

¡Qué grata sorpresa!

Aun no me lo he terminado de leer, pero tenía ganas de comentarlo con ustedes porque realmente da gusto leerlo. Sólo la introducción ya da una visión de IT Governance fresca y agradable de leer (qué lejos de ese estilo serio y gris de las publicaciones de ISACA, que parecen sacadas de una notaría), unas definiciones de conceptos como Servicio que he sentido realmente próximas y la diferenciación entre Servicios IT y Servicios profesionales que llevo aplicando desde los primeros proyectos realmente importantes allá por el año 99.

En realidad es un conjunto de whitepapers, de los cuales alguno como el de definición de un modelo de costes para los servicios TIC llevan tiempo circulando por la red (todos los autores son de Pink Elephant, así que allí podremos encontrar algunos de ellos).

El índice de contenidos es el siguiente:

• Introducción: ¿Alineación con el Negocio, o Integración con el Negocio?
• IT Governance al descubierto
• El proveedor externo de servicios gestionados
• Implementación de Procesos
• Definición, modelado y contabilidad de costes para servicios TI
• La CMDB Federada
• Desarrollando un marco de trabajo de medición basado en Calidad
• La Teoría de las Limitaciones y la mejora continua del servicio

Es una lectura que recomiendo fervientemente: al menos a mi, personalmente, ha conseguido algo que hacía tiempo que no me pasaba con literatura profesional: la Magia ha vuelto a recorrer mi cuerpo.

Título: Service Management Strategies That Work-guidance for Executives

Autores: Gary Case, Troy DuMoulin, George Spalding, Anil C. Dissanayake.

ISBN: 978-9087530488

Si quieres echarle un ojo, en GoogleBooks  puedes hacerlo e incluso leer (y disfrutar) del prefacio y la introducción.

¿Ya lo has hecho? ¿Qué Opinas?

8 claves para el éxito de un Cuadro de Mando en ITSM

Esta semana se ha realizado la jornada sobre Cuadros de Mando en el itSMF España. Ya que participé como ponente, he querido aprovechar la ocasión para redactar y desarrollar un poco los conceptos que expliqué durante mi charla.

La idea de la ponencia es simple: presentar 8 puntos de interés que se deben tener en cuenta para diseñar, implantar y utilizar un Cuadro de Mando orientado especialmente a la Gestión de Servicios TIC.

No creo que haga falta hacer una introducción previa a lo que es, para qué sirve y cuál es la importancia de un Cuadro de Mando, pero para aquellos que quieran un poco más de literatura al respecto, les recomiendo el blog de Jorge Fernández Sistemas Decisionales.

Lo primero que hay que explicar en todo esto es el porqué del título de la ponencia: "Sistemas Decisionales en la Gestión de Servicios TIC. 8 claves para el éxito".

¿Por qué "Sistemas Decisionales" y no "Cuadros de Mando"?

Bueno, el concepto de Sistema Decisional lo aprendí de Jorge. La idea es que el sistema que estamos montando cuando ponemos en marcha un Cuadro de Mando es una herramienta que debe servir a la dirección (de servicio, de IT, de la compañía...) para tomar decisiones. Asi que está íntimamente relacionado con los mecanismos mentales que se siguen a la hora de tomar una decisión: si yo le pregunto a mi hija "¿Qué quieres cenar?" tardará poco en responder y me dirá que quiere "un huevito claro", que es lo que quiere siempre.

No se lo ha pensado; pero si le pregunto "¿Qué quieres cenar, carne o pescado?" también tardará poco y me dirá que carne: sigue sin pensar demasiado. Ahora, si le pregunto si quiere "omelette du cranc" o "bife ruigné" (ambos platos invención de mi calenturienta imaginación) entonces... ¿qué creen que dirá?

La respuesta (esta noche cuando llegue a casa hago la prueba!) será "¿eso qué es?"

¡Ajá! Ahí está la clave: cuando tienes que tomar una decisión sobre la que no tienes suficiente información (tienes un indicador en rojo y nada más) puedes optar entre "tirarte a la piscina", utilizar la técnica CDO (los cinco dedos oscilantes) o bien buscar más información para poder articular una decisión con criterio, seria e informada.

De esta forma, un Cuadro de Mando presentado como un panel en el que se muestra la situación de veinte indicadores críticos no será suficiente para tomar adecuadamente las decisiones, por lo que el sistema de debemos montar para la ayuda a la decisión ha de permitir al decisor navegar a través de la información según sea necesario. Por eso hablamos de Sistema Decisional.

¿Por qué 8 claves y no LAS 8 claves?

Porque en realidad, lo que presento son 8 de las múltiples claves que se han de tener en cuenta, ordenadas "según me las dijo el espíritu" y escogidas esas 8 porque son las que más daño me han hecho durante mi vida profesional.

¿Qué tiene de especial un Sistema Decisional?

Depende de quién lo pregunte. Si lo pregunta una persona del área de BI, no tiene nada de especial, es un sistema basado en el esquema datawarehouse clásico aplicado al mundo TIC y en el que la única característica especial que debemos tener en cuenta es el hecho de que los sistemas operacionales (la fuente de información) pueden cambiar a gran velocidad.

Si lo pregunta alguien que no haya tenido contacto con el mundo del BI, lo que tiene de especial es que es un monstruo de 7 cabezas que hay que domar con mucho cariño. Normalmente cuando te piden un Cuadro de Mandos, están pensando en la capa más externa, en la que estamos únicamente representando los datos que hemos extraido y agregado. Para poder obtener esa foto tan bonita (el "bife ruigné") hemos tenido que trabajar en la cocina utilizando gran cantidad de materia prima que a veces no es demasiado bonita.

CLAVE #1: GENERAR LA INFORMACION

Tal y como explicábamos en el punto anterior, la representación tipo Cuadro de Mando es el resultado de un arduo trabajo de cocina y se requieren unos ingredientes y materia prima especialmente difícil de obtener. A veces, una métrica que queremos representar puede desembocar en un enorme proyecto de medición que deberá ser abordado antes de obtener la métrica final.

Muchas veces podemos, además, encontrarnos con que los datos originales nos permiten obtener la métrica que queremos para representarla en el CdM, pero no podemos obtener de una forma fácil las diferentes dimensiones en las que queremos realizar el análisis.

Por ejemplo, es posible que dispongamos de un valor para el Tiempo Medio de Transacción en los cajeros electrónicos de nuestro banco, pero... ¿podemos clasificar este tiempo medio por área geográfica, oficina o modelo del cajero?

CLAVE #2: DEFINIR LAS METRICAS

Evidentemente, un CdM es una representación de un conjunto de métricas obtenidas a partir del análisis de la información de la que disponemos en los Sistemas Operacionales (los del día a día). Definir adecuadamente qué métricas son las que debemos construir y representar es uno de los factores más importantes.

Identificar métricas que no sólo sean de rendimiento (KPI) sino que además tengamos en cuenta métricas destinadas a evaluar el cumplimiento de objetivos (KGI) e incluso del grado de aporte de los procesos o servicios TIC al cumplimiento de los objetivos estratégicos de la compañia (consultar el post al respecto de la madurez como prerrequisito para el gobierno).

CLAVE #3: USAR LA ESTADISTICA

COn mucha frecuencia se ven CdM que presentan datos en los que se ha aplicado un gran poder de agregación, para pasar desde millones de registros unitarios en el mundo operacional a un único valor, pero este valor no está analizado en profundidad con toda la potencia que nos da la cienca Estadística.

Aplicar transformaciones estadísticas, análisis de frecuencias, estimaciones y grados de confianza nos va a permitir sacarle muchísimo más jugo a la gran cantidad de datos con los que podemos trabajar.

Aquí encuentro que es de gran ayuda combinar estándares (como siempre en este blog!) y aprovechar la fuente de conocimiento y experiencia que nos puede brindar el mundo 6sigma nos va a permitir aproximarnos de una forma muy interesante al análisis y mejora de procesos y servicios.

CLAVE #4: GARANTIZAR LA CALIDAD DEL DATO

Siguiendo con el ejemplo de la cena, si le contesto a mi hija que una "bife ruigné" es un ojo de vaca estofado con hormigas al pil-pil, estoy seguro de que va a esgoger la "omelette du cranc" para cenar, aún sin saber qué es.

Recordemos que estamos construyendo una herramienta de ayuda a la toma de decisiones: si la información que presentamos no es de buena calidad, lo más probable es que las decisiones que se tomen sean, también, de mala calidad.

Es por esto que hay que prestar especial interés a cómo de bien se registran y procesan los datos en origen; en el mundo del BI se tiene este factor muy en cuenta y nosotros debemos aprender de ellos.

No olvidemos que los datos registrados manualmente son especialmente sensibles a errores o inconsistencias (el simple hecho de clasificar una llamada de servicio puede provocar indicadores de todo tipo). Para asegurarnos de que los origenes de datos son relativamente buenos (otra vez las estadísticas y los márgenes de confianza) es especialmente importante reforzar la función de auditoría, como se encargó de demostrar claramente mi compañero de ponencias.

CLAVE #5 DRILL-DOWN, DRILL-UP, DRILL-THROUGH

Es un sistema decisional, ¿no? Necesitamos navegar por los datos. Esta necesidad fue la que provocó inicialmente el nacimiento de los conceptos OLAP: la posibilidad de analizar la información de una forma dinámica (y no de forma estática en base a informes predefinidos).

Por otra parte, comentábamos al principio de todo que el Sistema Decisional está ligado al mecanismo intelectual de tomar decisiones:

¿cómo piensas tú?

Seguro que de una forma diferente que yo. Eso significa que no podemos, a priori, saber qué información va a necesitar el usuario de nuestro CdM para tomar las decisiones y por eso debemos estar preparados para proporcionarle la que necesite. De ahí nace el concepto de los famosos cubos OLAP.

CLAVE #6: METRICAS DE PROCESO O METRICAS DE SERVICIO

En función de quién sea el destinatario de nuestro CdM o cuál sea el objetivo decisional que perseguimos, necesitaremos conjuntos diferentes de métricas. Ya se ha escrito en este blog (aquí y aquí)bastante al respecto de la diferencia existente entre medir procesos (actividad de las personas) y medir servicios (actividad de las máquinas), pero además de estas diferencias debemos tener en cuenta que, como norma general, las métricas de proceso interesan internamente al departamento de TI, mientras que las métricas de servicio interesan especialmente al cliente.

CLAVE #7: GESTION DE CAMBIOS

Ah! El punto clave! Si no tenemos una gestión de cambios buena que nos asegure que se tienen en cuenta los aspectos de incorporación y agregación de datos en el sistema cuando se realizan cambios en los operacionales, la calidad del dato se verá afectada de lleno: no dispondremos de la información o bien dispondremos de una información incorrecta.

Por ejemplo, puede ser que estemos midiendo procesos y que alguna parte del proceso cambie: la herramienta seguirá siendo la misma, los datos incorporados y agregados también, pero el significado de los datos será diferente!!

CLAVE #8: ACTUAR Y COLABORAR

¿Se acuerdan del objetivo final de todo esto? Tomar Decisiones! Si tenemos un CdM que se utiliza para celebrar lo bonito que es, estaremos desperdiciando tiempo y dinero valiosísimos para todos.

La fase más importante del ciclo de Gobierno de las TIC propuesto por COBIT es "proporcionar direccion", por eso el CdM es una herramienta importante de gobierno y lo que se espera del Sistema Decisional es, precisamente, que se use para tomar decisiones, para proporcionar dirección, para actuar.

CLAVE #9: CONSTRUYE PROGRESIVAMENTE

Un lector anónimo dejó un comentario añadiendo una novena clave. Dicho y hecho, aquí está: construye de lo simple (una buena base) a lo complejo (unos acabados excelentes). Siguiendo con tus ejemplos culinarios, empieza por elegir la mejor materia prima y no te dejes impresionar por el tamaño de la cocina, ves a lo simple y cuando lo hayas conseguido sigue con lo complejo. La carta del menú se ampliará sola, cuando ocurra, recuerda explicar brevemente que son esos platos raros que ocasionalmente pedimos.

----------------

Por último, recordar (una vez más) que todo esto no es una ciencia exacta: estas no son las únicas 8 claves ni siquiera son las más importantes y todo esto no ha sido más que producto de un vuelo retrasado y una larga espera en el aeropuerto (para variar).

¡Piensa y así existiras!

Sistemas Decisionales para ITSM: 8 claves para el éxito

El próximo Martes, 5 de Junio a eso de las 17:00, estaré dando una pequeña charla sobre 8 de las claves más importantes (desde mi humilde punto de vista) que debemos tener en cuenta a la hora de pensar, diseñar y poner en marcha un Cuadro de Mando para la Gestión de Servicios TI.

Esta charla forma parte de una mesa de debate del itSMF España, la primera organizada desde el capítulo de Catalunya, en la que habrá dos ponencias y posteriormente una rueda de preguntas, respuestas y opiniones al respecto.

Gracias a la cesión de las instalaciones por Telefónica, el acto será retransmitido en directo y por videoconferencia a Madrid, Valladolid, Granada y Sevilla así que si estás en alguna de estas ciudades y te apetece venirte, será un placer.

Para más información sobre el evento, localizaciones y horario (y nada de precio, que esto es gratis, "por la patilla") puedes consultar la convocatoria en la página del itSMF España.

¡Nos Vemos!

HP y la compra de Mercury

Bien saben las personas que leen este blog a menudo que no suelo entrar a hablar de productos ni de fabricantes, pero esta vez quiero explicar un poco mis percepciones sobre la ampliación en el portafolio de productos que ha hecho HP tras la compra de Mercury y su incorporación ya definitiva al menos en España.

Esta semana he tenido la oportunidad de asistir al HP Business Perspectives de este año; han sido tres días intensos de presentaciones, contactos, intercambio de cromos y alguna que otra copa. Durante estas sesiones he oido hablar de muchos productos, bundles y suites diferentes, pero los que realmente me han llamado la atención por la coherencia y alineación con mi actividad profesional de su discurso han sido los chicos de Mercury (bueno, los chicos de Mercury que ahora firman como HP, ¡claro!).

Estuve en una primera presentación en la que daban una visión "a vista de pájaro" de la solución de Project and Portfolio Management, donde se hizo una primera charla sobre IT Governance, pero al venir de un fabricante de software había cosas realmente curiosas más que nada por el hecho de "materializar" o "convertir en algo práctico" los conceptos teóricos (o académicos, como los llamaba el ponente) de Gobierno de las TIC.

Durante toda la charla y si lo unimos con la charla sobre los productos de testeo de software y pruebas de carga, se oyeron conceptos de COBIT, de CMMI, de Six Sigma y de ITIL, pero sin nombrar ninguno de los estándares y desde un punto de vista eminentemente práctico... me encantó, porque visto de esa manera no asustan a la audiencia con las toneladas de siglas que estamos acostumbrados a usar en este sector.

Después de esta introducción, planteaban un modelo tanto para la definición de las espectativas como para la presentación de resultados muy alineado con el modelo 3x3 presentado por Jan Van Bonn en las charlas que dió en el itSMF y que centraba el interés en juntar el concepto de "Alineación de las TIC con el Negocio" con la definición de objetivos estratégicos de la compañía y de las TIC (al más puro estilo COBIT) y con la ejecución o materialización de estos objetivos a través de un ciclo de Gestión de la Demanda y del ciclo de vida del Servicio con aroma a ITIL V.3

Luego hubo una poca de presentación de los productos y posicionamiento de los mismos en los cuadrantes del modelo anterior y creo que nos dejaron a todos con la ilusión y las ganas de ver mejor estos nuevos productos y comenzar a pensar en cómo se pueden aplicar para alegrarles la vida a nuestros clientes. Sinceramente, mientras los iba viendo iba pensando "ah! cómo le gustaría esto a XXX" o "eps! Esto es justo lo que necesita YYY".

Definitivamente, me parece que la compra de Mercury, si la consiguen integrar adecuadamente y conseguir un canal formado, serio y capaz de trasmitir el mensaje y no vender únicamente licencias sin trasfondo de conocimiento, ha sido la mejor decisión que ha tomado HP Software en los últimos años.

PS: Una de las cosas que me llamaron mucho la atención fue que cuando el ponente puso la slide con las definiciones "académicas" de IT Governance, las fuentes citadas fueron Gartner y Forrester, no ISACA ni ITGI.

¿Casualidad, o Marketing?