Planificación Perfecta Vs Planificación Evolutiva (Basada en Aprendizaje y Evidencia)

A medida que vamos encontrando nuestras propias formas de hacer efectivo ese Business Agility que nos promete tener la capacidad organizacional de poder probar, cambiar y adaptarnos rápidamente para entregar servicios y productos valiosos para el consumidor, vamos entendiendo que esto se logra si somos capaces de medir tempranamente outcomes puntuales de nuestra estrategia y reaccionar velozmente, girando y redefiniendo horizontes (y objetivos) de corto, mediano y largo plazo.

Haciendo el “doble click” a lo anterior, todo comienza efectivamente por la definición de una estrategia, sus objetivos y además por la adquisición de nuevas habilidades, formas, mentalidades y capacidades que vamos adquiriendo para hacer esto.

Al plantearnos como aterrizar el Business Agility en nuestra organización, podemos mirar lo que han hecho bien otros y también podemos ver que han hecho otros e identificar que NO hacer. En realidad “copiar” soluciones que han funcionado en otros puede tener un efecto de éxito temporal en el mejor de los casos, pero el problema es que no aprendimos nada, nos dieron el pescado y nunca aprendimos a pescar.

Business Agility para cada organización no se trata de copiar el significado de Business Agility en otros, sino entrar en un modo propio, casi asumido, de aprendizaje continuo y de esa forma ir definiendo y redefiniendo constantemente que es lo que significa Business Agility para cada organización.

En el caso específico de planificación y de los objetivos claros que deberían ser resultado de esa planificación, una de las formas de plantear objetivos estratégicos que puedan ser claramente medibles es la nomenclatura:

pensamos que <tal capacidad>
resultara en <tal outcome>
para <tales personas>
y tendremos éxito cuando <feedback claro / condición que pueda ser iterable>

Por ejemplo: “pensamos que al incrementar el tamaño de las fotos del hotel en la pagina de booking resultara en un engagement y conversiones mejoradas para los nuevos clientes que no han hecho un booking antes con nosotros tendremos éxito cuando veamos un 5% de incremento in clientes quienes revisen las fotos de los hoteles y luego procedan a hacer el booking en 48 horas

Y aún si las llegamos a plantear de esa forma, Seiden & Gothelf nos muestran un ejemplo de que cosas debemos evitar desde una perspectiva agile: el infame FirePhone de Amazon, un proyecto que le costó $170 millones de dólares al gigante de Seattle sin que en ningún momento supiesen oler el desastre que se venía.

Es interesante, pero si uno se pone a analizar el génesis mismo del proyecto desde una perspectiva de “aprender-actuar-aprender-actuar” y no de “diseñar la gantt perfecta”, algunas luces se hubiesen encendido de forma temprana. Una de las formas en la que ese proyecto fue planteado probablemente tenia la siguiente visión:

“…Creemos que podemos lograr un incremento en compras via dispositivo móvil si nuestros clientes pueden acceder a nuestros productos con un teléfono móvil dedicado de Amazon en vez de su teléfono iPhone o Android.”

El verdadero problema de todo esto es que un grupo, probablemente muy capaz, de personas, se enfocaron en construir la Planificación Perfecta al rededor de este objetivo (probablemente una Gantt maravillosa, de colores y en 3D…) sin cuestionarse siquiera la sensatez del mismo.

Supongamos que todavía no vemos el riesgo en este objetivo. Iniciemos un proceso de “preguntas incómodas” y desagreguemos ese supuesto en otros más granulados que están IMPLICITOS en ese primer statement. Dado que la gran mayoría de personas usamos 1 teléfono inteligente, el creer que lo anterior se puede lograr, implica que lo siguiente debería suceder:

“…Creemos que los clientes cambiarán su teléfono iPhone o Android por un Amazon FirePhone porque…. les gusta mucho el feature de 3D que trae.”

¿Comenzamos a verlo ahora? Vamos con una tercera que ya nos dejará bien claro el panorama:

“…Creemos que podemos ganarles a los dos líderes en teléfonos inteligentes que se dedicaron desde muy temprano a competir entre ellos por el mejor teléfono inteligente del mercado, aunque estamos haciendo un teléfono con una única fortaleza (comprar) y a un solo proveedor (Amazon).”

¿Realmente pensó Amazon que batiría a iPhone y Android solo porque su desconocido teléfono tiene 3D (que ya lo había sacado alguien más) y sin que su objetivo real sea generar un mejor teléfono completamente? La lucha que mantiene a iPhone y Android relevantes es porque ellos creen que pueden hacer un mejor teléfono que el otro en su totalidad y dedican su existencia a ello.

Así planteados sus objetivos, probablemente o no hubiesen comenzado su proyecto o de insistir, se hubiesen dado cuenta de que las características que estaban incluyendo en los mismos no eran suficientes como para el objetivo que perseguían y hubiesen tenido que extender esa lista.

Es por eso que en el proceso dinámico de la estrategia ágil, todo comienza por  entender que hay muchas cosas que aprender, no necesariamente antes de comenzar, pero con la claridad de que deben ser resueltas en algún momento. No se trata de paralizarse hasta saber todo, porque así también corremos el riesgo de teorizar las soluciones y de ver como crece el Holding Cost (costo de no sacar un producto al mercado tempranamente).

Si en vez de buscar la Planificación Perfecta al rededor de un objetivo ciego (y dudoso), Amazon hubiese entendido el paradigma de la Planificación Evolutiva con solo hacerle caso al amigo Simon Sinek que siempre se pregunta PORQUE antes de QUÉ, Amazon hubiese entendido que su reto se trataba de, en primera instancia, aprender.

Entonces les hubiese venido bien preguntarse:

  • ¿Qué es lo primero que tenemos que aclarar o aprender?
  • ¿Cuáles supuestos son peligrosos?
  • ¿Cuál es la manera mas rápida y mas barata de obtener ese conocimiento?

Es entonces que las recientemente adquiridas habilidades ágiles de los equipos dedicados a entregar productos y/o servicios serán útiles. Sino, entrenarlos, agruparlos, invertir en esos equipos… para que produzcan más rápidamente “Amazon FirePhones” no solo resulta tonto, sino ineficiente y probablemente desmotivante para esos equipos que añoran el momento que la organización se ajuste a su velocidad y entendimiento del cliente y las nuevas dinámicas organizacionales.

Deja un comentario

A %d blogueros les gusta esto: