XavMP

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 org...

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 Redu...

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.

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 p...

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)...

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...

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 u...

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 ...

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...