El Sistema Lean en Wipro Technologies

608- S07
16 D E OC T U B R E DE 2 0 0 6
DA VI D M. U P T O N
BRAD L E Y R . ST AAT S
El sistema Lean en Wipro Technologies
“Queremos incorporar la generación siguiente del pensamiento en base al sistema Lean a nuestros procesos
y entretejerlo en nuestro propio sistema, de modo que conduzca a una ventaja competitiva sostenible”.
—Azim Premji, presidente del Consejo de Dirección de Wipro
Sambuddha Deb (“Deb”), director de calidad y jefe de excelencia operativa de Wipro
Technologies, y Alexis Samuel, gerente general de procesos, herramientas, y productividad,
agradecieron a los asistentes a la junta de revisión del proyecto Lean (‘Esbelto’) y salieron juntos de la
sala. El día soleado de enero y las instalaciones de Wipro Technologies en Bangalore, India,
semejantes a un jardín, reflejaban muy bien el estado de ánimo de ambos en esos momentos.
Dirigiéndose a sus automóviles, analizaron el estatus de la iniciativa de la compañía sobre la base del
sistema Lean. Menos de medio año antes, habían decidido tratar de trasladar los conceptos del
sistema Toyota de producción (TPS, las iniciales en inglés), o Lean, del área de manufactura a
servicios de software, en respuesta a retos organizacionales y competitivos. En enero de 2006, la
compañía tenía terminados o en desarrollo 235 proyectos Lean.
La promesa y las posibilidades del sistema Lean eran temas de conversación en todo Wipro, fuera
en la sala del consejo de dirección o en los comedores de la compañía, diseminados por toda la India.
A pesar de los resultados positivos de la primera etapa, la implantación de la iniciativa estaba lejos de
consumarse. Wipro tenía más de 1.100 proyectos simultáneos, y menos del 15% estaba utilizando este
sistema. Hasta ese momento, el proceso había sido, fundamentalmente, de experimentación y con
escasa participación central. Deb y Alexis se preguntaban si había llegado el momento de formalizar
el planteamiento a los proyectos que venían desarrollándose en Wipro. Aunque utilizaban muchas
herramientas del Lean, ¿había otras que también deberían usar? Por último, seguían especulando si lo
que hacían era de veras el Lean. ¿Era posible contar con servicios tipo Lean de software o deberían
incorporar las mejores prácticas a su sistema, para así crear una “forma Wipro de ser”?
Perspectiva general de la empresa
Wipro Technologies (“Wipro”), subsidiaria de Wipro Ltd., competía en el mercado global de
servicios de software. La compañía prestaba servicios de integración de aplicaciones, desarrollo y
mantenimiento, además de investigación y desarrollo, y administración de infraestructuras.
Los servicios de software abarcaban numerosas áreas tecnológicas: servidores de clientes,
El caso de LACC número 608-S07 es la versión en español del caso de HBS número 9-607-032. Los casos de HBS se desarrollan únicamente para
su discusión en clase. No es el objetivo de los casos servir de avales, fuentes de datos primarios, o ejemplos de una administración buena o
deficiente.
Copyright 2007 President and Fellows of Harvard College. No se permitirá la reproducción, almacenaje, uso en planilla de cálculo o transmisión
en forma alguna: electrónica, mecánica, fotocopiado, grabación u otro procedimiento, sin permiso de Harvard Business School.
608-S07
El sistema Lean en Wipro Technologies
almacenamiento de datos, comercio electrónico, sistemas alojados, aplicaciones para empresas, redes,
soluciones para telecomunicación, y aplicaciones en base a la web. La compañía operaba en múltiples
sectores verticales, a saber, instituciones bancarias y de seguros, sistemas alojados, energía y servicios
públicos, servicios financieros, atención médica, manufacturas, medios de comunicación, comercio al
menudeo, tecnología, telecomunicaciones, y transportes.
A fines de 2005, Wipro tenía 35.000 empleados, y atendía a clientes de todo el mundo a través de
oficinas en más de 30 países (véase en el Anexo 1 un resumen estadístico de la compañía). En el año
fiscal 2005 reportó ingresos de 1,2 mil millones de dólares. En los últimos cuatro años había crecido
velozmente, a una tasa anual compuesta de 37%. Los ingresos se distribuían globalmente: Estados
Unidos representó el 67%, Europa el 27% y el resto del mundo 6% de los ingresos totales durante el
año fiscal 2005. Más del 95% de los empleados tenía estudios profesionales en ciencias o ingeniería,
que habían terminado antes de contratarse en la empresa.
Si bien Wipro era un proveedor de servicios de software subcontratados, también participaba en
proyectos in situ (en las instalaciones del cliente) y en proyectos intramuros (en sus propias
instalaciones, principalmente en la India). En 2005, la compañía llevó a cabo intramuros el 75% de su
trabajo, e in situ el 25%. Presiones de costos (el trabajo intramuros era relativamente más barato) y la
escasez de visas de trabajo (sobre todo en Estados Unidos) la obligaban a realizar más proyectos
intramuros. Wipro cobraba sus proyectos recurriendo a dos criterios. El criterio inicial, conocido
como “tiempo y materiales”, implicaba cobrar a una tasa previamente especificada el número real de
horas que los ingenieros de software invertían en un proyecto, además del costo de cualquier
software o herramientas necesarias. Aplicando un criterio más reciente, conocido como “proyecto a
precio fijo”, Wipro cotizaba un precio garantizado por el trabajo y luego se hacía responsable de
entregar al cliente el producto final. Cualquier esfuerzo adicional efectuado en un proyecto a precio
fijo era responsabilidad de Wipro. En 2005, aproximadamente 80% de los ingresos provinieron de
trabajos cobrados con el criterio “tiempo y materiales”, y 20% con el criterio “proyecto a precio fijo”.
El porcentaje que provenía de este último iba creciendo a medida que los clientes se entendían mejor
con proveedores de servicios subcontratados de software y administraban sus costos con mayor
determinación. Por lo demás, el criterio “proyecto a precio fijo” resultaba atractivo a Wipro conforme
acrecentaba su destreza manejando la rendición de cuentas de principio a fin, y a medida que
aumentaba su interés en conservar los beneficios de sus esfuerzos para mejorar la productividad.
Servicios de software
El proceso de desarrollar software se parece mucho al proceso de construir una casa. El primer
paso para construir una casa consiste en especificar los requisitos necesarios para la solución. Ello
podría incluir la determinación del número de metros cuadrados, los pisos, los dormitorios, los baños
y demás. Una vez especificados los requisitos, arquitectos, e ingenieros crean diseños detallados, que
no sólo especifican la ubicación de las habitaciones y los acabados, sino también dónde se localiza la
infraestructura eléctrica y la plomería. Sólo entonces comienza el proceso de construcción. Durante la
construcción se detectan y corrigen defectos en los planos. A lo largo de la construcción, el trabajo se
inspecciona para detectar deficiencias. Los sistemas se ponen a prueba una vez que han sido
terminados (por ejemplo: el sistema de aire acondicionado), y la casa entera se inspecciona cuando ya
está lista: primero lo hace el constructor y a fin de cuentas el cliente que la compra. En el desarrollo de
software se dan las mismas etapas básicas, en la mayoría de los proyectos, pero la terminología es
diferente: especificación de requisitos, diseño detallado, pruebas de codificación y de unidad,
pruebas del sistema, y por último pruebas para la aprobación del usuario. Una diferencia que hay
entre construir una casa y desarrollar software reside en que el progreso o la forma que tendrá lo que
se lleva a cabo, a menudo no es visible para el usuario, sino hasta que se le presenta el producto o
servicio final.
2
El sistema Lean en Wipro Technologies
608-S07
Los servicios de software son un negocio distinto a los paquetes de software para consumidores
(por ejemplo: Microsoft Word), o a los sistemas de software para empresas (por ejemplo: la
Planeación de Recursos de la Empresa, ERP, las iniciales en inglés). Gran parte del trabajo realizado
en Wipro no consistía en partir de cero, sino, más bien, implicaba adaptar, ligar, y respaldar sistemas
de software ya existentes. Dado que no se empezaba trabajo alguno a menos de que un cliente lo
solicitara, la incertidumbre tanto técnica como de mercado solía ser menor para Wipro que para un
desarrollador de aplicaciones de software. Sin embargo, solía ser grande la complejidad del proceso,
pues Wipro atendía cientos de proyectos (con exigentes requisitos de calidad) al mismo tiempo. Deb
definió así el negocio: “No construimos toda una casa para una persona. Más bien, añadimos la
terraza en la parte de atrás. No obstante, tenemos que conocer bien la casa que ya está en pie, sus
cimientos y diseño, antes de añadir la terraza”.
Hay otras dos distinciones importantes en el tipo de trabajo realizado en Wipro. La compañía se
dividía en tres unidades de negocio independientes, vinculadas al cliente: soluciones de ingeniería de
producto (integradas por telecomunicaciones y sistemas alojados); soluciones para empresas; y banca,
finanzas, ahorro, y seguros. Originalmente, los proyectos realizados por la unidad de soluciones de
ingeniería de producto implicaba brindar respaldo para el software de un producto (por ejemplo: los
controladores de una impresora). Al paso del tiempo, la compañía comenzó a desarrollar software.
En fecha más reciente, los clientes subcontrataban subsistemas enteros, no sólo software
simplemente. Wipro comenzaba a responsabilizarse del mantenimiento y mejoramiento de productos
maduros o de ocaso.
El trabajo en soluciones de ingeniería de producto solía ser responsabilidad del director de
tecnología de la compañía cliente. Pero el trabajo en soluciones para empresas, así como los proyectos
en banca, finanzas, ahorro, y seguros, caían por lo general dentro de la esfera del director de
información de la compañía cliente. Los trabajos de estas dos unidades de negocio eran usualmente
de dos tipos generales: mantenimiento o desarrollo. Los proyectos de mantenimiento implicaban
respaldar y acrecentar los sistemas ya existentes de un cliente. Un proyecto usual de mantenimiento
consistía, por ejemplo, en respaldar el sistema de planeación de recursos empresariales de alguna
compañía. Wipro podría componer defectos que la compañía hubiera identificado y diseñar software
para añadir funcionalidad al sistema. Un proyecto de desarrollo, por su parte, implicaba construir,
integrar o modernizar sistemas de informática. Proyectos de desarrollo eran, por ejemplo: crear un
nuevo sitio web sumamente interactivo, trasladar de Palm OS a Windows CE la aplicación para
ventas móviles de una compañía, y desarrollar un nuevo sistema de administración para
distribuidores, a fin de rastrear incentivos, presentar informes y hacer pagos.
Iniciativas anteriores de calidad
Wipro siempre se había distinguido en el mercado por la calidad de su trabajo. Anurag Behar, el
predecesor de Deb después de entrar a Wipro en 2002, una vez que se separó de General Electric,
definió así el enfoque de la compañía en la calidad:
Antes de unirme a Wipro, mi impresión es que se trataba de una organización
enfocada en la calidad en sentido amplio y en el desempeño óptimo en todos los
contextos. Con frecuencia he comprobado que la visión externa de una situación es
mejor que la visión interna. Pero no fue así al entrar en Wipro. Es común que las
personas que más odian la calidad son los vendedores, ya que son los que se la
pasan escuchando las quejas de los clientes a causa de lo que sale mal. En Wipro
simplemente no es así: los vendedores aman nuestra calidad.
3
608-S07
El sistema Lean en Wipro Technologies
Gran parte del enfoque en la calidad surgió de la desconfianza a la que en un principio Wipro se
enfrentó cuando, a fines de los años 80 y principios de los 90, entró al mercado internacional de los
servicios de software, en el cual compitió más adelante. Los clientes globales se mostraron escépticos
y dudaron que una pequeña compañía de la India fuera capaz de suministrar el software de gran
calidad que necesitaban en sus negocios. Por eso Wipro se concentró en criterios sumamente públicos
en torno al mejoramiento del proceso, con el fin de demostrar su determinación a ofrecer calidad
elevada. En 1995, Wipro fue una de las primeras compañías de software en certificarse con la norma
ISO 9000 (véase en el Anexo 2 una tabla del proceso de Wipro en las iniciativas para mejorar
procesos).
En los años 80, el Departamento de Defensa de Estados Unidos financió el Software Engineering
Institute (SEI, Instituto de Ingeniería en Software) en la Universidad Carnegie Mellon, encargándole
“impulsar el progreso del estado de la práctica de la ingeniería en software”.1 El SEI estableció el
“Modelo de Madurez en Capacidad (CMM, las siglas en inglés)” para software, y en 1998 Wipro pasó
a ser la primera compañía de servicios de informática en el mundo que llegó a satisfacer los requisitos
del nivel 5. En 1997, inspirada por una empresa conjunta entre otra subsidiaria de Wipro Ltd y
General Electric, la empresa fue la primera en introducir el Six Sigma a los servicios de software.
Hacia el año 2000, Six Sigma había florecido en Wipro Technologies. Motorola fue la primera
compañía en introducir el Six Sigma en un entorno de manufactura, y General Electric rápidamente
se convirtió en su exponente más famoso. El Six Sigma recurre a técnicas estadísticas, instructores
llamados “cintas negras” (Cinturón negro, como en las disciplinas orientales karate, yudo, etc.) y, por
lo general, a un proceso DMAIC (siglas en inglés para Definir, Medir, Analizar, Mejorar, Controlar)
para tratar de reducir el total de defectos a 3,4 defectos en cada millón de oportunidades.
Más tarde, en 2002, el SEI introdujo una nueva versión del Modelo de Madurez en Capacidad, el
CMM Integrado (CMMI), y Wipro se convirtió en la primera compañía del mundo con certificado de
nivel 5 en tal modelo. Sus iniciativas en el proceso de mejoramiento le permitieron lograr mejoras
constantes en calidad, en adhesión a calendarios, y en adhesión a esfuerzos (véase en el Anexo 3
detalles al respecto desde 1995 a 2004). Hacia 2004, Wipro advirtió que se estancaban sus iniciativas
en el proceso de mejoramiento, acerca de lo cual comentó un líder en calidad de la compañía:
“Las iniciativas de calidad duraban entre año y medio y dos años, tal vez tres años
si uno tenía suerte. La razón de esto era que cada iniciativa se enfocaba en procesos
de control más avanzados, a comparación de los anteriores, o bien, en nuevas
técnicas, como el uso del control del proceso estadístico en el Six Sigma, y cada uno
rendía menos al paso del tiempo. Nosotros sabíamos si ya había llegado la hora de
comenzar a buscar algo nuevo.”
Retos en 2004
En 2004 Wipro se enfrentaba a retos tanto estáticos como dinámicos. A dos hechos estáticos se
enfrentaban todos los proveedores de servicios de software. En primer lugar, la clave para desarrollar
software eran ingenieros talentosos en software. De acuerdo con el cliché, los ingenieros en software
serían gente tozuda e independiente, que considera un arte su labor y gusta de hacer las cosas a su
manera. Muchos de ellos aceptaban la validez del estereotipo. En segundo lugar, los servicios de
software eran, en sí, un negocio variable. Los proyectos se personalizaban para cada cliente y, por lo
mismo, eran de carácter bastante sui generis. Dado que buena parte del trabajo de Wipro consistía en
amalgamar sistemas de informática diversos, los retos específicos a los que se enfrentaba cada
1 Software Engineering Institute, “About the SEI”, sitio web del Instituto, http://www.sei.cmu.edu/about/about.html.
4
El sistema Lean en Wipro Technologies
608-S07
proyecto recibían un fuerte impacto no sólo por el tipo de sistemas que eran integrados (de manera
un tanto uniforme en todos los proyectos), sino también por la forma (sui generis en todos los
proyectos) en que el cliente había implantado tales sistemas en su negocio. Además de estos desafíos
incesantes, estaban los cambios dinámicos que tenían lugar en el mercado.
Cuestiones organizacionales
Aunado al sentir de la compañía de que su actual iniciativa de calidad iba caducando, Wipro se
enfrentaba a varios retos organizacionales. A fines de 2003, la empresa tenía casi 18.000 empleados,
40% más que el año anterior. Además del aumento general de la plantilla, en la mayoría de las
empresas hindúes de servicios de software (Wipro entre ellas) las bajas por edad avanzada eran en
promedio del 10% al 20% anuales. La veloz entrada y rotación de personal significaba que cualquier
software (procesos) utilizado en la compañía tenía que ser lo bastante sólido para suministrar
orientación necesaria a los nuevos miembros del equipo, y proporcionar a los gerentes controles para
monitorear el desempeño.
Por lo demás, el trabajo en Wipro siempre se había llevado a cabo aplicando un método vertical.
Los gerentes de proyecto tenían la responsabilidad de crear un plan detallado para los proyectos
utilizando Microsoft Project, después de lo cual asignaban roles específicos a los miembros del
equipo. Explicó Alexis Samuel: “No se aprovecha el poderío latente en los ingenieros con el esquema
actual”, y la compañía deseaba un planteamiento del proceso que “conserve algunos de los beneficios
de la Empowerment que se brinda a los miembros del equipo”.
Por último, Wipro registraba variaciones considerables en el desempeño de cada una de las
unidades de negocio que la constituían. En parte, estas variaciones eran consecuencia de las
características de la industria atendida por las unidades de negocio. Pero otras muchas variaciones
nada tenían que ver con ello. La compañía contaba con un sistema para administrar el conocimiento
que le daba ciertos buenos resultados. Sin embargo, persistía la impresión de que las mejores
prácticas en una parte de la empresa no se reproducían con éxito en otras unidades de negocio.
Cuestiones relativas a la competitividad
Además de los desafíos organizacionales, Wipro tenía ante sí un panorama estratégico dinámico.
La compañía se había diferenciado en el mercado, desde siempre, por ser un proveedor de bajo costo
y alta calidad. Si bien sus costos eran menores que los de los principales competidores internacionales
(por ejemplo: IBM, Accenture y EDS), la ventaja se iba reduciendo conforme la demanda en la India
de ingenieros talentosos en software seguía incrementando su precio (los salarios aumentaban el 12%
anual en promedio); aunado a esto, los competidores internacionales acrecentaban su presencia en el
país, con la intención de sacar partido a los mismos recursos de bajo costo que Wipro aprovechaba.
Asimismo, aunque firmas más pequeñas en otros países de bajos salarios ejercían presión sobre
Wipro (por ejemplo: China, Filipinas, Vietnam, y Rusia), una de las mayores amenazas provenía de
nuevas compañías hindúes. Deb describió así el desafío: “Cada año se gradúan en la India más de
380.000 ingenieros en software, bien preparados y que hablan inglés. En la India, constantemente se
renuevan los recursos para ejecutar una estrategia sencilla y de bajo costo.”
Por otra parte, pese a que el mercado reconocía en Wipro un líder en calidad, sus competidores
iban reduciendo la brecha en ese renglón. “Un reto enorme para nosotros”, aseguró Alexis, “es que
de tres años a la fecha los demás están alcanzando a Wipro”.
Por último, Wipro creía advertir un cambio significativo en el mercado. Dentro de la empresa se
tenía la visión de que la informática iba dejando atrás la producción al modo artesanal y se
presentaba la oportunidad de convertirse en un líder de procesos. Explicó Anurag:
5
608-S07
El sistema Lean en Wipro Technologies
En mi opinión, la informática está en el mismo lugar que la industria del automóvil
en 1910 -1920. En la actualidad, cada organización hace su trabajo en forma muy
particular; todavía estamos produciendo artesanalmente. Sin embargo, hay mucha
ineficiencia que es posible eliminar, y el mercado es demasiado competitivo como
para no eliminarla. Nosotros advertimos que esto precisamente está ocurriendo. La
ola entera de subcontratación y globalización demuestra que tiene lugar toda una
transición. Hoy por hoy es necesario ser capaces de entenderse con 10.000 mentes,
y de una manera uniforme. Todavía no sabemos cómo lograrlo en el negocio del
software, pero el sector de manufactura sí sabe hacerlo. En una fábrica, la cuestión
no consiste en comprar máquinas, sino en manejar gente. De modo que, ahora, la
clave está en hacer que 10.000 trabajen juntas. Entonces, si se presupone que esto es
lo que va a suceder, ¿lidera uno o sigue? Si uno se decide a liderar, hay dos formas
de hacerlo. La primera es usar la marca tal como lo hace IBM. La segunda es
convertirse en el competidor más eficiente. Nosotros no podemos ser líderes de
marca en la coyuntura actual. Así que no tenemos otra opción que la de apostarle a
la eficiencia.
Cuestiones relativas al cliente
Además de las dificultades organizacionales y el entorno competitivo, Wipro descubrió que la
demanda de los clientes también atravesaba por cambios perceptibles. En primer lugar, el enfoque
del mercado en la competencia cambiaba más allá de la simple exigencia por mayor calidad. SM Bala,
jefe de calidad en la unidad de soluciones de ingeniera de producto, describió así la situación:
Los clientes comienzan a dar por supuesta la calidad, como si fuera algo
objetivo y ya dado. A medida que se vuelven más exigentes, comienzan a utilizar
el costo para impulsar el desempeño de su proveedor de servicios subcontratados
de software, en lugar de usar la calidad.
En un principio, el cliente pedía verificaciones y un enfoque externo en la
calidad, debido a que quería estar seguro de que los proveedores manejaran bien el
trabajo que les había encargado. Ahora, el cliente tiene la expectativa de obtener
rebajas de costos, a medida que mejora la calidad. Además, el mercado sigue
cambiando: descarta contratos bajo el criterio tiempo y materiales, en los que el
cliente corre con el riesgo de que tengan que realizarse tareas adicionales, y
prefiere contratos a precio fijo, en los que nosotros corremos con tal riesgo.
Pero los clientes no sólo tenían la expectativa de que se les ofreciera precios más bajos:
también comenzaban a solicitar un producto diferente. En 2004 desearon que el proveedor de
servicios de software les ofreciera una ventaja comercial. Dado que los clientes querían soluciones
comerciales, las soluciones técnicas ya no bastaban. El desafío para Wipro consistió en que, en ese
momento, sus estándares eran estándares de proceso, no estándares de proceso comercial. Partiendo
de una especificación técnica, se optimizaban las rutinas existentes para ofrecer un producto muy
fiable, que cumplía con la especificación. La compañía no estaba tan bien preparada para ofrecer una
solución comercial al cliente. SM Bala definió el problema en estos términos:
Es necesario ligar el enfoque comercial a enfoque de proceso. Mediante el Modelo
de Madurez en Capacidad (CMM) nos hemos vuelto muy buenos manejando
6
El sistema Lean en Wipro Technologies
608-S07
procesos. Sin embargo, en realidad no sabemos cómo manejar personas. En los
sondeos acerca de la satisfacción del cliente, ellos nos dicen: “Ustedes son muy
buenos para hacer lo que les pido. Si les pido que me construyan una mesa de tres
patas, me la hacen. Pero nunca me preguntan por qué la mesa debe tener sólo tres
patas”. Los clientes quieren que les demos ideas innovadoras. A lo mejor ni ellos
saben [lo que quieren], pero sí se dan cuenta cuando Wipro no les cumple.
Implantación del sistema Lean
En virtud de todos los factores antes mencionados, al comenzar 2004, la dirección de Wipro
decidió que era hora de plantearse nuevamente la mejora del proceso. Su objetivo fue una
metodología que mejorara tanto la calidad como la innovación. Después de debates internos, la
dirección formuló una lista de tres alternativas: los criterios del Premio Nacional Malcolm Baldridge
a la Calidad, TRIZ (siglas en inglés del término ruso ‘Teoría para Solucionar Problemas con
Inventiva’), y el sistema Lean. Después de algunas discusiones la alta dirección escogió la tercera
alternativa, considerándola mejor que las otras, ya que la primera se enfocaba demasiado en la
calidad, y la segunda demasiado en la innovación. Y decidió también que utilizaría el Lean en forma
distinta a como había manejado la iniciativa fundamental anterior, el Six Sigma. Deb se refirió a la
implantación del Six Sigma en estos términos:
Aplicamos el Sigma Seis verticalmente, y fue algo sensacional. Se nos fue mucho
tiempo ideando un método Six Sigma para aplicarlo al software, y luego lo
introdujimos a los niveles inferiores de la organización. La idea dio resultados, la
eficacia aumentó, pero no la dedicación. El equipo tardó mucho en aceptarlo. Por
eso decidimos hacerlo de otra forma con el Lean. Sabíamos que se abría la
posibilidad de que el impacto fuera menor, pero confiamos en que la aceptación
sería mayor.
Wipro comenzó el proceso con el Lean integrando un equipo base de diez personas. Entraron en
el equipo Deb, Alexis, Ravishankar Kuni, jefe de la oficina de productividad, y su gente (un grupo de
cuatro personas que supervisaría la implantación del Lean a medida que fuera expandiéndose), otros
líderes de calidad y miembros de la alta dirección. La primera meta de la organización fue
familiarizarse bien con el Lean, a fin de saber cómo “trasladarlo” a los servicios de software. El
equipo base comenzó leyendo todo lo que tuviera al alcance acerca de este sistema. De enero a marzo
de 2004, sus integrantes visitaron diversas compañías de manufactura que utilizaban procesos Lean.
Una de esas visitas fue a una planta de Toyota ubicada cerca, y también a plantas en el igualmente
cercando Tamil Nadu, que habían ganado el prestigioso Premio Deming. Después entrevistaron
consultores, a fin de dar con alguien que los orientara durante el proceso. Deb recordó la junta clave
con una firma global muy importante de consultoría en estrategia:
De entrada nos dijeron que no tenían experiencia previa implantando el Lean en
software, y que tendrían que ir aprendiendo con nosotros. Conversamos con
algunos expertos japoneses y dijeron lo mismo. Así pues, dado que nadie había
aplicado el Lean al software, no iba a ser posible aplicar una solución de eficacia
comprobada. Nosotros, solos, tendríamos que hacerlo todo.
7
608-S07
El sistema Lean en Wipro Technologies
A fin de cuentas Wipro recurrió a consultores japoneses familiarizados con el Lean en entornos de
manufactura. “Fueron de mucha utilidad porque nos abrieron los ojos”, explicó Anurag. “No
aportaron soluciones, pero enriquecieron la discusión. Fuimos mejorando a medida que aumentaban
las preguntas. En cada discusión descubrimos algo nuevo”.
Deb sintetizó así las lecciones principales que aprendieron durante el proceso: “El objetivo no fue
hacer teorías, sino de hacer cosas”. Y para lograrlo, el equipo base decidió que cada uno de sus
miembros escogería un proyecto, lo pondría en marcha, y presentaría resultados en dos o tres meses.
El equipo base debió dedicarse a ello en paralelo al trabajo normal que cada quien tenía que sacar
adelante. No se tenía autoridad formal para obligar a los gerentes de proyecto a que participaran. No
obstante, cada uno de los miembros disponía de suficiente capital organizacional para “atraer” gente
a un proyecto. Uno de los primeros gerentes describió así el proceso:
El [miembro del equipo base] me buscó y dijo que yo iba a utilizar el sistema
Lean en este proyecto. Me pidió comprar dos libros acerca del tema 2 y luego me
asesoró durante dos días en torno al sistema. Me ayudó a desbaratar el plan original
para el proyecto y crear un plan de acuerdo con el Lean. Durante las primeras tres
semanas andaba yo muy confundido, ni siquiera sabía explicarle al equipo qué cosa
era este sistema. Me reunía con el equipo semanalmente, dedicando 3 o 4 horas para
enseñarles el Lean. Durante las reuniones, enumeraba ideas tomadas del Sistema de
Producción Toyota para que las analizaran y luego les pedía que hicieran tormentas
de ideas.
El equipo base instaló una sala electrónica de guerra para compartir las experiencias obtenidas en
los diferentes proyectos. A fines de octubre de 2005, analizó los resultados y concluyó que el primer
experimento había logrado ocho éxitos en diez proyectos. Se consideró exitoso un proyecto, si lograba
una mejora superior al 10% en relación con los parámetros previos y específicos de desempeño para
tal proyecto. Con una tasa de éxito del 80%, el equipo base decidió seguir adelante con la
implantación del sistema.
El paso siguiente, en noviembre de 2004, fue una sesión de capacitación, de un día de duración,
con 35 gerentes de calidad. En Wipro se asignaba a cada proyecto un integrante del personal de
aseguramiento de calidad en software (SQA, las iniciales en inglés), con la misión de supervisar la
calidad y la productividad, y también para monitorear el cumplimiento del proceso. Era común que
el personal de aseguramiento trabajara en un mínimo de cinco y un máximo de diez proyectos a la
vez. Por otra parte, en esas fechas Azim Premji, presidente del consejo de Wipro, hizo público que la
compañía estaba aplicando el sistema Lean a los servicios de software y tenía la expectativa de
obtener una ventaja competitiva considerable gracias al cambio. “Azim comunicó que utilizábamos el
Lean”, señaló cierto director, “con lo cual puso de manifiesto el compromiso de la dirección. Eso tal
vez fue prematuro. Pero de cualquier manera, ahora teníamos que cumplir.”
En agosto de 2005, un año y ocho meses después de poner en marcha la iniciativa del Lean, había
en Wipro 112 proyectos terminados o a punto de serlo en base al sistema. En enero de 2006 la cifra
llegó a 235 proyectos. Algunas unidades de negocio ya habían sostenido sesiones de medio día de
duración con los gerentes de proyecto, a fin de capacitarlos en el sistema. “El Lean es un proceso
lento”, dijo Ravishankar Kuni, jefe de la oficina de productividad, describiendo los avances. “Es un
cambio de estilo directivo. Es un cambio de cultura.”
Pese a su tamaño, relativamente pequeño, la oficina de productividad desempeñó un papel de la
mayor importancia en la implantación del Lean a lo largo y ancho de Wipro. Dado que los
2 Lean Thinking y The Toyota Way.
8
El sistema Lean en Wipro Technologies
608-S07
integrantes de esta oficina asesoraban cada proyecto de acuerdo con los principios del Lean, la oficina
funcionó como un centro de intercambio de información que confirió claridad al pensamiento de la
organización en torno al sistema. Asimismo, la oficina de productividad desarrolló muchos de los
nuevos conceptos Lean durante las primeras fases, y asesoró a los gerentes de proyecto a la hora de
hacer nuevos experimentos. Aseguró Kuni: “Cuando el horizonte se nublaba y no sabíamos qué
significaba el Lean en los servicios de software, la oficina de productividad fue como una brújula
para la organización.”
El Lean en Wipro
Procedimiento estándar de operación
Según se explicó más arriba, la nueva versión del método de madurez en capacidad (CMMI) fue el
criterio general que Wipro utilizó para mejorar el proceso.3 Existían, además, varios Ciclos de Vida
para Desarrollar Software (SDLC, las iniciales en inglés) que satisfacían los requisitos del CMMI, y a
éstos recurría Wipro para terminar proyectos específicos; algunos ejemplos son: modelos en cascada,
modelos reiterativos, y modelos enfocados específicamente en el cliente. El método en cascada era, y
con mucho, el ciclo de vida comúnmente utilizado en Wipro. En el método en cascada (parecido al
modelo fase–puerta para desarrollar productos), un equipo determinaba los requisitos del cliente,
preparaba el diseño detallado en un documento, formulaba un código, hacía pruebas de unidad,
integraba las diversas partes del proyecto, hacía pruebas de sistema y luego lo entregaba al cliente.
El proceso avanzaba en forma lineal y, de haber retroalimentación en el sistema, ésta tenía lugar sólo
entre las fases sucesivas. Wipro reconocía que el método en cascada era predecible y se prestaba a ser
llevado a escalas mayores. Sin embargo, presentaban ciertas desventajas en cuanto a flexibilidad.
En Wipro, todos los proyectos debían apegarse al marco de referencia propuesto por la nueva
versión del modelo de madurez en capacidad. Los gerentes de proyecto utilizaban el Veloci–Q, el
sistema interno de la compañía, a fin de presentar planes para proyectos, diseñar documentos y
documentación adicional necesaria.
Proyectos utilizando el Lean
La compañía pensaba que satisfacer las exigencias del CMMI al nivel 5 seguía siendo un estándar
externo de importancia; de ahí que, en su forma inicial, se implantó el Lean operativamente, a nivel
de proyecto, como un ciclo de vida que satisfizo los requisitos del CMMI. No existían requisitos
centralizados para considerar que un proyecto dado era un proyecto Lean. Con todo, se exigía que un
proyecto Lean utilizara necesariamente las diversas contramedidas (countermeasures) estipuladas por
el sistema. La oficina de productividad llevaba un registro de los proyectos de este tipo y cada mes
llevaba a cabo revisiones, en cuyo marco los equipos informaban acerca de sus avances. Algunas
unidades de negocio enviaron a líderes de negocio a tales reuniones; otras, en cambio, se limitaron
nada más a la supervisión del personal de aseguramiento de calidad en software. De acuerdo con la
expectativa inicial, un proyecto Lean tenía que dar resultados en dos o tres meses. Los proyectos que
3 Por esas fechas tenía lugar una “batalla” metodológica entre los partidarios del CMMI y los usuarios de los métodos ágiles de
programación (ejemplos: Extreme Programming (XP), Scrum, Crystal). Algunos adeptos a la programación ágil argumentaban
que el CMMI creaba un proceso sin otra justificación que el proceso mismo, y producía software fiable y de alta calidad sin
satisfacer las necesidades del cliente. Por su parte, los partidarios de CMMI sostenían que los métodos ágiles producían hacking
sin ton ni son, y que eran adecuados sólo para proyectos pequeños y muy especiales. Al igual que en la mayoría de las
divergencias, la verdad se hallaba en algún punto intermedio, de modo que ya se había trabajado para armonizar ambos
planteamientos. En agosto de 2005, estimulada en parte por las exigencias de su clientela, Wipro experimentaba con diez
proyectos pilotos en base al método ágil, con el fin de comprobar si resultaba apropiado para su negocio bajo ciertas
circunstancias.
9
608-S07
El sistema Lean en Wipro Technologies
llevaran más de seis meses sin mostrar impacto alguno, eran cancelados como proyectos Lean. La
consecuencia de la expectativa temporal fue que los primeros proyectos Lean consistieron a menudo
en aspectos parciales de un proyecto grande, o bien, en la intervención en un proyecto afectado por
inconvenientes exógenos y que, por lo mismo, exigía un nuevo planteamiento para salir adelante (por
ejemplo: que un cliente adelantara la fecha límite, o que un equipo se retrasara). La meta de la
iniciativa Lean fue lograr un incremento del 10%, o mayor, según los parámetros previamente
especificados (calendario, esfuerzo, o calidad) para el proyecto. La compañía daba seguimiento
riguroso a los parámetros de desempeño en todos los proyectos, lo cual le permitió medir
cuantitativamente el impacto de los proyectos Lean. Deb definió así la razón de ser de la meta del
10% o más:
Si la meta era demasiado baja, digamos que una mejora de 2–3%, lo único que el
gerente debía hacer era presionar a su equipo para lograrla. Algo así no habría sido
suficientemente sostenible. Fue necesario fijar una meta que sólo podría lograrse
cambiando nuestra forma de operar.
Cuando un gerente de proyecto se proponía lanzar un proyecto en base al sistema Lean, el
personal de aseguramiento de calidad asignado a él y uno de los integrantes de la oficina de
productividad le brindaban apoyo mediante reuniones, conferencias telefónicas, y documentos
conceptuales acerca de las contramedidas del Lean. Por lo general, cuando un nuevo equipo
comenzaba un proyecto aplicando el Lean, el gerente podía escoger entre pedir al personal de
aseguramiento que llevara a cabo una breve sesión de capacitación para su equipo, o capacitarlo él
mismo. Por lo demás, cada gerente de proyecto tenía la libertad de escoger las contramedidas del
Lean que considerara apropiadas para su proyecto. En enero de 2006, a ninguno de ellos no se les
exigió realizar proyectos en base al Lean. Las unidades de negocio tenían metas para el número de
proyectos Lean que debían terminar; no obstante, ello no fue incorporado directamente a las metas y
objetivos de los gerentes en lo individual. Se dio cierto debate interno acerca de si la realización de un
proyecto Lean debía ser parte de las metas y objetivos de cada gerente de proyecto para el año fiscal
2007.
Las contramedidas estipuladas por el Lean
Para enero de 2006, Wipro había puesto a prueba numerosos criterios en base al Lean para
resolver problemas (“contramedidas”).4 Si bien no existía un sola forma de aplicar el Lean en la
organización, en cada proyecto en base a este sistema se recurría comúnmente a varias de las
medidas de remedio detalladas enseguida.
Justo a tiempo / flujo pieza por pieza Al nivel de proyecto, cada proyecto en Wipro se efectuaba
en base al principio “justo a tiempo” y utilizaba el flujo pieza por pieza, ya que la labor en un
proyecto no empezaba sino hasta que un cliente lo solicitaba. Sin embargo, dentro de un proyecto
había oportunidad de terminar en forma secuencial cada uno de los pasos de producción necesarios.
4 Toyota utiliza el término “contramedida”, en lugar de “solución”, para definir sus diversas herramientas y técnicas. Ello se
debe a que cada respuesta se considera el medio para un fin (por ejemplo: reducir el desperdicio), más que una respuesta en sí
y de por sí. Información adicional al respecto se encuentra en Steven Bear y H. Kent Bowen, “Decoding the DNA of the Toyota
Production System (‘Decodificación del sistema Toyota de producción’)”, Harvard Business Review, septiembre y octubre de
1999, pp. 97–106.
10
El sistema Lean en Wipro Technologies
608-S07
En cierto proyecto de conversión de un sitio web, Wipro actualizaba y modernizaba el sitio web
de una compañía muy importante. El sitio web anterior consistía de páginas web construidas encima
de 680 páginas de servidor Java. Cada página web podía reproducir múltiples páginas de este tipo.
Antes, al trabajar en un proyecto de conversión como éste, el gerente de proyecto pedía qué
miembros de su equipo convirtieran todas las páginas de servidor Java, mientras que otros trabajaban
en las páginas web que las reproducían. En este proyecto, en cambio, el equipo movió cada página
web mediante desarrollo en un proceso de flujo pieza por pieza, y trabajó en una página de servidor
Java sólo cuando una página web la reproducía. Recurriendo a este procedimiento, el equipo
descubrió que 200 de las páginas de servidor Java (alrededor del 30%) no eran reproducidas por
páginas web y, por lo tanto, no exigían conversión.
Reunir el problema y la solución Uno de los objetivos principales del Lean es reunir el problema
y la solución en tiempo, espacio, y persona. Ello reduce las variaciones y aumenta la oportunidad de
aprender. Wipro identificó un método reiterativo para el diseño, a fin de aprovechar esta lección.
Recurriendo a un ciclo de vida para desarrollar software, del tipo reiterativo, el equipo siguió los
mismos pasos de desarrollo estipulados en el modelo en cascada; no obstante, el ciclo se repitió varias
veces, añadiendo cada vez mayor funcionalidad a cada ciclo.
La reiteración desempeñó un papel importante en cierto proyecto de telecomunicaciones. Una
gerente de proyecto lanzaba un nuevo proyecto para un cliente de años y decidió incorporar los
principios del sistema Lean por primera vez. Lo usual era que los proyectos de este cliente tardaran
un año y utilizaran un ciclo de vida en cascada. Esta vez, la gerente y su arquitecto usaron
herramientas tales como la matriz de diseño de estructuras (descrita más abajo), y dividieron el
proyecto en cinco fases. Después consultaron al cliente para definir las prioridades de cada fase, y
comenzaron a trabajar en la primera.
Una vez que el equipo terminó la primera fase, el cliente decidió cambiar el proyecto de .Net a
Java (con la consecuencia de que era necesario cambiar el lenguaje del software y la arquitectura). El
equipo carecía de los conocimientos imprescindibles, de modo que tuvo que capacitarse en el sistema
Java durante dos semanas. A fin de maximizar el aprendizaje específico, relativo al proyecto, la
gerente trabajó con el equipo de capacitación para aprovechar lo hecho en la primera fase, y utilizarlo
como ejemplos y ejercicios de capacitación. Dado que todos habían trabajado juntos durante la
primera fase, ello suministró un medio eficaz para enseñar el material nuevo (a diferencia del primer
procedimiento, en el cual cada quien habría trabajado en sus tareas respectivas, y el trabajo no se
había integrado aún). La combinación de los principios del Lean aceleró la tasa de aprendizaje y
mejoró el desempeño. Así, a pesar del cambio de tecnología, el equipo fue capaz de terminar el
proyecto tres meses antes de los quince fijados como plazo límite. “Antes, lo normal era que
comenzáramos despacio”, dijo la gerente, refiriéndose al cambio. “Y al final acabábamos trabajando
como bomberos. El Lean de veras redujo los tiempos de espera y nos permitió terminar exitosamente
el proyecto, y dentro de un plazo reducido”.
Matriz de diseño de estructuras Uno de los desafíos clave para Wipro al utilizar un modelo
reiterativo, consistía en definir qué debía entrar en cada reiteración. Aunque la literatura de
ingeniería en software no hacía una recomendación definitiva, la compañía adaptó la matriz de
diseño de estructuras a la tarea. Se trata de una matriz binaria y cuadrática, que en el caso de Wipro
usaba la actividad o funcionalidad exigida como material de alimentación. Se coloca uno en la matriz
para indicar una dependencia hacia adelante (colocada debajo de la diagonal) o un bucle de
retroalimentación (colocado encima de la diagonal). Después de que se puebla la matriz inicial, el
paso que sigue es partir la matriz. Se hace la partición a fin de que las tareas independientes (es decir,
las tareas en sentido ascendente) se programen con anterioridad a sus contrapartes dependientes (es
decir, las tareas en sentido descendente), y las funcionalidades dependientes entre sí se programan
11
608-S07
El sistema Lean en Wipro Technologies
para el mismo tiempo. Si bien existen numerosos procedimientos para partir la matriz, la meta es
transformarla en una forma triangular más baja o, de ser posible, por lo menos bloquear la forma
triangular. Por último la matriz es “agrupada”, de modo que se resalten las tareas que habrán de ser
programadas simultáneamente.5 Un miembro del personal de aseguramiento de calidad en software
comentó lo siguiente acerca de la matriz de diseño de estructuras:
Todos los procedimientos de mejora que hemos aplicado obligan a que el gerente
de proyecto planee y monitorice mejor, y ambas cosas mejoran el desempeño. Con
la matriz de diseño de estructuras, el gerente de proyectos puede sacar de su
cabeza los conocimientos y ponerlos por escrito. No es posible hacerlo todo
mentalmente.
La resonancia de la matriz de diseño de estructuras pudo verse en Wipro al ser utilizada en un
entorno de intervención. Cierto cliente de importancia encargó a un equipo pequeño terminar una
prueba de concepto, con el fin de trasladar de Palm OS a Windows CE la aplicación para ventas
móviles de la empresa. En un principio, el cliente solicitó que el trabajo estuviera listo en cuatro
semanas, y el gerente de proyecto desarrolló un plan. Antes de empezar el trabajo, el cliente pidió
que el trabajo se le entregara en tres semanas. El gerente consultó al personal de aseguramiento de
calidad y a un miembro de la oficina de productividad para que le orientaran acerca de cómo ahorrar
tiempo. Le recomendaron usar el sistema Lean y que recurriera a la matriz de diseño de estructuras,
así como a otros principios del Lean (por ejemplo: reiteraciones y el tablero para control visual). Los
tres trabajaron con el líder técnico del proyecto y llenaron la matriz (véase en el Anexo 5 una copia de
la matriz de diseño inicial, partida y agrupada). La matriz inicial de diseño de estructuras muestra
que, en el primer plan, el gerente no manejó todas las dependencias del proyecto (por ejemplo: doce
depende de quince, pero doce se programa antes de quince). El gerente detectó estas contradicciones
en el proceso de planeación y las corrigió con la matriz de diseño agrupada. Gracias a la aplicación
de la matriz de diseño de estructuras, el equipo terminó el proyecto en dos semanas, y así cumplió la
nueva fecha límite.
La mayoría de los proyectos realizados en Wipro utilizan la matriz de diseño de estructuras. La
herramienta se hizo tan popular, que Navneet Bhushan, miembro de la oficina de productividad,
aseguró: “Para mucha gente, el Lean se ha vuelto sinónimo de la matriz de diseño de estructuras. El
atractivo es que la matriz ofrece una herramienta con la cual una persona alimenta los datos, oprime
un botón y luego obtiene una respuesta.” Además de la matriz de diseño de estructuras, Wipro
aprovechó su propia experiencia para desarrollar una herramienta similar: un estimador de
complejidad. Esta herramienta permite al usuario tomar en cuenta la complejidad de la funcionalidad
al estar diseñando el plan para un proyecto.
Tablero de control visual Los tableros de control visual (VCB, las iniciales en inglés) se utilizan
en el Lean para aumentar la comunicación y destacar cuestiones difíciles, de modo que fuera posible
mantener unidos el problema y la solución. En Wipro, el tablero de control visual comenzaba cuando
el gerente de proyecto repartía el trabajo en incrementos de uno o dos días. Luego, en un pliego
grande de papel, el gerente apuntaba los días de la semana en los encabezados de las columnas, y los
nombres de los ingenieros en los encabezados de las filas. Hecho esto, el gerente pegaba el tablero en
la pared, a fin de que todos los miembros del equipo pudieran verlo. El trabajo que un ingeniero tenía
que terminar en un día determinado, se apuntaba en la celda correspondiente. Al final de cada día, el
ingeniero anotaba el porcentaje del trabajo que hubiera terminado ese día. Si era menos del 100%, lo
anotaba en rojo. Si algún ingeniero terminaba su trabajo de ese día anticipadamente, podía comenzar
5 Mayor información acerca de la matriz de diseño de estructuras se encuentra en http://www.dsmweb.org/
12
El sistema Lean en Wipro Technologies
608-S07
el trabajo en el proyecto del día siguiente. (El Anexo 6 muestra un tablero para control visual
hipotético, que el equipo ha terminado hasta el miércoles).
Mediante el tablero de control visual, el gerente de proyecto tenía un lugar fijo adonde ir para
consultar el estatus del equipo, en lugar de acudir con líderes de módulo o reunir a los miembros del
equipo. Asimismo, el tablero obligaba a los gerentes de proyecto a dividir el trabajo a realizarse en
incrementos de uno o dos días. Esta división en porciones pequeñas facilitaba monitorizar el
progreso y detectar problemas a tiempo. El tablero daba a los miembros del equipo una perspectiva
general de todo el proyecto, de modo que sabían dónde entraba su trabajo en el conjunto de este.
También les permitía identificar a la persona de la que dependía su labor, y les era posible
consultarla, de ser necesario. Por último, el tablero para control visual les permitía solicitar más
trabajo, en caso de haber terminado anticipadamente la tarea en la que estaban ocupados.
Autonomización / Jidoka Otro de los fundamentos del sistema Lean es crear pruebas sencillas e
infalibles para identificar problemas. Wipro abordaba el tema mediante dos procedimientos. El
primero se hacía por medio de revisiones periódicas de códigos. Aunque las revisiones periódicas de
códigos eran parte del proceso obligatorio desde mucho tiempo atrás, su utilización aumentó después
de la introducción del Lean. Lo ideal era que se las hiciera a diario, pero en algunos casos eran menos
frecuentes. Como el nombre indica, en la revisión diaria del código, alguien lo revisaba todos los días.
Esta revisión podría consistir en un análisis visual, en busca de errores, o la comprobación de que el
código se adecuaba a los estándares de diseño. En ocasiones, miembros de alto nivel del equipo
llevaban a cabo la revisión; en otras ocasiones, parejas o grupos del equipo revisaban entre sí su
trabajo. El segundo procedimiento consistía en hacer construcciones diarias, en las cuales el equipo
compilaba todos los días su trabajo y efectuaba pruebas automatizadas, preparadas en forma
individual. Los miembros del equipo construían estos casos de prueba con el fin de comprobar que
los módulos hubieran logrado las metas a las que se habían comprometido.
Heijunka / Nivelación Otro concepto del sistema Lean, adoptado por Wipro, era heijunka o
nivelación. El concepto de heijunka es “nivelar” la carga de trabajo, de modo que el sistema opere a
una tasa constante. Por ejemplo: si una fábrica exige 72 unidades por día, un tiempo de ciclo de 10
unidades por hora, operando durante ocho horas, el método usual consistiría en operar la fábrica a
máxima velocidad durante 7,2 horas, a fin de satisfacer la demanda, y luego crear inventario
adicional, o bien suspender labores por ese día. Aplicando el principio de heijunka, una compañía
operaría la fábrica a una tasa del 90%, a fin de satisfacer la demanda a lo largo del día. Esta
diseminación del trabajo reduce los picos de la demanda y es parte importante del sistema Lean
entero, con lo cual se reducen los plazos de realización de proyectos y las variaciones en la carga de
trabajo. Al mismo tiempo, aumenta la capacidad de respuesta hacia los clientes.
La necesidad de nivelar el trabajo se presentó en uno de los primeros proyectos de Wipro
aplicando el Lean. En este proyecto, Wipro trabajo no sólo con el cliente, sino también con un
integrador de sistemas y otros desarrolladores subcontratados. Utilizando las contramedidas del
Lean, Wipro pudo terminar el trabajo con mucha mayor rapidez. Pero como los socios no estaban
preparados para recibir con tanta anticipación la aportación de Wipro, la compañía devolvió sus
ganancias, en lo que esperaba a que los socios terminaran. En el proyecto siguiente utilizó otros
principios del Lean. Pero ahora, en lugar de tratar de terminar el trabajo antes, lo llevó a cabo con
menos recursos generales. La nivelación del trabajo permitió a Wipro retener las ganancias obtenidas
con el Lean para el segundo proyecto.
Mapa de la corriente de valor Uno de los principales objetivos del sistema Lean es enfocar a una
compañía en la creación de valor para el cliente y eliminar todas las partes del proceso que no añadan
tal valor. Un Mapa de la Corriente de Valor (VSM, las iniciales en inglés) es parecido al diagrama del
proceso de flujo, pero, a diferencia, clasifica los pasos según si añaden valor o no.
13
608-S07
El sistema Lean en Wipro Technologies
La preparación de Mapas de la Corriente de Valor fue un área en la cual los gerentes de proyecto
tuvieron la oportunidad de hacer participar a sus equipos en el proceso del sistema Lean. Después de
preparar un mapa de esta clase, cierto equipo se dio cuenta de que su proceso dependía de una sola
impresora para pruebas (el equipo diseñaba formas automatizadas para un banco y usaba la
impresora para someter a prueba lo hecho). La situación era que no sólo cuatro personas dependían
de una sola impresora, lo cual provocaba esperas prolongadas y tardados tiempos de cambio, sino
que, además, la impresora estaba ubicada en el piso de arriba. Calcularon que un proceso que debía
tardar una hora, consumía dos. Para resolver el problema, instalaron una computadora para pruebas
junto a la impresora y luego asignaron tiempos de utilización a varios ingenieros.
Si bien Wipro había utilizado con éxito el Mapa de la Corriente de Valor para reorganizar los
flujos del proceso, los beneficios de enfocarse en el valor para el cliente habían tardado más en
desarrollarse. Un buen ejemplo de la dificultad para cambiar la mentalidad, a fin de identificar
nuevas modalidades de aportar valor al cliente, se presentó en una sesión de capacitación en el
sistema Lean. El equipo en cuestión desarrollaba controladores de impresora y trataba de definir el
valor para el cliente. Después de una larga discusión, concluyeron que el valor para el cliente era un
controlador de impresora.
Después de dos años de implantar la iniciativa, la alta dirección estaba ansiosa de ver, de principio
a fin, los resultados de la misma. Se tenía el deseo de identificar y validar resultados contundentes.
Una comparación de proyectos terminados con y sin la aplicación del Lean mostró que los proyectos
en base a este sistema podrían manejar mejor las exigencias planteadas por la inestabilidad, y con
menos revisiones de calendario. Si bien todo se movía en dirección satisfactoria, no era evidente que
la productividad hubiera aumentado de manera impresionante ni que la reducción de esfuerzos fuera
considerable. Mirando retrospectivamente, Alexis y Deb pensaron que el sistema Lean debía
utilizarse en porciones más grandes de un proyecto, y aplicarse también al nivel de la rendición de
cuentas.
Los pasos siguientes
Deb y Alexis se despidieron, y cada quién subió a su auto. Al tiempo que se preparaban para
enfrentarse al tráfico que se dirigía de Electronic City a Bangalore, siguieron sopesando los pasos que
la compañía debía dar a continuación. Aunque la implantación del Lean había sido exitosa hasta la
fecha, estaban conscientes de que el camino por recorrer todavía era largo. ¿Había otras
contramedidas que debieran introducir a su entorno? Si la clave del sistema Lean residía en
incorporar múltiples medidas de remedio a un sistema uniforme, ¿lo estaban haciendo? ¿Era el Lean
el rumbo a seguir? En caso de que lo fuera, ¿cómo debería ser adaptado? ¿O deberían tratar de crear
algo totalmente diferente a este sistema? ¿Algo así como una “forma Wipro de ser”, totalmente
nueva? Por último: ¿era hora ya de crear un marco formal de trabajo en base al Lean? ¿Cuál sería el
mejor procedimiento para detectar las mejores prácticas y hacerlas obligatorias, al mismo tiempo
dejando espacio para la experimentación?
14
608-S07 -15-
Anexo 1
Estadísticas selectas de operación
25,000
Utilidades brutas globales por servicios
de informática (en rupias)
Ingresos globales por
servicios de informática (en rupias)
70,000
60,000
20,000
)
s
upee
R
s)
ee 50,000
p
R
u
an
i
d 40,000
n
(I
e
u
n
CAGR of 28%
n
di
15,000
a
n
I(
it
CAGR of 37%
Prof
s
os
r
G
s
e 10,000
ic
v
r
R
30,000
ev
e
S
e
T
I
l
ce
s
20,000
ervi
S
T
I
al
b
o
Gl 10,000
oba
l
G 5,000
0
0
2001
2001
2002
2003
2004
2002
2003
2004
2005
Licenciatura
4%
Bachelor
4%
El resto del
es t of
muRnWorld
do 6%
Bachelor
of Science
Licenciatura
14%
en ciencias
6%
14%
Europe 27%
Europa
27%
Estados
United States
Unidos:
67%
67%
Licenciatura
en
Bachelor
of Engineering
ingenieria
82%
82%
2005
608-S07 -16-
Anexo 2
Evolución del mejoramiento del proceso en Wipro
Premio del IEEE Estados Unidos al
Logro en Proceso de Software
Seis Sigma
La mejor empresa
en procesos
relativos a la gente
La primera
Estándares de compañía en el
mundo con
calidad
específicos a certificado PCMM
de nivel 5
Se define el proceso
para la empresa entera
Rumbo a la
mejora
continua
Comienzan
las prácticas
para evitar
defectos a
nivel de
proyectos
Metodologías
Sigma Seis
para software
Certificada en dos ocasiones
Procesos maduros Comienza la
colección de parámetros
Fuente: Documentos de la empresa
la industria
La
primera
compañía
en el
mundo
con
certificad
o CMMI,
versión
1,1, de
nivel 5
Se introduce
rigor
estadístico a
la dirección
Configuracio
nes
ortogonales
Implantación
de los marcos
de referencia
DMAIC +
DSSS
Implantación
intensiva de la
metodología
Six Sigma
Métodos
estadísticos
Cumplimiento de 2003 COPC. BS
15000, y de la ley inglesa para la
protección de datos
Proyectos
pilotos
utilizando el
sistema
Lean
608-S07 -17-
Anexo 3 Mejoramiento en Wipro de la calidad, la productividad y la adhesión a los calendarios, de 1995 a 2004
Tiempo
Tasa de errores de campo
Adhesión a los calendarios
Costo menor por descuidar los calendarios
Costo menor de mantenimiento
Defectos
Bajo costo de desarrollo
Fuente: Documentos de la compañía Todas las cifras se ajustan a 100 en 1995
Productividad
Productividad
Anexo 4 Implantación de los proyectos en base al sistema Lean y al método Six Sigma
1200
250
235
1046
1000
200
Número de proyectos
877
Número de proyectos
This document is authorized for educator review use only by Gustavo Machuca, Other (University not listed) until Jun 2021. Copying or posting is an infringement of copyright.
[email protected] or 617.783.7860
608-S07 -18-
800
s
t
s 150
ec
t
oj
r
P
of
er
662
ojec
r
P
of 600
m
b
er
u
N
112
m 100
b
u
N
400
307
200
50
143
35
80
0
10
1998
0
Aug-04
83
Nov-04
Feb-05
May-05
Aug-05
Implantación del proyecto en base al Lean
Fuente: Documentos de la compañía
Nov-05
1999
2000
2001
2002
2003
Jan-06
Implantación del proyecto en base al Six Sigma
2004
El sistema Lean en Wipro Technologies
608-S07
Anexo 5 Matriz de diseño de estructuras
Matriz inicial de diseño de estructuras:
Name
Control de filtros
Filter
Control
Control
de datos 2
Plantilla
editable para datos
Data
Control
Plantilla
paraGrid
datos con casilla de
Editable
Data
corrección
Data
Grid
with
Check Box
Plantilla para datos con casilla de
Data
Grid with
corrección
en Check
una filaBox in One Row
Objeto
de acceso
Data
Access
Objecta datos
Objeto
para
transferir
un conjunto de
Data Set Transfer Object
datos
Footer
Pie de página
Customer
Listlista
Filter
Filtro para
de clientes
Customer
PlantillaList
paraGrid
lista de clientes
Pie de página
para lista de clientes
Customer
List Footer
Forma para lista de clientes
Customer List Form
Filtro para pedido de adquisición
Order
Acquisition
Filter
Plantilla
para pedido
de adquisición
Pie Acquisition
de página para
pedido de
Order
Grid
adquisición
Order
Acquisition Footer
Forma para pedido de adquisición
Order
Acquisition Form
Control de tabulador para pedido de
Order
Acquisition Tab Control
adqusición
Order
Acquisition
Inventory
Tabulador
de inventario
paraTab
pedido de
adquisición
Product
Measures
Parámetros
para
productos
Product Measures Tab Control
Control de tabulador para parámetros
SKU
de Tab
productos
SKU
Filter SKU
Tabulador
Filtro
SKU
SKU
Grid
Plantilla
SKU
Form SKU
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
11
2
2
3
1 3
4
1
4
5
1
5
6
6
17
7
8
8
91
9
1
10
1
10
1
11
1
11 1
1 1 1 12
12
1
13 1
13
1 1
14
1
14 1 1
15
1
15 1
16
1 1 1 16
17
17 1
18
1111
1 18
19
20
21
22 1
23
1
24
19 1
20 1
21 1 1 1
22
23
1 1 24
Matriz partida diseño de estructuras:
Filter Control
Control
de filtros
Control
de datos
Data Control
Objeto
de
acceso
a datos
Data Access
Object
Pie de página
Footer editable para control de datos
Plantilla
Editablepara
Data
Gridcon casilla de
Plantilla
datos
corrección
Data Grid with Check Box
Objeto
para
transferirObject
un conjunto de datos
Data Set
Transfer
Filtro para pedido de adquisición
Order Acquisition Filter
Plantilla para pedido de adquisición
Order
Acquisition
Grid de adquisición
Pie
de página
para pedido
Forma
Order para
Acquisition
pedido deFooter
adquisición
Filtro
OrderSKU
Acquisition Form
Plantilla SKU
SKU Filter
Plantilla para datos con casilla de
SKU Griden una fila
corrección
Data para
Gridlista
withdeCheck
Box in One Row
Filtro
clientes
Plantilla
para
lista
de clientes
Customer
List
Filter
Pie
de
página
para
lista
de
clientes
Customer List Grid
Forma para lista de clientes
Customer
List Footer
Control
de tabulador
para pedido de
Customer List Form
adqusición
Tabulador
de inventario
pedido de
Order Acquisition
Tabpara
Control
adquisición
Order Acquisition Inventory Tab
Forma SKU
SKU Form
Tabulador
SKU
SKU Tab
Control
de tabulador para parámetros de
productos
Product Measures Tab Control
Parámetros
para productos
Product Measures
1 2 6 8 3 4 7 13 14 15 16 22 23 5 9 10 11 12 17 18 24 21 20 19
1 1
2
2
6
6
8
8
3
1
3
4
1
4
7
1
7
13 1
13
11
14
1
14 1 1
15 1
15
1
16
1 1 1 16
22
22 1
23
1
23
5
1
5
91
9
1
10
1
10
1
11
1
11 1
12
1
1 1 1 12
17
17 1
1 1 1 1
1 18
18
1 1
24
24
1 21
21
1 1
20
1 20
19
1 19
19
608-S07
El sistema Lean en Wipro Technologies
Matriz agrupada de diseño de estructuras:
1 2 6 8 3 4 7 13 14 15 16 22 23 5 9 10 11 12 17 18 24 21 20 19
Filter
Control
Control
de filtros
Control
de datos
Data
Control
Objeto
de acceso
Data
Access
Objecta datos
Pie de página
Footer
Plantilla editable para control de datos
Editable
Data
Plantilla
paraGrid
datos con casilla de
Data
Grid with Check Box
corrección
Data
Set Transfer
Object
Objeto
para transferir
un conjunto de datos
Filtro
para pedidoFilter
de adquisición
Order
Acquisition
Plantilla
para pedido
Order
Acquisition
Gridde adquisición
Pie Acquisition
de página para
pedido de adquisición
Order
Footer
Forma para pedido de adquisición
Order
Acquisition
Form
Filtro
SKU
SKU
Filter SKU
Plantilla
SKU
Grid para datos con casilla de
Plantilla
corrección
enCheck
una filaBox in One Row
Data
Grid with
Filtro para
de clientes
Customer
Listlista
Filter
PlantillaList
paraGrid
lista de clientes
Customer
Pie de página para lista de clientes
Customer
Listlista
Footer
Forma para
de clientes
Customer
Form para pedido de
Control List
de tabulador
Order
Acquisition Tab Control
adquisición
Forma
SKU
Order
Acquisition
Inventory Tab
Tabulador
SKU
Form SKU
Control
SKU
Tab de tabulador para parámetros de
productos
Product
Measures
Control
Parámetros
para Tab
productos
Product Measures
11
2
6
8
3
4
7
13 1
14
15
16
22 1
23
5
91
10
11
12
17
18
24
21
20
19
2
Fuente: Documentos de la compañía.
20
6
8
1
1
3
4
1
7
13
1
14
1
1
1
15
111
1
1
1
16
22
1
23
1
5
9
1
1
11 1
111
12
1
10
1
1
17 1
1 18
1111
11
11
24
1 21
1 20
1 19
El sistema Lean en Wipro Technologies
608-S07
Anexo 6 Tablero hipotético para control visual
Prashant
Ananth
Barti
Saravanan
Tripu
Lunes
SK 1
100%
FC 1
100%
TM 1
100%
NE 1
100%
AC 1
100%
Martes
SK2
100%
FC 2
70%
TM 2
100%
NE 2
85%
AC 2
100%
Miércoles
SK3
100%
FC 3
40%
TM 3
100%
CC 1
100%
ST 1
100%
Jueves
RG1
Viernes
RG2
FC 4
FC 5
TM 4
FR 1
CC 2
CC 3
ST 2
OB 1
21