He creado mi primer mapa y he aplicado algunos patrones climáticos básicos que me han permitido comprender cómo podrían influir en él. Estos patrones eran las cosas que no podía detener pero que podía anticipar. Me podía gustar o no, pero los componentes de mi mapa evolucionarán a través de las acciones del mercado. Sin embargo, aunque no tenía elección sobre el mercado, eso no significaba que no tenía elección sobre mis acciones. Podría influir en el contexto a través de la acción, podría decidir cómo me organizaría, los principios que enfatizaría dentro de la empresa y nuestra forma de operar.
Algunas de mis elecciones pueden ser específicas del contexto, es decir, una decisión de flanquear a un oponente requiere que este se encuentre en una posición conocida. Esto no significa que todo sea específico del contexto. Podría existir en los negocios principios generalmente útiles que todos deberían aplicar. Estos principios son doctrina y en este capítulo vamos a examinar esa parte de mi viaje (ver figura 29).
Figura 29. Doctrina
Que es la doctrina
La doctrina son los principios universales básicos que son aplicables a todas las industrias, independientemente de su situación y su contexto. Esto no significa que la doctrina sea correcta, sino que parece ser constantemente útil por el momento. Siempre existirá una mejor doctrina en el futuro. Al igual que con los patrones climáticos, revisaremos algunas formas básicas de doctrinas y las refinaremos en futuros pasos a través del ciclo de la estrategia.
Doctrina: foco en las necesidades del usuario
Cualquier valor que creamos es a través de satisfacer las necesidades de los demás. Incluso nuestra capacidad de comprender nuestro entorno mediante la creación de un mapa requiere que primero definamos las necesidades del usuario, ya que es el ancla para todo el mapa. Mira la figura 30. el mantra de «no chupar tanto como los competidores», aunque rara vez se dice explícitamente, es sorprendentemente común. Un mantra alternativo es «debemos ser lo mejor que podamos», pero para hacerlo debemos entender qué es lo que debemos ser. A pesar de esto, la respuesta habitual que recibo cuando le pido a una empresa o un proyecto específico que explique sus necesidades de usuario es una mirada en blanco. He visto muchos proyectos grandes que superan los $ 100 millones de dolares con documentos de especificaciones interminables en los que la escala de gastos y papeleo solo se corresponde con la incapacidad del grupo para explicar lo que el usuario realmente necesita.
Figura 30. Foco en las necesidades del usuario
Debería ser obvio que no satisfacer las necesidades de sus usuarios, especialmente cuando los competidores logran hacerlo, es una mala idea. Hay una premisa muy común y es suponer que sus competidores intentarán lograrlo. Si está operando en un mercado donde todos ignoran las necesidades de los usuarios o, mejor aún, les dicen a los usuarios lo que quieren (independientemente de las necesidades), entonces nadie obtendrá ventaja.
Pero, ¿cómo resolvemos esas necesidades de los usuarios? Esto es extremadamente complicado porque traemos nuestros propios prejuicios a la mesa. Lo primero que debe hacer es comprender de qué usuarios estamos hablando: sus clientes, los reguladores de su industria, sus accionistas, sus empleados o incluso su propio negocio. Si habla de clientes, debe centrarse en sus necesidades, no en las necesidades de su negocio. Es decir, puede que necesite generar ingresos y ganancias, pero NO es la necesidad de sus clientes. Al satisfacer las necesidades de sus clientes, debe tratar de satisfacer las necesidades de su negocio para generar ingresos y ganancias, y no al revés.
¡Pero seguramente debería centrarme en mi negocio primero! Este es un tema conocido como flujo que cubriremos más adelante. Cuando observa un mapa, cada componente representa una reserva de capital (ya sea física, financiera o de otro tipo). Las líneas entre componentes representan flujos de capital de un componente a otro. Si piensa en un negocio, entonces quiere un flujo de capital (en este caso, ingresos) de los clientes a usted mismo. Para hacer esto, tendrá que satisfacer sus necesidades porque es poco probable que le den dinero por nada. A menos que esté operando en un mercado extraño donde todos ignoran al cliente o usted le dice lo que quiere.
Debido a este flujo, la mejor manera que he encontrado para determinar las necesidades de los usuarios es comenzar por observar las transacciones que una organización realiza con ellos. Esto tenderá a darle una idea de lo que proporciona y lo que es importante. El siguiente paso es examinar el recorrido del cliente cuando interactúa con esas transacciones. Al cuestionar este viaje y hablar con los clientes, a menudo encontrará pasos inútiles o necesidades no satisfechas o necesidades innecesarias que se atienden. Otro mecanismo que también he encontrado que es excepcionalmente útil, especialmente cuando sus usuarios son de hecho otras corporaciones, es ir y trazar su panorama. En la mayoría de los casos, encuentro que estos usuarios tienen una mala idea de lo que realmente necesitan. Si usted es proveedor de una empresa de este tipo, las conversaciones tienden a degenerar en las cosas que quieren y las que creen que son necesarias en lugar de las que necesitan. Al mapear su contexto, a menudo puede aclarar lo que realmente se necesita y a la vez, encontrar nuevas oportunidades para los negocios.
La conversación y la recopilación de datos son una parte clave para determinar las necesidades de los usuarios, por lo tanto, hable con ellos y hable con expertos del sector. Sin embargo, hay una trampa. ¡En muchos casos resultan ser ambos incorrectos! ¿está sorprendido? ¿Qué quieres decir con que están ambos equivocados? Hay dos áreas importantes donde los usuarios y los expertos generalmente se equivocan al describir sus propias necesidades. Aunque parezca mentira, ambos son cruciales para el juego estratégico.
El primer área es cuando un componente se mueve entre etapas de evolución, por ejemplo cuando algo cambia de un desarrollo a medida hacia un producto o, lo que es más importante, de un producto hacia un servicio básico (+ utilidad). El problema es que la base instalada preexistente causa inercia al cambio. Invariablemente, los usuarios estarán obsesionados con el mundo que han heredado y, por lo tanto, tendrán un sesgo hacia él. Esto es equivalente a que un usuario le diga a Henry Ford: «no queremos un automóvil; ¡Queremos un caballo más rápido! El sesgo es causado por un patrón climático conocido como coevolución, pero por el momento simplemente debe desconfiar de la mentalidad heredada.
El segundo área a tener en cuenta es la del dominio inexplorado. Estas necesidades son raras y altamente inciertas; y esto significa que tendrá que apostar. No hay una manera consistente de determinar qué necesita realmente el usuario con algo nuevo porque no se conoce a sí mismo. Por lo tanto, prepárate para pivotar. Puede pensar que está construyendo una máquina que detendrá todas las guerras (el concepto original de Wright Brothers para el avión) pero hubo otros que encontraron usos alternativos: el avión de combate o el bombardero.
Cuando se trata de lidiar con las necesidades, existen tres enfoques diferentes según los dominios de inexplorado, transitorio e industrializado. En el dominio inexplorado tienes que apostar: Los usuarios y expertos en realidad no saben lo que se necesita más allá del vago movimiento de la mano. En el dominio de transición tienes que escuchar: Los usuarios y expertos pueden guiarlo a lo que necesitan. En los primeros días del dominio industrializado, debe tener en cuenta el sesgo de los usuarios y expertos causado por la inercia del éxito pasado. Ya sabe lo que se necesita, pero debe proporcionarse en forma de operaciones de volumen y de forma suficientemente buena.
Doctrina: Usa un lenguaje común
En lugar de utilizar múltiples formas diferentes de explicar lo mismo entre las diferentes funciones de la empresa, intente usar, por ejemplo, un mapa. Si usa diagramas de procesos de negocio por un lado y diagramas de sistemas de TI en el otro, terminará con errores de traducción, desalineación y confusión. La colaboración es importante, pero es muy difícil de lograr si un grupo habla klingon y el otro élfico y admitámoslo, Finance es Klingon para TI y generalmente es élfico para finanzas. Es por eso que las empresas a menudo valoran a las personas capacitadas en múltiples áreas que actúan como traductores. Pero un soldado no necesita saber cómo operar un bote para trabajar con alguien de la Marina, ni un marinero necesita saber cómo operar un mortero para trabajar con el Ejército. Usan mapas para colaborar y coordinar. El problema en los negocios es la falta de un lenguaje común, es decir, la falta de cualquier forma de mapeo. Si no puede mapear lo que está haciendo, le recomiendo que no actúe y que pase unas horas mapeándolo.
Doctrina: Sé transparente
Compartir un mapa permitirá a otros desafiar y cuestionar sus premisas. Esto es esencial porque nos ayuda a aprender y refinar nuestros mapas. La desventaja de compartir es que permite que otros desafíen y cuestionen sus suposiciones. Muchas personas encuentran esto incómodo. Como CEO de la compañía, ¿realmente quería que uno de mis juniors destrozara mi estrategia usando el mapa que había creado? Si. Prefiero que alguien me señale que nuestra estrategia consistía en llevar a un ejército a través de un campo minado antes de permitirme descubrirlo por mí mismo. Sin embargo, no subestimes lo difícil que es esta transparencia dentro de una organización.
Doctrina: Desafía las suposiciones
No tiene mucho sentido concentrarse en las necesidades del usuario, crear un lenguaje común mediante el uso de un mapa y compartirlo de manera transparente en la organización si nadie está dispuesto a desafiarlo. Este acto debería ser un deber para todos en la empresa. No me importaba si era mi proyecto favorito, necesitaba que la gente me dijera abierta y honestamente dónde creían que me estaba equivocando. Esto requiere no solo transparencia sino también confianza. Cualquier forma de retribución o parcialidad contra alguien por desafiar es un pecado mortal que perjudicará a su empresa. Como CEO, convertí a mi CFO en «XO» en 2004. Una de sus tareas era desafiar mis elecciones y alentar este tipo de preguntas.
Doctrina: eliminar las duplicidades y los sesgos
No solo debe compartir mapas, sino también cotejarlos en un esfuerzo por eliminar la duplicidad y el sesgo, es decir, reconstruir lo mismo o construir a medida lo que ya es un servicio básico. El mapeo es en sí mismo un proceso iterativo y probablemente ha estado tomando decisiones durante mucho tiempo sin comprender el contexto. Por lo tanto, no necesita mapear todo el entorno para comenzar a tomar decisiones, sino pensar en los mapas como una guía que nos brinda más información cuanto más la usamos.
Con su primer mapa, probablemente pueda cuestionar si hemos satisfecho adecuadamente las necesidades de los usuarios o tal vez cómo estamos tratando los componentes. A medida que recopila más mapas de diferentes sistemas o líneas de negocio, comienza a descubrir que el mismo componente está en varios mapas. He marcado algunos ejemplos en la figura 31 en verde.
Figura 31. Duplicidad
Ahora, el mismo componente que está en mapas diferentes está bien, excepto cuando decimos que es una instancia diferente de ese componente. Por ejemplo, si tiene diez mapas, todos con base de datos o centro de atención telefónica o centro de impresión como componente, eso no es necesariamente un problema, pero podría serlo si realmente está diciendo que tenemos 10x bases de datos diferentes ejecutándose en 10x sistemas diferentes. Puede haber razones legítimas para la duplicación, como la localización, pero aun así, desearía que hubiera 10 veces más instalaciones de impresión bastante estandarizadas y no 10 veces más personalizadas.
En organizaciones grandes como petroquímicas o compañías bancarias con comités de arquitectos, normalmente no se ven duplicaciones en una escala de diez veces. En cambio, por experiencia, lo que comúnmente encuentro en una sola organización global construida por adquisición con una federación de unidades de negocios es más de cien veces mayor. No hay nada como descubrir equipos aislados de 380x que construyen sistemas ERP 380x personalizados para satisfacer las mismas necesidades de los usuarios con 380x sistemas diferentes (una compañía química). El peor de los casos que he visto es una compañía de energía que tiene una duplicación de más de 740x. Dicho esto, ahora conozco un banco que incluso podría haber superado esto con más de 1,000 sistemas de gestión de riesgos. En estos días, estoy muy contento de encontrarme con una gran organización global que tiene duplicaciones a escala de decenas o incluso unidades. Por supuesto, tenga en cuenta que la mayoría de las empresas podrían afirmar esto, pero en la práctica no tienen idea de cuáles son realmente sus niveles de duplicación y subestiman significativamente el problema.
Una técnica que encuentro útil para ayudar a resaltar este problema es crear un diagrama de perfil. Simplemente comparto mapas, identificando componentes comúnmente descritos y luego los coloco en el perfil. Esto me da una idea de la duplicación y el sesgo. Del diagrama de perfil a continuación en la figura 32, se observan los siguientes puntos:
Figura 32. Diagrama de perfil
Punto 1: para cada componente común, registra cuántas veces se repite. El alto número de repeticiones no es necesariamente un problema, ya que puede haber una razón legítima o podría ser el mismo componente en diferentes mapas. En este caso, nuestros mapas muestran siete referencias a sitios web.
Punto 2: registrar la evolución de un componente puede proporcionarle una idea del sesgo dentro de la organización. En la figura 32, hay seis ejemplos de registro de usuarios en los mapas. Uno de los cuales está distanciado de los demás. Esto podría deberse a que un grupo simplemente pensó en su mapa que el registro de usuarios era una actividad única (no lo es) o, alternativamente, podría tener cinco grupos que utilizan un servicio común y un grupo personalizado que crea la suya propia. En este caso, pueden tener una razón legítima, pero merece la pena el desafío.
Punto 3: la recopilación de mapas a menudo ayuda a crear un léxico común. Lo mismo a menudo se describe con diferentes términos en una sola organización.
Punto 4: hay siete referencias al correo electrónico dentro de los mapas. Con suerte (aunque lamentablemente no siempre es el caso), esto se refiere a un sistema de correo electrónico utilizado en diferentes lugares. También hay un sesgo con la mayoría de los grupos que consideran que el correo electrónico es más básico, pero un grupo piensa que es un producto en evolución. Esto probablemente debería hacer sonar las alarmas.
Punto 5: hay cinco referencias a centros de datos. De nuevo con suerte, esto se refiere a un cluster construido por razones geográficas específicas. Por desgracia, un deporte popular en muchas grandes empresas es construir centros de datos como si fueran los primeros en construirse en la propia organización. En los peores casos que me encontré, me contaron como habían construido un centro de datos creado con mucho cariño para luego ir al taller y encontrarme un estante triste y solitario en medio de una gran sala vacía. El estante contiene invariablemente servidores con nombres cariñosos como Seven, Janeway, Paris, Chakotay (todos los personajes de la serie Voyager de Star Trek).
Los mapas y el diagrama de perfil son simplemente guías para ayudarlo a eliminar la duplicación y el sesgo. Esta es una necesidad para operaciones eficientes. Sin embargo, la duplicación no debe considerarse únicamente como un coste financiero porque afecta nuestra capacidad para desarrollar capacidades más complejas. En el caso del banco con 1,000 sistemas de gestión de riesgos, uno de los problemas al que se enfrentan es su incapacidad para liberar cualquier cosa.
Otra técnica que encuentro útil en una estructura dispersa es determinar qué capacidades necesitamos como grupo. Por ejemplo, en la figura 33, se proporciona un mapa que resalta explícitamente tanto el viaje del cliente como las capacidades asociadas. He derivado este mapa de un ejemplo del mundo real utilizado por el Methods Group. En este mapa, el recorrido del cliente (descrito como patrones de servicio) se destaca más claramente y nos estamos enfocando no solo en la tecnología requerida para satisfacer las necesidades de los sistemas de pedidos superiores, sino también en los sistemas de pedidos superiores, por ejemplo, gestionar una llamada, determinar el patrocinio. Por razones de confidencialidad, he cambiado y eliminado muchos de los términos.
Figura 33. Mapa con viaje del cliente
Al agrupar muchos de estos mapas, puede desarrollar una imagen de lo que la empresa realmente hace y cuáles son sus capacidades existentes a través de un perfil de capacidades; consulte la figura 34.
Figura 34. Perfil de capacidades
Puede encontrar que las capacidades comunes a menudo se asumen como personalizadas (por ejemplo, ofrecen una selección de inversiones) cuando en realidad deberían estar mucho más definidas. También puede encontrar que tiene una gran cantidad de tecnología duplicada y personalizada que proporciona una capacidad única que debe racionalizarse. Nunca deja de sorprenderme cómo un negocio sencillo con capacidades limitadas se vuelve increíblemente complejo y lento por una mezcla heterogénea de soluciones personalizadas duplicadas debajo.
Doctrina: usa métodos apropiados
Uno de los patrones climáticos que examinamos en la figura 22 (del capítulo 3) fue cómo no existe un método de talla única para todos. Suponiendo que está eliminando el sesgo en sus mapas, ya sea desafiando directamente o con la ayuda de un diagrama de perfil construido a partir de múltiples mapas, la siguiente pregunta es ¿qué métodos son adecuados? El error más común que encuentro es con la contratación externa. El problema con el outsourcing no es que el concepto sea incorrecto, sino que tenemos una tendencia a externalizar sistemas completos para los que no entendemos el contexto. Esto a menudo se hace con la esperanza de que alguien diferente lo cuide de manera más efectiva.
Imaginemos un sistema con múltiples componentes distribuidos en el eje de evolución pero no tenemos un mapa. Ahora apliquemos un único proceso altamente estructurado al sistema, a menudo a través de un contrato que detalla lo que se debe entregar. Desafortunadamente, sin que lo sepamos, algunos de esos componentes estarán en el dominio inexplorado y, por lo tanto, son inciertos por naturaleza. Cambiarán y, por lo tanto, incurriremos en algún tipo de coste de control de cambios. Estos costes pueden ser significativos en cualquier sistema complejo que contenga muchos componentes desconocidos. Como resultado, los problemas terminan apareciendo entre el comprador y el proveedor. Desafortunadamente, el proveedor tiene la ventaja porque puede señalar el contrato y mostrar que los componentes que no cambiaron fueron entregados de manera eficiente y el coste está asociado con los componentes que cambiaron. La típica frase de «si lo hubiera especificado correctamente desde el principio» a «segue cambiando de opinión» desaparecen y el comprador normalmente siente algún tipo de culpa. ¡Fue su culpa y si tan solo lo hubieran especificado mejor! Esto es una mentira y una trampa.
El problema no era que un proceso altamente estructurado con especificación detallada se aplicara correctamente a los componentes industrializados, sino que la misma técnica también se aplicaba incorrectamente a los componentes que por su propia naturaleza eran inciertos y cambiantes. El comprador nunca podría especificar esos componentes cambiantes con ningún grado de certeza. Los costes excesivos de control de cambios causados por un proceso estructurado aplicado a los componentes cambiantes son inevitables. El error es que el proveedor que debe tener la experiencia para saber que una talla para todos no puede funcionar. Desafortunadamente, y no hay una manera cortés de decir esto, es una estafa lucrativa.
Aún mejor, si la estafa funciona, especialmente si el proveedor renuncia a algún coste como un gesto de buena voluntad, entonces la próxima vez el comprador intentará especificar el próximo sistema con más detalle. Para ello, a menudo pagarán al proveedor o una consultora externa para ayudarlos a hacer esto. Desafortunadamente, una vez más contendrá componentes inexplorados que cambiarán y, por lo tanto, se incurrirá en costes. La única forma de evitar esto es dividir el sistema en componentes y tratarlos con los métodos apropiados, como por ejemplo se ilustra en la figura 35.
Figura 35. Usa los métodos apropiados
En el ejemplo anterior de 2005, la energía debe subcontratarse a un proveedor de servicios básicos, mientras que el CRM, la plataforma, el centro de datos y las computadoras deben usar productos listos para ser usados o soluciones de alquiler (por ejemplo, alojamiento) con un cambio mínimo siempre que sea posible. Idealmente, los componentes de almacenamiento de fotos en línea y manipulación de imágenes que van a cambiar rápidamente deberían construirse internamente con nuestros propios ingenieros y utilizando un enfoque ágil. Si bien podríamos usar contratos más detallados y específicos para elementos como el centro de datos (hosting), también somos conscientes de que no podemos especificar completamente la manipulación de imágenes en este momento. Si en 2005 hubiéramos subcontratado todo el sistema de la figura anterior a un enfoque único altamente estructurado usando una especificación detallada, entonces casi seguro que habríamos terminado con costes de cambio excesivos en torno a la manipulación de imágenes y al almacenamiento de fotos.
El problema de la subcontratación inadecuada es tan abundante que merece la pena hacer un ejemplo simple para reforzar este punto. En la figura 36, proporciono un diagrama de cajitas (comúnmente utilizado en los sistemas de TI) para un automóvil sin conductor. Sin embargo, he traducido la descripción de los componentes a élfico porque, como ya he dicho, la mayoría de TI es élfico para las personas en los negocios. Me gustaría que miraras el diagrama y contestaras las preguntas etiquetadas como 1 y 2.
Figura 36. Coche autónomo en élfico (diagrama de componentes)
Ahora, en la figura 37, se muestra exactamente el mismo diagrama en un formato de mapeo. Todavía está en élfico. Vea si puede responder las preguntas 1 y 2.
Figura 37 – Automóvil autónomo en élfico(mapa)
Debería poder decir algo razonable sobre cómo trata las preguntas 1 y 2. Si tiene dificultades, mire la figura 22 (capítulo 3).
Como referencia, la pregunta 1 probablemente debería construirse internamente con nuestros propios ingenieros de manera ágil, mientras que la pregunta 2 debería subcontratarse con un proceso estructurado y bien definido o consumir algún tipo de servicio básico o producto. En la figura 38, muestro el mismo diagrama sin el élfico para que pueda verificar su pensamiento.
Figura 38. Coche autónomo (mapa)
Lo que te permite hacer esta hazaña de sensibilidad élfica es el eje de movimiento de la evolución. Desafortunadamente, en la mayoría de las iniciativas de subcontratación (outsourcing) que he visto, los diagramas de cajitas o mapas de procesos de negocios (ver figura 39) tienden a ser predominantes. Por desgracia, estos carecen de todo ese movimiento importante característico. Los diagramas de cajitas y procesos de negocio no son en realidad mapas; éstos confían únicamente en la información contextual de las palabras (por ejemplo, se sabe que un proceso de pago es un producto o servicio básico maduro). Los diagramas en sí mismos no le proporcionarán una guía sobre lo que debe o no debe subcontratar.
Figura 39. Diagrama de un proceso de negocio
Antes de ir y pedirle a su consultora de confianza que haga un mapa para usted, recuerde que sus intereses no son necesariamente los suyos. De la misma manera, es importante desafiar cualquier sesgo que su empresa pueda tener en sus mapas. Un equipo que construye su propio suministro de electricidad propio puede argumentar que la electricidad no es un producto básico, sino que necesitamos construir nuestro propio suministro a medida. Junto con el sentido común, la chuleta de la figura 17 (capítulo 2) y los diagramas de perfil construidos a partir de mapas agregados (figura 32) deberían aportarle una gran evidencia para desafiar esto.
Llegados a este punto, en muchos casos me dices: «eso es obvio, no haríamos eso», sin embargo, pregúntese cuántos sistemas de gestión de contenido empresarial (ECM) tiene en su organización. Si eresuna empresa típica global creada por adquisiciones, la experiencia me dice que probablemente digas 5–8x. En la práctica, es más probable que sean versiones personalizadas de 40–250x con probablemente 3–5x grupos separados construyendo un ECM global sin ser conscientes de que existen los otros grupos. El problema es que la mayoría de ustedes no sabrá cuánta duplicación o sesgo tienen. Por supuesto, hay una amplia gama de excusas que se implementan para no dividir sistemas complejos en componentes y luego aplicar métodos más apropiados. Mis favoritos incluyen: –
«Necesitamos mejores expertos y mejores especificaciones», esto es lo que se llama no afrontar el problema. Es como decir que nuestro proyecto de la estrella de la muerte para limpiar el desastre de los proyectos fallidos de la estrella de la muerte ha fallado; ¡Necesitamos una nueva estrella de la muerte! Hay una cita famosa sobre repetir lo mismo y esperar resultados diferentes que es relevante aquí.
«Es demasiado complejo, dividirlo en partes lo hará inmanejable», el antiguo esfuerzo de pretender que un sistema que contiene 100 partes móviles diferentes no contiene 100 partes móviles diferentes. No construimos autos fingiendo que son una cosa; de hecho, a menudo tenemos cadenas de suministro complejas que satisfacen las diferentes necesidades de diferentes componentes con medidas apropiadas y contratos implementados en función del componente. Sí, hace un poco más de trabajo entender lo que se está construyendo, pero si gastas sumas significativas, generalmente es una buena idea saber esto.
«Causará caos» – indica la vieja línea de «disturbios en la calle». Dada la situación, la industria automotriz y muchas otras no tienen problemas con la «componentización», entonces no puedo ver cómo alguien salta mentalmente a esta noción de caos. La verdad suele ser más un deseo de tener «un hombro donde llorar y desahogarse», aunque no hay nada que impida a una empresa utilizar un proveedor para construir todos los componentes con los métodos adecuados.
«Terminarás con cientos de startups experimentales», en este punto nos estamos metiendo en lo surrealista. Si divide un sistema complejo en componentes, algunos de los componentes no graficados serán experimentales. Esto no es algo malo, esto es exactamente lo que son. Para esos componentes, es probable que haga esto internamente con técnicas ágiles o utilice una empresa especializada centrada en procesos más ágiles. Pero no le dará a esa compañía todos los componentes porque la mayoría de los componentes tienden a estar altamente industrializados y, por lo tanto, utilizará proveedores de servicios establecidos como Amazon para la infraestructura informática. No estoy seguro de cómo la gente da el salto mental de la «componentización» a dar todo a «cientos de startups experimentales». En general, esto tiende a ser causado por un deseo de mantener el statu quo actual.
«Complejidad en la gestión de interfaces»: esta es mi excusa favorita que lleva el surrealismo a un nivel completamente nuevo. Pretender que un sistema complejo de 100 componentes con componentes inexplorados e industrializados que tienen interfaces entre ellos es, de hecho, un sistema con un método único para todos y las interfaces inexistentes es la definición misma de fantasía. Esos componentes están ahí, esas interfaces están ahí: la complejidad no desaparece simplemente mediante la «subcontratación». Todo lo que has hecho es intentar fingir que lo complejo que estás construyendo es de alguna manera simple porque entonces es más fácil de administrar. Sería como si BMW o Apple subcontrataran todas sus líneas de productos a otra persona y trataran de no involucrarse porque simplifica la administración.
Doctrina: piensa en pequeño
Para aplicar los métodos apropiados, debe pensar en pequeño. No puede tratar todo el sistema como una sola cosa, sino que necesita dividirlo en componentes. A menudo esto le llevará al uso de pequeños contratos localizados alrededor de componentes específicos. Conocer los detalles te ayuda a gestionar un contexto. Pero puede llevar esto más allá e incluso usar equipos pequeños como estructuras basadas en células. Probablemente, los enfoques más conocidos para usar equipos pequeños son el modelo de las «2 pizzas» de Amazon y la estructura basada en celdas de Haier.
Dichos equipos deben tener autonomía en su espacio y esto puede lograrse proporcionando al equipo de unos interfaces bien definidos para que otros consuman, de acuerdo a unos límites definidos que a menudo están descritos a través de alguna forma de función de condición física. Por ejemplo, el equipo tiene un objetivo en torno a un área específica con métricas definidas de entrega. Los mapas en sí mismos pueden ser útiles para ayudarlo a identificar no solo los equipos que debe construir, sino también las interfaces que deben crear; consulte la figura 40.
Figura 40. Piensa en pequeño (como en equipos)
Doctrina: Piensa en aptitud y actitud
Ahora supongamos que te embarcas en una estructura basada en células y estás pensando en pequeño. Entonces cada celda requerirá habilidades diferentes, es decir, aptitudes. Sin embargo, hay otro factor en juego aquí: la actitud. Cuando miramos un mapa, sabemos que las actividades evolucionan del dominio inexplorado al industrializado y los métodos y técnicas que necesitamos son diferentes. La génesis de algo requiere experimentación y si bien es posible que necesite la aptitud de ingeniería, necesita una forma específica, es decir, ingeniería agile. Por el contrario, el tipo de ingeniería que necesita para construir un acto altamente industrializado requiere un enfoque en las operaciones de volumen y la eliminación de desviaciones como Six Sigma. Por lo tanto, tenemos una aptitud de ingeniería que requiere diferentes actitudes. No importa qué aptitud examinemos: finanzas, ingeniería, telecomunicaciones o marketing: la actitud también es importante. No existe tal cosa como TI, finanzas o marketing, sino múltiples.
Para resolver este problema, debe llenar las celdas con diferentes tipos de tipos de personas: pioneros , colonos y urbanistas . No es realista pensar que todos tienen la misma actitud, algunos son mucho más capaces de vivir en un mundo de caos, experimentación y fracaso, mientras que otros son mucho más capaces de lidiar con el modelado intensivo, los rigores de las operaciones de volumen y la medición. Necesita personas brillantes con las aptitudes adecuadas (por ejemplo, ingeniería, finanzas) y diferentes actitudes (por ejemplo, pioneros, colonos).
Los pioneros son personas brillantes. Son capaces de explorar los conceptos nunca antes descubiertos, la tierra inexplorada. Te muestran asombro pero fallan mucho. La mitad del tiempo la cosa no funciona correctamente. No confiarías en lo que construyen. Crean ideas ‘locas’. Su tipo de innovación es lo que describimos como investigación central. Hacen posible el éxito futuro. La mayoría de las veces los miramos y decimos «¿qué?», »¿No entiendo?» o «¿es eso magia?». Construyeron la primera fuente eléctrica (la batería Bagdad, 400 AD) y la primera computadora digital (Z3, en 1943). En el pasado, a menudo los quemamos en la hoguera o generalmente morían de malaria en algún pantano recién descubierto.
Los colonos son personas brillantes. Pueden convertir la cosa a medio cocer en algo útil para un público más amplio. Construyen confianza. Construyen entendimiento. Hacen realidad el posible futuro. Convierten el prototipo en un producto, hacen posible su fabricación, escuchan a los clientes y lo vuelven rentable. Su innovación es lo que tendemos a pensar como investigación aplicada y diferenciación. Construyeron los primeros productos informáticos (por ejemplo, IBM 650 y en adelante), los primeros generadores (Hippolyte Pixii a los generadores de Siemen). Drenan el pantano y crean alguna forma de asentamiento.
Los urbanistas son personas brillantes. Son capaces de tomar algo e industrializarlo aprovechando las economías de escala. Esto requiere una habilidad inmensa. Confías en lo que construyen. Encuentran formas de hacer las cosas más rápido, mejor, más pequeño, más eficiente, más económico y lo suficientemente bueno. Crean los componentes sobre los que se basan los pioneros. Su tipo de innovación es la investigación industrial. Toman algo que existe y lo convierten en un servicio básico o una utilidad (por ejemplo, con Electricidad, luego Edison, Tesla y Westinghouse). Son los gigantes industriales de los que dependemos. Ellos construyen Roma.
En 2005, sabíamos que la cultura existente no parecía funcionar y permitir que las personas adquirieran dominio en una de estas tres actitudes parecía hacer que las personas fueran más felices y estuvieran más centradas. Tomar una actitud y colocarlas en un campo que requiere otra actitud nunca es una buena idea. Pruébalo por ti mismo. Encuentre un ingeniero de software pionero en su empresa, alguien acostumbrado a un mundo de experimentación y desarrollo ágil y envíelos a un curso de ITIL de tres semanas. Después, observa lo miserable que vuelve. Pruebe lo mismo con un urbanista y envíelos en un curso de tres semanas de días de hackeo y experimentación con áreas completamente inciertas y muchos fallos. Después, observa como la sonrisa desaparece de su cara.
Al usar un mapa, no solo debe dividirse en componentes y construir celdas pequeñas alrededor de este, también debe considerar la actitud: consulte la figura 41.
Figura 41. Aptitud y Actitud
Es realmente importante entender que los pioneros construyen y operan la novela. Los pioneros son responsables de ser pioneros y eso lo es todo. Tienden a hacerlo consumiendo componentes construidos por colonos (por ejemplo, productos o bibliotecas de capacidades) y urbanistas (por ejemplo, servicios industrializados). Los urbanistas, por otro lado, construyen y operan los componentes industrializados a gran escala. No caigas en la trampa de que los Pioneros construyen cosas nuevas y se las entregan a otra persona para que las ejecute o las opere. Así no es como funciona esto.
Esta idea tripartita tampoco es nueva. Si indaga un poco, llegará al libro de Robert X. Cringely, Accidental Empires, 1993. Cringely describió cómo había tres tipos diferentes de compañías conocidas como infantería, comando y policía. La estructura de PCU (pionero, colono y urbanista) es un descendiente directo de esa idea, pero se aplicó a una sola empresa y se puso en práctica en 2005. Citando su libro, que recomiendo encarecidamente, lea:
“Ya sea si invaden países o mercados, la primera línea de tropas en ver la batalla son los comandos. El paracaídas del comando detrás de las líneas enemigas o se arrastra silenciosamente a tierra por la noche. La velocidad es por lo que viven los comandos. Trabajan duro, rápido y barato, aunque a menudo con un bajo nivel de profesionalidad, lo cual también está bien, porque la profesionalidad es costosa. Su trabajo es hacer mucho daño con sorpresa y trabajo en equipo, desembarcando en esa playa del territorio enemigo antes de que el enemigo se dé cuenta de que existe. Hacen de la creatividad un arte destructivo.
[Refiriéndose al negocio del software] Pero lo que construyen, si bien puede parecer un producto y funcionar como un producto, generalmente no es un producto porque todavía tiene errores y fallos importantes que están por debajo del aviso de los tipos de comando. O tal vez funciona bien, pero no se puede producir de manera rentable sin un amplio rediseño. Los comandos son inútiles para este tipo de trabajo. Se aburren.
Es fácil deshacerse de los comandos. Después de todo, la mayoría de los negocios y la guerra son parecidos en muchas cosas. Pero sin comandos nunca llegarías a la playa. Agrupados en alta mar, mientras los comandos hacen su trabajo tenemos la segunda ola de soldados, la infantería. Estas son las personas que llegan a la playa en masa y consolidad la victoria temprana, afianzando lo conquistado por los comandos. Las tropas de la segunda ola toman el prototipo, lo prueban, lo refinan, lo hacen fabricable, escriben los manuales, lo comercializan e idealmente producen ganancias. Debido a que hay muchos más de estos soldados y sus deberes son muy variados, requieren una infraestructura de reglas y procedimientos para hacer las cosas, todo lo que los comandos odian. Por esta misma razón, los soldados de la segunda ola, aunque pueden trabajar con la primera ola, generalmente no confían en ellos, aunque los comandos ni siquiera se dan cuenta de este hecho, ya que en este momento están aburridos y ya están buscando la puerta de salida. Si bien los comandos hacen posible el éxito, es la infantería la que hace que el éxito suceda.
Lo que sucede entonces es que los comandos y la infantería avanzan hacia nuevos territorios, realizando sus mismos trabajos nuevamente. Todavía existe la necesidad de una presencia militar en el territorio. Estas tropas de la tercera ola odian el cambio. No son tropas en realidad, sino policía. Quieren impulsar el crecimiento no planeando más invasiones y aterrizando en más playas, sino agregando personas y construyendo economías e imperios de escala ”.
Accidental empires, Robert X. Cringely
Doctrina: diseño para la evolución constante
Todo está evolucionando debido a la competencia. Los efectos de esto en los negocios se pueden ver en su continua reestructuración para hacer frente a nuevos paradigmas externos. Los recientes presidentes de empresas «en la nube» y las redes sociales no son diferentes de los ex-presidentes de electricidad y telefonía que empleaban la mayoría de las empresas antaño. El atornillado de hoy incluye a los directores digitales. Estas cosas nuevas son el legado de mañana y esto genera un problema. Podríamos introducir una estructura basada en celdas teniendo en cuenta no solo la aptitud sino también la actitud, ya que el mapa no es estático. Necesitamos imitar de alguna manera ese estado constante de evolución en el mundo exterior pero dentro de una empresa. La solución es introducir un mecanismo de «robo», lo que significa que los nuevos equipos deben formar y robar el trabajo de los equipos anteriores, es decir, los colonos roban a los pioneros y producen el trabajo. Esto obliga a los pioneros a seguir adelante. Igualmente, los urbanistas roban a los colonos e industrializan, forzando a los colonos a seguir adelante, pero también proporcionando un servicio de componentes para permitir a los pioneros. Esto da como resultado un ciclo que se muestra en la figura 42.
Figura 42. Diseño para evolución constante
Punto 1 : los urbanistas crean algún tipo de componente industrializado que anteriormente existía como producto. Esto se proporciona como un servicio de utilidad.
Punto 2 : los pioneros ahora pueden construir rápidamente sistemas de orden superior que consuman ese componente.
Punto 3 : a medida que evolucionan los nuevos sistemas de orden superior, los colonos identifican nuevos patrones dentro de ellos y crean un producto o algún tipo de componente de biblioteca para su reutilización.
Punto 4 : a medida que el producto o componente de la biblioteca evoluciona, los urbanistas completan el ciclo creando una forma industrializada (según el punto 1). Esto da como resultado la creación de una plataforma en constante expansión de componentes industrializados discretos sobre los cuales los pioneros pueden construir.
Los mapas son una forma útil de iniciar este proceso. También le dan un propósito a cada celda (o componente) ya que saben cómo su trabajo encaja en la imagen general. La estructura basada en células es un elemento esencial de la estructura y debe tener autonomía en su espacio, deben ser autoorganizados. Por lo tanto, las interfaces entre las células se utilizan para ayudar a definir las funciones de aptitud física, pero si una célula ve algo de lo que puede aprovechar tácticamente en su espacio (recuerde que tienen una visión general de todo el negocio a través del mapa), entonces deberían explotarlo. Las celdas están pobladas no solo con la aptitud correcta sino también con la actitud (pioneros, colonos y urbanistas). Esto permite a las personas desarrollar dominio en su área y les permite concentrarse en lo que son buenos. Debe dejar que las personas seleccionen su tipo y cambien a voluntad hasta que encuentren algo con lo que se sientan realmente cómodos. Recompénselos por ser realmente buenos en eso. Propósito, dominio y autonomía son los temas del libro Drive de Daniel H.Pink.
A medida que aparecen cosas nuevas en el mundo exterior, deben fluir a través de este sistema. Esta estructura no requiere un atornillado que debe reemplazar más adelante. No se requiere jefe digital, jefe de telefonía, jefe de electricidad, director de nube. Las celdas pueden crecer en tamaño, pero en última instancia, debe aspirar a subdividirse en celdas más pequeñas y los mapas pueden ayudar a lograr esto. Tenga en cuenta el problema de Hackman de que los canales de comunicación aumentan exponencialmente a medida que el equipo crece. Los Navy Seals de EE. UU. Aprendieron hace mucho tiempo que 4 «es el tamaño óptimo para un equipo de combate» .
Sin embargo, tendrá que estructurar cada vez más el monitoreo y la comunicación entre las celdas utilizando una jerarquía y sí, eso significa que necesita una jerarquía sobre una estructura basada en celdas. Descubrí que se puede aplicar una estructura ejecutiva que imita a la organización, es decir, un CEO, un pionero en jefe, un colono en jefe y un planificador en jefe de la ciudad. Sin embargo, probablemente usará nombres que suenan más tradicionales, como Director de Operaciones, Jefe I+D, etc. Lo hicimos. No estoy seguro de por qué lo hicimos y en estos días no me molestaría por saberlo; solo quería dejarlo claro. También necesitará estructuras de apoyo separadas para reforzar la cultura y proporcionar capacitación con algún tipo de grupo de recursos (para formar nuevas células).
Contrariamente a los conceptos populares de cultura, la estructura hace que florezcan tres culturas separadas. Esto es algo contrario al pensamiento general porque la cultura resulta de la estructura y no al revés. También significa que no tiene una cultura de empresa única, sino múltiples que necesita mantener. Describí los elementos básicos de esto en la figura 43.
Figura 43. Cultura
Por último, PST es una estructura que he usado con un efecto notable en un número muy pequeño de casos. Ese es el código para ‘podría ser una casualidad’. Sin embargo, en la última década no he visto nada que se acerque y en su lugar he visto una matriz interminable o sistemas duales que crean problemas. ¿Aparecerá algo mejor? Por supuesto que sí. Sin embargo, para invocar la ley de Conway, si no imita la evolución en sus mecanismos de comunicación (por ejemplo, a través de un mecanismo de robo), nunca podrá hacer frente a la evolución fuera de la organización.
Entonces, ¿qué tan común es una estructura PCU? Fuera de ciertos círculos es extremadamente raro. En el mejor de los casos, veo empresas incursionando en estructuras basadas en células que, para ser sinceros, son bastante buenas de todos modos y probablemente a dónde esas empresas deberían ir. Decirle a una empresa que necesita tres tipos de cultura, tres tipos de actitud, un sistema de robo, un mapa de su entorno y altos niveles de conciencia situacional suele ser suficiente para que los gestores se escapen. No cabe en un simple 2 x 2. Tampoco importa para muchas organizaciones porque solo necesitas altos niveles de conciencia situacional y estructuras adaptativas si compites contra organizaciones que tienen lo mismo o estás en el final muy agudo de la competencia feroz. Personalmente, para la mayoría de las empresas, entonces recomendaría usar una estructura basada en células y leer «ranas en ebullición» de GCHQ, que es un trabajo excepcional. Le dará ideas más que suficientes y contiene una estructura muy similar.
Apuntar que en los últimos años he escuchado a mucha gente hablar sobre estructuras duales. Tengo que decir que desde mi perspectiva y experiencia, este tipo de estructuras son fundamentalmente defectuosas y que te están llevando por el camino de los extremos. No es suficiente lidiar con los extremos, debes manejar la transición en el medio. Si no lo hace, no creará una organización que haga frente a la evolución. Si se enfoca en los extremos, disminuirá el centro más importante, tenderás a crear una guerra entre facciones y debido a que los componentes de los pioneros nunca evolucionan (los planificadores de la Ciudad describirán estos sistemas como «fraudulentos») entonces creas un «nunca crece la plataforma» y encima de esto una creciente «unión de spaghetti» de «lo nuevo» construido sobre «nuevo». Lo experimenté yo mismo en 2003 junto con el inevitable y lento frenado del desarrollo y los llamados «proyecto de estrella de la muerte» de inmensa escala para construir la «nueva plataforma para el futuro». Nunca he visto ese trabajo.
Doctrina de categorización
La doctrina es universal y aplicable a todos los contextos, aunque muchos requieren que uses un mapa para explotarlos por completo. Merece la pena hacer una distinción aquí (cortesía de Trent Hone). Mientras que la doctrina consiste en principios básicos, la aplicación de esos principios será diferente en diferentes contextos. Por ejemplo, «Centrarse en las necesidades del usuario» no significa que todos nos centremos en las mismas necesidades del usuario, sino que las necesidades exactas del usuario variarán según el contexto y el propósito. Las necesidades del usuario de una empresa automoción no son las mismas que las de una tienda de té. Igualmente, las necesidades del usuario de «la mejor tienda de té en Kent» no son las mismas que las necesidades del usuario de «la tienda de té más conveniente en Kent». Por lo tanto, la doctrina se puede subdividir en los principios de la doctrina (es decir, «centrarse en las necesidades del usuario») y la implementación de doctrina (es decir, «el usuario necesita la tienda de té más conveniente en Kent»)
Además, la doctrina es un conjunto de creencias sobre las cuales tienes elección. Son algo que usted aplica a una organización a diferencia de los patrones climáticos que se aplicarán a usted independientemente de su elección. También representan nuestra creencia de lo que funciona en todas partes. Enumeré las formas básicas de doctrina (los principios) que cubriremos en este libro en la figura 44, marcando en naranja las que acabamos de leer. Esta no es una lista exhaustiva, pero es suficiente por ahora. En capítulos posteriores recorreremos esta sección, refinando tanto los conceptos como los diferentes aspectos de la doctrina a medida que avanzamos. Como referencia, las categorías que uso para la doctrina dependen de si impacta principalmente: –
- métodos de comunicación.
- la mecánica del desarrollo o la construcción de cosas.
- el funcionamiento de una organización.
- cómo estructurar nosotros.
- la manera en que nos enteramos.
- la forma en que ejecutamos.
Figura 44. Doctrina
Usando la doctrina con nuestro primer mapa
Cuando lees la lista de doctrinas, suena basicamente a sentido común. La mayoría de ellos lo son pero, de nuevo, son muy difíciles de lograr (el sentido común es el menos común de los sentidos a veces). Realmente tienes que trabajar duro en ellos. En el caso de «eliminar duplicación y sesgo», no puede aplicarlo efectivamente a su primer mapa porque requiere múltiples mapas. Sin embargo, incluso con un mapa simple, puede aplicar algunas de estas doctrinas. En la figura 45, tomé nuestro primer mapa en el que aplicamos patrones económicos comunes a la figura 28 ( Capítulo 3 ) y mostré dónde es relevante la doctrina.
Figura 45 – Aplicando la doctrina y patrones económicos a nuestro primer mapa.
Punto 1 : centrarse en las necesidades del usuario. El ancla del mapa es el usuario, en este caso un cliente.
Punto 2 : el mapa proporciona un lenguaje común. Proporciona un mecanismo para desafiar visualmente los supuestos.
Punto 3 : utilice los métodos adecuados (agile, lean y six sigma o interno vs externo) y no intente aplicar un solo método en todo el contexto.
Punto 4 : trate el mapa como componentes pequeños y use equipos pequeños (p. Ej., Equipo 4).
Punto 5 – Considere no solo la aptitud sino también la actitud (pioneros, colonos y urbanistas).
Punto 6 – Diseño para la evolución constante. Los componentes evolucionarán y esto podría requerir la formación de nuevos equipos (por ejemplo, el equipo 8) con nuevas actitudes.
Merece la pena tomarse un poco de tiempo para reflexionar sobre la figura 45. Lo que tenemos no es solo las necesidades del usuario, los componentes que satisfacen esas necesidades y los patrones económicos comunes que lo afectan, sino también una anticipación del cambio, la estructura organizativa que necesitaremos y incluso los tipos de métodos y cultura que son adecuados. Todo esto está en un solo diagrama. En la práctica, normalmente solo mostramos las estructuras en el mapa que son relevantes para la tarea en cuestión, es decir, si anticipamos un cambio, entonces podríamos no mostrar la estructura celular, la actitud y, por lo tanto, los aspectos culturales. Sin embargo, merece la pena señalar que todos se pueden mostrar y con la práctica aprenderá cuándo incluirlos o no.
Ahora estamos en una posición de comprender nuestro contexto, poder anticipar algunas formas de cambio debido a los patrones climáticos y tenemos una comprensión de la doctrina universal básica para ayudarnos a estructurarnos. Finalmente estamos en un punto en el que podemos comenzar a aprender las formas de juego específicas del contexto que están en el corazón de la estrategia. Con unas pocas lecciones básicas sobre el juego, estaremos listos para actuar.
Un ejercicio para el lector
En el capítulo 3, le pedí que aplicara algunos patrones económicos básicos a un mapa que creó en el capítulo 2 . Si ha estado omitiendo estos ejercicios, ahora es el momento de regresar y completarlos. El mapeo no es algo que solo puede leer y convertirse en un experto, es algo que debe aplicar y aprender.
Quiero que ahora tome su mapa y observe las diversas formas de doctrina resaltadas en la figura 44. Intente y trabaje con otros y aplíquelos a su mapa. ¿Estás pensando en las necesidades del usuario? ¿Estás desafiando tus suposiciones? ¿Cómo te organizarías? ¿Conoces los detalles?
3 comentarios en «Capítulo 04 – Doctrina»