procesos

Reflexiones: SCRUM y 5M

Tenemos visiones parciales, incompletas, segregadas… Es inevitable.

Fue hace unas semanas.

A los alumnos de un grado en informática (es un ejemplo, pero es real) les enseñan ya metodologías ágiles e incluso cómo desencadenar un proceso de design thinking para afrontar un wicked problem, con toda su artillería metodológica… pero nadie les habla de cómo resolver un problema que probablemente tenga poco de wicked.

Y es que espero que nadie, a estas alturas, estimados lectores, se plantee siquiera que SCRUM pueda garantizar un camino de éxitos, exento de problemas y solo sujeto a un número incierto de iteraciones tras las cuales, sin duda alguna, aparecerá el santo grial…

Es más, las metodologías ágiles y el pensamiento de diseño están concebidos como un reto y no como un proceso de resolución de un problema, porque incluso cuando el problema es el origen de todo (algo extremadamente frecuente e incluso recomendable), el trabajo se centra en el reto de superarlo y no en corregirlo, independientemente de si se atacan las causas o no, mediante dosis masivas de observación, pensamiento lateral y experimentación.

El camino es diferente, gratificante, desafiante y motivador… pero no siempre resuelve un problema, sino que en muchas ocasiones elimina sus efectos o la necesidad de que éstos nos afecten o de que ni siquiera nos lo tengamos que plantear.

Y claro… a veces los problemas son tozudos y no quieren “dejarse desaparecer”, jejeje…

Un buen SCRUM trata de garantizar que se alcancen las funcionalidades requeridas y un buen diseño de UX se preocupa de satisfacer e incluso superar las expectativas del cliente… pero en cualquier caso, durante el desarrollo de un proyecto, en su implantación y posteriormente a su implantación, surgen problemas que muchas veces los equipos no saben cómo afrontar.

Y si han trabajado con proveedores recientemente en un marco SCRUM, estoy seguro de que entienden de qué les hablo.

¿Cómo han tratado de corregir sus proveedores un problema relacionado con la entrega de un producto con rendimientos insatisfactorios o claramente por debajo de lo esperado, a pesar de numerosas interacciones? ¿Cómo han abordado retrasos significativos que incluso han afectado el potencial de su negocio como cliente? ¿Cómo han gestionado el aprendizaje posterior y cómo se lo han comunicado?

Mira, lo hemos hecho mal… pero hemos aprendido. Nos vamos a hacer cargo de esta y esta otra manera y, además, te vamos a contar cómo hemos analizado los problemas, cuáles han sido las causas que creemos los han motivado y qué cambios vamos a introducir para que no nos vuelva a ocurrir“. ¿Recuerdan a algún proveedor que haya adoptado una iniciativa similar? ¿La han adoptado en sus propios equipos para con sus clientes? No, ¿verdad?

El mundo de los servicios de consultoría, ingeniería o diseño no está en general acostumbrado a este tipo de relación con sus clientes. Para un desarrollador de software, que su cliente haga de beta tester, o que incluso lo haga durante semanas y en correcciones sobre correcciones, entra dentro de lo que cabe esperar, dentro de lo que puede ser normal que pase.

Eso es un anatema en el mundo de la industria. Pecado mortal. Si haces algo así, estás fuera.

Y sin embargo, muchos de los problemas que surgen en el desarrollo de un proyecto de software no son diferentes a los problemas que surgen en cualquier otro orden de la vida, en cualquier otro tipo de negocio, tecnología o disciplina. O sea, que las metodologías clásicas de resolución de problemas (sí, incluidas las viejas y nuevas herramientas de calidad y calidad total) son perfectamente aplicables.

A los que ya hemos pasado de los 50, nadie nos enseñó en nuestras carreras cómo resolver un problema en una empresa. El conocimiento y las técnicas implicadas formaron parte del aprendizaje experimental que luego fuimos desarrollando en nuestras actividades profesionales, en función del sector o de la función que nos hubiera tocado en suerte. Entonces, la mejora continua, los conceptos lean o la calidad total no formaban parte de los estándares de aprendizaje y, aunque parezca mentira hoy, conformaban la cultura emergente… 😮

Lo alucinante es que, hoy en día, el poder de lo cool esconda muchas veces carencias que, en estos tiempos, es increíble que se permita permanezcan en el territorio de la ceguera cognitiva de un profesional. Como en el caso del grado en informática con el que abría el post, el adiestramiento en los procesos de resolución de problemas está universalmente al margen del aprendizaje académico, cuando en mi opinión debería formar parte de una cultura generalizada de estar en el mercado de trabajo. Su transversalidad es absoluta.

Incluso si adoptamos SCRUM como metodología de desarrollo de proyectos. Veámoslo.

Imaginemos un “proyecto A” en el que se ha generado un conflicto con el cliente: se ha entregado con un retraso considerable, la calidad del producto está lejos de satisfacer las expectativas de quien paga, los costes de desarrollo se han disparado y ha habido que renegociar el contrato, o han surgido dificultades técnicas que han forzado al cliente a renunciar a determinadas funcionalidades deseadas.

Venga… seguro que no les es muy difícil acordarse de un proyecto en el que haya surgido alguno de estos “problemillas”… o varios de ellos a la vez…

Imaginemos pues que hemos hecho uso como estándar de metodologías ágiles y singularmente SCRUM. ¿Qué podemos hacer para aprovechar la experiencia para aprender y mejorar nuestro desempeño? ¿Cómo nos podemos hacer cargo del problema para robustecer nuestras competencias y habilidades en la gestión de proyectos? ¿Cómo identificamos nuestros errores para aprender de ellos y ser más competitivos, más eficientes, más efectivos y en definitiva mejores?

Da igual si se han sentido aludidos como clientes o como proveedores. Se trata de un problema para ambos y por lo tanto ambos pueden exprimirlo para aprender.

Es perfectamente posible hibridar el pensamiento de diseño con la utilización de herramientas de resolución de problemas. De hecho, y aunque los guay del design thinking no lo sepan, algunas de las herramientas que usan son o derivan directamente de aquéllas, jejeje… >:D

Veamos las clásicas 5M. Se trata de ser sistemático en el análisis de causas para que no se nos escape ninguna cuando tratamos de identificar el origen de un problema. El objetivo es siempre determinar todas las causas que provocan su aparición, para atacar la raíz de las mismas y evitar que en el futuro se reproduzcan.

Suelen ser preludio del uso de otras herramientas adicionales (los 5 WHY o el diagrama de Ishikawa, por ejemplo) que nos ayudan a ello, pero hoy nos quedaremos en este primer paso, el más básico.

Cuando uno comienza a enfrentarse al análisis de un problema, es muy recomendable escoger un esquema mental que ayude a colocar el foco de nuestra mente en todos y cada uno de los ingredientes relevantes que suelen ser origen de cualquier problema, sin olvidar ninguno. Un brainstorming simple, abierto y no guiado por restricciones bien segmentadas, suele conducir siempre a lugares comunes, lo que implica que habrá aspectos que se nos escapen del análisis y, en definitiva, que el problema conservará potencial de reaparición.

Si hemos sido buenos profesionales y hemos tratado de corregir nuestros errores y aprender de ellos, pero no lo hemos hecho con método y los problemas se repiten a pesar de las acciones tomadas, acabaremos pensando en lo buenos o malos que somos… y no en cómo hacemos lo que hacemos. Mal camino.

Las 5M proponen que concentremos nuestra mente en identificar las causas de un problema (las razones por las que un proyecto ha sido fallido) en 5 focos diferentes:

  • Máquina: causas relacionadas con el mal funcionamiento o la insuficiente capacidad de proceso de máquinas, equipos o herramientas.
  • Método: causas relacionadas con el mal uso o la no aplicación adecuada de metodologías contrastadas o de estándares de trabajo definidos.
  • Materiales: causas relacionadas con el uso de materiales de insuficiente calidad o inadecuados para la función a desarrollar.
  • Mano de obra: causas relacionadas con bajos rendimientos personales, insuficientes competencias técnicas, errores humanos o comportamientos dañinos para el proyecto.
  • Medio: causas relacionadas con factores del entorno que tienen capacidad de influir en el rendimiento de producto o en el desarrollo del proyecto.

Pues vayamos a analizar cómo aplicar las 5M al “proyecto A” que mencionábamos antes, un proyecto gestionado con SCRUM… que no ha ido bien.

A pesar de que SCRUM es en sí mismo una metodología y de que por lo tanto lo más fácil es que nos surjan preguntas sobre el funcionamiento del método en sí mismo o sobre las personas (al ser un proyecto donde los recursos fundamentales suelen ser de conocimiento), en función del tipo de proyecto o problema podríamos hacernos preguntas como las siguientes:

  • Máquina:
    • ¿Se adecuaban las interfaces, nuevas o disponibles, que hemos utilizado, a las especificaciones técnicas? ¿Y al lugar de uso? ¿Por qué no?
    • ¿Su robustez y calidad eran las necesarias para un funcionamiento continuo y sin fallo? ¿Estaba todo ello garantizado? ¿Por qué no?
    • ¿Estaba la máquina en que se insertaba o integraba nuestra solución, preparada para ello? ¿Cumplía las necesidades mínimas para absorber el funcionamiento del nuevo sistema? ¿Por qué no?
    • ¿Eran las plataformas tecnológicas usadas las adecuadas para las necesidades del proyecto? ¿Estaban suficientemente disponibles? ¿Eran seguras? ¿Se disponía de redundancia, respaldo o alta disponibilidad? ¿Por qué no?
    • ¿Se disponía de la suficiente capacidad de cálculo y en el tiempo preciso? ¿Por qué no?
    • ¿Disponíamos de planes de contingencia para el fallo en nuestras instalaciones? ¿O frente a fallo catastrófico? ¿Por qué no?
  • Método:
    • ¿Se definió adecuadamente la misión del proyecto? ¿Representaba fielmente el objetivo deseado? ¿Existía una comprensión compartida en el equipo y con el cliente del significado, las limitaciones y las implicaciones de la misma? ¿Por qué no?
    • ¿Era claro el campo de decisión interna del equipo y los elementos que necesitaban de validación externa? ¿Se respetó? ¿Por qué no?
    • ¿Recogía adecuadamente el contrato las expectativas para el producto, los plazos, las limitaciones y condicionantes del proyecto, las formas y penalizaciones de pago, la propiedad de los fuentes y de los datos o los niveles de servicio, por poner algunos ejemplos? ¿Por qué no?
    • ¿Se definieron con la suficiente precisión las funcionalidades del product backlog? ¿Y las de los sucesivos sprint backlog? ¿Por qué no?
    • ¿Se construyó una estructura de releases y sprints razonablemente ajustada a la naturaleza y necesidades del proyecto? ¿Por qué no?
    • ¿Se definieron con suficiente detalle las acciones a desarrollar en cada sprint? ¿Se desglosaron lo suficiente, en dimensiones manejables? ¿Había suficiente conocimiento en el equipo como para estimar con la suficiente aproximación el coste en horas de cada acción? ¿Por qué no?
    • ¿Se ajustaron las dedicaciones previstas a las disponibles? ¿Mostró habitualmente el burn down chart un ajuste razonable de recursos y necesidades? ¿Se establecieron acciones para corregir las desviaciones? ¿Por qué no?
    • ¿Se realizaron sistemáticamente las reuniones diarias? ¿Y los cierres de sprint? ¿Por qué no?
    • ¿Se utilizaron como herramienta eficaz de gestión las herramientas de gestión visual? ¿Por qué no?
    • ¿Fueron los entregables, en general, bien recibidos por el cliente? ¿Estaba su estructura y contenido bien definidos con antelación? ¿Respondían claramente a una funcionalidad del backlog que podía ser testada? ¿Respondían a una necesidad de feedback para consolidar el avance del proyecto? ¿Por qué no?
  • Materiales:
    • ¿Las carcasas, los soportes del interfaz y en general de los equipos instalados, eran adecuados a la agresividad del entorno de trabajo (acidez, salinidad, partículas en suspensión, humedad, presión, temperatura…)? ¿Por qué no?
    • ¿Los materiales de los soportes eran adecuados para la transmisión o recepción de señales inalámbricas (evitando encajonar en aluminio, por ejemplo, la recepción de señales de geoposicionamiento)? ¿Se había previsto prestar atención a este asunto? ¿Por qué no?
    • ¿Eran los equipos, interfaces físicas, soportes y conexiones, suficientemente robustos como para impedir casos de daño accidental, vandalismo o robo? ¿Por qué no?
    • ¿Respetaban los materiales utilizados las normativas del sistema en que se integraban, incluyendo compatibilidad electromagnética, reglamentación, seguridad, eficiencia energética o reciclabilidad? ¿Por qué no?
  • Mano de obra:
    • ¿Hemos destinado al proyecto a las personas adecuadas? ¿Eran técnicamente competentes y profesionalmente responsables, a los niveles necesarios? ¿Por qué no?
    • ¿Hemos podido atender a las puntas de trabajo con la flexibilidad necesaria en el equipo o fuera del mismo? ¿Por qué no?
    • ¿Ha habido un nivel de dedicación y compromiso con el proyecto que impida negligencias? ¿Por qué no?
    • ¿Ha habido un nivel de comunicación fluido entre los miembros del equipo, entre éstos con el product owner, entre éste y el scrum master y, en definitiva, entre el equipo y el cliente? ¿Por qué no?
    • ¿Se han cubierto adecuadamente las funciones de product owner o scrum master? ¿Se han sabido separar bien del trabajo operativo, cuando procedía? ¿Por qué no?
    • ¿Ha estado el proceso libre de interferencias significativas de elementos externos (jerárquicos, por ejemplo, o presiones procedentes de entornos multiproyecto) en la capacidad del equipo de gestionar el proyecto y tomar decisiones? ¿Por qué no?
  • Medio:
    • ¿Ha sido posible asegurar la buena marcha del proyecto frente a la aparición de tensiones laborales o sociales? ¿Por qué no?
    • ¿Ha estado el proyecto libre de herencias nocivas fruto de experiencias previas cliente-proveedor o de relaciones personales tóxicas internas o externas al equipo? ¿Se previeron y gestionaron? ¿Por qué no?
    • ¿Han aparecido, en el transcurso del proyecto, limitaciones no previstas (internas o externas) o modificaciones en los objetivos, que introducían variaciones relevantes en la misión asignada al mismo? ¿Se han negociado a satisfacción de todos los stakeholders implicados? ¿Por qué no?
    • ¿Se disponía de los espacios y medios de trabajo necesarios para el proyecto y para las dinámicas de trabajo en equipo? ¿Por qué no?
    • ¿Ha funcionado adecuadamente la estructura corporativa que aportaba los recursos auxiliares necesarios (en compras, subcontratación, asesoría legal o selección de personal, por ejemplo)? ¿Por qué no?

Una vez obtenidas las primeras respuestas, conviene preguntar de nuevo a cada una “¿por qué?”, sucesivamente hasta 5 veces (como los niños en periodo de descubrimiento), para acercarnos a la verdadera causa raíz. Y una vez identificada una causa raíz, las soluciones se mostrarán evidentes en un alto porcentaje de las veces.

Para terminar, es altamente recomendable hacer un test de coherencia con un análisis de potenciales causas derivadas de posibles fallos en personas que hubieran podido intervenir, directa o indirectamente, en el proyecto. Se trataría de seguir los siguientes pasos:

  1. Identificar las personas implicadas: scrum master, product owner, miembros del equipo, director de proyecto, cliente, responsable de compras, proveedores, responsable de infraestructuras, comercial, responsable de control de costes…
  2. En cada una de ellas, pensar si se han producido fallos de rigor o de competencia, siempre teniendo en cuenta dos facetas de cada fallo: por qué sucedió algo indeseable, por un lado… y por qué no nos enteramos, o nos enteramos demasiado tarde como para mitigar sus efectos, por otro.
  3. Verificar que los fallos que así encontremos estaban ya contemplados, aunque fuera de otra manera, en el análisis de causas anterior.

El objetivo de este test de coherencia no es “meterle el dedo en el ojo” a nadie. No se trata de buscar culpables sino soluciones, no lo olvidemos. Se trata de un proceso metodológico que busca exclusivamente robustecer nuestro desempeño y evitar la reproducción de un problema en el futuro.

Obviamente, la lista anterior de preguntas asociadas a cada una de las 5M no es exhaustiva (cada proyecto tendrá sus preguntas adecuadas)… y el ejemplo no es exclusivo: SCRUM puede utilizarse para gestionar un proyecto de desarrollo de producto físico o incluso de creación de una nueva línea de negocio: cualquier entorno donde la incertidumbre sea elevada y exija moverse en ese entorno.

De hecho, si el proyecto descansa, total o parcialmente, sobre un producto físico, la aplicabilidad es incluso más evidente.

¿Y sobre un intangible, como un “negocio”? Imaginen, por ejemplo, un desarrollador de software que decide “montárselo por su cuenta”: darse de alta como autónomo, construir su propio modelo de negocio y enfrentarse al mercado como empresa independiente o como freelance. Imaginen que… no le va bien. Que no vende, a pesar de ser una persona técnicamente competente y de volcarse personalmente en construir su marca personal y en conseguir que ello le reporte ingresos suficientes como para que merezca la pena. “¿Por qué no vendo?” es una pregunta que se hará cada noche, ¿verdad? “¿Qué puedo hacer para cambiar la situación?”

Pues les aseguro que pensar en clave 5M sobre lo que identifique que no funciona en cada uno de los elementos de su canvas de negocio (supongo que a definirlo ya habrá llegado, claro) le va a ayudar a afrontar ese problema porque aflorará preguntas tan importantes como las siguientes:

  • ¿Qué tecnología estoy utilizando y qué alternativas tendría?
  • ¿Qué me están aportando realmente (y cómo) mis aliados y mi red de apoyos para la configuración de equipos de proyecto o para completar mi propuesta de valor?
  • ¿Gestiono los capítulos principales de mi estructura de costes?
  • ¿Sé realmente quiénes son mis clientes o quiénes tendrían que ser? ¿Me ayuda a entenderlo la estratificación que he hecho… suponiendo, claro está, que la haya hecho?
  • ¿Cómo me relaciono con mis clientes? ¿Sé qué necesitan? ¿Y el mercado? ¿Cómo lo averiguo? ¿Cómo lo conecto con mi propuesta de valor? ¿Cómo les hago percibir que me necesitan a mí?
  • ¿Con qué recursos cuento, con qué tecnología o equipos, para mi trabajo o para soportar mi propuesta de valor?
  • ¿Cómo lleno mi dealflow de proyectos?
  • ¿A qué he decidido expresamente renunciar? ¿Qué renuncias estoy dispuesto a hacer?

Lo hará en otro orden, adaptando estas preguntas genéricas a su circunstancia particular y probablemente desglosándolas en otras más específicas… pero lo hará.

Venga… Les dejo un ejercicio para casa: ¿identifican de cuál de las 5M puede haber procedido cada una de estas preguntas? 🙂

Vibraciones: Spiral-Up Process

Como un gran círculo“. Así titulaba hace ahora algo más de un mes Manel Muntada uno de sus artículos, revisando su vida al asomarse y descubrir en el presente conexiones con lugares vitales recorridos años atrás.

La curva loxodrómica, la espiral o la cinta de Moebius aparecían en los comentarios como analogías alternativas que respondían fielmente a lo que muchos creemos observar al ascender y ver el camino recorrido desde las alturas de la distancia. A mí me recordó la conversación a la teoría “spiral-up” de Hiroshi Tasaka… y Manel cerró la ventana tildándome de “ingeniero…”, en una única palabra que lo expresaba todo. 🙂

Pero ahí le decía que escribiría sobre ello… y aquí estoy.

Hiroshi Tasaka es un personaje singular. Realmente no sé cómo calificarlo, porque en las reseñas de su biografía aparecen desde su capacitación como ingeniero nuclear o su actividad como profesor de la universidad de Tama (Tokyo), hasta su más conocida faceta de escritor (lleva más de 40 libros), de filósofo (construyendo su pensamiento desde la dialéctica) o de fundador del Sophia Bank (banco de conocimiento o think tank orientado a incubar innovación social), pasando por su trabajo en numerosas empresas o su actividad como asesor de organismos gubernamentales e internacionales.

He coincidido con Tasaka en dos ocasiones, ambas de la mano de infonomia. De la primera de ellas, el iFest’08, se destiló un vídeo titulado “la paradoja de la sociedad del conocimiento” (en un momento en el que la producción de contenidos era, más que hoy, uno de los principales propósitos de infonomia) que ha circulado con generosidad en la red.

Del segundo, ya ligado a la realidad actual de Co-Society, salieron mis notas sobre filosofía dialéctica, uno de los tres métodos que él postula como válidos para identificar las tendencias evolutivas principales que está recorriendo la humanidad. El Spiral-Up Process” que les introduzco a continuación es una de las cinco leyes de la dialéctica que él postula como válidas para interpretar el camino al futuro. Probablemente la más importante.

Para Tasaka, la humanidad camina hacia el futuro de forma recurrente, volviendo a lugares ya visitados en su concepción básica, pero no a modo de círculo ni tan siquiera de espiral divergente, sino como una espiral cilíndrica en la que la evolución implica la adquisición de un nuevo valor, un “upgrade”.

Para Tasaka, la interpretación de cada vuelta espiral es que los sistemas que desaparecen adquieren tiempo después un nuevo valor que, socialmente reconocido, les convierten de nuevo en sistemas vivos, pero reinventados.

Gráficamente, por lo tanto, no es un círculo recursivo como el del universo de Sísifo, sino una progresión continua que muestra rangos recurrentes en la propuesta de valor, pero siempre evolucionando.

La verdad es que podría haber incluido este post en la categoría de “personas inquietas“, pero, aunque he estado físicamente en el mismo espacio que él en las dos ocasiones que les mencionaba, nunca hemos mantenido una conversación particular. Así que no puedo decir que le conozco… 😉

Les recomiendo leer detenidamente el documento enlazado unas líneas atrás sobre los tres métodos que postula Tasaka para prospectar el futuro, pero si no tienen las suficientes ganas de hacerlo, a pesar de su brevedad, les dejo una alternativa encantadora.

Creo que éste es un vídeo mucho menos conocido. Está en inglés, pero verán que es muy sencillo de entender (y en cualquier caso, les dejo aquí una traducción casera… que espero que no miren salvo en caso de extrema necesidad).

Se trata de la intervención de Hiroshi Tasaka en una conferencia TEDex Tokyo, en 2010. Bajo el título “Capitalismo Invisible“, es solo un cuento zen, una fábula poética que, como todo lo que puede describirse bajo esos calificativos, parece que simplemente narra una historia ingenua que bordea la simpleza, pero que esconde reflexiones de las que de verdad importan.

Creo que en él encontrarán, contado de otro modo, el espíritu del “spiral-up process”.

Háganme caso: escúchenlo atentamente… al menos dos veces. Yo llevo ya unas cuantas…

Libros que inquietan: “Innovar para ganar – El modelo ABCDEF”

Imagínense un libro que intente explicar cómo ganar al mus en 15 capítulos, pero que cuente las supuestas claves del triunfo entre los capítulos 13 al 15, dejando los primeros 11 para la introducción y para describir el significado de los ases, de los doses, de los treses… (hasta de las sotas, de los caballos y de los reyes) y el 12 para explicar las normas.

Pues esa es la estructura del último libro de Fernando Trías de Bes y Philip Kotler, quienes pretenden resumir todo lo que se ha publicado y ya es conocido en materia de innovación (incluidas su propias aportaciones previas), entendido y ordenado como un proceso al que su carácter no lineal da permiso para ser considerado como modelo.

Claro que, a mi modo de ver, el que hayan dotado al libro de ese extraño orden que les contaba (que además explican, digámoslo así, usando una baraja con las cartas bien mezcladas…) ha hecho, se lo reconozco, que el texto me haya resultado de difícil lectura.

Y no es que los autores utilicen palabras o estructuras semánticas complejas o elevados niveles de abstracción en los conceptos. El lenguaje es más bien simple. Pero conviene apuntar que lenguaje sencillo y simplicidad no son necesariamente sinónimos, que en la noción de simplicidad… hay más cosas.

Advierto que lo he usado como lectura de tumbona y eso condiciona opiniones, pero realmente no he conseguido que me enganche: iba recorriendo sus páginas a base de determinación… y no es cuestión en época estival.

Así que he llegado a pensar que mi capacidad de concentración en una lectura se había deteriorado notablemente, hasta el punto de que elegí como siguiente libro de verano una novela ligera (cuyas más de 300 páginas de la edición de bolsillo leí afortunadamente de un tirón, en un único día de mal tiempo) para comprobar que no… o al menos que no del todo.

Entonces, dirán… ¿por qué traer aquí este libro?

Pues por lo mismo que los demás libros que han pasado por esta bitácora: porque su lectura me ha inquietado lo suficiente como para que fuera tomando una serie de notas que pretendo aplicar en la práctica y de inmediato.

Trías de Bes y Kotler identifican 6 roles que deberían encontrarse activos a lo largo de un proceso de innovación, que ordenan alfabéticamente porque los nombran por 6 palabras que empiezan por letras de la “A” a la “F”:

  • Activadores: proporcionan el marco general de innovación, lanzan iniciativas y definen las pautas generales que condicionarán las decisiones de lanzamiento de proyectos.
  • Buscadores: suministran información, diferente en las diferentes etapas del proceso, en forma de informes de evolución, análisis de tendencias, en su categoría o en adyacentes…
  • Creadores: generan ideas, de innovación incremental o con potencial disruptivo, si es el caso, pero siempre con perspectiva de cambio de lo ya establecido o conocido… y definiendo cada concepto creado dentro del marco general del mercado.
  • Desarrolladores: consideran y trabajan para superar las limitaciones comerciales, tecnológicas, productivas o financieras que aparecen rodeando a las ideas generadas por los anteriores, hasta obtener un producto o servicio “industrializable”.
  • Ejecutores: llevan el producto y el servicio hasta el mercado, ocupándose de la producción y del análisis de respuesta del mercado hasta asegurar el retorno previsto.
  • Facilitadores: de muy diversos tipos, ayudan al proceso en muy diversas formas y fases, desde aportar técnicas creativas o desbloquear equipos de proyecto, hasta aprobar inversiones o decidir qué proyectos se priorizan, normalmente apoyados en técnicas, métodos y herramientas.

Aparentemente, además, podrían actuar en una secuencia lineal (siguiendo un proceso clásico de alineación y atención estratégica, ideación, gestión de proyecto e industrialización y comercialización), pero ya advierten los autores, en una de sus principales aportaciones, que esto no será así, puesto que todos los roles deben entregar y recibir aportaciones relevantes de los demás en las distintas fases del proceso.

De hecho, Trías de Bes y Kotler proponen una interesante y clarificadora tabla sintética de aportaciones colaborativas que se van cruzando entre los cinco primeros roles.

Los facilitadores quedan fuera de la tabla porque su función es colaborativa per se.

Otra tabla más conteniendo qué figuras pueden desempeñar los roles anteriores dentro de la mayoría de las organizaciones y una última con cuáles podrían ser entregables elaborados por cada uno de esos roles, completan (junto con algunos gráficos y criterios adicionales) un modelo sobre el que dibujar la elección que cada uno hagamos en nuestra casa.

Pero lo que a mí más me ha interesado, como suele suceder, es la lista de ideas que me iban surgiendo al hilo de la lectura de las páginas del libro. Ideas algunas muy menores, otras más importantes, pero todas ellas traducidas con exactitud al lenguaje que yo comprendo de mi organización.

La lista que va a continuación contiene de qué van algunas de ellas, para que entiendan mejor de qué hablo. No es una lista exahustiva ni de detalle, claro… y no tiene demasiado sentido que lo sea porque, como advertía en el párrafo anterior, es una traducción exclusiva y subjetiva de aspectos marginales del texto a una realidad muy particular, que es la que yo observo de mi empresa:

  • formas de retribución en especie para proyectos de innovación;
  • papel del responsable de un proyecto en los procesos de ideación creativa;
  • enmarque presupuestario de proyectos de alto impacto;
  • formación estable en técnicas creativas;
  • componentes para una carta de servicios del área de innovación;
  • liderazgo y comunicación con la organización;
  • representación visual, de la cartera, de los recursos, de los niveles de innovación…

Así que si leen el libro… deberán hacer la suya. 😉

Innovar para ganar – El modelo A-F“. Fernando Trías de Bes y Philip Kotler, 2011. 349 páginas. Ediciones Urano (colección Empresa Activa). ISBN: 978-84-92452-74-3

Reflexiones: análisis relacional de decisiones relevantes

Acabamos con este post la serie de cuatro con la que vamos llegando al título de hoy: el análisis relacional de decisiones relevantes como forma diferente de abordar la mejora sistemática de procesos.

Habíamos comenzado entendiendo que, según Sveiby, el valor se genera cuando se activan relaciones entre personas, estructuras internas o estructuras externas a las organizaciones, en cualquiera de las nueve formas distintas que se identificaban.

Después advertimos que, en el marco de cualquiera de esos canales relacionales activados, es cuando las personas tienen que tomar decisiones cuando aportan ese valor. Finalmente, que siendo todo lo que hacemos un proceso o parte de un proceso… podemos concluir que el rendimiento de cualquier proceso depende de la forma en que las personas que participan en el mismo adoptan decisiones, en el cauce de relaciones que activan para ello.

Nuestro desafío era llevar a una práctica útil esta conclusión. Establecimos una sistemática de revisión de procesos que analizaba 5 fuentes de información para la mejora, que se recogen en la figura adjunta.


Describamos, pues, cómo desarrollamos el análisis de decisiones. Estamos hablando, fundamentalmente, de cómo abordamos la revisión y mejora sistemática de los grandes procesos de gestión de la organización (apenas una docena en nuestro caso). La revisión de los cinco puntos anteriores se planteaba para cada uno de esos procesos con una frecuencia anual, lo que dejaba margen para que cada año se analizaran en equipo una o dos de las decisiones recogidas en la lista de decisiones relevantes del proceso.

¿Cómo lo hicimos?

En primer lugar, eligiendo una decisión sobre la que trabajar, que previamente definíamos identificando quién o quiénes la adoptaban, qué conocimiento se requería para adoptarla… o en dónde o en quién residía la información necesaria, por ejemplo.

Una vez elegida, había que desmenuzarla de una forma original: identificando todos los canales relacionales que pudiéramos definir en el entorno de esa toma de decisión.

Pongamos un ejemplo…

Supongamos que estamos analizando la siguiente decisión: “decidir la factibilidad técnica de un proyecto”. Siendo P = personas, EI = estructura interna y EE = estructura externa, posibles relaciones serían:

  • EE>>P – El cliente solicita una oferta al director comercial.
  • P>>P – El director comercial reenvía la oferta al jefe de proyecto.
  • EI>>P – El plano y las especificaciones de oferta llegan al jefe de proyecto.
  • P>>EI – El jefe de proyecto consulta la lista de normas.
  • P>>EI – El jefe de proyecto solicita las normas disponibles a la base de datos.
  • P>>P – El jefe de proyecto solicita las normas no disponibles al responsable de normas.
  • P>>EE – El responsable de normas gestiona la adquisición de normas no disponibles con el cliente o el organismo de normalización.
  • EE>>P – El organismo regulador envía las normas al responsable o el cliente al director comercial.
  • P>>P – Se remiten las normas conseguidas al jefe de proyecto.
  • P>>EI – El jefe de proyecto analiza las normas necesarias.
  • P>>EI – El jefe de proyecto interpreta factibilidad consultando con la información técnica disponible.
  • P>>P – El jefe de proyecto consulta dudas de fabricabilidad con un experto.
  • P>>EI – El jefe de proyecto mantiene el sistema de normas.

En cada uno de estos pequeños pasos puede haber retrasos, dilaciones y errores. Cada uno de ellos pasa a formar parte del juego de prioridades de quienes tienen que hacer que sucedan… y estas personas pueden ser expertas o recién llegadas, estar ausentes de sus puestos de trabajo, tener relaciones emocionales complejas con sus interlocutores, utilizar canales de flujo de información seguros y rápidos o lentos y poco fiables…

En fin, que entendimos que teníamos que analizar cómo funcionaban los principales facilitadores de que todo fluyera satisfactoriamente en cada una de esas relaciones. Agrupamos 4 tipos de facilitadores sobre los que tratamos de identificar problemas:

  • Culturales y organizativos:
    • Querer: detectar barreras emocionales.
    • Saber: insuficiente competencia para la acción.
    • Poder: incapacidad de activar las acciones precisas en el momento necesario.
  • Métricos: ausencia de señales que detectaran fallos.
  • Sistemas de transmisión de conocimiento: dificultades en el acceso a la información o a conocedores.
  • TIC: flujos de información manuales y no asegurados o verificables.

La primera parte del trabajo era, por lo tanto, hacernos preguntas sobre cómo andábamos de facilitadores para cada relación detectada, es decir, aflorar problemas que normalmente quedan ocultos en los procesos de gestión. La segunda… encontrar unas soluciones que, desmenuzadas de esa forma las dificultades, en buena parte resultaban evidentes.

Los dos cuadros que adjunto a continuación son una muestra de la sencillez de la herramienta que utilizamos.

Mantuvimos viva esta manera de promover la mejora de los procesos durante 3 años. Luego, un cambio organizativo profundo, la llegada de la crisis y el adelgazamiento de las estructuras de apoyo la hicieron languidecer.

Y sin embargo… le aseguro que es una aproximación muy diferente a las cosas, una mirada desde las barreras que las personas somos o construimos, a veces consciente y a veces inconscientemente, para impedir relaciones y decisiones efectivas.

Espero que hayan disfrutado del camino.

______

Los 4 posts de la serie son los siguientes:

  1. La empresa relacional de Sveiby.
  2. Conocimiento y decisiones.
  3. Procesos y decisiones relevantes (+ mapas QSQ).
  4. Análisis relacional de decisiones relevantes.

Reflexiones: procesos y decisiones relevantes (+mapas QSQ)

En el post anterior dibujábamos la segunda pieza del puzzle que vamos construyendo para explicar cómo intentamos llevar la noción de empresa relacional de Sveiby a la práctica.

Concluíamos extrapolando a la totalidad de los procesos de la organización, la experiencia que relacionaba el valor aportado por el trabajo de conocimiento con la toma de decisiones.

Vista así, su derivada natural hacia la revisión y mejora sistemática de los procesos se dibujaba con facilidad. Para ello:

  1. revisamos el diagrama de cada proceso sobre el que estábamos trabajando;
  2. identificamos qué decisiones relevantes se debían adoptar en cada uno de sus subprocesos;
  3. configuramos la lista de decisiones relevantes del proceso, agrupando y priorizando las anteriores;
  4. generamos un método para analizar cambios y mejoras en la toma de esas decisiones relevantes.

En esquema, para los tres primeros puntos hicimos lo siguiente:

Bueno, he dicho que se veía fácil… pero hablaba del “mapa de carreteras”.

Sin que necesitáramos profundizar en ninguna ciencia pura ni infusa, sí teníamos un trabajo de definiciones simples que acometer: por ejemplo… qué hace relevante a una decisión.

Decisiones principales.

El que el producto o el servicio sobre el que estemos actuando avance de una fase de proceso a otra o no lo haga, o las condiciones en que ello se produzca, dependen siempre de una o varias decisiones que uno o varios de los agentes del proceso adopten.

Sin embargo, analizar todas las pequeñas decisiones que se producen en la sucesión concatenada de actividades de un proceso es una tarea imposible. No arriesgamos nada asumiendo que abordarlas en su integridad conduce desde el momento mismo de intentarlo a la parálisis por el análisis.

Era necesario, por tanto, focalizar mucho el esfuerzo de análisis, seleccionando aquellas decisiones que tuvieran un impacto considerable sobre el proceso, pero… lo que no podíamos evitar era identificar, al menos, las decisiones principales implicadas en la gestión del proceso. Para ello realizamos un simple brainstorming apoyado en tres guías:

  • recorrido por los subprocesos del ciclo PDCA del proceso, poniendo el foco en sus descripciones, sus subproductos, sus responsables de validación y las relaciones con los otros subprocesos;
  • recorrido por los indicadores asociados a la medición de la eficacia, la eficiencia y la satisfacción de los clientes del proceso;
  • recorrido por las entradas al proceso y por sus “materias primas”.

La lista de decisiones relevantes.

Obtenida una lista de decisiones principales, sólo había que definir criterios para elaborar una matriz de priorización y obtener así las decisiones relevantes del proceso, aquéllas sobre las que en el futuro centrar el análisis y las propuestas de cambio.

Consideramos en todos los casos 2 criterios básicos (comunes a todos los procesos) y 3 subcriterios para cada uno de los anteriores (que debían definirse específicamente para cada caso). Los criterios básicos fueron:

  1. Impacto en la satisfacción y expectativas del cliente.
  2. Impacto en el rendimiento interno.

En un proceso productivo, por poner un ejemplo, los subcriterios fueron, para el primer criterio: calidad, coste y plazo; para el segundo: inactividad, defectivo y eficiencia. Resultó igualmente sencillo para el resto de los procesos.

Una tarde es suficiente para identificar las decisiones principales y para acordar los criterios de ponderación. Si la aplicación de estos últimos a las primeras, se deja como “tarea para casa” de los miembros del equipo (cuyo trabajo individual sea “cocinado” más tarde por un coordinador), habremos construido sin demasiado esfuerzo la lista de decisiones relevantes del proceso (que en nuestra experiencia oscilaba entre 10 y 20), un entregable cuya vigencia se mantendría por varios años.

Un interesante “efecto colateral”: el mapa QSQ.

Una vez obtenida la lista y antes de entrar a desmenuzar cómo se adoptaba cada decisión y cómo podía reducirse el riesgo de tomarla, decidimos detenernos un tiempo en identificar el conocimiento relevante asociado a cada decisión, quién tenía que enfrentarse a ella, con qué información contaba como apoyo (documentos o personas) y dónde podía localizarla a un nivel actualizado, tanto si se trataba de una fuente interna como externa.

Esta experiencia nos llevó a dos resultados prácticos: el primero fue que el simple hecho de hacerlo nos obsequió con una lista de acciones que debían ser desplegadas, pues se expusieron a la luz carencias en la protección del conocimiento explícito, de conservación del tácito, de disponibilidad de información básica o de explotación o simple acceso a la información disponible. El segundo, que la suma de conocimientos necesarios para la toma de decisiones nos permitía configurar un mapa de conocimiento del proceso.

El mapa de conocimiento sirvió de inmediato para algo muy interesante: los miembros del equipo dedujeron competencias asociadas, tanto técnicas como relacionales y de gestión, e identificaron a quiénes de entre ellos reconocían, para cada competencia, las mejores capacidades técnicas o de transmisión de conocimiento a otros.

El resultado de poner todo ello en negro sobre blanco fue lo que denominamos entonces “Mapa QSQ” (Quién Sabe Qué), en el que no voy a profundizar ahora porque me llevaría a un artículo insoportablemente largo y me sacaría, en cierto modo, de la ruta arrancada en las ideas de Sveiby (todo se andará…).

Pero una aplicación directa del mapa QSQ, en el proyecto de integración del personal directo en la gestión, dio lugar a una extraordinaria e innovadora propuesta en el diseño y la aplicación del plan de acogida de una persona nueva que se incorporara al equipo, cuyos miembros, desde conceptos de autogestión, se comprometían a reducir drásticamente el periodo de aprendizaje tácito del aprendiz, a mejorar la calidad y profundidad del mismo y, con ello, a recortar significativamente los costes económicos y no económicos de adaptación.

Aunque como es habitual… acabamos aplicando sólo algunos aspectos marginales de todo aquello.

Preparados para componer el puzzle.

Tenemos todas las piezas:

Sólo queda por tanto componer el puzzle, abordando lo que llamaremos el análisis relacional de decisiones… y por añadidura de procesos.

Lo haremos en el cuarto y último artículo de la serie.

¿Me acompañan?