Necesito una Unidad de Intervención Inmediata

Frecuentemente cuando se ponen en marcha nuevos servicios, incidimos sobre cientos de usuarios que deben adquirir rápidamente nuevos conocimientos y adaptarse a nuevas maneras de trabajar. Es en este momento cuando necesitamos poner foco en una Gestión del Cambio precisa y especializada que nos ayude a conseguir poner a todas estas personas en marcha rápidamente.

El problema

Cuando hacemos este tipo de despliegues, se produce un rápido aumento de las necesidades de soporte: gran cantidad de usuarios necesitan apoyo en un corto espacio de tiempo. Los equipos de soporte se ven fuertemente afectados por esta situación, que además deben combinar con dar apoyo a las necesidades cotidianas del negocio.

La gestión del cambio debe proporcionar una base de conocimientos, materiales de formación y procedimientos que sean comprensibles, que se mantengan actualizados y que sobre todo puedan ser consultados de manera fácil por los usuarios afectados.

La solución

El empleo de soluciones especializadas y temporales, que puedan montarse, usarse y desmontarse fácilmente y en modalidad de pago por uso. Soluciones que no interfieran con los entornos corporativos y que proporcionen la flexibilidad y el acceso global que requieren los usuarios.

La Propuesta de G2

El próximo Jueves 7 de Mayo de 2020 haremos un webinar explicando cómo montamos una de estas plataformas express para habilitar una Unidad de Intervención Inmediata. 

Inscríbete aquí:  https://atlassian.gedos.es/inscripcion-webinar/ 

El Service Desk como Unidad de Intervención Inmediata

Llevo en el sector de las TIC unos 33 años y desarrollando proyectos unos 28. Aún así, mis participaciones en proyectos de software más intensas se han dado durante los últimos 10 años, temporada en la que desde G2 hemos hecho una suave deriva dentro de la gestión de servicios a la gestión completa del ciclo de vida del servicio, cosa que me ha permitido participar en los equipos de desarrollo aportando visiones de Lean, de Agile y de DevOps.

Durante estos años, una de las lecciones más importantes que he aprendido es que no hay DONE sin Materialización del Valor. Es decir, que por mucho que los equipos de desarrollo piensen que han finalizado un paquete de funcionalidades, hasta que no están en manos de usuario y siendo utilizadas, no son más que promesas incumplidas de un valor futuro.

Ya escribía sobre esto aquí

http://www.gobiernotic.es/2009/12/el-ultimo-del-ano-y-va-sobre-valor.html

y aquí

http://www.gobiernotic.es/2010/05/la-evolucion-cuantica.html

Ya más maduro, sobre el año 2013 reflexionaba sobre la problemática que nos presentaba el hecho de acelerar el flujo utilizando técnicas de automatización y el cuello de botella se trasladaba a otro sitio: el usuario, la última frontera.

http://www.gobiernotic.es/2013/06/el-punto-debil-de-devops.html

Así que llegamos a la conclusión de que una de las fases que más pueden influir en la materialización del valor generado por un proyecto es la de la Gestión del Cambio: poner en manos de los usuarios la nueva aplicación y conseguir desplegar lo antes posible y sobre el número de usuarios adecuados, el conocimiento, la práctica y los nuevos circuitos que harán que la promesa de valor se convierta en realidad.

¿De qué serviría un nuevo sistema para canalizar las oportunidades de venta que llegan por los diferentes canales si los comerciales no lo saben usar o lo usan mal?

¿De qué serviría el precioso sistema de seguimiento de indicadores si los que deben tomar decisiones en base a esos indicadores no lo saben usar o aquellos que alimentan los datos lo hacen mal o a deshora?

¿Cómo diablos vamos a conseguir poner a todas esas personas en teletrabajo si cuando les damos las herramientas técnicas no saben usarlas?

Así, pues, se nos hace fundamental ayudar a los equipos en esta etapa de Gestión del Cambio, y tradicionalmente las empresas ponen foco en una serie de acciones: 

• generación de materiales de formación
• formación a usuarios clave
• formación a formadores
• formación al equipo de soporte
• documentación de las preguntas más frecuentes

Pero...  ¿A qué se parece la realidad cuando te enfrentas a desplegar una solución para cientos o miles de usuarios? 

Pues lo primero que te pasa es que la aproximación de formar a usuarios claves o formación de formadores es quizás un poco lejana al usuario final. 

Tardas demasiado en llegar a ellos y con personas que en realidad son “proxies” del conocimiento: muy buena tiene que ser la formación a formadores (teórica y práctica) para que ellos puedan transmitir de manera fluida todo lo que se supone que debe saber el usuario final. Y muy buenos tienen que ser los materiales de formación, no podemos aspirar a que ellos generen sus propios materiales.

Lo segundo es que habrá situaciones que hayan quedado fuera de la formación y que durante las sesiones de formación a usuario final aparezcan en forma de preguntas que el recién estrenado profesor no sea capaz de resolver. ¿Tenemos un canal para poner en contacto al profesor con el equipo de desarrollo para que le resuelvan la duda de un día para otro? ¿Tenemos una manera de documentar este conocimiento modificando rápidamente el material de formación o de consulta?

En tercer lugar, los recién formados alumnos comienzan a trabajar con el nuevo sistema y lógicamente tienen dudas, encuentran cosas que no saben hacer o peor aún, encuentran errores. Esto, que en condiciones normales significaría una pequeña porción del trabajo habitual del Centro de Soporte, se puede convertir rápidamente en una avalancha de llamadas para las que, por si fuera poco, el técnico de soporte debe invertir mucho más tiempo en resolver porque a) no tiene la práctica y la formación habitual (es un producto nuevo) y b) necesita dar formación al usuario, dando una respuesta que al tiempo de resolver su problema, sea pedagógica para facilitar la incorporación del usuario en la nueva solución.

Para terminar de rizar el rizo, nos vamos a encontrar con que si el Centro de Soporte está colapsado atendiendo este tipo de interacciones, ¿cómo vamos a atender los contactos habituales, los que se refieren a otro tipo de servicios que incluso podrían ser más prioritarios? ¿Cómo atenderemos el Business as Usual?

En definitiva, vemos que para una situación más o menos excepcional como es el roll-out de un proyecto que tiene afectación a un elevado número de usuarios en un breve espacio de tiempo, debemos buscar soluciones adecuadas y excepcionales, huyendo de la solución tradicional de “lo pasaremos a través de soporte ” y construyendo una solución adecuada a esta situación de trato especial al usuario. (de hecho, a esta fase de los proyectos se le llama precisamente la fase de HyperCare)

Posiblemente pensarás que este tipo de roll-outs son poco habituales, que las cosas las hacemos de manera iterativa e incremental y que eso de un gran proyecto en modo cascada está pasado de moda. Te doy toda la razón del mundo, pero también es cierto que la gran mayoría de proyectos que significan sustituir una plataforma por otra, aquellos que tienen una puesta en marcha en formato big-bang, aquellos que ponen un producto mínimo viable en manos de un gran número de usuarios y todos aquellos que se ponen en marcha por motivos de extremada urgencia (por ejemplo, motivados por la activación de planes de continuidad) son candidatos a recibir este tipo de tratamiento. 

¿Y cuál es la respuesta?

Bueno, en G2 llevamos tiempo ya dándole vueltas a esto y ayudando a nuestros clientes a crear esto que llamamos Unidades de Intervención Inmediata. 

Para ello, nos inspiramos en el concepto de Arquitectura Efímera: son instalaciones que se diseñan y se piensan teniendo en cuenta que serán poco duraderas. Están orientadas a transmitir sensaciones, mensajes o emociones a través de las formas durante un breve espacio de tiempo (semanas o quizás meses), como puede ser una instalación artística en un aeropuerto, el stand alucinante que viste en la última feria a la que asististe o un hospital de campaña montado de manera urgente para atender una situación como la que estamos viviendo.

Estas arquitecturas efímeras están pensadas para transmitir un mensaje concreto durante un tiempo concreto, de la misma manera que en IT necesitamos transmitir un mensaje concreto (la tranquilidad de dar el paso a usar una nueva herramienta) durante un tiempo concreto (el que necesite el negocio hasta haber estabilizado el uso del nuevo sistema).

Así, nuestra propuesta es la generación de una plataforma de soporte completamente nueva, especialmente orientada a apoyar a los usuarios en la transición a esta nueva manera de trabajar que supone el despliegue del nuevo servicio y que se concibe desde el inicio como una plataforma efímera: se monta rápido, se usa rápido, se destruye rápido y sólo se paga por el tiempo que se usa.

El próximo Jueves 7 de Mayo de 2020 haremos un webinar explicando cómo montamos una de estas plataformas express para habilitar una Unidad de Intervención Inmediata. En esta charla veremos cuáles son las ventajas que le aporta al cliente, tanto al equipo de soporte, como al equipo de administración de herramientas y a los usuarios finales.

Si te ha picado el gusanillo de la curiosidad, inscríbete en nuestra página del G2 Atlassian Team y trae preparadas todas las preguntas que quieras plantearle al equipo que con gusto las resolveremos.

4 ideas para aumentar la velocidad

En Scrum se utiliza el concepto de velocidad para referirnos a la capacidad que tiene el equipo de “quemar puntos”, o sea, a su capacidad de producción. El aumento de la velocidad es uno de los principales indicadores de que el equipo está cohesionado, en continuo aprendizaje y en mejora continua.

Pero... ¿cómo se aumenta la velocidad?

Desde luego, no es por azar. En este artículo veremos cuatro herramientas fundamentales para la mejora de la velocidad en tu equipo Scrum.

1.- Identificar QUÉ nos resta capacidad

Si sumamos todo el tiempo laboral del que disponen los miembros del equipo, tendremos una capacidad productiva teórica máxima.

Esto es una simplificación, porque estamos sumando “peras con manzanas” ya que una hora de María no es igual a una hora de Joan y, desde luego, una hora de Joan haciendo análisis no es igual que una hora de Joan haciendo testing. Por esta razón utilizamos puntos en lugar de horas para estimar las tareas, pero esta es otra historia que debe de ser contada en otra ocasión.

Centrémonos: tenemos una capacidad máxima teórica que luego se convertirá en una capacidad efectiva real. ¿Cuál es la diferencia? ¿Qué nos está mermando la capacidad productiva?

Debemos aprender a identificar en qué estamos invirtiendo el tiempo del equipo para ver cómo podemos optimizarlo y ganar en capacidad productiva, o al menos ganar en objetividad y no engañarnos pensando que el equipo produce 8 horas al día. Por ejemplo, nos encontraremos frecuentemente que los miembros del equipo dedican parte de su capacidad en tareas como:

• Reuniones
  
• Llamadas telefónicas
  
• Formación
  
• Participación en otros proyectos
  
• Colaboración con otros equipos
  
• I+D
  
• Ausencias / Absentismo
  
• Ejecución de tareas no planificadas
  

Atención! Hemos dicho “optimizar”, no “eliminar”. Hay que ser conscientes de en qué invertimos nuestro tiempo y en conseguir un equilibrio. Por ejemplo, una de las grandes ventajas de aislar al equipo y tratar de eliminar las interrupciones es reducir el tiempo dedicado a reuniones y llamadas telefónicas; o una de las ventajas de mantener acotado el numero de equipos a los que pertenece una persona es reducir el overhead de coordinación y de cambio de contexto.

2.- Identificar EN QUÉ derrochamos capacidad

Este punto está más relacionado con la parte “interna” del trabajo como equipo Scrum. De todo el trabajo que hacemos como equipo (es decir, del que estamos considerando dentro del cómputo de la velocidad), ¿qué podemos optimizar? ¿Se nos va el tiempo en actividades que no aportan valor al usuario?

Hay tres grandes “vampiros” de la eficiencia en el trabajo de un equipo scrum: Muda, Mura y Muri.

Muda: Son actividades que no aportan valor y que están clasificadas por algunos autores en 8 grandes bloques:

1. Trabajo a Medias (el famoso WIP)

2. Exceso de Funcionalidad (hacer más de lo que el cliente requiere)

3. Procesos Extra (algo parecido al exceso de burocracia o procesos excesivamente complicados)

4. Traspasos (cruzar barreras organizativas siempre añade retrasos a nuestro flujo)

5. Retrasos (todo aquello que suponga tiempos de espera)

6. Conmutación de Tareas (la multitarea es enemiga de tu cerebro, que es tu principal medio de producción!)

7. Defectos (los errores y la deuda técnica)

8. El talento desaprovechado (por eso somos un equipo scrum!)

Mura: es la irregularidad en las tareas o en los resultados. Por eso tratamos de estandarizar las entradas al proceso, utilizar plantillas y checklists o incluso homogeneizar el trabajo a nivel inter-equipo scrum y hasta hemos formalizado una Definition of Done

Muri: es el trabajo tensionante. El stress sobre personas y máquinas produce errores y genera más muda. Por este motivo buscamos equipos motivados, equilibrados y felices.

Aprender a ver, clasificar y eliminar muda, mura y muri en el trabajo que hace el equipo Scrum día a día debe convertirse en uno de los puntos clave de las retrospectivas y alimentar el backlog de mejora continua de forma implacable.

Aprender a ver, clasificar y eliminar muda, mura y muri debe convertirse en uno de los puntos clave de las retrospectivas para optimizar el trabajo del equipo Scrum

3.- Aprender a NIVELAR la demanda

En el sprint plan hacemos entrar trabajo al sprint backlog y se adquiere el compromiso del equipo con respecto a los objetivos a cumplir. Si dejamos entrar demasiado, tendremos más demanda que capacidad y eso genera muri. Si dejamos entrar poco, tendremos más capacidad que demanda y eso genera muda.

Tenemos que aprender no sólo a dejar entrar la cantidad justa sino que además debemos aprender a dejar entrar la combinación adecuada de tareas en función de las características del equipo (y por esta razón los equipos deben de ser lo más estables posibles).

Así, debemos trocear las historias de usuario en paquetes pequeños que fluyan suavemente y debemos evitar entrar bloques grandes en el proceso. Un trabajo “grande” se comportará como un tractor en una carretera: todo el resto del trabajo estará atascado detrás, ya trabajes en modo Scrum o en modo Kanban.

Esta técnica de combinación de la demanda para ocupar nuestra capacidad se llama Heijunka y es clave en la planificación industrial de la producción.

4.- Aprender a ayudar al FLUJO

Recuerdas el manifiesto ágil? Decía algo así como “Preferimos software funcionando sobre documentación extensiva”. Nos gusta más el software funcionando, es decir, nos gusta ese momento en que pasamos un “PSPI” (Potentially Shippable Product Increment) a Done.

Así que cuando acabes una tarea, en lugar de dirigirte al sprint backlog y coger la próxima tarea para iniciarla, para un momento y mira el tablero; recuerda que somos un equipo y nos medimos como equipo, así que no se trata de ser el que más tareas inicia, sino que se trata de que como equipo debemos terminar las tareas que nos hemos comprometido.

Lo importante es llevar la historia de usuario a done, no las tareas individuales. Esto nos hace trabajar como un equipo y poner foco en la entrega de valor.

Una vez hecha esta reflexión plantéate:

1. ¿Hay alguna tarea bloqueada que tú puedas desbloquear?
   
2. ¿Hay alguna tarea a medias en la que tú puedas ayudar?
   
3. ¿Hay algún compañero que necesite tu ayuda?
   
4. De todas las tareas que hay en el sprint backlog y tú puedes hacer, ¿Cuál es la que más ayuda a una historia a terminar?
   

La idea, una vez más, es completar el trabajo que hemos comprometido al inicio del sprint. ¿Qué crees que hará más feliz al cliente al final del sprint, mostrar que hemos iniciado todas las historias y no hemos acabado ninguna o mostrar que hemos acabado el 70% de las historias y que no hemos llegado a completar el otro 30%?

¿Qué otros trucos tienes para aumentar la velocidad? Estos cuatro son sólo eso... cuatro de entre los cientos que podemos imaginar.

La rana en la olla, agile y los equipos de operaciones

Cuando das clases de muchas temáticas diferentes pasa que durante un curso tu mente se enfoca en una materia concreta y al siguiente curso la materia cambia. Si en medio además te dedicas a hacer proyectos, notas cómo esas materias te influencian fuertemente en tu manera de enfocar o de abordar los problemas que se plantean en la ejecución.

Este último mes he tenido proyectos de agilidad, clases de lean y clases de ITIL® así que mi cabeza es un hervidero de ideas. Entre ellas, esta mañana apareció un flash: ¿que pasa con los atributos de garantía en un entorno ágil?

Hace unas semanas escuchaba a Alex Ballarin en una clase diciendo algo que me hizo sonreír: las historias de usuario pueden usarse también para expresar requerimientos no funcionales, por ejemplo algo así como "Como sistema quiero soportar 1000 usuarios concurrentes para que no se ralentice la cadena de valor"

Con la interpretación “tradicional" de ITIL® vemos el ciclo de vida del servicio como una gigantesca rueda waterfall que lleva un servicio completo desde la Estrategia hasta la Operación y luego lo hace evolucionar en forma de "servicio modificado” con la mejora continua del servicio. Con esta visión es fácil comprender la importancia que tiene en la etapa de diseño que utilicemos las famosas 4P para tener en cuenta los aspectos de garantía del servicio y que incorporemos los requerimientos de garantía en el diseño y posteriormente en la construcción, pruebas y despliegue.

La cosa es grande y viene de lejos, así que nos preparamos para acogerla en nuestro entorno de producción; para ello tendremos en cuenta a los equipos de operaciones o, para ser más itileramente formal, a las funciones de la etapa de Operación del Servicio y por ejemplo prepararemos las infraestructuras para dar soporte al volumen de usuarios que esperamos.

Cuando se avecina un cambio grande, es normal que se cree esa sensación de necesidad de preveer las consecuencias y por lo tanto que se piense en aspectos como la capacidad, la disponibilidad o la seguridad.

Pero… ¿y qué pasa en el momento en que cambiamos el modo de trabajo y pasamos a trabajar el modo “evolutivo” desde el minuto cero?

Peter Senge explica en su libro La Quinta Disciplina el concepto de adaptación a los cambios lentos y graduales y el peligro que conllevan si no estamos atentos y lo ilustra con una parábola que a mi personalmente me pone los pelos de punta por lo cruel de la idea: la parábola de la rana hervida. Muy cruel, pero explicita!

Si ponemos una rana en una olla de agua hirviente, inmediatamente intenta salir. Pero si ponemos la rana en agua a la temperatura ambiente, y no la asustamos, se queda tranquila. Cuando la temperatura se eleva de 21 a 26 grados centígrados, la rana no hace nada, e incluso parece pasarlo bien. A medida que la temperatura aumenta, la rana está cada vez más aturdida, y finalmente no está en condiciones de salir de la olla. Aunque nada se lo impide, la rana se queda allí y hierve. ¿Por qué? Porque su aparato interno para detectar amenazas a la supervivencia está preparado para cambios repentinos en el medio ambiente, no para cambios lentos y graduales.

De repente ocurre que en algún momento aparece esa necesidad de soportar 1000 usuarios concurrentes, la implementamos y luego se producen 200 modificaciones posteriores a las funcionalidades del servicio en forma de sendas historias de usuario que se implementan en sprints sucesivos…. y de repente esas pequeñas modificaciones que una a una eran poquita cosa hacen que nuestro sistema deje de soportar 1000 usuarios concurrentes.

Técnicamente esto no debería pasar, porque a cada modificación hacemos pruebas de regresión y pruebas de los requerimientos funcionales y nos aseguramos de que cada pequeño cambio no rompa nada, pero… por favor, que levante la mano el que esté dispuesto a asegurar que hace eso para todos sus servicios en la etapa de construccion.

Si salen más de 10, prometo borrar este post.

En resumen, que propongo que al menos para empezar, la historia de usuario se reescriba para contemplar este peligro y quede en algo asi como

Como sistema, quiero soportar 1000 usuarios concurrentes y seguir soportándolos despues de los próximos 10 sprints. Depués volvemos a hablar de demanda, capacidad y arquitectura.

A media que vayamos madurando y consigamos un flujo continuo con todos los requerimientos de información necesarios, una arquitectura flexible y escalable y un sistema de testing automatizado que nos garantice que cumplimos los requisitos no funcionales en modo regresión entonces podremos modificar la historia de usuario para reflejar el objetivo real:

Como sistema quiero soportar el numero de usuarios concurrentes que necesite el negocio en todo momento de modo flexible, elástico y con una estructura de costes asumible por la organización.

Pero eso requiere un nivel de madurez enorme en toda la organización: el negocio debe decir de forma continua (o casi) la demanda prevista, la capacidad debe poderse adaptar de forma instantánea, las arquitecturas deben poderse redimensionar al momento y todo esto con un esquema económico razonable… o podemos quitar al negocio de la ecuacion y montar un sistema flexible y automatizado que crezca o decrezca según la demanda real…

¿Ciencia Ficción?

¡Preguntale a Etsy o a Netflix!

PS:: Iba a ilustrar este post con alguna foto… lo primero que me vino a la cabeza fue esta preciosa ranita de San Antonio del blog Naturaleza Andaluza, pero finalmente me he negado…. no se ha dañado ninguna rana para escribir este post. Ojalá Peter Senge piense en otra parabola menos salvaje!

PS2: Pues resulta que este post inspiró a mi amigo Rui Soares, autor de ITIL Blues y creador de los personajes Mush & Room, quien me dibujó la  fantástica ilustración que acompaña  este artículo. GRACIAS!

¿Transformación Digital? No sin DevOps!!

Se me repite la ocasión en que vuelvo a casa despues de un curso de DevOps Foundations. Probablemente disponer de tres horas de tranquilidad después de tanta actividad hace que me aparezcan algunas ideas y me den ganas de escribir.

Una de las slides que presento en la versión para managers de este curso está sacada del documento State of DevOps Report 2015, publicado por Puppet Enterprise y que representa un informe sobre el estado de la cuestión que han venido publicando desde 2013 y que se ha ganado el respeto de la comunidad.

La primera vez que vi esta gráfica se me pusieron los pelos de punta y creo que es de una importancia tan grande que es necesario dedicarle un post, una noticia en el periódico y hasta un libro si fuera necesario con tal de hacer entender a todos los directivos del pais lo que significa.

Vamos a ir por partes: en el eje vertical tenemos tenemos la frecuencia de despliegues en la organización., pero atención, representada en una escala logarítmica donde 1 significa un despliegue al día… pero es que 2 significan 10 despliegues al día y 3 significan 100 despliegues al día; no nos dejemos engañar por la inocencia de esa gráfica.

En el eje horizontal tenemos, en escala también logarítmica, el tamaño de los equipos de desarrollo. Asi que me he permitido el lujo de calcular “a ojo” los valores de la curva, meterlos en un excel y hacer una gráfica parecida pero con escala lineal, para no suavizar el impacto del puñetazo que nos dan estos datos

¿Y qué significa esto? Pues básicamente que

a) Los “low performers” (aquellos que con sus prácticas actuales no llegan a más de 100 desarrolladores y que aún así están haciendo como mucho tres o cuatros despliegues a la semana.

b) El rendimiento de los “low performers” cae rápidamente cuando crecen en número de desarrolladores. Esto es típico de las aproximaciones tradicionales: al añadir más personal, crece la desorganización y el waste y por lo tanto la eficiencia cae en picado. En la siguiente gráfica he quitado a los high performers para poder percibir esta situación:

c) Con respecto a los “Mid Performers”, podemos ver que soportan relativamente bien la incorporación de cada vez más personal y lentamente aumentan el número de despliegues al día. Fijémosnos en que esto significa, desde el punto de vista del negocio, que podemos llegar a doblar el número de desarrolladores (e incurrir en costes mucho más elevados, ya que el aumento de costes no es lineal al numero de personas) y aún así no llegan al despliegue diario (en el fondo, quizás aqui el aspecto importante de verdad es que puedes doblar los recursos, pero no doblarás la velocidad de despliegues, sino que se mantendrá relativamente constante)

d) Finalmente, los “High Performers”. Estos son los preocupantes. Estos se mantienen más o menos cercanos hasta llegar a los 300 desarrolladores. Entonces comienza su escalada brutal: pasan a los cinco despliegues al día y rápidamente con capaces de llegar a los 80 despliegues al día apenas triplicando los recursos (osea, triplico los recursos y multiplico por 15 los resultados (!!!)

Posiblemente en estos momentos estés pensando que eso en el fondo son unos números más o menos trucados, quizás que en tu empresa hay doscientos programadores y que eres capaz de hacer 40 despliegues a la semana (que son unos 5 al día) y que eso está chupado, o simplemente que “¿y para qué quiero yo hacer tantos despliegues al día?”.

Perdón, que me ha faltado la última excusa, bastante frecuente además, la de “si, claro… pero ¿cuántos de esos despliegues son buenos? ¿Qué nivel de fallos tienen estos tios a esa velocidad?”. Te lo respondo en la siguiente tabla, tambien sacada del mismo State of Devops Report 2015

Ok, pues esto nos muestra que se está produciendo una brecha inmensa que está separando a los high performers del resto del mundo a una velocidad pasmosa y eso es un problema.

Ahora piensa en todos aquellos que están hablando sobre Transformación Digital. En el fondo están tratando de aplicar soluciones del mundo digital a los problemas que tienen sus clientes y buscando nuevas vías de contactar con ellos, de mantenerlos ligados a su marca, productos y servicios y rompiendose la cabeza para innovar en sectores que posiblemente sean muy tradicionales: ¿cómo ofrecer novedades en el sector banca, seguros, retail?

Y resulta que todo el concepto de Transformación Digital se basa en cuatro palabras: experimentar, innovar, aprender y digitalizar. Una empresa que aborde una iniciativa de transformación digital tiene que ser consciente de que esto no es un proyecto con inicio y fin, sino una transformación: ahora eres una cosa y luego serás otra, pero esa otra cosa, ese punto de destino es móvil y cambiante; las empresas transformadas ya no son empresas rígidas sino que son empresas líquidas que se adaptan de forma continua a un entorno, a un mercado y a unos clientes que cambian continua y rápidamente.

¿Y cómo puedes conseguir eso en un entorno digitalizado? Pues con velocidad. Necesitas que en IT tu flujo de aportación de valor sea muy rápido y que tu lead time sea muy corto con un nivel de acierto elevadísimo… y eso es exactamente lo que están consiguiendo los high performers de nuestra gráfica de arriba.

Resulta que los high performers han llegado a una situación en la que su lead time de experimentacion es muy corto, su capacidad de desplegar pruebas en los entornos de produccion es altisima, su riesgo muy bajo y su capacidad de recuperarse ante los errores es increible… los high performers pueden probar nuevos productos, nuevas lineas de negocio y nuevas maneras de comunicarse y satisfacer a sus clientes 200 veces más rápido que una empresa “normal”: o espabilamos o se nos comen!!

Así pues, la próxima vez que te plantees la transformación digital de tu compañía piensa primero en los cimientos sobre los que debes consruir ese cambio:

• una cultura de colaboración
  
• una organización transversal que huye de los silos verticales
  
• equipos multidisciplinares
  
• flujo de valor
  
• aprendizaje
  
• automatización
  

En definitiva, Lean-IT, Agile y DevOps o lo que nosotros llamamos Agile IT Management.

Y esos cimientos debes construirlos rápido: los high performers llevan años haciéndolo así que no te van a dejar respirar.

No tardes y empieza ya!

La X Muda

Esta vez me pilló viajando. El dia 23 de Marzo me pilló en uno de esos viajes al otro lado del mundo que hago al menos una vez al año y que me sirven para despejarme del ruido cerebral que produce la civilización y la gran ciudad.

¿Que qué pasa el 23 de Marzo?

Pues este año, concretamente, el 23 de Marzo supuso el décimo aniversario de este blog. 10 años contando historias vividas día a día y que ahora, cuando las miro en perspectiva me muestran en gran medida cómo ha sido mi evolución personal en el mundo del Gobierno y la Gestión de las Tecnologías de la Información…

Aqui tienes la primera entrada de este blog: La CMDB Federada (qué ojo!! jeje)

Pero no me pilló desprevenido! Ya sabía que me iba a pillar de viaje así que antes de salir me compré un bloc y un boli Bic de cuatro colores y armado con semejante despliegue de tecnología me fui al paraiso Zen a pensar en el contenido de este post de celebración de una década de GobiernoTIC.

La X Muda

Una de las obsesiones incorporadas en los sistemas de producción basados en Lean es la detección y eliminación sistemática de las ineficiencias. Esas ineficiencias se clasifican fundamentalmente en tres grandes grupos:

• Muda: tipos de trabajo o acción que resultan en derroche de tiempo, esfuerzo, recursos, ...
  
• Mura: grupo de las ineficiencias producidas por falta de homogeneidad en las entradas, en las tareas, en las personas, ...
• Muri: grupo de las ineficiencias que se producen por el stress o sobretensión en personas y medios de producción

Taiichi Ohno hizo un gran trabajo clasificando las diferentes tipologías de MUDA en lo que posteriormente hemos ordenado alrededor de las letras del acrónimo TIMWOOD (acrónimo que los profesores utilizamos para facilitar que los alumnos que están comenzando su recorrido no tengan problemas en recordar cuáles son los 7 tipos de muda):

• Transportation
  
• Inventory
  
• Motion
  
• Waiting
  
• Overprocessing
  
• Overproduction
  
• Defects
  

Más adelante, en el libro The Toyota Way, Jeff Liker menciona la octava muda como el no aprovechar la creatividad, el talento o la sabiduría de los empleados.

Con el paso de los años he ido acostumbrando el ojo a ver y a detectar los ocho tipos de muda, al tiempo que he ido desarrollando la capacidad de enseñar a clientes, compañeros y alumnos a detectarlas; sin embargo, poco a poco iba apareciendo la necesidad de ampliar esta lista. Si nos fijamos bien, veremos que los ocho tipos de muda tienen que ver con acciones que realizamos, con actividad no provechosa (especialmente las 7 primeras, que están muy relacionadas con los procesos productivos).

Sin embargo, no aparecen en esta clasificación mudas que tengan que ver con el cómo se hacen las tareas, desde el punto de vista humano y no del procesos; desde el punto de vista de los “soft-skills”.

Justamente cuando repasaba la historia del blog y veia que se habían cumplido 10 años de GobiernoTIC mi reflexión era ¡¡Vaya… ahora en la distancia me doy cuenta de que no tenian que haber sido 10 años de Gobierno TIC sino de Gobierno de las Personas que Trabajan en las TIC!! ¡¡Cómo no me dí cuenta en las primeras conferencias de Paul Wilkinson en el 2005!!

En más de una ocasión me he encontrado actividades de tipo VA que se ejecutaban de una forma muy cuestionable y el problema no está en ninguna de las letras del TIMWOOD, sino que la cosa tiene que ver con la forma en que la información, los mensajes o las órdenes fluyen en la organización.

No es un problema de delegación ni de matrices RACI sino que es más profundo: hay organizaciones en las que cuesta mover la rueda simplemente porque a cada impulso que se da, aparecen palos en las ruedas, falta de grasa, tensiones, dudas, protestas… aspectos culturales que nos llevan a declarar la X MUDA: LA FRICCION

Entiendo por fricción toda aquella fuerza contraria al correcto fluir del valor hacia el cliente. Son fuerzas contrarias al flujo definido y no se representa por actividades NVA o NNVA, no son actividades sino fuerzas.

Podemos ver ejemplos de fricción cuando se pide hacer una tarea y se te activa la Tercera Ley de Newton: "Actioni contrariam semper & æqualem esse reactionem” o sea "Con toda acción ocurre siempre una reacción igual y contraria"

O cuando hay que actuar y primero tenemos que dar diez mil explicaciones porque la persona no acaba de estar convencida de que esa sea la linea de acción correcta.

O cuando Newton vuelve a actuar, pero esta vez en forma de su primera Ley: “Todo cuerpo persevera en su estado de reposo o movimiento uniforme y rectilineo a no ser que sea obligado a cambiar su estado por fuerzas impresas sobre él"

Básicamente, encontraremos que hay equipos cohesionados en los que el trabajo se ejecuta de forma suave, coordinada y sin fricciones… mientras que hay otros equipos en los que las fricciones son las que ocasionan el derroche de energía, tiempo y recursos. No tiene que ver con las tareas que se desempeñan sino con la convivencia, feeling, liderazgo y comunicación que hay en el equipo.

Y de la misma manera que desarrollamos patrones y antipatrones para enfrentarnos a los ocho tipos de Muda, hacemos ejercicios para “aprender a ver” las ineficiencias en nuestro flujo e incorporamos todas las observaciones en el tablon de posibles entradas para un Kaizen o un Kaizen Diario, debemos incorporar la friccion dentro de nuestras observaciones, analizar qué es lo que la causa y tratar de buscar soluciones, sólo que generalmente las contramedidas a desplegar tendrán más que ver con la cultura de equipo o la gestión del cambio que con los procesos, procedimientos o métodos de trabajo.

… y así es como yo veo la Décima forma de Muda: la FRICCION, que hace que incluso un proceso perfecto se ejecute de manera ineficiente, que no se ve fácilmente, que siempre tenderemos a encubrir y que no acabo de imaginarme cómo representar en un Value Stream Map…

Umbrales de Tolerancia - Aprendiendo a delegar

Un par de semanas después de hacer el taller que contaba en el post anterior pasé por otro cliente en el que estoy trabajando temas relacionados con la Gestión de Servicios. Empezamos a hablar y no se muy bien cómo, pero salió (de nuevo) el tema de la delegación y el reparto de responsabilidades, así que me saqué las cartas de la mochila y le enseñé a mi interlocutor lo divertido que es jugar a la baraja.

Siempre que sacas algo que se parezca a jugar en un entorno serio a la gente le cambia la cara… y es muy satisfactorio! Cómo me gusta sacar al niño que hay escondido en los mayores!

La primera impresión fue del tipo “humm que interesante! cómo mola!”, pero en cuestión de minutos la siguiente reacción fue “aquí eso no funcionaría ni de coña. Los jefes cambian de opinión constantemente y aunque te hubieran delegado una faena, seguro que cuando la vean te van a encontrar faltas y la vas a tener que hacer de nuevo”.

Que cosa más común, no?

Tenía una amiga que incluso lo había institucionalizado: metía errores adrede en los informes para que sus jefes los encontraran y los corrigieran, dejandola en paz con el resto del documento.

Ella añadía errores voluntariamente en su trabajo para saciar la sed de micro management de sus superiores y no tener que cambiar continuamente el trabajo realizado. Un honeypot para jefes!

La lección es rápida en este sentido: delegar es un trabajo bidireccional. Como manager tengo que hacer el ejercicio de “entregar” la responsabilidad del trabajo y la toma de decisiones, pero tambien tengo que hacer el trabajo de “recibir” los resultados. Como ejecutor de las tareas, tengo que hacer el trabajo de “aceptar” el trabajo y la toma de decisiones y el de “entregar” unos resultados adecuados.

Con el taller del Poker de Delegación hemos definido el terreno de juego al respecto de las decisiones y con la matriz RACI lo hemos hecho con respecto a las tareas… Desde el punto de vista del manager hemos organizado el DAR. ¿Y qué pasa con el RECIBIR?

Y aquí es donde entra en juego este nuevo concepto: los umbrales de tolerancia.

Todos tenemos unos determinados umbrales de tolerancia con respecto a la vida. Los hay que son más estrictos y los hay que son más laxos… los hay super minuciosos (los que viven en el 5º sigma de la vida) y los hay más relajados (los que viven en el 0,5 sigma de la vida).

Y tradicionalmente serán los del 5º sigma los que entran a saco en el micro management.

Si delegas un trabajo, tienes que estar dispuesto a que lo que recibas no sea exactamente lo que tu esperas. Habrá variaciones porque no es posible que hayas especificado exactamente tus deseos; habrá variaciones porque la forma de hacerlo del otro será diferente de la tuya; habrá variaciones porque la forma de entender el trabajo, la vida, la calidad o las herramientas del otro será diferente de la tuya.

Delegar significa estar dispuesto a recibir el trabajo diferente a como te lo esperabas.

Así que si delegas, prepárate a recibir cosas que no son exactamente lo que querias. Debes tener un margen de tolerancia adecuado. Si es demasiado abierto, no podrás asegurar que el trabajo se haga “a tu estilo” o “según las normas” o “de manera adecuada”. Pero si es demasiado cerrado, estarás machacando a tus compañeros permanentemente, repitiendo el trabajo y a la larga habrás minado totalmente la iniciativa y las ganas de autonomia de lagente.

Y cuando juegues al poker, el equipo pedira siempre un 1 - Tell, que básicamente significa “yo soy un mandado, a mi, lo que diga el jefe; las decisiones, que las tome él que para eso le pagan… que si no, siempre dice que lo hago mal y paso"

¿Has tenido un jefe del quinto sigma? ¿Cómo lo has vivido?

¡¡Pues no lo seas tu!!

PS:: Mis agradecimientos a Rui Soares por darme el empujón a comenzar a publicar mis primeros dibujos… quien sabe si no conseguiré algún día llegarle a la altura del tobillo! Obrigado pela inspiração!

Foto original de Krzysztof Puszczyński

Acordando niveles de delegación

A medida que han ido pasando los años y he ido madurando como profesional, más le he ido encontrando sentido a todo el discurso de Paul Wilkinson quien, desde que yo conozco esto de la Gestión de Servicios, ha sido monotemático: lo importante son las personas [y desde 2004 que sigo oyendo el eco de sus palabras "las personas, las personas, …”]

Asi que me centré en las personas, en su trabajo, en su forma de entender lo que debían hacer y en su forma de aprender; y eso me llevó a pensar en asuntos como la motivación, la implicación y la asunción de responsabilidades, al tiempo que me llevaba a investigar mejores maneras de enseñar a las personas lo que deben saber para hacer su trabajo.

Yo lo que necesito es que ellos tomen las decisiones sin que yo tenga que entrar al micromanagement, dijo el CIO.

Recientemente, haciendo un trabajo con un cliente, llegamos al momento en el que se debían repartir las responsabilidades sobre un determinado conjunto de actividades, así que sacamos nuestra matriz RACI y comenzamos a repartir letras a diestro y siniestro, en una reunión con los implicados para que tuvieran voz y voto sobre este reparto. De repente llegamos a un momento en que el CIO dijo algo así como “pero yo lo que necesito es que ellos tomen las decisiones sin que yo tenga que entrar al micromanagement” y vimos claramente que nos faltaba algo.No es lo mismo una tarea que una decisión.

Menos mal que uno es un hombre de recursos y que en G2 siempre estamos aprendiendo cosas nuevas “para cuando hagan falta”, así que tiré de agenda y concreté una siguiente fecha para hacer un taller de “Póker de Delegación”, práctica que aprendí en las clases de Management 3.0 de las manos de Gabri Prat, Angel Medinilla y Angel Diaz-Maroto.

La idea que subyace detrás de este taller es identificar el conjunto de decisiones que se deben tomar en un determinado ámbito de actuación (dentro de un proceso, dentro de una metodología, durante la ejecución de un proyecto, etc) y llegar con la dirección a un acuerdo al respecto del modelo de delegación que vamos a utilizar para cada una de ellas. A modo de ejemplo, podríamos acordar que la decisión sobre si realizar o no gastos no presupuestados y con un importe superior a 2.000 € será tomada por la dirección consultando opinión a la persona que solicita el gasto, pero la decisión sobre qué miembro del equipo debe realizar las guardias se deja al equipo sin necesidad de aportar más explicaciones. Desde la orden impuesta y sin derecho a réplica hasta la delegación absoluta de una decision hay todo un continuo de posibles modelos, que el juego de Póker de Delegación establece en siete niveles.

Llegar a este tipo de acuerdos es de gran utilidad para un equipo de trabajo: nos ayuda a poner claras las reglas del juego, a saber cuándo tengo que pedir permiso y cuándo no, a visualizar claramente cuál es el terreno de juego y a reducir el tiempo necesario y el desgaste asociado a las reuniones. Un gran invento!!

Fue un taller fantástico, discutimos los puntos de decisión y el grado de delegación que quería el equipo y el que quería el responsable y nos encontramos en casos en los que el responsable queria dar más “correa” de la que el equipo quería asumir, y casos en los que el propio equipo pedía más y mientras ellos jugaban a tomar decisiones yo los observaba y sonreía porque estaba viendo a un equipo hacerse mayor.

Ahora ellos tienen un terreno de juego delimitado, que les indica para las 10 ó 12 decisiones más habituales que deben tomar en el desempeño de sus tareas cuál es el modelo de delegación que han acordado. Y si quieren cambiar ese modelo, como ahora está objetivado, sólo tienen que volver a jugar una partida a las cartas.

La muerte del proyecto o el Nirvana del Flow

Voy en el AVE volviendo de impartir un (otro) curso de Lean-IT; eso significa que llevo al menos tres días en los que mi cabeza sólo tiene un foco: el flujo, el waste, el valor, la Voz del Cliente y todo ese tipo de conceptos. Cuando consigo ese nivel de concentración pasan cosas interesantes, las ideas van sedimentando y de tanto explicar conceptos, otros más grandes se van consolidando encima de ellos.

Cierro los ojos y veo el flujo, como Neo. Me imagino una situación ideal, el Nirvana del flow y tiene pinta de un equipo multidisciplinar y no demasiado grande, bien avenido, motivados y con muchas ganas de cumplir su misión: entregar un software a su comunidad de usuarios que funciona, que hace lo que necesitan los usuarios incluso sorprendiéndoles con algún que otro truco sacado del sombrero de chistera del product owner o del UX Designer. Un software que va a la velocidad que quieren los usuarios, que está disponible, que no falla y que además cumple con las normativas y mantiene la seguridad en regla.

Pero ese equipo, además, resulta que se mantiene en contacto permanentemente con los usuarios, con los clientes (no obligatoriamente son la misma persona!) y de esa manera va incorporando nuevas funcionalidades y características al sistema de información y a la manera en que la empresa tiene de ponerlo al alcance de los usuarios (nuevos modos de contratación, nuevos modelos de facturación, nuevas formas de estar en contacto con los usuarios o incluso nuevas maneras de ayudar a los usuarios a sacarle el máximo provecho a tan preciado software).

¿Y sabes cómo empezó todo? Con una pequeña idea que probaron en un laboratorio de esos semestrales que la empresa facilita: “la semana que viene hay hackaton”, dijeron… se juntaron uno de marketing con un desarrollador, un experto en usabilidad y uno que trabaja en soporte, pero que le encanta jugar los fines de semana montando contenedores Docker, dejaron salir todo lo que tenian dentro y plof! Apareció una primera idea que parecía que podía tener éxito.

Cuando terminó el hackaton le mostraron a sus compañeros el resultado (basto, poco pulido, pero con una pequeña muestra de funcionalidad) y hubo quien apreció la viabilidad, así que la empresa decidió apostar y les pidió que en dos meses tuvieran montado un MVP (un Producto Minimo Viable) que pudieran presentar para ver si lo lanzaban.

A medida que pasaba el tiempo la lista de ideas iba creciendo: algunos usuarios piloto daban su opinión y encontraban nuevas maneras de usar la aplicación, muchos de los desarrolladores soñaban con nuevas funcionalidades y habia quien pensaba que añadiendo integraciones hacia otras partes de la organización podrían sacarle mucho más partido.

El equipo no era novato y ya había vivido esas sensaciones antes. Hicieron un gran esfuerzo para mantener a raya el WIP. Había que morder el pastel a pequeños trozos, masticarlos bien y hacer la digestión. Poco a poco aquello que era apenas una maqueta pasó a ser un MVP y el MVP fue creciendo hasta convertirse en un producto a secas y al cabo de los años hasta le quitaron el logo de “Beta” que tenía en la home page.

Durante todo este tiempo, el equipo permaneció relativamente estable. Algunos entraban y otros salían, pero el indice de rotación se mantuvo relativamente bajo. Sí que es cierto que cuando el producto comenzó a tener éxito, las nuevas ideas entraban mucho más rápido de lo que les daba tiempo a fabricarlas, así que trabajaron duramente para automatizar todo lo que podían para que los ciclos de desarrollo-integración-pruebas-aceptación-despliegue fueran lo más cortos posible, eliminando siempre que podían los frenos al flujo y habilitando bucles de feedback para que todo el equipo supiera en cada momento qué estaba pasando.

También es cierto que a medida que el volumen de usuarios iba creciendo el tamaño de las actividades de soporte y apoyo era cada vez mayor. Compredieron que no era sostenible así que decidieron poner en marcha todos los mecanismos que les facilitaran reducir este tipo de demanda: tolerancia cero a la deuda técnica, controles de calidad cada vez más exhaustivos, un interfaz de usuario brillante y fácil de usar, formación a los usuarios y una magnífica base de conocimientos que permitiera a los usuarios resolver sus dudas. Para terminar de poner la guinda a este pastel se inventaron el rol de “usuario ayuda a usuario” y habilitaron un foro de soporte en el que unos usuarios ayudaban a otros, todo inspirado por un potente motor de gamificación que permitía ganar puntos que podrías canjear en algunos establecimientos colaboradores (si ayudas en el foro puedes conseguir un pase VIP para el estreno de Star Wars!!).

Han pasado algunos años, y el producto sigue en constante evolución: siempre hay ideas nuevas, siempre hay necesidades nuevas y siempre hay formas nuevas de interactuar con el cliente, de forma que el equipo no se ha disuelto, siguen siendo aquellos que empezaron junto con otros que se han sumado a la aventura.

Lo que más me sorprende de todo esto es el cambio tan profundo de mentalidad: nunca ha habido un proyecto… nunca ha habido una planificación a un año vista ni tan sólo un roadmap (porque el roadmap lo hacen los clientes en as reuniones quincenales que tienen con el product owner. El roadmap nunca es a 5 años vista, sino que es a dos meses vista).

Esta manera de pensar ha sido “la muerte del proyecto” tal y como lo conocemos. Ahora ya no hay proyectos en esta empresa; lo que hay son experimentos que dan lugar a un ciclo de vida de producto (o de servicio, según lo quieras mirar). El proyecto tiene fecha de fin: acaba cuando se termina de construir, pero en este modelo no terminamos nunca de construir.

Hay algunos en el equipo que empiezan a dar señales de aburrimiento. Tienen ganas de nuevas aventuras, pero no piensan en cambiar de empresa. ¡Ni locos!

El mes que viene hay hackaton. ¿Te animas?

———
REFERENCIAS:

Para los conceptos de MVP y experiementación para incorporar la innovación, Lean Startup de Eric Ries
Para los ciclos cortos de desarrollo y contacto con el cliente, Agile
Para la automatización de los ciclos de desarrollo-pruebas-despliegue, Integración Continua de Jezz Humble
Para la cohesion de equipos multidisciplinares (de verdad), DevOps y Agile. Gene Kim y Jezz Humble
Para la motivación de los equipos y mantenerlos a tu lado, Management 3.0 de Jurgen Appelo
Para aprender más de todo esto sin tener que leerte la Biblioteca de Alejandria, G2 Gobierno y Gestión de TI

La minería de procesos en acción

Hacía mucho tiempo que tenía ganas de hacer esto. Un pequeño vídeo que demostrara las capacidades de la minería de procesos de tal forma que te pudieras hacer una idea más clara de lo que se puede llegar a conseguir con este tipo de herramientas.

La semana pasada organizamos en G2 el evento Business Process Transformation, donde explicamos varias técnicas que nos permiten facilitar la mejora continua y la transformación de los procesos de negocio, y entre ellas hablamos de la minería de procesos. Un “problemilla” técnico deslució mucho una demo en la que tenía puestas muchas ilusiones así que he aprovechado un rato que tenía disponible para preparar este video. No soy un profesional de la edición, así que ha quedado como ha quedado… pero estoy seguro de que te activará las neuronas y te dejará imaginando cómo podrías aplicar este tipo de ideas en tus procesos.

Sólo una pista a tener en cuenta: cuando hablamos de “proceso” hablamos de “cosas que cambian en el tiempo”… así que podemos aplicar estas técnicas para analizar la evolución en el tiempo de cualquier concepto. Por ejemplo, mi compañero Jorge hizo una extracción de datos de LinkedIN para representar el mapa de cuáles son los caminos más exitosos para que una persona se convierta en CIO. Mi amigo Mariano quiere utilizarlo pasa estudiar el comportamiento de los alumnos en los MOOC de la Generalitat y yo lo he utilizado para estudiar el proceso de conformación de facturas o el factor de rotación de personal de un outsourcer del que no se mucho más que el rastro que dejan sus operadores en mis herramientas de gestión.

Abre tu mente, imagina cómo podrías utilizarlo y ponte en contacto con nosotros en http://www.gedos.es si quieres un piloto o una prueba con tus propios datos. ¡Aprender es gratis!

DevOps Foundations

Hace sólo un par de días se ha publicado el State of DevOps Report 2015, un estudio que cada año llevan a cabo los equipos de The IT Revolution y Puppet Labs. Este año se repiten algunas de las conclusiones a las que se había llegado en años anteriores, pero con unas cifras aún más espectaculares todavía: los dos primeros Key Findings son para dejar con la boca abierta a cualquiera:

• High-performing IT organizations experience 60 times fewer failures and recover from failure 168 times faster than their lower-performing peers. They also deploy 30 times more frequently with 200 times shorter lead times. Failures are unavoidable, but how quickly you detect and recover from failure can mean the difference between leading the market and struggling to catch up with the competition.
  
  
• Lean management and continuous delivery practices create the conditions for delivering value faster, sustainably. Manufacturing was revolutionized by the application of lean principles in the 1980s. Today, it’s IT’s turn to go lean. When you apply lean management and continuous delivery practices to software delivery, you get the same results — higher quality, shorter cycle times with quicker feedback loops, and lower costs. And the benefits don’t stop there: These practices also contribute to creating a culture of learning and continuous improvement, lower levels of burnout, and higher organizational performance overall.
  

La promesa de ser capaz de llevar valor al negocio en forma de funcionalidades TIC 30 veces más frecuentemente, 200 veces más rápido y de una forma 60 veces más estable no puede dejar indiferente a nadie; tampoco a nosotros. Así mismo, la importancia de la utilización de los princiios Lean-IT es algo que llevamos predicando desde hace años, así que esto tenía que pasar… estaba en nuestro roadmap.

Durante el último mes el equipo G2 ha estado trabajando a toda máquina para sacar adelante la primera edición de nuestra nueva incorporación en el catálogo de formación: el curso DevOps Foundations, una experiencia de 20 horas en la que combinamos unas 5 horas de teoría y le sacamos brillo a nuestros skills más techies con unas 15 deliciosas horas de práctica.

Este curso ha sido perfilado después de las conversaciones con varios clientes, en las que hemos discutido cuáles debían ser los puntos a tratar en los diferentes tipos de sesión formativa, con diferentes audiencias y diferentes necesidades. De esta manera, el paquete formativo ha quedado compuesto por tres elementos fundamentales:

• Una Keynote de una hora orientada especialmente al cuadro directivo, en la que explicamos los conceptos fundamentales y nos centramos en dar a conocer los beneficios para el negocio y para el equipo de IT del uso de estas prácticas.
  
• Una Master Class de cuatro horas dirigida al equipo de mandos intermedios, gestores de servicio, jefes de proyecto y líderes de equipo. En esta sesión explicamos los conceptos teóricos fundamentales y lanzamos los punteros hacia los diferentes cuerpos de conocimiento que nos permitirán comprender la esencia de las prácticas DevOps. 
• Un curso DevOps Foundations de cinco horas de teoría y 15 de práctica dirigido especialmente al equipo técnico (tanto de Desarrollo como de Sistemas u Operaciones ). En este curso las horas de teoría explican los patrones y antipatrones presentes en las prácticas DevOps, el por qué las cosas se hacen así y las líneas teóricas que dirigen estas prácticas. La parte práctica permite al alumno comenzar con un desarrollo simple (el foco no es el desarrollo ni las prácticas de desarrollo) e ir implementando en cada sesión los automatismos para cada paso, de forma que el último día habremos completado un ciclo completo de desarrollo en el que hemos automatizado:
  • El control de versiones
  • El Build
  • Las pruebas unitarias
  • La conexión con el repositorio de binarios
  • La gestión de la configuración
  • Las pruebas de integración
  • Las pruebas de carga
  • El despliegue al entorno de producción
  • La monitorización de los sistemas
  • La monitorización de la aplicación
  • La representación en el dashboard y la correlación con los despliegues

Hemos impartido la primera sesión y los resultados han sido muy buenos: los alumnos pudieron tener una visión global de las posibilidades que brinda el uso de DevOps, ganaron los conocimientos en fundamentos para comenzar a hacer sus primeras automatizaciones del pipeline de despliegue de aplicaciones y aprendieron las ventajas que nos aporta el adoptar una perspectiva de trabajo en la que los equipos de Desarrollo, Testing y Operaciones se alinean en un flujo común.

Queda abierta la puerta para el desarrollo de un curso de nivel Advanced en el que se expandan los conceptos de testing y QA, se incorpore todo el conjunto de herramientas de ticketing y la trazabilidad de acciones y podamos ver tambien el aprovisionamiento y aseguramiento de la calidad de elementos de infraestructura infraestructuras.

Tambien vemos necesaria la creación de un nivel FusionSM, en el que se exploren las adaptaciones necesarias en los modelos de gestión y gobierno actuales para el despliegue “sin sangre” de estas metodologías al tiempo que se discuta el impacto de la externalización y tipologías de contrato. ¿Cómo conecta esto con la ISO 20.000 o con mi modelo actual basado en ITIL(r)? ¿Qué impactos tiene sobre la Gestión de la Seguridad y el cumplimiento legal? ¿Qué ocurre cuando el desarrollo está externalizado?. Siguiendo los principios de la Gestión Lean de Servicios, lo haremos si hay demanda...

¿Te imaginas hacer un push a tu sistema de control de versiones y que tus modificaciones pasen a producción de forma automatizada, con los controles comprobados, cumpliendo los requerimientos de tu Gestión de Cambios y en poco tiempo? ¿Se lo imagina tu negocio?

… y no hay mucho más que decir…

1. Crear constancia en la mejora de productos y servicios, con el objetivo de ser competitivo y mantenerse en el negocio, además proporcionar puestos de trabajo.
   
2. Adoptar una nueva filosofía de cooperación en la cual todos se benefician, y ponerla en práctica enseñándola a los empleados, clientes y proveedores.
   
3. Desistir de la dependencia en la inspección en masa para lograr calidad. En lugar de esto, mejorar el proceso e incluir calidad en el producto desde el comienzo.
   
4. Terminar con la práctica de comprar a los más bajos precios. En lugar de esto, minimizar el costo total en el largo plazo. Buscar tener un solo proveedor para cada ítem, basándose en una relación de largo plazo de lealtad y confianza.
   
5. Mejorar constantemente y por siempre los sistemas de producción, servicio y planeamiento de cualquier actividad. Esto va a mejorar la calidad y la productividad, bajando los costos constantemente.
   
6. Establecer entrenamiento dentro del trabajo (capacitación).
   
7. Establecer líderes, reconociendo sus diferentes habilidades, capacidades y aspiraciones. El objetivo de la supervisión debería ser ayudar a la gente, máquinas y dispositivos a realizar su trabajo.
   
8. Eliminar el miedo y construir confianza, de esta manera todos podrán trabajar más eficientemente.
   
9. Borrar las barreras entre los departamentos. Abolir la competición y construir un sistema de cooperación basado en el mutuo beneficio que abarque toda la organización.
   
10. Eliminar eslóganes, exhortaciones y metas pidiendo cero defectos o nuevos niveles de productividad. Estas exhortaciones solo crean relaciones de rivalidad, la principal causa de la baja calidad y la baja productividad reside en el sistema y este va más allá del poder de la fuerza de trabajo.
    
11. Eliminar cuotas numéricas y la gestión por objetivos.
    
12. Remover barreras para apreciar la mano de obra y los elementos que privan a la gente de la alegría en su trabajo. Esto incluye eliminar las evaluaciones anuales o el sistema de méritos que da rangos a la gente y crean competición y conflictos.
    
13. Instituir un programa vigoroso de educación y auto mejora.
    
14. Poner a todos en la compañía a trabajar para llevar a cabo la transformación. La transformación es trabajo de todos.
    

William Edwards Deming, 1986

Dilbert y el Lean Sourcing

Hace un par de semanas fui a dar con esta tira de Dilbert que viene a resumir muchas de las tristes situaciones que se dan en los procesos de Outsourcing en los que he participado en los últimos años (que como puedes ver en esta conferencia que di para la ATI en 2012 es uno de los temas candentes en G2). La tira, además de hacerme reir un rato, me hizo reflexionar y poco a poco fue saliendo este texto que resumo aquí en forma de dos cartas.

---

Querido Proveedor:
Yo se que a veces soy un poco caótico y que no acabo de establecer un paquete claro de prioridades, pero es que las cosas son así… la vida en los negocios, como tú ya sabes, no es estable ni tranquila sino que es cambiante y variopinta. Por esta razón no acabo de ver claro que podamos cerrar un acuerdo rígido de colaboración a 5 ó 7 años vista donde se describa con detalle todo lo que vamos a hacer, los niveles de servicios que me prestarás y las tarifas de precios que me cobrarás; no veo que así tú te puedas ganar la vida mientras que yo pueda tener las TIC que deseo para mi empresa.

¿Cómo vamos a plasmar en un contrato las necesidades que tendré dentro de dos años, si ni tú ni yo sabemos lo que necesitaremos dentro de seis meses?

En realidad, lo que a mi me gustaría es que entiendas por qué te escojo a tí y no a cualquier otro de los que han presentado ofertas respondiendo a la RFP que hemos publicado. No es por el precio, ni porque sea “más bonita”. Es porque me transmite confianza; la confianza en que me vas a acompañar durante los próximos siete años, en que vas a poner los intereses de mi compañia por delante de una visión cortoplacista, de la venta y del margen; la confianza en que te vas a preocupar por sentarte conmigo para discutir por dónde vamos, cuáles son las mejores líneas de trabajo, cuáles son mis necesidades y cuáles tus preocupaciones.

Yo estoy eligiendote a tí frente a un departamento de IT propio, y en ese gesto estoy arriesgando mi negocio para ponerlo en tus manos. Eso lo hago porque tengo la confianza en que tú, como la gran compañia a la que representas, sabrás estar a la altura, podrás proporcionarme los conocimientos, los servicios, las habilidades y sobre todo la experiencia que yo necesito al ritmo que yo necesito (que es más rápido de lo que tarda mi equipo IT interno en aprender o en ganar la experiencia).

A cambio, espero que podamos establecer un modelo en el cual tú también te ganes la vida, obtengas tus margenes de beneficios y no te ganes la vida regateando ni haciéndome trampas que lo único que harán será minar nuestra relación. Espero también que puedas destinar parte de los ingresos a potenciar el personal que necesitaré el día de mañana. Para eso espero que te preocupes de conocer cuáles serán mis necesidades el día de mañana.

Y de esa manera no serás un proveedor más, serás mi compañero de viaje y yo te preferiré a ti frente a otros porque tú me conocerás y me comprenderás y esa será tu gran ventaja competitiva.

Querido proveedor, me pongo en tus manos. ¡No me falles!

---

Querido Cliente:
Lo que me planteas es muy atractivo, porque para mi es muy complicado establecer de partida un modelo de precios y de servicios que satisfaga tus necesidades (desconocidas en un futuro próximo). Entiende, por favor, que estamos en un momento de bidding y por lo tanto estamos más preocupados por asegurar la venta que por asegurar la prestación: para que exista la posibilidad de prestar los servicios primero es condición indispensable haberle ganado a la competencia y por esta razón en los negocios “normales” tenemos que apretar mucho en esta fase.

¿Qué te parece si por un momento nos olvidamos del dinero? Al fin y al cabo, el importe que tú pagues por los servicios te parecerá barato o caro en función de dos factores fundamentalmente: el mercado (cuánto cobran otros por un servicio similar) y el valor aportado (el valor que aportan mis servicios a tu negocio).

Si establecemos un marco de colaboración fuerte, con interacciones potentes entre tu negocio y mi compañía habremos eliminado el factor “mercado”, pues no habrá en el mercado otro que te ofrezca un servicio similar; al mismo tiempo espero que el valor sea muy superior al habitual gracias a que entenderemos tus necesidades, te podremos orientar en las líneas de acción y podremos entregar rápidamente los recursos que nos pidas pues podremos prever con cierta antelación tus demandas.

Pero para eso te necesito a ti, querido cliente. Porque yo necesito que tú no pienses que “hacer un outsourcing va a arreglar todos tus problemas” y que no te creas que puedes olvidarte de mí. Yo necesito que me cuentes tus problemas, que me expliques qué necesitas y que juntos diseñemos una informática adecuada para tus necesidades, en la que ambos nos sintamos responsables del producto final que le entreguemos juntos a tu negocio. Necesitamos que no haya “unos” y “otros”, sino que trabajemos como un equipo para entregar servicios TIC de calidad.

Sé que no te puedo pedir estabilidad, pero tampoco puedo trabajar apagando fuegos permanentemente… tú tampoco puedes, en estos momentos en que tienes tu departamento propio; no pienses que somos superhéroes que podemos con todo. Hay recursos, hay flexibilidad, pero también hay una capacidad limitada. Hablemos. Prioricemos juntos y tratemos de sacar adelante el máximo de trabajo con las capacidades y herramientas que tenemos.

Y ahora que más o menos tenemos claro qué queremos ambos, tendremos que sacar el tema del dinero: ¿cómo podríamos poner un precio al trabajo realizado? Tenemos que buscar juntos unos drivers económicos que sean justos para ambos: tú quieres valor, agilidad, experiencia, conocimientos. Yo te los puedo dar, pero a cambio quiero beneficios, ganarme bien la vida y poder satisfacer a mis accionistas. Si no lo hago así, no será sostenible y no podré pagarle al personal los sueldos que se merecen y será todo un desastre. Debemos trabajar juntos para encontrar un modelo que sea bueno para ambos, sostenible en el tiempo; que te permita a tí descontarte las mejoras que podamos crear juntos y me permita a mí ampliar el volumen de negocio que tengo contigo.

Prometo no hacer trampas en el corto plazo, ganarme tu confianza, ampliar cada vez más el abanico de servicios que hacemos para tí y mantener unos niveles de facturación razonables (al tiempo que la mejora continua, la innovación, la automatización y la ampliación de negocio me permite garantizar unos márgenes cada vez mayores).

Estoy seguro de que podemos crear una gran relación entre ambas compañías, para eso necesito que no me escojas por ser el más barato en las ofertas, sino por ser el que mejor te puede satisfacer las necesidades actuales y futuras al tiempo que te transmite la confianza necesaria.

Lo esencial es invisible a los ojos

A mediados de los años 70 yo cursaba 3º de E.G.B. Carmen, la profesora que nos había acompañado desde primero, se despedía de nuestra clase deseándonos a todos un gran futuro con una gran sonrisa y para que no nos olvidásemos de ella jamás, nos regaló a cada uno de sus alumnos un ejemplar de El Principito con una dedicatoria especialmente pensada para cada uno de nosotros.

Ese libro me ha acompañado toda mi vida y la historia ha ido variando de interpretación a medida que yo iba creciendo y ganando en comprensión del mundo que me rodea; al principio me llamaba mucho la atención la figura de las boas abiertas y cerradas y cómo era cierto que los mayores no entendían las cosas que les contábamos pequeños porque están tan influenciados por su mundo de mayores y han perdido la habilidad de imaginar que los pobres no entienden nada…

Luego me convertí en profesor y me di cuenta de que las cosas difíciles hay que explicarlas como las explican los niños. Por eso mis clases están llenas de anécdotas, ejemplos y preguntas: tengo que conseguir que los adultos que tengo delante vean el elefante dentro de la boa y no un simple sombrero (a veces, otros profesores más serios ven mis clases y me advierten de que quizás mis alumnos tan serios no van a estar muy cómodos con mi forma de dar clases, pero en general consigo despertar al niño que todos llevan dentro)

Pasaron los años y fui a parar a la mejora continua, los procesos y el uso de LeanIT y aquí volvió a entrar El Principito en acción. Uno de los principios fundamentales del pensamiento Lean es aprender a ver el flujo de valor. El libro que describe el método para representar el flujo de valor (Value Stream Mapping) se llama Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA y ya nos deja claro cuál es el reto

Siempre que hay un producto para un cliente, hay un flujo de valor.
El reto consiste en verlo

…y eso que John Shook, Mike Rother, Jim Womack y Daniel Jones venían del mundo de la fabricación, donde los materiales se mueven, son tangibles y con un poco de paciencia puedes ver cómo fluyen! Quizás por eso pusieron tanto empeño en recordarnos que es un reto: lo que tenemos que ver no es un flujo de materiales sino un flujo de valor.

El flujo de valor en IT

Cuando pretendemos aplicar los métodos de gestión Lean a las tecnologías de la información nos encontramos con que algunos aspectos son esencialmente diferentes al mundo de la fabricación. Uno de estos aspectos diferentes es el concepto de Servicio IT: el servicio es intangible, es invisible, se crea en el momento de consumirse… tiene muchas características que hacen que ver ese flujo sea un reto mucho mayor aún si cabe.

Y cómo vemos y representamos el flujo de valor?

Uno de los personajes que más impactan de El Principito es el zorro. El zorro pide al Principito que lo domestique, pues eso significa crear vínculos y hacer que ambos sean importantes el uno para el otro; pasa el tiempo y el Principito se debe marchar y en la despedida el zorro le dice

–Adiós –dijo el zorro–. He aquí mi secreto. Es muy simple: no se ve bien sino con el corazón. Lo esencial es invisible a los ojos.

Hay varias técnicas para hacer aflorar aquello que es invisible a los ojos, para visualizar el flujo de valor y para representarlo de una forma visual que sea comprensible para todos. La primera, las más utilizada, la que nos enseñan John Shook y sus compañeros es la del Value Stream Mapping:

1. Identifica el flujo que quieres representar. Es decir, pon foco, no trates de representar *todos* los flujos de valor de tu departamento de golpe, que no podrás. Selecciona algo pequeño para empezar, una petición de servicio, por ejemplo. (puntero mental: aquí entra en juego el concepto S+C de Rob England)
   
2. Reúne a un equipo de personas con representantes de las diferentes unidades organizativas o grupos de trabajo por los que pasa la ejecución de este flujo. Si puedes incorporar a un cliente también, mejor que mejor.
3. Provoca un diálogo constructivo en el equipo con el fin de descubrir qué tareas y en qué orden hacemos cada uno para completar la petición (demanda del cliente).
4. Identifica qué tareas debe de hacer el cliente para poder hacer la petición (pull) y qué momentos de la verdad hay durante toda la ejecución de la petición
5. Ten la mente abierta, deja que todo el mundo se exprese y no intentes arreglar nada en ese momento: ahora estamos descubriendo el flujo, no analizándolo ni mejorándolo.
6. Cuando hayas terminado, da un paso atrás y míralo todo con perspectiva: ¿Dónde empieza? ¿Es ahí donde debe de empezar? ¿Dónde acaba? ¿Estás seguro? ¿Hay demanda fallo adicional? ¿Cuál?
7. Repite desde el punto 3 para dar un par de vueltas más

En realidad hacen falta algunos pasos más, porque después de representar el flujo de valor querrás analizarlo y para eso te harán falta más datos, sobre todo de cantidades: cuántas veces hacemos las actividades, cuántas repeticiones, cuánto tiempo tardamos, cuántos recursos hay que lo puedan hacer, cuánta variabilidad, cómo son los patrones de demanda… es decir, tendremos que llenar de números el mapa del flujo que acabamos de hacer, y esos números no son nada fáciles de conseguir.

Aquí entra en juego el método CDO de estimación de valores: piensa en el indicador que quieres calcular. Visualízalo en tu mente. Extiende el brazo todo lo que puedas. Abre la mano separando los dedos y ahora mueve la muñeca de forma oscilatoria mientras piensas “mmmmhhh más o menos soooon cuarenta!”. CDO, son las siglas de los Cinco Dedos Oscilantes (Gracias Jordi Cirera por enseñarme tan magnífica técnica!).

Si no queremos trabajar con estimaciones, entonces tendremos que acudir a sistemas de medicion, pero la gran mayoría de veces nos encontraremos con que no tenemos sistemas de medición adecuados para las tareas que estamos intentando analizar y aquí es donde viene la debacle: si tengo que montar sistemas de medición cada vez que quiera mejorar algo, va a ser más caro remedio que la enfermedad (al menos a corto plazo, claro!) y por eso es por lo que los que trabajamos en Lean utilizamos métodos de estimación y conceptos como el del valor de la información para descubrir qué variable de las que componen nuestro modelo de estimación influye más en la reducción de la incertidumbre.

En los últimos años, ha entrado con fuerza una nueva disciplina en el mundo del análisis de la información: la Minería de Procesos. Se trata de un conjunto de técnicas que tienen su origen en la Universidad Tecnológica de Eindhoven y que nos permite realizar algo parecido a una ingeniería inversa de los procesos utilizando para ello la información de logs y trazas que su ejecución deja en los Sistemas de Información.

Partiendo de estos logs, la primera etapa de la minería de procesos es el Descubrimiento del modelo de proceso, utilizando conceptos tan alucinantes como el algoritmo Alfa o el Heuristic Miner.

Una vez que hemos descubierto el modelo del proceso a partir de las trazas, viene el momento del Enriquecimiento: tenemos toda la información al respecto de quién hace las tareas, cuánto se tarda en ejecutar, cuánto tiempo están las tareas en las colas, qué tipología de tareas, en qué momento se crean los casos y cuánto tiempo tardan… lo tenemos todo, y la minería de procesos es capaz de incorporar toda esa información en el mapa del proceso de forma que puedes comprenderla rápidamente, e incluso puedes hacer un Replay y volver a ver la ejecución de cada uno de los pasos de tu proceso.

Cuando ves un mapa de estos, ocurre que de repente ¡Plaf! lo esencial se hace visible a los ojos… en realidad no estamos mirando con el corazón sino que hemos utilizado las matemáticas para hacer visible lo que hasta el momento sólo eran sensaciones o suposiciones.

La minería de procesos nos abre las puertas a entender cómo funcionan en realidad nuestros procesos, a descubrir los puntos de mejora, las características de cada uno de los pasos del proceso para saber si son estables, capaces, de calidad… Nos abre la puerta a una mejora continua objetiva e incluso a poder demostrar fácilmente si nuestras iniciativas de mejora continua realmente están dando resultados o no, en base a analizar el proceso antes y después de los cambios.

Las posibilidades son enormes, sólo hay que abrir la mente y ver con el corazón para que no se te escape lo esencial.

Más Información

Talleres de Mejora Continua en G2
Monografía sobre Minería de Procesos en la revista Novática (ATI)
Conferencia “Buceando en Standard+Case” en el congreso TFT13
Conferencia sobre el uso de la Minería de Procesos en la Auditoría de Sistemas de Información (ISACA)
Entrevista en Flux Capacitor sobre la presencia en el Process Mining Camp
Conferencia “Process Mining and Lean” en el Process Mining Camp 14
Artículo “Las posibilidades de uso de la Minería de Procesos en ITSM”, finalista para el premio Novática 2013

IT4IT: L’enfant terrible

En verano de 2014 The Open Group dió a conocer su nueva propuesta de modelo de arquitectura para las TIC llamada IT4IT. Posiblemente no me hubiera llamado mucho la atención si no hubiera sido porque el anuncio de publicación me llegó del mismísimo Charlie Betz, persona a la que sigo asiduamente desde hace al menos unos diez o doce años y autor al que admiro y respeto profundamente. Si lo anuncia Charlie, la cosa es importante!

La primera imagen que le llevas de IT4IT ya es de por sí impactante: un modelo de cadena de valor al estilo Porter con las piezas fundamentales que componen el negocio de las TIC

Eso llama mucho la atención, pero lo más impactante de todo es lo que se muestra en la parte superior: las cadenas de aportación de valor, los cuatro grandes flujos:Strategy to Portfolio, Requirement to Delivery, Request to Fulfill, Detect to Correct. Son las cuatro grandes áreas en las que podemos clasificar el trabajo que se hace en un departamento de IT, los cuatro grandes flujos de valor, el pipeline que todos desean automatizar y mejorar… es una aportación inocente, que muestra las TIC ordenadas en cuatro grandes flujos, pero lo cambia todo:

a) El concepto de servicio sigue existiendo junto con el del ciclo de vida, pero aparece sólo si tu quieres (inicialmente está diseñado para unas TIC orientadas a servicios, pero si lo tuyo no es la orientación a servicios, puedes mover en el pipeline aplicaciones, infraestructuras, o lo que quieras: hablé con un señor holandés que lo utiliza para el uniforme y equipamiento de la policía)

b) Está pensado para ser un modelo normativo: plantea una arquitectura para “el negocio de las TIC”, de la misma manera que eTOM lo plantea para el negocio de las Telco, BIAN para la banca o ACORD para los seguros. La arquitectura estará detallada en niveles, llegando incluso al nivel de atributos y tipos de dato.

c) Si se consigue su adopción, se habilitará un mecanismo increiblemente potente para normalizar el trabajo, integrar procesos multicompañia, evaluar proveedores de sourcing, definir aplicaciones o “ERP para IT”… Piensa en las posibilidades que te daría que el concepto de incidencia fuera homogéneo entre todos tus diferentes proveedores de soporte.

d) Es un modelo con Lean, Agile y DevOps “en el ADN”. Ha nacido pensado para eso

Más tarde, en Noviembre de 2014 me escapé a las jornadas CAS2014 en las que pude hacer un ejercicio importante de inmersión en el mundo de los agilistas, les observé, atendí a sus presentaciones y saqué algunas conclusiones; y una de estas conclusiones fue precistamente “hace falta una teoría unificadora que permita a las TIC ver el flujo completo. Todos necesitamos ver el pipeline”. Y eso me llevó a continuar mirandome IT4IT con muchísimo respeto: no era un modelo más de esos que hay cientos; esta vez hay algunos detalles diferentes.

Durante el congreso gigaTIC15 tuve la oportunidad de presentar junto con Walter Henríquez una charla sobre la evolución que ha vivido Cuatrecasas Gonçalves Pereira después de cuatro años de utilización de técnicas Lean en su centro de soporte, y sobre los retos que se le plantean a la organización en un futuro próximo. La utilización algunos de estos conceptos de IT4IT me vino de perlas para explicar algunas de las problemáticas que tienen Cuatrecasas y cuáles serán las vías de mejora en el futuro:

a) La dedicación del personal a diferentes cadenas de valor sin estar formalizada esta dedicación, hace que se le presete poca (o demasiada) atención a los flujos segundarios

b) La escasa participación transversal de las diferentes unidades organizativas a los diferentes flujos hace que la visión sea de silos en lugar de transversal (pero no organizados alrededor de procesos tradicionales, sino agrupados entorno a cadenas de valor, todo muy Lean)

Finalmente, esta semana se ha celebrado en Madrid el congreso Enabling Boundaryless Information Flow, organizado por The Open Group y que contaba con un track especial de IT4IT en el que presentaba el mismísimo Charlie Betz.

¡¡Cómo me lo iba a perder!!

Así que me planté en Madrid, atendí a todas las presentaciones de IT4IT en las que pude descubrir algunos detalles que explicaré más adelante y por si fuera poco pude asistir como invitado especial a las reuniones de los grupos de trabajo de IT4IT en los que se trataron aspectos del futuro del modelo de arquitectura que no te puedo contar porque me hicieron firmar un acuerdo de confidencialidad, así que lo único que puedo decir de lo que aprendí por la tarde es que en Octubre habrá magníficas noticias.

El servicio TI

Hace unos cuantos días que en un foro del underground ITSM se está discutiendo al respecto de la definición del concepto de Servicio TI. Parece mentira que a estas alturas tengamos estas discusiones, pero la verdad es que eso de “un medio de darle valor al cliente, bla bla bla” lo ha hecho un poco difícil, al tiempo que “un sistema de información que soporta un proceso de negocio” era demasiado simple.

La discusión viene de lejos… si bien en este caso todo empezó por esta entrada de blog que escribió Aale Ross ( http://pohjoisviitta.fi/itsm-from-the-top-of-the-world/improving-itil-3-forget-the-service-lifecycle/ ) también han salido a relucir otras discusiones como esta ( http://www.itskeptic.org/what-service) o esta otra mucho más reciente (http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID=276434337&gid=68677&goback=.nmp_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1_%2A1#commentID_null )

Esto no hace más que demostrar que la comunidad de Gestión de Servicios TI no se acaba de poner de acuerdo al respecto de lo que es un servicio TI.

Ya me iba a casa, incluso tenía el PC apagado! pero de repente se me encendió una idea que no quería dejar de compartir aquí. ¿Y si lo miramos desde otro punto de vista?

En castellano la palabra “servicio” tiene otras acepciones… ¿No? Pero no es a eso a lo que yo me refiero. ¿Quien puso el WC ahí? ¿Quién lo mantiene?

Si pensamos como usuarios, la definición del servicio está clara… y las expectativas también: espero que funcione, que desagüe, que no huela mal, que esté limpio… características del servicio.

Si le preguntamos al departamento de mantenimiento de edificios qué servicios ofrece al respecto de los lavabos, seguramente me dirá que “limpieza”, “desinfección”, “provisión de fungibles”… es decir nada de lo que yo como usuario entiendo como servicio.

Lo que ellos hacen son actividades orientadas a asegurar que el WC está y se comporta como yo (usuario) espero: lo limpian, lo desinfectan, lo mantienen en correcto funcionamiento… se preocupan de que el WC entregue UTILIDAD y GARANTIA, pero es servicio NO ES EN SI MISMO el trabajo de asegurar la utilidad y la garantía.

En Informática nos pasa lo mismo: nos empeñamos en decir que nuestros servicios son “el mantenimiento de aplicaciones” o “la administración de sistemas”, cuando en realidad eso son actividades que hacemos para asegurar que los sistemas de información entregan utilidad y garantía.

Siguiendo por esta línea, me quedo con la definición de servicio IT que llevo utilizando mucho tiempo: un sistema de información gestionado (osea, con todas esas actividades realizadas por personas a su alrededor orientadas a asegurar que se entrega la utilidad y la garantía).

Un sistema de información, no una aplicación.

Con visión de usuario. Outside-In.