Eleva tus habilidades de liderazgo y negocios

Súmate a más de 52,000 líderes en 90 empresas mejorando habilidades de estrategia, gestión y negocios.


Innovación a la velocidad de la información

Desarrollar un nuevo producto implica un ensayo y error, pero más allá de un cierto punto, el rediseño se vuelve inútil. Una herramienta práctica y comprobada, la matriz de estructura de diseño, puede ayudar a agilizar la forma en que una empresa innova.
Innovación a la velocidad de la información

El intercambio de información es el elemento vital del desarrollo de productos. Cuando los diseñadores de circuitos de una empresa electrónica saben lo que hacen los diseñadores de carcasas, diseñan un circuito que se adapta mejor a la carcasa. Y cuando los diseñadores de carcasas saben lo que necesitan los diseñadores de circuitos, diseñan una carcasa en la que sea más fácil colocar un circuito mejor. Estos flujos de información permiten la experimentación y la innovación y, por esa razón, muchas empresas fomentan la retroalimentación y la iteración en sus procesos de desarrollo de productos. Esta práctica se conoce como ingeniería simultánea.

Sin embargo, la iteración excesiva puede tener inconvenientes. Un continuo retroceso del trabajo consume inevitablemente tiempo y recursos. Y muchas de las iteraciones pueden resultar solo marginalmente beneficiosas o incluso derrochadoras. Por ejemplo, en una empresa de telecomunicaciones a la que asesoramos mis colegas y yo, había hasta 20 iteraciones regulares entre los equipos que trabajaban en dos especificaciones técnicas clave. El resultado fue que pocas personas trabajaron cuidadosamente en las especificaciones en las primeras etapas, porque todo el mundo sabía que se producirían repeticiones exhaustivas en el tiempo.

La lección está clara. La iteración debe planificarse y gestionarse cuidadosamente. Se debe fomentar una buena iteración y eliminar la iteración incorrecta. Para ello, los gerentes necesitan herramientas de representación que les ayuden a identificar y modelar la iteración.

Lamentablemente, los kits de herramienta estándar de administración de proyectos, como Microsoft Project, no contienen estas herramientas. Las herramientas de planificación de proyectos más utilizadas (principalmente diagramas de red PERT y CPM) son descripciones gráficas de los flujos de tareas. En ellas, las tareas suelen estar representadas por cuadros o círculos, y la secuencia se representa mediante flechas. En un proyecto complejo, un gráfico puede tener decenas o incluso cientos de páginas, y cada página contiene un número limitado de círculos y flechas legibles. Una representación de cajas y flechas del proceso de diseño de la suspensión de un automóvil, por ejemplo, tendría más de 30 páginas. Si el proyecto se compone de tareas que se pueden completar en secuencia sin temor a que se vuelvan a trabajar, se pueden generar gráficos manejables para pequeños fragmentos de trabajo.

Pero las herramientas se vuelven muy difíciles de usar si lo que sucede en la página 60 te obliga a reelaborar una tarea de la página 18 y, por lo tanto, muchas de las tareas posteriores vuelven a la página 60. Es casi imposible para los gerentes comprender, y mucho menos cambiar, la organización completa de un proceso de este tipo con una herramienta convencional de gestión de proyectos. Además, por su naturaleza, los procesos de desarrollo de productos de alta tecnología suelen implicar muchas tareas entrelazadas.

La matriz de estructura de diseño se diferencia de las herramientas convencionales de gestión de proyectos en que se centra en representar flujos de información en lugar de flujos de trabajo. Por lo tanto, es capaz de representar mejor la dinámica clave de los procesos de innovación.

Sin embargo, existe una herramienta que los gerentes pueden utilizar para obtener una representación sencilla y significativa de procesos tan complejos. Esta herramienta, Design Structure Matrix (DSM), se diferencia fundamentalmente de las herramientas convencionales de gestión de proyectos en que se centra en representar los flujos de información de un proyecto en lugar de los flujos de trabajo. Como resultado, puede representar mejor la dinámica clave de los procesos de innovación, como el desarrollo de productos. Además, a menudo puede proporcionar representaciones de procesos de desarrollo complejos en una sola página. En este artículo, explicaremos cómo funciona el DSM y mostraremos cómo un gestor puede usarlo para hacer que los procesos de desarrollo sean más eficientes. En primer lugar, vamos a explorar por qué el desarrollo de productos necesita una herramienta de planificación fundamentalmente diferente.

El desarrollo de productos se trata de información, no de tareas

Se crearon diagramas PERT, diagramas de Gantt y otras herramientas de programación comunes para ayudar a los gerentes a planificar proyectos de construcción de gran envergadura, como la construcción de naves o fábricas. Aunque estos proyectos pueden ser complejos e implicar cientos de tareas diferentes o más, los principios de planificación son bastante sencillos: tú decides dónde y cuándo deben llevarse a cabo las tareas. No importa cuán complicado sea, todos los proyectos de construcción pueden considerarse como una secuencia de tareas discretas, muchas de las cuales pueden llevarse a cabo simultáneamente, pero ninguna de las cuales debería ser reelaborada como resultado de información posterior.

Imagina que estás construyendo una casa. Algunas tareas deben completarse en secuencia. No puedes enmarcar las paredes hasta que hayas construido los cimientos. No puedes ponerte en el tejado hasta que hayas construido las paredes. Tareas secuenciales, por definición, confíe en la información generada por tareas anteriores. Otras tareas, denominadas tareas paralelas, se puede llevar a cabo simultáneamente. Puede instalar ventanas, pasar cables y colocar tuberías al mismo tiempo. Estos tres trabajos necesitan muros, pero ninguno necesita los otros dos. Ni las tareas secuenciales ni las paralelas tendrán que ser reelaboradas como resultado de tareas posteriores. No cambias los cimientos después de construir los muros. No se vuelve a cablear como resultado del acristalamiento de la ventana.

El desarrollo de productos es muy diferente. Requiere innovación y la innovación requiere ciclos complejos de aprendizaje (retroalimentación). Repite las tareas anteriores a medida que aprende de las siguientes. Las tareas interdependientes que se benefician mutuamente de esta manera se conocen como tareas acopladas. Si quieres crear una base mejor para futuras casas, puedes rediseñar los cimientos después de construir los muros. La información de esta iteración es precisamente lo que ayuda a encontrar la mejora, y la presencia de tareas asociadas es lo que distingue los procesos de innovación, como el desarrollo de productos, de los proyectos de construcción.

Las herramientas convencionales responden a la pregunta: «¿Qué otras tareas debo completar antes de comenzar esta?» Pero los planificadores de un proceso de desarrollo de productos necesitan una herramienta que responda a una pregunta muy diferente: «¿Qué información necesito de otras tareas antes de poder completar esta?» Esta es la pregunta que aborda la matriz de estructura de diseño.

Dibujando el DSM

La construcción de un DSM del proceso de desarrollo de productos existente de su empresa es un proceso relativamente sencillo, aunque a veces lento. El primer paso, identificar las tareas implicadas, es fácil y, a menudo, está disponible como parte de la documentación de gestión de proyectos. Las empresas con un proceso de desarrollo establecido ya conocen las tareas necesarias para desarrollar un nuevo producto. Ford, por ejemplo, ejecuta en gran medida el mismo proceso cada vez que desarrolla un nuevo motor de automóvil.

Lo que lleva tiempo es identificar correctamente las necesidades de información de las distintas tareas. No puedes confiar en lo que te digan los gerentes de tu empresa: por lo general no son las personas que realizan el trabajo y pueden tener interés en justificar procesos existentes u obsoletos. Cuando dibujamos un DSM para un proceso de desarrollo de productos, nos dirigimos a las bases y preguntamos a los equipos de desarrollo individuales qué necesitan de otros equipos para hacer su trabajo. Es importante centrarse en los aportes y no en los resultados porque hemos descubierto que los gerentes, ingenieros y otros profesionales del desarrollo de productos son más precisos a la hora de identificar lo que necesitan saber que al describir lo que otros necesitan saber.

Una vez que tengas toda esta información, estarás listo para dibujar el DSM del proyecto. Primero, enumere todas las tareas en el orden en que se llevan a cabo actualmente. Organízalos en el mismo orden horizontal y verticalmente para formar una matriz de filas y columnas. En cada fila correspondiente a una tarea, marque las demás tareas que proporcionan la información necesaria. En otras palabras, al mirar a lo largo de una fila se muestran todas las entradas de información que necesitas para completar una tarea, y al mirar hacia abajo una columna se muestran todos los resultados de información que proporcionarás a otras tareas. Considere el DSM simplificado que se muestra a continuación. Leer a lo largo de la fila B indica que la tarea B necesita información de las tareas A, G y J. Al leer la columna B se indica que la tarea B proporciona información para las tareas E, H y J.

Innovación a la velocidad de la información

Lo que el DSM puede decirte

Un DSM de su proceso de desarrollo proporciona una comprobación de la realidad útil. En primer lugar, revela claramente qué intercambios de información implican la iteración del diseño y cuáles no. En el ejemplo que acabamos de presentar, observe la diagonal formada por los puntos que dividen nuestra matriz. Todas las X por debajo de la diagonal denotan feedforward intercambios de información en los que se dispone de información de tareas anteriores para tareas posteriores. Pero un X en la mitad superior denota retroalimentación en el que la información de una tarea posterior puede obligar a reelaborar una tarea anterior. Estos son los acoplado tareas. La tarea B, por ejemplo, necesita información de la tarea G, que se lleva a cabo mucho después de B. La ejecución de B requiere adivinar o asumir la información que falta de G. Cuando finalmente se disponga de información completa y precisa de la tarea G, puede ser necesario reelaborar la tarea B. Luego, el proceso de desarrollo debe comenzar de nuevo a partir de B, y las tareas de intervención también se repiten para reflejar el cambio en la salida de B.

Un DSM revela claramente qué intercambios de información implican la iteración del diseño y cuáles no. También puede ayudarlo a ver qué tan bien su proceso de desarrollo se anticipa a la necesidad de volver a trabajar.

Un DSM también puede ayudarle a ver qué tan bien su proceso de desarrollo se anticipa a la necesidad de volver a trabajar. He aquí cómo. En el DSM, simplemente dibuja cajas alrededor de las tareas que realiza tu empresa simultáneamente, es decir, de forma interdependiente. Estas son las de tu empresa planificado iteraciones, las tareas que su empresa reconoce como repetitivas y, por lo tanto, organiza para facilitar y acelerar el flujo de información entre ellas. Si todos los X que están por encima de la diagonal se capturan dentro de las cajas, su organización ha planificado estas iteraciones y ha organizado su proceso para acomodarlas de la manera más eficiente posible. Nuestro segundo ejemplo, a continuación, muestra que las tareas E a I se realizan simultáneamente. Sin embargo, la empresa no ha podido prepararse para un buen número de iteraciones potenciales: todavía hay cuatro marcas de retroalimentación (ahora representadas por O s) por encima de la diagonal y fuera de las tareas en caja. Estos son no planificado iteraciones.

Innovación a la velocidad de la información

En la práctica, por supuesto, los desarrolladores de productos exitosos son buenos para reconocer iteraciones potenciales y sus DSM suelen revelar un flujo de información bastante eficiente. Sin embargo, algunas empresas encuentran que este ejercicio revela procesos confuso. Un ejemplo es la empresa de telecomunicaciones cuyo proceso de desarrollo de los servicios de datos se describe en el gráfico «Desarrollo caótico en las telecomunicaciones». Los ingenieros de la empresa se habían sentido frustrados durante mucho tiempo por el tiempo y la energía necesarios para desarrollar nuevos servicios, pero no fue hasta que vieron un DSM que se dieron cuenta de cuántos bucles de retroalimentación se habían integrado en su proceso.

Innovación a la velocidad de la información

Desarrollo caótico en las telecomunicaciones La elaboración de un DSM del proceso de desarrollo de los servicios de datos de esta empresa reveló de inmediato el grado de iteración no planificada. Las iteraciones dentro de las fases se integraban en el proceso (los cuadros sombreados), pero las iteraciones no planificadas a través de las fases (las O) eran la realidad.

Optimización de flujos de información

El DSM es un recurso poderoso para organizaciones como la compañía de telecomunicaciones porque ayuda a los gerentes no solo a identificar problemas sino también a ver cómo solucionarlos. A continuación, examinamos cuatro formas de mejorar los flujos de información de una empresa.

Reorganiza la secuencia de tareas.

El primer paso para racionalizar un proceso de desarrollo de productos es determinar si una secuencia diferente de tareas reducirá el número de marcas de retroalimentación. Esto implica reorganizar las filas del DSM, un proceso que los ejecutivos de Boeing denominan «eliminar las repeticiones fuera de secuencia». El objetivo es mover tantos X es lo más posible desde arriba de la diagonal hasta debajo de ella.

Empieza por identificar a los candidatos para las primeras y las últimas tareas. Idealmente, la primera tarea no requeriría ninguna entrada, lo que indica que nunca será necesario volver a elaborarla. En referencia a los dos DSM anteriores, la tarea A, por lo tanto, queda en primer lugar. La tarea C viene a continuación porque solo necesita información de A; estas son secuencial tareas. Luego, seleccionamos las tareas D y F para que vengan a continuación porque solo requieren información de A y C. Tenga en cuenta que D y F no requieren información entre sí, por lo que pueden llevarse a cabo en paralelo, lo que indicamos con un cuadro de líneas discontinuas en nuestro tercer ejemplo.

Del mismo modo, la última tarea ideal no produciría ninguna información requerida por otras tareas (en otras palabras, su columna quedaría en blanco). Aquí está la tarea H, que se convierte en la última tarea del proyecto.

Cuando ya no pueda encontrar ninguna tarea para programar temprano o tarde, debe agrupar las tareas restantes en bloques, con lo que el X está más cerca de la diagonal. En nuestro ejemplo, la secuencia más eficaz muestra dos bloques de tareas acopladas: B, J y G deben ejecutarse juntas, al igual que las tareas E e I. Este DSM planea todas las iteraciones.

Innovación a la velocidad de la información

Para un DSM simple como el de aquí, es bastante fácil identificar mediante prueba y error el orden y el acoplamiento de tareas que minimizan el número de retroalimentación de información por encima de la diagonal. Sin embargo, en el caso de los DSM más complicados, deberá aplicar un enfoque sistemático que implique el uso de algoritmos informáticos.

Vuelva a revisar la organización de tareas.

Después de haber reorganizado el orden de las tareas, ahora debería reconsiderar su organización. Observe de nuevo los dos bloques de tareas acopladas que se muestran en el tercer DSM, arriba. En principio, las tareas de cada conjunto deben llevarse a cabo al mismo tiempo y en el mismo lugar. Pero mire hacia atrás en el segundo DSM, que muestra las tareas que la hipotética empresa lleva a cabo de forma simultánea. La tarea E se agrupa con I, pero las tareas B, J y G no entran en la agrupación inicial de tareas simultáneas; como resultado, las iteraciones con B, J y G requieren muchas más tareas en el proceso original. Claramente, esta empresa necesita replantearse qué tareas se juntan con qué otras.

Mantener las tareas interdependientes separadas puede causar un desperdicio considerable, y es aquí donde agrupar tareas de forma diferente puede acelerar el proceso de desarrollo.

Mantener las tareas interdependientes separadas puede causar un desperdicio considerable, y es aquí donde agrupar tareas de forma diferente puede ayudar realmente a acelerar el proceso. Una empresa de electrónica a la que asesoramos descubrió que estaba realizando un conjunto de tareas estrechamente relacionadas en dos países diferentes. Cuando los equipos estuvieron juntos brevemente, pudieron completar las tareas asociadas en solo dos semanas, permitiendo así que otros trabajos continuaran utilizando sus resultados.

Reduzca el intercambio de información.

Sin embargo, la resecuenciación de la matriz solo te llevará a un proceso de desarrollo eficiente. El siguiente paso consiste en reducir el número de intercambios de información cambiando el contenido de algunas de las tareas. Dado que la importancia y la naturaleza de los intercambios de información entre tareas pueden diferir considerablemente, normalmente es posible dividir las tareas acopladas en conjuntos más pequeños cambiando las especificaciones de las tareas. Aunque esto puede significar aumentar el número de tareas y personas, la reducción del número de flujos de información (y, por lo tanto, de iteraciones potenciales) compensa con creces estas inversiones. Los ejecutivos de una empresa aeroespacial con la que hemos trabajado, por ejemplo, creen que este ejercicio les ayudó a reducir el número de iteraciones potenciales en los procesos de desarrollo de la empresa hasta en un 50%.%.

Estas son tres formas de reducir la necesidad de intercambiar información. En primer lugar, puedes transferir conocimientos clave entre equipos. En algunos casos, una empresa puede desacoplar una tarea de otra simplemente añadiendo a cada equipo a alguien con experiencia en la otra tarea. Estas personas deben estar suficientemente informadas para proporcionar información que de otro modo se habría intercambiado en una o más iteraciones entre equipos.

Se puede lograr un efecto similar mediante el uso de la tecnología de la información. El software de ingeniería asistida por ordenador, por ejemplo, permite a los equipos de diseño predecir las implicaciones de sus diseños entre sí, evitando de nuevo la necesidad de un intercambio directo de información. Un diseñador de piezas de plástico de un fabricante de teléfonos móviles puede utilizar un software de simulación de flujo de moldes para prever los problemas de producción derivados de su diseño. De esta manera, puede anticipar los comentarios de los expertos en herramientas de moldes que de otro modo la obligarían a volver a la mesa de dibujo semanas después.

En segundo lugar, puede introducir una nueva tarea al principio del proceso para simplificar las iteraciones posteriores, que requieren mucho tiempo, realizadas por equipos interdependientes. La nueva tarea suele requerir un acuerdo temprano sobre aspectos comunes a las tareas acopladas. La adición de una nueva tarea, llevada a cabo por representantes de los equipos acoplados, puede desglosar algunas de las iteraciones. Por ejemplo, dos equipos que diseñan piezas acopladas (por ejemplo, un circuito de control electrónico y su teclado de interfaz de usuario) pueden acordar por adelantado la ubicación de los puntos de fijación y los microinterruptores. Esta especificación de interfaz permite al equipo de diseño de circuitos y al equipo de teclados proceder en paralelo.

En tercer lugar, puede redefinir tareas dentro de grupos acoplados. Otra forma de reducir las iteraciones es eliminar un intercambio de información dentro de un grupo añadiendo una o dos tareas adicionales para intervenir entre las tareas existentes en el grupo. Para ver cómo se puede hacer esto, resulta instructivo comparar cómo dos proveedores diseñan el mismo componente de tablero, un grupo de velocímetro para General Motors. (Consulte la barra lateral «Reducción del intercambio de información mediante la disociación de tareas»).

El proveedor A adopta un proceso de ingeniería simultáneo, realizando tres tareas (diseño de la carcasa, disposición del cableado y detalles de iluminación) a la vez, con tres equipos de trabajo trabajando en estrecha proximidad. Los tres equipos pasan por varias iteraciones y tardan un tiempo relativamente largo en finalizar sus planes, pero el resultado final es un prototipo bastante avanzado. Sin embargo, si la fase de prueba revela problemas, pueden verse afectados hasta cuatro pasos del proceso y es posible que haya que repetir gran parte del proceso (consulte O está en el lado izquierdo de la exposición).

El proveedor B adopta un enfoque diferente, reduciendo las tareas asociadas a solo dos: diseño de la carcasa y detalles de iluminación. Un circuito de cableado se elabora en función de la salida de las dos primeras tareas, y el velocímetro se crea un prototipo burdo. Una vez probado el prototipo, se realizan revisiones de cableado para producir el diseño final. Aunque implica una tarea adicional (revisar el cableado), de hecho, este proceso es más rápido que el primero porque hay mucha menos iteración entre dos equipos de tareas que entre tres. El paso adicional también anticipa y permite cambios en el prototipo, y las iteraciones planificadas eliminan prácticamente las no planificadas.

Un proceso combinado fomenta las iteraciones y la búsqueda de soluciones creativas. Pero a veces la velocidad es más importante que la innovación.

En general, cualquier decisión de desacoplar una tarea (en este caso, el cableado) depende de cómo la empresa ve la compensación entre velocidad y calidad. Un proceso combinado fomenta las iteraciones y la búsqueda de soluciones creativas y, por lo tanto, es más probable que produzca una mejora significativa en la calidad del producto que se está desarrollando. Pero a veces la velocidad es más importante que la innovación. Entonces, es preferible un proceso más rápido y menos acoplado.

Gestiona las repeticiones imprevistas.

Hasta el momento, la mayor parte de nuestro debate se ha centrado en procesos relativamente pequeños y de fácil administración. En nuestro ejemplo teórico, por ejemplo, fue posible optimizar un proceso para que todos los X se han movido cerca o por debajo de la diagonal. Todas las tareas acopladas podrían llevarse a cabo simultáneamente, por lo que todas las iteraciones podrían planificarse.

Sin embargo, en la vida real, el desarrollo de productos es un proceso amplio y complicado. Es raro que una empresa pueda diseñar un proceso en el que todas las tareas acopladas se puedan llevar a cabo juntas. Por lo general, habrá tareas que solo se pueden realizar más adelante en el proceso pero que proporcionan información sobre las tareas completadas meses antes.

Piense en Intel, uno de los desarrolladores de productos más exitosos y una empresa que lidera regularmente el camino en el desarrollo de la próxima generación de microprocesadores. El proceso de desarrollo de productos para chips semiconductores de Intel consta de 60 tareas distintas, y el DSM se muestra en la barra lateral «Desarrollo de semiconductores en Intel». Por encima de la diagonal, el X denotan intercambios de información planificados, y el O significan iteraciones no planificadas.

Como revelan las áreas en caja del DSM, Intel agrupa la mayoría de las tareas en 15 etapas administradas simultáneamente. Algunas de las etapas se superponen, es decir, algunas de las tareas de un grupo también se incluyen en el siguiente. Como es de esperar, hay pocos incentivos para que una empresa de gran éxito como Intel mejore su proceso probado y de confianza mediante la reorganización y la reorganización de sus tareas. Igualmente, es poco lo que se puede ganar con la descomposición de los grupos acoplados existentes.

Pero como el O, puede producirse un número significativo de iteraciones no planificadas potenciales cuando se descubren errores durante el proceso de desarrollo. Los resultados de las pruebas térmicas de Intel (tarea 54), por ejemplo, podrían obligar a la empresa a reelaborar el diseño del paquete (tarea 29) o a reelaborar el modelado funcional (tarea 17) o ambas. Esta revisión también requeriría que la empresa rehiciera algunas tareas intervinientes. El valor del DSM en casos como este reside principalmente en hacer explícito dónde pueden producirse intercambios de información de este tipo. A continuación, la empresa decide qué hacer con ellos.

A veces, es poco lo que puede hacer. Las tareas interdependientes pueden estar tan separadas que un retraso causado por la incorporación efectiva de información tardía significa volver a iniciar todo el proceso. Estas situaciones suelen surgir porque al principio del proyecto se cometió algún error fundamental en las suposiciones. En el caso de Intel, la creación de una demostración de producto (tarea 48) tenía el potencial de revelar que las estimaciones de volúmenes de ventas y niveles de precios de la empresa eran defectuosas (tareas 2 y 3). Si los errores fueran graves, el producto tendría que ser rediseñado por completo.

En tales casos, recomendamos tratar la información negativa como «comentarios sobre el aprendizaje generacional», como hizo Intel (consulte •’s en la parte superior de la tabla). En lugar de reelaborar por completo el producto desarrollado y quedar por detrás de los competidores en ese ciclo de producto, la empresa abandonará el proyecto por completo si la información revela fallas fatales o lanzará el producto tal y como se diseñó si los defectos son menores. Mientras tanto, la información se introducirá en el diseño y desarrollo de un producto en la próxima generación.

Sin embargo, en la mayoría de los casos, los equipos de desarrollo prefieren minimizar la probabilidad de que una tarea posterior genere información que requiere reelaboración. Por lo tanto, tiene sentido transferir conocimientos clave y crear tareas previas, como hemos comentado anteriormente. Sin embargo, las soluciones individuales pueden surgir de forma inesperada. En Intel, por ejemplo, los gerentes descubrieron que podían reducir la probabilidad de fallos en las pruebas térmicas si un ingeniero de pruebas térmicas contribuyera al diseño del paquete. Las soluciones de este tipo nunca eliminarán por completo las iteraciones no planificadas, pero ciertamente reducirán la probabilidad de que se produzcan.

Al eliminar el misterio en torno al intercambio de información durante la innovación, el DSM puede dar a los gerentes mucho más control sobre algunos de los proyectos más costosos y arriesgados de su empresa.

Según nuestra experiencia, la información generada en un análisis de DSM siempre ha aportado nuevos conocimientos para mejorar la forma en que las empresas desarrollan productos y servicios. Al eliminar el misterio en torno al intercambio de información durante la innovación, el DSM puede dar a los gerentes mucho más control sobre algunos de los proyectos más costosos y arriesgados de su empresa.


Escrito por
Steven D. Eppinger




Eleva tus habilidades de liderazgo y negocios

Súmate a más de 52,000 líderes en 90 empresas mejorando habilidades de estrategia, gestión y negocios.