ITIL SD - Del Capacity Management al Availability Management

Cuando los dejé en nuestra entrada anterior les prometí que entraba de lleno en el Capacity Management; el Santo Grial de los recursos a obtener para tener tus servicios con talento que los mantenga, talento motivado, talento renovándose feliz de progresar con los bolsillos llenos de dinero.

Ahí es donde chocamos con Recursos Humanos.

Eso de chocar con RRHH y con las políticas de contratación o carrera de las compañías; es una condena del trabajo de Gerente de Sistemas, también de todos sus reportes y de cada empleado o usuario que trabaja con los servicios de TI. El problema es que a esta difícil ecuación, las áreas que deberían ayudar a resolverla están más preocupadas en hacer un prode interno o un concurso de empoderamiento de la diversidad sexual.

ITIL SD evita estratégicamente el tema para no comentar cosas como las que digo más arriba y no profundiza en esta relación, sino que enfoca en la disciplina de entender que el Capacity Management es un proceso de ITIL que abarca a todo el SD a través de un Capacity Plan a actualizar anualmente.

Increíble, van tres años de lecturas pausadas de ITIL, admiro vuestra paciencia. Yo por mi parte aporto mi tozudez y avanzo en la lectura de Service Design, estoy en los densos capítulos de Availability Management que para mi hasta podría ser un libro aparte.

Libro aparte porque conlleva en si mismo la marca de la madurez de la empresa en el entendimiento que tiene de la estabilidad de sus sistemas. Es el lugar donde se encuentra el BCP con un circuito bien articulado de tecnología.

Cuando leía estos capítulos marqué una serie de variables a tener en cuenta: me detuve en los costos del Service Failure Analysis y la extensión desmesurada que toma esta disciplina en ITIl. Me anoté mentalmente aquello de las revisiones profundas anuales y me introduje con algarabía dentro del IT Service Continuity Management sobre el cual pienso que la clave es saber como articularlo con lo que acabamos de leer.

Los dejo rescatando el gráfico siguiente, véanlo y piensen.

ITIL SD - El Service Catalogue, los SLA y los KPI

Escribo esto acompañado de Tus manos /4, les recomiendo hacer los mismo.

Estuve leyendo mucho para ustedes, hice un esfuerzo para avanzar en Service Design de ITIL; para que si alguno de ustedes lo compra en la tienda oficial tenga en estas entradas un resumen, un ayuda memoria o alimento a la curiosidad. Van a poder seguir el avance con la etiqueta Service Design del mismo modo que hicimos con los dos libros anteriores.

Ojo, las lecturas de estos tiempos fueron vibrantes y muy densas en contenido. Pasamos por aquello del SLM (Service Level Management), base de los disparadores para armar el diseño de los servicios y donde enfrentamos variados conceptos para llegar luego a los SLA, bien a fondo, y los KPI.

Llama la atención en este punto que haya un hincapié especial en la percepción de los estados de cada servicio, no sólo importa el estado actual objetivo, es importante el subjetivo. De todos modos yo agregaría que no pueden ser conceptos que el Service Desk conosca y nada más, el verdader embajador de lso KPI no es Operaciones, tu Mesa de Ayuda es el arma más fuerte para difundir y encontrar socios internos que se sumen al templo sagrado de ITIL.

Y me parece que esto en Service Design está un poco flojo, calculo que Service Operations o Change Management van a insitir con mayor énfasis.

Recuerden distinguir clramente SLA, OLA y SLR, tener un draft y arrancar tu primer Service Design con la ayuda de gente que sume y valore la calidad como resultado de una arquitectura ordenada y orientada, eficiente y efectiva.

Les dejo el gráfico del Businesss Service Catalogue, sobre el cual pueden agradecer que no haya insistido hoy, porque hay mucho para hablar.

Ahora seguimos con Capacity Management (yo leo en inglés, ¿ustedes?) donde nos vamos a cruzar con el segundo NO de toda corporación, el primer NO es el cambio de cultura y el tercer NO es el dinero.

ITIL SD - Primeros pasos, el diseño y la arquitectura

Arrancamos; dejamos atrás el Service Strategy y tomamos las riendas del que parece el más adusto de los libros de ITIL, Shanon Taylor trabajó para que hagamos foco en el diseño una vez entendida la estrategia. Vean que este libro tiene tantas páginas de lectura como páginas de anexo.

Yo arranco decididamente, esperando que estos meses donde los abogados no nos molestan tanto, sean meses para avanzar y mejorar el entendimiento del diseño de servicios. Al final de todo esto me gustaría entender cuál fue el libro de ITIl que más combina con mi carrera, sospecho que lo referido a Change Management va a ser el lugar donde voy a hacerme el festín.

A pesar de todo lo leído hasta ahora, me parece que es importante tener cierto nivel de delivery y éxito en la adaptación al cambio, para que la empresa empiece a entender el diseño de servicios como tiempo a invertir. Como dice la introducción:

If services or processes are not designed they will evolve organically.

Los capítulos que leí hasta ahora son los de SD as a practice y SD principles. El primero nos trae a la “bete noire” del management de sistemas donde vemos como el usuario de IT se relaciona con el negocio.

El capítulo de los principles es denso, repite mucho de lo que intuimos cuando desarrollamos el Portfolio de servicios y entiendo que fue detallado así para acortarle el camino a los especialistas del Service Design.

A mí me aclaró mucho el tema de la arquitectura de sistemas y aquello de la Service Oriented Arquitecture, que es donde hoy en día las compañías tienen que enfocar, sobre todo aquellas que tienen sistemas legacy y alguna experiencia hecha en Business Intelligence que les reclama ir un poco más allá en la información de negocio. ¿Cómo vas a encarar una transformación digital sin invertir tiempo en definir tu arquitectura futura?.

Me dio mucha risa eso de la página 36, donde el autor pide que el arquitecto de sistemas se junte con equipos de planificación de negocios. ¡Ja!

Los ilustro con esto de arquitectura de servicios. ¿Les gusta? ¿Dónde pondrían ustedes el Portfolio de Servicios?

Sigo leyendo.

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.

ITIL - Ya dimos el primer paso

Algún día tenía que pasar… terminé de leer el libro The Official Introduction to the ITIL Service Lifecycle

Recorrí rápidamente el último capítulo antes de las vacaciones, no me hice a tiempo de escribirles esta nota y me veo forzado ahora a bucear en la memoria, mientras decido cual de los siguientes libros voy a leer.

En realidad no es una decisión difícil. Después de leer la introducción hay que ir de cabeza al Service Strategy, es la evolución natural en un desarrollo ordenado de los temas, mismo si a veces las compañías arrancan la implementación de ITIL por el lado del Service Desk.

Lo que si me queda claro de esta lectura inicial en la cual me acompañaron aburridos, es que este primer libro te da una visión global de la norma y suficientes herramientas para encarar los libros siguientes.

En particular cuando lo resume todo en el gráfico 10.6

Pasa que todo el capítulo final tiene espíritu de repaso y esquema, calculo que en el futuro lo voy a utilizar como referencia, apuntando ahí para recordar la secuencia de temas y elementos de un modo ordenado.

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!