Wipro

For exclusive use FGV - EAESP, 2015
6 1 2 -P 1 1
OCTOBER 16, 2009
DAVID M. UPTON
BRADLEY R. STAATS
O Sistema Lean na Wipro Technologies

Ns queremos trazer a prxima gerao do pensamento lean para os nossos processos e incorpor-la ao
nosso sistema para gerar uma vantagem competitiva sustentvel.
- Azim Premji, Presidente da Wipro
Sambuddha Deb, diretor de qualidade e chefe de excelncia operacional da Wipro Technologies, e

Alexis Samuel, gerente geral de processos, ferramentas e produtividade, agradeceram os outros
presentes na sesso de reviso de projetos lean e saram juntos da sala. O belo e ensolarado dia de
janeiro e a atmosfera tpica de um jardim nas instalaes da Wipro Technologies em Bangalore, ndia,
combinavam bem com o atual bom humor dos dois. Enquanto andavam em direo aos seus carros,
eles discutiram o atual status da iniciativa lean da empresa. Menos de dezoito meses antes, como uma
resposta a desafios organizacionais e competitivos, eles haviam decidido tentar transportar os
conceitos do Sistema Toyota de Produo (TPS), ou Lean, do setor de manufatura para o de software.
Em janeiro de 2006, a empresa tinha mais de 235 projetos lean completos ou em processamento.
A promessa e a possibilidade do sistema Lean eram tpicos de discusso em toda a empresa, das
salas de conferncia s cafeterias espalhadas por toda a ndia. Apesar dos resultados positivos
iniciais, a implementao da iniciativa lean estava longe de ser concluda. A Wipro tinha mais de
1.100 projetos simultneos, o que significava que apenas 15% deles estava usando os conceitos Lean.
O processo at ento havia sido caracterizado por uma grande quantidade de experimentao, com
um envolvimento central limitado. Eles se perguntavam se agora no era a hora de formalizar uma
abordagem lean para o desenvolvimento de projetos na Wipro. Embora eles estivessem aplicando
muitas ferramentas do sistema Lean, haveria outras que deveriam estar sendo utilizadas? Finalmente,
eles continuavam a especular se o que eles estavam fazendo era realmente Lean. Era possvel ter
servios de software lean ou eles deveriam estar desenvolvendo melhores prticas para seu prprio
sistema, um Jeito Wipro talvez?
Viso Geral da Empresa

A Wipro Technologies, uma subsidiria da Wipro Ltda., competia no mercado global de servios
de software. A empresa fornecia servios de integrao, desenvolvimento e manuteno de
________________________________________________________________________________________________________________
Caso LACC nmero 612-P11 a verso traduzida para Portugus do caso nmero 607-032 da HBS. Os casos da HBS so desenvolvidos somente
como base para discusses em classe. Casos no devem servir como aprovao, fonte primria de dados ou informao, ou como ilustrao de
um gerenciamento eficaz ou ineficaz.
Copyright 2011 President and Fellows of Harvard College. Nenhuma parte desta publicao pode ser reproduzida, armazenada em um sistema
de dados, usada em uma tabela de dados, ou transmitida de qualquer forma ou por qualquer meio - eletrnico, mecnico, fotocopiada, gravada,
ou qualquer outra - sem a permisso da Harvard Business School.
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.

612-P11
aplicativos, alm de servios de pesquisa e desenvolvimento e gerenciamento de infraestrutura de TI.

Os servios de software da Wipro incluam muitas reas tecnolgicas, como servidor de clientes,
armazenamento de dados, comrcio eletrnico, sistemas embutidos, aplicativos de negcios,
networking, solues de telecomunicaes e aplicativos de rede. A empresa operava em mltiplos
setores, incluindo o setor bancrio e de seguros, sistemas embutidos, energia e servios de utilidade
pblica, servios financeiros, sade, manufatura, mdia, varejo, tecnologia, telecomunicaes e
transportes.
No fim de 2005, a Wipro tinha mais de 35 mil funcionrios e servia clientes em todo o mundo
atravs de seus escritrios localizados em mais de 30 pases (veja no Anexo 1 um resumo de
estatsticas da empresa). A empresa teve receita de US$ 1,2 bilho no ano fiscal de 2005 e vinha
crescendo rapidamente, com uma taxa de crescimento anual composta de 37% nos ltimos quatro
anos. A receita estava distribuda globalmente, com os EUA, a Europa e o resto do mundo
correspondendo a 67%, 27% e 6% da receita total do ano fiscal de 2005 respectivamente. Mais de 95%
dos funcionrios da Wipro tinham diplomas em cincia ou engenharia antes de comearem a
trabalhar na empresa.
Embora a empresa fosse uma fornecedora terceirizada de servios de software, ela trabalhava
tanto in loco (nas instalaes do cliente) quanto distncia (nas instalaes da Wipro, localizadas
principalmente na ndia). Em 2005, a empresa realizou aproximadamente 75% de seu trabalho
distncia e 25% in loco. Tanto presses relacionadas a custos (trabalho feito distncia era
relativamente mais barato) e uma falta de vistos de trabalho (particularmente para os EUA) estavam
forando a Wipro a realizar mais trabalhos distncia. A Wipro cobrava por seus projetos usando
uma dentre duas abordagens. A abordagem inicial, conhecida como tempo e materiais (T&M),
envolvia cobrar de um cliente uma taxa pr-especificada pelo nmero de horas em que seus
engenheiros trabalhavam no projeto mais o custo de qualquer software ou ferramentas necessrios.
Na abordagem mais recente, conhecida como projeto de preo fixo (FPP), a Wipro oferecia a seus
clientes um preo fixo garantido pelo trabalho e, ento, era responsvel pela entrega do produto final.
Qualquer esforo a mais do que o combinado era de responsabilidade da Wipro. Em 2005, a receita
da empresa estava dividida em aproximadamente 80% e 20% entre T&M e FPP, respectivamente. O
porcentagem de trabalhos FPP estava crescendo na medida em que clientes estavam ficando mais
confortveis com fornecedores terceirizados de servios de software e estavam gerenciando custos de
forma mais agressiva. Alm disso, a Wipro considerava o modelo FPP atraente na medida em que a
empresa vinha ficando mais confiante em assumir responsabilidade pelo projeto do comeo ao fim e
estava buscando colher os benefcios de seus esforos para melhoria de produtividade.
Servios de software
O processo de desenvolvimento de software era similar em muitos aspectos ao processo de
construo de uma casa. O primeiro passo para construir uma casa era especificar os requisitos
necessrios para a soluo. Isso poderia incluir determinar o nmero de metros quadrados, andares,
quartos, banheiros etc. Uma vez que os requisitos tenham sido especificados, ento os arquitetos e
engenheiros criam designs detalhados, que no apenas especificam a localizao dos quartos e da
estrutura geral (tomadas, torneiras, interruptores etc.), como tambm o posicionamento da
infraestrutura eltrica e de encanamento. Somente depois disso comea o processo de construo.
Durante a construo, falhas encontradas nas plantas so corrigidas e o trabalho constantemente
inspecionado em busca de defeitos. Quando sistemas so concludos (por exemplo, o sistema de ar
condicionado), eles so testados, e quando todo o trabalho est concludo, toda a casa inspecionada,
2

O Sistema Lean na Wipro Technologie
612-P11
primeiro pelo construtor e depois pelo cliente que compra a casa. No desenvolvimento de software,
os mesmos passos bsicos so tomados na maioria dos projetos, embora estes passos tenham nomes
diferentes: especificao de requisitos, design detalhado, teste de cdigo e unidade, teste de sistemas
e, finalmente, teste de aceitao do usurio. Uma diferena entre construir uma casa e desenvolver
um software que o progresso ou a forma do que est por vir so frequentemente invisveis para o
usurio at que ele possa ver o produto ou servio final em funcionamento.
Servios de software so um negcio diferente de softwares direcionados para o consumidor final
(como Microsoft Word) ou sistemas de software para empresas (por exemplo, sistemas integrados de
gesto empresarial, ou ERP). Muito do trabalho da Wipro no era desenvolvimento do comeo, mas
envolvia adaptar, conectar e apoiar sistemas de software existentes. Incertezas tcnicas e de mercado
eram menores para a Wipro do que para um desenvolvedor de softwares aplicativos, pois a empresa
no iniciava um projeto at que um cliente solicitasse o trabalho. No entanto, a complexidade do
processo costumava ser alta, j que a empresa trabalhava em centenas de projetos com altos
requisitos de qualidade ao mesmo tempo. Deb descrevia o negcio dizendo: Ns no construmos
uma casa inteira para algum. Ao invs disso, ns adicionamos a varanda nos fundos. Ns
precisamos, no entanto, ter um bom conhecimento da casa em questo e da sua fundao e design
antes de adicionar a varanda.
Havia duas outras importantes distines no tipo de trabalho que a Wipro fazia. A empresa
dividia-se em trs unidades de negcios: Solues de Engenharia de Produtos (PES, que consistia em
telecomunicaes e sistemas embutidos), Solues Empresariais (ES) e Bancos, Finanas, Poupanas e
Seguros (BFSI). Originalmente, projetos em PES envolviam fornecer suporte para o software em um
produto (por exemplo, os drivers em uma impressora). Com o tempo, a empresa comeou a realizar
servios de desenvolvimento de software. Mais recentemente, clientes passaram a terceirizar subsistemas inteiros ao invs de apenas softwares. A Wipro estava comeando a assumir
responsabilidade pelo gerenciamento tanto da manuteno quanto da melhoria de produtos maduros
ou em fim de linha.
Embora o trabalho realizado pela Wipro na rea de PES costumava ser de responsabilidade do
Diretor de Tecnologia do cliente, o trabalho feito nas reas de ES e BFSI tipicamente era de
responsabilidade do Diretor de Informao do cliente. Projetos nestas duas unidades de negcio eram
geralmente de um entre dois tipos: manuteno ou desenvolvimento. Projetos de manuteno
envolviam apoiar e melhorar os sistemas existentes de um cliente. Por exemplo, apoiar o sistema
integrado de gesto empresarial de um cliente era um projeto de manuteno comum. A Wipro podia
consertar falhas identificadas pela empresa e criar software para adicionar novas funcionalidades ao
sistema. Por outro lado, um projeto de desenvolvimento envolvia construir, integrar ou atualizar
sistemas de TI. Exemplos de projetos de desenvolvimento incluem criar um novo website altamente
interativo, transferir o aplicativo mvel de vendas de uma empresa do sistema Palm OS para o
Windows CE e o desenvolvimento de um novo sistema de gerenciamento de distribuidores para
rastreamento, relatrios e pagamentos.
Iniciativas de Qualidade Anteriores

Tradicionalmente, a Wipro se diferenciava no mercado devido qualidade de seu trabalho.
Anurag Behar, o predecessor de Deb, que comeou na Wipro em 2002 depois de deixar a GE,
descreveu desta forma o foco em qualidade na Wipro:
3

612-P11
Antes de comear na Wipro, minha impresso era de que se tratava de uma organizao focada
na qualidade no sentido geral e em performance ideal em todos os contextos. Em vrias ocasies,
percebi que a viso externa da situao melhor que a viso interna. Mas este no era o caso na
Wipro. Tipicamente, as pessoas que odeiam seu nvel de qualidade so as equipes de vendas, porque
eles so aqueles que esto em contato com o cliente, ouvindo reclamaes sobre tudo que est dando
errado. Mas isso no acontece aqui; as equipes de vendas adoram nosso nvel de qualidade.
Muito do foco em qualidade veio da descrena inicial que a empresa enfrentou quando estava
entrando, e depois competindo, no mercado internacional de servios de software no final dos anos
80 e incio dos anos 90. Clientes globais demonstraram ceticismo de que uma pequena empresa na
ndia poderia fornecer o software de alta qualidade de que seus negcios precisavam. Assim, a
empresa se concentrou em abordagens pblicas para melhoria de processos para demonstrar seu
compromisso com a alta qualidade. Em 1995, a Wipro foi uma das primeiras empresas de software a
receber a certificao ISO 9000 (veja no Anexo 2 uma tabela das iniciativas de melhoria de processo
da empresa).
Nos anos 80, o Departamento de Defesa dos EUA fundou o Instituto de Engenharia de Software
(SEI) na Carnegie Mellon University, com a inteno de avanar o estado da prtica de engenharia
de software1 O instituto estabeleceu o Modelo de Amadurecimento de Capacidade (CMM) para
softwares e, em 1998, a Wipro tornou-se a primeira empresa de servios de TI a conquistar o nvel 5
do modelo. Em 1997, inspirada por uma joint venture entre outra subsidiria da Wipro Ltda. e a
General Electric (GE), a empresa foi a primeira a introduzir o sistema Six Sigma aos servios de
software. Em 2000, o sistema era um sucesso na Wipro Technologies. A Motorola originalmente
introduziu Six Sigma em um contexto de manufatura e a GE rapidamente tornou-se sua mais famosa
adepta. O sistema Six Sigma usava tcnicas estatsticas, professores chamados de faixas pretas e
normalmente um processo DMAIC (Definir, Medir, Analisar, Melhorar [Improve] e Controlar) para
tentar reduzir o nmero total de defeitos para 3,4 por milho de oportunidades.
Mais tarde em 2002, quando o SEI introduziu uma nova verso do CMM, CMM Integrated
(CMMI), a Wipro novamente tornou-se a primeira empresa do mundo a receber a certificao de
nvel 5. As iniciativas de melhoria de processo da empresa levaram a melhorias consistentes em
qualidade, aderncia a prazos e aderncia a esforos (veja no Anexo 3 detalhes de 1995 a 2004). Em
2004, a Wipro percebeu que suas iniciativas de melhoria de processo estavam empacando. Um lder
snior de qualidade da empresa afirmou:
Iniciativas de qualidade duram de 18 a 24 meses, talvez 36 meses se voc tem sorte. A razo
para isso que ou cada iniciativa se concentrava em processos de controle mais avanados
quando comparadas s anteriores, ou em novas tcnicas, como o uso de controle estatstico de
processos no sistema Six Sigma, e cada uma destas fornecia retornos menores com o tempo. Ns
sabamos que era hora de comear a procurar algo novo.
Desafios em 2004
Em 2004, a Wipro estava enfrentando tanto desafios estticos quanto dinmicos. Havia dois
fatores estticos que todos os fornecedores de servios de software enfrentavam. Primeiro, o principal
fator para o desenvolvimento de software era engenheiros de software talentosos. O esteretipo era
de que os engenheiros de software eram pessoas cabea dura e independentes, que acreditavam que
1 Software Engineering Institute, About the SEI, website do Instituto de Engenharia de Software,
http://www.sei.cmu.edu/about/about.html.
4

612-P11
seu trabalho era uma arte e gostavam de fazer coisas de sua prpria maneira. Muitos engenheiros de
software concordavam que esta reputao era merecida. Segundo, servios de software era
inerentemente um negcio varivel. Projetos eram customizados para cada cliente e, portanto, eram
idiossincrticos por natureza. Como a maior parte do trabalho da Wipro era unir diferentes sistemas
de TI, os desafios enfrentados por um projeto em particular eram fortemente impactados por no
apenas que sistemas estavam sendo integrados (algo mais ou menos consistente em todos os
projetos), mas tambm por como o cliente havia implementado estes sistemas dentro de seus
negcios (algo idiossincrtico em todos os projetos). Alm destas questes constantes, havia tambm
mudanas dinmicas acontecendo no mercado.
Questes organizacionais
Alm do sentimento da empresa de que sua iniciativa de qualidade atual (Six Sigma) estava se
estagnando, havia vrios outros desafios organizacionais sendo enfrentados pela Wipro. No final de
2003, a empresa tinha quase 18 mil funcionrios, um aumento de 40% com relao ao ano anterior.
Alm do aumento geral de funcionrios, a taxa de sada de funcionrios na maioria das empresas de
servios de software da ndia (incluindo a Wipro) era de em mdia 10% a 20% por ano. A rpida
entrada e troca de pessoal significava que qualquer processo de software utilizado na empresa
precisava ser robusto o suficiente para fornecer a orientao necessria para novos membros de
equipes e controles de monitoramento de performance para gerentes.
Adicionalmente, o trabalho na Wipro era tradicionalmente feito a partir de uma abordagem de
cima para baixo. Os gerentes de projeto eram responsveis por criar um detalhado planejamento do
projeto usando Microsoft Project e, em seguida, designar tarefas especficas para os membros da
equipe. Como disse Alexis Samuel, com nossa configurao atual, o poder latente dos engenheiros
no aproveitado, e a empresa queria uma abordagem processual que iria capturar alguns dos
benefcios de dar poder aos membros das equipes.
Finalmente, a Wipro vivenciava variaes substanciais em performance atravs das diferentes
unidades de negcio da empresa. Embora parte desta variao fosse resultado de caractersticas
bsicas das indstrias que as unidades de negcio serviam, uma quantidade significativa no era. A
empresa tinha um sistema de gerenciamento de conhecimento que foi usado com algum sucesso, mas
ainda havia uma crena de que melhores prticas em uma rea da empresa no estavam sendo
reproduzidas com sucesso em outras unidades de negcio.
Questes de competitividade
Alm dos desafios organizacionais, a empresa enfrentava um contexto estratgico dinmico. A
Wipro havia tradicionalmente se diferenciado no mercado como um fornecedor de baixo custo e alta
qualidade. Embora seus custos fossem menores do que os de seus principais concorrentes
internacionais (por exemplo, IBM, Accenture e EDS), esta diferena estava diminuindo, j que a alta
demanda por engenheiros de software talentosos na ndia estava aumentando seu valor (salrios
cresciam em mdia 12% ao ano), e concorrentes internacionais estavam expandindo sua presena na
ndia para tirar vantagem de alguns dos recursos de baixo custo que a Wipro utilizava. Alm disso,
embora houvesse empresas menores em outros pases com baixos salrios pressionando a Wipro (por
exemplo, China, Filipinas, Vietn e Rssia), uma das maiores ameaas vinha de novas empresas
indianas. Deb descreveu o desafio da seguinte forma: A ndia forma mais de 380 mil engenheiros de
5

612-P11
software qualificados, que falam ingls, por ano. Os recursos para executar uma estratgia simples,
de baixo custo, esto se renovando constantemente na ndia.
Adicionalmente, embora o mercado reconhecesse a Wipro como lder em qualidade, seus
concorrentes estavam diminuindo esta diferena. Diz Alexis: Um grande desafio para ns que, em
comparao com trs anos atrs, as pessoas esto alcanando a Wipro.
Finalmente, a Wipro acreditava que estava acontecendo uma mudana significativa no mercado.
Havia uma viso interna de que o setor de TI estava deixando a produo artesanal para trs e havia
uma oportunidade para se tornar lder em processos. Anurag descreveu assim a situao:
Na minha opinio, TI est na mesma situao que a indstria automobilstica em 1910-1920.
Hoje, cada organizao faz seu trabalho de forma nica; ainda estamos na fase da produo artesanal.
No entanto, h tanta ineficincia que pode ser eliminada e o mercado muito competitivo para que
ela no seja eliminada. Ns vemos isso acontecendo. Toda a onda de terceirizao e globalizao
prova de que a transio est acontecendo. Hoje, voc deve ser capaz de fornecer consistentemente
para diversos tipos de clientes. No sabemos como fazer isso com software ainda, mas o setor de
manufatura sabe. A chave para o sucesso de uma fbrica no comprar mquinas gerenciar
pessoas. Ento, agora, a chave torna-se fazer dez mil pessoas trabalharem juntas. Assim, se voc
supe que isso vai acontecer, voc lidera ou voc segue? Se voc decide liderar, h duas formas de
fazer isso. A primeira usar sua marca, como uma IBM, e a segunda ser a empresa mais eficiente.
No podemos ser o lder de marca atualmente, por isso no temos escolha a no ser sermos os mais
eficientes.
Questes ligadas a clientes

Em adio s dificuldades organizacionais e ao ambiente competitivo em mudana, a empresa
descobriu que a demanda dos clientes estava passando por mudanas perceptveis. Primeiro, o foco
da competio no mercado estava mudando para alm de simplesmente alta qualidade. S.M. Bala, o
chefe de qualidade em PES, descreveu assim a situao:
Clientes esto comeando a ver a qualidade como algo natural ao invs de usar a qualidade como
forma de medir a performance. Na medida em que os clientes ganham em sofisticao, eles esto
comeando a usar custos para impulsionar a performance de seu fornecedor de servios de software
terceirizado, ao invs de usar qualidade. Inicialmente, clientes queriam verificaes e um foco em
qualidade porque eles queriam ter certeza de que os fornecedores estavam fazendo seu trabalho
corretamente. Agora, clientes esperam redues de custos regulares com melhoria de qualidade.
Adicionalmente, o mercado continua a ver uma mudana de contratos T&M, em que o cliente assume
o risco de custos extras, para contratos FPP, nos quais ns assumimos os riscos.
Embora os clientes estivessem esperando preos menores com melhor qualidade, eles tambm
estavam comeando a procurar por um produto diferente. Em 2004, clientes queriam que seus
fornecedores de servios de software oferecessem uma vantagem de negcios. Solues tcnicas no
eram mais suficientes, j que clientes queriam solues de negcios. O desafio para a Wipro era que
padres atuais na empresa eram padres de processo, no padres de processos de negcios. Dada
uma especificao tcnica, as rotinas existentes eram otimizadas para fornecer um produto de alta
confiabilidade que fosse de encontro a esta especificao. Elas no eram to bem capacitadas para
fornecer uma soluo de negcios para o cliente. S.M. Bala descreveu o problema desta forma:
6

612-P11
Precisamos conectar foco em negcios e foco em processos. Atravs de sistemas como CMM, nos
tornamos bastante bons em gerenciamento de processos. No entanto, no sabemos como gerenciar
pessoas. Em nossas pesquisas de satisfao de clientes, nossos clientes nos dizem: Vocs so muito
bons em fazer o que eu peo. Se eu peo para vocs construrem uma mesa com trs ps, vocs fazem
isso, mas vocs nunca perguntam porque a mesa tem apenas trs ps. Nossos clientes querem que a
gente fornea ideias inovadoras. Eles podem no saber ainda [o que eles querem], mas eles sabem
quando a Wipro no est fazendo-o.
Implementao do Sistema Lean

Devido a todos os fatores mencionados, no comeo de 2004, a diretoria da Wipro decidiu que era
hora de desenvolver uma nova abordagem para melhoria de processos. Eles queriam uma
metodologia que melhoraria tanto a qualidade quanto a inovao. Aps debates internos, eles
chegaram a uma lista de trs alternativas: o critrio Malcolm Baldridge National Quality Award, o
TRIZ (sigla de Teoria da Soluo Inventiva de Problemas em russo) e o sistema Lean. A primeira era
muito focada em qualidade e a segunda era muito focada em inovao. A terceira opo, no entanto,
parecia ideal.
A diretoria snior decidiu abordar o sistema Lean de uma forma diferente da que tinha sido usada
na implementao da iniciativa anterior, Six Sigma. A seguir, Deb descreve o processo de
implementao do Six Sigma:
Com o Six Sigma, ns fizemos tudo de baixo para cima. Foi uma exploso. Ns passamos muito
tempo criando uma abordagem Six Sigma para software e, em seguida, ns a impusemos a toda a
organizao. As ideias que tivemos funcionavam, ento a efetividade estava alta, mas o engajamento
era baixo. Levou muito tempo para que a iniciativa fosse aceita pela equipe. Assim, com o Lean, ns
decidimos fazer as coisas de outra maneira. Ns sabamos que estvamos correndo o risco de que a
iniciativa tivesse um menor impacto, mas ns espervamos ter uma aceitao maior.
A Wipro iniciou o processo lean formando uma equipe nuclear de dez pessoas. Esta equipe inclua
Deb, Alexis, Ravishankar Kuni, diretor do setor de produtividade e a sua equipe (o grupo de quatro
membros que iria supervisionar a implementao do sistema medida que este crescesse), e outros
lderes de qualidade e membros da gerencia snior. O primeiro objetivo da organizao era aprender
sobre o sistema Lean, para que eles pudessem descobrir como transferi-lo para o setor de servios
de software. A equipe principal comeou lendo tudo que eles conseguiram encontrar sobre a filosofia
Lean. De janeiro a maro de 2004, eles visitaram diferentes fbricas na ndia que estavam usando
processos lean. Estas visitas incluram uma viagem para uma planta da Toyota nas redondezas, alm
de uma planta na regio de Tamil Nadu, que havia ganho o prestigiado prmio Deming. A seguir, a
empresa entrevistou consultores para tentar encontrar algum que pudesse ajudar a gui-los pelo
processo. Deb descreveu desta forma a reunio com uma grande empresa global de consultoria
estratgica:
Eles deixaram claro que no tinham nenhuma experincia anterior em implementar estes
conceitos na rea de software e teriam que aprender junto conosco. Ns conversamos com alguns
especialistas japoneses e eles disseram a mesma coisa. Assim, ns no poderamos usar uma soluo
criada por especialistas, porque ningum tinha usado Lean em software antes. Ns teramos que fazlo sozinhos.
7

612-P11
No fim das contas, a Wipro acabou trazendo do Japo alguns consultores que tinham
familiaridade com o sistema Lean no ambiente de manufatura. Como descreveu Anurag: Eles foram
muito teis em abrir nossos olhos. Eles no forneceram solues, mas estimularam discusses.
Quanto mais perguntas fizemos, melhor ns ficamos. Cada interao ajudou-nos a fazer
descobertas.
Deb resumiu o principal aprendizado da equipe durante o processo, No se trata de teorizar,
trata-se de fazer. Ento, para comear, eles decidiram que cada membro da equipe iria encontrar um
projeto, comear a implement-lo e fornecer resultados em dois a trs meses. A equipe tinha que fazer
isso ao mesmo tempo em que continuavam a realizar seu trabalho normal. Eles no tinham
autoridade formal para obrigar a participao de um gerente de projeto, mas cada um tinha capital
organizacional suficiente para alistar um projeto. Um gerente de projeto descreveu o processo:
Ele [o membro da equipe lean] me procurou e disse que eu iria usar o sistema Lean para esse
projeto. Ele me disse para comprar dois livros sobre Lean2 e ns tivemos discusses a respeito por
dois dias. Ele me ajudou a me desfazer do plano original para o projeto e criar um plano de projeto
lean. Durante as primeiras trs semanas, eu estava muito confuso e no sabia dizer minha equipe
o que era Lean. Eu tinha reunies semanais com a equipe e passei de 3 a 4 horas ensinando-lhes sobre
o sistema. Nas reunies, eu listava ideias do TPS para eles discutirem.
A equipe Lean montou uma sala de estratgia eletrnica para compartilhamento de experincias
dos vrios projetos. No final de outubro de 2004, eles analisaram os resultados e descobriram que este
primeiro experimento havia resultado em oito sucessos dentre dez projetos. Um projeto era
considerado um sucesso se resultasse em mais de 10% de melhoria na(s) medida(s) de performance
pr-especificada(s) do projeto. Com taxa de 80% de sucesso, a equipe decidiu continuar com a
implementao.
O prximo passo, em novembro de 2004, foi realizar uma sesso de treinamento de um dia com 35
gerentes de qualidade. Na Wipro, cada projeto tinha um representante do setor de garantia de
qualidade do software (SQA) designado, para oferecer assistncia com qualidade e produtividade,
alm de monitorar a conformidade do processo. O representante de SQA normalmente trabalhava em
cinco a dez projetos por vez. Depois da sesso de treinamento, os membros da equipe de SQA
deveriam encontrar um projeto lean no qual trabalhar. Alm disso, neste momento, Azim Premji, o
presidente da Wipro, anunciou publicamente que a empresa estava usando uma abordagem lean para
servios de software e estava esperando obter uma significativa vantagem competitiva com a
mudana. Como disse um gerente snior: Ele anunciou que ns estvamos usando Lean. Isso
demonstrou compromisso da diretoria, mas pode ter sido prematuro. De qualquer forma, agora ns
temos que ir em frente.
Em agosto de 2005, vinte meses aps o incio da iniciativa lean, a Wipro tinha 112 projetos lean
concludos ou em processamento, e em janeiro de 2006 este nmero tinha aumentado para 235 (veja
no Anexo 4 um histrico da implementao dos projetos Lean e Six Sigma). Algumas unidades de
negcio j tinham realizado sesses de treinamento lean de meio perodo para seus gerentes de
projeto. Ravishankar Kuni, diretor de produtividade da empresa, descreveu desta forma o progresso:
Lean um processo lento uma mudana no estilo de gerenciamento uma mudana de
cultura.
2 Lean Thinking e The Toyota Way
8

612-P11
O setor de produtividade desempenhou um importante papel na implementao do sistema Lean

em toda a empresa, apesar de seu tamanho relativamente pequeno. Como um membro do setor tinha
responsabilidades de aconselhamento em todos os projetos Lean, o grupo servia como uma fonte de
informao para a organizao sobre Lean. O setor de produtividade incubava muitos dos novos
conceitos Lean em seu estgio inicial e ajudava a treinar os gerentes de projeto enquanto eles testavam
novos experimentos. Kuni explicou: Quando o horizonte estava nebuloso e ns no sabamos o que
lean significava para servios de software, o setor de produtividade serviu como um ponto de
encontro para a organizao.
Lean na Wipro
Procedimento operacional padro
Como discutido anteriormente, CMMI era a abordagem geral de melhoria que a Wipro usava3.
Alm disso, houve vrios ciclos de vida para desenvolvimento de software (SDLC) em conformidade
com CMMI que a empresa empregou para concluir projetos individuais. Exemplos incluram
cascatas, modelos iterativos e abordagens especficas para clientes. De longe o ciclo de vida mais
usado na Wipro foi a abordagem cascata. Nela (similar a um modelo stage-gate em desenvolvimento
de produtos), uma equipe determinava requisitos de clientes, desenvolvia um documento de design
detalhado, escrevia cdigos, realizava testes nas unidades, integrava as diferentes partes do projeto,
conduzia testes de sistema e, ento, fornecia-o a um cliente. O processo continuou linearmente e se
havia feedback no sistema, era apenas entre estgios sucessivos. A abordagem cascata foi reconhecida
como previsvel e escalonvel, mas havia alguma troca em termos de flexibilidade.
Esperava-se que todos os projetos na Wipro seguissem a estrutura definida de CMMI. Gerentes de
projeto usavam o sistema interno da empresa, Veloci-Q, para submeter planos de projetos, gerar
documentos e outros procedimentos necessrios.
Projetos Lean
A empresa achou que a conformidade com o nvel 5 do CMMI continuava a ser um importante
padro externo, ento, em sua forma inicial, Lean foi operacionalizado no nvel de projeto como um
ciclo de vida que ia de encontro aos requisitos de CMMI. No havia requisitos centralizados para um
projeto ser considerado lean, mas a expectativa era que um projeto lean usasse vrias das diferentes
contramedidas lean. O setor de produtividade mantinha uma lista dos projetos lean e todos os meses
eram feitas revises destes projetos, em que as equipes apresentavam seu progresso. Algumas
unidades de negcio incluam lderes de negcio nestas reunies, enquanto outras deixavam-nas a
cargo do representante de SQA. A expectativa inicial era que os projetos lean precisavam mostrar
3 Neste momento, havia uma batalha metodolgica acontecendo entre proponentes do CMMI e de mtodos geis de
programao (por exemplo, Extreme Programming (XP), Scrum, Crystal). Alguns proponentes dos mtodos geis
argumentavam que CMMI criava processos sem razo de ser e entregava software confivel e de alta qualidade que no
satisfazia as necessidades do cliente. Por outro lado, alguns proponentes do CMMI respondiam que mtodos geis resultavam
em hacking indisciplinado e eram apropriados somente para projetos pequenos. Como na maioria dos casos, a verdade estava
no meio termo e algum trabalho havia sido feito para unir as duas abordagens. Em agosto de 2005, inspirada em parte por
pedidos de clientes, a Wipro estava experimentando com dez projetos-piloto geis para ver se havia alguma circunstncia em
que o uso deles poderia ser apropriado em seu negcio.
9

612-P11
resultados em dois a trs meses. Projetos que estavam abertos a mais de seis meses sem demonstrar
nenhum impacto deixavam de ser considerados projetos lean. Esta expectativa de prazo fazia com
que muitos dos projetos lean iniciais fossem ou uma parte menor de um projeto grande ou uma
interveno onde um projeto enfrentava um choque externo e precisava de uma nova abordagem
para reagir (por exemplo, um cliente adiantando o prazo final ou uma equipe se atrasando). O
objetivo da iniciativa lean era demonstrar aumento de 10% ou mais nas medidas pr-especificadas de
projeto (agenda, esforo ou qualidade). A empresa rigorosamente rastreava medidas de performance
em todos os projetos e, por isso, podia medir quantitativamente o impacto de projetos lean. Deb
descreveu assim o raciocnio por trs do objetivo de 10% ou mais:
Se estabelecssemos um objetivo muito baixo, por exemplo melhoria de 2% a 3%, um gerente de
projeto poderia fazer uma equipe trabalhar muito para atingir a meta. No entanto, isso no seria
sustentvel. Precisvamos estabelecer um objetivo que s poderia ser atingido realmente mudando
como trabalhamos.
Se um gerente de projeto quisesse lanar um projeto lean, o representante de SQA e um membro
do setor de produtividade forneceriam apoio, incluindo reunies, conversas telefnicas e artigos
sobre contramedidas lean. Normalmente, quando uma nova equipe comeava um projeto lean, era
data ao gerente de projeto a opo de ter o representante de SQA conduzir uma curta sesso de
treinamento para a equipe ou o gerente podia faz-lo sozinho. Cada gerente podia escolher as
contramedidas lean que ele ou ela considerava mais apropriadas para seu projeto. Em janeiro de 2006,
gerentes no eram obrigados a conduzir projetos lean. Unidades de negcio tinham metas com
relao ao nmero de projetos lean que deveriam ser concludos, mas isto no havia sido diretamente
transferido para alvos e objetivos individuais. Havia algum debate interno sobre se concluir um
projeto lean deveria fazer parte dos alvos e objetivos de cada gerente de projeto para o ano fiscal de
2007.
Contramedidas Lean
Em janeiro de 2006, a Wipro havia tentado muitas abordagens diferentes para resolver problemas
(contramedidas)4 Embora no houvesse uma abordagem nica para Lean na Wipro, vrias das
contramedidas listadas abaixo eram comumente usadas em cada projeto lean.
Just in time/Fluxo nico Todo projeto na Wipro era just in time e usava fluxo nico, j que o
trabalho no comeava em um projeto at que fosse requerido pelo cliente. No entanto, dentro de um
projeto havia a oportunidade de concluir cada um dos passos de produo necessrios em sequncia,
um de cada vez, ao invs de utilizar o processamento em srie.
Em um projeto de converso de um website, a Wipro estava atualizando e melhorando o site de
uma grande empresa. O site antigo consistia de pginas construdas em cima de 680 pginas de
servidor Java (JPSs). Cada pgina do site podia levar a mltiplas JPSs. No passado, em um projeto de
converso como este, o gerente de projeto designava alguns indivduos para converter todas as JPSs,
enquanto outros membros da equipe trabalhavam nas pginas do site que levariam a elas. Ao invs
disso, neste projeto a equipe moveu cada pgina em um processo de fluxo nico, trabalhando em
uma JPS somente quando uma pgina do site levava a ela. Ao usar esta abordagem, a equipe
Ao descrever suas diferentes ferramentas e tcnicas, a Toyota usa o termo contramedidas ao invs de solues.
Isso porque cada resposta vista como um meio para um fim (por exemplo, reduo de desperdcio) ao invs de
uma resposta por si s. Para mais informaes, consulte Steven Spear e H. Kent Bowen, Decoding the DNA of
the Toyota Production System, Harvard Business Review (Setembro/Outubro 1999): 97-106.
10

612-P11
percebeu que 200 das JPSs (aproximadamente 30%) no estavam ligadas s paginas do site e, por isso,
no precisavam ser convertidas.
Aproximando problemas e solues Um dos principais objetivos do sistema Lean unir o

problema e a soluo no tempo, no espao e pessoalmente. Isso reduz variabilidades e aumenta a
oportunidade de aprendizado. A Wipro identificou uma abordagem iterativa para design como uma
forma de incorporar esta lio. Em um SDLC iterativo, a equipe passou pelos mesmos passos de
desenvolvimento do modelo cascata, mas o ciclo foi repetido diversas vezes com cada vez mais
funcionalidade adicionada a cada ciclo.
Iterao desempenhou um importante papel em um projeto de telecomunicaes. O gerente
estava lanando um novo projeto para um cliente estabelecido e decidiu incorporar princpios lean
pela primeira vez. Normalmente, projetos para este cliente duravam um ano e utilizavam um ciclo de
vida cascata. Desta vez, o gerente e o arquiteto, usando ferramentas como a matriz da estrutura de
design (discutida abaixo) dividiram o projeto em cinco fases. Ento, trabalhando com o cliente, eles
priorizaram as partes em cada fase e comearam a trabalhar na primeira fase.
Depois que a equipe concluiu a primeira fase, o cliente decidiu mudar o projeto de .Net para Java
(resultando em uma mudana tanto de linguagem quanto de arquitetura). A equipe no tinha o
conhecimento necessrio sobre Java, por isso passou por um treinamento de duas semanas. Para
maximizar o aprendizado especfico do projeto, o gerente trabalhou com a equipe de treinamento
para usar os resultados da fase 1 como exemplos e exerccios de treinamento. Como todos vinham
trabalhando juntos na fase 1, isso fornecia um meio eficiente de ensinar o novo material (em oposio
abordagem anterior, onde indivduos ainda estariam trabalhando em suas prprias partes e no
teriam integrado seu trabalho). A combinao de princpios lean levou a um aprendizado mais rpido
e a uma melhor performance. Assim, apesar da mudana de tecnologia, a equipe conseguiu concluir
o projeto, programado para durar quinze meses, com trs meses de antecedncia. O gerente de
projeto descreveu assim a mudana: Ns costumvamos comear devagar e a correr no final. O
sistema Lean realmente diminuiu os perodos de espera e permitiu que ns conclussemos o projeto
com sucesso em um prazo comprimido.
Matriz da estrutura de design Um dos principais desafios para a Wipro com um modelo
iterativo era definir o que deveria fazer parte de cada iterao. A literatura sobre engenharia de
software no fornecia uma recomendao conclusiva, mas a empresa adaptou a matriz da estrutura
de design (DSM) tarefa.
Uma DSM uma matriz binria, quadrada, que no caso da Wipro usava a atividade ou
funcionalidade requeridas como dados. Um nmero um colocado na matriz para indicar uma
dependncia futura (colocada abaixo da linha diagonal) ou um loop de feedback (colocado acima da
linha diagonal). Depois que a DSM inicial preenchida, o prximo passo dividir a matriz. Esta
diviso feita para que tarefas independentes (isto , tarefas upstream) sejam programadas antes de
suas correspondentes dependentes (isto , tarefas downstream) e funcionalidades conjuntamente
dependentes sejam programadas para o mesmo momento. Embora haja diferentes abordagens para a
diviso da matriz, o objetivo transform-la em uma forma triangular inferior ou, se isso no
possvel, pelo menos em uma forma triangular blocada. Finalmente, a DSM combinada para que
tarefas que devem ser programadas simultaneamente sejam destacadas 5. Um representante de SQA
descreveu o valor da DSM:
Ver http://www.dsmweb.org para mais informaes sobre DSM.
11

612-P11
Todas as abordagens de melhoria que utilizamos foram um gerente de projeto a planejar melhor
e monitorar mais de perto, e ambas estas atividades melhoram a performance. Com a DSM, o gerente
tem uma ferramenta para tirar o conhecimento de sua cabea e coloc-lo no papel. No d para fazer
tudo de cabea.
O impacto da DSM pode ser visto em sua utilizao em um contexto de interveno na Wipro.
Um grande cliente da empresa convocou uma pequena equipe para transferir o aplicativo de vendas
mveis da empresa de Palm OS para Windows CE. O cliente inicialmente solicitou entrega em quatro
semanas e o gerente de projeto desenvolveu um plano. Antes do trabalho comear, o cliente pediu
que a equipe entregasse o trabalho em trs semanas. O gerente procurou o representante de SQA e
um membro do setor de produtividade querendo saber como poupar tempo. Eles sugeriram o
sistema Lean e, alm de outros princpios lean (por exemplo, iteraes e quadro de controle visual),
eles recomendaram usar uma DSM. Os trs sentaram-se com o lder tcnico do projeto e preencheram
a matriz DSM (veja no Anexo 5 uma cpia das DSM inicial, dividida e combinada). A DSM inicial
mostra que o primeiro plano do gerente no levava em considerao todas as dependncias do
projeto (por exemplo, doze depende de quinze, mas doze est programado para antes de quinze). O
gerente identificou estas contradies no processo de planejamento e as corrigiu com a DSM
combinada. Com a aplicao da DSM e outros princpios lean, a equipe finalizou o projeto em duas
semanas, cumprindo o novo prazo solicitado pelo cliente.
A maioria dos projetos lean na Wipro usava a DSM. A ferramenta havia se tornado to popular
que Navneet Bhushan, um funcionrio do setor de produtividade, disse: Lean tornou-se sinnimo de
DSM para muitas pessoas. O apelo que a DSM oferece uma ferramenta onde algum insere os
dados, aperta um boto e, ento, recebe uma resposta. Alm da DSM, a Wipro usou sua prpria
experincia para desenvolver uma ferramenta similar, um estimador de complexidade. Esta
ferramenta permitia que os usurios considerassem a complexidade da funcionalidade quanto esto
criando um plano de projeto.
Quadro de controle visual Quadros de controle visual (VCB) so usados no sistema Lean para
aumentar a comunicao e destacar determinadas questes, para que o problema e a soluo
permaneam juntos. Na Wipro, um VCB comeava com o gerente de projeto dividindo o trabalho em
sesses de um ou dois dias. A seguir, em uma grande folha de papel, o gerente desenhava uma tabela
e escrevia os dias da semana no alto das colunas e os nomes dos engenheiros no incio das linhas. O
gerente ento pregava o VCB na parede para que todos os membros da equipe pudessem v-lo. O
trabalho que um engenheiro deveria concluir em um determinado dia era inserido na clula
apropriada. No final de cada dia, um engenheiro anotava a porcentagem do trabalho que ele ou ela
havia concludo. Se fosse menos de 100%, o nmero era escrito em vermelho. Se os engenheiros
terminassem seu trabalho cedo, eles podiam comear o trabalho do dia seguinte. (O Anexo 6 mostra
um VCB hipottico que a equipe havia concludo at quarta-feira.)
Com o VCB, o gerente de projeto agora tinha um lugar para visualizar o status da equipe, ao invs
de ter que ir at os lderes de mdulos ou fazer pesquisas com os membros da equipe. Alm disso, o
quadro forava o gerente a dividir o trabalho a ser concludo em sesses de um ou dois dias. Estes
pedaos menores tornavam mais fcil monitorar o progresso e perceber problemas mais cedo. Para os
membros da equipe, o quadro fornecia uma viso geral do projeto como um todo. Assim, eles sabiam
onde o seu trabalho se encaixava dentro do projeto. Eles tambm ficavam sabendo de quem o seu
trabalho dependia e podiam ir at esta pessoa diretamente se necessrio. Finalmente, o VCB podia ser
usado para que os membros da equipe iniciassem novos trabalhos se o trabalho atual havia sido
concludo antes do previsto.
12

612-P11
Autonomao/Jidoka Outro dos princpios do sistema Lean criar testes simples e confiveis
para identificar problemas. A Wipro lidou com isso de duas formas. A primeira foi atravs de
revises de cdigo peridicas. Embora estas j fossem parte do processo mandatrio h bastante
tempo, sua utilizao aumentou aps a introduo do sistema Lean. Idealmente, as revises ocorriam
diariamente, mas em alguns casos elas aconteciam com menor frequncia. Como o nome sugere, em
uma reviso diria de cdigo algum confere o cdigo a cada dia. Esta reviso poderia ser uma
anlise visual em busca de erros ou um checagem de conformidade com os padres de design.
Algumas vezes, membros snior da equipe faziam a reviso, enquanto outras vezes pares ou grupos
de membros checavam o trabalho uns dos outros. A segunda forma era fazer com que a equipe
compilasse todo o seu trabalho atual a cada dia e, em seguida, realizasse testes automticos, criados
individualmente. Os membros da equipe construam esses casos de teste para checar se os mdulos
cumpriam as metas estabelecidas.
Heijunka/Nivelamento Outra ideia Lean incorporada pela Wipro era heijunka, ou
nivelamento. O conceito de heijunka nivelar a carga de trabalho, para que o sistema funcione a
uma taxa constante. Por exemplo, se uma fbrica tem demanda de 72 unidades por dia, um tempo de
ciclo de 10 unidades por hora e opera por oito horas, o mtodo tradicional seria operar a fbrica a
velocidade mxima por 7,2 horas para cumprir a demanda e a gerar inventrio extra ou encerrar as
atividades do dia. Usando o princpio de heijunka, uma empresa iria, ao invs disso, operar a fbrica
a uma taxa de 90% para cumprir a demanda ao longo de todo o dia. Este espalhamento do trabalho
reduz picos de demanda e uma parte importante dos sistemas lean de uma maneira geral,
reduzindo variabilidade na carga de trabalho enquanto aumenta a capacidade de responder s
necessidades dos clientes.
A necessidade de nivelamento na Wipro surgiu em um dos primeiros projetos lean da empresa.
Durante este projeto, a Wipro no estava apenas trabalhando com seu cliente, mas tambm com um
integrador de sistemas e outros desenvolvedores terceirizados. Usando outras contramedidas lean, a
Wipro foi capaz de concluir seu trabalho com muito mais rapidez, mas como seus parceiros no
estavam preparados para aceitar as recomendaes da Wipro no incio, a empresa perdeu sua
vantagem enquanto esperava por seus parceiros. No projeto seguinte, os outros princpios lean foram
incorporados, mas ao invs de tentar terminar o trabalho rapidamente, eles concluram o trabalho
com menos recursos. O nivelamento do trabalho ajudou a Wipro a manter as vantagens obtidas com
o sistema Lean no segundo projeto.
Mapeamento de fluxo de valor Um dos principais objetivos do sistema Lean fazer a

empresa se concentrar em fornecer valor ao cliente e eliminar todas as partes do processo que no
adicionam valor. Um mapeamento de fluxo de valor (VSM) similar a um diagrama de fluxo de
processo, mas ele classifica passos de acordo com o fato deles adicionarem valor ou no.
Mapeamento de fluxo de valor era uma rea na qual os gerentes de projeto tinham conseguido
envolver suas equipes nos processos lean. Depois de um VSM, uma equipe percebeu que seu processo
dependia de uma nica impressora de testes (eles estavam projetando formulrios automticos para
um banco e usavam a impressora para testar os resultados). No apenas quatro pessoas diferentes
estavam utilizando uma nica impressora, o que resultava em esperas significativas, como tambm a
impressora estava localizada um andar acima da equipe. Eles estimaram que um processo que
deveria durar uma hora estava levando duas. Para resolver este problema, eles instalaram um
computador de testes ao lado da impressora e alocaram perodos de tempo para cada engenheiro.
Embora a Wipro tivesse usado o mapa de fluxo de valor com sucesso para reorganizar fluxos de
processo, os benefcios de se concentrar no valor para o cliente foram se desenvolvendo mais
13

612-P11
lentamente. Um bom exemplo da dificuldade de mudar a mentalidade para identificar novas formas
de fornecer valor ao cliente ocorreu em uma sesso de treinamento lean. A equipe estava
desenvolvendo drivers de impressora e tentou definir o que significava valor para o cliente. Depois
de uma longa discusso, eles acabaram determinando que o driver de impressora representava valor.
Com a iniciativa em seu 24 ms, a diretoria queria ver resultados. Havia um desejo de ver e
validar resultados reais. Uma comparao de projetos prximos com e sem a interveno lean indicou
que os projetos lean podiam ser capazes de lidar melhor com volatilidade de requisitos, com menos
revises de agenda. Embora as coisas estivessem indo em uma direo positiva, uma melhoria
explosiva de produtividade ou grande reduo de esforos no eram visveis. Olhando para trs,
Alexis e Deb acharam que o sistema Lean precisava impactar pores maiores de um projeto e
tambm ser utilizado no nvel de contas.
Prximos Passos
Deb e Alexis se despediram e entraram em seus carros. Enquanto se preparavam para enfrentar o
trnsito de Bangalore, eles continuaram a pensar sobre quais deveriam ser os prximos passos para a
empresa. Embora a implementao havia sido bem-sucedida at ento, eles sabiam que ainda tinham
muito cho pela frente. Havia outras contramedidas que eles deveriam introduzir na empresa? Se a
chave do sistema Lean era incorporar mltiplas contramedidas em um sistema coerente, eles estavam
fazendo isso? Lean era o melhor caminho a seguir e, caso fosse, como deveria ser adaptado? Eles
deveriam estar tentando criar algo diferente de Lean: um Jeito Wipro completamente diferente?
Finalmente, era hora de criar uma estrutura lean formal? Qual seria a melhor abordagem para
estabelecer a diferena entre impor melhores prticas e deixar espao para a experimentao?
14
612-P11
-15-
612-P11
-16-
612-P11
-1-
612-P11
-1-
612-P11
-1-
20
612-P11
--
612-P11
--
612-P11
--

Wipro

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Wipro

Enviado por

Direitos autorais:

Formatos disponíveis

For exclusive use FGV - EAESP, 2015

O Sistema Lean na Wipro Technologies

Sambuddha Deb, diretor de qualidade e chefe de excelncia operacional da Wipro Technologies, e

Viso Geral da Empresa

For exclusive use FGV - EAESP, 2015

O Sistema Lean na Wipro Technologies

aplicativos, alm de servios de pesquisa e desenvolvimento e gerenciamento de infraestrutura de TI.

For exclusive use FGV - EAESP, 2015

Iniciativas de Qualidade Anteriores

For exclusive use FGV - EAESP, 2015

O Sistema Lean na Wipro Technologies

For exclusive use FGV - EAESP, 2015

For exclusive use FGV - EAESP, 2015

O Sistema Lean na Wipro Technologies

Questes ligadas a clientes

For exclusive use FGV - EAESP, 2015

Implementao do Sistema Lean

For exclusive use FGV - EAESP, 2015

O Sistema Lean na Wipro Technologies

2 Lean Thinking e The Toyota Way

For exclusive use FGV - EAESP, 2015

O setor de produtividade desempenhou um importante papel na implementao do sistema Lean

For exclusive use FGV - EAESP, 2015

O Sistema Lean na Wipro Technologies

For exclusive use FGV - EAESP, 2015

Aproximando problemas e solues Um dos principais objetivos do sistema Lean unir o

Ver http://www.dsmweb.org para mais informaes sobre DSM.

For exclusive use FGV - EAESP, 2015

O Sistema Lean na Wipro Technologies

For exclusive use FGV - EAESP, 2015

Mapeamento de fluxo de valor Um dos principais objetivos do sistema Lean fazer a

For exclusive use FGV - EAESP, 2015

O Sistema Lean na Wipro Technologies

For exclusive use FGV - EAESP, 2015

For exclusive use FGV - EAESP, 2015

For exclusive use FGV - EAESP, 2015

For exclusive use FGV - EAESP, 2015

For exclusive use FGV - EAESP, 2015

For exclusive use FGV - EAESP, 2015

For exclusive use FGV - EAESP, 2015

For exclusive use FGV - EAESP, 2015

Você também pode gostar