El control y el mundo de lo imposible en la demanda a TI

Les comparto algo que publiqué en Linkedin https://www.linkedin.com/pulse/el-control-y-mundo-de-lo-imposible-en-la-demanda-ti-javier-pincemin-1ruvf 

Las áreas de TI, las áreas de Sistemas o de Cómputos, estamos vinculadas a todos los problemas de todos los equipos que integran la compañía y lo hacemos profundamente. Deberíamos ser material de consulta diaria de Calidad, Auditoría y Procesos para ejecutar controles y mejoras.

En especial para nosotros que somos del ámbito industrial, en el frigorífico hay dos áreas que son importantes de analizar por las diferencias de enfoque a la hora de atender la demanda sobre sistemas estabilizados y con un portfolio de proyectos maduro. Se trata de Operaciones y Comercial.

En Operaciones de una empresa con un ciclo industrial la clave es el control. Cuando el sistema es estable los problemas operativos se resuelven con acciones correctivas que suelen ser control de validaciones de controles controlados controlando. TI tiene que ayudar y a veces frenar las situaciones donde el desarrollo y la implementación son más caros que el beneficio. ¿Cuántas de las mejoras implementadas en el último semestre son nuevos controles? ¿Cómo medimos el beneficio que entregaron?

En cambio, en Comercial el desafío es el mundo de lo imposible. El área comercial tiene en la mira a los clientes y sus necesidades, necesita explorar la demanda y abrir todas las ventanas posibles para ubicar el stock y preservar el margen. Para el área comercial lo importante es la flexibilidad y el histórico de datos y leads comerciales; un tablero potente y un CRM que los deje volar son las claves de la felicidad.

¿Estás orientando tu gestión de la demanda con estos objetivos?

Twitter - Mucha gente enojada con Elon Musk

Es unánime, y la unanimidad es señal de alerta.

Esta entrada es a cuenta de una animosidad completa del espectro tecnológico contra Elon Musk y las últimas medidas en torno al límite de lecturas en la plataforma.

TODOS los referentes tecnológicos que leo, se manifestaron contrarios. Sin dar pie a duda refieren que la última medida de los responsables de la red Twitter, es un atentado directo a la libertad de expresión. ¡La muerte de la democracia!

Musk lo expresó de este modo:

To address extreme levels of data scraping & system manipulation, we’ve applied the following temporary limits:

• Verified accounts are limited to reading 6000 posts/day
• Unverified accounts to 600 posts/day
• New unverified accounts to 300/day

En las horas siguientes, gracias a que esto salió ayer sábado 1 de Julio, pude leer varios comentarios y dos notas extensas de lloradores y agitadores de catástrofes profesando su salida al exilio de Mastodon. El mismo Mastodon que todos los conservadores conocimos hace años porque Twitter era una cárcel que no nos dejaba decir a viva vos que las mujeres no tiene órganos reproductivos masculinos.

Los argumentos son varios:

Se quejan de que Twitter se está muriendo y que la última estrategia para salvarlo es atacar de este modo el tráfico excesivo, dada la incapacidad de estabilizarlo. Para mi esta no es la llave de la cerradura, hace meses que funciona con 10% de los empleados que tenía y sin caídas graves, nada parece indicar que este sea el motivador.

Los que leí no quieren comentar el problema del data scrapping, ni como amenaza a la censura motorizada por AI, ni como estrategia de negocio para que Twitter pueda hacer su propio data scrapping y venderlo a la dictadura mejor pagante. Yo repliqué el siguiente comentario https://twitter.com/Perpetualmaniac/status/1675287728555167744 que me pareció un poco conspiranoico, pero factible. Realmente no le veo el problema a que Twitter quiera monetizar la información que le damos, es el concepto mismo de una red social.

El tercer argumento que encontré fue del tenor: "¡La muerte de la democracia!". Tomar esta medida de Twitter como si fuera una nueva censura para impedir a la gente ser libre en Twitter, librarlos del único lugar donde podían expresarse con libertad y romper la plaza pública de las ideas, que según ellos garantiza la libertad y da sentido a toda la plataforma. Se nota en el griterío que los gritantes no vivieron en internet durante los últimos 10 años, donde se nos era prohibido disentir con lo políticamente correcto y donde estas plataformas estaban valladas contra el disenso. Todo lo asocian a un monopolio conservador homofóbico que quiere revancha y fascismo electrónico.

Buena suerte en Mastodon, Twitter sigue vivo por un tiempo más. 

La AI, complejidad, miedo y desinformación

Esta va a ser una entrada difícil, porque requiere que lean mucho y que lean a gente que espera al transhumanismo como la próxima albricia tecnológica que nos va a salvar. Por ejemplo, en http://www.elladodelmal.com/2021/06/usar-gpt-3-y-deepfakes-para-crear-joi.html 

Es que como dijo Chesterton en su frase de las ideas sueltas… aunque lo niegue, el mundo moderno quiere Salvación y Apocalipsis; esos mismos que juró destruir junto a la Cristiandad. 

Los invito a leer dos noticias acerca de AI (Inteligencia Artificial, que en el estado del arte actual solo son de Machine Learning, pero no importa, se entiende). La primera es que Facebook invierte fuerte en tecnología para detectar DeepFakes; los DeepFakes son videos falsos (utilizados principalmente para fines corruptos) donde una AI remplaza una cara y reproduce expresiones de un modo asombroso. 

Lean en https://www.theverge.com/2021/6/16/22534690/facebook-deepfake-detection-reverse-engineer-ai-model-hyperparameters?scrolla=5eb6d68b7fedc32c19ef33b4 y vean esta imagen de caras que fueron creadas por una computadora y que en realidad no existen. 

Si, estas personas no existen. 

La otra nota es un vuelta de tuerca de complejidad que le da marco a mi reflexión de más abajo, se trata de http://www.elladodelmal.com/2021/06/la-inteligencia-artificial-comienza.html acerca de una AI que se dedica a diseñas chips para hacer AI. Una idea muy lógica, pero de una complejidad extrema, porque los límites que toca son muy complejos de aprehender y solo son observables para un puñado reducido de personas, muy técnicas y muy cercanas a los resultados. 

Ya hace mucho que la discusión en torno a la moralidad de los actos propios de quienes desarrollan soluciones tecnológicas dejó de ser un tabú, es moneda corriente y motivo de preocupación, hay vidas en juego. Lo que yo quiero agregarle es un nivel adicional, se trata de que el nivel de complejidad es tal que no hay manera de utilizar esas tecnologías si no es con una confianza irracional.

Esto es germen para dos fenómenos que son bisagra: el miedo y la desinformación. El miedo porque es tierra fértil para todo lo delirante que puedan imaginar; la desinformación porque va a ser el burdel donde se van a refocilar todos los medios de comunicación. 

Nos libre Dios y venga pronto

No voy a escribir acerca de videojuegos violentos.

Primero leen los comentarios de Enrique acerca de este tema, comentarios medidos, pero enviciados por una miopía propia de no conocer la realidad política de EEUU y pensar que todo lo que hace Trump es malo por diseño. Miren sino esta muestra.

Pero sobre todo, debemos estudiar el contexto: desde 2016, el número de actos violentos en los que se trasluce una motivación racial o una connotación de crimen de odio ha ido incrementándose gradualmente, a medida que el inquilino de la Casa Blanca radicalizaba más y más sus posturas en ese sentido. De cara a las elecciones de 2020, la postura de Donald Trump en ese sentido se ha hecho cada vez más militante, además de incrementar progresivamente el acoso a la población inmigrante y el clima de hostilidad.

Yo coincido con el en algunas premisas, pero me encontré mucho más en las palabras (en inglés) de Michael Knowles, que no tiene miedo a criticar a Trump y a la culpa de los videojuegos, pero que lo hace con más sentido común que Enrique.

Es increíble lo esclarecedor que resulta entender el idioma original, me suelo llevar estos días -como compañía cuando estoy corriendo - los podcast de Daily Wire y son un bálsamo, muy divertidos.

Pero esta entrada no es acerca de los videojuegos violentos, es acerca de no dejarte nublar por tus filias e investigar más.

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.

FreeCodeCamp, 503 y los valores

Celebro hoy haber alcanzado el final del módulo de Javascript de FreeCodecamp, me costó bastante hacer los últimos ejercicio donde había que codificar con algo más de detalle; ojo, no porque no estuviese encarando bien los ejemplos, sino porque no tengo tiempo mental para estar cinco horas mirando 30 líneas de código. Debe ser algo de la edad o la urgencia. 

 

Me encantaría, luego de terminar las 2400hs de curso, tocar algo como esto https://lifehacker.com/10-steps-to-create-your-first-android-app-1773386357 queda en la lista de pendientes.

 

---

 

Pequeño recordatorio: si tu WordPress da error 503 en wp-login.php es probable que te hayas quedado sin espacio, hay que entrar por ftp o file manager del sitio y limpiar un poco la mugre. O comprar más almacenamiento.

 

---

 

Una revelación, con mil aristas notables, con mucho para pensar y cogitar. Resulta que los valores tan mentados y que todo el mundo reclama sin mencionar, en realidad son las viejas y queridas virtudes de toda la vida.

Increíble.

Asombroso.

 

Por lo menos para mi, que hasta ahora los identificaba (a los valores) con los principios fundamentales como familia, Fe, dignidad, subsidiariedad, honestidad, etc. No, no son eso, son las viejas virtudes, son todo acción y nada fundamento. ¡¿Se dan cuenta!?

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.

Backup y Restore de SuiteCRM

Ustedes nunca lo supieron porque nunca lo conté, pero utilizo mucho SuiteCRM en el trabajo. Con SuiteCRM pude arrancar el proceso de reclamo de mis funciones actuales y generar información de gestión de un modo inteligente, solo con la ayuda de un XAMPP y algún tunning.

Lo que me faltaba era el tema de migrar de PHP y prepararme para una futura caída y recuperación de backup. Resumiendo el asunto les cuento que tuve éxito total y que ahora soy un Wizard Master de SuiteCRM (por si necesitan ayuda), la entrada de hoy sirva para detallar el logro y los pasos a seguir por si mi memoria me deja a pié.

1. Primero hacemos el Backup desde el propio SuiteCRM http://127.0.0.1/suitecrm/index.php?module=Administration&action=Backups en mi caso el enlace es este porque tengo una instalación local.
2. Luego, con la ayuda de mysqldump -u root -p contraseña --all-databases >dumpdelabase.sql generamos el dump de MySQL (este amiguito mysqldump tiene que venir en c:\xampp, en bin)
3. Luego me voy al servidor nuevo e instalo xampp y el SuiteCRM de Bitnami.
4. Bajamos el apache, para no hacer ruido con el siguiente paso
5. Recupero el backup de SuiteCRM, que en realidad es un zip con todo adentro y necesita ser copiado pegando los archivos. Tuve algún problema con php.ini, ojo con esto. En este punto me pareció que SuiteCRM debería tener su opción de Restore para resolver esto.
6.  Ahora tiramos un cmd con mysql -u root -p -use suitecrm <dumpdelabase.sql donde el parámetro use tiene el nombre de la base en cuestión o sino podés usar --alldatabases
7. Lo que me pasó también fue que al pasar de instalación de SuiteCRM normal a Bitnami, tuve que editar el config.php de SuiteCRM para que apunte a la base de dato nueva.
8. Ahí ya podemos levantar el Apache de nuevo y hacemos un Repair desde la administración de SuiteCRM.
9. ¡Listo! Todos felices.

Listo, ahora puedo volver al trabajo y a hacer los dump diarios de la Base de datos. Debería programarlos en un script de ejecución diaria, tengo que resolver con el conflicto de usuario. O mejor aún, ver si hay una herramienta para programar backup de MySQL.

Empoderamiento, albaricoque y maduración

Batalla cultural a pleno en el trabajo, donde se suscribieron acuerdos del pacto global de la UN y donde se empiezan a acunar los conceptos de "empoderamiento de la mujer", "igualdad de género" y otros mantras ideológicos.Yo lo observo con curiosidad, me llama la atención la unanimidad y la cercanía.

Tiempos difíciles para los que estamos más cerca de ideas de "dignidad", "solidaridad", "bien común" y "subsidiariedad"

---

Los vecinos de la casa abandonada del fondo han cometido un crimen atroz. En plena floración, en el momento donde el añoso damasco (albaricoque) que ornaba la medianera estaba llenando de su perfume nuestro jardín, lo cortaron de raíz.

Por lo que pude intuir, sin sentido alguno. Asomándome se ve la limpieza de la jungla que se había formado y el tocón a ras del piso, con restos y evidencias del crimen. Chau sombra, chau flores blancas, chau deliciosos damascos que podíamos cosechar de nuestro lado.

Un crimen atroz, que me tiene en duelo.

---

Encontré esto esta mañana en Twitter.

Léanlo con atención, es la clave para entender muchas cosas que pasan en torno a la información, en torno a la política y el debate en general. Mi resumen personal es que madurar se transforma en la vara que divide las aguas entre el conocimiento futil y la búsqueda de la verdad.

Y por elevación, explica también porque Snapchat es tan nocivo para educar a tus hijos.

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.

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.