Trabajo de conocimiento ajustado

Resumen.

Reimpresión: R1110G

Muchas empresas manufactureras y algunas empresas de servicios han cosechado beneficios considerables al aplicar variaciones del Sistema de Producción Toyota, un método para hacer que las operaciones sean «ajustadas» mediante esfuerzos incansables para aumentar la calidad y la eficiencia y eliminar el desperdicio.

Pero la sabiduría convencional sostiene que los principios lean no se prestan al trabajo del conocimiento, lo que implica juicio y experiencia, no el tipo de tareas repetitivas y fácilmente especificadas que se encuentran en una línea de montaje. La investigación de los autores, que incluye estudios plurianuales de unos 1.800 proyectos del gigante indio de servicios de IT Wipro, desafía esta idea. Trabajo de conocimiento lata se lean, argumentan Staats y Upton, si los gerentes se basan en seis principios:

• Desenraiza continuamente todos los residuos.
• Esfuérzate por hacer explícito el conocimiento tácito.
• Especifique cómo deben comunicarse los trabajadores.
• Utiliza el método científico para resolver problemas rápidamente.
• Reconozca que un sistema lean siempre será un trabajo en progreso.
• Que los líderes marque el camino.

La aplicación de estos principios exige una inversión sostenida y una reinvención popular de cómo se realiza el trabajo. Pero los beneficios son considerables: productividad y satisfacción laboral cada vez mayores, y un sistema que será difícil de replicar para los competidores.

El sistema de producción Toyota es posiblemente el invento más importante en operaciones desde que el Model T de Henry Ford comenzó a salir de la línea de producción. Ha generado numerosos enfoques para mejorar las operaciones, todos basados en los mismos principios: atención incesante a los detalles, compromiso con la experimentación basada en datos y carga a los trabajadores de la tarea continua de aumentar la eficiencia y eliminar el desperdicio en sus trabajos. Esta colección de ideas a menudo se denomina «esbelta». Hoy en día, la mayoría de las empresas manufactureras y algunas firmas de servicios cosechan sus

Sin embargo, los intentos de aplicar enfoques ajustados al trabajo del conocimiento han resultado frustrantemente difíciles. La mayoría en el mundo empresarial cree que el trabajo del conocimiento no se presta a principios lean, porque, a diferencia del montaje de automóviles, no es repetitivo y no se puede definir de forma inequívoca. Considere la posibilidad de que un funcionario bancario decida si concede un préstamo, que un ingeniero desarrolle un nuevo producto y que un trabajador social decida si el entorno de un niño es seguro: en cada caso, el trabajo implica experiencia y juicio que dependen en gran medida del conocimiento tácito, conocimiento encerrado en la cabeza del trabajador.

Sin embargo, nuestra investigación en IT, finanzas, ingeniería y servicios legales revela que este tipo de trabajo puede beneficiarse de los principios del Sistema de Producción Toyota. Por un lado, una cantidad sustancial de conocimiento que se supone que es tácito no tiene por qué serlo; se puede articular y capturar por escrito si la organización hace el esfuerzo de sacarlo de la cabeza de la gente. Por otro lado, todo el trabajo de conocimiento incluye algunas actividades que no tienen nada que ver con la aplicación del juicio y que pueden simplificarse capacitando a los empleados para que encuentren y eliminen continuamente el desperdicio. Incluso cuando el conocimiento es realmente tácito, la creación de sistemas y reglas para guiar las interacciones de los trabajadores puede dar lugar a una colaboración más eficaz.

En la fabricación, existe un entendimiento común de cómo hacer que una operación sea ágil, y muchas de las mismas técnicas se pueden emplear en diferentes organizaciones. Este no es el caso del trabajo del conocimiento. Sin embargo, hemos descubierto que los principios lean pueden aplicarse de alguna forma a casi todos los tipos de trabajo de conocimiento y pueden generar beneficios significativos: tiempo de respuesta más rápido, mayor calidad y creatividad, menores costos, menos trabajo pesado y frustración, y mayor satisfacción en el trabajo.

El viaje Lean de Wipro

Nuestro estudio más extenso sobre la aplicación de los principios lean al trabajo del conocimiento implica una ambiciosa iniciativa de Wipro Technologies. Con sede en Bangalore, India, Wipro es una de las mayores empresas de servicios de IT e ingeniería de productos del mundo. Cuenta con más de 100.000 empleados y 72 centros de entrega en 55 países.

Las operaciones que hemos estado estudiando crean software personalizado complejo. No se parecen en nada a una línea de montaje. Los proyectos se asignan a equipos cuyos miembros se eligen en función de las habilidades necesarias para abordar las tareas, que van desde el diseño de software que controla un decodificador digital hasta la creación de nuevas plataformas de comercio electrónico. Así como un equipo de abogados que trabajan en un caso importante suele incluir miembros con una amplia gama de conocimientos, un equipo de software Wipro está formado por personas con una experiencia muy variada. Algunos son bastante experimentados, otros recién están empezando; algunos tienen habilidades especializadas, otros son generalistas; algunos proporcionan una supervisión y apoyo amplios, otros hacen el trabajo real. Al hacer rebotar ideas entre sí y probar cosas, se les ocurren soluciones.

Varios desafíos llevaron a Wipro a embarcarse en su viaje de lean, en 2004. Su necesidad de empleados altamente cualificados aumentaba justo cuando la rotación aumentaba debido a la fuerte demanda de la industria. Los días en que la empresa podía competir sobre la base de los bajos costos laborales habían terminado. Tampoco podía seguir compitiendo en calidad superior; sus principales rivales se habían puesto al día. En busca de una ventaja sostenible, los líderes de Wipro decidieron crear un sistema ajustado. Aunque reconocieron que este enfoque no estaba probado en el trabajo del conocimiento y que requeriría una profunda transformación de la empresa, creían que valía la pena arriesgarse a la rentabilidad potencial (la capacidad de mejorar más rápido que sus competidores).

Los gerentes de Wipro no pudieron encontrar empresas que hubieran utilizado técnicas ajustadas para producir software personalizado a gran escala. Y descubrieron que incluso las principales consultorías de estrategia carecían de experiencia relevante. Así que Sambuddha Deb, el gerente sénior a cargo de las operaciones, reunió a otros nueve gerentes de Wipro. El grupo se reunió en torno a una mesa de conferencias y formuló una pregunta sencilla: «¿Cómo lo hacemos?» Su respuesta: «Vamos a educarnos a nosotros mismos. Propondremos nuestras propias ideas para adaptar lean a una operación de software a gran escala y luego las probaremos».

Los gerentes comenzaron a estudiar cómo se había aplicado el enfoque lean en la fabricación. Estudiaron todo el material escrito que pudieron encontrar, recorrieron fábricas esbeltas y conversaron con un ex gurú de Toyota. Luego hicieron una lluvia de ideas sobre cómo usar lo que habían aprendido; cada uno eligió un proyecto existente para poner a prueba sus ideas. Poco a poco, identificaron prácticas que funcionaban.

Hemos estudiado este esfuerzo desde el principio. Analizamos los resultados de 1.883 proyectos Wipro que implicaban ingeniería de productos compleja o la entrega de soluciones informáticas. De esos proyectos, 772 utilizaron un enfoque ajustado y 1,111 no. También observamos muchos de ellos a medida que se llevaban a cabo.

Hacer que una operación sea ágil es un viaje de muchos años, no un gran esfuerzo. Sin embargo, descubrimos que el enfoque lean ya está teniendo un impacto significativo. Los proyectos lean que estudiamos no funcionaron mejor que otros en cuanto a medidas de calidad (defectos y errores), quizás porque los estándares ya eran altos. Pero produjeron resultados superiores en términos de tiempo y costo. En promedio, los proyectos lean se completaron en un 5% menos de lo previsto; los demás proyectos suelen terminar en el momento previsto. Y los proyectos lean quedaron un 9% por debajo del presupuesto; los demás estaban un 2% por debajo del presupuesto. (Para obtener más detalles sobre los resultados, consulte «Principios ajustados, aprendizaje y trabajo del conocimiento: evidencia de un proveedor de servicios de software», por Bradley R. Staats, David James Brunner y David M. Upton, Revista de Gestión de Operaciones, Julio de 2011.)

Basándonos en nuestra investigación en Wipro, redactamos algunos principios para hacer que las operaciones de conocimiento sean más eficientes. Perfeccionamos nuestras ideas después de revisar la literatura sobre fabricación ajustada (para un artículo particularmente útil, véase «Decodificación del ADN del sistema de producción Toyota», de Steven J. Spear y H. Kent Bowen, HBR de septiembre a octubre de 1999) y de estudiar los esfuerzos ajustados en otros entornos de trabajo del conocimiento. Al final se nos ocurrieron seis principios, que describiremos en detalle a continuación. Al usarlos, los gerentes pueden crear los enfoques ajustados personalizados que mejor se adapten a sus organizaciones.

Elimine los residuos

Taiichi Ohno, el principal arquitecto del sistema Toyota, dijo que había «siete desperdicios» que todos en una operación de fabricación deberían esforzarse por eliminar: sobreproducción; transporte innecesario, inventario y movimiento de los trabajadores; defectos; sobreprocesamiento; y espera. Los sitios de trabajo de conocimiento típicos están cargados con estos desechos. De hecho, el trabajo del conocimiento incluye muchas actividades rutinarias que no implican juicio ni experiencia y que pueden consumir enormes cantidades de tiempo: imprimir documentos, solicitar la información necesaria para tomar una decisión y organizar reuniones, por nombrar solo algunas.

Hemos descubierto que los trabajadores del conocimiento tienden a subestimar en gran medida la cantidad de ineficiencia que podría erradicarse de sus puestos de trabajo. La clave es lograr que todos los miembros de la organización hagan visibles sistemáticamente los residuos y hagan algo al respecto. He aquí cómo alistar a las personas en la causa:

Enseñe a todos a preguntar «los cinco porqués».

El desperdicio puede ser obvio una vez que se ha señalado, pero encontrarlo en primer lugar no siempre es fácil, porque por lo general ha formado parte del paisaje durante mucho tiempo. El remedio: en lugar de asumir que el enfoque utilizado para un proceso es correcto, supongamos que es incorrecto. Con este fin, los gerentes de Toyota idearon «los cinco porqués», un proceso de hacer preguntas continuamente hasta llegar a la raíz de cada actividad realizada. ¿Por qué voy a asistir a esta reunión? ¿Por qué estoy rellenando este informe? ¿Por qué estoy parado frente a la imprenta?

Cuando un equipo de Wipro cuyo proyecto estaba atrasado realizó este ejercicio, descubrió, en primer lugar, que sus miembros estaban resolviendo los mismos problemas una y otra vez. Otras preguntas revelaron un problema mayor: el equipo estaba tan ocupado tratando de mantenerse al día con su trabajo que descuidaba la creación de soluciones estándar y la formación de personas. Esto significaba que pocos miembros tenían la experiencia necesaria para manejar una variedad de problemas. En respuesta, el equipo reestructuró el proyecto siguiendo líneas funcionales, asignó a los individuos como líderes principales y de respaldo de cada función, y los hizo responsables de crear soluciones estándar y capacitar a los demás miembros del equipo. Las personas rotaron en una función diferente cada trimestre para asegurarse de que todos adquirieran habilidades amplias. Aunque inicialmente estas medidas aumentaron el tiempo necesario para realizar el trabajo, pronto el equipo pudo acelerar y entregó su proyecto a tiempo.

Anime a todos a buscar formas pequeñas de desperdicio, no solo grandes.

La mayoría de las empresas exitosas ya han eliminado grandes y obvias formas de desperdicio, pero los pisos de las operaciones de conocimiento suelen estar plagados de monedas de cinco centavos que nadie se ha molestado en recoger. Piensa en tu propio lugar de trabajo. ¿Cuántos correos electrónicos abarrotan tu bandeja de entrada porque alguien te envió una copia innecesariamente? ¿Cuánto tiempo tuvo que esperar para iniciar una reunión programada regularmente porque los asistentes se acercaron lentamente? ¿Cuántos informes se crean que nadie lee?

Para identificar y eliminar continuamente el desperdicio, una organización debe aprender a preocuparse por las cosas pequeñas. Esto significa ayudar a las personas a ver cuánto desperdicio les rodea y reconocer que eliminarlos los liberará para hacer un trabajo más valioso (y más gratificante). Significa aplicar los cinco porqués a todo. Y significa dedicar tiempo y otros recursos a eliminar el desperdicio.

Un equipo de proyecto que observamos al principio de la transición de Wipro sabía que necesitaba identificar pequeñas fuentes de residuos, pero no estaba seguro de cómo hacerlo. Decidió utilizar un mapa de flujo de valor para poner en marcha el proceso. Un mapa de flujo de valor no solo captura las etapas detalladas e individuales de un proyecto en curso, sino que también identifica el valor añadido y el desperdicio. Un equipo debe hacer un seguimiento de cada paso que da y preguntar: «¿Por qué hicimos eso?» Esto le permite crear una lista priorizada de elementos que se pueden eliminar.

El equipo que estudiamos desarrollaba controladores de impresora, un software que controla las impresoras. A medida que los miembros escribían código, necesitaban probar el código en una impresora. El mapeo del flujo de valor puso de relieve varias formas de desperdicio. Por ejemplo, cuatro personas que usaban la misma impresora a menudo se encontraban de pie alrededor de la máquina mientras imprimían los trabajos de los demás. El cambio frecuente entre los usuarios también significaba que pasaban mucho tiempo ajustando la configuración de la impresora según sus necesidades particulares. Y como la impresora estaba en un piso diferente, subían y bajaban constantemente las escaleras, un viaje de ida y vuelta de cinco a diez minutos.

Tras identificar estas formas de desperdicio, el equipo encontró espacio para la impresora en su propia planta y designó franjas horarias para cada usuario. Estos y muchos otros pequeños cambios le permitieron dedicar mucho más tiempo al trabajo real.

Revisar periódicamente la estructura y el contenido de cada trabajo.

Muchos trabajos de conocimiento no están estructurados y son amplios. Tienden a expandirse gradualmente a medida que se añade una actividad tras otra. La gente puede terminar con demasiado trabajo y dedicar demasiado tiempo a tareas de poco valor.

Los gerentes deben evaluar periódicamente las tareas de sus empleados, incluido el tiempo que se dedica a cada una de ellas. Una organización de desarrollo de productos que llevó a cabo una revisión de este tipo descubrió que el desorden de tareas, la priorización inadecuada de las asignaciones y la falta de comprensión de lo que constituía una carga de trabajo completa habían creado una situación en la que sus ingenieros normalmente tenían el doble de trabajo del que podían realizar de manera realista. Esto provocaba cuellos de botella significativos, cambios excesivos entre tareas, incumplimiento de plazos y desgaste del personal. Por lo tanto, la empresa redujo la carga de trabajo de los ingenieros para que el compromiso de nadie superara el 100% de su capacidad. Esto significaba que no todo el trabajo que se había planeado podía programarse y los gerentes tenían que tomar decisiones difíciles. Sin embargo, la productividad y la satisfacción de los empleados aumentaron.

Especificar el trabajo

La práctica de escribir exactamente cómo realizar una tarea (definir claramente la sustancia, el orden, el momento y el resultado deseado) ha aportado un valor significativo a los fabricantes. Permite comparar los resultados reales y esperados. Si los dos no coinciden, la organización sabe que hay un problema con el cumplimiento del proceso o del proceso en sí y puede tomar medidas para solucionarlo.

A primera vista, este enfoque puede no parecer relevante para las operaciones de conocimiento. Muchos de los procesos de las operaciones de conocimiento se desarrollan dentro de la cabeza de un empleado; pueden ser invisibles para los demás y difíciles de articular en pasos concretos y replicables. Un banquero de inversión, por ejemplo, puede no ser capaz de explicar fácilmente cómo persuadió a alguien para que aceptara un trato.

Lecturas adicionales de HBR

«Decodificación del ADN del sistema de producción Toyota», de Steven J. Spear y H. Kent Bowen (septiembre-octubre de 1999)

«La atención médica en primera línea» de Richard M.J. Bohmer (abril de 2010)

«Arreglando la atención médica desde dentro, hoy» de Steven J. Spear (septiembre de 2005)

«Aprender a liderar en Toyota», de Steven J. Spear (mayo de 2004)

«La máquina de servicio ajustado» de Cynthia Karen Swank (octubre de 2003)

«Más allá de Toyota: cómo erradicar el desperdicio y perseguir la perfección» de James P. Womack y Daniel T. Jones (septiembre-octubre de 1996)

«De la producción ajustada a la empresa ajustada» de James P. Womack y Daniel T. Jones (marzo-abril de 1994)

Además, el trabajo en una operación de conocimiento puede cambiar rápidamente y, en cualquier día, la gente puede realizar una combinación de tareas, algunas que requieren juicio o intuición, y otras que podrían reducirse a un protocolo porque el problema y las mejores formas de abordarlo se comprenden bien. Precisamente porque las personas suelen realizar ambos tipos de trabajo, ellas y sus organizaciones asumen que muchas tareas que podrían estandarizarse no pueden serlo.

A pesar de los desafíos, se puede especificar una cantidad sorprendentemente grande de trabajo de conocimiento. Y una vez que ha sido así, se puede mejorar continuamente. La clave es desafiar la suposición de que todo conocimiento es intrínsecamente tácito. Una empresa de fabricación que conocemos tenía un programador experimentado que asignaba el trabajo en toda la fábrica. Los líderes de la compañía, queriendo mejorar el proceso de programación, pidieron a un alto directivo que lo entrevistara. Inicialmente respondió a las preguntas del gerente con vagas generalidades. Pero cuando el gerente persistió, pidiéndole que explicara por qué tomó una decisión en lugar de otra, comenzó a dar respuestas concretas y detalladas. El gerente descubrió gradualmente las reglas implícitas que usaba el planificador. Luego, la empresa ajustó las reglas y el rendimiento subió.

La especificación del trabajo de conocimiento implica cuatro pasos:

Busque partes repetibles del proceso y codifíquelas.

Casi todas las áreas de trabajo del conocimiento tienen más puntos en común de lo que parece a simple vista. En Wipro, a los equipos les resultó difícil especificar el proceso general de escritura de código, porque a menudo implicaba soluciones novedosas que se usaban en algún momento. Pero cuando reformularon la pregunta para preguntar «¿Qué hacemos repetidamente?» se dieron cuenta de que muchos aspectos del proceso, como la revisión por pares, las compilaciones diarias (la integración de todos los fragmentos de código escritos ese día en el programa), las pruebas y las revisiones de los clientes, ocurrían con frecuencia dentro de un proyecto y en todos los proyectos, y que podían estandarizarse.

No intentes especificarlo todo inicialmente, si es que alguna vez.

Algunas tareas ocurren tan raramente que la inversión necesaria para especificarlas no merece la pena. Y a veces un problema se entiende tan mal que un experto debe aconsejarle sobre la mejor manera de abordarlo. Sin embargo, incluso en estos casos se pueden especificar partes del proceso.

Un banco japonés que quería hacer crecer su negocio de hipotecas hipotecarias descubrió que contratar analistas de crédito expertos para respaldar el crecimiento deseado sería costoso y difícil. Pero los gerentes reconocieron que, al estudiar detenidamente las decisiones de préstamos anteriores, podían derivar las reglas utilizadas para elaborarlas e integrarlas en un sistema de IT. El sistema no eliminó por completo la necesidad de expertos, que tenían que tomar decisiones en casos que eran inusualmente complejos o involucraban factores especiales. Sin embargo, la gran mayoría de los casos podrían manejarse automáticamente, lo que permite a la empresa hacer crecer su negocio hipotecario de forma rápida y segura.

Usa los datos para conseguir la aceptación.

Una ventaja importante de especificar procesos repetibles es que los trabajadores del conocimiento se liberan para centrarse en las partes del trabajo en las que pueden crear más valor. Sin embargo, muchos profesionales altamente capacitados no creen que su trabajo pueda ser explícito. Por ejemplo, aunque especificar el trabajo puede mejorar los resultados en medicina, los médicos a menudo se resisten enérgicamente, argumentando que su criterio y experiencia no pueden reducirse a un conjunto de reglas. (Consulte la barra lateral «Lectura adicional de HBR» para ver artículos sobre este tema escritos por Richard Bohmer y Steven Spear).

Dado que la especificación satisfactoria del trabajo a menudo depende de la participación de los trabajadores, superar esa resistencia es crucial. Demostrando la eficacia del proceso es clave para superar esta resistencia. Wipro lo reconoció desde el principio y comenzó a hacer un seguimiento de dónde y cómo la especificación de tareas estaba aumentando el rendimiento. Rápidamente se dio cuenta de que la especificación era especialmente beneficiosa para los proyectos que se retrasaban. Los gerentes pudieron utilizar los datos de las mejoras de estos proyectos para ganarse a otras partes de la organización.

Sigue estudiando el trabajo que ha sido designado como tácito.

Aunque hoy no se especifique el trabajo, eso no significa que no pueda ser mañana. Lo que actualmente es un acontecimiento poco común puede ocurrir con frecuencia en el futuro. Y la comprensión de problemas complicados puede crecer con el tiempo. En «Fijación de la atención médica en primera línea» (HBR abril de 2010), Richard M.J. Bohmer describe cómo Intermountain Healthcare, una empresa que opera en Utah e Idaho, destaca por mejorar regularmente los protocolos para el tratamiento de enfermedades. Un enfoque que emplea es permitir que los médicos anulen los protocolos en situaciones ambiguas. Recopila y analiza los datos de las anulaciones y utiliza los conocimientos de las correctas para mejorar el protocolo. Si una anulación produce malos resultados, la empresa utiliza los datos para persuadir a los médicos de que se atengan a la rutina con más frecuencia. Intermountain incluso ha creado una unidad para poner a prueba las ideas y corazonadas de los médicos. Una prueba permitió mejorar los criterios para trasladar a los pacientes de los pabellones a cuidados intensivos.

Especificar el trabajo de la manera sistemática que hemos descrito permite que una organización del conocimiento participe continuamente en el aprendizaje disciplinado. Este esfuerzo exige a menudo recursos dedicados. Wipro creó una oficina de productividad para realizar un seguimiento de las mejores prácticas, investigar nuevas ideas, ayudar a los esfuerzos educativos y ayudar a diseñar procedimientos estándar prácticos que pudieran utilizarse en diferentes equipos.

Comunicaciones de estructura

Al reconocer que muchos problemas son demasiado grandes o complejos para que una sola persona los aborde, las organizaciones utilizan cada vez más los equipos para realizar trabajos de conocimiento. Sin embargo, una vez que varias personas participan en un proceso, la comunicación eficaz se vuelve imprescindible, especialmente porque los equipos pueden tener miembros en todo el mundo. Un sistema lean puede promover una buena comunicación articulando las formas en que debe llevarse a cabo. He aquí cómo:

Defina quién debe comunicarse, con qué frecuencia y qué.

Los trabajadores del conocimiento deben entender quién utilizará su producción. Cuando el proveedor de la obra está en contacto directo con el «cliente» (normalmente alguien del mismo equipo), ambos pueden colaborar para garantizar que el resultado funcione según lo esperado. Si la comunicación frecuente genera un flujo abundante de información, los problemas pueden detectarse y solucionarse desde el principio. Y cuando se detalla el contenido deseado de la comunicación, las personas obtienen la información que necesitan y no tienen que perder el tiempo tratando de entender lo que dicen los demás.

Una herramienta que Wipro adoptó para ayudar a las comunicaciones fue la matriz de estructura de diseño. En un DSM, las tareas de un proyecto se enumeran a lo largo de las filas y columnas de una matriz, y el equipo marca si cada elemento está relacionado con los demás, designando cada relación como una dependencia directa o un ciclo de retroalimentación. El álgebra matricial puede crear un orden recomendado para las tareas. (Para obtener más información sobre el DSM, consulte «¿Sus ingenieros hablan entre sí cuando deberían?» de Manuel E. Sosa, Steven D. Eppinger y Craig M. Rowles, HBR noviembre de 2007.) Las matemáticas son algo complicadas, pero Wipro utilizó una versión simplificada de hoja de cálculo que cualquier equipo podía entender. Con solo pulsar un botón, el programa clasificó las tareas e identificó qué miembros del equipo necesitaban interactuar sobre cada una de ellas y cuándo.

Crea un entendimiento compartido.

Los miembros de los equipos de conocimiento trabajan cada vez más allá de los límites geográficos, culturales, lingüísticos y funcionales. Esto significa que es posible que no tengan la misma idea de lo que se comunica; las mismas palabras pueden tener significados diferentes para diferentes personas. Considere las interacciones entre las personas de una empresa estadounidense y su proveedor indio de servicios de IT. Un intercambio que documentamos incluía una pregunta aparentemente sencilla: «¿Puedes terminar el trabajo dentro de un plazo determinado?» Para la gente de la compañía estadounidense, sí significaba sí y no significaba no, y si algo salía mal, podrían gritar y golpear la mesa. Por el contrario, los indios solían decir no tan indirectamente que sus homólogos estadounidenses oyeron que sí. Y cuando los indios plantearon problemas, los enmarcaron como preguntas de redacción suave, que fueron ignoradas en gran medida por los trabajadores estadounidenses, que no estaban acostumbrados a tales sutilezas. Aunque la comunicación entre los dos grupos estaba estructurada (había actualizaciones periódicas entre las partes designadas, centradas en los puntos de discusión establecidos), los mensajes no se transmitían. La empresa estadounidense se dio cuenta de que cada vez que entabla una nueva relación con el proveedor, necesitaba especificar exactamente cómo debía comunicarse el proveedor.

La necesidad de estructurar las comunicaciones y construir un entendimiento compartido también fue evidente en una revista que conocemos. Un editor puede adquirir un artículo largo de un autor externo y entregarlo a un colega para que lo edite. La tarea de convertir estas contribuciones en artículos de alta calidad a tiempo era a menudo desafiante y estresante. La dirección reconoció el dilema pero pensó que era ineludible: creía que las entregas eran intrínsecamente difíciles porque la edición implica un conocimiento tácito del tema y cómo expresar las ideas, y no hay dos editores que aborden una pieza de la misma manera.

Estas cosas eran ciertas, pero parte del problema era que no había un proceso específico para que los dos editores se comunicaran sobre el propósito del artículo y cómo lograrlo. A menudo no hablaban en absoluto. Incluso cuando lo hacían, las conversaciones no estaban estructuradas. Los dos podrían tener ideas muy diferentes sobre el borrador y el trabajo necesario antes de que pudiera publicarse, y no había medios formales para conciliar puntos de vista opuestos.

La revista tenía un proceso específico para presentar propuestas de artículos: se suponía que cada una debía incluir una descripción escrita del valor de la pieza y un plan de edición. Pero a menudo la propuesta se basaba en la descripción del autor de un artículo previsto, y el borrador que finalmente llegó podría apartarse significativamente de la propuesta. Y a veces un editor que lo adquiere eludiría el proceso presentando una propuesta al editor jefe en una presentación oral.

Un enfoque más eficaz habría estipulado, en primer lugar, que cada editor presentara una propuesta por escrito, de modo que las razones para publicar el artículo —el valor que daría a los lectores— quedarían en el registro. Una vez recibido el borrador completo del artículo, tanto el adquirente como el editor asignado tendrían que redactar una crítica detallada y un plan de edición. (Esto último podría incluir la estructura y la longitud, la necesidad de contenido adicional, el uso de ejemplos y una estimación del tiempo necesario para completar el trabajo). El último paso sería una conversación estructurada facilitada por un editor de alto nivel, durante la cual los tres llegarían a un acuerdo sobre estos temas.

Con comunicaciones bien especificadas, las personas entienden el trabajo que están realizando. Esto les permite dedicar tiempo a resolver problemas en lugar de tratar de averiguar el trabajo que tienen entre manos.

Resolver los desacuerdos con hechos, no con opiniones.

Una larga línea de investigación destaca las formas en que las emociones y la irracionalidad pueden distorsionar el proceso de toma de decisiones. Esto puede ser un problema especialmente importante cuando el trabajo implica conocimiento tácito, porque a menudo no está claro cómo un experto llegó a una decisión concreta y hasta qué punto esa decisión se basó en la intuición o la emoción frente a los hechos.

Uno de los proyectos lean de Wipro ilustra el desafío y el beneficio de una comunicación inequívoca dentro de un equipo. El equipo en cuestión había implementado un sistema de revisiones programadas regularmente en el que los miembros más experimentados evaluaban el código de software escrito por sus colegas menos experimentados. El revisor de cada miembro junior era diferente cada vez. El propósito era sobresalir en la búsqueda y corrección de diferentes tipos de errores, ayudar a las personas menos experimentadas a mejorar y permitir que los miembros del equipo se conocieran unos a otros. Lamentablemente, los revisores sénior utilizaron estándares diferentes y comunicaron las evaluaciones de manera diferente. Lo que era bueno escribir código en uno podría ser un error para otro. Incluso cuando los revisores estaban de acuerdo en lo que constituía un error, a menudo lo llamaban cosas diferentes. La falta de normas comunes y de comunicación perjudica la moral de los empleados junior.

Uno de los revisores detectó el problema y convocó al equipo para discutirlo. El grupo reconoció que tenía la oportunidad de estandarizar las comunicaciones así como el trabajo principal. Algunos de los miembros sénior elaboraron una lista de errores comunes y sus definiciones, para que la usaran todos los revisores. El ejercicio llevó al equipo a darse cuenta de que muchos errores que habían considerado errores difusos (cuestiones relacionadas con aspectos tales como cómo se definían las variables y cómo se incorporaban las explicaciones en el código) eran en realidad bastante concretos. Y una vez que se hayan explicado estas cosas, los errores podrían corregirse sistemáticamente.

El lenguaje del equipo pronto se hizo tan preciso que incluso una máquina podía entenderlo: el programa de redacción de códigos podía evaluar automáticamente si los miembros habían seguido las pautas y levantaría una bandera roja si no lo habían hecho.

Al final, el equipo pasó menos tiempo luchando por lo que era un error y más tiempo trabajando para evitar errores en primer lugar. Como resultado, la incidencia de errores disminuyó drásticamente.

Abordar problemas de forma rápida y directa

Uno de los objetivos fundamentales del sistema de producción Toyota es convertir una operación en un motor para resolver problemas. El núcleo de ese motor es el método científico: articular una hipótesis explícita y mensurable sobre cómo podría mejorarse algún aspecto del trabajo, realizar una prueba objetiva de la hipótesis y, si los datos apoyan la hipótesis, convertir el enfoque en el estándar. Pero hay mucho más que eso. He aquí cómo adaptar el método científico en un entorno de conocimiento:

Si surge un problema, lo ideal es que la persona que lo creó lo solucione.

Los problemas pueden surgir porque el proceso de trabajo es defectuoso o porque el trabajador ha cometido un error. En cualquier caso, involucrar al trabajador en la solución del problema suele dar lugar a una solución más rápida, porque las personas más cercanas a un problema suelen ser las que más lo saben. Si esto no es factible, el trabajador debe participar en la aplicación de la solución. Recuerde que en Wipro, los miembros superiores de un equipo de software comprobarían el código escrito por los novatos. Si se encontraba un error, los novatos, no los expertos, eran los encargados de solucionarlo, con la ayuda de sus colegas superiores cuando era necesario. Esto aseguraba que los novicios supieran cuándo habían cometido un error y entendieran qué había salido mal, reduciendo la probabilidad de que cometan errores similares en el futuro.

Los problemas deben resolverse donde se producen.

La ubicación proporciona información contextual importante. Sin esa información, aquellos que intentan resolver un problema no pueden reproducir exactamente lo que sucedió y es mucho menos probable que tengan éxito.

En una época en la que los miembros del equipo suelen estar repartidos por todo el mundo, la idea sencilla de que todos los que intentan resolver un problema deberían poder verlo de primera mano puede parecer inviable. Pero la tecnología moderna lo hace eminentemente posible. Por ejemplo, algunos miembros de un equipo de Wipro que observamos eran responsables de probar el software en las instalaciones de un cliente de EE. UU.; otros miembros, con sede en la India, eran responsables de corregir cualquier error que surgiera. En este caso, los miembros del equipo no solo se encontraban en ubicaciones diferentes, sino en zonas horarias diferentes. Un grupo solía dormir mientras el otro trabajaba. A veces, los ingenieros de la India no podían replicar los errores que habían encontrado sus colegas en Estados Unidos y, por lo tanto, no podían corregirlos. En última instancia, el equipo decidió que el grupo estadounidense utilizara herramientas de vídeo web para registrar los pasos dados y las configuraciones del sistema que habían producido un error; esto facilitó mucho a los ingenieros de la India identificar las causas y solucionar el problema.

Resuelva los problemas lo antes posible después de que surjan.

Cuanto más fresca sea la información sobre un problema, menos sujeto estará a la distorsión y más fácil será encontrar la causa. Atacar un problema desde el principio también te ayuda a aprovechar al máximo el incidente como una oportunidad de aprendizaje. Esta es la razón por la que Toyota hace que los empleados tiren de los cables andon para hacer sonar la alarma cuando se produce un problema. Incluso si instalar sistemas de alarma similares, por ejemplo, en un bufete de abogados o en un laboratorio farmacéutico no es factible, aplicar el principio detrás de ellos sí lo es. Con esto en mente, un equipo de Wipro que había estado revisando semanalmente su código recién escrito cambió a que los ingenieros de primera línea revisaran el trabajo de los demás a diario, mientras que los jefes de equipo revisaron el trabajo del grupo cada dos o tres días. La incidencia de errores disminuyó.

Al utilizar el método científico y hacer que quien haya causado un error lo corrija dónde y cuándo ocurrió, una organización del conocimiento puede crear un motor de resolución de problemas que impulse la mejora continua.

Planifica un viaje incremental

Aplicar los principios lean al trabajo del conocimiento no es simplemente una cuestión de copiar herramientas que han tenido éxito en la fabricación. En cambio, debes usar el contenido de la caja de herramientas para inventar algo nuevo. Probablemente no lo hagas bien en el primer intento, pero con el tiempo puedes armar un sistema de mejora continua haciendo lo siguiente:

Empieza poco a poco.

Wipro puso en marcha 10 proyectos piloto para explorar si un enfoque ajustado era una opción viable. Cuando ocho mostraron resultados prometedores, encargó a la oficina de productividad la tarea de liderar un esfuerzo en toda la empresa. Poco a poco, la empresa aprendió qué ideas funcionaban, cuáles necesitaban refinamiento y cuáles debían descartarse.

Codifica las lecciones aprendidas.

Es importante que alguien de la organización tenga una visión general de la iniciativa; de lo contrario, podría perderse fácilmente un aprendizaje valioso. La oficina de productividad de Wipro asumió esta función, revisando todos los proyectos ajustados, liderando los esfuerzos educativos y ayudando a estandarizar las prácticas.

Sigue buscando nuevas formas de trabajar.

Aunque los avances en Wipro fueron constantes en cuanto al número de proyectos ajustados emprendidos, los altos directivos reconocieron que la adopción generalizada era solo una medida del éxito y que la aplicación también debía ser profunda.

Tres años después de la iniciativa lean, todas las señales externas eran prometedoras. Los empleados estaban muy comprometidos, los clientes expresaban interés en aplicar los nuevos métodos de Wipro a sus propias operaciones de IT y el crecimiento del número de proyectos ajustados era enorme. Sin embargo, durante su revisión continua del esfuerzo, los líderes de la iniciativa vieron que algunos equipos estaban aplicando enfoques ajustados solo a ciertas partes de sus proyectos. Preocupados de que los equipos pudieran adoptar solo algunas de las herramientas más atractivas superficialmente y no cambiar fundamentalmente su forma de trabajar, los líderes dejaron de agregar proyectos al esfuerzo y se tomaron tiempo para reexaminar las experiencias hasta la fecha. Crearon recomendaciones detalladas y específicas para cada etapa que podrían aplicarse a varios tipos de proyectos. Finalmente, reconociendo que carecían de los recursos necesarios para apoyar los esfuerzos lean en todos los ámbitos, decidieron centrarse en proyectos más grandes, donde las ganancias potenciales eran mayores. Cuando se completó este trabajo preliminar (en cuestión de tres o cuatro meses), relanzaron el esfuerzo y aumentaron los beneficios.

Recuerde que el enfoque lean no es útil en todas partes.

Si el trabajo que tenemos entre manos es visionario y experimental y requiere inventar nuevas formas de realizar tareas, no intentes aplicar los principios lean en todas partes. Las tareas repetitivas dentro del trabajo pueden y deben abordarse con ideas sencillas. Pero la innovación se verá afectada si el tiempo necesario para proponer y probar ideas descabelladas se clasifica como desperdicio y se elimina.

Involucra a tus managers

A largo plazo, los principios lean resultan en una mejora ascendente: las personas de primera línea generan e implementan nuevas ideas, mientras que los gerentes desempeñan un papel de apoyo. Pero este es el estado final; una organización rara vez, si es que alguna vez, empieza ahí. Los gerentes medios y superiores son fundamentales para poner en marcha el proceso.

Los gestores de proyectos y otros líderes de nivel medio deben formar y motivar a sus equipos.

Esto requiere una inversión significativa de tiempo de gestión. Durante nuestra investigación, descubrimos que los equipos que tenían líderes que estaban muy comprometidos con la iniciativa lean (que educaron a sus equipos y los convencieron de que los esfuerzos ajustados mejorarían el rendimiento) tenían más éxito que los equipos cuyos líderes no lo eran. En Wipro, el director del proyecto o un instructor lean certificado realizaron la formación inicial. Luego, el director del proyecto debía empujar al equipo a utilizar las ideas.

Los líderes sénior deben ser campeones a largo plazo.

Muchas organizaciones sufren mejora de procesos. Sus líderes hablan de boca a la iniciativa del mes y, no es de extrañar que la gente no se tome muy en serio las iniciativas.

Convertir una organización en un sistema ajustado requiere una reinvención de base de cómo se realiza el trabajo. Esto es tan cierto en el trabajo del conocimiento como en la fabricación. La transformación exige una inversión sostenida, una gran cantidad de formación, una nueva cultura y nuevos procesos. El liderazgo sénior debe tratarlo como un programa de cambio a largo plazo.

Azim Premji, presidente de Wipro, lo entendió bien; estuvo profundamente involucrado con la iniciativa de su empresa desde el principio. Revisó personalmente los proyectos lean, se reunió constantemente con los líderes de la iniciativa y habló de ello con el mundo exterior. Su compromiso público dejó claro a los empleados que el programa estaba ahí para quedarse.

Convertir un una planta de fabricación en un sistema ajustado requiere un esfuerzo enorme e implacable. La clave es la persistencia, no la genialidad.

Convertir una operación de conocimiento, que tiene muchos menos procesos repetitivos y codificables, en un sistema ajustado es aún más difícil. Pero como hemos visto, se puede hacer. Y la dificultad misma significa que el sistema será difícil de replicar para un competidor. Este es su poder.

1. La eliminación continua de los residuos debe ser una parte integral del trabajo de todo trabajador del conocimiento.

2. Esfuérzate por hacer explícito el conocimiento tácito.

3. Especifique cómo deben comunicarse los trabajadores entre sí.

4. Utilice el método científico para resolver los problemas lo antes posible. Las personas que crearon el problema deberían solucionarlo.

5. Recuerde, un sistema ajustado tarda años en construirse.

6. Los líderes deben abrir el camino.

— Escrito por Bradley Staats Bradley Staats David M. Upton