nodos en la Red

Formular un problema: cantidad ES calidad (2)

user

Mario López de Ávila Muñoz

Emprendedor e inversor, mentor, advisor. Profesor asociado del área de Operations and Quantitative Methods de la IE Business School, imparte clases en la escuela desde el año 1996. Fundador de la Agile Entrepreneurship Spain, la comunidad hispano hablante de interesados en las metodologías Lean Startup en Meetup decana en España y una de las más grandes del mundo. Startup NEXT Madrid Lead Facilitator. Lean Startup Machine Madrid Co-founder. Co-director del proyecto España Lean Startup. Co-fundador de UEIA, primera aceleradora de empresas sociales de base tecnológica en el mundo.


LATEST POSTS

Let’s talk about Profit Models [I]: introducing Wei-Zhu Profit Model Matrix 06th April, 2015

#LEAN ELEPHANTS True Lean Intrapreneurs 23rd July, 2014

Creativity

Formular un problema: cantidad ES calidad (2)

el .

Podemos generar una gran cantidad de enunciados del problema o ‘puntos de entrada’ al mismo utilizando una versión ‘pedestre’ del sistema empleado por el software de Ideation del que os hablé en mi entrada anterior.  El método está muy bien descrito en el artículo ‘Lateral thinking and The Problem Formulator’, publicado, si no me equivoco, en el mes de marzo de 1998 del TRIZ Journal.  Es obra de un señor (o señora) que responde al nórdico nombre de Tore H. Wiik.  Mr (o Mrs) Tore desarrolla en su artículo dos ejemplos muy ilustrativos presentados por el Dr. De Bono en su libro "El Pensamiento Lateral. Manual de Creatividad", publicado por Editorial Paidós en su colección Empresa.

Para los que tienen problemas con el idioma inglés o poco tiempo,
haré un resumen.  Edward de Bono propone en el libro citado algo
denominado ‘rotación de la atención’ para generar una serie de
enunciados del problema encadenados, que él denomina – muy
acertadamente, en mi opinión -, ‘puntos de entrada’.  Son las
‘direcciones’ desde las que abordaremos el problema.  Pues bien, el Problem Formulator® de Ideation genera ese tipo de enunciados de forma automática y, debo añadir, exhaustiva.  ¿Dónde está la trampa? Para hacerlo, el software parte de un modelo de relaciones causa-efecto que debe construir el usuario.  Aquí es donde la mayoría de vosotros dice "manda g*ev*s" y deja de leer.  Tened paciencia!  Volveré sobre el tema de la construcción del modelo causa-efecto más tarde.

Problemformulator_2
Os adjunto una diapositiva que contiene la versión traducida del primer
ejemplo utilizado por Mr (o Mrs) Tore.  El color verde viene a
significar "esto es algo bueno", una función útil del sistema.  El
color rojo, por el contrario, indica "esto puede ser o es un
problema".  En terminología TRIZ, se trata de una función dañina [harmful]
del sistema.  El asunto a tratar es la congestión del tráfico urbano en
el centro de Londres, que se pretendió resolver en un primer momento
obligando a los edificios públicos y/o de oficinas a habilitar plazas
de garaje.  El Dr. De Bono nos cuenta como la oferta ampliada de plazas
tuvo un desastroso "efecto llamada", atrayendo más tráfico aún, lo que
obligó a buscar una nueva ‘vía de entrada’ o ‘de ataque’ al problema.

Una vez elaborado el modelo causa-efecto de la situación, enunciar
los diferentes ‘puntos de entrada’ es sencillo. Básicamente, hay dos
tipos de enunciados: preventivos, que se aplican a las funciones dañinas y alternativos,
que se enuncian para las funciones útiles.  Tanto unos como otros
pueden adoptar distintas redacciones.  Además, para según qué entidad,
puede formularse adicionalmente alguno de los siguientes tipos de
enunciados: beneficiarse de una función dañiña, aumentar el beneficio derivado de una función útil o resolver una contradicción.

En fin, en el ejemplo del que habla Mr (o Mrs) Tore, estos son los
enunciados del problema o ‘puntos de entrada’ a los que llegamos
aplicando este método [observad cómo se repiten algunas estructuras sintácticas, porque son la clave de todo esto].  Os recomiendo que leáis los enunciados con el diagrama causal en lugar bien visible:

1. Encontrar una manera de eliminar, reducir o prevenir [Congestión del tráfico rodado], dada la condición [Escasez de plazas de parking] y la condición [Entrada y salida de vehículos de la ciudad].
2. Encontrar una forma de beneficiarse de [Congestión del tráfico rodado].
Este segundo enunciado es una aplicación del Principio Inventivo #22, "Blessing in disguise" o "Turn Lemons into Lemonade".
3. Encontrar una manera de eliminar, reducir o prevenir [Escasez de plazas de parking], dada la condición [Entrada y salida de vehículos de la ciudad].
4. Encontrar una forma de beneficiarse de [Escasez de plazas de parking].
5. Encontrar una manera de eliminar, reducir o prevenir [Entrada y salida de vehículos de la ciudad], dada la condición [Desplazarse al lugar de trabajo].
6. Encontrar una forma de beneficiarse de [Entrada y salida de vehículos de la ciudad].
7. Encontrar una forma alternativa de proveer [Desplazarse al lugar de trabajo], que proporcione o incremente [Hacer el trabajo] y que no cause [Entrada y salida de vehículos de la ciudad].
8. Encontrar una forma de mejorar o incrementar [Desplazarse al lugar de trabajo].
9. Encontrar una manera de resolver la CONTRADICCIÓN: [Desplazarse al lugar de trabajo] debe estar presente para obtener [Hacer el trabajo] y no debería estar presente para no causar [Entrada y salida de vehículos de la ciudad].
Los
hipotéticos lectores saben cómo utilizar una Nube de Evaporación para
atacar este conflicto.  De hecho, siempre que veáis en un diagrama de
este tipo una entidad de la que surjan una flecha roja y otra verde,
sabréis que estáis ante una contradicción y, por consiguiente, ante una
"Nube".
10. Encontrar una forma alternativa de proveer [Hacer el trabajo], que no requiera [Desplazarse al lugar de trabajo].
11. Encontrar una manera de mejorar o incrementar [Hacer el trabajo].

Como véis, si se posee una mínima comprensión de las relaciones
causales que se dan en la situación que se está abordando, podemos
generar múltiples ‘vías de ataque’ al problema
.  En este caso,
tenemos 11 formas de ‘hincarle el diente’ a la congestión del tráfico
rodado, cuando al principio sólo teníamos una.  Por experiencia, sé que
incluso cuando las relaciones causales identificadas no son más que
intuiciones sin evidencias que la soporten, el método resulta de gran
ayuda a la hora de afrontar el problema
.  No hace falta un modelo
causa-efecto como los que utilizamos en el Proceso de Razonamiento de
TOC, ni con el nivel de detalle exigido en esos casos ni validado con
la ayuda de las Categorías de Reserva Legítima.  De hecho, en algunos
casos he utilizado un mapa perceptual [‘flowscape‘] de De Bono con buenos resultados [para saber más, ver su maravilloso libro "Lógica Fluida", también en Editorial Paidós]Recordad
que de lo que se trata aquí es de encontrar múltiples formas de definir
el problema y, de ahí, múltiples formas de atacarlo.  NO estamos
buscando soluciones.

Supongo que será evidente, pero por si acaso lo dejo claro.  Esta relación de ‘enunciados del problema’ debe ser sometida a reflexión antes de seguir avanzando.
Pueden escogerse una o varias direcciones de ataque.  Además, varios de
estos enunciados pueden agregarse en una macro-dirección de resolución
del problema.

profile

Mario López de Ávila Muñoz

Emprendedor e inversor, mentor, advisor. Profesor asociado del área de Operations and Quantitative Methods de la IE Business School, imparte clases en la escuela desde el año 1996. Fundador de la Agile Entrepreneurship Spain, la comunidad hispano hablante de interesados en las metodologías Lean Startup en Meetup decana en España y una de las más grandes del mundo. Startup NEXT Madrid Lead Facilitator. Lean Startup Machine Madrid Co-founder. Co-director del proyecto España Lean Startup. Co-fundador de UEIA, primera aceleradora de empresas sociales de base tecnológica en el mundo.

  • Muy bien apuntado. Este método tiene un gran defecto: opera dentro de los límites (más o menos estrechos) del problema tal y como han sido definidos durante la construcción del modelo causa-efecto. Es por eso que yo lo utilizo para introducir algo de “sistematización” en el trabajo con Nubes y Ramas Negativas. Claro que me surge otro peligro: complicar el uso de herramientas que por lo demás son sencillas. Eso sí, es capaz de generar una burrada de “puntos de entrada”. Por todo esto quería conocer vuestra opinión.
    Hay otras muchas “herramientas” procedentes de distintas disciplinas relacionadas con la creatividad que nos ayudan a ver el problema desde otras perspectivas:
    a) Todas las herramientas DATT de De Bono entran en esta categoría (personalmente sólo uso Considera Todos los Factores, Opiniones de Otras Personas y Plus Minus Interesting). También técnicas como el Abanico de Conceptos o los mismos 6 sombreros para pensar te ayudan a ver las cosas de otra manera, porque te obligan a enfocar tu atención en otros puntos.
    b) El Problem Explorer de Darrell Mann, las 9 ventanas (también llamado Operador Sistémico), o el Operador DTC (Dimensiones Tiempo Coste), todos ellos de TRIZ, te obligan a salirte de los límites del problema que previamente has definido.
    c) Técnicas de reencuadre aportadas por la NLP, la Neurosemántica de Hall, etc, también son de utilidad.
    d) Otras muchas :-)
    Todas estas ‘herramientas’ guardan grandes similitudes.

  • Interesante proceso para abordar un problema…Tomando en cuenta que se trata sólo de encontrar múltiples formas de definir el problema (para atacarlo) y no de buscar soluciones…Creo que es importante el hecho de que pueden escogerse varias direcciones de ataque y emitirse varios enunciados para resolver el problema. No obstante y luego de leer el artículo en Inglés, también pienso que el software no ha considerado la posibilidad (o la variable) de que el problema tal vez no lo sea o de que ya forma parte de otra solución y el desconocimiento de ello derive en un problema mayor…Me explico:
    En el ejemplo sobre la congestión del tráfico urbano en el centro de Londres, que se pretendió resolver en un primer momento, creo que no se consideró que ese tráfico, que es un problema para algunos, también es una solución para otros y por esto resultó en un problema más grave; es decir, un problema es algo relativo, pues no lo es para todos los habitantes del centro de Londres. ¿Es posible alimentar el algoritmo con otras variables para hacer más específica la descripción del problema…? De esta forma se podría aumentar la comprensión de las relaciones causales en la situación a resolver para así poder dirigir el “ataque” de una forma más precisa hacia la solución del problema.
    Buen post…el tema de resolver problemas siempre me ha interesado pues es parte de mi día a día.

View Comments (2) ...