Necesito una Unidad de Intervención Inmediata

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

El problema

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

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

La solución

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

La Propuesta de G2

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

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

El Service Desk como Unidad de Intervención Inmediata

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

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

Ya escribía sobre esto aquí

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

y aquí

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

¿Y cuál es la respuesta?

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

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

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

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

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

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

Las amebas y la estrategia

¿Has visto alguna vez una ameba? Al microscopio, en vivo y en directo… en la EGB, quizás? en el Instituto?

Una ameba es un ser vivo unicelular, no tiene cilios ni flagelos, como podrían tenerlos un paramecio o un vibrión colérico. Una ameba se mueve emitiendo pseudópodos, arrastrando lentamente parte de la masa celular en el sentido en que se quiere desplazar y luego moviendo el resto de la célula completa hacia allí.

Cuando se quiere alimentar, emite dos pseudópodos que rodean la partícula que quiere absorber hasta que éstos se unen y fusionan, dejando a la particula dentro de la ameba.

Pues las empresas son como las amebas.

Llevo años explicando esto en mis clases, primero cuando hablaba de mejora continua en ITIL, después cuando hablaba de mejora continua en ISO/IEC 20000, luego cuando hablaba de mejora continua en Lean y últimamente cuando hablo de mejora continua en Agile. Es mi forma de ver la importancia que tiene el impacto que tiene desplegar el pensamiento estratégico hacia toda la organización cuando estamos fomentando una cultura de mejora continua. Y sin embargo, repasando este blog nunca había escrito sobre la ameba.

Pero hoy he visto un post de Txell Costa donde hace una metáfora parecida pero con una goma elástica… y por eso me he decidido a escribir sobre la relación que hay entre un ser unicelular, microscópico, sin cilios ni flagelos, que se mueve por medio de pseudópodos … y tu empresa.

Las empresas son como las amebas. Emiten un pseudópodo y exploran nuevos territorios, como tú cuando tocas el agua de la playa con la punta del pie antes de meterte, tanteando a ver si está demasiado fría. Estos nuevos territorios pueden ser nuevos mercados, nuevos productos, nuevas maneras de hacer, nuevas maneras de organizar… emiten un pseudópodo y tantean y, si les parece que el agua está de su gusto, se tiran (algunas de cabeza y otras de culo… ya sabemos cómo va esto...)

En un entorno tradicional y jerarquizado, la alta direccion sabe a dónde quiere ir, y cuáles son los planes estratégicos para los próximos 5 años. La visión es clara y dirige el timón con mano férrea hacia ese horizonte que se ha planteado. En estos casos, transmitir la estrategia a los trabajadores no es necesario, es incluso contraproducente, no vaya a ser que alguien se vaya de la lengua, cuente nuestros planes y la competencia acabe adelantándonos.<ironic mode off>

Y qué pasa con la mejora continua? Los pequeños movimientos evolutivos no forman parte de aquellos grandes planes estratégicos, asi que aparece otra manera de avanzar: el modo ameba, en el que pequeños grupos de personas dentro de la organización se plantean pequeñas mejoras que hacen más eficiente el sistema o más valioso el producto final. Esas pequeñas mejoras se plantean como pruebas o experimentos (Da igual cuál sea el modelo de mejora continua que uses, más tarde o más temprano aparece el Dr. Deming con su ciclo PDCA y el planteamiento de experimentos… no conozco ningún modelo de mejora continua que no pase por ahí)

Bien. Ya he puesto en tu cabeza la imagen de la amena extendiendo sus pseudópodos para experimentar un nuevo terreno.

¿Funcionará bien la nueva manera de gestionar pedidos? Hacemos un piloto, probamos un MVP, hacemos una prueba con un par de clientes, extendemos a “friends & family” y si todo va como debe ir, pues ¡adelante!

Pero los métodos modernos de mejora continua tratan de conseguir un factor multiplicador involucrando a todo el personal de la organización (a lavez que potencian la cultura, empoderan al personal y un buen atado de otras ventajas). Se trata de paralelizar el modelo evolutivo y conseguir un pipeline continuo de experimentos. Hasta llegar al extremo asombroso de booking.com y sus 2^1000 versiones concurrentes de la web. Esto significa que estamos montando modelos de mejora continua que tratan de conseguir multitud de pequeños equipos distribuidos por la organización haciendo experimentos y provocando pequeños cambios que, en algunos casos, pueden resultar interesantes y provocar una tensión de movimiento “hacia allí"

Pero ¡atención! No estamos hablando de un ser pluricelular que hace muchos experimentos, sino de una pobre y triste ameba, unicelular y sin cilios ni flagelos.

¿Qué le pasa a la ameba si de repente emite 50 pseudópodos en direcciones opuestas y se empeña en moverse?

Lo mismo que le pasa a tu empresa cuando no se ha transmitido la estrategia y se montan grupos de mejora: cada vez que un grupo de mejora encuentra algo interesante (es decir, realiza un experimento exitoso) provoca una tensión hacia aquello que ha descubierto. Una empresa cuyos equipos no conocen la estrategia y tiene pocos experimentos exitosos se moverá como un tronco a la deriva en medio del océano: en el mejor de los casos, se deja llevar por los resultados de estos experimentos.

Pero una empresa que no ha transmitido la estrategia a sus colaboradores, que fomenta un entorno de mejora continua con gran parte de su personal y que además consigue multitud de éxitos en los experimentos, puede terminar intentando avanzar de forma simultánea en direcciones contrarias. En el mejor de los casos no se mueve y en el peor de los casos se rompe, se parte la pared celular y todo citoplasma queda por ahí desparramado. ¡Qué triste!

¿Nunca has tenido la sensación de que en tu empresa tienes varios jefes y que estos jefes estiran de ti en direcciones opuestas como si te estuviesen torturando al estilo mongol con 4 caballos?

Una buena transmisión de la estrategia corporativa ayuda a que los experimentos vayan en direcciones similares al menos, reduciendo el riesgo de que la empresa se parta, los trabajadores se quemen o la goma elástica de Txell salte por los aires.

Finalmente y por aterrizar esto a un terreno más práctico: si te imaginas una empresa que tiene varios equipos de desarrollo usando Scrum y estos equipos hacen retrospectivas y plantean pequeñas mejoras, te recomiendo que:

1. Los equipos tengan claro hacia dónde vamos
2. Hagas Retros de Retros uniendo representantes de los equipos o una comunidad de Scrum Masters para que vean periódicamente si las mejoras propuestas por el equipo A no le están haciendo la vida imposible al equipo B o al departamento C

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

DevOps Foundations

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

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

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

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

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

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

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

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

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

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

… y no hay mucho más que decir…

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

William Edwards Deming, 1986

Dilbert y el Lean Sourcing

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

---

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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.

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!

Consumada la venta de ITIL

Es curioso cómo son las cosas… hay días en que parece que los astros se alineen para dar esas coincidencias extrañas que pasan sólo muy de vez en cuando. Esta mañana he estado repasando un poco la línea temporal sobre historia de ITSM que tengo para mis clases y me di cuenta que una de las últimas entradas era la publicación del concurso para formar una joint-venture que impulsara las best-practices del gobierno británico (ITIL, MoV, Prince, etc..). Como no había tenido novedades al respecto y el tema había levantado bastante debate entre los profesionales del sector, me puse a buscar a ver si había algo de información al respecto del resultado, pero no encontré nada.

Luego, después de comer miré el correo y zas! ahí estaba la notificación de que se había publicado la nota de prensa con el resultado de esta aventura: la formación de una Joint-Venture con una empresa que yo no conocía de nada: Capita PLC

Esta Joint-Venture tiene aspectos muy curiosos. Empezamos leyendo la composición: 51% Capita, 49% Cabinet Office (o gobierno británico o su majestad la reina… los actuales dueños, vamos). Cuando salió la noticia del concurso hubo mucha discusion al respecto de si una JV sería vender ITIL® o no… para mi ahora está claro: si te asocias con alguien y ese alguien tiene más del 50% del asunto, lo has vendido. A partir de ahora, en las decisiones importantes, quien manda es Capita, no la Cabinet Office.

Otro aspecto interesante son los matices de la nota de prensa del gobierno británico:

Capita plc will own a 51% share of the new company. It will bring commercial expertise and enable investment needed to develop the products and break into new international markets. The government will retain 49% to ensure taxpayers benefit as the business grows.

Ojo, que no dice que se quedan el 49% para asegurar el buen crecimiento de los estándares ni la calidad de los mismos ni nada por el estilo… se quedan el 49% para asegurarse el beneficio. Y punto. A lo largo de toda la noticia se habla constantemente de los beneficios económicos y de las grandes perspectivas de comercialización que tienen los productos. Si alguna vez hubo alguna posibilidad de que ITIL® pasara a formar parte de la cultura general en forma de material libre, ya nos podemos olvidar… y eso significa también que la cultura de compartir y enriquecer los contenidos de las Best Practices de una manera similar a las comunidades open source desaparecerá rápidamente.

Y todo esto para qué? ¿A qué se dedicará la nueva empresa?

The new company will accredit exam institutes and training organisations to run exams and courses. It will act as an exam institute itself for the Project and Programme Management portfolio, including PRINCE2® products. Professionals using the qualifications will benefit too.

Asi que quedará como ente acreditador para los institutos examinadores y empresas de formación… ¿Qué pasará con APMG? En su página web apenas si hay una pequeña mención al tema… como si lo dijeran con la boca chica. Ellos hicieron ya un movimiento con ISACA que les puede salvar el trasero al menos en lo que a ITIL se refiere: están en el negocio de las certificaciones de COBIT 5, y eso puede ser muy grande si lo saben mover bien.

Y EXIN también ha movido ficha, anunciando en su pagina web la noticia e incluyendo un comentario esperanzador al respecto de que CAPITA respetará el ecosistema actual. De todas formas, tanto APMG como EXIN tienen sus salvavidas particulares en caso de que a estos británicos se les vaya la pinza.

¡Qué curioso es este mundillo!

Te puede interesar mirar atrás:

El futuro de ITIL (Noviembre de 2006)

La vuelta al cole (Septiembre de 2006)

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”.

Stephen 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.

Visión sistémica en el outsourcing – o nos crecen los enanos

Llevo varios meses trabajando con diversas empresas que se encuentran en una situación de outsourcing con múltiples proveedores. Cada una tiene sus características, sus situaciones especiales, si carácter; pero eso sí, hay algunos detalles que son factor común. Uno de estos puntos en común es la dificultad que tienen para gobernar los contratos con proveedores de servicios que están trabajando en diferentes áreas.

Cuando una empresa se plantea externalizar parte del trabajo que se realiza debe tomar una primera decisión: ¿por dónde pasamos las tijeras?  ¿cómo “troceamos” el modelo de provisión de servicios al cliente interno para asignar partes de este trabajo a terceros? Básicamente, hay tres respuestas a esta pregunta:

Opción 1:  trocear por servicios – Se le asigna a un proveedor la entrega de un servicio completo, extremo a extremo, hacia el cliente interno. Es una práctica muy poco (o nada) empleada en IT, pero sí que se ve en otras áreas de negocio, donde se le llama Business Process Outsourcing o BPO.

Opción 2: trocear por funciones – Se le asigna a un proveedor la ejecución de una función (un grupo de personas con un cuerpo de conocimiento específico). Esto es lo más habitual en el entorno de IT, y así vemos a terceros realizando “Gestión de Infraestructuras”, “Gestión del puesto de trabajo”, “Gestión de Aplicaciones”, etc.

Opción 3: combinar las dos anteriores con un reparto regional – Cuando la empresa está localizada en múltiples sedes o en diferentes países, se puede realizar una aproximación en la que se asigna una función o un servicio por región geográfica (por ejemplo, la “Gestión del puesto de trabajo” para la región de “Sur de Francia”)

Una vez tomada la decisión, viene la siguiente fase: la creación de los contratos; aquí ya se empieza a diversificar el asunto, y normalmente serán los responsables de las diferentes funciones (del área TI interna) quienes definan los requerimientos para estos procesos de externalización, resumiendo en pliegos o RFPs las necesidades y las primeras guías de cómo se va a gobernar la ejecución del contrato (aparecen los primeros indicadores, los primeros borradores de niveles de servicio y de SLAs, etc)

Si nos fijamos bien, en este momento del proceso comienzan a sentarse las bases de lo que será en el futuro el “nuevo modelo de prestación de servicios” de IT a su cliente (a.k.a. “el negocio), y aquí es donde comienzan a sentarse las bases de los futuros problemas de gobernabilidad: lo que en una primera fase fue la definición holística de un modelo ahora se ha traducido en una contratación por partes y de ahí viene el título de este post: es necesario mantener una visión sistémica del conjunto y es necesario transmitir esa visión sistémica a la contratación por partes.

¿Nunca has tenido la sensación de que gobernar tu departamento de IT se parece a una partida de Whacka-Mole?

Básicamente, la sensación viene producida porque cuando aprietas en un sitio, el problema sale por otro lado… y la razón simplemente es que, a pesar de que en la superficie los contratos con tus diferentes proveedores sean inconexos, por debajo están conectados; entre ellos, con nosotros, con los clientes, con las personas; formando una intrincada red de túneles por las que se mueven los topos, los enanos, los problemas, el dinero y siempre aparecen por donde menos te lo esperas.

Es por esta razón por la que debemos adoptar una visión sistémica, de sistema, de todo lo que ocurre en este entorno.

Yo creo que el mejor ejemplo que se puede dar para entender esto es poner un caso simple: una empresa que tiene un equipo interno de Sistemas (que se encarga de la gestión y administración de las infraestructuras, sistemas operativos, máquinas, middleware como las bases de datos o los servidores web, comunicaciones…), un proveedor externo que se encarga del soporte al usuario y otro proveedor externo que se encarga de la gestión de aplicaciones.

Aquí vemos un sistema formado por 3 componentes (a gran escala) que colaboran entre sí para entregar un conjunto de servicios TI al cliente y que se ven regulados por una serie de contratos. Veamos cómo son estas reglas de juego (simplificadas en aras de que se comprenda bien el ejemplo, claro!)

EQUIPO	RESPONSABILIDAD	OBJETIVOS
SISTEMAS	Mantener las infraestructuras en marcha con los niveles adecuados de capacidad y disponibilidad	Disponibilidad de los Sistemas Rendimiento de los sistemas
SOPORTE	Atender las incidencias y peticiones de los usuarios	Resolución de incidencias en plazos Ejecución de peticiones en plazos
GESTION APPs	Mantener y evolucionar las aplicaciones de negocio	Cumplimiento de plazos y presupuestos de desarrollo

Ante esta situación, si pretendemos gobernar el sistema mediante el uso de indicadores y SLAs nos encontraremos con que:

1. A pesar de tener una correcta disponibilidad y rendimiento de los sistemas, los usuarios pueden estar completamente descontentos (es necesario incorporar una figura que vele por el servicio extremo a extremo, independientemente de las 3 funciones que tenemos en el ejemplo)
2. El proveedor de soporte… ¿cómo nos factura por el servicio? Evidentemente, es justo que a mayor carga de trabajo nos pueda facturar más; sin embargo, la mayor carga de trabajo puede ser generada en otras de las funciones (que, en el caso de Gestión de Aplicaciones es otro proveedor al que no le interesa lo más mínimo reducir la carga de trabajo de Soporte)
3. El proveedor de desarrollo, ¿qué objetivos tiene? Cumplir plazos y ajustarse al presupuesto. Simplemente eso.

Así, en este ejemplo vemos rápidamente que la tarea del CIO será hacerse con un martillo y comenzar a golpear enanos que le irán creciendo eternamente… cambiará 1, 2… hasta 7 veces de proveedores y seguirá con el martillo porque la causa no es una incompetencia del proveedor, sino un sistema diseñado para fallar. Apretará al de soporte, pidiéndole que resuelva en plazos y el de soporte hará hasta que los números se lo permitan. El de desarrollo cumplirá plazos y presupuestos, pero a costa posiblemente de producir desarrollos de baja calidad que llenarán al SAU de llamadas o que malgastarán los recursos de sistemas hasta tener que ampliar máquinas una y otra vez. Ahorraremos en un sitio, pero los costes se irán a otro lado.

¿Y todo esto por qué? Porque los objetivos individuales van en contra de una visión de conjunto. Al tener objetivos individuales en cada contrato, estamos rompiendo la visión de sistemas y estamos primando la creación de silos verticales. Además, no nos engañemos: el objetivo de cada uno de los proveedores de servicios será siempre, salvo contadísimas excepciones, “barrer para casa”, así que o imbuimos la visión sistémica desde el principio, en el propio diseño de “por dónde paso las tijeras” y añadimos esa visión en los contratos y en la operativa diaria, construyendo equipos focalizados no en el cumplimiento de indicadores parciales sino en la entrega real de valor al cliente, o estaremos toda la vida dándole golpetazos con un martillo a los enanos que nos crecen por todas partes. Por ejemplo, podríamos:

1. Hacer co-responsable al proveedor de desarrollo de las implicaciones de su software en soporte y en sistemas.
2. Hacer que el proveedor de soporte sea co-responsable de la mejora continua de las aplicaciones y los sistemas.
3. Hacer que el equipo de sistemas sea co-responsable en la definición de arquitecturas y estándares para apoyar al equipo de desarrollo.
4. Hacer que todos tengan responsabilidad sobre indicadores globales de servicios extremo a extremo.
5. Establecer responsabilidad transversal de la entrega de servicios entre las diferentes funciones.
6. Establecer, como decía Walter en una de las presentaciones del itSMF Catalunya 2011, un único indicador: satisfacción del cliente. Perder un poco el foco en el cumplimiento de SLAs y poner el foco en lo que nos importa: el cliente

Ya lo decía Jim Womack en una de sus últimas conferencias: EL problema es que el poder y el control se ejerce verticalmente, cuando el valor al cliente fluye horizontalmente. ¡¡Gestionemos la horizontal!!

Cruzando la cordillera

Llevaba mucho tiempo deseando que se diera la posibilidad de combinar una visita a la familia con una oportunidad laboral… siempre deseando encontrar un cliente en Las Palmas o una tentativa en Chile, hasta que al final los astros se han alineado y todo ha quedado encarado.

Hace unos meses tuve la oportunidad de conocer a Judit Laguardia, socia fundadora y directora ejecutiva de ORCI. La conexión fue instantánea, somos dos personas entusiasmadas por la Gestión de Servicios, interesadas en nuevas ideas y, sobre todo, emprendedoras… así que no hubo que hacer demasiadas filigranas para organizar el  I Seminario de Gestión Lean de Servicios en Santiago de Chile.

Nos juntaremos el próximo 4 de Agosto en el Hotel Marina Las Condes y hablaremos sobre qué es esto del Pensamiento Lean, sobre cómo se pueden aprovechar estos conceptos para enriquecer nuestra Gestión de Servicios y, principalmente, compartiremos experiencias.

Puedes encontrar la nota de prensa, el cartel y la convocatoria en la página de G2

Se que hay muchos seguidores de este blog en LatinoAmérica, así que si te encaja en la agenda, no dudes en ponerte en contacto con Judit y su equipo para que lo puedan organizar todo. Te esperamos!!

Nota: Lean Service Management™ is a servicemark and trademark of Service Management 101

La encuesta de San Juan

Luis Carrasco ha montado una encuesta interesantísima: ¿Qué porcentaje supone el presupuesto de TI sobre las ventas de tu compañía?

Cuanta más participación, más útiles serán los resultados… así que venga! Anímate y participa!

Para contestar a la encuesta: AQUI

Para ver los resultados: ACÁ

¿Proveedor o Partner?

Cuando era pequeño, las mañanas de los sábados se dedicaban inevitablemente a las compras semanales para la familia. Salíamos mi madre y yo, carrito de la compra en ristre, rumbo al supermercado y después de ahí al mercado central, a hacer la compra de la fruta y la verdura.

Estas salidas siempre fueron motivo especial de alegría (nunca se sabe lo que vas a encontrar en el mercado!) y de aprendizaje, ya que mi madre siempre aprovechaba cualquier ocasión para enseñarme las cosas de la vida y el mercado era la fuente principal de lecciones sobre Relación con Proveedores.

Íbamos siempre a los mismos puestos, siguiendo siempre la misma ruta, y comprando siempre a las mismas tenderas, salvo que alguna no tuviese lo que buscábamos y en ese caso ellas mismas nos indicaban a qué puesto teníamos que ir (bueno, en realidad era la propia tendera la que decía “Manolo, vete al puesto de Josefa y pídele una calabaza. Que sea buena, que es para la Señora Bernardita”, y allá que iba el señor Manolo a buscarnos la mejor calabaza del mercado)

Era bastante habitual que volviésemos a casa, además de con el carrito lleno, con una caja de fruta remadura que no se podía vender y que nosotros convertíamos en mermelada o con unos cuantos calabacines que de puro feos no tenían salida, pero que convertidos en puré estaban exquisitos.

La clave está en comprar siempre en el mismo sitio, en tejer una relación de confianza con las señoras de los puestos para que te cuiden porque eres un buen cliente. Los que compran cada día en un sitio, buscando siempre el mejor precio, seguramente se ahorran unas pesetillas, pero no se llevarán el mejor género porque ese se guarda para la gente de confianza

Ni mi madre ni yo somos de madrugar, así que las visitas al mercado eran más bien tardías… pero siempre había buen género para la Señora Bernardita.

Cuando se establece una relación ventajosa entre un cliente y un proveedor, en la que el cliente trata con respeto y lealtad al proveedor y éste responde con implicación y valor añadido se están dando los primeros pasos para convertir a este proveedor en un Partner.

Partner es una palabra inglesa, que significa literalmente “an associate who works with others toward a common goal”, un asociado que trabaja con otros para conseguir (y aquí es donde viene lo bueno) lograr unos objetivos comunes. Los objetivos de un partner tienen que ser comunes a los de sus asociados, o no será un partner.

Así, es necesario que el proveedor vea en el cliente una relación de larga duración y que desee cuidarla (idea totalmente contraria a la “cultura del pelotazo” en la que si le puedo enchufar sea como sea el mega-proyecto al cliente ya soy feliz).

Esta relación de larga duración le dará al proveedor algo que es especialmente importante: conocimiento de su cliente. Cuando conoces a tu cliente, puedes precisamente dar esa pieza de valor añadido de la que hablábamos antes…. Amazon puede ser mi proveedor de libros, pero jamás (al menos por ahora) podrá ser mi “partner en asuntos de libros”, porque no me conoce, no sabe mis gustos y no puede escuchar mis opiniones al respecto (van por ese camino, pero aún les queda mucho!)

Sin embargo, el señor de la librería a la que siempre voy ya sabe qué libros me gustan y me puede sugerir “llévate este que me acaba de llegar que seguro que te gustará”; y esa sugerencia estará en línea con mis gustos literarios (confianza, valor añadido) y no será dada porque ese sea el libro que más margen le esté dando al librero ese mes (cultura del pelotazo).

Pero para que el proveedor pueda tener ese conocimiento y ese interés en fomentar la relación a largo plazo, le hace falta algo que tiene que aportar el cliente: lealtad y flexibilidad. La lealtad hace que “siempre vaya a comprar al mismo sitio” y la flexibilidad hace que no intente apretar al señor Manolo para que me ponga las naranjas al mismo precio que el más barato del mercado, porque el señor Manolo tiene que ganarse la vida.

Y aquí está el equilibrio necesario: el Partner tiene que poderse ganar la vida y el cliente tiene que permitírselo, al tiempo que vigila que no “se le suban los humos” y deje de ser interesante la relación.

CLIENTE	PARTNER
Respeto	Implicación
Lealtad	Conocimiento
Transparencia	Valor Añadido
Flexibilidad	No excesiva ambición
Confianza	Confianza

Y así, a través de este tipo de relación entre organizaciones, el cliente se beneficia de productos y servicios ofrecidos con un “extra” de valor añadido que es realmente importante (y más en estos tiempos que corren) y el partner se beneficia por tener clientes fieles que hacen de altavoz de sus excelencias.

Sobre las ventajas de la confianza y el conocimiento del cliente a la hora de proponer productos y servicios de alto valor añadido ya hablaremos en otra ocasión-

Por último, si quieres leer un poco más sobre el tema, te recomiendo los primeros capítulos de Universal Service Management Body of Knowledge (USMBOK), de Ian Clayton.

La Guerra de los Ingenieros Informáticos

Llevo ya varios días dándole vueltas a cuál es la postura adecuada ante el jaleo que se ha montado y se está montando alrededor del futuro de la titulación de Ingeniero Informático en España.

El tema es complicado, porque se mezclan varios conceptos y además, al ser algo que te toca de cerca, es fácil que la sangre se caliente y no demos tiempo suficiente a la cabeza a procesar. Así que he leído de varias fuentes, he esperado a ver la postura oficial de ATI y de los Colegios, y al final más o menos me he hecho una opinión.

Primero, voy a dar las fuentes de las que he leído:

1. http://www.huelgainformatica.es/ es el website que corrió como la pólvora por la red y que me pasaron varios de los colegas de profesión. Nada como una buena web revulsiva y un efecto viral para que la problemática de la titulación se conozca rápidamente.
2. http://www.coetic.org/ es la web del Colegio Oficial de Ingeniería Técnica de Catalunya
3. http://dafib.upc.edu/ es la web de la Delegación de Alumnos de la Facultad de Informática de Barcelona (FIB)
4. http://www.ati.es/article.php3?id_article=1077 es la posición oficial de la ATI al respecto
5. La Carta Abierta del Decano de la UPV, donde explica algunas posturas
6. Bolonia for Dummies, un website con FAQs sobre el asunto
7. Libro Blanco del Título de Grado en Ingeniería Informática

Al final, lo que ocurre es que el Tratado de Bolonia ha puesto en relevancia algo que venía ocurriendo de lejos: la profesión de Ingeniero Informático (que no de Informático... eso es lo primero) está ligeramente desprestigiada y se le ha hecho un trato de agravio comparativo en relación a otras ingenierías; pero como los IIII, o sea, I4 (Ingenieros Informáticos) no somos un colectivo especialmente social, gregario y luchador por nuestros intereses sociales, no hemos hecho nada.

...Y nada quiere decir que cuando se ha hablado de Colegio, hemos dicho que no queríamos que nadie nos "chupara la sangre" (se ha demostrado con las bajísimas tasas de "colegiación") al mismo tiempo que decíamos aquello de "es que estamos hartos de que haya tantísimo intrusismo profesional".

El núcleo de la discusión son dos palabras que hay que mirarse con cuidado y un problema filosófico que hay que resolver. Las dos palabras son COMPETENCIAS y ATRIBUCIONES

Las COMPETENCIAS tienen que ver con los contenidos de la carrera, con aquellos conocimientos que los I4 deben tener para ejercer su profesión de manera competente y esto es la base para regular con planes de estudio ya que establece los contenidos mínimos de la titulación. En la situación actual, la Ingeniería Informática es una de las carreras que no tiene definida la ficha de competencias y por lo tanto queda a voluntad de cada universidad el decidir los contenidos que se enseñan.

Esta situación puede parecer que beneficia a las Universidades, que podrán desarrollar productos diferenciados de la competencia, pero también ocurre que a la larga no creo que beneficie a la profesión ya que no habrá un concepto claro y más o menos unificado de qué significa el título. Es decir, cuando el mercado busque a un profesional que deba cumplir las características A, B y C y un II se presente con su título obtenido en la UPC , en la ULPGC o en la ULDCDSA  los títulos no serán comparables ya que cada uno será "de su padre y de su madre".

A la larga, y teniendo en cuenta además una situación de globalización y de homogeneización de otras ingenierías a nivel europeo, ¿qué pedirá el mercado laboral? Además de buenos profesionales, se sentirá más cómodo con títulos con contenidos estandarizados (aquellos que tienen ficha de competencias a nivel paneuropeo) o con títulos de fama reconocida (provenientes de Universidades con reconocimiento global -- nadie rechaza un título del MIT, aun sin conocer los planes de estudio, no? )

Las ATRIBUCIONES tienen que ver con actividades reguladas por Ley que hacen que, para realizarlas, sea obligatorio disponer de una titulación especial (por ejemplo, un Médico puede recetar antibióticos, pero un Físico no). En mi opinión, estas atribuciones no pueden salir de las Universidades, sino que deben ser los órganos legisladores quienes las atribuyan en función de lo que vaya necesitando la legislación vigente y lo que vaya reclamando la sociedad.

En estos momentos no existe ninguna actividad regulada en el mundo de la Informática (al menos que yo sepa), pero un ejemplo clarísimo de este tipo de actividad que si debería estar regulada es la auditoría de LOPD, donde la ley crea la necesidad de auditoría, explicita la figura del auditor y sin embargo no explicita quién y bajo qué supuestos puede realizar esta auditoría. El resultado de esta situación es bien conocido: todo Dios está haciendo auditorías de LOPD, sabiendo o sin saber, y además ISACA está intentando que la certificación CISA sea la necesaria para poder realizar estas auditorías. ¿No sería mucho más coherente (que no mejor) que fuera una certificación propuesta por el Colegio (inexistente?) ?

Por último, está el tema del PROBLEMA FILOSOFICO que comentaba al principio: creo que es muy importante tener en cuenta que la provisión de servicios Informáticos se nutre de un conjunto muy variado de titulaciones (a parte de las que no son explicitamente de informática y se pueden considerar como intrusismo profesional). Al igual que en la provisión de servicios de salud intervienen médicos, enfermeras, celadores, farmacéuticos... en la provisión de servicios TIC intervienen I4 , Ciclos Formativos, Telecos, etc.

Así, la duda filosófica que hay que resolver para zanjar este asunto es, ante todo, ¿qué es y para qué sirve un II ? Parece una tontería, así escrito; pero en las últimas dos semanas he recibido un par de inputs que refuerzan esta pregunta: 

por una parte, en una reunión en la que se comentaba la idoneidad de incorporar contenidos sobre la Gestión de Servicios TIC en los temarios de las universidades, ante mi afirmación de esto es importante si queremos que las Universidades formen a los profesionales que necesitarán mañana la sociedad y las empresas la respuesta fue: es que lo que no está claro es si las Universidades deben formar a los profesionales del mañana o a los investigadores del mañana

¡¡La Leche!! Si eso no está claro, todo lo demás se tambalea! Y además, eso explica lo alejado del mundo real que está un recién licenciado, no?

El segundo input fue el desayuno de trabajo que organizó la ATI y el FOBSIC para la presentación del informe "Los profesionales TIC en Catalunya, La visión empresarial de las necesidades a corto plazo", donde una de las afirmaciones que se hicieron fue que las empresas en realidad querían contratar titulaciones de FP (Ciclos Formativos), pero que en realidad había tal cantidad de Ingenieros, que acababan contratando ingenieros al mismo precio.

Esta problemática se podría mitigar aunque fuera ligeramente con el uso correcto (y divulgado) de esas fichas de competencias, de tal manera que las empresas supieran qué es un II y qué es un FP y los futuros alumnos supieran exactamente para qué se les va a capacitar en la elección de carrera de estudios que hagan.

Como CONCLUSION, creo que es necesario apoyar la definición de las competencias, que es importantísimo establecer claramente las competencias núcleo de la Ingeniería Informática y que esto no excluye que aparezcan competencias (conocimientos) propias de las Ingenierías Informáticas en otras carreras.

Al mismo tiempo, creo que los cuerpos legisladores deben regular alguna que otra parte de la profesión (como el ejemplo de auditor LOPD y quizás el de perito y alguno más que ahora no se me ocurre), pero no es algo que me quite especialmente el sueño.

Y, en definitiva, esa es mi opinión al respecto. ¿Huelga? No lo se... no hay suficiente unidad en el colectivo como para que yo crea que va a tener algún éxito. Además, una huelga de informáticos es algo sin precedentes y que es un arma lo suficientemente potente como para tener que tener muy pero que muy mucho cuidado en usarla... no se puede dar una respuesta desmesurada.

Ahora bien, manis? las que haga falta. en Barcelona está convocada ¿Y en tu ciudad?

 POSTDATA: No se dónde lo leí, pero en algún sitio decía que la II no tenía competencias definidas porque algún estamento había determinado que la Informática es una materia horizontal, utilizada en todas las ingenierías... Eso me puso de muy, pero que de muy mal humor porque es de una simpleza tan grande que no me lo podía creer.

En todas las casas del país hay un botiquín y posiblemente el 90% de los adultos nos automedicamos, pero no por ello la medicina es una materia horizontal ni la automedicación es buena. En todas las carreras se estudia Matemáticas, pero no por ello es una materia horizontal. Para sintonizar el TDT no necesito ser un Telecos, pero para diseñar la red de transmisión y su cobertura posiblemente si.

Señores... los Ingenieros Informáticos no sólo arreglan el PC del vecino cuando se estropea: también diseñamos el sistema de información del Servicio Nacional de Salud o los servicios de apoyo a la navegación de AENA y si eso se para, hay vidas en juego. Exactamente igual que cuando un arquitecto diseña un edificio.

¿En qué otra ingeniería caben las competencias de Arquitectura Tecnológica, SOA, Calidad del Software, Seguridad de la Información o Gestión de Servicios? ¿En la de Física, Matemáticas, Telecos? ¿O en la carrera de Derecho? [porque todos usan un PC para su trabajo... y mi primo hizo un cursillo en CCC]

La Informática es algo más que el Word y el Excel.

Perdón por el ladrillo.

[Imagen por Michael Connors en Morguefile]