ITIL - Un mar de métricas y alegrías

En CSI hice unos primeros dubitativos pasos por unos problemas de agenda, pero voy avanzando igual.

Me llamó la atención especialmente el punto 8.5.1 de las Baselines, donde la norma nos recomienda tener indicadores a pesar de que los mismos no sean confiables. Copio el párrafo porque está en la raíz de muchas discusiones tecnológicas que tuve con la MAYORÍA de mis colaboradores a cargo.

If a baseline is not initially established the first measurement efforts will become the baseline. That is why it is essential to collect data at the outset, even if the integrity of the data is in question. It is better to have data to question than to have no data at all. 

¿Vieron? ¡Yo sabía! No hablemos de medición sin haber medido, démosle forma de indicador a la realidad. Avanzar sobre lo poco que sabemos y construir sobre eso un proceso de mejora. Mejora de medición, mejora de resultados, mejora de calidad, mejora de percepción del cliente.

También vean el 8.5.2 que nos llama a revisar y repensar siempre lo que sabemos. Vean las tres preguntas clave.

1. ‘Why are we monitoring and measuring?’
2. ‘When do we stop?’
3. ‘Is anyone using the data?’ 

Después de eso Itil sigue escarbando en la herida, llamándonos a construir un proceso donde las métricas tienen una evolución y un sentido. De este punto de las métricas (el 8.6, bien detallado en etapas), me guardo aquello de ponderar métricas duras junto con la percepción del usuario.

De mi experiencia puedo recordar como la falta de sinergia entre el Service Desk, Operations y Technology hacía al área toda -y a la comunicación al usuario en especial- un verdadero dolor de cabeza. A lo mejor una buena práctica, para compañías muy complejas o con estos problemas, sería hacer que indicadores estén disponibles para que el usuario los consulte y tenga la opción de marcar un servicio o realizar alguna acción de “Esto no me funciona bien como lo dice el indicador”. Herramientas como Slack o un twitter interno con un bot de estados pueden ser viables también. Si me apuran armaría algún bot en Telegram que publica estados y recibe likes o dislikes de los usuarios.

Me gustó la ironía en el tema de análisis de indicadores:

It is interesting to note the number of job titles for IT professionals that contain the word ‘analyst’ and even more surprising to discover that few of them actually analyse anything.

El capítulo Cierra con los roles, la presentación de la información y un párrafo especial para alertar acerca de las interpretarciones demasiado rápidas de indicadores y tendencia.

Y de ahí pasamos a Complementary Guidance y luego a The ITIL Service Management Model, el último capítulo del libro. Estamos terminando. Los ilustro con la tabla de ejemplos de métricas, porque estoy seguro que me va a servir en el futuro.

Cabe aclarar, a tono de mi entrada anterior, que estoy leyendo recién la introducción a la norma. Me faltan todavía 5 libros más por leer, y es probable que la falta de detalle que veo en algunos puntos sea desplegada en alguno de esos libros sucedáneos.

ITIL - Service Desk con sabor a poco

¿Pensaron que el suplicio de ITIL - Entrando en Service Operation y lo que te g... había terminado? Tsk Tsk, sigo leyendo y voy a terminar este libro. Es muy interesante

Ahora me interné en el CSI y la mejora continua, también repasé el capítulo de Service Desk que tiene sabor a poco. Yo de Service Desk escribiría un libro de 400 páginas acerca de la importancia, el alcance, la responsabilidad, los roles, lecciones aprendidas, eficiencia. ¡Hay para hacer dulce!, además me acompaña una experiencia muy buena que tuve en mi empresa actual, donde lamentablemente veo languidecer el trabajo que dejé hace dos años (La Gerencia actual no cree en la atención del usuario).

Después están las unidades funcionales de infraestructura y operaciones, dos sobre las cuales tengo mucho para decir y que en general suelen ser un desafío para alocar recursos. Son zona de conflicto, donde mantener motivado un especialista es una obra de arte de día a día. En general las tareas de Operation Management van a sumarse a las de Technical Management dentro del rol y las funciones de muchos de tus especialistas, es dificil tener capacidad operativa para trabajarlas por separado, cosas del tercer mundo.

Me acerco lentamente al capítulo 8, totalmente dedicado al CSI, ¿Es CSI el enemigo de la innovación? ¿Es ITIL el enemigo de la innovación? Una organización volcada a la mejora continua suele tener dificultades para innovar.

PS: Armé un Service Desk excelente (70% de resolución en el nivel 0), lideré IT Operations y trabajé muy de cerca con Technical Management.

Cuatro postulados del Papa Francisco aplicados a la gestión de TI

Cuando hablé bien de Denzinger Bergoglio era con el afán de que en su camino, los autores descubrieran el centro del pensamiento del actual pontífice, y que los lectores –durante ese camino- aprendiéramos a entenderlo. Meses después sólo tengo en la mano algunos artículos indignados, que tratan de interpretar el pensamiento del Papa a fuerza de citas incendiarias.


No leo más ese blog, si bien tengo en mi lista revisar algunas de las cuestiones que compilaron como base de su estudio.Por otro lado tenemos un Papa que tiene un sentido práctico político muy argentino, y la intención de revolucionar la Iglesia para orientarnos a la Misericordia.

Fue en ese sentido que me interesó el título del artículo Los cuatro clavos de los cuales Bergoglio cuelga su pensamiento, tanto para entender el personaje como para llenar el hueco dejado por el Denzinger Bergoglio.


Recuerden los cuatro postulados

1. El tiempo es superior al espacio
2. La unidad prevalece sobre el conflicto
3. La realidad es más importante que la idea
4. El todo es superior a la parte

Yo empecé a leer el artículo justo en medio de mi investigación de ITIL y en particular me encontré cogitando en el tercer principio y su impacto en….¡los modelos de calidad y la gestión de sistemas!.Aunque usted no lo crea, me parece que estos postulados pueden aplicarse a la dirección de áreas de sistemas.

¿Por qué intentar aplicar los postulados del Papa a la gestión de Sistemas? Porque tengo un blog y porque me gusta, son libres de leer o no.


Vamos lá¡

Voy separando por postulado, recomiendo en cada caso leer el resumen que hace Giovanni Scalese, si bien él mismo reconoce que hay que ampliar el estudio.

El tiempo es superior al espacio:

Viendo este postulado en particular, el Papa no podría ser un buen gerente de Sistemas. La gestión de TI es justamente un tema de espacios, el tiempo es limitado y los procesos de cambio muy cortos, de modo que los gerentes de sistemas ven sus logros concretarse en períodos de 4 a 6 años. Frente a esta evidencia lo importante de la gestión de Sistemas está justamente en lograr que sea parte de las decisiones de negocio, transformando el grado de madurez de las necesidades, llevándolas de “hablo con un área de servicios…” a una relación de intercambio mutuo.

A todo esto se suma el hecho de que los procesos que van a durar en el tiempo son parte del comodity de TI, pero la vida del gerente viene de su capacidad de gestionar los proyectos; y los proyectos son una realidad de espacio. El gerente va a trabajar esos años de proyecto y renovación tecnológica, para llegar al final de su período y haber logrado el espacio para que su remplazo no sea traumático y pueda continuar ligado (¿Cómo consultor?¿Cómo director?¿En funciones de controller?).


La unidad prevalece sobre el conflicto

En este caso la coincidencia es total y donde hay conflicto…"…, algunos simplemente lo miran y siguen adelante como si nada pasara, se lavan las manos para poder continuar con su vida. Otros entran de tal manera en el conflicto que quedan prisioneros, pierden horizontes, proyectan en las instituciones las propias confusiones e insatisfacciones y así la unidad se vuelve imposible. Pero hay una tercera manera, la más adecuada, de situarse ante el conflicto. Es aceptar sufrir el conflicto, resolverlo y transformarlo en el eslabón de un nuevo proceso" (n. 227).”

Salvando al tema de la unidad, que no es un principio tan importante en TI y hay que definir mejor, la visión del conflicto es la que hay que tener. Suena un consejo muy difícil de encarar, sobre todo cuando el conflicto no es técnico, no entiendo tampoco como lo hace trabajar el Papa en su gobierno de la Iglesia.


La realidad es más importante que la idea

100% De acuerdo en el enunciado (si bien no tengo elementos ni capacidad, para juzgar la elucubración en torno a idea y realidad que hace Scalese) y especialmente clave para aquellos que disfrutan los procesos operacionales, desafíos técnicos, o procesos de mejora continua. Normas como la ISO o ITIL pueden ser mortales para un gerente miope o sin contacto con la realidad. Enfocar en tener informaciones de estado del usuario por medio de la Mesa de Ayuda o romper el molde de las ideas propias con un área de Procesos muy conectada con el usuario puede transformarse en la clave del éxito, en particular cuando el Portfolio de Proyectos es muy exigente.

El todo es superior a la parte

“El todo es más que la parte, y también es más que la mera suma de ellas. Entonces, no hay que obsesionarse demasiado por cuestiones limitadas y particulares. Siempre hay que ampliar la mirada para reconocer un bien mayor que nos beneficiará a todos.”

Llegados a este cuarto postulado hay que hacer una distinción importante: una cosa es el mensaje y la otra la realidad técnica. En el diagnóstico y plan de ataque de los procesos y problemas técnicos, también el las capacidades de innovación del área, lo que prima son las partes y la capacidad de aislar. Muchas veces la respuesta suele venir de una disociación del problema, de una visión atómica como la de SOA. Pero cuando se trata de comunicar (que es donde el Papa tiene experiencia), entonces ahí este postulado es rey, y es donde muchas veces los gerentes de sistemas fallamos miserablemente.


Bueno, ahí tienen, los postulados del Papa Francisco asociados a la gestión de Sistemas. ¡Qué idea loca!

ITIL - Entrando en Service Operation y lo que te gustaría ver en el ambiente de Service Desk

Metidos de lleno en lo de Change Management con la diferencia de conceptos entre Event, incident, Problem y Service Request.

Ojo. Todos entendemos que son categorías reales y necesarias, que en algunos casos como en los sistemas viejos donde la incidencia de los problemas puede ser muy alta, se requiere aislarlos y proporcionarles una atención especial. También imagino que en compañías de más de 5000 empleados se transforma en necesidad.

Pero en general, con un buen sistema de gestión de incidentes y un Service Desk de carne y hueso, se puede dar vida a un proceso eficaz y satisfactorio para el usuario.

Lo que si es claro es que estas estructuras tradicionales de Service Desk no suelen alcanzar al Problem (que suele estar bajo el ala de Desarrollo) y no suelen catalogar los eventos e incidentes en la esfera de un control de gestión de un servicio.

Imagino que volcar las relaciones Servicio/Incidente con una categorización común, debe ser una recompensa instantánea y un empujón hacia una visión sistémica de los servicios como componente atómico de las soluciones que el usuario espera. Tu mesa de ayuda no tiene que hacer más reportes de cantidades de llamadas, directamente debe hablar de atención de incidentes, visibles al nivel de cada uno de los servicios.

Para entenderlo… me siento a revisar un servicio y una de las patas del informe es la lista de todos los event, incident, problema y service request relacionados.

Y de nuevo aparece el tema de seguridad con una visión especial para Access Management, que yo simplifiqué como un Service Request más. La pelea por la autonomía de Seguridad Informática sigue dando sangre.

Me interesó lo de Open-Loop y Closed-Loop en Single monitor control loop, como algo importante para arrancar el Service Operation. Puedo asegurar que nadie ahí afuera categoriza y monitorea de esa manera.

ITIL - Ls 7+1 erres del Change Management y otras yerbas.

Muy buena la lectura de The Official Introduction to de ITIL Service Lifecycle, el Change management aparece relacionado con todos los problemas entendidos de modo general en el Service Design. Me intriga mucho entender cómo funcionaría mi empresa bajo el dominio de ITIL y frente a la ausencia de mejora tecnológica en años. El desafío es entender un gap de proyectos de mejora tecnológica que requiere un portfolio de proyectos ad-hoc.

Ayuda mucho el tema de las 7 erres:

• Who RAISED the change?
• What is the REASON for the change?
• What is the RETURN required from the change?
• What are the RISKS involved in the change?
• What resources are REQUIRED to deliver the change?
• Who is RESPONSIBLE for the build, test and implementation of the change?
• What is the RELATIONSHIP between this change and other changes?

Y le agregaría una R adicional relacionada con el tiempo que el servicio viene trabajando sin cambios:

• How much the service has been ROLLING without changes?

Ahora estoy entendiendo el Change Advisory Board, aunque el breve resumen que trae la Introduction no permite delimitar la cantidad de personas involucradas, la lista de funciones que trae hace imposible que sea un grupo de trabajo eficiente. ¿Se imaginan a toda esta gente trabajando al unísono?

• Customer(s)
• User manager(s)
• User group representative(s)
• Applications developers/maintainers
• Specialists/technical consultants
• Services and operations staff, e.g. Service Desk, test management, ITSCM, security, capacity
• Facilities/office services staff (where changes may affect moves/accommodation and vice versa)
• Contractor’s or third parties’ representatives, e.g. in outsourcing situations

¡Explota todo por el aire! Vamos a ver si el libro ad-hoc de ITIL3 Service Transition trae luz al CAB.

Ilustremos con algo que nos hace pensar. Vaya el SACM que es a la vez algo sencillo, de sentido común y que requiere trabajo, como todo en ITIL.

ITIL - Llegando a Service Transition

Avanzo tozudamente en ITIL. A medida que el proceso de conocer la norma avanza nos encontramos con múltiples herramientas de disponibilidad, catálogo, capacidad, análisis de fallos, etc.

Son todas funciones que entiendo que se pueden implementar por separado, pero que ITIL entiende como si fuera el anillo de Sauron, las suma a todas y acompaña la lucha de todo gerente de IT: la pelea entre una gestión ordenada y el desafío de perder agilidad en el camino.

Viendo esto muchos pensarán que ITIL es penoso. Nada de eso, ITIL es poner en blanco y negro lo que cualquier área de TI orientada a mejora continua haría para garantizar la satisfacción de aquellos que le pagan el sueldo (y un suculento bono anual).

Lo que no entiendo bien de ITIL es ese foco en montar una entrada especial para Information Security Management cuando debería ser parte incluida de molde en el Service Design, analizando para cada servicio los riesgos y planes de mitigación. No sé si esté asunto no es parte de adecuar la norma a empresas donde el ISM forma parte de TI como área ad-hoc.

Dejando de lado esto, sigo leyendo el The Oficial Introductiont the ITIL Service Lifecycle, me sumerjo en el capítulo de Service Transition donde vamos a llegar al lugar más recóndito de todos los problemas de Ti: el Change Management.

¡Change Management, boooooo!.

Ya les contaré más, pero les dejo el esquema gráfico de Service Transition, que no puede ser más claro.

ITIL Primeros pasos

Me sumergí profundamente en los mares de ITIL, porque soy así de valiente y porque tengo energía para entenderlo. En principio la primera reflexión que surge es que se trata de otro sistema de mapeo de procesos de sistemas, que requiere ingente documentación y que se transforma en tarea titánica para cualquier gestión de TI.

El problema es que eso lo puede decir alguien que piensa eso de todos los modelos de calidad, sin embargo para mí son un bálsamo y tuve muchos proyectos aplicándolos. Pude en el pasado trabajarlos sin problema y con relativo éxito.

Recuerdo aquella matriz de riesgo que hice para la eficiencia del control de pérdida de información (hasta hice una presentación del modelo a un grupo de colegas), las otras matrices de riesgo que hice luego de esa, todo el proceso de certificación ISO 9000 y también lo mucho que me ayudó COBIT a entender el control de TI. Procesos lentos, que requieren centrarse en una evaluación de especialista y que te cuentan al final lo que sabías desde el principio, pero que te permiten ordenar la gestión y la mejora continua a través del tiempo (hay que mantenerlas).

Lo otro que les puedo asegurar es que nadie en el negocio te va a valorar el esfuerzo de llevar tu TI a ITIL, vas a tener que dedicar horas extra de tu equipo para configurar tu estrategia de servicios y para lograr que el arduo final de la cadena -el momento de la mejora continua- sea visible para todos. El problema no es la existencia de servicios; el problema es que en las áreas de TI monopólicas de las empresas, esos servicios (especialmente el de change management) no son eficientes, o no dan valor agregado.

ITIL como marco tiene una división que tiene mucho sentido común, vean el gráfico de más abajo, no me digan que no es descriptivo. Si leen el primer libro de ITIL The Oficiall introduction to the ITIL Service Lifecycle van a ver que no miento.


Ese acercamiento de sentido común se basa en una debilidad que tienen todas las áreas de TI: mucha aplicación ad-hoc y poca visión orientada al proceso. ITIL puede ser una buena herramienta para traer orden al caos y definir claramente los roles, en especial los del cliente.

Yo por mi parte sigo explorando y les contaré como viene la mano.

Nota: tomo el gráfico de examenvragen.info, lo quito si no quieren verlo en este blog.