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

Mi ruta en el Vision15

Ya está aquí el Vision15, la cita anual de todos los profesionales del mundo de la Gestión de Servicios; y con el congreso, la dura tarea de tener que seleccionar de entre la abundancia de ponencias aquellas que más me interesan para tener la agenda lista y no perderme nada.

Este año la cosa ha estado difícil y he tenido que tomar decisiones, dejando fuera de la agenda algunas ponencias que realmente me interesan, pero nadie dijo que la vida fuese fácil!!.
También he decidido dejarme algunos huecos libres: habitualmente me pasa en este tipo de congresos que tengo ganas de cruzar impresiones con gente o que alguien me pide un rato para intercambiar ideas y resulta que no puedo porque la agenda está a tope.

¿Que tienes ganas de que hablemos de algo concreto?
Pues me he dejado cuatro slots el primer dia y dos el segundo para comentar.

¿Que quieres una demo de Process Mining? 
Pues tenemos tiempo más que de sobras para mirarlo con calma.

¿Que quieres que nos tomemos una cerveza mientras hablamos de un plan de formación en DevOps? 
Tenemos sofás y tiempo. Yo pago la cerveza ;-)

El primer día a las 12:20 es mi ponencia sobre el uso de la Minería de Procesos en ITSM; luego por la tarde, a las 17:10 es la ponencia de Telefónica explicando su caso de éxito en el uso de la Minería de Procesos y el viernes a las 10:20 es la ponencia sobre integración de herramientas ITSM multifabricante, un caso muy interesante de integración en escenarios de outsourcing multiproveedor en el que G2 ha tenido una participación importante.

En fin, sin más preámbulos, esta es mi selección.

Jueves 12:
9:45 - 10:20 PP.1 El IT como bróker de Servicios
10:20 - 11:00 PP.2 Hacking Físico
11:00 - 11:40 CAFE
11:40 - 12:20 <<LIBRE>>
12:20 - 13:00 Posibilidades de uso en la minería de procesos 
13:00 - 13:40 Cómo conseguir un SLA adaptado
13:40 - 14:20 Ingeniería del Éxito
14:20 - 15:30 COCTEL
15:30 - 16:10 <<LIBRE>>
16:10 - 16:50 ¿Cómo es una organización Ágil?
16:50 - 17:10 <<LIBRE>>
17:10 - 18:00 Ojo de Halcón
18:00 - 18:40 Influencia del Factor Humano
18:40 - 18:50 Resumen jornada (SALÓN ATOCHA)
18:50 - 20:00 <<LIBRE>>

Viernes 13:
09:00 - 09:40 PP.3 Recuerdos del futuro presente
09:40 - 10:20 Aplicación de tecnologías analíticas
10:20 - 11:00 Integración herramientas ITSM multifabricante
11:00 - 11:30 CAFE
11:30 - 12:10 Hacia la excelencia con Lean(Out)sourcing
12:10 - 12:50 Cuarto y mitad de gobierno, por favor.
12:50 - 13:30 ITSM2020 nuevo modelo para la gestión de negocios
13:30 - 13:50 <<LIBRE>>
13:50 - 15:00 PP.4 PANEL DE EXPERTOS/MESA DEBATE
15:00 - 15:30 AC.4 Entrega de galadornes y cierre del Congreso
15:30 - 16:30 <<LIBRE>>

¿Cuál es tu selección? ¿Me pierdo algo que no debería?

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

Jugando a Lean Lens con el itSMF

Una de las últimas adquisiciones de G2 en materia de juegos didácticos ha sido Lean Lens, un juego creative commons desarrollado por Andrea Darabos y Bazil Arden en 2014 y que presentaron en las jornadas CAS2014 que se desarrollaron en Barcelona el año pasado.

El juego es una representación en forma de obra de teatro en la que hasta 9 grupos de personas interpretan diferentes escenas de la vida cotidiana de las TIC, desde las conversaciones con Negocio para discutir nuevas funcionalidades en la web hasta la resolución de correctivos afectando a diferentes partes de la aplicación. En cada una de las escenas intervienen diversos roles (el Stakeholder, el developer, el tester, el project manager, el tecnico de soporte, etc.) e incorporamos un rol especial en cada grupo que hace las labores de observador. El observador tiene como misión analizar cómo se desarrolla la escena e identificar los diferentes tipos de waste que se generan durante la actividad, de forma que posteriormente se discute con el equipo y se llega a un consenso sobre los derroches identificados.

Cuando se han escenificado todas las escenas, los observadores rellenan el “Mural del Waste”, que hace patente la presencia de los 8 tipos de derroche en cada una de las etapas de la cadena de valor de las TIC, al tiempo que se plantean las diferentes soluciones y formas de mejorar el escenario propuesto.

El juego facilita la comprensión de los diferentes tipos de derroche, la colaboración en equipo y sobre todo demuestra cómo un Mural del Waste puede convertirse en una herrmaienta importantísima (y visual) a la hora de potenciar las actividades de mejora continua dentro de las organizaciones.

Algunos de los comentarios que surgieron en esta edición de Lean Lens con el itSMF España en el Curso de Verano fueron

Lo que estamos representando aquí es tan familiar que le podríamos poner nombre y apellidos a cada post-it que estamos pegando en el Mural del Waste

Pero… ¿Vamos a mejorar ya, o nos quedamos mirando esto como si nada?

Nos ha parecido tan evidente y tan típico lo que estabamos representando que nos da la sensación de que nos vamos a repetir mucho al poner los derroches en el Mural del Waste

Una mañana intensa en la que hemos aprendido mucho; los alumnos se han llevado nuevas técnicas para hacer aflorar las ineficiencias en su organización y para apalancar los planes de mejora continua y yo… pues yo me he llevado un paquete de mejoras a plantearle a Andrea sobre el juego y un paquete de experiencia adicional para mi mochila.

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

Lean-IT reloaded

Una certificación vale tanto como las empresas (u otras organizaciones) la exijan, y las empresas la exigirán cuando entiendan su significado y contenidos y cuando vean que un profesional certificado realmente domina la materia de la certificacion.

Por esta razón, el mercado de la formación y las certificaciones profesionales necesita un poco de orden y de estabilidad, para asegurar que no existe un abanico enorme de certificaciones procedentes de diferentes institutos u organismos certificadores sobre las mismas temáticas; si con dos o tres esquemas de certificación profesional sobre Gestión de Servicios o sobre Gestión de Proyectos ya hay dudas al respecto de cuál escoger, imaginemos qué pasa cuando para una misma temática puedes encontrar hasta cuatro o cinco esquemas de certificación diferentes: el mercado se fragmenta, pierde prestigio, los alumnos pierden el interés y ninguno de los esquemas consigue la masa crítica necesaria como para que sea “un estándard de facto reconocido en el sector”.

Esta era la situación en la que se encontraba Lean-IT hasta Marzo de este año: había un gran incremento en la demanda de formación en los conceptos de Lean-IT, pero nadie había definido exactamente qué era. Había un gran interés en certificar al personal en Lean-IT, pero nadie sabía exactamente qué esquema de certificación seguir… cuál será mejor, el Lean-IT Foundations de EXIN o el de APMG? Valdrá la pena el de Quint? Nadie sabía exactamente a qué atenerse, y no podías descartar a ninguno porque todos los players del mercado eran grandes pesos pesados en la industria de la certificación profesional. La situación era complicada y corríamos el peligro de que la cuerda se rompiese.

En un alarde de profesionalidad, en Marzo de 2015 se presentó a nivel mundial la Lean IT Association (http://www.leanitassociation.org ), una organización sin ánimo de lucro formada por tres de los grandes organismos de certificación (EXIN, APMG y PeopleCert) y tres de los grandes en formación (ITpreneurs, Pink Elephant y Quint Wellington Redwood) cuyo principal objetivo es proporcionar una visión homogénea sobre Lean-IT, sus materiales de formación y su esquema de certificación para profesionales.

Un pequeño paso para un hombre...
pero un gran paso para la humanidad.

Al poco tiempo de su creación, la LITA presentaba al mundo su esquema de certificación basado en tres niveles (Fundamentos, Practitioners y Profesional) con cinco certificados orientados a capacitar y a acreditar a los profesionales en las diferentes áreas de trabajo en las que se orienta la aplicación de los principios del Lean Thinking al desarrollo y gestión de los servicios IT.

El nivel de fundamentos ya está definido, con syllabus, temario y exámenes de certificacion y la verdad es que es muy bueno: el alumno se lleva una visión global de los principios del Lean Thinking y su aplicacion en todas las áreas de IT, sirviendo de enlace hacia las futuras certificaciones en IT4IT o hacia las certificaciones en metodologías ágiles.

G2 es Accredited Examination Center y Accredited Training Provider con EXIN y por lo tanto tenemos la capacidad de realizar los examenes de certificación también en el nuevo esquema Lean-IT de la LITA y ya hemos comenzado los primeros cursos de Fundamentos en la UPC Tech Talent School dentro del programa de formación Agile IT Management.

¡Bienvenidos!

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.