Tiempo estimado de lectura ( 38 minutos)

Todo cambia por favor

A principios de 2009, conocí a Liam Maxwell. Es posible que ese nombre no signifique mucho para usted a menos que trabaje en el gobierno, pero él ha sido una figura influyente en la tecnología gubernamental en todo el mundo, un firme defensor de la cartografía y un buen amigo desde ese primer encuentro. Nos conocimos cuando estaba hablando en una conferencia al azar en Londres sobre evolución y tecnología. Por casualidad, Liam estaba entre el público. Charlamos y descubrimos que teníamos intereses y formas de pensar en común sobre la tecnología. Pronto fui invitado al grupo «Triple Helix», que consistía en un variopinto equipo de personas interesantes: Jerry Fishenden, Mark Thompson y otros. Querían intentar ayudar a solucionar los problemas que vieron en la TI del gobierno. Era un grupo no partidista, es decir, muchos de nosotros veníamos de diferentes antecedentes políticos.

Por mi parte, me sentí completamente fuera de mi alcance. Se trataba de una «gran TI» como en grandes proyectos con cientos de millones gastados en sistemas de escala masiva de los que normalmente sólo había oído hablar debido a algún fallo que afectaba a la prensa convencional. También hubo grandes personalidades. Conocí a Francis Maude (estaba en el gabinete de la oposición en ese momento), que consistía principalmente en que yo tratara de no murmurar «eres Francis Maude», dado que estaba un poco asombrado. ¿Qué demonios era yo, un niño de la escuela estatal que había vivido en una propiedad del consejo haciendo en las Casas del Parlamento hablando con personas que había visto en la televisión?

También me presentaron a varios departamentos que amablemente se ofrecieron a darme una hora más o menos para explicar cómo sucedió la “gran TI”. Lo que vi me estremeció, pero tampoco había visto a las “grandes TI” en el mundo comercial, habiendo construido principalmente empresas o trabajado para grupos de tamaño moderado. Lo primero y más obvio que noté fue la falta de habilidades de ingeniería a pesar de la escala de estos proyectos de ingeniería. Me presentarían a un ingeniero tras otro que, de hecho, resultó ser un director de proyecto glorificado. La respuesta a todo parecía ser «subcontratarlo», un mantra que había sido alentado por hordas de consultores de gestión. Traté de explicar cómo esto conduciría inevitablemente a sobrecostes porque algunos componentes serían nuevos, pero generalmente obtuve una respuesta que culpaba a una especificación deficiente. Parecía que no importaba cuántas veces fallara un proyecto, la respuesta fue «mejores especificaciones» o «mejor subcontratación». Este era un dogma desbocado. Me di cuenta cada vez más de que estos grupos no solo dependían de los proveedores, sino que muchos carecían de las habilidades necesarias para cuestionar las cotizaciones dadas.

No existía el concepto de mapas ni un mecanismo eficaz de comunicación, aprendizaje o intercambio. Todo estaba aislado. La duplicación abundaba. Antes de que alguien continúe hablando de lo malo que es el gobierno, permítanme aclarar que esto palidece hasta la insignificancia en comparación con las ineficiencias e ineficacia del sector privado. Es posible que haya visto el mismo sistema reconstruido cientos de veces en el gobierno, pero en el mundo comercial, he visto a 350 equipos separados de personas reconstruir el mismo proyecto de TI en una organización al mismo tiempo. Cualquier cosa que el gobierno haga mal, el sector privado sobresale en mostrar cuánto más mal es posible.

De todos modos, el Gobierno seguía siendo un shock. Hubo algunas medidas débiles de control de costes, pero casi ningún concepto de precio por usuario o transacción o necesidades del usuario o cualquier cosa que haya comenzado a dar por sentado. Hubo un proyecto en el que Liam me pidió que adivinara el precio, respondí alrededor de £ 300k después de revisar los detalles. Estaba al norte de £ 50 millones. Tuve verdaderos problemas para asimilar esas cifras, pero luego vi mil millones de dólares gastados sin esperanza, obviamente condenados al fracaso desde el principio en los esfuerzos del sector privado. Siempre había asumido que había una mayor sabiduría de la que no era consciente. Se estaba volviendo claro que este no era el caso. En el gobierno, sin embargo, esto tendía a molestarme. No me importa la supervivencia de los menos incompetentes del sector privado porque eventualmente alguien vendrá y hará un mejor trabajo. En el gobierno no hay nadie y hacer las cosas bien es fundamental. Tengo una familia que vive en viviendas sociales que se horrorizarían por el desperdicio.

Entre trazar el dominio de la nube por parte de Ubuntu, comencé a dedicar mi tiempo libre a trabajar con este grupo en la redacción del artículo “Más por menos”. Rápidamente se hizo evidente que el Gobierno no solo gastaba enormes sumas en proyectos individuales, sino que esos proyectos tenían índices de éxito deplorables. “Sólo el 30% de los proyectos de TI gubernamentales tienen éxito, dice el CIO”, grita la edición de mayo de 2007 de Computer Weekly. ¿Cómo fue posible que los proyectos gastaran sumas tan infladas y fracasaran con tanta frecuencia?

Cuanto más miraba, más cosas descubría. No se trataba de un problema de los funcionarios y de la falta de pasión por hacer lo correcto, sino de una cuestión cultural, un deseo de no ser visto fracasado que inevitablemente acababa en fracaso. Las habilidades se habían subcontratado hasta el punto de que la subcontratación era la única opción con pocas personas que podía plantear un desafío. Hubo una grave falta de transparencia. Llevar el gasto en TI en el gobierno al billón más cercano era casi imposible. Las palabras «¿Cómo puedes no saber esto?» Parecían salir constantemente de mi lengua. El shock se había quedado atónito.

Por supuesto, las razones por las que estábamos construyendo cosas a menudo parecían aún más ridículas. La mayoría de los sistemas estaban mal diseñados para adaptarse a la legislación y las políticas que apenas habían tenido en cuenta su propio impacto operativo. Cualquier concepto de lo que los usuarios (es decir, los ciudadanos) podrían querer de esto estaba muy lejos. La interacción con los ciudadanos se sintió más como un inconveniente para lograr la política. Debe recordar que había pasado cinco años ejecutando servicios en línea para millones de usuarios. Este enfoque impulsado por políticas para la construcción de TI fue la antítesis de todo lo que había hecho.

Para complicarlo todo, el enfoque de silo o el departamentalismo de los proyectos había significado que los grupos ni siquiera hablaban entre sí. De alguna manera, Whitehall había desarrollado un enfoque para crear y mantener costosos recursos de TI, a menudo duplicados, que a menudo fallaban pero que tampoco interactuaban entre sí de manera efectiva. En 2003, estaba acostumbrado a que los servicios web proporcionaran servicios de componentes discretos que eran consumidos por muchos otros servicios. En 2005, estaba acostumbrado a diseñar entornos con una comprensión clara de las necesidades del usuario, los componentes involucrados y el potencial para compartir. En 2010, mientras estaba sentado en una de estas reuniones de departamento, flabbergast se convirtió en horror. Estaba analizando enfoques que no había visto desde mediados de los 90 y discutiendo cuestiones de política con personas que carecían de la habilidad para tomar decisiones racionales. Donde existía la habilidad, el gobierno tenía estratificaciones extrañas de jerarquía, lo que a menudo significaba que las personas que podían tomar las decisiones correctas estaban muy lejos de las personas que tomaban las decisiones. “Big IT” parecía ser un eufemismo para snafu y solo era “Big” en términos de coste, falta de información de administración sólida y tasas de falla. En lo que respecta al número de usuarios atendidos y al rendimiento, fue decididamente «Promedio» al borde de «Pequeño».

Con Fotango, habíamos tratado con millones de usuarios de nuestra base de almacén en el desierto tecnológico (en ese momento) de Old Street. Usamos un entorno de plan abierto que trae sus propios problemas, usamos días de hackeo, reuniones de scrum y sesiones plenarias para contrarrestar las dificultades de comunicación. A pesar de nuestros mejores esfuerzos, nuestro uso de equipos pequeños y nuestro pequeño tamaño, era inevitable que las capas de jerarquía y política impactaran la comunicación. Sin embargo, la escala de nuestros problemas de comunicación fue trivial en comparación con las estructuras arraigadas, la política y las fallas de comunicación dentro de estos departamentos. La escala de los problemas era «grande» incluso si la TI no lo era.

El grupo de la “triple hélice” necesitaba comenzar en alguna parte, así que comenzamos con un conjunto básico de principios.

Doctrina: pensar en grande
Necesitamos salir de la mentalidad de pensar en sistemas específicos y abordar todo el problema. Necesitábamos romper con estos sistemas individuales aislados. Necesitábamos cambiar el mecanismo de entrega predeterminado para los servicios públicos hacia servicios en línea que utilizan procesos automatizados para la mayoría de los ciudadanos. Necesitábamos un enfoque que se enfocara sin descanso en la entrega al ciudadano y sus necesidades. Esta iba a ser la «gran» idea.

Doctrina: hacer más con menos
Este enfoque tenía que ser transparente y medido en términos de coste. Tenía que representar un desafío para lo que se estaba construyendo actualmente. A partir de esto, desarrollamos la idea de una junta de escrutinio que luego se convirtió en control de gastos bajo OCTO. No fue suficiente simplemente reducir el gasto; nuestro enfoque estaba en reducir drásticamente el desperdicio mientras mejoramos los servicios públicos. No podríamos hacer esto sin medir.

Entendimos que este no sería un enfoque de Big Bang, sino un proceso iterativo, un ciclo constante de hacerlo mejor con menos. Para ello, propusimos el uso de datos abiertos con un enfoque en la transparencia del Gobierno. También agregamos el uso de código abierto, incluidas las prácticas asociadas con él, y el uso de estándares abiertos para impulsar mercados competitivos.

Doctrina: Muévete rápido
Entendimos que habría inercia en los cambios que proponíamos y que la cultura y las estructuras existentes bien podrían levantarse para combatirnos. Implementamos un concepto inicial de flujos de trabajo que se enfocaba en diferentes áreas. La idea era que si alguna vez poníamos esto en práctica, tendríamos aproximadamente 100 días para hacer los cambios antes de que la resistencia nos abrumara. Si no estuviera en funcionamiento en ese momento, habríamos perdido nuestra ventana.

Doctrina: Comprometerse con la dirección, adaptarse a lo largo del camino
Para permitir el cambio, necesitábamos un mensaje claro y eficaz de la autoridad combinado con un compromiso con el cambio. Sin embargo, en el pasado esto ha sido notoriamente difícil ya que solo un ministro en la Oficina del Gabinete (Tom Watson MP) antes de 2010 tenía un compromiso real para comprender la tecnología. Sin embargo, con un cambio de gobierno podría haber una oportunidad con un nuevo equipo ministerial.

Para respaldar todo esto, propusimos una estructura basada en el modelo de innovación – apalancamiento – mercantilización. La estructura incluía fondos de innovación que operaban a nivel local, una junta de escrutinio que fomentaba el desafío junto con un servicio de tecnología común que proporciona componentes industrializados. La estructura se basó en conceptos de tecnologías abiertas, fue impulsada por datos con énfasis no solo en definir sino en medir el éxito. Fue iterativo y adaptativo utilizando la retroalimentación constante tanto de la primera línea como de los ciudadanos. Para respaldar esto, tendríamos que desarrollar capacidades internas en ingeniería que incluyan enfoques similares más ágiles. También necesitaríamos crear un plan de estudios para la confianza y la comprensión de los problemas de TI para los funcionarios de rango medio y los ministros. Necesitaríamos adoptar un enfoque más modular para crear sistemas que fomenten la reutilización.

Doctrina: Sea pragmático
Aceptamos que no todo encajaría en la estructura o las corrientes de trabajo que habíamos descrito. La mayoría lo haría y sería la reducción de costes y la mejora en esos casos lo que generaría el mayor ahorro. Sin embargo, era importante reconocer que un enfoque único para todos no funcionaría y sería vulnerable a la inercia. El pragmatismo para lograr el cambio fue más importante que la ideología. También tuvimos que mantener el patrimonio de TI existente, reconociendo al mismo tiempo que el futuro requerirá un enfoque fundamentalmente diferente basado en una entrega local ágil, abierta y efectiva. No solo tendríamos que auditar, sino también exprimir los activos existentes hasta que pudieran ser reemplazados.

Doctrina: un sesgo hacia lo nuevo
Nos enfocamos en un enfoque de afuera hacia adentro para la innovación donde el cambio fue impulsado y alentado a nivel local a través de fondos semilla en lugar de que el gobierno intentara forzar su propio concepto de cambio a través de “grandes TI”. El papel del gobierno central se redujo a proporcionar experiencia en ingeniería, una función de cliente inteligente para desafiar lo que se hizo, servicios de componentes industrializados, fomento del cambio y mostrar lo bueno que se veía.

Doctrina: Escuche sus ecosistemas (actúa como motores de detección del futuro)
Consideramos que el enfoque centralizado existente era problemático porque a menudo estaba alejado de las necesidades reales de los empleados del servicio público, los intermediarios o los ciudadanos por igual. Visualizamos un nuevo grupo de ingeniería que trabajaría en el campo y detectaría y luego fomentaría las oportunidades de cambio en la primera línea, trabajando en estrecha colaboración con los proveedores de prestación de servicios.

Aunque la mayor parte del trabajo del grupo de la «triple hélice» se completó algún tiempo antes, Liam publicó el artículo resultante «Más por menos» en septiembre de 2010. Si bien el artículo ciertamente no es tan conocido como la carta de Martha Lane Fox sobre «revolución, no evolución ” tuvo un pequeño impacto. Las ideas y conceptos incluidos en el documento se distribuyeron dentro del gobierno y brindaron cierto apoyo a las estructuras que se crearon posteriormente, ya sea el control de gastos o el desarrollo de la capacidad de ingeniería interna en los servicios digitales gubernamentales o el desarrollo de programas de capacitación. De vez en cuando me encuentro con funcionarios públicos que lo han leído en el periódico o han utilizado sus conceptos. Puedo sentirme reconfortado al saber que el trabajo no fue en vano, sino que ayudó a dar punta a la aguja. Pero también descubrí que había cometido un terrible error en el periódico. Ese error fue una suposición.

Demasiado de lo que querías

Con la transformación comenzando dentro de la TI gubernamental, Liam había asumido el papel de director de tecnología de HMG. Ocasionalmente aparecía y discutía los cambios, incluso me reunía con departamentos para revisar proyectos con parte del control de gastos. A menudo fui brutal, desafiando el coste, la falta de enfoque en el cliente y los intentos interminables de especificar lo que era incierto. Fue durante una de estas discusiones que tracé un mapa del espacio y utilicé el mapa para mostrar un gasto excesivo de costes particularmente irritante y cómo un proveedor estaba tratando de encerrarnos con costes de actualización cada vez mayores. Usando el mapa, le señalé a Liam cómo podíamos romper el dominio de este proveedor. Él asintió con la cabeza y luego dijo algo muy inesperado: «¿Qué es eso?»

Lo que sucedió en los siguientes cinco minutos fue una revelación para mí. Conocía a Liam desde hacía algún tiempo, habíamos trabajado juntos en el artículo «Más por menos» y discutimos los problemas de la evolución, pero de alguna manera, en todo esto, nunca le había explicado qué eran mis mapas. Aunque Liam podía ver el potencial de los mapas, yo estaba confundido. ¿Cómo no supo qué eran estos mapas?

Comencé a hablar con otros CEO, CIO y CTO y rápidamente descubrí que nadie sabía qué eran los mapas. Aún más impactante, a pesar de mi suposición de que todos los demás tenían su propia forma de mapear, resultó que nadie lo hizo. Finalmente me di cuenta de que el increíblemente sabio ejecutivo senior del Arts Hotel que me había preguntado «¿Tiene sentido esta estrategia?» No me estaba probando, no tenía ni idea. Pero esta pregunta me había hecho dar vueltas en este viaje (ver capítulo 1). Parecía que no era solo yo quien había estado fingiendo como director ejecutivo.

Fue en 2013 cuando esta revelación realmente apareció. Trabajaba para el Leading Edge Forum (una organización de investigación privada) con acceso a lo bueno de muchas industrias y muchos gobiernos. Realicé una encuesta muy informal de alrededor de 600 empresas y concluí que solo cuatro de esas empresas tenían algo remotamente equivalente a un mapa. En cada uno de estos casos, estaban usando modelos mentales. El mundo entero jugaba una partida de ajedrez sin ni siquiera mirar el tablero. De repente, mi éxito al apoderarse de todo el espacio en la nube con Ubuntu a pesar de la riqueza y el tamaño de los competidores tuvo sentido. Su incapacidad para contrarrestar mis movimientos se debió simplemente a la ceguera. Es posible que los ejecutivos recibieran salarios de millones de dólares, pero estaban jugando al ajedrez.

Parte del problema con el documento “Más por menos” era que había asumido que todos tenían algún tipo de mapas. Sin estos, sería casi imposible eliminar la duplicación y el sesgo, introducir desafíos en el sistema y aplicar los métodos correctos. Había hablado de que el control de gastos se convirtiera en la sede institucional del aprendizaje para el gobierno, pero esto no iba a suceder si nadie tenía mapas para comparar. No puedo subestimar lo importante que fue esa simple declaración de Liam. Sin él, podría haber seguido asumiendo que todos sabían cómo trazar mapas durante muchos años más. Tengo con Liam una gran deuda de agradecimiento.

Una oportunidad

A finales de 2013, escribí un documento para la Oficina del Gabinete titulado «Gobernanza del cambio tecnológico». Utilicé este artículo para tratar de combatir lo que veía como una “tiranía de lo ágil” e introducir las ideas de aprendizaje continuo a través de mapas. Ya tenía un puñado de ejemplos en los que los mapas habían resultado útiles en el gobierno, como su uso en el desarrollo de sistemas de TI dentro de HS2 (tren de alta velocidad) por James Findlay. Estos ejemplos fueron pocos y espaciados. El problema dentro del gobierno fue una tendencia pasada a una talla única. La subcontratación estaba siendo superada ahora por una nueva e inapropiada talla única llamada ágil. Sin mapas, es fácil caer en una trampa única para todos. Para mostrarle lo que quiero decir, tomemos un mapa para un sistema de TI en HS2 y superpongamos los diferentes métodos, técnicas y tipos de actitudes que usaría – vea la figura 235

Figura 235 – Mapa de trenes de alta velocidad con técnicas superpuestas

A estas alturas, debería ser obvio para usted cómo necesitamos usar un panorama cambiante de múltiples métodos al mismo tiempo para administrar un sistema complejo como este. Sin embargo, imagínese si no tuviera un mapa. La tentación y la facilidad con la que una talla única se puede usar o reemplazar por otra debería ser obvia. ¿Cómo contrarrestaría un argumento a favor del uso de una técnica ágil para construir un sistema de recursos humanos dado el éxito que agile ha tenido en la construcción de un sistema de registro de la propiedad? Son iguales, ¿verdad? Esto es lo que sucede cuando se pierde el contexto. Es como acabas intentando subcontratar todo o «agilizar» todo.

Tenga cuidado, este camino no le hará ganar muchos amigos. He estado en conferencias en las que me he metido en conversaciones acaloradas con gente que intenta explicarme que lo ágil funciona en todas partes. Esto a menudo es seguido por otras conferencias y conversaciones acaloradas con personas que intentan explicar que six sigma funciona en todas partes. En ambos casos, a menudo explican el error como «no hacerlo de la manera correcta» o «usando los bits incorrectos» y nunca que existe un límite o contexto para el método. No es diferente con el problema de «mejores especificaciones». El error siempre se atribuye a otra cosa y no a esa especificación, agile o seis sigma no deberían haberse utilizado para esas partes.

Durante mis años de uso de mapas, el «uso de métodos apropiados» fue solo uno de una larga lista de juegos específicos de contexto, patrones climáticos (económicos) y doctrina (principios universalmente útiles) que había descubierto a través del uso de mapas. Recurrí a mi lista de doctrina para ayudarme a escribir el documento «Gobernanza del cambio tecnológico» y para corregir algunos de mis errores en el original «Más por menos». Usé estos principios para proponer una nueva forma de estructura de gobierno que se basó en el trabajo que ya estaba hecho. Los elementos clave de la doctrina utilizados fueron:

Doctrina: centrarse en una alta conciencia situacional (comprender lo que se está considerando)
Uno de los principales errores de «Más por menos» fue la falta de énfasis en los mapas. Tuve que aumentar la conciencia de la situación más allá de simples modelos y estructuras mentales como ILC. Para lograr esto, necesitábamos desarrollar mapas dentro del gobierno, lo que requiere un ancla (necesidad del usuario), una comprensión de la posición (la cadena de valor y los componentes involucrados) y una comprensión del movimiento (evolución). Para empezar, el sistema de gobernanza propuesto reflejaría claramente las necesidades de los usuarios en todos sus procesos de toma de decisiones. Los usuarios incluyeron no solo a los usuarios departamentales, sino también al público en general que interactuará con los servicios prestados. Por lo tanto, era fundamental que las necesidades de esos usuarios fueran determinadas desde el principio, representadas en la creación de cualquier propuesta y que los resultados esperados de cualquier propuesta se compararan con esas necesidades. Pero esto no fue suficiente también necesitábamos la cadena de valor que satisficiera las necesidades de los usuarios y la evolución de los componentes. Por tanto, los mapas se convirtieron en una parte fundamental de la estructura de gobernanza.

Doctrina: ser transparente (un sesgo hacia la apertura)
El sistema de gobierno tenía que ser completamente transparente. Por ejemplo, las propuestas deben publicarse abiertamente en un solo lugar y en un formato a través de una canalización pública y compartida. Esto debe permitir el examen de las propuestas tanto a nivel interno como externo del gobierno para fomentar la interacción de los departamentos y miembros del público con cualquier propuesta.

Doctrina: Usar un lenguaje común (necesario para la colaboración)
El sistema de gobernanza tenía que proporcionar un mecanismo para la coordinación y el compromiso entre los grupos, incluidos los departamentos y el control de gastos. Esto requiere un mecanismo de aprendizaje compartido, por ejemplo, el descubrimiento y la difusión de ejemplos de buenas prácticas. Para lograrlo, debemos tener un lenguaje común. Los mapas eran ese idioma.

Doctrina: Usar métodos apropiados (p. Ej., agile vs lean vs six sigma) La
gobernanza tuvo que aceptar que actualmente no existen métodos únicos de gestión que sean adecuados para todos los entornos. El uso de múltiples métodos y técnicas basados ​​en el contexto tenía que convertirse en una norma.

Doctrina: distribuir el poder y la toma de decisiones
Los departamentos y grupos deben poder organizarse según corresponda para cumplir con la política central. Por tanto, el procedimiento de gobernanza debe abstenerse de imponer directamente las metodologías y la estructura del proyecto a los departamentos y grupos y permitir la toma de decisiones autónoma. Se podrían lograr mejoras en las formas de operar mediante el desafío a través de mapas, es decir, si un departamento pensara que todo debería subcontratarse, podríamos usar sus propios mapas para ayudarlos a desafiar su propio pensamiento.

Doctrina: Piense rápido, económico, sobrio y elegante (FIRE)
La gobernanza debe fomentar un enfoque rápido, económico, simple y pequeño en lugar de la creación de sistemas lentos, caros, complejos y grandes para lograr una buena relación calidad-precio. Cualquier propuesta de tecnología razonablemente grande debe dividirse en componentes más pequeños con cualquier desarrollo interno logrado a través de equipos pequeños. El desglose de sistemas grandes también ayudaría a demostrar que, por lo general, se necesitaban múltiples métodos además de fomentar la reutilización. Sin embargo, tendríamos que estar preparados para la inercia y contra argumentos como la «complejidad de la gestión de interfaces». Las interfaces existían independientemente de si intentamos ignorarlas o no.

Doctrina: utilizar un mecanismo sistemático de aprendizaje (un sesgo hacia los datos)
El sistema de gobernanza debe proporcionar un mecanismo de medición coherente con respecto a los resultados y para la mejora continua de las mediciones. Esto se trata en el capítulo 6 y es una función principal para cualquier grupo de control de gastos.

El documento fue escrito y entregado en 2013. Desafortunadamente, sospecho que en este caso ha acumulado polvo. El problema con el papel era la familiaridad. Muchos de los conceptos que contenía son desconocidos para la mayoría y eso requiere esfuerzo y compromiso para superarlos. Ese compromiso no estaba ahí, la tiranía de lo ágil continuó y se produjo la inevitable contrarreacción. Hubo y hay muchas cosas buenas que ha logrado el Gobierno en TI desde 2010. Las personas que han trabajado y trabajan allí han enorgullecido a esta nación. Sin embargo, se podría haber logrado más. En mis momentos más oscuros y egoístas, sospecho que si no hubiera asumido que todos sabían cómo trazar mapas, entonces podría haber sido capaz de mover esa aguja un poco más al introducir estos conceptos de manera más prominente en el artículo «Mejor por menos». Pero, por desgracia, este no es mi único fracaso.

Supuestos y sesgo

La suposición es una actividad muy peligrosa y que me ha sorprendido constantemente. En el pasado, había asumido que todos sabían cómo trazar mapas, pero la verdadera pregunta es ¿por qué pensé esto? La respuesta en este caso es un sesgo conocido como sesgo de falso consenso. Tiendo a asumir que si yo sé algo, todos los demás también deben saberlo. Es la razón por la que me tomó seis años descubrir que otros no estaban mapeando. También estaba detrás de mis suposiciones en el artículo «Más por menos».

Cuando se trata de sesgos con mapas, hay dos tipos principales que debe considerar. El primero es el sesgo evolutivo y nuestra tendencia a tratar algo de manera incorrecta, por ejemplo, construir a medida lo que es una mercancía. Al comparar varios mapas, puede ayudar a reducir este efecto. El segundo grupo amplio y poderoso de sesgos son los sesgos cognitivos. Los mapas pueden ayudar aquí, pero solo mediante la acción de permitir que otros desafíen su mapa. Los tipos de sesgos cognitivos más comunes y peligrosos a los que me he enfrentado (y mi descripción de estos como «los más comunes y peligrosos» es otro sesgo) son: –

Sesgo de confirmación
Una tendencia a aceptar o interpretar la información de una manera que confirme las ideas preconcebidas existentes. Por ejemplo, un grupo que se aferra a la información que respalda que el uso de algún proceso sea diferente al de la industria y, por lo tanto, justifique la forma en que lo ha construido.

Sesgo de aversión a la pérdida
El valor de perder un objeto excede el valor de adquirirlo, por ejemplo, el efecto del coste perdido. Los ejemplos escuchados incluyen «si no hubiéramos invertido este dinero, no usaríamos este activo para hacer esto». A menudo, una causa fundamental de inercia.

Sesgo de resultado
Una tendencia a mirar el resultado real y no el proceso mediante el cual se tomó la decisión. Suele aparecer en los memes copiando a otras empresas cuando existe poca o ninguna conciencia de la situación, por ejemplo, «deberíamos ser como Amazon».

Sesgo de retrospectiva
Una tendencia a ver los eventos pasados ​​como más predecibles de lo que fueron. Un ejemplo sería describir la evolución de la computación desde el mainframe al cliente / servidor a la nube como una forma de ruta ordenada. El problema es que la ruta «aparente» tomada en un nivel alto depende de qué tan evolucionados fueron los componentes subyacentes (por ejemplo, almacenamiento, procesamiento, red). Si el procesamiento y el almacenamiento fueran mucho más caros que la red, tenderíamos a la centralización. Mientras que si la red fuera más cara, tenderíamos a la descentralización.

Sesgo en cascada
Una creencia que gana más plausibilidad a través de su repetición en los círculos públicos, por ejemplo, muchos de los falsos mitos de la nube como la “venta de capacidad sobrante” de Amazon.

Sesgo de instrumentación
El problema de la familiaridad y la dependencia de herramientas o enfoques conocidos con exclusión de otros métodos. Resumido por la línea «Si todo lo que tienes es un martillo, todo parece un clavo».

Sesgo de disposición
Un deseo de no perder valor, es decir, vender activos que han acumulado valor pero se resisten a vender activos que han disminuido con la esperanza de que se recuperen. Esta es otra fuente común de inercia a través de la creencia de que una línea de negocio existente o un activo adquirido que se está desempeñando mal se recuperará.

Efecto Dunning-Kruger
Tendencia de los inexpertos a sobreestimar su habilidad y de los experimentados a subestimar.

Sesgo de cortesía
Una tendencia de las personas a evitar dar su opinión verdadera para evitar ofender a los demás, por ejemplo, para no cuestionar a la fuerza por qué estamos haciendo algo, especialmente cuando se considera un “proyecto favorito” de otro.

Sesgo de ambigüedad
Una tendencia a evitar la incertidumbre cuando sea posible y / o intentar definir la incertidumbre, por ejemplo, para especificar lo desconocido.

Sesgo de supervivencia
Examinando únicamente los datos que alcanzan algún estado final en lugar de los que no lo hacen. En el corazón del mapeo hay un sesgo de supervivencia. La curva de evolución (descrita en el capítulo 7) que se utiliza como base del eje x de un mapa se construyó a partir de los datos de los componentes que habían sobrevivido para convertirse en una mercancía. Muestra un camino de «Si un componente evoluciona a un producto básico, atravesará estas etapas». Pero, ¿qué pasa con los componentes que no sobrevivieron? Lamentablemente no pude distinguir otro patrón para explicarlos más que decir que siguieron el camino de la evolución y murieron en una de las etapas. De forma más visible (porque podemos acceder a los datos), los componentes mueren en la etapa de construcción personalizada y solo puedo asumir (porque es casi imposible obtener datos) que la etapa más común de muerte es la génesis, donde existe el mayor grado de incertidumbre. Por supuesto, la suposición es algo peligroso.

Aplicar la doctrina

Hasta ahora en este capítulo, he cubierto varios aspectos de la doctrina y las cuestiones de prejuicio y suposición. Hay una razón para mi locura. Una de las preguntas más comunes que me hacen es ¿qué partes de la doctrina debemos aplicar primero? La respuesta a esto es, no lo sé.

Basado en mi experiencia, creo (y tal vez ese sesgo) que hay un orden en la doctrina. Por ejemplo, antes de que pueda aplicar una estructura de pionero – colono – urbanista (es decir, diseño para una evolución constante), primero debe implementar otras formas de doctrina. Un orden aproximado es: –

1. Empiece por comprender las necesidades de sus usuarios (es decir, céntrese en las necesidades del usuario ).
2. Mejore su comprensión de los detalles al describir la cadena de valor necesaria para respaldar las necesidades de sus usuarios (es decir, conocer los detalles ).
3. Aumente su conocimiento de la situación creando un mapa del contexto. Esto se logra tomando su cadena de valor y agregando evolución para visualizar cómo cambian las cosas (es decir, enfocándose en el conocimiento de la situación ).
4. Utilice su mapa para aplicar métodos apropiados , para restringir el sistema a pequeños contratos y eliminar sesgos y duplicaciones .
5. Convierta los pequeños contratos en una estructura basada en células con equipos autónomos (es decir, piense en equipos pequeños).
6. Aplicar actitudes adecuadas a los equipos, como pionero, colono y urbanista, e introducir un sistema de robo para habilitar un sistema que se enfrente al cambio constante (es decir, piense en aptitud y actitud ).

Aunque podemos deducir un orden para algunos de los principios dentro de la doctrina, más allá de los trazos generales, entonces no sé qué partes de la doctrina importan más, es decir, ¿es la transparencia más importante que establecer estándares excepcionales?

Por desgracia, probablemente me llevará muchas décadas clasificar esto y, obviamente, debido a los efectos de la coevolución, aparecerán nuevas prácticas y nuevas formas de organización durante ese tiempo. Por lo tanto, la doctrina misma está cambiando con el tiempo. Esta es una de esas situaciones que pintan las situaciones del puente Forth que para cuando finalmente he resuelto un orden, ha cambiado. Sin embargo, puedo adivinar el orden de importancia según la experiencia. He dividido la doctrina en un conjunto de fases discretas que debería considerar, pero al mismo tiempo, quiero que recuerde que estaré sufriendo por mis propios prejuicios. Por lo tanto, tómelo con una pizca de sal y no se preocupe por desviarse de esto. Es solo una guía. Mis fases de doctrina se proporcionan en la figura 236.

Figura 236 – Fases de la doctrina

Las fases son: –

Fase 1 – Detener las autolesiones.
El enfoque en esta primera fase es simplemente el conocimiento y la eliminación de la duplicación. Lo que pretendo no es cambiar radicalmente el entorno, sino evitar que se sigan causando daños. Por lo tanto, el énfasis está en comprender las necesidades de sus usuarios, mejorar el conocimiento de la situación, eliminar la duplicación, desafiar las suposiciones, comprender los detalles de lo que se hace e introducir un mecanismo sistemático de aprendizaje, como el uso de mapas con un grupo como el control de gastos .

Fase 2: ser más conscientes del contexto
Si bien la fase 1 trata de detener la podredumbre, la fase 2 se basa en esto ayudándonos a comenzar a considerar y utilizar el contexto. De ahí que el énfasis esté en utilizar herramientas y métodos adecuados, pensar en FIRE, gestionar la inercia, tener un sesgo hacia la acción, actuar con rapidez, ser transparentes sobre lo que hacemos, distribuir el poder y comprender que la estrategia es un proceso iterativo.

Fase 3 – Más por menos
Llamo a esta sección «Más por menos» porque en retrospectiva (y sí, es probable que esto sea un sesgo) hubo algunas lecciones fundamentales que me perdí (debido a mi propio sesgo de falso consenso) en el original papel. Esas lecciones ahora se cubren principalmente en las fases 1 y 2. En esta fase, nos enfocamos en la mejora constante, lo que significa optimizar los flujos en el sistema, buscar lo mejor, un sesgo hacia lo nuevo, pensar en grande, inspirar a los demás, comprometernos con el camino, aceptar la incertidumbre, asumir la responsabilidad y dar propósito, dominar & autonomía. Esta es la fase que tiene más que ver con el cambio y avanzar en una mejor dirección, mientras que las fases anteriores se tratan de la limpieza.

Fase 4 – Evolución continua
La fase final se centra en la creación de un entorno que se enfrente a los constantes choques y cambios. Este es el punto donde el juego estratégico pasa a primer plano y donde diseñamos con pioneros, colonos y urbanistas. El énfasis está en la evolución constante, el uso de múltiples culturas, la escucha de los ecosistemas externos, la comprensión de que todo es transitorio y la explotación del paisaje.

¿Son las fases, verdad? Es casi seguro que no, y probablemente les falte una cantidad significativa de doctrina no descubierta. Sin embargo, son la mejor suposición que puedo ofrecerles. Hay otras dos partes de la doctrina que he pasado por alto. Ambos son dignos de destacar. Uno es manejar el fracaso, el otro es ser humilde.

Sobre la cuestión del fracaso

Cuando se trata de gestionar el fracaso, la vida es maestra. Para categorizar el fracaso, tiendo a usar los conceptos de ingeniería versus resiliencia de los ecosistemas de CS Hollings; consulte la figura 237.

Figura 237 – Tipos de fallas

La resiliencia de la ingeniería se centra en mantener la eficiencia de una función. La resiliencia ecológica se centra en mantener la existencia de la función. En términos de sostenibilidad, el objetivo de cualquier organización debería ser volverse resiliente. Esto requiere una estructura que pueda adaptarse a la evolución constante junto con muchos ecosistemas de apoyo. Desafortunadamente, la mayoría de las organizaciones más grandes tienden a estar en la categoría robusta, constantemente diseñando procesos para hacer frente a modos de falla conocidos y tratando de mantener la eficiencia de cualquier función de capital cuando ocurre un choque, es decir, constantemente tratando de mantener la rentabilidad y el retorno a los accionistas. Si bien es eficiente, la falta de diversidad en términos de cultura y pensamiento significa que estas organizaciones tienden a estar mal preparadas para entornos que cambian rápidamente fuera de su «zona de confort».

Doctrina: Sea humilde

Si vamos a discutir el sesgo y el fracaso en el mundo de la tecnología, probablemente no haya mejor ejemplo que Open Stack. También es uno con el que estoy familiarizado. Cuando estaba en Canonical, uno de mi camarilla que ayudó a impulsar la agenda de Ubuntu en la nube fue Rick Clark. Es un gerente de ingeniería talentoso y rápidamente aprendió los conceptos de mapeo. También es un buen amigo. Aproximadamente un año después, Rick estaba trabajando para Rackspace. Rick y yo habíamos discutido durante mucho tiempo una jugada abierta contra Amazon en la nube, cómo crear un ecosistema de proveedores públicos que coincidiera con las API de Amazon y forzar una guerra de precios para aumentar la demanda más allá de la capacidad de Amazon para suministrar, fragmentando así el mercado. Me encantó recibir esa llamada de Rick a principios de 2010 sobre sus planes en este espacio y para marzo de 2010, Acepté ponerlo en el centro y el escenario principal de la cumbre de computación en la nube en OSCON. Lo que se lanzó fue OpenStack.

Mi entusiasmo y alegría, sin embargo, no duró mucho. En la fiesta de lanzamiento esa noche, me presentaron a varios ejecutivos y durante esa discusión quedó claro que algunos miembros del equipo ejecutivo habían agregado sus propios procesos de pensamiento al juego de Rick. Habían tramado una idea que era tan tonta que toda la empresa estaba amenazada. Esa idea, que socavaría todo el enfoque del ecosistema, era diferenciar cosas que no importaban: las API. Advertí que esto conduciría a una falta de enfoque, un dilema colectivo de prisioneros de diferenciación de las empresas, un error en contrarrestar el beneficio del ecosistema que tenía Amazon y una serie de otros problemas, pero se mantuvieron firmes. Mediante el uso de su propia API, eliminarían todas las ventajas de Amazon y dominarían el mercado. Eventualmente, como me dijo un ejecutivo, Amazon tendría que adoptar su API para sobrevivir. El lugar estaba lleno de arrogancia y confianza en sí mismo.

Traté de apoyar tanto como pude, pero sin embargo tuve bastantes discusiones públicas sobre esta idea de API. Al final de 2012, había llegado a la conclusión de que OpenStack, en lugar de ser la gran esperanza para un mercado competitivo, era un ‘pato muerto’ obligado a luchar contra VMware en lo que finalmente será un espacio agonizante y abarrotado mientras Amazon (y otros jugadores) se llevaron la futuro. Admiro el nivel de marketing, esfuerzo y entusiasmo que ha creado OpenStack y ciertamente hay nichos para que cree una existencia rentable (por ejemplo, en el espacio de equipos de red) pero a pesar de la creencia de que desafiaría a Amazon, ha perdido. La confianza de OpenStack fue, en última instancia, su fracaso. La arrogancia, la falta de pragmatismo, su decisión de no explotar los ecosistemas que ya existían y su propia confianza en sí mismo no le han venido bien. Fue un fracaso en cascada de proporciones significativas con personas que creían que OpenStack ganaría solo porque otros en sus círculos lo decían en público. Muchos dirían hoy que OpenStack no es un fracaso y que los objetivos de respaldar un mercado competitivo de proveedores públicos no eran su objetivo ni planeaba enfrentarse a Amazon. Eso es simplemente historia revisionista y un intento de hacer más aceptable el presente.

Sí, OpenStack ha hecho ganar mucho dinero a algunas personas, pero es un pececillo en el espacio de la nube. Ciertos analistas predicen que todo el mercado OpenStack alcanzará los $ 5 mil millones en 2020. Incluso si aceptamos esta cifra al pie de la letra y esto es para todo un mercado, los ingresos de AWS alcanzaron los $ 12 mil millones en 2016. Los ingresos futuros para todo un mercado en 2020 ¿Es menos de la mitad de los ingresos de un solo proveedor en 2016 y crece a un ritmo más lento? Tendría que estirar la definición hasta el punto de ruptura para llamar a esto un éxito, por lo tanto, sospecho que la importancia de un poco de revisión. Sin embargo, la batalla es un juego largo y hay una ruta de regreso a la arena pública a través de China, donde existen muchos mejores jugadores.

Necesitas aplicar el pensamiento

Uno de los problemas del mapeo es que la gente espera que les dé una respuesta. Los mapas no son un 2×2 donde tu objetivo es llegar a algún rincón para ganar el premio mágico. Todos los mapas lo ayudan a comprender el entorno, desafiar lo que está haciendo, fomentar el aprendizaje y la aplicación de un poco de pensamiento. Puede existir todo tipo de circuitos de retroalimentación para los incautos. Por ejemplo, consideremos la atención médica.

Una cuestión de salud

Tienes un gobierno que tiene necesidades, incluida la necesidad de que la gente lo vote, asumiendo que es una democracia. Esos votantes también tienen necesidades, una de las cuales es sobrevivir. En el caso de afecciones médicas, esto requiere un tratamiento del cual existe una serie de tratamientos. Desde tratamientos una vez novedosos como los antibióticos que se han industrializado mucho hasta tratamientos más novedosos hoy como CRISPR. Con el tiempo, todos estos enfoques novedosos evolucionan para industrializarse y surgen otros enfoques novedosos. De ahí una tubería. Obviamente, dicho tratamiento tiene un costo, por lo que asumimos que hay un presupuesto para la atención médica junto con los centros de tratamiento. Ahora, supongamos que el Gobierno ha decidido brindar atención médica universal. Dado que esto no será gratuito, necesitaremos algunos impuestos. Podemos mapear esto rápidamente – vea la figura 238

Figura 238 – Mapa de la atención sanitaria universal

A medida que avanzan los mapas, esto es increíblemente simplista, falta una gran cantidad de cosas y podría mejorarse significativamente. Pero, estoy usando esto como ejemplo y lo haré por ahora. Miremos ese mapa. Ciertamente podemos comenzar a agregar cifras financieras para el flujo y podemos comenzar a preguntarnos por qué los centros de tratamiento no están altamente industrializados. ¿Seguramente son iguales? Sin embargo, agreguemos algo más. Consideraremos la atención preventiva.

El Gobierno ha decidido introducir un programa de atención preventiva al que se exige o se anima a los votantes a asistir. Obviamente, hay un impacto presupuestario (es decir, el gasto en atención preventiva), pero la buena noticia es que mediante el uso de la atención preventiva podemos reducir el volumen general de tratamiento (es decir, algunas enfermedades se pueden prevenir), reduciendo así el coste y satisfaciendo las necesidades de pacientes para sobrevivir más tiempo. ¡Todos están felices! Excepto que hay un problema. Si bien el objetivo de reducir costes, brindar un mejor servicio a más personas y permitir que las personas vivan más tiempo es un objetivo noble, ¡el problema es que nuestra gente vive más tiempo! Desafortunadamente, lo que descubrimos posteriormente es que las personas que viven más tiempo incurren en mayores costes de tratamiento debido a los tipos de enfermedades por las que mueren o la necesidad de algún tipo de apoyo.

Figura 239 – Comentarios de atención médica

El problema al que nos enfrentamos ahora es una población de edad cada vez mayor (debido a la atención médica preventiva que introdujimos) que requiere mayores costes de tratamiento. Lo que en un momento pareció ser un beneficio (atención médica preventiva) se ha convertido en una carga. ¿Qué haremos? Suponiendo que no somos una especie de dictadura, necesitábamos que la gente votara por nosotros, por lo que la ceremonia vikinga de Ättestupa está fuera de discusión, tenemos que reducir de alguna manera los costos del tratamiento. La mejor forma de hacerlo es acelerar el proceso, es decir, queremos que los tratamientos se industrialicen más rápidamente. Para lograr esto, necesitamos más competencia, que podría ser mediante la reducción de las barreras de entrada, la creación de fondos para alentar a los nuevos participantes o el uso de enfoques abiertos para permitir que los tratamientos se extiendan más rápidamente en el mercado. Supongamos que hacemos esto,

Figura 240 – Fondo médico

Por lo tanto, la gente vive más tiempo, pero estamos contrarrestando cualquier aumento de costes debido a nuestro enfoque de industrialización en el campo de la medicina. Todos están felices, ¿verdad? Incorrecto. Hay empresas que brindan tratamientos en ese espacio y probablemente tengan inercia ante este cambio. Sus intentos de industrializar sus productos más rápidamente significan más inversión y pérdida de ganancias. Por supuesto, podríamos mapearlos, usarlo para ayudar a comprender sus necesidades y refinar el juego un poco más. Sin embargo, el punto que quiero plantear es este. No hay respuestas simples con mapas. A menudo hay ciclos de retroalimentación y sorpresas ocultas. Necesita adaptarse a medida que se descubren las cosas. Sin embargo, a pesar de todo esto, aún puede usar mapas para anticipar y prepararse para el cambio. No sé nada sobre atención médica, pero incluso yo sé (por un mapa) que si va a invertir en atención preventiva, tendrá que invertir en fondos médicos para alentar a los nuevos participantes en el mercado.

Puse en cursiva lo anterior porque, lamentablemente, aquí es donde la falta de humildad y el efecto Dunning-Kruger pueden tener consecuencias terribles. Es fácil dejarse seducir por la idea de que comprende un espacio y que su plan funcionará. Alguien con experiencia en medicina podría mirar mi declaración sobre cuidados preventivos y fondos médicos y, con razón, romperla en pedazos porque no tengo experiencia en el espacio, no sé de qué estoy hablando. Pero puedo crear una historia convincente con un mapa a menos que alguien me desafíe. Por eso recuerda siempre que todos los mapas son imperfectos y no son más que una ayuda para el aprendizaje y la comunicación. No tienen «razón».

Una cuestión de planificación: OODA y PDCA

La idea de que deberíamos planificar en torno a un pronóstico y la importancia de la precisión en el pronóstico tiene sus raíces en la filosofía occidental. El acto de planificar es útil para ayudarnos a comprender el espacio, hay muchos patrones predecibles que también podemos aplicar, pero hay mucha incertidumbre e incógnitas, incluidas las acciones de los actores individuales. Por lo tanto, cuando se trata de planificación, debemos considerar muchos escenarios y una amplia gama de posibilidades. Como dijo Deng Xiaoping, administrar la economía es como cruzar el río sintiendo las piedras. Tenemos un propósito y una dirección, pero nos adaptamos a lo largo del camino. Esto está en el corazón de la estrategia de ciclo – O bserve el medio ambiente, O riente alrededor de ella, D ecide su camino y A ctúa – y se le conoce como OODA.

En este punto, alguien normalmente menciona el ciclo PDCA de Deming: Planificar, hacer (Do), verificar (Check) y Actuar. Para comprender la diferencia, debemos considerar un poco más el ciclo OODA. El bucle OODA completo de John Boyd se proporciona en la figura 241

Figura 241 – OODA

Hay varios componentes sobre los que me gustaría llamar su atención en la parte de orientación del ciclo. Nuestra capacidad para orientar depende de nuestra experiencia previa, herencia cultural y disposición genética a los eventos en cuestión. En términos de una organización, su disposición genética es similar a la doctrina y las prácticas que tiene.

Ahora, si se desconoce un evento y estamos en el espacio inexplorado del mapa, entonces no hay nada que realmente podamos planificar. Nuestra única opción es probar algo y ver qué pasa. Este es el mundo del JDI (just do it) o simplemente hazlo. Es un salto hacia lo desconocido y se requiere un enfoque de hacer y luego verificar qué sucedió. Sin embargo, a medida que entendemos más sobre el espacio, nuestra experiencia y prácticas anteriores crecen en esta área. Entonces, mientras que nuestro primer paso a través del ciclo OODA significa que simplemente hacemos y comprobamos, los ciclos posteriores nos permiten comenzar a planificar, luego hacer, verificar el resultado y actuar para actualizar nuestras prácticas. Esto es PDCA. A medida que nuestra experiencia, prácticas e incluso mediciones crecen, nuestro proceso de decisión se refina. Podemos definir concretamente el evento, podemos proporcionar las medidas esperadas, podemos analizar en contra de esto y buscar mejorar lo que se está haciendo y luego controlar las mejoras para asegurarnos de que sean sostenibles. Esto es DMAIC. El ciclo OODA puede resultar en comportamientos muy diferentes de simplemente probar algo a DMAIC dependiendo de cuánta experiencia y herencia exista con lo que se está administrando, es decir, qué tan evolucionado está y qué tan familiarizados y seguros estamos con él. He resumido esto en la figura 242.

Figura 242 – Del «Just do it» a PDCA a DMAIC

Una cuestión de privilegio

Si bien todos los planes deben adaptarse, eso no significa que no podamos planificar escenarios y prepararnos para posibles resultados. Tomemos otro ejemplo, en este caso el automóvil autónomo. En la figura 241, describí la industria automotriz en forma de mapeo. Comenzamos con la necesidad básica del usuario de ir de A a B. Luego nos extendemos a la gestión de rutas (es decir, hacerlo rápidamente), comodidad y asequibilidad. También incluimos el estado: un automóvil no se trata solo de moverse de A a B, también se trata de verse bien mientras lo hace. A partir de esto, nos extendemos a una serie de automóviles con más comodidades, especialmente en términos de características. Menciono un par de partes discretas, desde el entretenimiento hasta los sistemas de información y entretenimiento, y continuamos a lo largo de la cadena de valor. Puede que no esté de acuerdo con los componentes y su posición, pero ese es el propósito de un mapa, permitir esta forma de desafío.

Figura 243 – La industria del automóvil

Sin embargo, ese es un mapa para hoy o más específicamente para 2015 cuando fue escrito. Lo que podemos hacer ahora es hacer avanzar el mapa hacia el futuro. Lo que surge es una imagen de automóviles autónomos (es decir, agentes inteligentes en todos los automóviles), una experiencia inmersiva (el Heads Up y la pantalla se han combinado) y el vehículo en sí se vuelve más comercial, incluso potencialmente más útil.

Por lo tanto, puede pensar en un mundo en 2025 en el que cada vez más no poseemos automóviles, sino que los pagamos en función de los servicios públicos. Los coches son autónomos y cada vez más inmersivos. El coche que me lleva a una reunión podría haber sido el coche que te llevó al teatro anoche. Sin embargo, al usar este mapa también podemos ver algunas otras conexiones que quizás no hayamos considerado antes – vea la figura 244

Figura 244 – La industria del automóvil, 2025

Primero está la creciente importancia del diseño en la creación de la experiencia inmersiva (se muestra como una línea de conexión roja). En segundo lugar está la cuestión del estatus y esa experiencia inmersiva. Si los coches son los mismos, todavía tenemos que satisfacer esa necesidad de estatus. Una forma de lograr esto es tener niveles de suscripción digital, por ejemplo, platino, plata y bronce y alterar sutilmente la experiencia tanto en la inmersión como en el aspecto del automóvil, dependiendo de quién lo ocupe actualmente. Un miembro de bronce estándar podría recibir anuncios, mientras que un miembro de platino recibiría contenido más exclusivo. Pero eso realmente no impulsa el concepto de estatus. La tercera adición es un enlace (en rojo) entre el estado y la gestión de rutas. Si un miembro platino necesita un automóvil, entonces debería tener mayor prioridad. Pero mas que esto Si necesita ir de A a B, mientras conduce (o, para ser más exactos, lo conduce), los miembros de la clase inferior pueden pasar al carril más lento. Con los conductores humanos eso no va a suceder, pero con los vehículos autónomos, entonces ese privilegio se puede automatizar.

Por supuesto, habría reacciones en contra de esto, pero cualquier jugador astuto puede comenzar con el argumento de proporcionar primero rutas más rápidas a los vehículos de emergencia (por ejemplo, bomberos, ambulancias) y, una vez que se haya establecido, introducir más prioridad comercial. Más tarde, esto se puede reforzar aún más con el privilegio de geo-cercado hasta el punto de que los vehículos no se dirijan a las geografías a menos que tenga el nivel de membresía correcto. Para muchos, eso probablemente parecerá razonable hasta el punto en que algún futuro miembro del gobierno se enfrente a la prensa después de un desastre ambiental (por ejemplo, una inundación) donde todas las personas ricas con el estatus digital adecuado escaparon rápidamente y la mayoría de las personas pobres fueron atrapadas en autos en atascos de tráfico interminables. Se va a incorporar la desigualdad social en el transporte.

Obviamente, este tipo de cambio tiene todo tipo de efectos sociales y es necesario considerar el refuerzo del privilegio y el daño que podría causar. Los gobiernos deberían planificar su escenario en el futuro. Sin embargo, el objetivo de los mapas no es solo ayudar a hablar las cosas obvias, por ejemplo, la pérdida de ingresos por licencias al gobierno, los impactos en la señalización del tráfico, la futura prohibición de conductores humanos (que en efecto tienen un precio fuera de la carretera debido al seguro) o los impactos en los aparcamientos. El objetivo de los mapas es ayudarnos a encontrar aquello para lo que podamos prepararnos. Por supuesto, podemos llevar esto un paso más allá. Anteriormente hablamos del uso de la doctrina para comparar organizaciones y el uso de los ciclos de paz, guerra y maravillas para identificar puntos de cambio. En este caso, podemos llevar el mapa de la industria automotriz hacia 2025, agregue nuestras señales débiles para esos puntos de guerra y trate de determinar qué cambiará rápidamente en la industria en ese momento. Luego podemos mirar a los jugadores en ese mercado, tratar de identificar oportunidades para explotar o incluso mirar el juego del estado nación.

En el caso de la industria automotriz, he marcado los puntos de guerra que estarán ocurriendo (o simplemente habrían ocurrido) para 2025 y luego agregué el juego de China en ese espacio. Esto se muestra en la figura 245. Lo que muestra es que China está realizando importantes inversiones estratégicas en partes clave de la cadena de valor antes de estos puntos de industrialización. También está construyendo una forma de juego basada en fuertes restricciones en torno a las materias primas mediante la adquisición de activos significativos en este espacio. Si superpone a las empresas chinas en el mercado y luego realiza un ejercicio similar para Estados Unidos, lo que surge es bastante sorprendente. Si bien muchos han asumido que este futuro estará dominado por empresas estadounidenses y de Silicon Valley, parece cada vez más probable que el futuro del automóvil autónomo pertenezca a China.

Figura 245 – Automoción, puntos de guerra y jugabilidad

Un ejercicio para el lector

Hemos cubierto bastante en este capítulo, desde desarrollar varios conceptos en torno a la doctrina hasta la cuestión del sesgo, la cuestión del fracaso y los circuitos de retroalimentación para la planificación de escenarios. Algunos de estos conceptos los hemos abordado antes en capítulos anteriores, pero el aprendizaje de mapas es como el ciclo de la estrategia en sí: un proceso iterativo. Por supuesto, la práctica importa.

Primero, me gustaría que observara su organización y repasara la figura 236. Determine qué partes de la doctrina usa y en qué partes es pobre o no existe en absoluto. Utilizando las fases como guía, elabore un plan de acción para mejorar la doctrina.

En segundo lugar, me gustaría que tomara una línea de negocio y, utilizando un mapa, la empujara diez años hacia el futuro. Piense en lo que podría suceder, qué circuitos de retroalimentación podrían aparecer y qué oportunidades podría aprovechar.

Por último, dado que ya se ha comparado con la doctrina, me gustaría que mirara a los competidores para la línea de negocio que trazó en el futuro y examinara su doctrina. No se limite a los competidores existentes, sino que piense en quién podría aprovechar el entorno cambiante y mírelos. Quiero que piense en cualquier prejuicio que pueda tener y que lo convencerá de que no será una amenaza. Además, si hicieron un movimiento, ¿qué tan resistente es su organización para cambiar? ¿Tiene una diversidad de cultura, práctica y pensamiento que le permitiría adaptarse?