Lean Knowledge Work

El sistema de producción Toyota es sin duda el invento más importante en funcionamiento desde que el modelo 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 los datos y encargar a los trabajadores la tarea continua de aumentar la eficiencia y eliminar el despilfarro en sus puestos de trabajo. Esta colección de ideas se denomina a menudo «ajustada». Hoy en día, la mayoría de las empresas de fabricación y algunas empresas de servicios cosechan sus frutos.

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

Sin embargo, nuestra investigación sobre los servicios de TI, financieros, de ingeniería y legales revela que ese trabajo puede, de hecho, beneficiarse de los principios del sistema de producción de Toyota. Por un lado, una cantidad sustancial de conocimiento que se supone tácita no tiene por qué serlo; se puede articular y plasmar por escrito si la organización hace el esfuerzo de sacárselo de la cabeza a la gente. Por otro lado, todo el trabajo con el conocimiento incluye algunas actividades que no tienen nada que ver con la aplicación del juicio y se pueden simplificar capacitando a los empleados para que encuentren y eliminen continuamente el despilfarro. Incluso cuando el conocimiento es genuinamente tácito, crear sistemas y normas que guíen las interacciones de los trabajadores puede llevar a una colaboración más eficaz.

En la fabricación, hay una visión común de cómo hacer que una operación sea eficiente y muchas de las mismas técnicas se pueden emplear en diferentes organizaciones. Este no es el caso en el trabajo con conocimiento. Sin embargo, hemos descubierto que los principios de optimización se pueden aplicar de alguna forma a casi todos los tipos de trabajos relacionados con el conocimiento y pueden generar importantes beneficios: tiempo de respuesta más rápido, mayor calidad y creatividad, menores costes, reducción del trabajo pesado y la frustración y mayor satisfacción laboral.

El viaje de Wipro hacia el adelgazamiento

Nuestro estudio más extenso sobre la aplicación de los principios de Lean al trabajo con el conocimiento incluye una ambiciosa iniciativa en Wipro Technologies. Con sede en Bangalore (India), Wipro es una de las mayores empresas de ingeniería de productos y servicios de TI 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 un 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 realizar 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 trabaja en un caso importante suele incluir miembros con una amplia gama de conocimientos, un equipo de software de Wipro está formado por personas con una experiencia muy variada. Algunos tienen bastante experiencia, otros acaban de empezar; algunos tienen habilidades especializadas, otros son generalistas; algunos ofrecen una amplia supervisión y apoyo, otros hacen el trabajo real. Al intercambiar ideas y probar cosas, encuentran soluciones.

Varios desafíos llevaron a Wipro a embarcarse en su viaje de escasez, en 2004. Su necesidad de empleados altamente cualificados aumentaba al mismo tiempo que la rotación aumentaba debido a la fuerte demanda del sector. Los días en que la empresa podía competir sobre la base de los bajos costes laborales habían terminado. Tampoco podía seguir compitiendo con una calidad superior; sus principales rivales lo habían alcanzado. En busca de una ventaja sostenible, los líderes de Wipro decidieron crear un sistema ágil. Aunque reconocieron que este enfoque no estaba probado en el trabajo con el conocimiento y que requeriría una transformación profunda de la empresa, creían que la posible recompensa (la capacidad de mejorar más rápido que la competencia) merecía la pena correr el riesgo.

Los directivos 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 la experiencia pertinente. Así que Sambuddha Deb, el director sénior a cargo de las operaciones, reunió a otros nueve directivos de Wipro. El grupo se reunió alrededor de una mesa de conferencias e hizo una pregunta sencilla: «¿Cómo lo hacemos?» Su respuesta: «Nos educaremos. Se nos ocurrirán nuestras propias ideas para adaptar Lean a una operación de software a gran escala y, después, las probaremos».

Los directivos empezaron a estudiar cómo se había aplicado el enfoque ajustado en la fabricación. Revisaron minuciosamente todo el material escrito que pudieron encontrar, recorrieron fábricas esbeltas y conversaron con un antiguo gurú de Toyota. Luego hicieron una lluvia de ideas sobre cómo utilizar lo que habían aprendido; cada uno eligió un proyecto existente para poner a prueba sus ideas. Poco a poco fueron identificando las prácticas que funcionaban.

Hemos estado estudiando este esfuerzo desde el principio. Analizamos los resultados de 1883 proyectos de Wipro que implicaban una ingeniería de productos compleja o el suministro de soluciones de TI. De esos proyectos, 772 utilizaban un enfoque simplificado y 1.111 no. También observamos muchos de ellos mientras se llevaban a cabo.

Hacer que una operación sea eficiente es un viaje de muchos años, no un esfuerzo enorme. Aun así, descubrimos que el enfoque simplificado ya está teniendo un impacto significativo. Los proyectos ajustados que estudiamos no tuvieron mejores resultados que otros en cuanto a las medidas de calidad (defectos y errores), quizás porque los estándares ya eran altos. Pero obtuvieron resultados superiores en términos de tiempo y coste. De media, los proyectos de optimización se completaron en un 5% menos de tiempo del previsto; los demás proyectos suelen terminar a la hora prevista. Y los proyectos ajustados estuvieron un 9% por debajo del presupuesto; los demás estuvieron un 2% por debajo del presupuesto. (Para obtener más información sobre los resultados, consulte «Lean Principles, Learning and Knowledge Work: Evidence from a Software Services Provider», de Bradley R. Staats, David James Brunner y David M. Upton, Journal of Operations Management, Julio de 2011.)

Basándonos en nuestra investigación en Wipro, redactamos algunos principios para hacer que las operaciones del conocimiento sean sencillas. Refinamos nuestras ideas después de revisar la literatura sobre fabricación ajustada (para ver un artículo especialmente útil, consulte «Decodificando el 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 de optimización en otros entornos de trabajo con conocimiento. Al final, se nos ocurrieron seis principios, que describiremos con detalle a continuación. Al utilizarlos, los directivos pueden crear los enfoques ajustados personalizados que mejor se adapten a sus organizaciones.

Elimine el despilfarro

Taiichi Ohno, el principal arquitecto del sistema Toyota, dijo que había «siete residuos» que todos en una operación de fabricación deberían esforzarse por eliminar: la sobreproducción, el transporte, el inventario y el movimiento innecesarios de los trabajadores; los defectos, el sobreprocesamiento y la espera. Los lugares de trabajo típicos del conocimiento están repletos de estos residuos. De hecho, el trabajo con el conocimiento incluye muchas actividades rutinarias que no implican juicio ni experiencia y 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 enormemente 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 los residuos de forma sistemática y hagan algo al respecto. He aquí cómo reclutar a la gente en la causa:

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

Los residuos pueden ser obvios una vez señalados, pero encontrarlos en primer lugar no siempre es fácil, porque por lo general forman parte del paisaje durante mucho tiempo. La solución: en lugar de suponer que el enfoque utilizado para un proceso es correcto, asuma que es incorrecto. Con este fin, los directivos de Toyota idearon «los cinco porqués», un proceso en el que se hacen preguntas de forma continua hasta llegar a la causa principal de cada actividad realizada. ¿Por qué voy a esta reunión? ¿Por qué estoy rellenando este informe? ¿Por qué estoy de pie junto a la imprenta?

Cuando un equipo de Wipro cuyo proyecto estaba retrasado hizo este ejercicio, descubrió primero que sus miembros resolvían los mismos problemas una y otra vez. Más preguntas revelaron un tema mayor: el equipo estaba tan ocupado intentando mantenerse al día con su trabajo que se olvidó de crear soluciones estándar y formar a las personas. Esto significaba que pocos miembros tenían la experiencia necesaria para gestionar una variedad de problemas. En respuesta, el equipo reestructuró el proyecto según criterios funcionales, asignó a personas como líderes principales y de respaldo de cada función y las hizo responsables de crear soluciones estándar y de formar a los demás miembros del equipo. Las personas cambiaban a un puesto diferente cada trimestre para garantizar que todos adquirieran amplias habilidades. Aunque estas medidas aumentaron inicialmente el tiempo necesario para realizar el trabajo, pronto el equipo pudo acelerar y entregó su proyecto según lo previsto.

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

La mayoría de las empresas exitosas ya han eliminado las formas grandes y obvias de despilfarro, pero los pisos de las operaciones de conocimiento suelen estar plagados de monedas de cinco centavos que nadie se ha molestado en recoger. Piense en su propio lugar de trabajo. ¿Cuántos correos electrónicos abarrotan su bandeja de entrada porque alguien le ha hecho un cc innecesariamente? ¿Cuánto tiempo tuvo que esperar para empezar una reunión programada normalmente porque los asistentes llegaban poco a poco? ¿Cuántos informes se crean que nadie lee?

Para identificar y erradicar el despilfarro de forma continua, una organización debe aprender a preocuparse por las cosas pequeñas. Esto significa ayudar a las personas a ver la cantidad de residuos que las rodean y a reconocer que eliminarlos les permitirá realizar 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 despilfarro.

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

El equipo que estudiamos estaba desarrollando controladores de impresora, un software que controla las impresoras. A medida que los miembros escribían el código, tenían que probarlo en una impresora. Los mapas del flujo de valor destacaron varias formas de residuos. Por ejemplo, cuatro personas que utilizaban la misma impresora a menudo se quedaban de pie alrededor de la máquina mientras los demás imprimían. El cambio frecuente de usuario también hizo que dedicaran mucho tiempo a ajustar la configuración de la impresora según sus necesidades particulares. Y como la impresora estaba en otro piso, subían y bajaban constantemente las escaleras, un viaje de ida y vuelta de cinco a 10 minutos.

Tras localizar estas formas de residuos, el equipo encontró espacio para la impresora en su propio piso y designó franjas horarias para cada usuario. Estos y muchos otros pequeños cambios le permitieron dedicar mucho más tiempo al trabajo de verdad.

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

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

Los gerentes deben evaluar con regularidad las tareas de sus empleados, incluido el tiempo que dedican a cada una. Una organización de desarrollo de productos que llevó a cabo una revisión de este tipo descubrió que el retraso de las tareas, la priorización inadecuada de las tareas 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, siendo realistas. Esto estaba provocando importantes cuellos de botella, cambios excesivos de tareas, incumplimiento de plazos y desgaste del personal. Así que 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 planificado 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.

Especifique la obra

La práctica de anotar exactamente cómo realizar una tarea (definir claramente la sustancia, el orden, el momento y el resultado deseado) ha aportado un gran valor a los fabricantes. Permite comparar los resultados reales y esperados. Si las dos cosas no coinciden, la organización sabe que hay un problema con el cumplimiento del proceso o con el 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 del conocimiento se desarrollan dentro de la cabeza del empleado; pueden ser invisibles para los demás y difíciles de articular en pasos concretos y replicables. Un banquero de inversiones, por ejemplo, puede que no pueda explicar fácilmente cómo persuadió a alguien para que aceptara una operación.

Lectura adicional de HBR

«Decodificando el ADN del sistema de producción de Toyota», de Steven J. Spear y H. Kent Bowen (septiembre-octubre de 1999) «Arreglar la atención médica en primera línea» de

…

Además, el trabajo en una operación de conocimiento puede cambiar rápidamente y, en un día cualquiera, las personas pueden realizar una combinación de tareas, algunas que requieren juicio o intuición y otras que podrían reducirse a un protocolo, ya que el problema y las mejores formas de abordarlo se entienden 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 lo haya sido, se puede mejorar continuamente. La clave es impugnar la suposición de que todo el conocimiento es intrínsecamente tácito. Una empresa de fabricación que conocemos tenía un planificador experimentado que asignaba el trabajo a toda la fábrica. Los líderes de la empresa, con el deseo de mejorar el proceso de programación, pidieron a un alto directivo que lo entrevistara. Al principio respondió a las preguntas del gerente con generalidades vagas. Pero cuando el gerente insistió y le pidió que explicara por qué había tomado una decisión y no otra, empezó a dar respuestas concretas y detalladas. El gerente descubrió poco a poco las reglas implícitas que utilizaba el planificador. La empresa ajustó entonces las normas y el rendimiento subió.

Especificar el trabajo de conocimiento implica cuatro pasos:

Busque partes repetibles del proceso y codifíquelas.

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

No intente especificarlo todo inicialmente, si es que lo hace.

Algunas tareas se realizan tan raramente que la inversión necesaria para especificarlas no vale la pena. Y a veces un problema se entiende tan mal que un experto debe asesorarle 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 hipotecario descubrió que contratar analistas crediticios expertos para apoyar el crecimiento deseado sería caro y difícil. Pero los gerentes reconocieron que, al estudiar detenidamente las decisiones crediticias del pasado, podían derivar las reglas utilizadas para tomarlas e integrar esas reglas en un sistema de TI. El sistema no eliminó por completo la necesidad de expertos, que tenían que tomar decisiones en casos que eran inusualmente complejos o que implicaban factores especiales. Sin embargo, la gran mayoría de los casos podrían tramitarse automáticamente, lo que permitiría a la empresa hacer crecer su negocio hipotecario de forma rápida y segura.

Utilice los datos para obtener la aceptación.

Una de las principales ventajas de especificar procesos repetibles es que los trabajadores del conocimiento tienen la libertad de centrarse en las partes del trabajo en las que pueden crear más valor. Pero muchos profesionales altamente cualificados no creen que su trabajo pueda hacerse explícito. Por ejemplo, aunque especificar el trabajo puede mejorar los resultados en la medicina, los médicos suelen resistirse enérgicamente, con el argumento de que su juicio y experiencia no pueden reducirse a un conjunto de reglas. (Consulte la barra lateral «Más lectura de HBR» para ver los artículos sobre este tema de Richard Bohmer y Steven Spear.)

Lectura adicional

Repensando la fábrica de decisiones

Gestión del conocimiento Largometraje

• Roger Martin

Los argumentos a favor de estructurar el conocimiento funcionan como una empresa de servicios profesionales.

SaveShare

Como la especificación exitosa del trabajo depende a menudo de la participación de los trabajadores, superar esa resistencia es crucial. Demostrar la eficacia del proceso es clave para superar esa resistencia. Wipro lo reconoció desde el principio y empezó a rastrear dónde y cómo la especificación de las tareas aumentaba el rendimiento. Rápidamente se dio cuenta de que la especificación era especialmente beneficiosa para los proyectos que se retrasaban. Los gerentes pudieron entonces utilizar los datos sobre las mejoras de estos proyectos para ganarse a otras partes de la organización.

Siga estudiando la obra que ha sido calificada de tácita.

Aunque el trabajo no esté especificado hoy, eso no significa que no pueda ser mañana. Lo que actualmente es un hecho poco común puede ocurrir con frecuencia en el futuro. Y la comprensión de los problemas complicados puede crecer con el tiempo. En «Fixing Health Care on the Front Lines» (HBR, abril de 2010), Richard M.J. Bohmer describe cómo Intermountain Healthcare, una empresa que opera en Utah e Idaho, se destaca en la mejora regular de los protocolos de tratamiento de enfermedades. Un enfoque que emplea es permitir a los médicos anular los protocolos en situaciones ambiguas. Recopila y analiza los datos de las anulaciones y utiliza los conocimientos de las que tienen éxito para mejorar el protocolo. Si una anulación produce malos resultados, la empresa utiliza los datos para persuadir a los médicos de que sigan la rutina con más frecuencia. Intermountain incluso ha creado una unidad para poner a prueba las ideas y presentimientos de los médicos. Una prueba permitió mejorar los criterios para el traslado de los pacientes de las salas a los cuidados intensivos.

Especificar el trabajo de la manera sistemática que hemos descrito permite a una organización del conocimiento dedicarse continuamente a un aprendizaje disciplinado. Hacer ese esfuerzo a menudo exige recursos dedicados. Wipro creó una oficina de productividad para hacer 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.

Estructurar las comunicaciones

Al reconocer que muchos problemas son demasiado grandes o complejos para que los aborde una sola persona, 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 pasa a ser imperativa, sobre todo porque los equipos pueden tener miembros en todo el mundo. Un sistema ágil puede promover una buena comunicación al articular 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 tienen que 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 la producción funciona como se espera. Si la comunicación frecuente genera un flujo abundante de información, los problemas se pueden detectar y solucionar desde el principio. Y cuando se explica el contenido deseado de la comunicación, las personas obtienen la información que necesitan y no tienen que perder tiempo intentando entender lo que dicen los demás.

Una herramienta que Wipro adoptó para ayudar a la comunicación fue la matriz de estructuras de diseño. En un DSM, las tareas de un proyecto aparecen en las filas y columnas de una matriz, y el equipo marca si cada elemento está relacionado con los demás y designa cada relación como una dependencia directa o un ciclo de retroalimentación. El álgebra matricial puede entonces 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.) Los cálculos son un poco complicados, pero Wipro utilizaba una versión de hoja de cálculo simplificada que cualquier equipo podía entender. Con solo pulsar un botón, el programa clasificó las tareas e identificó qué miembros del equipo tenían que interactuar en torno a cada una de ellas y cuándo.

Crear 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 puede que no tengan la misma opinión sobre lo que se comunica; las mismas palabras pueden tener diferentes significados para diferentes personas. Tenga en cuenta las interacciones entre las personas de una empresa estadounidense y su proveedor indio de servicios de TI. Un intercambio que documentamos implicaba una pregunta aparentemente sencilla: «¿Puede terminar el trabajo en un plazo determinado?» Para la gente de la empresa estadounidense, sí significaba sí y no significaba no, y si algo salía mal, podían gritar y golpear la mesa. Por el contrario, los indios a menudo transmitían un no de manera tan indirecta que sus homólogos estadounidenses escuchaban que sí. Y cuando los indios plantearon problemas, los formularon como preguntas redactadas en voz baja, que los trabajadores estadounidenses, que no estaban acostumbrados a esas sutilezas, ignoraron en gran medida. A pesar de que 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 llegaban. La empresa estadounidense se enteró de que, cada vez que entablaba una nueva relación con un proveedor, tenía que especificar exactamente cómo debía comunicarse el proveedor.

La necesidad de estructurar las comunicaciones y crear un entendimiento compartido también se hizo evidente en una revista que conocemos. Un editor puede adquirir un artículo largo de un autor externo y dárselo a un colega para que lo edite. La tarea de convertir esas contribuciones en artículos de alta calidad a tiempo era a menudo difícil y estresante. La dirección reconoció el dilema, pero pensó que era inevitable: creía que las transferencias eran intrínsecamente difíciles porque la edición implica un conocimiento tácito del tema y de la forma de expresar las ideas, y no hay dos editores que aborden un artículo 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 consultaban, las conversaciones no estaban estructuradas. Los dos podrían tener ideas muy diferentes sobre el borrador y la obra necesaria antes de que pudiera publicarse, y no había ningún medio formal de conciliar puntos de vista contradictorios.

La revista tenía un proceso específico para presentar propuestas de artículos: cada una debía incluir una descripción escrita del valor del artículo 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 llegaba al final podía diferir significativamente de la propuesta. Y a veces un editor adquirente se saltaba el proceso presentando una propuesta al editor jefe en una presentación oral.

Un enfoque más eficaz habría estipulado, primero, que cada editor presentara una propuesta por escrito, de modo que los motivos de la publicación del artículo —el valor que proporcionaría a los lectores— quedaran registrados. Una vez recibido el borrador completo del artículo, tanto el comprador como el editor asignado tendrían que escribir un plan detallado de crítica y edición. (Esto último puede 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 primer nivel, durante la cual los tres llegarían a un acuerdo sobre estos temas.

Con una comunicación bien especificada, las personas entienden el trabajo que están realizando. Esto les permite dedicar tiempo a resolver problemas en lugar de a tratar de averiguar el trabajo en cuestión.

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 grave cuando el trabajo implica conocimiento tácito, porque a menudo no está del todo claro cómo un experto llegó a una decisión en particular y en qué medida esa decisión se basó en la intuición o en la emoción frente a los hechos.

Uno de los proyectos de 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 con regularidad en el que los miembros con más experiencia evaluaban el código de software escrito por sus colegas con menos experiencia. El revisor de cada miembro subalterno 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 con menos experiencia a mejorar y permitir que los miembros del equipo se conocieran. Lamentablemente, los revisores sénior utilizaron estándares diferentes y comunicaron las evaluaciones de manera diferente. Lo que era una buena escritura de código para uno podría ser un error para otro. Incluso cuando los críticos estaban de acuerdo en lo que constituía un error, a menudo lo llamaban de diferentes maneras. La falta de normas y comunicación comunes perjudica la moral de los empleados subalternos.

Antecedentes esenciales

El nuevo desafío de la productividad

Desarrollando empleados Largometraje

• Peter F. Drucker

¿Cómo pueden las empresas aumentar la productividad de los trabajadores del conocimiento y los servicios?

SaveShare

Uno de los críticos descubrió el problema y llamó al equipo para discutirlo. El grupo reconoció que tenía la oportunidad de estandarizar las comunicaciones y el trabajo principal. Algunos de los miembros principales elaboraron una lista de errores comunes y sus definiciones para que la utilizaran todos los críticos. El ejercicio llevó al equipo a darse cuenta de que muchos errores que habían considerado errores difusos (cuestiones relacionadas con la forma en que se definían las variables y la forma en que se incorporaban las explicaciones en el código) eran en realidad bastante concretos. Y una vez que se explicaran estas cosas, los errores podrían corregirse sistemáticamente.

El lenguaje del equipo pronto pasó a ser tan preciso que incluso una máquina podía entenderlo: el programa de escritura de códigos podía evaluar automáticamente si los miembros habían seguido las normas y, si no lo habían hecho, levantaba una señal de alerta.

Al final, el equipo pasó menos tiempo luchando por lo que era un error y más tiempo trabajando para prevenir los errores desde el principio. Como resultado, la incidencia de errores se redujo drásticamente.

Abordar los problemas de forma rápida y directa

Uno de los objetivos fundamentales del sistema de producción de Toyota es convertir una operación en un motor que resuelva problemas. El núcleo de ese motor es el método científico: articular una hipótesis explícita y mensurable sobre cómo se podría mejorar algún aspecto del trabajo, realizar una prueba objetiva de la hipótesis y, si los datos respaldan 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 a 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, implicar al trabajador en la resolución del problema normalmente se traduce en una solución más rápida, ya que las personas más cercanas a un problema suelen ser las que más saben al respecto. Si esto no es factible, el trabajador debería participar en la aplicación de la solución. Recuerde que en Wipro, los miembros principales de un equipo de software comprobarían el código escrito por los novatos. Si se encontraba un error, eran los novatos, no los expertos, los responsables de solucionarlo, con la ayuda de sus colegas principales cuando era necesario. Esto garantizó que los novatos supieran cuando habían cometido un error y entendieran lo que había ido mal, lo que reducía la probabilidad de que cometieran errores similares en el futuro.

Los problemas deben resolverse donde se producen.

La ubicación proporciona información contextual importante. Sin esa información, quienes intentan resolver un problema no pueden reproducir exactamente lo que ha ocurrido y es mucho menos probable que lo consigan.

En una era en la que los miembros del equipo suelen estar repartidos por todo el mundo, la idea 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 perfectamente posible. Por ejemplo, algunos miembros de un equipo de Wipro que observamos eran responsables de probar el software en el sitio de un cliente estadounidense; otros miembros, con sede en la India, se encargaban de corregir cualquier error que surgiera. En este caso, los miembros del equipo no solo estaban en diferentes lugares, sino en diferentes zonas horarias. Un grupo dormía normalmente mientras el otro trabajaba. A veces los ingenieros de la India no podían reproducir los errores que habían descubierto sus colegas en los EE. UU. y, por lo tanto, no podían corregirlos. Al final, el equipo decidió que el grupo estadounidense utilizara herramientas de vídeo web para grabar las medidas que tomaban 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 cuando surjan.

Cuanto más fresca sea la información sobre un problema, menos será objeto de distorsión y más fácil será encontrar la causa. Atacar un problema desde el principio también le ayuda a aprovechar al máximo el incidente como una oportunidad de aprendizaje. Por eso Toyota hace que los empleados tiren y pongan cables para hacer sonar la alarma cuando se produce un problema. Incluso si instalar sistemas de alarma similares en, por ejemplo, un bufete de abogados o un laboratorio farmacéutico no es factible, aplicar el principio en el que se basan sí lo es. Con esto en mente, un equipo de Wipro que comprobaba semanalmente su código recién escrito pasó a hacer que los ingenieros de primera línea comprobaran el trabajo de los demás a diario, mientras que los líderes del equipo revisaban 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 arregle dónde y cuándo se produjo, una organización del conocimiento puede crear un motor de resolución de problemas que impulse la mejora continua.

Planifique un viaje gradual

Aplicar los principios de optimización al trabajo con el conocimiento no es simplemente una cuestión de copiar las herramientas que han tenido éxito en la fabricación. En cambio, debe usar el contenido de la caja de herramientas para inventar algo nuevo. Probablemente no lo haga bien al primer intento, pero con el tiempo podrá crear un sistema de mejora continua haciendo lo siguiente:

Empiece de a poco.

Wipro lanzó 10 proyectos piloto para explorar si un enfoque simplificado era una opción viable. Cuando ocho obtuvieron resultados prometedores, encargó a la oficina de productividad que liderara una iniciativa en toda la empresa. Poco a poco, la empresa aprendió qué ideas funcionaban, cuáles necesitaban refinarse y cuáles debían descartarse.

Codifique las lecciones aprendidas.

Es importante que alguien de la organización tenga una visión general de la iniciativa; de lo contrario, se podría perder fácilmente un valioso aprendizaje. La oficina de productividad de Wipro ocupó este puesto, revisando cada proyecto de optimización, liderando las iniciativas educativas y ayudando a estandarizar las prácticas.

Siga buscando nuevas formas de trabajar.

Aunque el progreso en Wipro fue constante en términos del número de proyectos ajustados emprendidos, los altos directivos reconocieron que la adopción generalizada era solo una medida del éxito y que la implementación también tenía que ser profunda.

Tres años después de la iniciativa Lean, todas las señales externas eran prometedoras. Los empleados tenían un amplio compromiso, los clientes expresaban su interés en aplicar los nuevos métodos de Wipro a sus propias operaciones de TI y el aumento del número de proyectos de optimización era enorme. Sin embargo, durante su revisión continua de la iniciativa, los líderes de la iniciativa vieron que algunos equipos aplicaban enfoques ajustados solo a ciertas partes de sus proyectos. Preocupados de que los equipos pudieran adoptar solo unas pocas de las herramientas más atractivas desde el punto de vista superficial y no cambiar de manera fundamental su forma de trabajar, los líderes dejaron de añadir proyectos al esfuerzo y se dedicaron a reexaminar las experiencias hasta la fecha. Crearon recomendaciones detalladas y específicas para cada fase que podían aplicarse a varios tipos de proyectos. Por último, al reconocer que carecían de los recursos para apoyar los esfuerzos de reducción en todos los ámbitos, decidieron centrarse en los proyectos más grandes, en los que los posibles beneficios eran mayores. Cuando se completó este trabajo preliminar (en cuestión de tres o cuatro meses), relanzaron la iniciativa y los beneficios aumentaron.

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

Si la obra en cuestión es visionaria y experimental y requiere inventar nuevas formas de realizar las tareas, no intente aplicar los principios de Lean en todas partes. Las tareas repetitivas dentro de la obra pueden y deben abordarse con ideas sencillas. Pero la innovación se verá afectada si el tiempo necesario para idear y poner a prueba ideas descabelladas se clasifica como desperdicio y se elimina.

Involucre a sus gerentes

A la larga, los principios ajustados se traducen en una mejora de abajo hacia arriba: las personas de primera línea generan e implementan nuevas ideas, mientras que los gerentes desempeñan un papel secundario. Pero este es el estado final; una organización rara vez, o nunca, comienza ahí. Los directivos intermedios y superiores son fundamentales para iniciar el proceso.

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

Esto requiere una importante inversión de tiempo de gestión. Durante nuestra investigación, descubrimos que los equipos que tenían líderes que participaban activamente en la iniciativa Lean (que educaban a sus equipos y los convencían de que los esfuerzos ajustados mejorarían el rendimiento) tenían más éxito que los equipos cuyos líderes no lo estaban. En Wipro, el director del proyecto o un instructor certificado de Lean impartió la formación inicial. Luego fue el director del proyecto el que presionó al equipo para que utilizara las ideas.

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

Muchas organizaciones sufren de la mejora del proceso es. Sus líderes hablan de boquilla sobre la iniciativa del mes y, no es sorprendente que la gente no se tome las iniciativas muy en serio.

Convertir una organización en un sistema ágil requiere una reinvención popular de la forma en que se realiza el trabajo. Eso es tan cierto en el trabajo con el conocimiento como en la fabricación. La transformación exige una inversión sostenida, una enorme cantidad de formación, una nueva cultura y nuevos procesos. Los altos directivos deben tratarlo como un programa de cambio a largo plazo.

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

Convirtiendo un convertir una planta en un sistema eficiente 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 reducido es aún más difícil. Pero como hemos visto, se puede hacer. Y la misma dificultad significa que el sistema será difícil de replicar para un competidor. Este es su poder.

1. Erradicar continuamente el despilfarro debería ser una parte integral del trabajo de todos los trabajadores del conocimiento.

2. Esforzarse 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 que un sistema ágil tarda años en construirse.

6. Los líderes deben abrir el camino.