ITIL SS - Ponderando las variables de estrategia, táctica y operaciones

Estamos en el capítulo 8 de esta extensa serie de la lectura de ITIL - Service Strategy, lectura que en el caso de Service Strategy tiene un fuerte olor a ya visto, porque repite temas, conceptos e ideas anteriores trayendo mayores especificidad.

En este frente de Tecnología y Estrategia, revisamos el alcance que tiene que tener la automatización y el data análisis en aquellos servicios que realmente pueden ser sujetos a este nivel de control. No hay que hacerlo en todos los casos.

Hablamos fuerte de cuando no automatizar y del impacto de las interfaces en este esfuerza. Y también de los problemas que traen las distintas trampas en las cuales es común caer, les traigo el párrafo que bien vale el esfuerzo.

• The Capability Trap – By pressuring staff to work harder, an organization unwittingly triggers a scenario where everincreasing levels of effort are required to maintain the same level of performance.

• The Tool Trap – Although technology tools offer very useful help to an organization, they often require the development of knowledge and experience. When an organization adopts new tools, it triggers lower productivity in the short term. The increase in workload from training, learning and practice activities may unwittingly push a resource-constrained organization over its tipping point.

• The Firefighter Trap – When an organization rewards managers for excellence in firefighting, they may unwittingly create a dynamic harming the long-term performance of the organization. The long-term performance is instead improved by not rewarding excellence in firefighting.40

¡Si no las habremos visto!

Luego saltamos al capítulo 9 que habla de los Challenges y donde los autores se esforzaron en marcar todos los puntos referidos a la problemática del servicio, yo te recomiendo leerlo para entender todo el contexto, es un capítulo resumen que trata los temas claves del SS.

Identifiqué un par de cosas importantes; por ejemplo eso de que "Efficiency goes to waste when output or income is not fit for pourpose or fit for use" que parece una estupidez de obvio, pero que requiere un esfuerzo importante para areas de TI enfocadas en su ombligo.

También me llamó la atención el juego abierto a los servicios cloud y la AI que queda antes de leer Effectiveness and Measurement, es como que habría que reescribir el libro de cara a estos frentes tecnológicos nuevos. Nuevos para ITIL, a pesar de que la norma es lo suficientemente flexible para incluirlos como variable de escala o mejora.

Finalmente cerramos el capítulo 9 con el análisis de riesgo, encarado con inteligencia, pero menos efectivo y extenso que el informe COSO. Vean este simpático gráfico para imaginar los puntos que abarca.

Lo curioso es que después del capítulo 9 vienen dos apéndices, yo -como estoy haciendo una lectura de análisis- voy a recorrer a vuelo de pájaro los anexos para ver de que tratan, pero solo voy a lastimarlos de nuevo con ITIL cuando encare la lectura de Service Design, que creo que es el más extenso de los libros.

ITIL SS - Táctica primero y luego tecnología

Poco para rescatar del capítulo 7, seguimos intentando definir los límites de una estrategia de servicios, en especial el precio como limitación del diseño y luego en los frentes de transición, operación y mejora.

Ocurre que tuve un mes muy ocupado y no pude darle continuidad a la lectura, ahora retomo y rápidamente me encuentro con algo que nunca hubiese esperado hallar en este libro: "that SLA metrics are necesary but not sufficient to measure the quality of service delivered ti customers" y que entra en sintonía total con algo que compartí hace unos días en Linkedin : Las 9 mentiras que los CIO se hacen así mismos antes y después de la transformación digital

ITIL distribuye el análisis en factores de Garantía, Confianza, Mantenibilidad, Redundancia y Tiempo entre fallas.

Mensaje especial para los de Seguridad Informática, con aquello de que muchos de los valores que pregonan el usuario solo los entiende como disponibilidad. Availability.

Y bueno el gráfico de Redundancy, a ver si lo entienden.

Todo esto para explicar luego que al usuario poco le importa los MTBF y el MTRS y que lo bueno es el valor de "surface area" para mejorar su perspectiva, diversidad de canales, densidad de la red y loose coupling (facilidad de acceso) como soluciones para el usuario y su percepción.

Luego saltamos a Tecnología y Estrategia, un capítulo corto que les comentaré en otra entrada.

Saludos ITILicos

ITIL SS - Definamos la estrategia

Contrariamente a lo que esperábamos en el capítulo anterior, en capítulo 6 sufrimos lentamente otra categorización. No se cumplen las promesas de congeniar Lines of Service con Chargeback de servicios. ¡Amalaya!

El capítulo discurre rápidamente y pasa al olvido, salvo por aquel tema de como los servicios críticos de los proveedores no son necesariamente los distintivos, y no mucho más. También tiene su punto en la tabla 6.2, muy interesante; en particular para mi que estuve en tres de los 6 tipos de estructura de Sourcing que detalla.

Ojo al elegir una sourcing structure, soy de la idea de que hay que tener muy clara la madurez de los procesos internos del negocio y eso de los bussines and behavioural skills.

Sigo mientras tanto con el capítulo 7 que nos orienta a la Estrategia, Táctica y Operación de servicios.

ITIL SS - El catálogo de servicios

Primero vean esto...

...es el resumen de lo que vengo armando hasta ahora para tener el día de mañana mi layout de servicios. Considero que ahí está mi ayuda memoria, mi resumen para juntar todas las dimensiones y aquellos puntos que mostraría en una presentación a un usuario.

Muy oportuno, porque justo ahora me estoy metiendo en el capítulo de SPM (Service Portfolio Management). Vean sino el maravilloso Option Space, para orientar las decisiones en torno al Portfolio de Servicios.

Tomo esto alineado con la Demand Management que yo tengo entre ojo y ojo porque es el lugar donde más estupideces vi acontecer. Desde áreas orientadas por silos hasta cilclos de aplicaciones donde nadie es dueño de procesos, área de Proyectos metiendo la nariz, etc.

ITIL lo encara desde los PBA (Patterns of bussines activity) y los User Profiles, y a mi me eleva un grado el escepticismo, sobre todo cuando pienso que en general la demanda está ahí y está siempre como una carga pesada y urgente a procesar.

En fin, muchos pruritos para un tema que entiendo que ITIL logra resolver después de 4 años de maduración. Nadie tiene ese tiempo, creo que quedó claro en entradas anteriores.

Aunque más inmediato puede ser el otro concepto de Service Packages donde yo le pediría a un experto ayuda para implementar, pensar los Line of Services y como encajan con el Outcome. ¿Podemos hablar de realidades donde el cliente ve lo que quiere ver y a la vez se compromete con la separación de servicios y lo que cada uno de ellos entrega?

Bueno, lo veremos en el siguiente capítulo, Strategy and Organization.

Hope so.

ITIL SS - Facturar internamente tus servicios

Y ahora, cerrando el capítulo 5 de ITIL Service Strategy, nos metemos de lleno en el sueño que nunca pude hacer realidad. El sueño del Gerente de Sistemas de lograr facturar internamente sus servicios, para hacer entendible su presupuesto y lograr apartar esfuerzos para control de gestión, evolución de la arquitectura, calidad e innovación.

Lo que me faltó en su momento fue una estructura madura que entendiera como llegar a armar un catálogo de servicios con sus variables económicas. Ahora voy leyendo los factores claves y como el área contable te puede acompañar. Ojo, siempre orientado a servicios desde los más granulares hasta los más compuestos.

En el fondo, lo que pide ITIL, es que hagas previsión y presupuesto como en un proceso tradicional de Contabilidad, pero con una visión orientada a servicios. Si hay un buen Catálogo, solo es cuestión de avanzar durante un par de presupuestos y aplicarle mejora continua y paciencia.

Mención aparte merece el VCD (Variable Cost dynamics) donde vemos como el crecimiento de cada servicio debe calcular el crecimiento de costo de cada Unit Cost. Lástima que lo detallado en el libro es solo un esbozo de lineamientos. Armate tu propia metodología.

La excitación viene en los párrafos de 5.1.3 y e particular en el gráfico 5.3. Los desafío a mostrarme algo así en alguna compañía de Argentina.

 

Noten que luego da unos lineamientos muy buenos de como lograrlo y encara tímidamente el ROI. A mi el ROI me da para preguntar ¿Cómo calcular ROI cuando hay un 40% de inflación y el gerente de Sistemas no dura 4 años en su puesto?.

Este capítulo de Service Economics se anuncia largo y sustancioso.

 

ITIL SS - Tag en los servicios y mejora continua

Lo que se imaginaban en el post anterior acerca de la posibilidad de armar un catálogo, en los párrafos siguientes se ve reforzado por la necesidad de incorporar a esa visión una red de relaciones entre servicios, red que tiene que estar activa a la hora de la mejora y que además requiere etiquetar los servicios. Esto es para saber que si mejoro un servicio o lo paso a cuarteles de invierno, entonces cuales van a ser las víctimas realcionadas.

Ni que hablar, si a su vez quiero mostrar el potencial de mi servicio, ahí tenemos otra dimensión de la relación entre servicios. "Potencial", ITIL lo entiende no solo como la capacidad de crecer y suplir nuevas demandas, sino que pone foco en la capacidad de ofrecer algo nuevo y diferenciado, o la posibilidad de que solo estemos proveyendo la oportunidad de nuestro cliente para no cargarse con riesgos y costos. Ojo con esto.

Una cosa importante es lograr a través de todas estas evaluaciones de los servicios y sus relaciones, que la mejora en el desempeño del servicio derive en mejora del resultado para el cliente. Entender que no siempre nuestros delirios tecnológicos, tienen impacto en las capacidades del área de TI de responder a las necesidades del cliente/usuario.

Y de ahí baja a los servicios per se y la definición de la estrategia, primero dando lineamientos de la definición de objetivo, luego hablando de Outcomes y cerrando el capítulo 4 con una visión amplia de lo que son los Market Space y como logro diferenciarme en ellos.

Yo fui armando mi propio layout de servicio con todas las dimensiones, no prometo nada, pero al final de este libro estaría bueno darle forma digital y compartirlo.

Ilustremos con el último gráfico del capítulo y notemos que buenos que  ITIL gana mucho con estos diagramas, que son super claros e instructivos. Muchas veces uno va leyendo y debe detenerse para analizarlos.

ITIL SS - Multiples dimensiones de vista sobre el Service Portfolio

Bueno, ahí entramos en Service Strategy propiamente dicho, vamos definiendo el mercado y ya en la segunda página nos encontramos con la maravillosa tabla de ejemplo para etiquetar customer outcomes. Albricias!, la típica tabla con la cual las áreas de TI le piden al usuario que catalogue sus requerimientos. ¡Cuac! Dios nos libre, sólo utilizar internamente.

Ahí aparecen nuestros simpáticos amiguitos, los BRM Bussines Relationship Managers, bienvenidos al baile. Espero que más adelante haya un detalle profundo de las mejores prácticas de un BRM, porque en la historia de los Sistemas siempre fue una discusión álgida.

Un tema que me llamó la atención durante la lectura de estas páginas es que ITIL te orienta a un Service Catalog único, es inimaginable trabajar con la norma sin una visión clara de cómo se ordenan todos los ítems y sus relaciones. Tengo ya dos modelos en borrador con todas las variables estudiadas y estoy seguro que en una organización de complejidad mediana, con unos 20 o 30 servicios, es imposible gestionarlo todo con papel o con una planilla de cálculo básica.

Solo de pensar un Catálogo de Servicios, dentro de un Portfolio de Servicios se hace necesario verlo desde distintas dimensiones: la del catálogo propiamente dicho, la de los costos y riesgos, la de transición e historia, change management o incidentes, la de producción o valor y en particular la de crecimiento y futuro.

Dos comentarios con temas laterales de este capítulo. Uno eso de que si no hay definiciones no hay valor. Creo que es un error del autor, la norma no tiene capacidad de definir valor, solo se encarga de darnos el marco para implementar nuestra medida propia. Y la segunda es la difícil ecuación para incluir en un Service Pipeline mejoras de servicios de clara matriz tecnológica (ux, comunicaciones, software de base, el backoffice en general) donde los resultados son intangibles.

Yo sigo leyendo este apasionante capítulo 4 que tiene los siguientes temas:

• Define the Market
• Develop the Offerings
• Develop Strategic Assets
• Prepare for Execution

Ya les contaré más.

ITIL SS - Más definiciones

Cuando uno creía que en el capítulo anterior se acababan los dolores de cabeza del río de definiciones, viene el Capítulo Service Strategy Principles, con nuevas ideas en torno a las service units y bussines units, que uno descubre como conceptos que no eran claros en desarrollos anteriores de las ideas de ITIL. Enhorabuena.

Yo valoro todas estas definiciones como el marco conceptual que garantiza reconocer cuando TI pasa a ser un comodity y tratar de evitarlo furiosamente. Y es curioso que el dueño de un proceso de Sistemas se autodefina como alguien que no quiere ser comodity, pero la realidad es que las decisiones estratégicas sobre los servicios tienen que ser conscientes, y considerar la evolución de recursos y resultados como una decisión de todos los involucrados, no como algo “dado” que tiene que funcionar en base al dinero que la empresa pone ahí.

Además está la experiencia que tengo, suele ser desafortunado el juicio de alguien que viene de afuera cuando intenta entender la historia de un servicio y su crecimiento. De cómo pasaron de embrionarios a comodities en crecimiento y el grado de paciencia que requiere obtener valor en el tiempo.

Me interesó el concepto de SSU y la tentación de forzar que todos los proveedores del planeta sean finalmente Type II. De esa manera ganarían la agilidad de decisiones y un foco en fijar precios de mercado para vender internamente. Pasa que para mí la facturación interna de los servicios, es el objetivo final de mi estudio de ITIL, estuvimos siempre muy cerca de aplicarlo y siempre faltó el último empujón.

Muy buenas las preguntas de 3.3.4 para saber qué tipo de proveedor elegir y los tipos de transición entre tipos del gráfico 3.15. Sin olvidar la herida abierta por el breve párrafo acerca de la incumbencia, que es el factor específico de los problemas que tiene ITIL con la Innovación.

 

Nota de humor al iniciar Service Structures cuando nos viene la cita de George Box. "All models are wrong, but some off them are usefull", y muy lindo lo de las cinco P de la estrategia y el vital acercamiento a la Perspectiva, tan olvidada por el corset conceptual de Mision y Visión.

Y sobre el final encara la Estrategia como la solución conceptual a los problemas de ventaja competitiva y crecimiento, con esto terminamos el capítulo de Principles y pasamos directamente a Service Strategy.¡Qué emoción!.

ITIL SS - Arranquemos con Service Strategy

Terminada la lectura del primer libro de ITIL, elegí seguir con la secuencia lógica de leer Service Strategy, que dentro de la jerarquía de ITIL es el primero de los aspectos a desarrollar.

Digamos que las primeras páginas son un peaje a pagar, en estas se introduce al neófito en los aspectos centrales de la cuestión. No es necesario para alguien que ya leyó la Official Introduction, pero bien útil debe ser para quién da sus primeros pasos.

Pero rápidamente pasamos a Service Management as a practice y ahí las cosas toman otro color. En esas páginas el resaltador que uso para marcar los apuntes empezó a moverse vertiginosamente. Ahí están las definiciones de Service Management, de Service propiamente dicho con las componentes propias del valor que agregan los servicios: utilidad y garantía.

También vemos por primera vez el concepto de Función, que vamos a desarrollar más adelante, es uno de los principios para entender porque los servicios tienen jerarquías y deben comunicarse entre ellos.

Behold¡, abran lo ojos y conozcan el encapsulamiento, la gran mentira de los servicios de IT, garantía de felicidad del usuario y de dolores de cabeza del CIO.

Y ya sobre el final del capítulo entiendan la orientación a sistemas y este sencillo gráfico.

 

Mi reflexión personal acerca de esta primera introducción, es la misma que creo que ya les mencioné en el libro anterior y que calculo que voy a aplicar en el futuro para Service Strategy en oportunidades sucesivas´: es el tema del tiempo.

Muchos de los conceptos encarados requieren de tiempo y desarrollo, de estadísticas y métricas consistentes y representativas. En general no puedo evaluar un ROI de un servicio si no tengo historia desde donde sacar info.

Lamentablemente para los CIO de empresas del siglo XXI, el tiempo es una variable exigua y la estabilidad de los sistemas suele llegar justo en el momento del cambio de funciones. Se hace muy dificil contar con  la perspectiva y el apoyo para dejar una estrategia de servicios en funcionamiento. Quiera Dios que tu sucesor entienda el concepto y aproveche el esfuerzo.