Tiempo estimado de lectura ( 26 minutos)

Para seguir financiando mi investigación, acepté algunos trabajos pagados más, lo que básicamente significaba convertirme en un mercenario. La computación en la nube estaba entrando fuerte en la escena tecnológica y había mucha confusión al respecto. Por lo tanto, tuve un flujo constante de conferencias, incluidas algunas que realmente pagaron, junto con muchas oportunidades para el trabajo a tiempo parcial. Era el salvaje oeste en informática con, desafortunadamente, algunas prácticas y explotación bastante turbias en la industria. Traté de no causar daño pero tenía un talón de Aquiles en simplicidad.

El peligro de hacerlo simple

Uno de los obstáculos con el mapeo fue que algunas personas lo encontraron complejo. Esto no es realmente sorprendente porque está exponiendo a las personas a un mundo con el que la mayoría no está familiarizada. Pocos en los negocios tienen experiencia práctica con el conocimiento de la situación o el uso de mapas. Muchos no entienden por qué podría ser importante. También se necesita tiempo y esfuerzo para familiarizarse con la creación de un mapa. Una respuesta común tiende a ser «¿puede crear el mapa para nosotros?» Basado en una idea de que luego aplicarán su estrategia general similar. Esto siempre degenera en «¿puedes mostrarnos qué movimientos podemos hacer?» A los que aplicarán su intelecto general. Al final, se convierte en «qué movimiento deberíamos hacer» y luego en general como asentir con la cabeza.

Sin embargo, la confusión sobre la computación en la nube había creado una oportunidad para una nueva forma de pensar y, con suerte, de aprender. Lamentablemente, acumular la complejidad del mapeo en una persona desconcertada que no tiene conexión con la conciencia de la situación puede causar más confusión. La mayoría de las personas solo querían respuestas con las que pudieran estar de acuerdo, como cómo resolver su necesidad de estar en la nube sin sacudir demasiado el barco. Supongo que es por eso que ha habido una gran cantidad de esfuerzos cuestionables en la nube privada.

Por lo tanto, busqué formas de simplificar el mapeo, para hacerlo más apetecible y más familiar. Empecé con un diagrama puntual. Tomaría un diagrama de proceso de negocio o una caja y un cable para un sistema existente, como nuestro automóvil autónomo élfico en la figura 36 ( capítulo 4 ) y luego colorearía diferentes partes de acuerdo con si eran más génesis o mercancía. Produciría algo como la figura 83.

Figura 82. Diagrama «puntual» de un automóvil élfico autónomo

Estos diagramas, además de ser coloridos, resultaban más familiares y menos amenazantes para las personas que habían escrito los originales. Me permitieron introducir con bastante facilidad los conceptos de evolución en una organización y, por lo tanto, pudimos tener una conversación sobre qué métodos usar. Pero sin posición y movimiento, estos diagramas no fueron útiles para un desafío efectivo y el aprendizaje continuo de patrones económicos o formas de juego. Hubo un compromiso entre simplicidad y utilidad.

La simple trampa

La ley de Ashby de la variedad requerida describe cómo el mecanismo de control de un sistema debe ser capaz de representar lo que se está controlando. Las organizaciones son cosas complicadas y complejas. En general, son complicados porque tienen un gran alcance, contienen muchos componentes que requieren especialización y son difíciles de comprender y administrar. También son complejos porque hay muchos comportamientos emergentes. Por ejemplo, tienen muchos componentes en el espacio inexplorado para los que existe incertidumbre y no se puede predecir esto. Lo mejor que puede hacer aquí es sentir su camino. Si bien el mapeo le brinda una ventana a esto, debe tener una capacidad de administración capaz de manejarlo.

Desafortunadamente, existe otra solución a la ley de Ashby. En lugar de lidiar con un entorno complicado que contiene complejidad, toma la decisión de fingir que lo que se administra es simple. En los negocios, nos gustan cosas como los diagramas 2×2 no porque representen la realidad, sino porque la oscurecen y, por lo tanto, son fáciles de entender. Intercambiamos nuestra capacidad de aprender continuamente sobre el contexto por una ilusión de simplicidad y fácil administración.

Es importante hacer una distinción aquí. El acto de tomar algo complicado (como una máquina) y descomponerlo en componentes pequeños pero manejables o usar un mecanismo para detectar un cambio incierto en un entorno complejo no es lo mismo que tratar de administrar un sistema así fingiendo que es una matriz de 2×2. Como diría Einstein: «Todo debería ser lo más simple posible, pero no más simple».

Finalmente, me enfrenté a una elección. ¿Sigo usando estos diagramas de «puntos» haciendo que los conceptos de evolución sean más accesibles y simplemente acepto los defectos (y el dinero) o tomo un camino más lento y trato de empujar a las organizaciones hacia una mayor comprensión de la posición y el movimiento? Si tenían problemas, entonces podría comprometerme y hacer el trabajo pesado por ellos con solo proporcionarles un mapa y los resultados. Sin embargo, ya sabía que esto los haría depender de mí, que era el camino del consultor por el que estaba tratando de luchar. Mi propósito era liberar a las personas de las cadenas de los consultores y no encadenarlas aún más. Este compromiso estaba fuera de discusión. Tuve que tomar el camino más lento. Me gusta pensar que me mantuve firme aquí, pero con muy pocas empresas mapeando.

Encontrando mi mojo

(Mojo = poder personal o influencia que se tiene sobre otras personas)

Mi salvación fue un trabajo remunerado que me gusta especialmente. Se trataba de una cuestión de eficiencia versus eficacia y, para tener alguna esperanza de explicarlo, primero debemos introducir tres conceptos: 1) desarrollo basado en el valor, 2) granularidad de precios y 3) flujo. Después de lo cual podemos conectarlos todos juntos para examinar esta pregunta. Voy a tener que saltar en la historia para hacer esto, pero espero poder mantenerlo todo de una manera unificada.

1) Desarrollo basado en el valor

En 2003, la empresa que dirigía construyó y operó sistemas de pequeño tamaño para otros. No había grandes sistemas, estos eran más de la escala de £ 100k – £ 2M que cubrían algunos millones de usuarios. Nuestros clientes generalmente querían escribir una especificación detallada de exactamente lo que necesitaban para asegurarse de que entregáramos. Eso no suena tan mal, pero incluso a esta pequeña escala, algunos de los componentes de estos proyectos estarían en el espacio inexplorado y, por lo tanto, nadie sabía exactamente lo que se quería. Desafortunadamente, en ese entonces, no tenía el lenguaje para explicar todo esto. Por lo tanto, construimos y operamos los sistemas e inevitablemente tuvimos cierta tensión sobre el control de cambios y conversaciones sobre qué característica estaba dentro o fuera de un contrato en particular.

Durante una de estas conversaciones, le indiqué al cliente que estábamos sentados alrededor de una mesa discutiendo sobre un papel, pero ninguno de nosotros estaba hablando de lo que los usuarios necesitaban. El contrato no era realmente el cliente que tenía en frente; los usuarios finales del cliente lo eran. Necesitábamos cambiar la conversación y enfocarnos en el usuario final. Sugerí que deberíamos crear una métrica de valor basada en el usuario final, algo en lo que ambos podríamos trabajar. La idea cayó en oídos sordos ya que el cliente estaba preocupado por el contrato, pero al menos se plantó la semilla. No pasó mucho tiempo después de que otro proyecto brindó la oportunidad de probar esta idea. El cliente me dio una especificación y preguntó cuánto costaría construirlo. Respondí: «¿Cómo suena gratis?»

Se sorprendieron un poco, pero luego agregué: “Sin embargo, tendremos que pagarnos para operar el sistema. Necesitamos determinar una medida de valor o valor y me pagarán por eso ” . Hubo un poco de um y ah, pero finalmente acordamos probar un método de desarrollo basado en el valor.

En este caso, el objetivo del sistema era proporcionar pistas para una gama costosa de impresoras de gran formato (large format printers = LFP). El cliente quería más clientes potenciales. Sus posibles usuarios finales querían una forma de obtener más información sobre estas impresoras junto con una forma de probarlas. Construiría algo que se casara con los dos conjuntos diferentes de necesidades. Pero en lugar de que el cliente pague por adelantado y asuma todo el riesgo, lo construiría gratis y cobraría una tarifa por cada nuevo cliente potencial creado.

Nosotros (como el cliente y mi empresa) ya no estábamos enfocados en lo que estaba dentro o fuera de un contrato, sino en una sola tarea de crear más clientes potenciales. Ambos teníamos un incentivo para esto. También tenía un nuevo incentivo para la rentabilidad porque cuanto más eficiente era el sistema, más ganancias obtenía. Estuvimos de acuerdo, así que construí y operé un sistema que permitía a los consumidores cargar una imagen, probarla en una impresora de gran formato y obtener la impresión más información sobre el rendimiento del kit más una llamada de ventas. El sistema se disparó.

En tres meses habíamos generado más clientes potenciales de los que el cliente normalmente tenía en un año y esto se estaba acelerando. Fue asombroso. Los ingresos del cliente se dispararon, pero también mis ingresos, ya que el sistema se basaba en una métrica de clientes potenciales. Cuanto más éxito tuvieron, más éxito tuve yo. Era una situación en la que todos ganaban o eso creía. Por desgracia, esto en realidad creó dos problemas y un gran dolor de cabeza.

Los problemas se debieron a que el cliente no estaba preparado para este nivel de interés y a que los sistemas de presupuesto interno no estaban diseñados para hacer frente a un éxito tan variable. ¿Qué tiene que ver el presupuesto con esto? Bueno, para el cliente, el éxito consistía en más clientes potenciales que se traducían en más ingresos. Esto fue bueno desde el punto de vista presupuestario. Pero cuanto más éxito tenía el cliente, más aumentaba mi tarifa, ya que también se basaba en clientes potenciales. Esto fue malo desde el punto de vista presupuestario. El sistema tuvo tanto éxito que excedió una cifra del presupuesto interno que el cliente había establecido para los costos y esto provocó un conflicto interno con las demandas de apagar el sistema hasta que se asignara un nuevo presupuesto (un proceso muy largo). ¿Apagar un sistema de generación de ingresos porque le está yendo mejor de lo esperado y pasó alguna cifra presupuestaria arbitraria? Esto es lo que sucede cuando un enfoque de presupuestación inflexible de talla única se ajusta a la realidad.

Antes de decir «esto es una tontería», en realidad no lo es. Con el tiempo, las empresas tienden a construir una manera de trabajo y procesos, el corpus corporativo, diseñado para detener fallas pasadas. Todo está hecho con intenciones razonables. El deseo de gastar el dinero de manera eficaz y el deseo de saber que los recursos se están utilizando bien. Esa masa de buenas intenciones suele ser la causa de muchos problemas cuando intentas cambiar el sistema. Ese corpus puede convertirse en un cadáver, un zombi que mata la innovación cada vez que se encuentra. Había intentado cambiar el sistema mediante la introducción de un enfoque basado en el valor y debería haber sabido que esto causaría tensiones con el corpus, en este caso el sistema presupuestario. Aprendí esa lección rápidamente.

He utilizado enfoques basados ​​en el valor (a menudo llamados «resultados») muchas veces durante la última década, de hecho los prefiero. Si bien tienden a resolver el problema de un enfoque excesivo en los contratos, invariablemente se han topado con otros obstáculos, como que un cliente no pueda describir una métrica de valor o el propósito del sistema o incluso conflictos y políticas dentro de los procesos internos. Debe ser consciente de esto y mitigarlo.

Junto con problemas como la falta de preparación para el aumento de la demanda o el corpus corporativo, también estaba el dolor de cabeza que causaba este enfoque basado en el valor. Esta fue mi migraña. Existía algún riesgo financiero asociado con este proyecto y se necesitaba alguna inversión. Tenía que preocuparme no solo por el desarrollo sino también por las operaciones. Esto incluyó una gran cantidad de inversión de capital junto con costes que no eran realmente variables o que solo podía adivinar. Para minimizar el riesgo, compartimos componentes comunes con otros proyectos, pero en un gran entorno de aplicación heterogéneo, esto solo complica la asignación de costes. Cuánto nos costaría un usuario que visitara nuestra aplicación en términos de computación, energía y uso del centro de datos fue una pregunta increíblemente difícil.

En mis modelos de riesgo, tampoco tenía una forma clara de determinar los costes operativos a medida que escalaba. Tuve que hacer muchas estimaciones sobre los cambios paso a paso y la cantidad de recursos informáticos que utilizaría una aplicación que no se había creado. El modelo financiero se parecía más al arte que a cualquier forma de ciencia. Parte de esa incertidumbre termina como «relleno» en la métrica, por ejemplo, el precio por cliente potencial que cobraría. Afortunadamente, otras áreas tenían mejores modelos de costes. En el ejemplo de LFP anterior, los sistemas de distribución e incluso la impresión eran más variables (es decir, precio por impresión o precio por paquete) porque teníamos experiencia en la ejecución de un servicio de impresión y fotografías online. Esto me lleva al siguiente tema de la granularidad de precios.

2) Granularidad de precios

Con un enfoque basado en el valor, tengo un fuerte incentivo para: –

• Reducir el coste operativo del proyecto porque cuanto más barato es, más beneficio obtengo.
• Proporcionar confiabilidad porque si el sistema fallaba, no estaba ganando dinero.
• Asegúrese de que el sistema maximice la métrica de valor. En el caso de LFP, esta métrica estaba «generando clientes potenciales».

Pero también tenía preguntas sobre dónde invertir. En el caso de LFP, le estaba yendo muy bien (esto fue antes de las travesuras presupuestarias), por lo que decidí invertir $ 100K adicionales. ¿Pero dónde mejor pongo el dinero? ¿Mejorando la confiabilidad del sitio? ¿Reducir el coste operativo de la aplicación mediante un mejor código? ¿Maximizar el número de usuarios a través del marketing? ¿Mejorando la conversión de usuarios a clientes potenciales? ¿Qué opción me trae el mejor rendimiento? Esta es una pregunta particularmente difícil de responder si no puede determinar de manera efectiva el costo operativo de una aplicación más allá de agitar la mano o si también se adivinan otros datos.

Uno de los enormes beneficios de Zimki (nuestra plataforma como juego de servicio en 2006) no solo fue su naturaleza sin servidor y cómo se podía simplemente escribir código a través de un IDE en línea, sino que también su granularidad de precios se reducía a la función. Esto no fue un accidente ya que tenía una verdadera necesidad de saberlo. Cualquier aplicación no es más que una función de alto nivel que llama a otras funciones. Si desarrollaba una función en Zimki, cada vez que se llamaba a esa función, podía ver exactamente cuánto me había costado. Se me cobraron los recursos de red, almacenamiento y computación utilizados por esa función. Fue una gran revelación. Cambió el comportamiento de manera significativa porque de repente en el mar de código que es mi aplicación, pude encontrar funciones individuales que me cuestan más desproporcionadamente.

Hasta donde yo sé, este precio por función no existía en el mundo de TI en 2006 y no vimos una granularidad de precios equivalente hasta que se lanzó AWS Lambda en 2014. Ahora, obviamente, yo también era el proveedor de Zimki detrás de la escena. Había una compleja gama de conceptos de bienes y todo tipo de instrumentos financieros para poder proporcionar esas cifras de costes. Pero esto se extrajo del desarrollador. Todo lo que vieron fue un coste cada vez que su función se ejecutó, sin importar cuánto escalara. No hubo inversión de capital y esto convirtió el coste operativo de una aplicación en una variable manejable.

3) Fluir

Ahora voy a combinar las ideas de desarrollo basado en el valor (resultado) y la granularidad de precios para presentar una idea conocida como flujo. Para hacer esto, vamos a revisar el proyecto LFP, pero esta vez con un mapa y el conocimiento de lo que puede aportar una plataforma de servicios públicos. Cuando estábamos trabajando en el proyecto LFP, no había desarrollado completamente el concepto de mapeo y Zimki no fue lanzado. Por lo tanto, este es un análisis posterior al evento y más de lo que podría haber sucedido en lugar de lo que sucedió.

Entonces, volvamos a 2008. Sabemos cómo trazar (lo sabíamos en 2005). Imaginemos que Zimki (lanzado en 2005) hubiera sobrevivido o que haya surgido alguna otra plataforma equivalente como servicio. Imaginemos ahora un escenario en el que el cliente ha aparecido con el proyecto LFP y está dispuesto a construirlo utilizando un desarrollo basado en el valor (como sucedió en 2003).

En la figura 84, he creado un mapa del proyecto LFP basado en el valor. No marcaré puntos en este mapa, espero que ahora tengas suficiente experiencia para comenzar a leerlos.

Figura 84. Mapa del proyecto LFP

El mapa comienza con nuestro cliente que necesita más clientes potenciales y, en última instancia, los consumidores compran su producto. La conversión de cliente potencial a la compra de una impresora está más allá del alcance de este proyecto, ya que estaba dentro de la organización de ventas del cliente. Nos enfocamos únicamente en generar clientes potenciales. El otro tipo de usuario en este mapa es el consumidor que, con suerte, comprará una de estas costosas impresoras. Tienen diferentes necesidades, quieren saber cuál es el tipo de impresora adecuado para sus operaciones comerciales y probarlo antes de comprar algo que usarán. En este proyecto, nuestro objetivo es proporcionar un mecanismo en línea para que el consumidor conozca la impresora (un micrositio) junto con un método para probarla (la aplicación de prueba).

La prueba es una imagen de alta resolución que el usuario carga y que luego se imprime con la impresora de su elección. Su póster (de gran formato) se distribuiría al usuario junto con un póster gráfico estándar (mostrando todas las capacidades), folletos de marketing relevantes y una llamada de ventas. El espacio de la plataforma, que fue la fuente de mis dolores de cabeza originales debido a mi incapacidad para proporcionar un coste operativo variable para el uso de aplicaciones, está evolucionando hacia un servicio más de utilidad.

Entonces, supongamos que decidimos utilizar una plataforma de servicios públicos. Ahora voy a agregar algunos indicadores financieros a este mapa. Ver figura 85.

Figura 85 – Indicadores financieros en el proyecto LFP

Desde el mapa, esperamos que los usuarios visiten nuestro micrositio que ensalzaría los beneficios de tener una impresora de gran formato. Con suerte, esto persuade a algunos de estos visitantes para que lo prueben. El acto de convertir a un visitante en un cliente potencial real requiere que el usuario pruebe una impresora. Por lo tanto, tenemos múltiples tasas de conversión, por ejemplo, de un micrositio a una aplicación de prueba y de un visitante a un cliente potencial. Al principio, estos serán desconocidos, pero podemos adivinarlo.

Normalmente, operar un micrositio requiere todos esos costes difíciles de calcular, pero en el mundo de las plataformas de servicios públicos, su aplicación es simplemente una función que se ejecuta en la plataforma y me cobran por su uso. El coste operativo de mi micrositio es básicamente el número de visitantes x el coste promedio de la función del micrositio. Recuerde, una aplicación consta de muchas funciones y los usuarios pueden navegar por ella, lo que significa que algunos usuarios «errantes» resultan más costosos que otros. Pero podemos hacer frente a eso tomando un promedio de nuestro micrositio.

Lo mismo se aplicará a mi aplicación «probar la impresora» (prueba), pero en este caso los usuarios incluirán visitantes convertidos del micrositio junto con aquellos que visiten directamente. Cada uso de la aplicación de prueba (una función) incurrirá en un coste. Pero al igual que con el micrositio, esta es una variable. Por supuesto, el coste funcional real de la aplicación de prueba podría ser tremendamente diferente del micrositio dependiendo de lo que hicieran las aplicaciones y de qué tan bien se escribió el código, pero al menos tendríamos un precio granular para cada llamada. Finalmente, cada visitante que pruebe una impresora generará un costo de distribución e impresión para mí, pero también ingresos, ya que se han convertido en un cliente potencial.

Este no es el único camino por el que alguien puede imprimir un póster. Es posible que el visitante no provenga del micrositio, sino que vaya directamente a la aplicación de prueba a través del boca a boca o si exponemos la aplicación de prueba como una API. Hay varios flujos potenciales a través del mapa.

Cuando miras cualquier mapa, puede haber muchas formas de flujo dentro de él, ya sean financieras o de otro tipo. Pueden ser flujos de ingresos o flujos de riesgo. Por ejemplo, si la plataforma de servicios públicos muere debido a algún evento catastrófico, afectará mi micrositio y mi aplicación de prueba, lo que afectará las necesidades del consumidor y detendrá la generación de clientes potenciales. Esto supondría una sanción económica para mí en términos de pérdida de ingresos. Mientras que, si me quedo sin folletos, esto afecta la distribución y tengo la opción de enviar las impresiones ahora o retrasar hasta que los folletos estén disponibles. En la figura 86, he dado un ejemplo de un flujo dentro de un mapa desde el consumidor potencial a través de su necesidad de micrositio para probar la aplicación y la distribución.

Figura 86 – Flujo del proyecto LFP

Es importante tener en cuenta que las interfaces entre los componentes de un mapa representan estos flujos de capital, ya sean físicos, financieros, de información, de conocimiento, de riesgo, de tiempo o sociales. Podría ser cualquier cosa que intercambiemos. Las cosas rara vez son gratis. Siempre que utiliza un servicio, está intercambiando algo, ya sea información o capital social (por ejemplo, lealtad a un plan) o incluso solo su tiempo (por ejemplo, para crear nuevas entradas, editar el contenido).

Al utilizar el concepto de flujo, es relativamente sencillo construir un modelo financiero para el sistema. En la figura 87, he creado el esqueleto de tal modelo para el mapa de arriba.

Figura 87. Creación de un modelo financiero para LFP

Esto es como maná del cielo para alguien que intenta construir un negocio. Ciertamente, tengo la inversión para desarrollar el código, pero como la aplicación tiene un coste operativo variable, puedo ganar dinero en una máquina de impresión que crece con los usuarios. También cambia mi enfoque en la inversión: ¿quiero invertir en aumentar el marketing para más usuarios, o la tasa de conversión, o tal vez la aplicación de prueba está tan mal escrita (o una función dentro de ella) que invertir en la mejora de la codificación me traerá mejores resultados? ¿devoluciones? De repente, toda la forma en que construyo un negocio e invierto cambia.

Ahora volvamos a cuando construimos LFP en 2003. No había una plataforma de servicios públicos, no tenía mapas y no tenía el concepto de flujo. En cambio, mi CFO y yo teníamos una gran cantidad de hojas de cálculo tratando de calcular lo que hacía lo anterior y hacer frente a todas las inversiones escalonadas y los costes de capital necesarios. Lo que fue una pesadilla en 2003 es un juego de niños en 2016.

Siempre que esté construyendo algo novedoso, el juego consiste en utilizar los gastos operativos sobre el capital tanto como sea posible para reducir el riesgo, ya sea debido a que el sistema no se usa o crece rápidamente. Desea vincular el coste lo más cerca posible del camino de la generación de ingresos, especialmente dentro de cualquier sistema basado en el valor cuando está apostando por un resultado incierto. Sin embargo, siempre habrá alguna inversión, por ejemplo, escribir la aplicación, comercializar el micrositio. Este tipo de modelo puede ayudarlo a identificar qué opciones mejoran la ecuación y, por lo tanto, dónde debe invertir para el futuro.

Eficiencia vs efectividad

Después de presentarle los conceptos de 1) desarrollo basado en el valor, 2) granularidad de precios y 3) flujo, volvamos ahora a nuestra historia principal.

Así que ahí estaba yo en 2008 con una comprensión de la importancia de los mapas y del flujo de capital dentro de ellos. Esto me ayudó a explicar una cuestión de eficiencia versus efectividad en uno de los proyectos de mi cliente. Estaba bastante orgulloso de ello. Desafortunadamente, existía un problema.

Con suerte, está descubriendo que los mapas pueden ser una herramienta estratégica bastante útil. La información que contienen puede ser muy sensible. Ciertamente no voy a romper la confianza de un cliente al exponer su ropa sucia. Es por eso que muchos de los mapas que utilizo en este libro están ligeramente distorsionados y no identifican al propietario original a menos que sea yo quien dirija el programa. No me importa que sepas todos los errores y fallas que he cometido, pero no todos son así. Si no se siente cómodo con esto y necesita la tranquilidad de que le digan que “la gran empresa X hizo Y”, entonces deberá buscar a alguien más que le ayude.

Para superar este problema de confidencialidad, la siguiente sección cubre un caso hipotético que combina una historia relacionada con una empresa moderna para ayudar a contar una historia pasada que he puesto en un contexto tecnológico. Sí, los mapas son parte de la narración de historias, pero como dijo JRR Tolkien al escribir El señor de los anillos, «sabiamente comencé con un mapa».

Nuestra historia comienza, como muchos lo hacen, con un desafío y, lamentablemente, sin mapas. La empresa se estaba expandiendo y necesitaba aumentar sus recursos informáticos. Había creado un diagrama de flujo de proceso para esto (figura 88) que involucraba una solicitud de más computación para las acciones necesarias para satisfacer esa demanda.

Figura 88 – El flujo del proceso

Sin embargo, el proceso tenía un cuello de botella. Una vez que los servidores se entregaban en la «entrada de mercancías», era necesario modificarlos antes de colocarlos en estanterías. Esto requería mucho tiempo y, a veces, era propenso a fallar. Se centraron en mejorar la eficiencia del flujo del proceso, ya que era importante para su futura generación de ingresos. Había una propuesta sobre la mesa para invertir en robótica para automatizar el proceso de modificación de los servidores. Si bien la propuesta era costosa, los beneficios fueron considerables, especialmente teniendo en cuenta los importantes ingresos futuros que estaban en riesgo. Se había calculado un ROI muy positivo.

Quiero que considere lo anterior por un momento y decida si una propuesta para invertir en la mejora de la eficiencia de un proceso ineficiente tiene sentido, particularmente cuando los beneficios de la propuesta superan ampliamente los costes y su flujo de ingresos futuro está en riesgo.

Conocí a la empresa, hablé sobre el concepto de evolución y sería justo decir que no tenían ningún interés en el mapeo. Había mencionado el diagrama de «puntos» y acordamos echar un vistazo a la propuesta a través de esta lente. He dado los mismos primeros pasos (ver figura 89) y «detecté» el proceso. Si bien los pedidos y los productos en proceso estaban bastante industrializados, la parte de modificación del proceso era muy personalizada.

Figura 89 – Diagrama de puntos del proceso.

Es importante pararse un minuto aquí y echar un buen vistazo al diagrama de arriba. Intente ver si nota algo interesante o extraño antes de continuar con esta historia.

Ahora voy a convertir el diagrama de arriba en un mapa y espero que el problema se aclare. Comencemos por la necesidad del usuario de más computación. En realidad, esto tiene dos necesidades, el pedido de un servidor y el trasiego del servidor una vez entregado. Aparentemente, el montaje del equipo (es decir, montaje en bastidores, adición de energía y cableado) requiere modificaciones en el servidor, de ahí el interés de las empresas en la automatización con robótica. Ambas cadenas están conectadas en el punto del «servidor» y «mercancías en». Dibujé esto en la figura 90 con ambos flujos.

Figura 89. Mapeo de la propuesta

Tómese otro minuto aquí y observe bien el diagrama de arriba. Intente y vea si nota algo interesante o extraño esta vez antes de continuar con la historia.

Lo que merece la pena señalar es que los racks se consideraron personalizados. En la investigación, la empresa siempre había utilizado racks hechos a medida e incluso tenía una empresa de confianza que los fabricaba para ellos. Esto era solo parte de su corpus corporativo, un fantasma de un pasado lejano que todavía rondaba el lugar. Si le preguntaras a la empresa por qué estaban usando racks hechos a medida, te dirían que esto es lo que siempre han hecho, así es como funcionaban y los racks fueron diseñados para ellos. También le dirían que los racks eran irrelevantes para el proyecto en cuestión, que se trataba de automatización.

Sin embargo, investigue un poco más y llegaremos a la razón por la que los servidores necesitaban modificaciones. Resulta que los servidores estándar están diseñados para adaptarse a racks estándar. No encajaban en los racks hechos a medida que la empresa había construido con tanto cariño. Por lo tanto, era necesario agregar placas adicionales, perforar agujeros en los servidores: esta era la modificación que se requería. Seamos claros, sobre la mesa había una propuesta de invertir en robótica para personalizar los servidores estándar para que encajen en los racks personalizados que la empresa estaba comprando. ¿Sigue teniendo sentido la propuesta? ¿Es una buena inversión? ¿Hay alternativas? ¿Te escucho gritar «usa racks estándar»?

Ahora la pregunta es si deberíamos usar racks estándar. Esto obviamente mueve los racks hacia la mercancía (que es donde deberían estar) y la parte de modificación desaparece aunque todavía tenemos montaje, cableado y energía. Sin embargo, parece mucho mejor (ver figura 91).

Figura 91. Uso de racks estándar

Sin embargo, todavía tiene un problema que es el patrimonio heredado. ¿Vas a migrar todos los racks? ¿Qué pasa con nuestros costes ocultos? ¿Cómo vamos a mantener nuestros sistemas existentes? Habrá una larga lista de razones para contrarrestar el cambio propuesto. Antes de decir “esto es una tontería, deberíamos cambiar”, recuerde el ejemplo del presupuesto, el corpus corporativo y no espere cambiar un sistema sin cierta resistencia.

En este caso, a pesar de la resistencia, deberíamos dar un paso más. La informática se estaba convirtiendo en un bien proporcionado por los servicios públicos. Podemos simplificar todo este flujo simplemente adoptando servicios públicos para cualquier trabajo nuevo. No necesitamos pensar en la inversión robótica o incluso en la conversión al uso de racks estándar (en sí mismo un coste que podría ser prohibitivo). Esta parte completa de la cadena de valor debería desaparecer con el tiempo junto con los costes adicionales que podría estar ocultando (ver figura 92).

Figura 92— Costes ocultos y eliminación de partes de la cadena de valor

En esta historia, partimos de una propuesta de inversión en robótica basada en mejorar la eficiencia de un proceso existente. Parecía razonable de primeras, pero si hubieran tomado esa ruta, habrían invertido más en mantener un proceso altamente ineficaz. Con toda probabilidad, habría exacerbado el problema más tarde porque el corpus corporativo se habría expandido para incluir esta inversión robótica. Si alguna persona del futuro hubiera dicho «deberíamos deshacernos de estos racks personalizados», la respuesta sería «pero siempre hemos hecho esto y hemos invertido millones en robótica» .

Utilicé el flujo de proceso «detectado» para que nos hiciéramos parte del camino, es decir, identificar el bastidor personalizado como el problema. Sin embargo, para comprender realmente este espacio, necesitábamos un mapa y los flujos dentro de él. Lo más «eficiente» que se podía hacer era invertir en robótica, pero lo «eficaz» era deshacerse de toda esta parte de la cadena de valor. Es un poco como la pregunta de la plataforma de servicios públicos. Puedo invertir en hacer que mi infraestructura y los componentes de la plataforma sean más eficientes mediante la automatización o simplemente puedo planificar deshacerme de toda esa parte de la cadena de valor mediante el uso de una plataforma de servicios públicos. A menudo, lo «eficiente» que se puede hacer no es lo «eficaz».

Sin embargo, una palabra para los sabios. Esto fue en 2008 y la idea de deshacerse de los racks hechos a medida y adoptar un movimiento hacia el uso de la infraestructura de un proveedor de servicios públicos no fue bienvenida. En 2016 es fácil decir «esto es obvio», pero eso se debe a que la mayoría de las personas ahora tienen el beneficio de la retrospectiva. En 2008, estas ideas se consideraron radicales e incluso peligrosas. Los cambios necesarios estuvieron lejos de ser bienvenidos dentro de la organización y se luchó en cada paso del camino desde los ejecutivos hasta la planta baja. Sin el coraje y la convicción del director ejecutivo y algunos «rebeldes», la empresa habría gastado felizmente millones en robótica y todavía estaría construyendo racks personalizados en la actualidad.

Por experiencia, debe tener cuidado tanto con el uso de la simplificación al ver un contexto como con la inercia que existe. Debe tener mucho cuidado con las mejoras de procesos centradas únicamente en la eficiencia. Debe tener mucho cuidado al tratar con el corpus corporativo.

La empresa en cuestión era una empresa de fabricación, el escenario real no tenía nada que ver con la informática y sí, estaban a punto de gastar muchos millones en hacer más eficiente un proceso altamente ineficaz. No lo hicieron, están vivos y bien. También mantuve a raya a los lobos. Eso es lo que yo llamo un win-win («ganar-ganar») excepto, obviamente, para los proveedores que perdieron.

Antes de seguir adelante

En los últimos capítulos, nos hemos escabullido por el ciclo de la estrategia cubriendo principalmente el propósito y luego el contexto. Debería estar lo suficientemente familiarizado con el ciclo de la estrategia como para que no necesite repetirlo. Seguiremos dando vueltas alrededor de esto, sumergiéndonos en las interconexiones a medida que avanzamos. De todos modos, esta será la última vez que mencionaré eso. Debemos recapitular algunas de las ideas de este capítulo.

Contexto

• Cuidado con la sencillez. Aquí hay un acto de equilibrio causado por la ley de Ashby. Tenga en cuenta que a menudo está intercambiando su capacidad de aprender por una gestión más sencilla. En algunos casos, puede simplificar tanto que se vuelva perjudicial, por ejemplo, un tamaño para todos y KPI para todo el grupo. A menudo, la gente habla sobre el principio KISS (mantenlo simple, estúpido: keep it simple, stupid) solo recuerda que si lo mantienes demasiado simple, puedes tomar algunas decisiones bastante tontas.
• El mapa contiene flujos de capital que están representados por las interfaces. Suele haber varios flujos en un solo mapa. Dicho capital puede ser físico, financiero, de información, de conocimiento, de riesgo, de tiempo o social. Podría ser cualquier cosa que intercambiemos y se intercambie entre los componentes.
• Los mapas son un medio para contar historias . A pesar de mi actitud severa hacia la narración (especialmente el tipo de verborrea que se encuentra a menudo en la estrategia), los mapas son una forma de narración visual.

Doctrina

• Concéntrese en el resultado, no en el contrato. Las herramientas basadas en el valor (resultado) pueden ser útiles aquí, pero tenga en cuenta que también pueden exponer fallas en la comprensión del valor y verse obstaculizadas por el corpus corporativo, por ejemplo, un proceso de presupuestación y su incapacidad para hacer frente a la carga variable.
• Utilice las herramientas adecuadas . Cuando utilizo mapas, si busco flujos financieros, a menudo me sumerjo en modelos financieros cuando considero múltiples rutas de inversión, por ejemplo, me enfoco en aumentar los visitantes a través del marketing o la tasa de conversión de un micrositio. Del mismo modo, si he identificado varios «lugares» que puedo atacar, a menudo me sumerjo en el lienzo del modelo de negocio para compararlos. No tenga miedo de utilizar varias herramientas. Los mapas son simplemente una guía y una herramienta de aprendizaje.
• Optimice el flujo . A menudo, cuando examina los flujos, encontrará cuellos de botella, ineficiencias y flujos sin beneficio. Habrá cosas que está haciendo que simplemente no necesita.
• Tenga mucho cuidado de considerar no solo la eficiencia sino también la efectividad . Trate de evitar invertir para hacer que un proceso ineficaz sea más eficiente cuando necesite cuestionarse por qué está haciendo algo y descubrir costes ocultos. Además, no asuma que un cambio «obvio» será bienvenido. Cuidado con el corpus corporativo.
• Cuando se trata de administrar el flujo, la granularidad es su amiga. Sin embargo, esté preparado, la mayoría de las empresas no tienen ni cerca del nivel de granularidad que necesitará y es posible que incluso se encuentre con la política al intentar averiguarlo. Piense en pequeño, conozca los detalles.
• Cualquier mapa puede contener varios usuarios diferentes y, a menudo, las necesidades de esos usuarios pueden estar en conflicto, aunque debe intentar reunirlos a todos.

Hemos cubierto bastante doctrina hasta ahora, lo he resaltado (en naranja) en la figura 93. Aunque hemos pasado por alto varias otras áreas de doctrina, quiero volver a ellas más adelante en el libro con un examen más formal.

Figura 93 – Doctrina

También hemos mencionado un aspecto del juego: el comercio . Los mapas son una forma de capital de conocimiento y tienden a tener valor. No espere que la gente simplemente los comparta con usted. Deberá comerciar o crear el suyo propio.

En la siguiente sección nos centraremos en el clima, incluidos los patrones económicos comunes y la anticipación.

Un ejercicio para el lector

Me gustaría que se tomara un tiempo y mirara la figura 93: doctrina. Repase cada una de las secciones marcadas en naranja, vuelva a leer los capítulos de este libro que necesite y asegúrese de estar familiarizado con ellos. Entonces pregúntese, ¿su empresa tiene estas formas de doctrina? ¿Cómo los implementa? ¿Si no, porque no? que te esta deteniendo?