procesos

Vibraciones: el desastre aeroportuario (… y de “norwegian”)

Era mi primer contacto con Norwegian, una compañía aérea que asaltaba el aeropuerto de Bilbao con horarios y precios excelentes. Como ven en la imagen del tweet, aquel martes del pasado noviembre estaba uno predispuesto a perdonar incluso 2 horas de retraso, a cambio de una experiencia de vuelo gratificante…

Semanas más tarde vino un segundo vuelo también con retraso y días después una cancelación con varias horas de espera para viajar en el siguiente… pero sobre todo con explicaciones escasas, muy tardías, poco creíbles y abiertamente contradictorias, que es lo que más cabrea, porque uno siente que le están tomando el pelo.

En consecuencia, decidí vetar a Norwegian para mis viajes… y así ha sido hasta esta misma semana en la que (oh, carne débil…) decidí darles una nueva oportunidad.

Un reto a la serendipia en Barcelona a media mañana me permitía salir con Vueling a una hora razonable, pero el afán de aprovechar el viaje me llevó a concertar otra reunión a la tarde… y eso dibujaba la propuesta horaria de regreso con Norwegian como una tentación de excelente encaje. Así que caí… 😉

La verdad es que el pasado martes (el día antes de mi viaje) ya me cancelaron la reunión de la tarde… así que igual tenía que haber empezado a pensar que todo el plan del día se empezaba a torcer y que eso solo era el comienzo, jejeje… pero uno no es supersticioso, qué se le va a hacer. 😛

El miércoles comenzó con el embarque en el Vueling VY 1421 de las 09:05, con todos dentro del avión un buen rato sin que pasara nada de nada, acumulando un retraso que en Barcelona ya fue de 25 minutos. El tráfico de la ciudad no ayudó precisamente a recuperarlo, así que llegué a mi cita un cuarto de hora más tarde de lo acordado… aunque el encuentro se celebró satisfactoriamente: hasta aquí, todo bien.

Luego me tocó “gastar” el tiempo que quedaba hasta las 18:30, claro, dada la anulación de la reunión de la tarde, así que después de comer un poco, empleé el tiempo lo mejor que pude en una tarde donde la humedad del verano mediterráneo se hacía notar. En fin… tras 5 horas de paréntesis vacío, vuelta al aeropuerto, a donde llegué a las 19:00, con tiempo sobrado para coger mi vuelo de regreso con Norwegian (D8 5734), de las 20:20.

Y aquí empieza la historia…

Puede que alguna hora o detalle se me bailen en la memoria, pero básicamente, esto que sigue es lo que pasó:

  • A la hora prevista para el embarque, dos azafatas de tierra de Norwegian estaban en el mostrador de embarque, pero todos veíamos que el avión aún brillaba por su ausencia en el extremo del finger. Al poco tiempo, nos comunicaban por megafonía que traía un cierto retraso debido a las condiciones climatológicas… y que la nueva hora prevista de embarque era las 20:00, lo que suponía unos 20 minutos de retraso.
  • Hacia las 19:30 había empezado a llover con fuerza en el aeropuerto de Barcelona, una tormenta de verano que duró los 10 minutos de rigor (literalmente), para dar paso de nuevo al sol. Poco después actualizaban la información y anunciaban que la llegada del avión se preveía para las 20:22. Sí, sí… “a-y-22”, así de exacto.
  • Visto que a esa hora seguía solitario el extremo del finger… volvieron a indicarnos por megafonía que, por causas climatológicas adversas, el retraso sería mayor y que se suministraría nueva información a las 21:00.
  • En ese momento, entre nosotros empezaron a cruzarse llamadas con familiares en Bilbao, quienes nos informaron de que había un fuerte viento, una de esas galernas que hacen de los despegues y aterrizajes en Loiu un parque de atracciones circunstancial… así que asumimos que ese era parte de nuestro destino del día y que tocaba esperar.
  • Esperar… hasta que, a las 20:50, nos informaban de que la hora estimada de embarque pasaba a ser las 22:00. Al mismo tiempo, un mensaje en los móviles actualizaba la información del vuelo (vía app de la compañía) notificando la salida del mismo para las 22:30.
  • En ese momento, me dirijo a una de las azafatas para pedirle un vale que nos permita tomar algo para cenar (ya que la hora a la que llegaremos a nuestras casas va a ser realmente tardía, muy probablemente por encima de las 24:00 para muchos), dado que “ya hay más de dos horas de retraso acumuladas para el vuelo“. Su respuesta inicial es que “no han pasado dos horas de retraso“. Cuando le muestro la notificación en el móvil de salida a las 22:30 (cuando el horario inicial era las 20:20)… me responde que sí, que entonces tengo razón… pero que “el límite de retraso son dos horas y media, no dos horas“. Insisto (aunque no discuto por no enredarme en ello), pero ella sigue en sus trece. Como pueden comprobar en la propia web de Norwegian, era mentira.
  • Mi comentario final en esa conversación fue que mejor sería que no tuvieran que darnos el vale transcurridas dos horas y media, porque eso significaría que el avión se retrasaba al menos hasta las 23:00… y eso implicaría que, con el aeropuerto de Bilbao cerrado (lo cierran a las 24:00) se cancelaría el vuelo. Su respuesta fue que, en efecto, “más vale que no tengamos que darles un vale, por el bien de ustedes“. De su frase y de su expresión facial, yo asumí que la probabilidad de que se cancelara… era muy alta. Pero me callé y me fui.
  • A las 22:12 corrió el rumor (algún pasajero había hablado con un familiar controlador) de que el avión acababa de aterrizar en el aeropuerto de Barcelona… pero no debió ser así, porque no llegó a la puerta de embarque hasta las 22:34.
  • A las 22:47, asomados a los cristales, comenzamos a ver cómo subían nuestras maletas a la bodega… y algunas personas volvieron a preguntar a las azafatas si realmente tenían confirmación de que iban a recibirnos en Loiu, recibiendo respuesta afirmativa, asegurando que en Bilbao habían confirmado que esperaban.
  • Pocos minutos después, en efecto, comenzaba el embarque. Primero tuvieron que acomodar a una persona mayor, recién operada, que iba en silla de ruedas. Eso justificaba unos minutos añadidos para el proceso de embarque… pero no que cuando las filas 1-15 comenzamos a entrar, tras haber pasado ya filas posteriores a la 16… observáramos que aún todo el mundo estaba en el finger y nadie había entrado. No recuerdo un embarque tan largo en toda mi vida. No puedo asegurarlo con total certeza, pero créanme que se aproximó… ¡a los 45 minutos!
  • A las 23:25 me dije a mí mismo que era un desconfiado: el embarque quedó completo, las puertas del avión se cerraron y el finger se retiró. Peeeero… nada más se movió.

  • A las 23:40, el capitán nos informa por la megafonía del avión de que Loiu cierra y que el vuelo queda cancelado. Lo hace sólo en inglés.
  • Brama el pasaje… y otro miembro de la tripulación pide disculpas y comunica (esta vez en castellano)… que el avión había sido desviado al aeropuerto de Palma por condiciones climatológicas adversas… ¡en Barcelona! Que retornaron a El Prat cuando les dieron permiso y que esa había sido la causa del retraso.
  • Los pasajeros, molestos por no haber sido informados hasta ese momento de la situación real, pero en escrupuloso orden, abandonamos el avión con el mensaje de que a la salida nos darán instrucciones.
  • A la salida no hay nadie.
  • Cuando ya todo el mundo ha salido (casi 15 minutos después) y nadie sabe qué debe hacer, una de las azafatas aparece para decirnos que allí no va a ir nadie a resolver nada, que tenemos que ir a la oficina de Norwegian, que está hacia la salida.
  • Nos ponemos en marcha y nos paramos en la oficina que la compañía tiene en la zona de recogida de equipajes. Está a medio cerrar y tampoco hay nadie. Por fin vuelve a aparecer la azafata para decirnos que la oficina a la que tenemos que acudir, tras recoger las maletas, es la de ventas que está en la terminal de salida, fuera de la zona de facturación.
  • Todos en marcha de nuevo y, por fin… parece que hemos llegado al lugar adecuado: una oficina con las dos azafatas de tierra atendiendo (uno a uno), a una fila de casi 200 pasajeros, más un hombre como tercera persona de refuerzo. Las 00:30 aproximadamente, con 35% de batería en el móvil (los pocos enchufes disponibles, como podrán adivinar, todos ocupados), unas 80 personas por delante y unas 100 por detrás… y con mi mejor esperanza cifrada en dormir 3 o 4 horas y pillar el primer vuelo posible de la mañana.

  • El hombre de refuerzo sale de la oficina para preguntar a la cola si hay gente dispuesta a ir en autobús hasta Bilbao, que están intentando poner uno. Nos informa de que se está tratando de reubicar a los pasajeros en los vuelos de la compañía de las 07:50 y 16:30 del jueves, pero que no habría sitio para todos salvo que hubiera suficiente gente como para llenar un autobús. Con la condición que le ponemos de que saliera a la 1 y media o las 2 de la mañana y no a las 6 (“por supuesto, por supuesto”, nos dice), a la altura de cola en que yo estaba ya sumaba 28 voluntades, con lo que no hay duda de que gente había… pero del autobús nunca más se supo.
  • Algunas personas, en la cola, son capaces de gestionar el cambio de la reserva online, a través de la web de la compañía. Sin embargo, sin que se sepa muy bien la razón, a algunos les aparece la opción de cambio y a otros no. A mí, no.
  • Por esa razón, la cola aldelgaza algo por delante y por detrás. Los afortunados logran incluso obtener tarjetas de embarque en un mostrador de facturación aún abierto.
  • ¡¡¡Me toca!!! 01:50 de la madrugada y mi cara se pega a la ventanilla.
  • Una de las azafatas me informa de que ya no quedan plazas en los vuelos de Norwegian del jueves. Me ofrece la posibilidad de ir en un vuelo de Vueling a las 07:10, en el que ha comprobado que hay plazas libres, pero me informa de que no puede confirmarme el billete ni darme el localizador porque Vueling no responde a sus requerimientos.
  • Le pregunto por el hotel y me dice que están teniendo muchas dificultades pero que han conseguido un hotel en Blanes. Eso sí, me informa que el hotel está a 2 horas de viaje en coche.
  • Pienso dos veces lo que me han dicho, porque lo primero que entiendo… me parece que no puede ser, que es mi cabeza que ya no está fresca. Pero sí, sí que es.
  • Le digo que si me está tomando el pelo, que son casi las 2 de la madrugada y que me ofrece un hotel para el que debo emplear 2 horas en ir más 2 en volver… teniendo que estar de nuevo a las 6 en el aeropuerto de Barcelona.
  • Le digo que si no se da cuenta que lo único que voy a poder hacer en el hotel es entrar y salir de corrido por la puerta giratoria (si es que tiene), que ni el check-in… y me responde que “es lo que la compañía me está ofreciendo“.
  • Le digo que lo que me está ofreciendo es una burla, no una solución a la que legalmente están obligados, pero su respuesta es la misma anterior.
  • En la ventanilla de al lado, el otro pasajero reacciona de la misma manera.
  • Como sigo insistiendo, me dice que si prefiero que me diga que no tiene hotel… y le digo que por supuesto que sí, que prefiero que me diga que no puede cumplir con su obligación a que trate de engañarme con un “cumplimiento” formal pero inviable.
  • Una pasajera pide la dirección del hotel de Blanes porque piensa alquilar un coche para ir hasta él. Le dicen que espere unos minutos y se la darán.
  • Bloqueadas las dos ventanillas, sin movernos, la azafata me amenaza con llamar a Seguridad para que me haga a un lado y ella pueda seguir atendiendo a los pasajeros restantes.
  • Mientras tanto, otra pasajera se ha acercado a la otra ventanilla y le dan un detalle más: pueden poner un coche para llevarla hasta el hotel de Blanes si opta por un vuelo de Vueling a la tarde, pero el retorno del hotel lo tiene que hacer por su cuenta. Literalmente le dicen que “puede coger un tren“.
  • El nivel de cachondeo sube… me pongo de espaldas a la ventanilla y comienzo a explicar educadamente al resto de la cola lo que nos están diciendo…
  • En ese momento, la otra azafata se acerca y me dice que puede asegurarme el vuelo de Vueling de las 07:10 aunque no pueda darme el localizador. Me pide que vaya al Caffé di Fiore del fondo (la única cafetería que permanece abierta a esas horas en la terminal 2) con el vale de 15€ y se compromete a ir ella allí cuando tenga los billetes para entregarnos los localizadores. Me dice que han hecho todo lo posible por encontrar hoteles, pero que no hay ni una habitación disponible.
  • Me rindo. Acepto.

  • En la cafetería solo estamos gente con vuelos cancelados (quién, si no, iba a estar allí a esas horas…). Una pasajera escoge un café, un zumo y un bollo… y pide que le den el cambio, porque eso no valía 15€. La respuesta del camarero es que no está autorizado a dar cambio contra un vale. La pasajera le recuerda que el Caffé di Fiore ingresará los 15€ completos y pide entonces que le haga un vale por la diferencia (para volver luego), pero la respuesta es que por política de empresa, “no se dan vales“.
  • La gente, en una nueva cola, se empieza a incomodar por la espera y finalmente la clienta acepta renunciar a la diferencia… pero a partir de ese momento, cada persona empieza a coger “toblerones” y barritas de chocolate y cosas así, que nadie necesitaba, para completar los 15€… y que al menos no hicieran negocio con nuestra desgraciada situación.
  • Hasta donde sabemos, a la pasajera que pidió la dirección del hotel de Blanes no se la han dado todavía (al menos, una hora después de pedirla es seguro que no la tenía). Comenzamos a sospechar que el tal hotel de Blanes ni siquiera existe… y las teorías conspiranoicas se apoderan de las conversaciones. 😮
  • Son las 03:55 y no ha venido nadie a darnos los localizadores. Cruzamos de nuevo toda la terminal para acercarnos a las ventanillas de Norwegian… y ya: nos dicen que ya tienen los datos de Vueling. Nos dan un localizador, con instrucciones para coger el bus que nos lleve a la terminal 1, con salidas cada 20 minutos.

  • Las cabezas empiezan a dar vueltas, porque a esas alturas no es cuestión ya de fiarse de nada. La sombra de un posible overbooking sobrevuela y nos tiramos como locos a intentar el checking online en la app de Vueling.
  • A mucha gente no le permite hacerlo porque se han hecho casi 30 reservas con el mismo localizador… y la app dice que no se pueden gestionar los checking online con ese número de gente.
  • Mi móvil está al 18% de batería, pero lo intento. ¡Me deja! Estoy junto a la pasajera de la cafetería, selecciono nuestros dos nombres de la lista y pido las tarjetas de embarque… En efecto, me descarga dos tarjetas de embarque… ¡pero no son las nuestras, sino las de otros dos pasajeros! Nuestro gozo, de nuevo en un pozo.
  • Por fortuna, intentamos realizar la operación de nuevo… y observamos que, aunque no nos deja obtener las tarjetas de embarque, tenemos asiento asignado. Respiramos… el porcentaje perdido de la batería del móvil había merecido la pena. 😉
  • 05:15 horas, terminal 1. Al checking electrónico le pasa como a la app: no funciona con un grupo tan grande bajo el mismo localizador, así que nueva cola: la de los mostradores de facturación para obtener las tarjetas de embarque en papel… y por fin sin problemas, en los asientos asignados vía app.
  • Embarque y vuelo a Bilbao, sin incidencias. A mucha gente aún le quedaba coger su coche para ir a Santander o a Donostia.
  • 09:10 del jueves 29 de junio. En mi casa. No hay mal que por bien no venga: no saben lo bien que sienta una ducha tras 28 horas en pie y sin cerrar un ojo. 😛

Tengo los papeles para tramitar la correspondiente reclamación y ya me han advertido que, además, es conveniente hacerlo a través de su página web… o que todo es inútil si no la presento ante la oficina de Consumo. Pero, aparte de contarle todo esto a mi agencia de viajes este próximo lunes… no sé si haré algo más. Lo que me apetece, después de escribir este largo post, es olvidarme del asunto.

En cualquier caso, terminaré con una lista de preguntas para las que aún no tengo respuesta:

  • ¿Cuándo supo exactamente Norwegian que el vuelo que llegaba desde Bilbao iba a ser cancelado?
  • ¿Cuándo supo que se había desviado a Palma y por qué no informó a nadie de ello?
  • ¿Existió confirmación desde Loiu de que iban a esperar su llegada, a pesar de que ésta se iba a producir después de las 12 de la noche?
  • Y en ese sentido… ¿No tomaría la decisión el propio piloto, porque simplemente ya no consideró oportuno volar a esa hora?
  • O aún peor… ¿Tardaron tanto en embarcarnos y nos desembarcaron a continuación, solo para que encajara en horarios la indecente proposición de un hotel a dos horas de viaje, teniendo 4 para volver al aeropuerto, de forma que nadie optara por ir a él y Norwegian no se gastara un euro que pudiera evitar gastar?
  • ¿Existió, en realidad, ese hotel disponible en Blanes?
  • ¿Seguro que no era posible encontrar habitación alguna, no ya en Barcelona, sino en Sant Cugat, Manresa, Sabadell, Mataró, Badalona, Granollers…?
  • ¿Llamó realmente alguien a algún lugar buscando un autobús?
  • ¿Cómo es que una solución como la del autobús, no está sistemáticamente acordada como medida de contingencia para cuando pasen estas cosas?
  • ¿Será un buen negocio abrir una cafetería en un aeropuerto de madrugada, para facturar tickets que no se consumen?
  • ¿Habrá alguna vez apps de compañías aéreas que funcionen normalmente sin errores?
  • Y por último… ¿Cómo es posible que por no prolongar 30 o 40 minutos una jornada laboral en un aeropuerto como el de Loiu, se opte por dejar a 200 personas tiradas en un aeropuerto toda una noche a 600 km de distancia? (y que no me vengan con monsergas con el cansancio de los controladores… que no hay quien se crea que 8 horas es totalmente seguro y que 20 minutos más ya no… o que no hay manera de establecer coberturas para estos casos, que ocurren con demasiada frecuencia cada año).

En fin…

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?