"Las Reglas de la Colaboración: Guía para Colaborar Cuando No Te lo Habías Propuesto desde un Inicio

(Material de Lectura "Curso Introductorio: Introducción a la Colaboración" & "Curso Avanzado: Colaboración: Modelos de Negocios Colaborativos y Estrategia en la Nueva Era", Hugo Céspedes A.)

No solo las pandemias generan cambios en las reglas de funcionamiento, el contexto en general, sumado a las necesidades y problemas, con el correr del tiempo también van generando cambios en la forma de llevar a cabo procesos y/o procedimientos de creación de valor en todo su amplio espectro. Ya he dicho en post anteriores que el Status Quo no ayuda a la adaptación, incluso "las reglas ayudan a cambiar las reglas".

También en posteos anteriores, he tocado el tema de "la Colaboración", "la Inteligencia Colectiva", "Comunidades, Colaboración y Propósito", "Gestión de la Colaboración", "Medición de la Colaboración para su Gestión", "Liderazgo para la Colaboración", "Cómo Establecemos Redes Colaborativas", entre otros. Sin embargo, en esta ocasión quiero comenzar a dar tips (como lo haré con "los recursos" que pondré a disposición de ustedes este año en mi nueva website que estoy preparando) sobre cómo se viene la mano en lo relativo a la Colaboración, y cómo debemos acostumbrarnos a la flexibilización para la adaptación como base de la Estrategia de Colaboración.

Ya en 2005 Philips Evans & Bob Wolf vislumbraban que "los líderes corporativos que buscaban crecimiento, aprendizaje e innovación podían encontrar la respuesta en lugares sorprendentes" (casos como Linux, el Sistema de Producción de Toyota, entre otros).

Casos de Validación.

Por ejemplo, "Linux" es la creación de una comunidad necesaria y autorganizada de miles de programadores voluntarios y empresas. La mayoría de los líderes venderían a sus abuelas por fuerzas de trabajo que colaborarían de manera tan eficiente, fluida y creativa como los autodenominados "hackers" de Linux. Linux es una comunidad de software libre/ de código abierto que desarrolló y continúa refinando el sistema operativo y otros programas de código abierto.

Por su parte "Toyota", es una empresa como cualquier otra, clasificada entre las organizaciones de mejor desempeño del mundo. El fabricante de automóviles ha sido durante mucho tiempo líder en calidad y producción ajustada, y el éxito del Prius híbrido ha establecido su reputación como innovador. "Los métodos de gestión de Toyota se asemejan, en varios aspectos fundamentales, al funcionamiento de la comunidad Linux; el Sistema de Producción de Toyota (TPS) debe parte de su renombrada capacidad hacia un híbrido entre una jerarquía abierta". De hecho, la propia Toyota está evolucionando hacia un híbrido entre una jerarquía convencional y una red autorganizada similar a Linux.

Caso Linux: En Diciembre de 2003, cerca de la medianoche, Andrea Barisani, administrador de sistemas del departamento de física de la Universidad de Trieste, descubrió que un atacante había atacado el servidor Gentoo Linux de su institución. Rastreó la brecha hasta un punto vulnerable en el kernel de Linux y otro en rsync, un mecanismo de transferencia de archivos que replica automáticamente los datos entre las computadoras. "Este fue un ataque serio: cualquier penetración de rsync podría comprometer archivos en miles de servidores en todo el mundo".

Barisani despertó a algunos colegas, quienes lo pusieron en contacto con Mike Warfield, investigador principal de Internet Security Systems en Atlanta, y con Andrew “Tridge” Tridgell, un conocido programador de Linux en Australia en cuya tesis doctoral se basó rsync. Dirigieron el mensaje de Barisani (anónimo por razones de seguridad) a otro australiano, Martin Pool, que trabajaba para Hewlett-Packard en Canberra y había sido líder en el desarrollo de rsync. Aunque Pool ya no era responsable de rsync (nadie lo era), de inmediato llamó por teléfono y envió correos electrónicos, primero interrogó a Warfield y Dave Dykstra (otro de los primeros contribuyentes al desarrollo de rsync, que tenía su sede en California) sobre las vulnerabilidades y luego ayudó a Barisani a rastrear la falla línea por línea.

Por la mañana, hora de Trieste, Pool y Barisani habían encontrado la ubicación precisa de la brecha. Pool se puso en contacto con el actual grupo de desarrollo de rsync, mientras que Barisani se conectó con la afiliación suelta de aficionados y profesionales que empaquetan Gentoo Linux, y publicó un aviso de alerta temprana en el sitio de Gentoo. Pool y Paul “Rusty” Russell (un compañero de Canberran que trabaja para IBM) luego trabajaron durante la noche australiana para escribir un parche, y en cinco horas los usuarios-desarrolladores de Gentoo comenzaron a probar la primera versión. Mientras tanto, Tridge elaboró una descripción de la vulnerabilidad y su solución, asegurándose (a instancias de Pool) de dar crédito a Barisani y Warfield por sus esfuerzos tras bambalinas. El jueves por la tarde, hora de Canberra, el anuncio y el parche se publicaron en el sitio web de rsync y, por lo tanto, se distribuyeron a los usuarios de Linux en todo el mundo.

Unos días después de la emergencia, después de recuperar su sueño, Barisani se ofreció como voluntario para colaborar con Warfield en la creación de un sistema de servidores deliberadamente vulnerables para atraer al cracker del sistema para que se revelara.

"Nadie autorizó ni dirigió este esfuerzo". A nadie, aficionado o profesional, se le pagó por participar o habría sido sancionado por no hacerlo. El trabajo de nadie dependía de detener el ataque. Nadie se calló por miedo a la responsabilidad legal. De hecho, la comunidad de usuarios en general se mantuvo informada de todos los desarrollos. Sin embargo, a pesar de la necesidad de la máxima seguridad, un grupo de unas 20 personas, de las cuales casi ninguna se conocía, empleadas por una docena de empresas diferentes, que vivían en tantas zonas horarias y se alejaban mucho de las descripciones de sus puestos, lo lograron en unas 29 horas. lo que podría haber tomado a colegas en cubículos adyacentes semanas o meses.

Es tentador descartar esto como un ejemplo de la rareza de los piratas informáticos: admirable, sí, pero nada que ver con los negocios reales. Consideremos, sin embargo, otra historia.

Caso Toyota: A las 4:18 am se produjo un incendio en la planta número 1 de Kariya de Aisin Seiki, un importante proveedor japonés de repuestos para automóviles. En cuestión de minutos, el edificio y prácticamente toda la maquinaria especializada en su interior quedaron destruidos. Kariya Número 1 produce el 99 % de las válvulas dosificadoras de líquido de frenos, o "válvulas P", para las operaciones japonesas de Toyota, piezas requeridas por cada vehículo que fabrica Toyota. Toyota, fiel a sus principios "justo a tiempo -Just in Time-", tenía menos del inventario de un día. El sistema de producción japonés de Toyota enfrentó la posibilidad de un cierre total de meses.

En cuestión de horas, los ingenieros de Aisin se reunieron con sus homólogos de Toyota y otros proveedores de primer nivel de Toyota. El grupo acordó improvisar la mayor cantidad de producción posible. A medida que la noticia se difundió a través de la red de proveedores, algunos de nivel dos se ofrecieron como voluntarios para desempeñar roles de liderazgo. Aisin envió planos de las válvulas a cualquier proveedor que las solicitara y distribuyó las herramientas, las materias primas y el trabajo en proceso intactos que pudieran salvarse. Los ingenieros de Aisin y Toyota ayudaron a preparar las líneas de producción en 62 ubicaciones: talleres mecánicos sin usar, el propio taller de creación de prototipos de Toyota, incluso una instalación de máquinas de coser propiedad de Brother. Denso, el mayor proveedor de Toyota, se ofreció como voluntario para gestionar la complicada logística del envío de válvulas a Aisin para su inspección y luego a las líneas de montaje estancadas de Toyota.

Todos se sorprendieron cuando un pequeño proveedor de segundo nivel de electrodos de soldadura, Kyoritsu Sangyo, fue el primero en entregar válvulas de calidad de producción a Toyota: 1000 de ellas, solo 85 horas después del incendio. Otros siguieron rápidamente y Toyota comenzó a reabrir las líneas de montaje el miércoles. Aproximadamente dos semanas después de la interrupción, toda la cadena de suministro volvió a la producción total. Seis meses después, Aisin "distribuyó una guía de respuesta a emergencias que contenía lecciones extraídas de la experiencia y recomendaba procedimientos para responder a este tipo de situaciones en el futuro".

Ningún individuo u organización planeó este esfuerzo: más bien, las personas y las empresas intervinieron donde pudieron. Los competidores colaboraron. A nadie en ese momento se le pagó por contribuir. Meses después, Aisin "compensó a las demás empresas por los costos directos de las válvulas que le habían entregado. Toyota otorgó a cada proveedor de nivel uno un honorario basado en las ventas actuales al fabricante de automóviles, alentándolos, pero no exigiéndolos, a hacer lo mismo con sus propios proveedores de nivel dos".

Aprendizaje Obtenido para Colaborar.

En eventos de Colaboración como el presentado, los individuos se encuentran y asumen roles sin un plan o una estructura de mando y control establecida (cuando no se lo han propuesto directamente, ya que se trata de eventos fortuitos de aprendizaje Colaborativo). Las redes humanas extendidas se pueden organizar en cuestión de horas y soslayar una catástrofe o amenaza. Personas, equipos y empresas pueden trabajar juntos sin contratos legales, ni sesgos negociados. Y a pesar de la falta de cualquier garrote autoritario o zanahoria financiera, esas personas pueden trabajar como locos para resolver el problema. De esta manera, sin saberlo, las personas se convierten en practicantes virtuosos de nuevos principios de trabajo que producen equipos energizados y de costos más bajos. Tampoco están solos.

Toyota y Linux son bastante similares en cuanto a la forma que combina características clave de ambos mercados y jerarquías. Al igual que los mercados, las comunidades de Toyota y Linux pueden autorganizarse, pero a diferencia de los mercados, "no utilizan efectivo ni contratos en momentos críticos". Al igual que las jerarquías, Toyota y Linux disfrutan de "bajos costos de transacción", pero a diferencia de las jerarquías, "sus miembros pueden pertenecer a muchas organizaciones diferentes -o ninguna- y no están limitados por funciones y responsabilidades específicas y predefinidas". Además, al igual que las jerarquías, "los miembros comparten un Propósito Común, pero ese Propósito emana de la automotivación más que de los incentivos o sanciones que generalmente imponen las jerarquías". En estos aspectos, ambas organizaciones representan lo mejor de ambos mundos. Un análisis de sus características comunes, sugiere cómo las organizaciones de alto rendimiento siguen siendo productivas e inventivas, incluso en condiciones extenuantes.

Pocas comunidades parecen más diferentes que el mundo de los Piratas Informáticos y el mundo disciplinado de la ingeniería automotriz japonesa. Pero los paralelismos entre estas historias son sorprendentes. En ambos casos, los individuos se encontraron y asumieron roles sin un plan o una estructura de mando y control establecida.

Una red humana extendida se organiza en horas y puede contra una amenaza. Personas, equipos y empresas trabajan juntos sin contratos legales ni pagos negociados. Y a pesar de la falta de cualquier garrote autoritario o zanahoria financiera, esas personas trabajaron como locos para resolver el problema.

Obviamente, estas fueron respuestas de emergencia. Pero una mirada a las operaciones diarias de la comunidad Linux y el Sistema de Producción de Toyota, revela que esas respuestas fueron simplemente intensificaciones de la forma en que la gente ya estaba trabajando.

Tips para Colaborar en estos Casos.

Si bien las reglas de mercado se refieren a "Efectivo" y "Contratos", y las reglas de las jerarquías se refieren a "la Autoridad" y "la Responsabilidad"; en el centro de las Comunidades de Linux y Toyota hay reglas sobre tres temas completamente diferentes: "Los Individuos y Grupos Pequeños que Trabajan Juntos"; "Cómo y Con Qué Amplitud se Comunican"; y "Cómo los Líderes Guían Hacia una Meta Común".

Disciplina de Trabajo Común: Las Comunidades antes presentadas están compuestas por ingenieros, por lo que los miembros tienen las mismas habilidades que sus colegas y hablan el mismo idioma. Pero estos grupos son mucho más disciplinados y rigurosos en su enfoque del trabajo que otras comunidades de ingenieros. Ambos enfatizan la "granularidad" (prestan atención a los pequeños detalles), eliminan los problemas desde el origen y recortan todo lo que parezca exceso, ya sea trabajo, código o material. Los miembros de Linux, por ejemplo, comparten una obsesión por escribir un código mínimo, compilar el resultado de cada día antes de pasar al siguiente y extirpar las fallas de programación a medida que avanzan. Por su parte los ingenieros de TPS son implacables al aplicar ciclos cortos de prueba y error, enfocándose en una sola cosa a la vez, y observando los procesos reales. Ambos grupos llevan esos principios a extremos aparentes. Los programadores de Linux reducen el código en busca de elegancia más que de eficiencia computacional. Los ingenieros de Toyota rechazan los estampados para el capó de Lexus, aunque impecable y completamente de las especificaciones, porque el brillo a sus ojos carece de lustre.
Comunicación Granular y Generalizada: En ambas Comunidades de sus respectivas organizaciones, la información sobre problemas y soluciones se comparte ampliamente, con frecuencia y en pequeños incrementos. En el caso de "los piratas informáticos" de Linux, no es entre individuos, sino mediante publicaciones en servidores de listas abiertos y de búsqueda. Cualquiera puede revisar el historial de versiones del código y los debates de Listery, no resúmenes ejecutivos o resúmenes, sino la actividad en bruto en sí, donde cada contribución de código es probada por decenas de persona, donde cada pirata informático concilian sus esfuerzos casi continuamente. Si alguien trabajara de forma aislada durante seis meses incluso en la contribución más brillante, probablemente sería rechazada por falta de compatibilidad con los esfuerzos de los demás. En Toyota, la mejora continua también comprende mil pequeñas colaboraciones. Los ingenieros de Toyota son famosos por "preguntar por qué cinco veces" para seguir una cadena de causas y efectos hasta la raíz de un problema. Esto no es un cliché insípido sobre pensar profundamente. Todo lo contrario. De hecho el mérito del precepto está precisamente en su superficialidad. Decir que C causa B y D causa C, lo lleva rápidamente a un nuevo dominio, probablemente el de otra persona. Entonces, en lugar de inventar soluciones complejas dentro de sus propios dominios, los ingenieros deben buscar soluciones simples más allá de ellos. "Hacer tus por qué", como se conoce la práctica, no se trata de profundidad en absoluto, se trata de amplitud. En este contexto, al igual que con Linux, los protocolos de comunicación de Toyota hacen cumplir esta disciplina. Cada reunión aborda solo un tema y conduce hacia un resultado específico, incluso si eso significa que las mismas personas se reúnen más de una vez al día. Las lecciones están escritas en un formato estándar en una sola hoja de papel A3. Todos aprenden cómo elaborar estos informes, hasta el pliegue del documento que muestra los puntos principales y oculta los detalles.
Líderes como Conectores: En todos los niveles, los líderes de ambas organizaciones desempeñan tres funciones fundamentales: a) Instruir a los miembros de la comunidad (a menudo con el ejemplo) en las disciplinas recién descritas; b) Articular metas claras y simples para cada proyecto en base a su visión estratégica; c) Conectar a las personas, por el mérito de estar muy bien conectados ellos mismos. Dicho eso, es necesario aclarar que "ninguna comunidad trata el liderazgo como una disciplina distinta del hacer". Mas bien "la credibilidad y la autoridad de los líderes se deriva de su competencia como practicantes". En las comunidades, liderar no se trata como una disciplina distinta de "hacer". Más bien, la autoridad de los líderes se deriva de su competencia como "practicantes". Ocasionalmente, los líderes tienen que realizar actos tradicionales de liderazgo, como arbitrar conflictos. Esto, sin embargo, es la excepción y se ve como una pequeña falla del sistema. La suposición predeterminada es que, en la medida de lo posible, los gerentes no administran en un sentido tradicional: la red humana se administra a sí misma. En Linux las prioridades de desarrollo no las decide un CEO, sino miles de piratas informáticos que votan con sus pies para elegir en qué trabajar. Este tipo de autogestión radical no ocurre en Toyota, excepto en situaciones de emergencia. Pero incluso en las operaciones diarias, un solo trabajador de producción que ve un problema de calidad, puede detener la línea, y los equipos de proyecto tienen una amplia libertad para aprovechar los recursos, tomar decisiones de compra y perseguir las prioridades que ellos mismos establecieron.

Construyendo Redes Humanas Vibrantes.

Las organizaciones que están sentando las bases para una Colaboración de Alto Rendimiento, deben seguir estos principios:

Implementar Tecnología Colaborativa Generalizada: Manténgalo simple y abierto: "pequeñas piezas unidas sin apretar", es la feliz frase del coautor de Cluetrain Manifiesto David Weinberger. La herramientas deben trabajar juntas a través de estándares y ser lo más compatibles con las del resto del mundo. Piense en opciones, no en integración, adaptabilidad, no en eficiencia estática.
Mantener el Trabajo Visible: A menos que haya una muy buena razón para no hacerlo, deje que todos vean el trabajo real de todos. Deje que las personas aprendan a filtrar y clasificar por sí mismas. No abstraer, resumir o canalizar. El forraje es bueno. Ponlo al alcance de todos.
Construir Comunidades de Confianza: Cuando las personas confían unas en otras, es más probable que colaboren de manera libre y productiva. Cuando las personas confían en sus organizaciones, es más probable que se entreguen ahora en previsión de una recompensa futura. y cuando las organizaciones confían entre sí, es más probable que compartan la propiedad intelectual sin ahogarse en temas legales.
Pensar Modularmente: La reingeniería consistía en pensar de forma lineal (administrar el proceso de extremo a extremo en lugar de funciones discretas). La "modularidad" es lo contrario, vale decir "sacrificar la eficiencia estática por el valor recombinante de las opciones". Piense en equipos modulares además de procesos. Cuanto más fino, mejor.
Fomentar el Trabajo en Equipo: Celebre los sacrificios que hacen los equipos por la empresa en general, incluidos los clientes y proveedores. Desmonte las métricas de rendimiento individualizadas y las recompensas que enfrentan a las personas entre sí. Las transacciones baratas entre muchos alimentan más la innovación que los incentivos caros dirigidos a unos pocos. Recompensa al grupo, y el grupo te recompensará a ti.

Componentes de Infraestructura para este Tipo de Colaboración:

En el corazón de Linux y del Sistema de Producción de Toyota, hay un conjunto de prácticas de trabajo, comunicación y liderazgo que contribuye a una nueva forma de Colaboración también se basa en "dos componentes de infraestructura", vale decir, un conjunto compartido de conocimientos y herramientas universalmente disponibles para mover el conocimiento.

Propiedad Intelectual Común: La Licencia bajo la cual se publica Linux, requiere que todos los distribuidores hagan que su código esté libremente disponible para que otros puedan modificarlo libremente. Este principio viral evita que el código se almacene en productos patentados. Esa transparencia, a su vez, rompe la distinción entre productor y usuario. "Un Cliente" sofisticado como Andrea Barsani es en realidad un Usuario-Desarrollador, que corrige fallas y agrega funciones para su propio beneficio, y luego comparte esas mejoras con todos los demás. Tal función es imposible cuando el código propietario tiene licencia de un proveedor comercial. De manera similar la Cadena de Suministro de Toyota se basa en el principio de que, si bien el conocimiento del producto (como un plano) es propiedad intelectual de alguien, el conocimiento del proceso se comparte. Eso rompe algunas distinciones entre empresas. Los proveedores generalmente son exclusivos de un solo OEM (Original Equipment Maqnufacturer, ó Fabricante de Producto Original), por lo que el beneficio colectivo de esa información compartida permanece dentro de la cadena de suministro de Toyota. Incluso en los Estados Unidos, donde Toyota es solo uno de los varios clientes para la mayoría de las empresas de primer nivel, el fabricante de automóviles hace lo mismo a través de su Asociación de Fabricantes Automotrices Bluegrass, que difunde las mejores prácticas a todos los miembros.

Trabajo Simple y Omnipresente: Aunque la información es el alma de la comunidades Linux y TPS, sus sistemas de circulación son sorprendentemente rudimentarios. Los desarrolladores de Linux producen software de última generación utilizando tecnología de comunicación no más sofisticada que el correo electrónico y los servidores de listas, pero todos usan esa herramienta mundana. De hecho, el valor otorgado a la universidad es tan grande que los correos electrónicos de texto sin formato, en lugar de formateados, son la norma, lo que garantiza que los mensajes aparecerán exactamente iguales para todos los destinatarios. Toyota, cuyos productos también son de última generación, también prefiere una tecnología interna simple y omnipresente. Un contenedor Kanban vacío indica la necesidad de reposición de piezas; un trozo de cinta adhesiva en el piso de la línea de ensamblaje asigna los tiempos de finalización de las tareas en un vehículo en movimiento. Los problemas de control de calidad en la línea de montaje se anuncian a través de buscapersonas y monitores de televisión. Todos reciben la alerta, incluso Ray Tanguay, jefe de Toyota Canadá, es llamado cada vez que se encuentra una falla en el último envío de Lexus en el muelle de Long Beach, California, o en una bahía de servicio en cualquier lugar de América del Norte.

La Confianza y los Aplausos.

Estas Colaboraciones extremadamente ricas y flexibles tienen consecuencias psicológicas positivas para los participantes y poderosas consecuencias competitivas para sus organizaciones. Esas consecuencias son un rico conocimiento común, "la capacidad de organizar equipos modularmente, una motivación extraordinaria y altos niveles de confianza.

Reconocimiento Semántico: Una disciplina de trabajo rigurosa, la propiedad intelectual y el intercambio constante se combinan para distribuir el conocimiento de manera amplia y relativamente uniforme a través de las redes humanas. Ese conocimiento incluye no solo la información formal y semánticamente rico sobre el contenido y el proceso que es la moneda de la colaboración creativa. ¿Qué queremos decir con el brillo de un cuerpo estampado que no tiene suficiente brillo? Este tipo de pregunta sin respuesta fácil, se discute y resuelve continuamente en miles de colaboraciones de equipos pequeños. El pensamiento matizado resultante y el vocabulario común más rico sobre tales asuntos se retroalimentan al conjunto de conocimientos, donde están disponibles para que toda la comunidad los perfeccione.
Equipos Modulares: La modularidad "es un principio de diseño por el cual un proceso o producto complejo se divide en partes simples conectadas por reglas estándar". En arreglos modulares de equipos, cada equipo se enfoca en tareas pequeñas y simples que juntas forman un todo más grande. La modularidad permite que una organización ejecute múltiples experimentos paralelos, haciendo muchas apuestas pequeñas en lugar de algunas grandes. Los proveedores de Toyota se organizaron de esta manera para fabricar "válvulas-P", operando en parte por dirección pero principalmente como voluntarios para hacer lo que cada uno sabía mejor. El grupo de Gentoo, los expertos en seguridad de Tridge, y el círculo de ex alumnos de rsync, de Pool eran módulos preexistentes y superpuestos que mezclaban y combinaban roles según lo requería la emergencia. Así, cuando Philips Evans & Bob Wolf mapearon los "patrones de colaboración" diarios en todo el esfuerzo de desarrollo del kernel de Linux, descubrieron que dichos arreglos modulares son generalizados y, hasta cierto punto, andan unos dentro de otros. Esto crea una especie de "organigrama dinámico", un organigrama que nadie escribió pero que permite que la comunidad se expanda y se adopte sin colapsar en el caos.
Motivación Intrínseca: Las comunidades Linux y TPS disocian el dinero de las transacciones claves. Sin embargo, a pesar de los débiles incentivos financieros, tienen un nivel de motivación superior al que se encuentran en los entornos convencionales. Los psicólogos han descubierto consistentemente que "las zanahorias monetarias y los palos de rendición de cuenta motivan a las personas a realizar tareas limitadas y específicas, pero generalmente desalientan a las personas a ir más allá". "La reputación personal del desarrollador está unida a cada lanzamiento", explica Linus Torvalds al columnista de tecnología Robert Cringely en 1998. "Si está creando algo para regalar al mundo, algo que representa para millones de usuarios su filosofía de la informática, siempre lo convertirás en el mejor producto que puedas". "Las zanahorias monetarias y los garrotes de rendición de cuentas motivan a las personas a realizar tareas limitadas y específicas. La administración y los aplausos son estimulantes muchos más efectivos del comportamiento superior y más allá". Por otro lado, los psicólogos también enfatizan la importancia "motivacional de autonomía". Los programadores de Linux deciden por sí mismos cómo y dónde contribuir, y disfrutan de la satisfacción de producir algo cuya calidad no está definida por un departamento de marketing ni por contadores, sino por sus propios estándares exigentes. Bob Wolf y Karin Lakhan del MIT encuestaron a más de 800 usuarios-desarrolladores, y más de la mitad dijo que su trabajo de código abierto es el esfuerzo más valioso y creativo de su vida profesional. Por su parte, el Sistema de Producción de Toyota no ofrece una autonomía tan extrema, por supuesto, y los empleados no trabajan gratis. Pero en comparación con sus contrapartes en el resto de la industria automotriz, los trabajadores de TPS disfrutan de menos controles, mayor estímulo a la iniciativa individual, menos métricas vinculantes al desempeño individual y más aplausos de sus compañeros. El orgullo profesional y corporativo, no los honorarios de Toyota, fue la recompensa para el equipo de Kyoritsu Sangyo, cuando entregó el primer lote de "válvulas-P". Ese mismo orgullo lo siente un trabajador subalterno de una línea de montaje cuando compañeros confian en él para experimentar con las mejoras del proceso y detener la línea si algo sale mal.
Altos Niveles de Confianza: Cuando la información fluye libremente, la reputación, más que la reciprocidad, se convierte en la base de la confianza. Al operar bajo un escrutinio constante, que es desafiante pero no hostil, los trabajadores saben que su reputación está en riesgo y eso les sirve como garantía de buen comportamiento, el equivalente a contratos en un mercado o auditorías en una jerarquía. De ahí la obsesión en la Comunidad de Linux por reconocer las contribuciones de código e incluir direcciones de correo electrónico personales en los campos de comentarios de Listerys. De ahí el generoso crédito público otorgado a Barisani y Warfield. De ahí la celebración colectiva de los heroicos esfuerzos de Kyoritsu Sangyo. Ahora bien, con una reputación en juego, es menos probable que las personas actúen de manera oportunista. Con la misma información disponible para todos, hay menos posibilidades de que una parte aproveche la ignorancia de otra. Y con un vocabulario y una forma de trabajar comunes, se producen menos malentendidos. Esos factores impulsan la confianza, el capital social fundamental de estas comunidades. La confianza importaría menos si salir de estas redes no tuviera ningún costo o si las transacciones fueran de tamaños radicalmente diferentes (ya que eso tentaría a las personas o empresas a romper las reglas cuando surgiera una gran oportunidad). Pero tanto en la comunidad de Linux como en la de Toyota, la entrada al círculo interno es un privilegio ganado con esfuerzo, y ambas operan en muchos intercambios pequeños. Así, por supuesto, "donde la confianza es la moneda, la reputación es una fuente de poder". En una red dispersa, como la mayoría de los mercados y jerarquías, el poder se deriva del control o intermediación del flujo de información y, por lo tanto, a menudo, de su restricción. Sin embargo, en una red densa, la información simplemente fluye alrededor del posible cuello de botella. En esas circunstancias, hay más poder en ser una fuente de información que un sumidero de información. En consecuencia, "las personas están motivadas para maximizar tanto la visibilidad de su trabajo como sus conexiones con aquellos que están ampliamente conectados". Eso, a su vez, alimenta la densidad de información de la red.

Economías del Trabajo: Transacciones Baratas y Muchas de Ellas.

Hasta ahora hemos estado discutiendo el contenido del trabajo. Pero los modelos TPS y Linux también cambian la Economía del Trabajo, al reducir los costos de transacción. Los bajos costos de transacción hacen que sea rentable para las organizaciones realizar más y más pequeñas transacciones, tanto internas como externas, y así aumentar el ritmo y la flexibilidad típicos de las organizaciones de alto rendimiento.

Explotación del 80% Desatendido: El famoso Principio de Pareto, dicta que "las empresas obtienen el 80% de su valor de solo el 20% de sus productos, clientes o ideas". Debido a los altos costos de transacción, la cola larga de esa curva, ese 80% de generadores de valor incierto, no se puede explorar. Entonces, en nombre del enfoque de la empresa, la cola se corta, se segmenta o se re-diseña para que no exista. Las Innovaciones potencialmente rentables mueren con él. Por otra parte, las "organizaciones que reducen los costos de transacción" pueden acoger al 80% rechazado. Pueden responder a señales de mercado débiles, aprovechar pequeños segmentos y experimentar con combinaciones de tecnología poco probables. Pueden hacer cien apuestas pequeñas en lugar de algunas grandes. Por ejemplo:

"Detroit consideraba que los vehículos híbridos eran un producto intermedio sin interés: los ejecutivos automotrices de Estados Unidos preferían la investigación hasta ahora incompleta sobre la tecnología de celdas de combustible. Mientras tanto, Toyota estaba construyendo el Prius. El híbrido está ahora en su segunda generación y Toyota esperaba vender 300.000 en todo el mundo ese año (2005). Los bajos costos de transacción y la inclinación de Toyota por colaboraciones a pequeña escala, lo ayudaron a mantener abiertas 80 opciones discretas para el motor híbrido hasta solo seis meses antes de entregar un diseño final. Los fabricantes de automóviles convencionales habrían tenido que congelar estas variables de diseño al manos dos años antes.

Es en los intersticios de la red humana, en lugar de en las mentes de unos pocos niños prodigio, donde hacen la mayoría de las innovaciones reales. Así, son los costos de transacción los que restringen la Innovación al restringir las oportunidades de compartir ideas, habilidades y prejuicios diferentes y conflictivos.

"La gente de Detroit tiene mucho más talento que la gente de Toyota", sostiene el presidente de Toyota Fujio Cho, con excesiva modestia. "Pero tomamos personas medianamente talentosas y las hacemos trabajar como equipos espectaculares". La red, en otras palabras, es el Innovador.

Las fuentes clásicas de costos de transacción son "la vulnerabilidad mutua frente a la incertidumbre, los intereses en conflicto y el acceso desigual a la información". Gastamos efectivo en negociación, supervisión y restitución para reducir esas imperfecciones. Tanto los mercados como las jerarquías incurren en costos de transacción (aunque las jerarquías existen para economizarlos, como han argumentado Ronald Case y Oliver Williamson). Se estima que en el año 2000, los costos de transacción en efectivo por sí solos representaron más de la mitad del PIB no gubernamental de Estados Unidos. Gastaron más dinero negociando y haciendo cumplir las transacciones que cumpliéndolas.

En las comunidades de Toyota y Linux, los acuerdos se hacen cumplir no por la sanción de un contrato legal, ni por la autoridad de un jefe, sino "por la confianza mutua, lo que reduce drásticamente los costos de transacción". Esto no es nuevo, equipos de personas en todas partes en el lugar de trabajo convencional operan sobre la base de la confianza.

Lo que es nuevo es "cuán ampliamente se puede extender la confianza, incluso a personas que no se conocen entre sí, o incluso entre aquellas que tienen intereses contrapuestos". Asin confió a sus proveedores rivales planos de la válvula-P. Los piratas informáticos de rsync intercambiaron información confidencial con personas que nunca habían conocido. Los proveedores de componentes de Toyota comparten diariamente el conocimiento del proceso, confiando en que Toyota no lo utilizará para bajar los precios. Los piratas informáticos de Linux confían unos en otros para realizar enmiendas descortinadas y simultáneas en el código base.

Además, tener propiedad en común -como ciertos tipos de Propiedad Intelectual se tienen dentro de estas comunidades- reduce las apuestas monetarias entre los copropietarios. Los costos de transacción caen porque simplemente hay manos para negociar. En la comunidad de Linux, los costos de transacción se aproximan a cero. Hewlett-Packard le pagó a Martin Pool para que fuera un ingeniero de Linux, pero de eso no se deduce que HP tuviera que pagar en el margen por los trabajos nocturnos de Pool en rsync. En la comunidad de Toyota, los costos de transacción, si bien no son cero, se han reducido radicalmente. Cuando se destruyó la planta de Asin Selki, Toyota y sus proveedores no se demandaron entre sí, ni improvisaron contratos de suministro de emergencia. Simplemente continuaron entre sí, confiando en que eventualmente se haría una restitución justa. Jeffrey Dyer, profesor de Estrategia de la Universidad de Bringham Young, estima que "los costos de transacción entre Toyota y sus proveedores de primer nivel son solo una octava parte de los de General Motor", una disparidad que atribuye a los diferentes niveles de confianza.

Algunas Palabras al Cierre.

Philips Evans & Bob Wolf sostienen que "si reúnes todos estos elementos, tendrás un círculo virtuoso. Una red densa y autorganizada crea las condiciones para una confianza a gran escala. La confianza a gran escala reduce los costos de transacción. Los bajos costos de transacción, a su vez, permiten muchas transacciones pequeñas que crean una red autorganizada que se profundiza de forma acumulativa".

Una vez que "el sistema alcanza la masa crítica, se retroalimenta. Cuando más grande es el sistema, más ampliamente se comparte el conocimiento, el idioma y el estilo de trabajo. Cuando mayor es el Capital Reputacional de los individuos, más fuertes son los aplausos y más fuerte la motivación. El éxito de Linux es evidencia del poder de ese círculo virtuoso. El éxito de Toyota es evidencia de que también es poderoso en las empresas convencionales que maximizan las ganancias".

La Comunidad de Linux y el Sistema de Producción de Toyota son sorprendentemente diferentes. El hecho de que logren tanto de maneras tan similares, apunta a algunos principios que ustedes pueden seguir:

La Disciplina de la ciencia es sorprendentemente adaptable a la organización del trabajo, e incluso interoperativo.
En algunas circunstancias, la confianza es un sustituto viable de los contratos de mercado y la autoridad jerárquica, no sólo en equipos pequeños sino también en comunidades muy grandes.
En las cadenas de suministro, las organizaciones que pueden sustituir la confianza por contratos, obtienen más de la Colaboración de lo que pierden en poder de negociación.
Los bajos costos de transacción compran más Innovación que los altos incentivos monetarios.

Estos principios satisfacen la necesidad de crecimiento e Innovación de las empresas de formas que los modelos organizacionales tradicionales no lo hacen. Tal vez la eficiencia de estas Colaboraciones sugiera el surgimiento final de algo completamente nuevo: No Mercados, No Jerarquía. Pero una poderosa combinación de ambos y una firma de la sociedad en red.

(Nota: Para aquellos estudiantes del curso, vuelvan al curso y sigan las instrucciones para asimilar el conocimiento entregado.

Fuente: "Collaboration Rules", Phillip Evans & Bob Wolf, Harvard Business Review.