Mostrando entradas con la etiqueta Cynefin. Mostrar todas las entradas
Mostrando entradas con la etiqueta Cynefin. Mostrar todas las entradas

sábado, 30 de noviembre de 2013

La ovación de pie

Es cada vez mayor el componente social en los servicios y productos de software. El aspecto de procedimiento, que debe existir y operar correctamente, va camino a ser secundario.

Una simple intranet corporativa incorpora el botón “me gusta” en su diseño para poder mostrar nuestra aceptación o no sobre lo que leímos. 
Este comportamiento que parece simple, hacer  un click en un icono, analizado, puede revelarnos aspectos que nos interesan para diseñar un sistema competitivo.

Para explicarlo con palabras sencillas el ejemplo de la “Ovación de pie” (ver 1,2) es útil.

Imaginemos que queremos tratar de entender por qué la gente aplaude de pie en algunas circunstancias y en otras no.
Una primera aproximación sería que la gente espera un nivel de calidad del espectáculo. Superado ese nivel, se levanta y aplaude, no antes.
Esta aproximación es útil, aunque demasiado simplificada. Por ejemplo asume que la gente está ubicada en un único lugar puntual, lo cual no es real. Asume también que la gente no se conoce entre sí, es decir que cada uno actúa sin considerar a su vecino, lo cual tampoco tiene que ser así.
La realidad es más compleja. La gente se distribuye en la sala y, posiblemente, si reconoce una cara familiar y puede, tratará de sentarse junto a la persona conocida. Asimismo un grupo de personas que se conocía previamente podrían ir juntos a la función.

Todo esto hace que el comportamiento de la persona sea distinto en cada situación, y podría pensar:
    •       No me levanto
    •      No me iba a levantar pero como se levantó el de adelante y el del costado, me    levanto y aplaudo de pie yo también
    •     Me levanto y aplaudo de pie porque mi amigo lo hizo
    •     Fuimos juntos y nos pusimos de acuerdo previamente en ponernos de pie en      ciertos momentos de la función
    •    ...........
Y así podríamos seguir.

Bien, ¿pero para que nos sirve entender todo esto?

Por ejemplo para diseñar una sala de espectáculos e influenciar en el comportamiento de los espectadores.
    • ¿Me conviene poner más palcos? 
    • ¿Me conviene poner gente “amiga” que se levante y aplauda en lugares visibles, por ejemplo los palcos, o en la primera fila y así inducir a que se levante el resto?
    • ............
Tener a la gente aplaudiendo de pie, haría que la obra gane buena fama en la prensa y así vender más entradas para las funciones futuras y también más caras.

La conclusión: 

Nuestro trabajo no consiste en imponer un procedimiento estricto de comportamiento, que en el caso del espectáculo sería imposible. Sino proveer una plataforma para que los intervinientes desarrollen sus acciones y tratar que se genere el comportamiento que yo espero. Dirigir esas acciones hacia nuestro objetivo, por ejemplo que una visita se convierta en venta, es lo que debemos aprovechar.
Reglas simples, levantarse o no para aplaudir, presionar o no el “me gusta”, poner o no el HT, pueden desencadenar acciones complejas entre participantes, que se conocen o no, pero que están conectados.

La calidad del sistema, medida en un indicador como el antes mencionado (convertir visitas en ventas) sólo puede verse cuando el producto esté en uso, pero seguramente las formas de inducirlas pueden estudiarse antes. 

Podemos pensar "que no es mi caso....., que yo no hago sistemas así.....", tal vez, por ahora. Recuerdan el dicho de la luz al final del túnel, puede ser la salida ...o la locomotora que viene.


Saludos,
Raúl
TW: @RaulMartinez582


Referencias:

1. Complex Adaptive Systems. Page, Miller, 2007 Princeton Univ Press
2. Is Twitter a Complex Adaptive System?. Venessa Miemis 

martes, 12 de noviembre de 2013

Interés de los lectores


Distribución del interés de los lectores de nuestro blog ideassobresoftware.blogspot.com.ar, en los distintos temas a lo largo de los meses. Estos son los 10 primeros puestos en cantidad de lecturas.








Entrada


Fecha de Publicación


Tema

Oct 2013

Calidad de producto y expectativas

Jun 2013
Administración de proyectos

Nov 2013
Calidad y negocios, el resumen

Jun 2013

Indicadores Negocio/Producto

Sep 2013

Complejidad de distintos escenarios
Aug 2013
Testing y servicios
Jul 2013
Testing
May 2013
Calidad de producto
Sep 2013
Calidad de producto y negocio
May 2013
Calidad de producto y negocio

Saludos,
Raúl
TW: @RaulMartinez582


miércoles, 6 de noviembre de 2013

Acercarnos al Negocio (Conclusión)



Esta tabla es una conclusión de los posts anteriores sobre el tema del negocio y la calidad. 
Definitivamente incompleta y simplificada, creemos que permite entender la calidad desde varios puntos de vista que actúan simultáneamente sobre el usuario/consumidor, el negocio y el equipo que desarrolla. 
Atarse a un modelo de trabajo, a una situación determinada (usuario cautivo por ejemplo) o a una única definición de calidad es peligroso, para el negocio y para nosotros.

Otras conclusiones: 

  1. Si bien puede parecernos que es lento  y que no es posible que el negocio mute de un tipo a otro, lo que sí puede y va a mutar es la forma en que la tecnología va permitiendo resolver los problemas y ofrecer nuevas oportunidades de servir al usuario. Esto hace que con el tiempo los límites entre los tipos de negocio vayan haciéndose más tenues, en lo que a los servicios prestados vía la tecnología se refiere.
  2. El cambio entre columnas es costoso, en ambos sentidos. En un negocio donde se debe explorar el comportamiento del consumidor  no podemos esperar requerimientos escritos, al menos al inicio. Del mismo modo, en un negocio donde el objetivo del producto es conocido, explorar no tiene demasiado lugar y no recibir los requerimientos razonablemente definidos en este caso sólo agrega tiempo y defectos.
  3. En lo referido a contextos. El contexto complejo y desordenado no es un lugar para vivir. A medida que las expectativas del cliente se detecten y se cumplan, debemos esforzarnos para pasar al ordenado y complicado. Y prepararnos para una nueva tanta de expectativas a explorar y así siguiendo.  



 A considerar

Backoffice

Usuario adelante

Exploradores


La finalidad de la empresa
No relacionada con el software
Productos de sw vitales para su negocio, sin ser el negocio mismo
El negocio es la prestación de un servicio a través del producto de software

Los requerimientos
Conocidos
Conocidos; mayor cuidado en los atributos de calidad de cara al cliente
Conocidos los básicos; a explorar el resto según demandas del usuario y competencia

Los usuarios
Conocidos y cautivos
Conocidos internos y externos. Costo de cambio es alto para el cliente
Variados, muchos, desconocidos hasta la identificación. Comunidades,  decisiones conjuntas, no  controlables. Bajo costo de cambio para el consumidor.

Los modelos de trabajo
Tradicionales en desarrollo y PM
Tradicionales en desarrollo y administración. Parcialmente exploratorios de cara al cliente
En lo básico, en parte tradicionales. En lo competitivo,   modelos exploratorios.

La calidad
Cumplir los requerimientos
Cumplir los requerimientos y prestar atención a la calidad en uso
Cumplir los requerimientos básicos se da por hecho. La calidad se mide en el cumplimiento de expectativas de los consumidores.

Acercarnos al negocio
Apoyo tecnológico y soporte
Idem anterior sumando algunos indicadores accionables de negocio/producto
Indicadores accionables que permitan analizar en los tiempos del negocio la relación negocio/producto y corregir desvíos.

Contexto
Complicado - ordenado

Complicado - ordenado
Complejo - desordenado


lunes, 4 de noviembre de 2013

Acercarnos al negocio (exploradores)


Finalmente llegamos al tercer grupo en el tema de acercarnos al negocio y su relación con la calidad del producto. 
Aquí el consumidor opera el producto, disponiendo de una cantidad de opciones, por ejemplo consultar, registrarse, comprar, pagar, publicar, etc.
Sus expectativas juegan un papel central.

La finalidad de la empresa: el servicio que se presta a través del producto es el negocio mismo de la empresa.

Los requerimientos: conocidos los requisitos básicos, éstos pueden estar especificados con cierta precisión por adelantado. Varios, sobre todo aquellos que harán diferencial al producto, se encontrarán explorando las demandas del consumidor, la forma en que utiliza el producto, sus expectativas y el comportamiento de los productos competidores. Esta exploración nos guiará en la funcionalidad a implementar y su prioridad.

Los usuarios: Muchos, desconocidos o no conocidos hasta que se identifican, recorriendo pasos totalmente aleatorios o especificados en el producto en algunos casos. Estos consumidores pueden agruparse y tomar decisiones conjuntas o bien operar individualmente. Volátiles, con la posibilidad de hacer la misma operación con otro producto competidor, sin mayores costos en el cambio.

Los modelos de trabajo: Tradicionales de desarrollo de software, y administración de proyectos para las partes conocidas.
Necesidad de modelos exploratorios para las partes más volátiles.
Los atributos de calidad deben tenerse en cuenta y su valor objetivo se definirá en parte por la pérdida/ganancia de negocios para la empresa al cumplir o no las expectativas del consumidor.

La calidad: en este contexto significa cumplir con los requerimientos básicos del producto y del proyecto con la tasa de defectos más baja posible, admitiendo errores y equivocaciones en aquellas funcionalidades detectadas por medios exploratorios donde la puesta en producción o el "time-to-market" es prioritario. El indicador accionable, ya mencionado en el post anterior, que une el resultado de una funcionalidad para el negocio, con la pieza de software que la implementa, es una guía para saber qué corregir y con qué prioridad.

Acercarnos al negocio: vale todo lo mencionado en las entradas anteriores sobre conocimiento de productos, tecnología, etc. si bien posiblemente parte de ese conocimiento esté más difundido en estas compañías dado el tipo de negocio en gran medida dependiente de la tecnología.

Contexto: predominantemente complejo y desordenado.


Para una explicación más amplia de estos contextos ver 
http://ideassobresoftware.blogspot.com.ar/2013/09/todavia-quiere-seguir-jugando.html 

Post relacionados




Saludos,
Raúl
TW: @RaulMartinez582


sábado, 2 de noviembre de 2013

Acercarnos al negocio (con el cliente adelante)


Continuando con la relación entre el tema de acercarnos al negocio y su relación con la calidad del producto veamos el segundo caso. 
 Aquí el usuario / consumidor (introduzco este término), opera el producto con el cliente frente a él, disponiendo de una cantidad de opciones ej. : caja en el retail, terminal de cajero en bancos, tablet del visitador médico frente al médico, o bien es directamente operado por el usuario / consumidor final, por ejemplo un home banking desde su smartphone.

La finalidad de la empresa: sin ser su actividad principal, tiene a los productos de software como un elemento vital en su negocio, porque soportan la operación y además soportan un servicio, por ejemplo, un canal de ventas / comunicación con sus clientes.

Los requerimientos: conocidos, pueden estar especificados con cierta precisión por adelantado. Habrá alguna definición sobre objetivos de atributos de calidad, siendo éstos más importantes que en el patrón de back-office.

Los usuarios: conocidos, algunos internos, con el mismo patrón que de back-office y otros externos, clientes, que disponen de un menú variado de opciones a realizar con el producto.

Los modelos de trabajo: tradicionales de desarrollo de software y administración de proyectos funcionan correctamente en este entorno para las actividades de tipo back-office y para las de interacción.
Hay atributos de calidad que deben cuidarse más y valorizarse y otro factor a considerar que es la competencia. Si bien los clientes de un home-banking no son clientes cautivos (la relación cliente / banco va más allá de la interacción con nuestro producto) aun así la competencia incide.

La calidad: en este contexto significa cumplir con los requerimientos predefinidos del producto y del proyecto, estar atentos a las observaciones que puedan llegar de los clientes a través de una mesa de ayuda y vigilar todo lo relativo a la calidad en uso, de aquí la importancia de valorizar los atributos de calidad.

Acercarnos al negocio: vale todo lo mencionado en la entrada anterior sobre conocimiento de productos, tecnología, etc., agregando que conviene incorporar indicadores accionables que muestren la relación negocio-producto. Por ejemplo, cuántos clientes abandonaron la operación de consulta de saldo?, y cuál fue el motivo? Se puede rastrear el motivo al sistema/software que atiende la consulta?.

Contexto: seguimos en complicado pero ordenado.

Para una explicación más amplia de estos contextos ver http://ideassobresoftware.blogspot.com.ar/2013/09/todavia-quiere-seguir-jugando.html 

Post relacionados

Saludos,
Raúl

TW: @RaulMartinez582

jueves, 31 de octubre de 2013

Acercarnos al negocio (back-office)







En post anteriores se mencionó varias veces el tema de acercarnos al negocio y su relación con la calidad. ¿Pero qué significa y cómo se hace?

Básicamente es entender cómo gana plata la compañía, qué la hace crecer, etc.

El negocio final de la Compañía puede estar cerca o lejos de los productos de software, nuestros productos pueden ser el back-office del negocio, uno de los canales de venta o el negocio mismo de la compañía. Los escenarios no son excluyentes. En otra entrada veremos aquellas compañías cuyo negocio es desarrollar software para terceros.

Comencemos por el primer caso.

La finalidad de la empresa: no está relacionada con el software. (ej. Una maderera) y nuestros productos de software soportan la operación del negocio (back-office).

Los requerimientos: conocidos, pueden estar especificados con cierta precisión.

Los usuarios: conocidos, incluidos en sectores / jerarquías, su demanda de información se conforma por niveles, es decir los niveles de más abajo registran las operaciones y la información se condensa para los usuarios de la capa superior. Pueden tener herramientas de apoyo, pero están cautivos del sistema que les construimos o adquirimos.

Los modelos de trabajo: tradicionales de desarrollo de software y administración de proyectos funcionan correctamente en este entorno.

La calidad: en este contexto significa cumplir con los requerimientos predefinidos del producto y del proyecto.

Acercarnos al negocio: es entenderlo, conocer las novedades tecnológicas de nuestra especialidad para mejorar el negocio, ayudar a la empresa a adquirir el sistema más adecuado técnicamente para su fin (desarrollo o enlatado),  soportarlo y administrar la tecnología.

Contexto: complicado pero ordenado.


Para una explicación más amplia de estos contextos ver http://ideassobresoftware.blogspot.com.ar/2013/09/todavia-quiere-seguir-jugando.html 

sábado, 14 de septiembre de 2013

¿Todavía quiere seguir jugando?



Una pequeña historia

Entramos a un Casino en el que hay diferentes juegos en los que podemos elegir apostar. En una mesa hay un juego llamado “Multimedia”, en otra uno llamado “Web-services”,  en otra uno llamado “Banca Electrónica”.
Nos acercamos al crupier y se desarrolla el siguiente dialogo:
  • Nosotros: “Cuánto la apuesta mínima?”
  • Crupier: “3000 millones”
  • Nosotros: “¿Quién jugará?”
  • Crupier: “No lo sabremos hasta que lleguen”
  • Nosotros: “¿Cuáles son las reglas?”
  • Crupier: “Aparecerán a medida que el juego avance”
  • Nosotros: “¿Cuál es mi chance de ganar?”
  • Crupier: “No podemos decirlo, ¿todavía quiere seguir jugando?”
¿Qué distingue a un gran líder de un líder promedio? Su habilidad para percibir la naturaleza y las reglas de un juego a medida que lo juega.(W. Brian Arthur)
--oo0oo-- 

El motivo de esta introducción es tratar de entender:
  • ¿Cómo tomamos decisiones en un contexto cambiante e impredecible?
  • ¿En qué podemos  basarnos?
  • ¿Cómo podemos afirmarnos en un terreno resbaladizo como un problema poco definido y un entorno altamente cambiante?

Las preguntas son demasiado amplias, pero totalmente trasladables a gran cantidad de proyectos que encaramos en la actualidad con clientes más demandantes, competencia exacerbada, tecnología fluida, calidad sobreentendida, etc.

Los supuestos para la toma de decisiones

Nuestro sistema más común de toma de decisiones, está basado en
  • Que existe en el contexto del problema un cierto grado de predictibilidad y orden,
  • que se pueden hacer ciertas simplificaciones para entenderlo,
  • y por lo tanto poder resolver situaciones que requieran decisión.

Esto cada vez es más difícil. El entorno de toma de decisiones es cada vez más cambiante y los supuestos antes mencionados no siempre, en realidad cada vez menos, se cumplen.

Dando sentido a las cosas

Una ayuda a estos problemas de decisión en contextos cambiantes podemos encontrarla en el concepto de “sensemaking”, cuya posible traducción sería “dar sentido”.
Sensemaking: es el intento de darle sentido a situaciones ambiguas, complejas o inciertas ayudando a tomar decisiones en ellas, tratando de entender las conexiones entre las partes intervinientes para anticiparse y actuar en forma efectiva.
Un marco de referencia para este “dar sentido”, lo propone el modelo Cynefin, de Kurtz y Snowden, al que ampliamos con las ideas de Snowden y Boone acerca de  la toma de decisiones utilizando esta propuesta.
Pero atención, los criterios que proponen no son una receta, sólo permiten razonar sobre posibles modos de encarar situaciones comunes en distintos contextos. Por ejemplo:
  • Ordenados y simples
  • Ordenados y complicados
  • Desordenados y complejos
  • Desordenados y caóticos

 Gráficamente


¿Cómo reconocemos cada entorno? ¿Cómo tomamos decisiones en cada uno? ¿Qué debemos resolver y qué problemas podemos encontrar?



Entorno Ordenado – Simple - Conocido

El dominio de las mejores prácticas (know-know).

¿Qué caracteriza a esta situación?

  • Sucedió otras veces (repetible), es evidente, es predecible, si ocurrió un determinado evento sabemos lo que ocurrirá luego. Relación clara y lineal entre causa y efecto.
  • El entorno es conocido y estable, la probabilidad de cambios es baja.
  • Son aplicables las mejores prácticas, estructuradas en procesos.
  • Habitualmente el conocimiento de la solución reside dentro de la misma Organización.

¿Qué debemos tener en cuenta para tomar una decisión en esta situación?

  • Reconocer el contexto en el cual se desarrolla la situación.
  • Detectar y evaluar la información que se recibe.
  • Categorizarla.
  • Responder de acuerdo a una práctica predeterminada.
  • La “receta” es esencial ya que está probada y asegura repetibilidad.

¿Qué debemos lograr y fomentar?

  • Mantener una comunicación directa y clara, no es necesario que sea excesiva; el tema es conocido y la solución también.

¿Qué problemas esperar y qué evitar?

  • Equivocarse al leer el contexto y tratar de aplicar a todos los problemas las prácticas que conocemos. No poder pensar “fuera de la caja” para reconocer otra situación.
  • Resistirnos a entender que el entorno cambió y las soluciones  anteriores ya no aplican.
  • Confiarnos y simplificar demasiado; interpretar erróneamente lo simple como fácil.
  • El síndrome “esto es lo mismo que antes pero dicho de otra manera”. Tal vez no es lo mismo, ni se le parece.       

Caso:

  • Resolución de incidentes conocidos siguiendo pasos establecidos; no hay decisiones demasiado complejas y la mayoría de los casos están contemplados en “el manual”.
   

Entorno Ordenado - Complicado - Conocible

El dominio de la buena práctica o del experto -  (know-unknowns)

¿Qué caracteriza a esta situación?

  • La cultura de la Organización, algún proceso establecido y seguido ya hace tiempo, la burocracia ya incorporada en las tareas, producen problemas no visibles desde dentro. La relación causa-efecto existe, pero no es reconocida por la Organización o fácilmente detectable por quien debe tomar la decisión.
  • La causa puede estar separada del efecto, no es lineal (si toco aquí no explota allí inmediatamente) y posiblemente sólo un ojo entrenado y no comprometido,  pueda detectarla y aconsejar la decisión adecuada.
  • Las causas y los efectos se centran alrededor de un tema, lo cual deja al tema todavía en el terreno de lo predecible. Por ejemplo re-trabajo, defectos, etc.
  • Quien toma la decisión podría investigar, estudiar y finalmente también hacerlo, pero con tiempo e investigando. Asimismo ciertos conflictos de poder pueden actuar sobre una posible solución que descubra.

¿Qué debemos tener en cuenta para tomar una decisión en esta situación?

  • Reconocer el contexto en el cual se desarrolla la situación.
  • Detectar y evaluar la información que se recibe del contexto.
  • Analizarla, posiblemente con ayuda.
  • Responder de acuerdo a la sugerencia de el o los expertos.

¿Qué debemos lograr y fomentar?

  • Coordinar e integrar opiniones diferentes entre los expertos.
  • Crear una tema común de discusión evitando dispersión de los mismos expertos.
  • Escuchar a los no expertos que podrían aportar una solución creativa.

¿Qué problemas esperar y qué evitar?

  • Expertos demasiado confiados en su experiencia.
  • Opiniones diversas (y contradictorias), intereses personales de los expertos.
  • Parálisis por análisis.
  • Expertos pensando sólo “dentro de su caja” sin considerar alternativas.
  • Ignorar la solución propuesta, aunque sea evidente su corrección, por los problemas políticos que puede causar, sin analizar alternativas.

Caso:

  • Una serie de síntomas típicos en una Instalación, re-trabajo, tiempos muertos, visibles para los expertos, pero que pasan desapercibidos para el resto, y que muestra la necesidad de una mejora en los procesos.


Entorno Desordenado – Complejo – Retrospectivamente comprensible 

El dominio de la exploración y el ensayo (unknow-unknowns)

¿Qué caracteriza a esta situación?

  • La relación causa-efecto existe, pero la gran cantidad de variables intervinientes y relaciones entre ellas es tan amplia que no es posible incorporarlas en un proceso estructurado, ni analizarlas una a una ya que actúan a la vez. Por ejemplo proyectos extensos, con gran cantidad de personas intervinientes, organizaciones y tecnologías.
  • Pueden buscarse patrones de comportamiento que, si se repiten, ayudarán a simplificar la detección futura de situaciones similares.
  • La situación es entendible sólo retrospectivamente, es decir a posteriori, cuando se podrá encontrar una explicación para algunas de las cosas que sucedieron.         

¿Qué debemos tener en cuenta para tomar una decisión en esta situación?

  • Como posiblemente estemos ante un caso único, como la mayoría de los proyectos donde nunca todas las variables se repiten aunque lo hagan algunas, habrá que explorar posibles caminos y experimentar en base a la información del resultado de nuestras acciones.
  • Detectar patrones de comportamiento conocidos, e identificar nuevos. Responder de acuerdo a la nueva situación.        

¿Qué debemos lograr y fomentar?

  • Propiciar la experimentación creando un ambiente adecuado.
  • Lograr un alto grado de comunicación.
  • Aceptar errores o fallas en los ensayos.

¿Qué problemas esperar y qué evitar?

  • Incertidumbre en los resultados: estamos ante situaciones únicas.
  • Asustarse con los resultados o la falta de ellos y reincidir en procedimientos estructurados, que sin duda fallarán ya que fueron pensados para otros entornos.
  • Asociado a esto, perder la oportunidad de una solución creativa o alguna solución siquiera.
  • Confusión entre experimento y caos.
  • Buscar hechos concretos en un ambiente donde todo fluye y es difícil encontrarlos, en lugar de entender los patrones que van surgiendo.

Caso:

  • Cualquier producto de cierta complejidad, tamaño, extensión, novedoso como idea, sobre tecnologías nuevas o en desarrollo, para mercados en expansión y variados. Productos originales o innovadores están en este entorno.
  • Casos como YouTube, e-Bay, Google, las redes sociales, avanzaron en sus orígenes, y siguen actualmente, creando e identificando patrones de comportamiento que permiten cambiar el negocio a medida que se comprenden sus características.

·         

Entorno Desordenado – Caótico – Inesperado

El dominio de la respuesta rápida.

¿Qué caracteriza a esta situación?

  • Es totalmente inesperada. ¡Pasó y hay que resolverlo!
  • Nadie sabe exactamente qué hacer ya que escapa a todo lo conocido.
  • Quién piensa en ese momento en detectar y analizar la relación causa-efecto: no hay tiempo.
  • Lo primero es restablecer el orden, actuar rápidamente y detener la turbulencia.

¿Qué debemos tener en cuenta para tomar una decisión en esta situación?

  • Actuar para volver a ordenarnos.
  • Detectar el resultado de la acción y ver cuál puede ser el próximo paso. 
  •  Responder de acuerdo al resultado, profundizar o cambiar por otra acción.
  • No ir atrás de la respuesta correcta ni perfecta, sino de lo que funciona en ese momento.

¿Qué debemos lograr y fomentar?

  • Actuar.
  • Comunicar breve y claramente qué debe hacerse (órdenes en muchos casos).
  • Impedir mayor caos.

¿Qué problemas esperar y qué evitar?

  • Buscar culpables durante el caos: no ayuda a solucionarlo, al contrario.
  • Actitudes tanto egoístas como altruistas de las personas.
  • Continuar en la actitud de ordenar y controlar. Es útil para salir del caos, pero dañina más allá de lo necesario.
  • Vivir en crisis; hay mejores formas de sentir la adrenalina.

Caso: 

  • Situaciones de emergencia, caídas de los sistemas producidas por eventos fuera de cualquier riesgo esperado, aun los más extremos contemplados.


El centro: el desorden

¿Qué caracteriza a esta situación? 

  • Conflictos entre quienes deciden.
  • Ver la misma situación desde distintos puntos de vista.
  • Competencia por interpretar la situación basados en sus preferencias. Unos tratan de aplicar el proceso, otros de experimentar, y otros de controlar.
  • Cada uno lo llevará al plano donde cree tener más poder.

          ¿Qué debemos lograr y fomentar?

  • Posiblemente la única solución es acercarlos y ayudar a que reduzcan sus diferencias.
  • Buscar puntos en común.

  • ...No es fácil...

Conclusión

La pregunta inicial fue cómo tomábamos decisiones en situaciones complejas o inciertas.
No siempre estamos (o deberíamos estar) en el plano de caótico, y hay gran cantidad de situaciones en el contexto de lo complicado y hasta de lo simple. No toda situación es una emergencia.
Habrá también casos de situaciones complejas, las cuales, a medida que las comprendamos deberíamos hacerlas transitar hacia los estadíos anteriores más ordenados y así lograr una forma repetitiva de resolverlas.
Los riesgos son varios y no sencillos de tratar ya que están relacionados con las personas, la cultura de la organización, el contexto donde se insertarán las soluciones, y podríamos seguir agregando. Aun así, el mayor riesgo es no hacer nada y tratar de aplicar la misma receta a todo, cualquiera sea esta receta y situación que estamos tratando.
Como agregado, y si bien implica también un riesgo, debemos visitar los contextos desordenados, ya que en muchos casos allí residen las ideas creativas, todavía no procesadas. Logradas nuevas ideas, nuevamente podemos tratar de volver a los contextos más ordenados.
Resumiendo y en palabras sencillas:
  •        Simple = By the book
  •        Complicado = Preguntar al experto
  •        Complejo = Ensayar y analizar el resultado
  •        Caótico = Actuar.

Material de referencia

  • The new dynamics of strategy: Sense-making in a complex and complicated world, C. F. Kurtz y D. J. Snowden. IBM SYSTEMS JOURNAL, VOL 42, NO 3, 2003. Este trabajo dio origen al modelo. Es interesante, a veces necesita relectura.
  • A Leader’s Framework for Decision Making, David J. Snowden y Mary E. Boone, Harvard Business Review • Nov. 2007. Toma los conceptos del trabajo original, y lo orienta más específicamente a quien toma decisiones. Muy interesante la tabla resumen con las características de cada contexto, sus acciones y sus riesgos.
  • Increasing returns and the new world of business, W. Brian Arthur, HBR 1996.
  • Definiciones de Karl E. Weick. Varias publicaciones.