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.
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.
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.
Posted by: Mario | 12/05/2007 at 12:24 PM
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.
Posted by: Senior Manager | 12/05/2007 at 12:03 PM