Trabajo de Conocimiento Lean

Los principios de “Toyota” también pueden ser eficaces en operaciones de juicio y experiencia
Trabajo de Conocimiento Lean
Trabajo de Conocimiento Lean

24Oct11_Staats_lean-knowledge-work

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

Pero los intentos de aplicar enfoques delgados al trabajo del conocimiento han resultado frustrantemente difíciles. La mayoría en el mundo de los negocios creen que el trabajo del conocimiento no se presta a principios de inclinación, porque, a diferencia del montaje del automóvil, no es repetitivo y no puede definirse inequívocamente. Considere la posibilidad de que un funcionario bancario decida si desea hacer un préstamo, un ingeniero que está desarrollando un nuevo producto y un trabajador social decida si el entorno de un niño es seguro: en cada caso, el trabajo implica conocimientos especializados y juicios que dependen en gran medida del conocimiento tácito, conocimiento encerrado dentro de la cabeza del trabajador.

Sin embargo, nuestra investigación en servicios de IT, financieros, de ingeniería y legales revela que dicho 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é ser; puede articularse y capturarse por escrito si la organización hace el esfuerzo para 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 criterio y que pueden simplificarse capacitando a los empleados para encontrar y eliminar continuamente los residuos. Incluso cuando el conocimiento es realmente tácito, la creación de sistemas y reglas para guiar las interacciones de los trabajadores puede conducir a una colaboración más efectiva.

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

El viaje Lean de Wipro

Nuestro estudio más amplio sobre la aplicación de los principios lean al trabajo de conocimiento implica una ambiciosa iniciativa en Wipro Technologies. Con sede en Bangalore, India, Wipro es una de las empresas de servicios de IT e ingeniería de productos más grandes 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 complejo software personalizado. 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 normalmente incluye miembros con una amplia gama de conocimientos, un equipo de software Wipro está formado por personas con una experiencia muy variada. Algunos están bastante experimentados, otros están empezando; algunos tienen habilidades especializadas, otros son generalistas; algunos proporcionan supervisión y apoyo amplios, otros hacen el trabajo real. Al rebotar ideas entre sí y probar cosas, se les ocurren soluciones.

Varios desafíos llevaron a Wipro a embarcarse en su viaje de trabajo, en 2004. Su necesidad de contar con empleados altamente cualificados estaba aumentando al mismo tiempo que el rotación estaba aumentando debido a la fuerte demanda de la industria. Los días en que la empresa podía competir sobre la base de bajos costos de mano de obra 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 construir un sistema delgado. Aunque reconocieron que este enfoque no estaba probado en el trabajo del conocimiento y requeriría una profunda transformación de la empresa, creían que la recompensa potencial —la capacidad de mejorar más rápido que sus competidores— valía la pena el riesgo.

Los gerentes de Wipro no pudieron encontrar empresas que habían utilizado técnicas lean para producir software personalizado a gran escala. Y descubrieron que incluso las consultorías estratégicas líderes carecían de experiencia relevante. Así que Sambuddha Deb, el gerente principal encargado de las operaciones, reunió a otros nueve gerentes de Wipro. El grupo se reunió alrededor de una mesa de conferencias y formuló una simple pregunta: «¿Cómo lo hacemos?» Su respuesta: «Vamos a educarnos a nosotros mismos. Vamos a idear 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 manufactura. Ellos recorrieron todo el material escrito que pudieron encontrar, recorrieron fábricas delgadas, y se entrevistaron con un antiguo gurú de Toyota. Luego se intercambiaron ideas sobre cómo usar lo que habían aprendido; cada uno eligió un proyecto existente para probar sus ideas. Poco a poco identificaron prácticas que funcionaban.

Hemos estado estudiando este esfuerzo desde el principio. Se analizaron los resultados de 1.883 proyectos Wipro que involucraron ingeniería de productos complejos o la entrega de soluciones de IT. De esos proyectos, 772 utilizaron un enfoque ajustado, y 1.111 no lo hicieron. También observamos a muchos de ellos mientras se estaban llevando 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 tuvieron mejores resultados que otros en medidas de calidad (defectos y errores), tal vez 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 tiempo de lo previsto; los otros proyectos normalmente terminaron en el momento previsto. Y los proyectos lean llegaron en un 9% por debajo del presupuesto; los otros estaban en un 2% por debajo del presupuesto. (Para obtener más detalles sobre los resultados, consulte «Lean Principles, Learning, and Knowledge Work: Evidence from a Software Services Provider», por Bradley R. Staats, David James Brunner y David M. Upton, Gestión del Diario de Operaciones, Julio 2011.)

Basándonos en nuestra investigación en Wipro, elaboramos algunos principios para que las operaciones de conocimiento sean más delgadas. Hemos perfeccionado nuestras ideas después de revisar la literatura sobre la fabricación magra (para un artículo particularmente útil, véase «Decoding the DNA of the Toyota Production System», por Steven J. Spear y H. Kent Bowen, HBR Septiembre-octubre de 1999) y estudiar los esfuerzos de magra en otros entornos de trabajo de conocimiento. Al final se nos ocurrió seis principios, que describiremos en detalle a continuación. Al usarlos, los gerentes pueden crear los enfoques lean personalizados que mejor se adapten a sus organizaciones.

Eliminar residuos

Taiichi Ohno, el arquitecto principal del sistema Toyota, dijo que había «siete desechos» 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 de conocimiento incluye muchas actividades rutinarias que no implican juicio ni experiencia y pueden consumir grandes cantidades de tiempo: imprimir documentos, solicitar la información necesaria para tomar una decisión y organizar reuniones, por nombrar sólo algunos.

Hemos descubierto que los trabajadores del conocimiento tienden a subestimar groseramente la cantidad de ineficiencia que podría ser erradicada de sus trabajos. La clave es lograr que todos los miembros de la organización hagan visible sistemáticamente los desechos y hagan algo al respecto. A continuación se explica cómo alistar a la gente en la causa:

Enseñe a todos a preguntar «los cinco por qué».

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

Cuando un equipo de Wipro cuyo proyecto estaba retrasado pasó por este ejercicio, descubrió, en primer lugar, que sus miembros estaban resolviendo los mismos problemas una y otra vez. Otras preguntas revelaron un problema más grande: el equipo estaba tan ocupado tratando de mantenerse al día con su trabajo que estaba descuidando crear soluciones estándar y capacitar a las 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 las personas 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 giraron en una función diferente cada trimestre para asegurar aún más que todos adquieran habilidades amplias. Aunque estas medidas inicialmente añadieron al 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 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 llenos de níquel que nadie se ha molestado en recoger. Piensa en tu propio lugar de trabajo. ¿Cuántos correos electrónicos saturan tu bandeja de entrada porque alguien te hizo innecesariamente? ¿Cuánto tiempo tuvo que esperar para iniciar una reunión programada regularmente porque los asistentes se filtraron lentamente? ¿Cuántos informes se crean que nadie lee?

Para identificar y eliminar continuamente los desechos, una organización debe aprender a preocuparse por las cosas pequeñas. Esto significa ayudar a las personas a ver cuánto desperdicio los 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 del viaje de Wipro sabía que necesitaba identificar pequeñas fuentes de residuos, pero no estaba seguro de cómo hacerlo. Decidió usar un mapa de flujo de valor para iniciar el proceso. Un mapa de flujo de valor no sólo 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 rastrear cada paso que toma y preguntar: «¿Por qué hicimos eso?» Esto le permite crear una lista priorizada de elementos que se pueden eliminar.

El equipo que estudiamos estaba desarrollando controladores de impresora, software que controla las impresoras. Como los miembros escribieron código, necesitaban probar el código en una impresora. La cartografía del flujo de valor puso de relieve varias formas de desechos. Por ejemplo, cuatro personas que usaban la misma impresora a menudo se encontraban de pie alrededor de la máquina mientras los trabajos de los demás estaban imprimiendo. El cambio frecuente entre los usuarios también significó que pasaron mucho tiempo ajustando la configuración de la impresora para sus necesidades particulares. Y como la impresora estaba en un piso diferente, estaban constantemente subiendo y bajando las escaleras, un viaje de ida y vuelta de cinco a diez minutos.

Después de identificar estas formas de residuos, el equipo encontró espacio para la impresora en su propio piso y designó espacios de tiempo para cada usuario. Estos y muchos otros pequeños cambios le permitieron dedicar mucho más tiempo al trabajo real.

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

Muchos trabajos de conocimiento no están estructurados y amplios. Tienden a expandirse gradualmente a medida que se agrega una actividad tras otra. La gente puede terminar con demasiado en sus platos y demasiado tiempo dedicado a tareas de bajo valor.

Los gerentes deben evaluar regularmente las tareas de sus empleados, incluyendo cuánto tiempo se dedica a cada una de ellas. Una organización de desarrollo de productos que llevó a cabo ese examen determinó que la falta de tareas, la asignación inadecuada de prioridades a las asignaciones y la falta de comprensión de lo que constituye una carga de trabajo completa habían creado una situación en la que sus ingenieros solían tener el doble de trabajo que podían realizar de manera realista. Esto estaba causando cuellos de botella significativos, un cambio excesivo entre tareas, plazos incumplidos y desgaste del personal. Así que la compañía redujo las cargas de trabajo de los ingenieros, por lo que el compromiso de nadie superó 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 —definiendo claramente la sustancia, el orden, el tiempo y el resultado deseado— ha proporcionado 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 la adhesión al proceso o al 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 en las operaciones de conocimiento se desarrollan dentro de la cabeza de un empleado; pueden ser invisibles para otros 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.

Además, el trabajo en una operación de conocimiento puede cambiar rápidamente, y en cualquier día determinado la gente puede hacer una mezcla de tareas, algunas que requieren juicio o intuición, y otras que podrían reducirse a un protocolo porque el problema y las mejores maneras de abordarlo son bien entendidos. Precisamente porque las personas suelen realizar ambos tipos de trabajo, ellos y sus organizaciones asumen que muchas tareas que podrían ser estandarizadas no pueden serlo.

A pesar de los desafíos, se puede especificar una cantidad sorprendentemente grande de trabajo de conocimiento. Y una vez que lo ha sido, se puede mejorar continuamente. La clave es cuestionar la suposición de que todo conocimiento es inherentemente tácito. Una empresa de fabricación que conocemos tenía un planificador experimentado que asignó el trabajo en toda la fábrica. Los líderes de la compañía, queriendo mejorar el proceso de programación, pidieron a un gerente senior 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 administrador gradualmente descubrió las reglas implícitas que el programador estaba usando. La compañía luego ajustó las reglas, y el rendimiento subió.

Especificar el trabajo de conocimiento implica cuatro pasos:

Busque partes repetibles del proceso y codificarlas.

Casi todas las áreas de trabajo del conocimiento tienen más características comunes de lo que se ve a simple vista. En Wipro, a los equipos les resultaba difícil especificar el proceso general de redacción de códigos, ya que a menudo implicaba soluciones novedosas. Pero cuando reformularon la pregunta para preguntar «¿Qué hacemos repetidamente?» se dieron cuenta de que muchos aspectos del proceso, incluyendo la revisión por pares, compilaciones diarias (integrando todas las piezas de código escritas ese día en el programa), pruebas y revisiones de clientes ocurrieron con frecuencia dentro de un proyecto y entre proyectos y podrían ser estandarizados.

No intente especificar todo inicialmente, si es que alguna vez.

Algunas tareas ocurren tan raramente que la inversión necesaria para especificarlas no vale la pena. Y a veces un problema es tan mal entendido que un experto debe aconsejar 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 encontró que contratar analistas de crédito expertos para apoyar el crecimiento deseado sería costoso y difícil. Sin embargo, los administradores reconocieron que al estudiar cuidadosamente las decisiones de concesión de préstamos anteriores, podían derivar las reglas utilizadas para formularlas e incorporarlas en un sistema IT. El sistema no eliminó por completo la necesidad de expertos, que tenían que hacer juicios 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 permitiría a la empresa hacer crecer su negocio hipotecario de forma rápida y segura.

Use los datos para obtener buy-in.

Una ventaja importante de especificar procesos repetibles es que los trabajadores del conocimiento se liberan para centrarse en las partes del trabajo donde pueden crear el mayor valor. Pero 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 juicio y experiencia no pueden reducirse a un conjunto de reglas. (Ver la barra lateral «Más lectura de HBR» para los artículos sobre este tema de Richard Bohmer y Steven Spear.)

Lecturas adicionales

Repensando la Fábrica de Decisiones
Gestión del Conocimiento
Característica

El argumento para estructurar el conocimiento funciona como una empresa de servicios profesionales.


Debido a que la especificación exitosa del trabajo depende a menudo de la participación de los trabajadores, superar dicha resistencia es crucial. Demostrar la eficacia del proceso es clave para superar dicha resistencia. Wipro reconoció esto desde el principio y comenzó a rastrear dónde y cómo la especificación de las tareas estaba impulsando el rendimiento. Rápidamente vio que la especificación era particularmente 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 el trabajo que ha sido designado como tácito.

Incluso si el trabajo no está especificado hoy, eso no significa que no pueda ser mañana. Lo que actualmente es un evento poco común puede suceder con frecuencia en el futuro. Y la comprensión de problemas complicados puede crecer con el tiempo. En «Fixing Health Care on the Front Lines» (HBR abril 2010), Richard M.J. Bohmer describe cómo Intermountain Healthcare, una empresa que opera en Utah e Idaho, se 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. Recoge y analiza los datos de las anulaciones y utiliza el conocimiento de las exitosas para mejorar el protocolo. Si una anulación produce malos resultados, la empresa utiliza los datos para persuadir a los médicos a seguir la rutina con más frecuencia. Intermountain ha creado incluso una unidad para poner a prueba las ideas y las corazonadas de los médicos. Una prueba permitió mejorar los criterios para trasladar a 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 participar continuamente en el aprendizaje disciplinado. Para llevar a cabo este esfuerzo a menudo se requieren recursos dedicados. Wipro creó una oficina de productividad para realizar un seguimiento de las mejores prácticas, investigar nuevas ideas, ayudar a los esfuerzos de educación y ayudar a diseñar procedimientos estándar prácticos que podrían ser utilizados en diferentes equipos.

Estructuras Comunicaciones

Reconociendo que muchos problemas son demasiado grandes o complejos para que una persona pueda abordar, las organizaciones utilizan cada vez más equipos para realizar tareas de conocimiento. Sin embargo, una vez que varias personas están involucradas en un proceso, la comunicación efectiva se vuelve imperativa, especialmente porque los equipos pueden tener miembros en todo el mundo. Un sistema delgado puede promover una buena comunicación articulando las formas en que debe llevarse a cabo. A continuación se explica cómo:

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

Los trabajadores del conocimiento necesitan entender quién usará su producción. Cuando el proveedor de la obra está en contacto directo con el «cliente» (normalmente alguien del mismo equipo), los dos pueden colaborar para garantizar que la salida funcione como se esperaba. Si la comunicación frecuente genera un rico flujo de información, los problemas pueden detectarse y solucionarse desde el principio. Y cuando se explica el contenido deseado de la comunicación, la gente obtiene la información que necesita y no tiene que perder el tiempo tratando de averiguar lo que otros están diciendo.

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 bucle de retroalimentación. El álgebra de matriz puede crear un orden recomendado para las tareas. (Para obtener más información sobre el DSM, consulte «¿Están sus ingenieros hablando entre sí cuando deberían?» de Manuel E. Sosa, Steven D. Eppinger, y Craig M. Rowles, HBR Noviembre 2007.) La matemática es algo complicada, pero Wipro usó una versión simplificada de hoja de cálculo que cualquier equipo podrí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.

Crear un entendimiento compartido.

Los miembros de los equipos de conocimiento trabajan cada vez más a través de fronteras geográficas, culturales, lingüísticas y funcionales. Esto significa que pueden no tener la misma idea de lo que se está comunicando; las mismas palabras pueden tener significados diferentes para diferentes personas. Considere las interacciones entre personas de una empresa estadounidense y su proveedor indio de servicios de IT. Un intercambio que documentamos involucró una pregunta aparentemente simple: «¿Se puede hacer el trabajo dentro de un plazo determinado?» Para la gente de la compañía estadounidense, sí significa sí y no significa no, y si algo sale mal, podrían gritar y golpear la mesa. Por el contrario, los indios a menudo no transmitieron tan indirectamente que sus homólogos estadounidenses escucharon sí. Y cuando los indios plantearon problemas, los enmarcaron como preguntas suavemente redactadas, que fueron ignoradas en gran medida por los trabajadores estadounidenses, que no estaban acostumbrados a tales sutilezas. A pesar de que la comunicación entre los dos grupos estaba estructurada, hubo actualizaciones regulares entre las partes designadas, centradas en puntos de discusión establecidos, los mensajes no se estaban transmitiendo. La empresa estadounidense se enteró de que cada vez que entraba en una nueva relación con el proveedor, tenía que 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 podría adquirir un artículo largo de un autor externo y entregarlo a un colega para editarlo. La tarea de convertir esas contribuciones en artículos de alta calidad a tiempo suele ser difícil y estresante. La dirección reconoció el dilema pero pensó que era ineludible: creía que los traspasos eran intrínsecamente difíciles porque la edición implica un conocimiento tácito del tema y cómo expresar las ideas, y ninguno de los editores se acercaba a una pieza de la misma manera.

Estas cosas eran ciertas, pero parte del problema era que no había ningún proceso especificado para que los dos editores se comunicaran sobre el propósito del artículo y cómo lograrlo. A menudo no hablan en absoluto. Incluso cuando lo hicieron, las conversaciones no estaban estructuradas. Los dos podrían tener ideas muy diferentes sobre el proyecto y la labor necesaria antes de publicarlo, y no hay medios oficiales para conciliar puntos de vista opuestos.

La revista tenía un proceso específico para presentar propuestas de artículos: cada uno debía incluir una descripción escrita del valor de la pieza y un plan de edición. Sin embargo, a menudo la propuesta se basa en la descripción hecha por el autor de un artículo previsto, y el proyecto que finalmente llegó podría apartarse considerablemente de la propuesta. Y a veces un editor adquirente eludiría el proceso presentando una propuesta al editor jefe en un tono 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 entregaría a los lectores— quedaran registradas. Una vez recibido un borrador completo del artículo, tanto el adquirente como el editor asignado tendrían que escribir una crítica detallada y un plan de edición. (Estos últimos podrían incluir la estructura y la duración, la necesidad de contenido adicional, el uso de ejemplos y una estimación del tiempo necesario para completar el trabajo.) El paso final sería una conversación estructurada facilitada por un editor superior, durante la cual los tres llegarían a un acuerdo sobre estas cuestiones.

Con comunicaciones bien especificadas, las personas entienden el trabajo que están llevando a cabo. Esto les permite dedicar tiempo a resolver problemas en lugar de tratar de averiguar el trabajo en cuestión.

Resolver los desacuerdos con hechos, no con opiniones.

Una larga línea de investigación pone de relieve las formas en que las emociones y la irracionalidad pueden distorsionar el proceso de toma de decisiones. Esto puede ser un problema especialmente grande cuando el trabajo implica conocimiento tácito, porque a menudo no está claro cómo un experto llegó a una decisión en particular y hasta qué punto esa decisión se basó en la intuición o la emoción versus 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 puesto en práctica un sistema de exámenes programados periódicamente en el que los miembros más experimentados evaluaban el código informático 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 reparació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 examinadores superiores utilizaron diferentes normas y comunicaron las evaluaciones de manera diferente. Lo que era bueno escribir código a uno podría ser un error a 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 perjudicó la moral de los empleados jóvenes.

Antecedentes esenciales

El nuevo reto de la productividad
Desarrollo de Empleados
Característica

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


Uno de los revisores detectó el problema y convocó al equipo para discutirlo. El grupo reconoció que tenía la oportunidad de normalizar las comunicaciones, así como la labor principal. Algunos de los miembros superiores confeccionaron una lista de errores comunes y sus definiciones, para que los revisores las utilizaran. El ejercicio llevó al equipo a darse cuenta de que muchos errores que habían considerado como errores difusos —cuestiones que involucraban cosas tales como cómo se definían las variables y cómo se integraban las explicaciones en el código— eran en realidad bastante concretos. Y una vez que estas cosas fueron explicadas, los errores podrían corregirse sistemáticamente.

El lenguaje del equipo pronto llegó a ser tan preciso que incluso una máquina podía entenderlo: el programa de escritura de código podía evaluar automáticamente si los miembros habían seguido las directrices y alzaría una bandera roja si no lo hubieran hecho.

Al final, el equipo se encontró perdiendo menos tiempo luchando por lo que era un error y más tiempo trabajando para prevenir 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 de resolución de 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 apoyan la hipótesis, hacer que el enfoque sea el estándar. Pero hay mucho más que eso. A continuación se explica cómo adaptar el método científico en un entorno de conocimiento:

Si surge un problema, idealmente la persona que lo creó debería solucionarlo.

Pueden surgir problemas 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 generalmente resulta en una solución más rápida, porque las personas más cercanas a un problema generalmente saben más sobre él. Si esto no es factible, el trabajador debe participar en la aplicación de la corrección. Recordemos que en Wipro, los miembros sénior de un equipo de software verificarían el código escrito por los novatos. Si se encontró un error, los novatos, no los expertos, eran responsables de arreglarlo, con la ayuda de sus colegas mayores cuando fuera necesario. Esto garantizaba que los novicios supieran cuándo habían cometido un error y comprendían lo que había ido mal, reduciendo la probabilidad de que cometieran errores similares en el futuro.

Los problemas deben resolverse donde ocurren.

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 son mucho menos propensos a tener éxito.

En una época en la que los miembros del equipo están a menudo repartidos por todo el mundo, la idea de que todo el mundo que intenta resolver un problema debería ser capaz de verlo de primera mano podría 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 software en el sitio de un cliente de Estados Unidos; otros miembros, con sede en India, fueron responsables de corregir cualquier error que surgiera. En este caso, los miembros del equipo no sólo estaban en diferentes ubicaciones, sino que estaban en diferentes zonas horarias. Un grupo solía dormir mientras el otro trabajaba. A veces los ingenieros de la India no podían replicar los errores que sus colegas en los Estados Unidos habían encontrado y, por lo tanto, no podían solucionarlos. En última instancia, el equipo decidió que el grupo estadounidense utilizara herramientas de video web para registrar los pasos que tomaron y las configuraciones del sistema que habían producido un error; esto hizo que fuera mucho más fácil para los ingenieros de la India identificar las causas y solucionar el problema.

Resuelva los problemas tan pronto como sea posible después de que surjan.

Cuanto más fresca sea la información sobre un problema, menos sujeto será a la 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. Esta es la razón por la que Toyota hace que los empleados tire andon cables para hacer sonar la alarma cuando ocurre un problema. Incluso si instalar sistemas de alarma similares en, digamos, un bufete de abogados o un laboratorio farmacéutico no es factible, aplicar el principio detrás de ellos es. Con esto en mente, un equipo de Wipro que había estado revisando su código recién escrito semanalmente cambió a que ingenieros de primera línea verificaran el trabajo del otro diariamente, mientras que los líderes del equipo revisaban el trabajo del grupo cada dos o tres días. Se redujo la incidencia de errores.

Al usar el método científico y hacer que quien causó un error lo arregle dónde y cuándo ocurrió, una organización del conocimiento puede construir un motor de resolución de problemas que impulsa la mejora continua.

Planificar un viaje incremental

Aplicar principios delgados al trabajo de conocimiento no es simplemente una cuestión de copiar herramientas que han tenido éxito en la fabricación. En su lugar, debe 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 crear un sistema de mejora continua haciendo lo siguiente:

Empieza pequeño.

Wipro lanzó 10 proyectos piloto para explorar si un enfoque lean era una opción viable. Cuando ocho mostraron resultados prometedores, encomendó a la oficina de productividad 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.

Codificar las lecciones aprendidas.

Es importante que alguien de la organización tenga una visión general de la iniciativa; de lo contrario, un aprendizaje valioso podría perderse fácilmente. La oficina de productividad de Wipro desempeñó este papel, revisando cada proyecto lean, liderando los esfuerzos educativos y ayudando a estandarizar las prácticas.

Sigue buscando nuevas formas de trabajar.

Aunque el progreso en Wipro fue constante en lo que respecta al número de proyectos ligeros emprendidos, los directivos superiores reconocieron que la adopción generalizada era sólo una medida del éxito y que la aplicación también debía ser profunda.

Tres años después de la iniciativa «lean», todos los signos externos eran prometedores. Los empleados estaban ampliamente comprometidos, los clientes estaban expresando interés en aplicar los nuevos métodos de Wipro a sus propias operaciones de IT, y el crecimiento en el número de proyectos lean fue enorme. Sin embargo, durante su examen en curso del esfuerzo, los líderes de la iniciativa vieron que algunos equipos estaban aplicando enfoques ajustados sólo a ciertas partes de sus proyectos. Preocupados por que los equipos pudieran adoptar sólo unas pocas de las herramientas más superficialmente atractivas y no cambiar fundamentalmente 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 etapa que podrían aplicarse a diversos tipos de proyectos. Por último, reconociendo que carecían de los recursos necesarios para apoyar los esfuerzos limitados en general, decidieron centrarse en proyectos más grandes, en los que los beneficios potenciales eran mayores. Una vez concluida esta labor, cuestión de tres o cuatro meses, relanzaron el esfuerzo y aumentaron los beneficios.

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

Si el trabajo en cuestión es visionario y experimental y requiere inventar nuevas formas de realizar tareas, no trate de aplicar principios lean en todas partes. Las tareas repetitivas dentro del trabajo pueden y deben abordarse con ideas esbeltas. Pero la innovación sufrirá si el tiempo necesario para elaborar y probar ideas salvajes se clasifica como desperdicio y se elimina.

Involucre a sus gerentes

A largo plazo, los principios de 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 alguna vez, comienza allí. El personal directivo medio y superior es fundamental para poner en marcha el proceso.

Los directores de proyectos y otros líderes de nivel medio deben capacitar 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 fuertemente comprometidos en la iniciativa lean —quienes educaron a sus equipos y los convencieron de que los esfuerzos lean mejorarían el rendimiento— tuvieron más éxito que los equipos cuyos líderes no lo eran. En Wipro, el director del proyecto o un instructor lean certificado llevó a cabo la formación inicial. Luego le corresponde al director del proyecto empujar al equipo a usar las ideas.

Los líderes de alto nivel deben ser campeones a largo plazo.

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

Convertir una organización en un sistema delgado requiere una reinvención popular de cómo se realiza el trabajo. Eso 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 capacitació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 profundamente involucrado con la iniciativa de su empresa desde el principio. Él personalmente revisó proyectos lean, se reunió constantemente con los líderes de la iniciativa y habló de ello al mundo exterior. Su compromiso público dejó claro a los empleados que el programa estaba allí para quedarse.

Convertir un en un sistema delgado requiere un esfuerzo enorme e implacable. La persistencia, no el genio, es la clave.

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

1. El enraizamiento continuo de los residuos debe ser una parte integral del trabajo de cada trabajador del conocimiento.

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

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

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

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

6. Los líderes deben abrir el camino.

A version of this article appeared in the
October 2011 issue of
Harvard Business Review.


Bradley Staats David M. Upton
Via HBR.org

Related Posts
Maximizing Your Return on People

La carretera de la mente

Imaginemos un visitante estadounidense a Gran Bretaña que alquila un coche con transmisión manual y volante a la derecha. Él comienza, puestos de venta, y se reinicia una y otra vez. Él no está seguro donde el centro del carril es o lo lejos que está de otros vehículos. Si inadvertidamente se desliza en los hábitos de éxito de toda una vida de conducción, [...]
Leer más
Maximizing Your Return on People

Cuando se contrata, se prueba primero y luego se entrevista

Muchas empresas de servicios dependen de trabajadores cualificados, agradable para satisfacer a los clientes, pero la búsqueda de ellos pueden ser costosos; en algunas industrias la tasa de pérdida anual supera 50%. los mercados de trabajo débiles y click-to-aplicaciones en línea se aplican aumentar la carga sobre las empresas, que pueden llegar a cientos de candidatos por una sola abertura. Considere la industria de call center británica: En [...]
Leer más
Maximizing Your Return on People

Esos fértiles campos de recursos humanos

En teoría, los CEO generalistas están en mejores condiciones que los especialistas para navegar la miríada de funciones en el interior, y el complejo mundo exterior, paredes de sus empresas. En Japón, una de las mejores fuentes de generalistas es departamentos de recursos humanos. En su nuevo libro La Corporación Embedded: gobierno corporativo y relaciones de empleo en Japón y los Estados Unidos (Princeton, 2004), [...]
Leer más
Cuándo arriesgarse a un candidato a un puesto imperfecto

Cuándo arriesgarse a un candidato a un puesto imperfecto

Cuando evalúe candidatos para un puesto, comience por entender que nunca encontrará el candidato perfecto para el puesto, esa persona no existe. La contratación de la persona equivocada puede causar mucho daño, así que comience por usar datos para comprender los requisitos básicos del rol. A continuación, evalúe la capacidad del candidato para aprender y sus predictores de potencial, como curiosidad, confianza y motivación. A lo largo del proceso de evaluación, recoja opiniones de sus colegas y utilice comprobaciones de referencia para ayudar a medir la madurez emocional de un candidato. Es importante destacar que no debe comprometerse con defectos de carácter, como mentir y abuso.

Leer más
Maximizing Your Return on People

Seguidores: Es Personal, Too

Los artículos de este número oso testimonio lúcido especial al hecho de que el liderazgo ha perdurado como la cuestión candente para todo tipo de organizaciones y para los propios ejecutivos mientras luchan para definir sus éxitos personales (o falta de ella) en los negocios. Pero debe entenderse de manera adecuada, el liderazgo debe ser visto como lo que es: una parte [...]
Leer más