Búsqueda


Mostrando entradas con la etiqueta LeanITSM. Mostrar todas las entradas
Mostrando entradas con la etiqueta LeanITSM. Mostrar todas las entradas

2 de agosto de 2017

No es el problema. Eres tú frente al problema.

La primera vez que oí hablar sobre el modelo Cynefin fue allá por el año 2012 cuando estaba colaborando con Rob England en la traducción del libro Gestión Esencial de Servicios al castellano. En aquel momento me pareció un framework muy interesante para clasificar los problemas y cómo nos enfrentamos a ellos; luego Rob lo utilizó en su libro Plus! Standard+Case y en el congreso TFT13 yo le dí una vuelta más tratando de enlazar los conceptos de S+C, Cynefin y Minería de Procesos.

Pero luego vino el esquema de certificación de la Lean IT Association y la certificación LITA Kaizen. Cuando me preparaba, volvió a aparecer el modelo de Cynefin y esta vez venía con fuerza, como parte central del proceso de resolución de problemas que plantea la LITA combinando Kaizen con Six Sigma (DMAIC) y Cynefin.


Fue mientras daba una clase de Kaizen que me vino la iluminación; uno de esos momentos A-HA! que sólo puede tener el profesor cuando por el simple hecho de poner las cosas en orden en su cabeza para poderlas explicar, éstas encajan de una manera especial y plop! se hace la luz.

El modelo Cynefin ve los problemas como un cúmulo de causas y efectos; aquellos en los que la relación causa - efecto es clara, los entiende como “Simples”, mientras que en aquellos en que la relación causa - causa - causa/efecto intermedio - causa - efecto es intrincada, con multiples ramificaciones y multitud de causas contribuyendo a la aparición de los efectos los clasifica como “Complejos” y aquellos en los que las relaciones entre los eventos no son permisibles los clasifica como “Caoticos”.

Las relaciones causa-efecto con diferentes niveles de complejidad existen; el problema es que tú no eres capaz de percibirlas o de comprenderlas.

Pero, lo caótico no es el problema. Las relaciones causa-efecto con diferentes niveles de complejidad existen; el problema es que tú no eres capaz de percibirlas. Sin embargo si eres capaz de aprender nuevas ideas, si eres capaz de cambiar la perspectiva o el espectro en el que te mueves (en la vista, por ejemplo, cambiar a espectro infrarojo te permite ver las cosas desde otro punto de vista; en matemáticas, pasar de una serie temporal a un histograma te permite comprender otras facetas del problema analizado; en Telecos, Fourier cambió para siempre la forma de entender las ondas), si eres capaz de pensar de una manera diferente es cuando empujas el problema hacia niveles Cynefin de menor complejidad.

Aquí es justo cuando me viene a la cabeza ese momento en que Neo comprende.

Cómo clasificas el problema dice más de ti que del problema en sí.

Cómo clasificas el problema dice más de ti que del problema en sí. Y esta es una de las razones por las que utilizamos Kaizen para enfrentarnos a los problemas que nos parecen complejos o complicados: utilizamos un equipo para atacar el problema; un equipo multidisciplinar que, gracias a las diferentes perspectivas, experiencias y formas de vivir y de entender el problema hará que el grupo entero gane un nuevo nivel de conocimiento al respecto del problema y sus relaciones con los factores que contribuyen a su aparición. Ese es uno de los motivos por los que, casi sin darnos cuenta, los equipos multidisciplinares y la diversidad hacen empresas más eficientes: los problemas parecen menos cuando los enfrentas en buena compañía.

PS:: Este post viene provocado como reflexión ante una pregunta de Javier Garzás en linkedIn… como siempre, un placer! :-)

9 de octubre de 2016

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.

29 de abril de 2016

¿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!

20 de noviembre de 2015

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

23 de julio de 2015

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.

Obviamente, también hemos jugado....


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?

8 de julio de 2015

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.

17 de mayo de 2015

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

30 de abril de 2015

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!

8 de julio de 2013

Standard, Case y los procesos estructurados

41LQdp24ikL._SX385_En Diciembre del 2012 Rob England presentó en el congreso TFT12 una aproximación bastante novedosa a cómo enfocamos los procesos en ITSM. Esta nueva aproximación recibió el nombre de Plus! Standard+Case a falta de encontrar un nombre mejor que transmitiera el significado y además fuera lo suficientemente “pegadizo” para convertirse en el hit del verano ITSM.

Tuvo buena acogida y en Mayo de 2013 se presentaba el libro en el que Rob describía con pelos y señales esta nueva aproximación Plus! the Standard+case Approach: See Service Response in a New Light ;  luego, en Junio de 2013 durante el congreso TFT13 Rob presentó de nuevo su visión (esta vez con mayor profundidad y mejor estructura).

El modelo S+C plantea una realidad en la que podemos encontrar dos tipos complementarios de procesos: los que tienen una forma completamente estructurada y los que no.

Aquellos que tienen una forma estructurada son los procesos que cumplen a rajatabla la definición que encontramos en todos los libros:

 

un proceso es una serie estructurada de acciones que buscan cumplir un objetivo concreto, con [ blah blah blah …]

 

En fin, si eres lector de este blog seguro que ya te suena esta definición… Los procesos de este tipo se predefinen, son una serie estructurada de acciones y por lo tanto las actividades tienen estructura, tienen un orden predefinido.

El ejemplo ITSM que mejor encaja en esta definición es un cambio estándar. Según la definición que podemos encontrar en los libros de ITIL®

(ITIL Service Transition) A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction – for example, a password reset or provision of standard equipment to a new employee. Requests for change are not required to implement a standard change, and they are logged and tracked using a different mechanism, such as a service request. See also change model.

Para este tipo de proceso podemos predefinir las actividades, los recursos necesarios, los niveles de aprobación, el presupuesto y el tiempo de ejecución, porque son completamente predecibles. Este es el tipo de proceso que encaja a la perfección con los conceptos de industrialización, reducción de la variación y con la aplicación de métodos industriales como Six Sigma.

Así, si utilizamos el ejemplo de la provisión de un equipo estándar para un nuevo empleado nos podemos hacer a la idea de que podemos comprometernos en plazos y en costes, podemos hacer una estimación de los recursos y perfiles que necesitaremos y podemos tener predefinidos los procedimientos a utilizar para cada tipo de equipo estándar o perfil de empleado a satisfacer.

De hecho, incluso podemos plantearnos analizar el tiempo medio de entrega, pensar en la desviación estándar de este tiempo de entrega y utilizar mecanismos como el VSM o DMAIC para reducir esta desviación estándar aportando estabilidad al proceso de entrega.

…y por el otro lado están los procesos que no son tan estructurados, aquellos en los que no podemos definir las actividades con anterioridad porque son un tipo de proceso en el que cada actividad proporciona un conjunto de información que influye en cuál será la siguiente actividad de que ejecute en el proceso. Así, un médico avanza en el diagnóstico de un paciente a medida que va obteniendo resultados de las diferentes pruebas que realiza y decide la siguiente prueba en función de su conocimiento y del resultado de las pruebas anteriores. Igualmente, un investigador avanza en la resolución de un crimen realizando pruebas e indagaciones que alimentan el conjunto de información de la que dispone hasta llegar a una conclusión… pero al iniciar el caso, ni el médico ni el investigador sabían a ciencia cierta cuál era el camino que seguirían.

En el mundo de la gestión de procesos de negocio (BPM) a este tipo de situación se le denomina Case Management y uno de sus aspectos fundamentales es que no podemos predeterminar el conjunto de actividades que se llevarán a cabo y por lo tanto no podemos predecir con exactitud los recursos, perfiles, plazos o costes en los que incurriremos. Esta naturaleza impredecible de los casos hace que no podamos (o no debamos) utilizar mecanismos industriales como Lean o Six Sigma para su control precisamente porque no están estandarizados. De hecho, Taiichi Ohno decía

taiichi-ohno

 

When there is no standard, there is no Kaizen

 

 

Entonces, para gestionar adecuadamente el mundo de los casos, lo que necesitamos son políticas, orientación para que el profesional que está llevando adelante un caso sepa cuánto tiempo, recursos, presupuesto, perfiles puede utilizar para avanzar en su ejecución. Pongámonos en situación imaginando que tenemos una de esas incidencias complicadas que no sabemos cómo resolver (es decir, con la información de la que disponemos en el momento cero más nuestro conocimiento, no sabemos hacia dónde ir). En esta situación no podemos aspirar a que los tiempos objetivo de resolución se cumplan, o que el coste por incidencia sea inferior a XX€. En realidad, lo que ocurrirá es que se irán realizando pruebas o consultando con otras fuentes de información más elaboradas (escalado a N2 o N3) hasta que lleguemos a una conclusión. Bajo este paradigma, ¿en qué momento debemos parar?

Podríamos derivar todo el hilo de la historia hacia aspectos teóricos de si la gestión de incidencias o la gestión de problemas, que si los workarounds y los SLA… pero lo cierto es que en realidad lo que pasa es que no tenemos ni pajotera idea de cuándo podremos tener la cosa resuelta, de la misma manera en que cuando se presenta un caso difícil un médico no sabe cuándo tendrá el diagnóstico… hasta que no dé con el bicho, no habrá diagnóstico (recuerdo a mis padres haciendo biotipificaciones y antibiogramas como pieza fundamental del diagnóstico y cura de un paciente) y por eso en este tipo de casos nos debemos regir por políticas que establezcan qué tipo y cantidad de recursos está la compañía dispuesta a invertir/utilizar para la resolución del caso.

Desde el momento en que Rob comenzó a hablar de esto supe que tendría éxito. No está diciendo nada que no supiéramos anteriormente con respecto a procesos estructurados o no estructurados, pero lo que sí que es importante y tiene que cambiar cómo nos enfrentamos a la realidad del día a día de la Gestión de Servicios es que, siendo conscientes de que existen estos dos mundos, debemos aplicar diferentes métodos para su gestión:

  • Podemos trabajar con SLAs de tiempo y predicciones de coste en el mundo Standard y debemos trabajar con políticas y marcos de referencia que limiten el numero de recursos a invertir en el mundo Case.
  • Los perfiles a asignar en el mundo Standard son totalmente diferentes a los que debemos emplear en el mundo Case, y de hecho cada persona puede sentirse más o menos cómoda trabajando en el mundo Standard o en el mundo Case en función de sus aptitudes o su carácter.
  • Las herramientas a utilizar son diferentes, o al menos deben poder contemplar realidades standard (de flujo predefinido)  y realidades case (de flujo abierto, bayesiano)
  • Los indicadores son radicalmente diferentes: cuando buscaremos medias y desviaciones estándar en el mundo Standard, buscaremos ratios de utilización de recursos y grados de documentación (para facilitar “la estandarización del caso”)

La clave de Standard+Case no se encuentra en la definición o no de procesos estructurados… eso ya lo sabíamos.

Lo esencial que nos cuenta este libro es que debemos tener una serie de patrones que nos ayuden a movernos en los dos entornos.

¿Has pensado ya en cómo articularás tu próximo contrato de outsourcing?

8 de junio de 2013

El punto débil de DevOps

Hace algún tiempo leí el libro The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, una novela muy inspiradora al respecto del uso de las técnicas Lean en el mundo de las operaciones IT y su fuerte relación con el mundo del desarrollo y DevOps. Como novela es entretenida, explica y ejemplifica los conceptos fundamentales y es un cuento de hadas, donde todo va de acuerdo a lo que el guionista ha pensado y desemboca en un fantástico final feliz. Desde luego, no creo que sea necesario recordarles a los lectores que lo que pasa en esos mundos imaginarios no siempre se parece a la realidad y al contrario que en el mundo de Fantasía, a este otro lado a veces las cosas no son tan maravillosas. (Nadie piensa que los lobos hablan después de leer Caperucita, verdad??)

En un momento del libro, el protagonista está reflexionando al respecto de cómo acelerar el ritmo de pasos a producción en el equipo de desarrollo (se han puesto el objetivo de conseguir diez –si, 10- despliegues al día) justamente para seguir los consejos que daba el equipo de Flickr en su conferencia de 2009. Parte de esa reflexión le lleva a decir la frase

 

Until code is in production, no value is actually beign generated, because it is merely WIP stuck in the system

o sea… hasta que el código no está en producción no se está generando realmente valor porque es únicamente WIP atascado en el sistema

Claro, el paralelismo con el libro de Service Operations de ITIL® y el sentido de que no es hasta este momento cuando realmente se entrega valor al usuario del servicio es directo… pero mi reflexión posterior me llevó un poco más adelante: recordé aquel post que había escrito al respecto de que en realidad el valor de un servicio no es como dice ITIL® el equivalente a Utilidad x Garantía, sino que debemos incorporarle un factor más: el uso.

Así, pues, y siguiendo con la reflexión, tanto da que seamos capaces de hacer 1, 10 ó 100 despliegues al día, que si el usuario no es consciente de lo que pasamos a producción y no es capaz de usar las nuevas funcionalidades que estamos incorporando, en realidad IT habrá generado su parte de valor pero si damos un paso atrás e intentamos encontrar dónde está el valor aportado/generado por el negocio no lo encontraremos: así, mi propuesta de modificación a la frase es

Until code is properly USED to GENERATE the EXPECTED VALUE, it still will be WIP stuck at any other point of the system

o sea.. hasta que el codigo no sea USADO de forma adecuada para GENERAR el VALOR ESPERADO, seguirá siendo WIP atascado en cualquier otra parte del sistema.

Intenté contactar con Gene Kim, el autor del libro, a ver qué opinaba del tema, pero es un hombre ocupado y no he conseguido llamar su atención… pero sí que hubo otra persona que dio su punto de vista: Byron Miller opinó al respecto diciendo que en el fondo todo lo relacionado con formación, cambios culturales y modificación de procesos debe ser también considerado WIP.

Vamos a ver si soy capaz de explicar hasta qué punto es importante esto: dentro de las metodologías ágiles (Scrum, XP, etc.) hay un aspecto que es fundamental y es lo que llaman la definición de “HECHO”. Sin esta definición no funciona nada… y es algo que está aquí para arreglar gran parte de los problemas que tenemos en las TIC.

Es necesario que todo el equipo que participa en la cadena de valor del servicio llegue a un consenso al respecto de qué significa decir que una petición del cliente esté HECHA. Históricamente, cada uno de los diferentes silos que participan en la entrega de esta petición ha interpretado como HECHO el momento en que lo da por terminado (según su visión especializada de las cosas) y lo pasa al siguiente elemento en la cadena. Así, el analista da por hecho el análisis cuando lo pasa a desarrollo, el desarrollador da por hecho el código cuando lo pasa a QA Testing y toda la división de desarrollo da por hecho el programa cuando lo entrega a producción.

Pero la cosa no debe de ser así. Todo el equipo, completo, debe tener una definición común de hecho. ¿Cuándo está hecho el evolutivo? ¿Cuando entrego a Ops? ¿Cuando lo despliego? ¿o cuando he conseguido que los usuarios lo usen adecuadamente?

Desde el punto de vista del negocio, claramente el evolutivo está hecho cuando entrega el valor prometido y eso sólo se hace mediante el USO, por lo tanto HECHO incluye también la formación, el cambio cultural, la modificación de los procesos de negocio, etc etc etc.

Así que, desde luego, todo ese aspecto soft de la entrega de servicios forma parte del WIP.

Ahora vamos a darle otra vuelta de tuerca a todo esto. Si pensamos en la teoría de las limitaciones, la propuesta de Goldratt dice en parte que dado un sistema, siempre existirá un cuello de botella. Es más, resulta que cualquier mejora que pretendamos aplicar al sistema debe de ser directamente sobre el cuello de botella, ya que si actuamos antes el resultado será un atasco monumental a la entrada del cuello de botella; y si actuamos después nos encontraremos con que no servirá de gran cosa puesto que será la limitación actual del sistema la que no esté entregando suficiente “ritmo” a las piezas que se encuentran detrás de ella. Así, cualquier mejora introducida en el sistema si no es en el cuello de botella, o bien no tiene efecto o bien contribuye a empeorar el rendimiento global del sistema.

Ufff… esto es complicado, pero va cogiendo sentido!

¿Qué pasa cuando agilizamos el desarrollo y no agilizamos los pasos a producción? Pues que se produce un atasco monumental en los PaP, y eso provoca… que la gestión de cambios es “el malo”, el que no deja pasar las cosas a producción, el que es un freno para la organización. Y qué pasa cuando agilizamos también el paso a producción? Que nadie se explica cómo puede ser que no se usen las nuevas funcionalidades de las aplicaciones y que cuando se usan el equipo de soporte y apoyo funcional no da abasto (hemos movido el atasco a otro sitio).

Si juntamos una definición de HECHO con visión completa, en la que el evolutivo está hecho cuando se está usando y está generando valor a la organización, con la “prisa” por adoptar metodologías DevOps que nos permitan hacer diez despliegues al día, nos encontraremos con que ahora el cuello de botella es el usuario, que no es capaz de absorber tanto cambio de forma continuada o la organización no permite que el usuario dedique el tiempo necesario a formación para ser capaz de absorber los diez despliegues al día. facebookApp

En mi opinión, el ejemplo más claro de esta situación es el mundo de las Apps, en las que se despliegan (no 10 veces al día, pero hay algunos que despliegan al menos una vez al mes) nuevas funcionalidades que son documentadas en un pequeño “Read-Me” o similar que nadie se lee. El resultado? Pilas de nuevas funcionalidades que nadie usa… waste por todas partes porque no se está entregando valor con ese código desplegado, pero un equipo de desarrollo orgulloso de haber conseguido los hitos previstos.

De esa forma, todo vuelve a girar alrededor del “activo más importante de las empresas”: las personas. Las personas son la pieza sobre la que no tenemos capacidad de automatización y por lo tanto será el elemento que siempre será nuestro cuello de botella y sobre el que debemos trabajar en primera instancia, porque de lo contrario lo único que estaremos haciendo será cambiar el atasco de sitio (práctica muy habitual en las organizaciones estructuradas por silos, donde no hay una visión de conjunto: “yo ya he hecho mi parte… el resto no es cosa mía” y donde, además, se ponen objetivos por cumplimientos parciales)

En fin, todo esto ha sido una reflexión provocada por un párrafo en una novela… así que es probable que esté profundamente equivocado. ¿Tienes experiencias al respecto? ¿Trabajas en una empresa DevOps y nos quieres contar cómo transmites todo el cambio a la comunidad de usuarios?

¡Usa los comentarios, por favor!

Postdata: Ops! Por cierto… si somos capaces de hacer diez despliegues al día de correctivos, adelante!!! La comunidad de usuarios y los equipos de soporte lo están deseando! Es decir, todo este discurso es válido cuando el cuello de botella es el usuario por su ritmo de adoptar/asimilar/aprender las nuevas funcionalidades que estamos desplegando. Pero si hablamos de demanda fallo, el discurso es completamente distinto!

19 de octubre de 2012

Sense and Respond–Tomando café con Stephen Parry

El pasado mes de Agosto se celebró en Barcelona la unconference ALE2012 a la que no pude asistir completamente. Aún así, tuve la oportunidad de asistir a la conferencia que impartió Stephen Parry titulada “Evidences and Facts are not enough”.

senseAndrespondStephen es un orador veterano y ya nos conocíamos anteriormente debido a su libro Sense and Respond que es el motivo central de esta reseña bibliográfica.  Cuando me toca hablar sobre la aplicación de Lean a la gestión de servicios IT, es habitual poner sobre la mesa algunos casos de éxito o referencias y uso habitualmente el caso de Fujitsu Services, comentado por Jim Womak en el Hardvard Business Review. Fujitsu tiene una larga y conocida trayectoria en la aplicación de Lean en la entrega de servicios y esta trayectoria se ha visto fuertemente impulsada por la metodología Sense and Respond que Stephen Parry ayudó a desarrollar en sus años dentro de Fujitsu.

El libro recoge los aspectos fundamentales de esta aproximación, en la que podemos resaltar algunos aspectos fundamentales:

1.- Customer Purpose: Es un tema recurrente durante todo el libro. Sólo podremos dar servicios de valor si somos capaces de entender cuál es el propósito del cliente (no es qué me pide, sino para qué me lo pide). Este hecho fundamental está tanto en las definiciones de valor desde el punto de vista Lean como en la propia definición de servicio que hacen ITIL 2011 o ISO20000:2011 “[…] facilitando los resultados que los clientes quieren lograr[…]”

2.- Sense: en el sentido de percibir sensaciones, en el sentido en el que una araña siente cualquier vibración en su tela para acudir, la organización proveedora de servicios tiene que tener una predisposición especial a sentir lo que ocurre en sus clientes. Y justamente no es desde la dirección o desde los niveles más alejados del cliente donde se hace esta percepción, sino justamente desde los centros de atención al cliente, desde los soportes presenciales, desde las unidades que ejecutan y entregan los servicios a los clientes en primera instancia. Así, Stephen plantea en este libro una organización en la que son los niveles más de front-end los que se encargan de ese sentir la necesidad, la satisfacción, la experiencia, el propósito de los consumidores de servicios.

3.- Respond: y de la misma forma en que la araña responde a las vibraciones de la tela, la organización debe responder a las percepciones que el front-end está teniendo del cliente (no para comérselo esta vez, sino para reaccionar con más y mejores servicios, más adaptados a sus necesidades y para ayudarles a cumplir con su propósito). Así, para que la organización pueda responder es preciso que los niveles más directivos, aquellos que moldean la estrategia y la táctica de la organización estén conectados con el front-end. Esto pone de manifiesto la extrema importancia que tienen los centros de atención al cliente para capturar la información que permita a la empresa organizar, moldear y dirigir su prestación de servicios (en contraposición a esa sensación de “mal necesario” tan frecuente).

Es una lectura fundamental para descubrir los beneficios de una organización que realmente escucha a sus clientes y reacciona ante sus necesidades, muy enlazado a los conceptos que Lean nos da sobre la búsqueda del valor para el cliente.

9 de mayo de 2012

Mismo servicio, distintas perspectivas

Cover-Angled-21Hace unos días se comenzó una discusión en el foro de LeanSpain titulada “Muda en la Sanidad, 1-2-3 responda otra vez” en la que diversos participantes han hecho un breve resumen de la percepción que tienen sobre las ineficiencias en los hospitales. Uno de los participantes nos refería a una entrada que había escrito en su blog hace ya algún tiempo llamada “Muda en los hospitales”.

La lectura de este hilo junto con el post de José Iglesias me hizo pensar un poco en las diferentes perspectivas con las que vemos un servicio y, sobre todo, en cómo este caso me servía para ejemplificar algo de lo que siempre acabo hablando cuando me toca exponer Lean Service Management™: el consumo Lean.

Normalmente, cuando haces un taller de análisis Lean (un Value Stream Mapping, un estudio de derroches o cualquier otra actividad que sirva para ayudar a una organización a dar sus primeros pasos en la aplicación del Lean Thinking) convocas a un pequeño grupo de personas que vivan la ejecución de las actividades en su día a día (en terminología Lean, aquellos que viven el Gemba) y en la medida de lo posible convocas a los consumidores de eso que estás analizando. En el momento en que el equipo se comienza a plantear los derroches o las situaciones de ineficiencia, pronto comienzan a salir ideas que mejoran “el cómo se hace”.

Pero si nos fijamos bien en la lista de Mudas que se plantean en el hilo o en el post de José, las mudas que estamos explicando son… ¡¡ de consumo !!. Ninguno (creo) de los que estamos en el foro somos médicos, ni trabajamos en un hospital.. las ineficiencias las hemos explicado desde nuestro punto de vista: el de consumidor del servicio… pero si le hubiésemos preguntado a una doctora o a un enfermero, posiblemente nos hubiera dado una lista de mudas totalmente diferente: las mudas  de producción, no las de consumo.

Eso es lo importante cuando hablamos de aplicar Lean al mundo de los servicios: en los servicios se produce un acople entre la producción y el consumo; hay un acto de co-producción y por lo tanto una representación clásica de VSM no sirve, puesto que la experiencia del cliente es tanto o más importante que la producción del servicio en sí mismo.

En el mundo de servicios tenemos dos flujos de valor que confluyen y que hay que tratar de forma sincronizada: el flujo de la producción y el flujo del consumo. Si estos flujos no están acoplados, tenemos una situación negativa  cuya resolución es fundamental.

24 de abril de 2012

Lean Management: la clave para un outsourcing de primera clase

El 2011 ha sido el año de Lean-IT: han aparecido publicaciones y foros, se ha realizado el I European Lean IT Summit, han surgido de la nada nuevos esquemas de certificación y se han impartido clases y dado conferencias por todo el país.

Esto probablemente ha sido motivado porque se acabaron definitivamente las vacas gordas y ahora nos enfrentamos a una larga temporada de vacas flacas; los directivos buscan maderos a los que agarrarse y poder seguir entregando los niveles de servicio demandados pero, eso sí, dentro de unos niveles de calidad aceptables y, sobre todo, dentro de los márgenes económicos en los que se pueden mover en esta nueva situación.

El Pensamiento Lean se mueve siempre basado en una serie de principios, que podemos resumir en el siguiente gráfico:

Principios_Lean

Por otra parte, un proveedor de servicios IT en modalidad de outsourcing o prestación de servicios continuados se encuentra en estos momentos con la necesidad acuciante de cumplir con las necesidades del cliente (representado principalmente en el modelo tradicional de entrega de servicios por “cumplir las exigencias del contrato” o “satisfacer los SLA”), posiblemente reducir los importes de estos contratos (hacer más con menos) y por otra parte satisfacer sus propias necesidades de rentabilidad (mantener los márgenes de beneficio).

Así, nos encontramos en una situación en la que por una parte la demanda tira del beneficio hacia abajo y mantiene, si no aumenta, la tensión sobre las exigencias de nivel de servicio; por otra parte, el proveedor se ve en la obligación de mantener el beneficio obtenido por la prestación, por lo que alguno de los puntos del triángulo de los servicios se verá afectado.

Pero esto no debe ser necesariamente así. La primera lectura es que si disponemos de menos financiación, habrá que dar menor rendimiento o peores niveles de servicio, y es aquí donde Lean-IT nos puede ayudar especialmente. Veamos cómo siguiendo los diferentes principios que hemos presentado anteriormente:

IDENTIFICAR EL VALOR: Lean asume que los atributos de un producto o servicio que establecen el valor aportado para el consumidor son variables y que por lo tanto debemos realizar una alineación permanente con estos atributos. Eso repercute directamente en la necesidad permanente de contacto con el cliente/consumidor para identificar en cada momento qué es lo importante, ajustando la producción a esas necesidades. Desde el punto de vista de un proveedor de servicios, esto significa que necesitamos contratos lo suficientemente flexibles como para soportar fácilmente variaciones en las necesidades, eTriangulo_Leann los ámbitos, en los niveles de servicio entregados y, lógicamente, en los niveles de facturación y por lo tanto se debe trabajar en equipo para formalizar estos contratos ágiles con mecanismos de facturación variable. Por otra parte, un proveedor de servicios con espíritu Lean no sólo se centrará en el cumplimiento del contrato; pondrá su interés en el propósito de su cliente… ¿Recuerdas la definición de servicio según ITIL? “Un medio de generar valor al cliente facilitando los resultados que desea obtener…” esto es lo que significa ese interés en el propósito: entender y facilitar los resultados que el cliente desea obtener.

IDENTIFICAR, REPRESENTAR Y OPTIMIZAR EL FLUJO DE VALOR: Como dicen Mike Rother y John Shook en su libro “Learning to See”, siempre que hay un producto para un cliente, hay un flujo de valor. El reto consiste en verlo. Este principio Lean hace aflorar uno de los principales problemas organizativos que existen: la jerarquía es a nivel funcional, a nivel de unidades organizativas mientras que el flujo de valor hacia el cliente/consumidor es transversal y cross-funcional. Cuando se aprende a representar y ver el flujo de valor se puede detectar una multitud de actividades que se realizan que no aportan nada a esos parámetros o atributos de valor que hemos identificado en el punto anterior: es lo que el Pensamiento Lean denomina waste (desperdicio, ineficiencia, derroche) y que nos permitirá optimizar el flujo, dejándolo libre de todas estas actividades que sólo incorporan más tiempo de proceso, más volumen de actividad y más ineficiencia global. Aquí es donde entra en juego la posibilidad de hacer más con menos, hacer más de lo que aporta valor, más de lo que al cliente le sirve para lograr su propósito, con menos consumo de recursos, con menos ineficiencia y con menos actividades que no aportan valor. En el fondo, aquí de lo que estamos hablando es de poder lograr los objetivos marcados utilizando menos recursos con lo que podremos ajustar el presupuesto tal y como nos lo exigen los tiempos que corren, al tiempo que podemos mantener los niveles de servicio esperados.

FACILITAR EL “PULL”: Durante las sesiones de formación en Lean Thinking es habitual realizar simulaciones o juegos de mesa en los que se demuestran algunos de los conceptos explicados durante las clases. Uno de estos juegos consiste primero en simular un sistema basado en PUSH (empujar la producción hacia el mercado, producir en base a previsiones y acertar a que el producto se consuma en el momento esperado) y posteriormente otro sistema basado en PULL (en el que es la demanda y el consumo el disparador de la producción, principio básico para la producción Just in Time). Los resultados son espectaculares en estos juegos, donde llegamos a ver incrementos en el resultado final (no sólo en la productividad, sino en los resultados económicos finales: se produce ajustadamente a lo que se puede vender y por lo tanto no hay sobrecostes de almacenamiento, sobre-stock, materiales, etc..)

Pero nosotros, en IT, no nos movemos en una cadena de montaje. Lo nuestro no es una producción en serie con poca variabilidad en el producto entregado y por lo tanto las herramientas Lean no se pueden aplicar directamente sin modificaciones; nos movemos en el mundo de los servicios, intangibles, variables y con una característica fundamental que los hace únicos: la coproducción. El usuario sincroniza el acto del consumo con el acto de la producción que se realiza desde el área de IT (no en el 100% de los casos, pero sirve como generalización). Es por eso que en esta situación el PULL o acto de “estirar de la cadena de producción” se convierte en un factor crítico. Debemos facilitar el consumo y debemos conseguir alisar en lo posible la demanda.

En el caso de nuestro hipotético proveedor de lo que podremos llamar “LeanSourcing”, el hecho de estar permanentemente cerca del cliente, co-planificando la demanda y pensando con él en maneras de conseguir que haya el mínimo posible de picos, hace que el proveedor pueda organizar mucho mejor los recursos necesarios, entregar los recursos adecuados, planificar sus propias necesidades de contratación y de formación, racionalizar, en definitiva, sus costes.

Un ejemplo interesantísimo de este caso se produce cuando vemos a empresas que tienen externalizado su AM&O (Application Management & Operations ) y que colaboran con su proveedor para planificar la demanda de nuevos desarrollos y evolutivos en ventanas a 3 meses vista. Cuando esta planificación se hace de forma apropiada, el cliente consigue a las personas más adecuadas para cada uno de los trabajos y el proveedor, con un conocimiento previo de la demanda que tendrá del cliente, puede planificar mejor sus equipos e incluso planificar las necesidades de contratación o de formación que tendrá.

BUSQUEDA DE LA PERFECCION: Este principio asume que la perfección es un estado utópico, inalcanzable; no por ello debemos tirar la toalla, sino que debemos iniciar actividades de adaptación continua a las necesidades de ese “blanco móvil” que es el valor desde el punto de vista del consumidor. Bajo este paraguas aparecen las herramientas de mejora continua, tanto del sistema de producción como del producto/servicio producido.

Aquí aparece el trabajo en equipo, el aprovechar la inventiva, imaginación y conocimiento de todo el equipo, hacer participar a los diferentes integrantes del flujo de valor en las propuestas de mejora y un concepto importantísimo en toda iniciativa de gestión Lean: Walk the Gemba, pasear, visitar, conocer cómo se realiza el trabajo de verdad (Gemba es una palabra japonesa que tiene el significado de “lugar donde se encuentra la verdad” y “lugar donde se produce la acción”). Hablando con expresiones más castizas, comprenderemos mejor cuáles son las necesidades de mejora del sistema productivo si somos capaces de ponernos en la piel de cada uno de los que intervienen en el flujo de valor; y podremos comprender las necesidades de mejora del producto/servicio que entregamos si nos ponemos en la piel del consumidor/usuario que utiliza nuestros productos/servicios.

Otro ejemplo especialmente interesante del grado de comprensión que se adquiere cuando se vive el Gemba es el caso de una empresa en la que, después de varias sesiones destinadas a plantear las mejoras necesarias en la gestión de facturas de proveedores, el analista se pasó una mañana validando facturas y conformando albaranes. Mientras lo iba haciendo, iba exclamando “¡Pero este trabajo lo he hecho ya dos veces!”, “¡Aquí me faltaría un campo para registrar esta información!” o “¡Necesito una consulta que agilice este paso!”

consumo_leanUn LeanSourcer no desarrollará su trabajo de manera deslocalizada sin exigirle a su cliente que los equipos de trabajo puedan visitar, ver y vivir de vez en cuando el Gemba del usuario, sentir sus problemáticas y poder así plantear mejoras a los servicios entregados.

En conclusión, cumplir con la exigencia que hacen los clientes hoy en día de hacer más con menos sin perder la calidad es un reto que se puede conseguir traduciendo la consigna en “hacer lo necesario, bien a la primera, y con el menor consumo de recursos posible”, que es justamente el leitmotiv de la gestión Lean, aunque para ello es preciso que ambos componentes de la ecuación, cliente y proveedor, trabajen en equipo para conseguirlo. Se construye de esta forma un sistema productivo en el que todos ganan y, en esta relación win-win se consolidan relaciones de larga duración en las que el cliente y el proveedor se convierten en partners.

NOTA: Este artículo se publicó por primera vez en la revista Service Talk de Abril 2012 (Año VII – Edición I), publicada por el itSMF de España.

15 de noviembre de 2011

Incidencias, Peticiones, Consultas… Service Requests

Desde que comencé a trabajar en asuntos relacionados con ITSM, allá por el año 96, ya aparecían problemas a la hora de clasificar correctamente los tipos de solicitudes que llegaban a un CAU. Con la entrada de ITIL V2, recuerdo que enseñaba en los cursos de formación la Gestión de Incidencias y luego aclaraba que “aunque la teoría dice esto, en realidad recibimos muchos tipos diferentes de llamadas”, asunto que provocó un artículo en este mismo blog titulado Una Queja no es una Incidencia.

Con la llegada de ITIL V3 apareció de la nada un nuevo proceso llamado “Gestión de Peticiones”, que nos permitía romper aquel flujo único en dos, cosa que desde el principio ya fue aceptada positivamente, ya que separábamos lo que podríamos entender como Demanda Valor de lo que sería Demanda Fallo, pero cuando vas a la vida real te chocas con dos asunto básico: (a) un mismo flujo no sirve para todos los tipos de peticiones y (b) no es tan fácil saber, en el momento en que tienes al usuario al teléfono y apenas un par de minutos para atenderlo y registrar, si lo que el usuario quiere es una incidencia o una petición.

Las diferentes aplicaciones de ITIL en las que he trabajado (nótese lo premeditado de no utilizar la palabra implantación) han lidiado con este problema de diferentes formas, muchas veces en función de lo estandarizado que se tuviese la lista de peticiones o de las capacidades de las herramientas para soportar flujos, ordenes de trabajo, plantillas, etc.

Más tarde comencé mi viaje por el mundo del Pensamiento Lean, en el que fui a parar a la lectura del libro Lean Solutions de Jim Womack y Daniel Jones. En este libro se describe una forma de canalizar las peticiones del consumidor en lo que se denominan pathways de tal forma que se pueda estandarizar, optimizar y priorizar el trabajo en cada uno de estos caminos [cosa que nos resolvería el punto (a)]

Por otra parte, el estudio de una de esas obras poco difundidas pero de gran valor que es el libro Guide to the Universal Service Management Body of Knowledge (USMBOK) me llevó a ver que el planteamiento que se realiza en USMBOK es el de recibir todas las peticiones de consumidor, sean del tipo que sean, en una entidad llamada Service Request, que se clasifica según diferentes tipologías, entre ellas:

  1. Peticiones de servicio procesadas automáticamente por el motor de transacciones
  2. Peticiones de servicio derivadas de que una de las de tipo 1 ha fallado (incidencias)
  3. Peticiones de servicio procesadas con intervención humana, pero no del tipo 2
  4. Peticiones de servicio que solicitan la modificación del servicio (Petición de Cambio)

esquema1Esta aproximación nos resuelve el punto (b) ya que todo es una Service Request que luego es fácilmente reclasificable entre los diferentes tipos. Por otra parte, ayuda a implementar el concepto ITIL V3 de CSI Register (que USMBOK incorporaba previamente como Project Incubator) y permite ver toda la demanda agregada (cosa crítica ya que todos los diferentes tipos de demanda compiten por los recursos finitos de la organización proveedora de servicios).

Así, si unimos todo esto en un modelo único, lo que obtenemos es que hay diferentes formas de canalizar una Petición de Servicio hacia la organización proveedora de servicios, y diferentes tipos de petición que se pueden realizar. Por otra parte, la organización proveedora puede recoger todas estas peticiones y canalizarlas a través de diferentes flujos de actividad para su realización. Esto, aunque es de sentido común y podría parecer obvio, choca con estándares oficiales y de-facto que plantean flujos únicos para el tratamiento de las peticiones, mientras que la combinación Lean + USMBOK nos lleva a un tratamiento detallado y unificado de la demanda, tal y como podemos ver en los siguientes gráficos.

USMBOK2

USMBOK3

Puede parecer complicado, pero es una forma de incrementar el detalle de nuestra gestión de una forma gradual (incorporando nuevos tipos de petición con sus correspondientes pathways) que nos permitirá luego aplicar las técnicas Lean de mejora continua a elementos más pequeños y atómicos como es una petición concreta. Con una definición de la gestión al nivel de “Gestión de Peticiones” no tenemos la granularidad necesaria como para poder mejorar ni plantear objetivos de nivel de servicio ni criterios de comparación… ¿Te imaginas haciendo un benchmark del tipo “cuánto tiempo tardas en resolver peticiones” o “qué coste tienen las peticiones en tu organización”? ¿Y del tipo “cuánto tiempo tardas en proporcionar un equipo a un nuevo empleado” o “cuánto te cuesta el alta de un usuario”?

Hay otras maneras de hacer las cosas, no dejemos que las best-practices nos impidan pensar. Recordemos la máxima de la familia Atreides en Dune (un guiño cariñoso a Luis Moran)

El camino fácil dirige, inevitablemente, al estancamiento

enseñanzas de las Bene Gesserit
Dune

¿Quieres saber más?