O Sistema Lean na Wipro Technologies

Prévia do material em texto

612-P11 
 O C T O B E R 1 6 , 2 0 0 9 
 
 
________________________________________________________________________________________________________________ 
Caso LACC número 612-P11 é a versão traduzida para Português do caso número 607-032 da HBS. Os casos da HBS são desenvolvidos somente 
como base para discussões em classe. Casos não devem servir como aprovação, fonte primária de dados ou informação, ou como ilustração de 
um gerenciamento eficaz ou ineficaz. 
 
 Copyright 2011 President and Fellows of Harvard College. Nenhuma parte desta publicação pode ser reproduzida, armazenada em um sistema 
de dados, usada em uma tabela de dados, ou transmitida de qualquer forma ou por qualquer meio - eletrônico, mecânico, fotocopiada, gravada, 
ou qualquer outra - sem a permissão da Harvard Business School. 
 
D A V I D M . U P T O N 
B R A D L E Y R . S T A A T S 
 
O Sistema Lean na Wipro Technologies 
“Nós queremos trazer a próxima geração do pensamento lean para os nossos processos e incorporá-la ao 
nosso sistema para gerar uma vantagem competitiva sustentável.” 
- Azim Premji, Presidente da Wipro 
 
Sambuddha Deb, diretor de qualidade e chefe de excelência operacional da Wipro Technologies, e 
Alexis Samuel, gerente geral de processos, ferramentas e produtividade, agradeceram os outros 
presentes na sessão de revisão de projetos lean e saíram juntos da sala. O belo e ensolarado dia de 
janeiro e a atmosfera típica de um jardim nas instalações da Wipro Technologies em Bangalore, Índia, 
combinavam bem com o atual bom humor dos dois. Enquanto andavam em direção 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 Produção (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 tópicos de discussão em toda a empresa, das 
salas de conferência às cafeterias espalhadas por toda a Índia. Apesar dos resultados positivos 
iniciais, a implementação da iniciativa lean estava longe de ser concluída. A Wipro tinha mais de 
1.100 projetos simultâneos, o que significava que apenas 15% deles estava usando os conceitos Lean. 
O processo até então havia sido caracterizado por uma grande quantidade de experimentação, com 
um envolvimento central limitado. Eles se perguntavam se agora não 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 possível ter 
serviços de software lean ou eles deveriam estar desenvolvendo melhores práticas para seu próprio 
sistema, um “Jeito Wipro” talvez? 
 
Visão Geral da Empresa 
A Wipro Technologies, uma subsidiária da Wipro Ltda., competia no mercado global de serviços 
de software. A empresa fornecia serviços de integração, desenvolvimento e manutenção de 
Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
Grazi
Realce
Grazi
Realce
Grazi
Realce
Grazi
Realce
612-P11 O Sistema Lean na Wipro Technologies 
2 
aplicativos, além de serviços de pesquisa e desenvolvimento e gerenciamento de infraestrutura de TI. 
Os serviços de software da Wipro incluíam muitas áreas tecnológicas, como servidor de clientes, 
armazenamento de dados, comércio eletrônico, sistemas embutidos, aplicativos de negócios, 
networking, soluções de telecomunicações e aplicativos de rede. A empresa operava em múltiplos 
setores, incluindo o setor bancário e de seguros, sistemas embutidos, energia e serviços de utilidade 
pública, serviços financeiros, saúde, manufatura, mídia, varejo, tecnologia, telecomunicações e 
transportes. 
No fim de 2005, a Wipro tinha mais de 35 mil funcionários e servia clientes em todo o mundo 
através de seus escritórios localizados em mais de 30 países (veja no Anexo 1 um resumo de 
estatísticas da empresa). A empresa teve receita de US$ 1,2 bilhão 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 distribuída 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 funcionários da Wipro tinham diplomas em ciência ou engenharia antes de começarem a 
trabalhar na empresa. 
Embora a empresa fosse uma fornecedora terceirizada de serviços de software, ela trabalhava 
tanto in loco (nas instalações do cliente) quanto à distância (nas instalações da Wipro, localizadas 
principalmente na Índia). Em 2005, a empresa realizou aproximadamente 75% de seu trabalho à 
distância e 25% in loco. Tanto pressões relacionadas a custos (trabalho feito à distância era 
relativamente mais barato) e uma falta de vistos de trabalho (particularmente para os EUA) estavam 
forçando a Wipro a realizar mais trabalhos à distância. 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 número de horas em que seus 
engenheiros trabalhavam no projeto mais o custo de qualquer software ou ferramentas necessários. 
Na abordagem mais recente, conhecida como projeto de preço fixo (FPP), a Wipro oferecia a seus 
clientes um preço fixo garantido pelo trabalho e, então, era responsável pela entrega do produto final. 
Qualquer esforço 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 
confortáveis com fornecedores terceirizados de serviços de software e estavam gerenciando custos de 
forma mais agressiva. Além disso, a Wipro considerava o modelo FPP atraente na medida em que a 
empresa vinha ficando mais confiante em assumir responsabilidade pelo projeto do começo ao fim e 
estava buscando colher os benefícios de seus esforços para melhoria de produtividade. 
 
Serviços de software 
O processo de desenvolvimento de software era similar em muitos aspectos ao processo de 
construção de uma casa. O primeiro passo para construir uma casa era especificar os requisitos 
necessários para a solução. Isso poderia incluir determinar o número de metros quadrados, andares, 
quartos, banheiros etc. Uma vez que os requisitos tenham sido especificados, então os arquitetos e 
engenheiros criam designs detalhados, que não apenas especificam a localização dos quartos e da 
estrutura geral (tomadas, torneiras, interruptores etc.), como também o posicionamento da 
infraestrutura elétrica e de encanamento. Somente depois disso começa o processo de construção. 
Durante a construção, falhas encontradas nas plantas são corrigidas e o trabalho é constantemente 
inspecionado em busca de defeitos. Quando sistemas são concluídos (por exemplo, o sistema de ar 
condicionado), eles são testados, e quando todo o trabalho está concluído, toda a casa é inspecionada, Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
Grazi
Realce
GraziRealce
 O Sistema Lean na Wipro Technologie 612-P11 
3 
primeiro pelo construtor e depois pelo cliente que compra a casa. No desenvolvimento de software, 
os mesmos passos básicos são tomados na maioria dos projetos, embora estes passos tenham nomes 
diferentes: especificação de requisitos, design detalhado, teste de código e unidade, teste de sistemas 
e, finalmente, teste de aceitação do usuário. Uma diferença entre construir uma casa e desenvolver 
um software é que o progresso ou a forma do que está por vir são frequentemente invisíveis para o 
usuário até que ele possa ver o produto ou serviço final em funcionamento. 
Serviços de software são um negócio diferente de softwares direcionados para o consumidor final 
(como Microsoft Word) ou sistemas de software para empresas (por exemplo, sistemas integrados de 
gestão empresarial, ou ERP). Muito do trabalho da Wipro não era desenvolvimento do começo, mas 
envolvia adaptar, conectar e apoiar sistemas de software existentes. Incertezas técnicas e de mercado 
eram menores para a Wipro do que para um desenvolvedor de softwares aplicativos, pois a empresa 
não 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 negócio dizendo: “Nós não construímos 
uma casa inteira para alguém. Ao invés disso, nós adicionamos a varanda nos fundos. Nós 
precisamos, no entanto, ter um bom conhecimento da casa em questão e da sua fundação e design 
antes de adicionar a varanda.” 
Havia duas outras importantes distinções no tipo de trabalho que a Wipro fazia. A empresa 
dividia-se em três unidades de negócios: Soluções de Engenharia de Produtos (PES, que consistia em 
telecomunicações e sistemas embutidos), Soluções Empresariais (ES) e Bancos, Finanças, Poupanças 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 começou a realizar 
serviços de desenvolvimento de software. Mais recentemente, clientes passaram a terceirizar sub-
sistemas inteiros ao invés de apenas softwares. A Wipro estava começando a assumir 
responsabilidade pelo gerenciamento tanto da manutenção 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 Informação do cliente. Projetos nestas duas unidades de negócio eram 
geralmente de um entre dois tipos: manutenção ou desenvolvimento. Projetos de manutenção 
envolviam apoiar e melhorar os sistemas existentes de um cliente. Por exemplo, apoiar o sistema 
integrado de gestão empresarial de um cliente era um projeto de manutenção 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 móvel 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, relatórios 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 começou na Wipro em 2002 depois de deixar a GE, 
descreveu desta forma o foco em qualidade na Wipro: Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
Grazi
Realce
Grazi
Realce
Grazi
Realce
612-P11 O Sistema Lean na Wipro Technologies 
4 
“Antes de começar na Wipro, minha impressão era de que se tratava de uma organização focada 
na qualidade no sentido geral e em performance ideal em todos os contextos. Em várias ocasiões, 
percebi que a visão externa da situação é melhor que a visão interna. Mas este não era o caso na 
Wipro. Tipicamente, as pessoas que odeiam seu nível de qualidade são as equipes de vendas, porque 
eles são aqueles que estão em contato com o cliente, ouvindo reclamações sobre tudo que está dando 
errado. Mas isso não acontece aqui; as equipes de vendas adoram nosso nível de qualidade.” 
Muito do foco em qualidade veio da descrença inicial que a empresa enfrentou quando estava 
entrando, e depois competindo, no mercado internacional de serviços de software no final dos anos 
80 e início dos anos 90. Clientes globais demonstraram ceticismo de que uma pequena empresa na 
Índia poderia fornecer o software de alta qualidade de que seus negócios precisavam. Assim, a 
empresa se concentrou em abordagens públicas 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 certificação 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 intenção de “avançar o estado da prática de engenharia 
de software”1 O instituto estabeleceu o Modelo de Amadurecimento de Capacidade (CMM) para 
softwares e, em 1998, a Wipro tornou-se a primeira empresa de serviços de TI a conquistar o nível 5 
do modelo. Em 1997, inspirada por uma joint venture entre outra subsidiária da Wipro Ltda. e a 
General Electric (GE), a empresa foi a primeira a introduzir o sistema Six Sigma aos serviços 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 técnicas estatísticas, professores chamados de “faixas pretas” e 
normalmente um processo DMAIC (Definir, Medir, Analisar, Melhorar [Improve] e Controlar) para 
tentar reduzir o número total de “defeitos” para 3,4 por milhão de oportunidades. 
Mais tarde em 2002, quando o SEI introduziu uma nova versão do CMM, CMM Integrated 
(CMMI), a Wipro novamente tornou-se a primeira empresa do mundo a receber a certificação de 
nível 5. As iniciativas de melhoria de processo da empresa levaram a melhorias consistentes em 
qualidade, aderência a prazos e aderência a esforços (veja no Anexo 3 detalhes de 1995 a 2004). Em 
2004, a Wipro percebeu que suas iniciativas de melhoria de processo estavam empacando. Um líder 
sênior de qualidade da empresa afirmou: 
“Iniciativas de qualidade duram de 18 a 24 meses, talvez 36 meses se você tem sorte. A razão 
para isso é que ou cada iniciativa se concentrava em processos de controle mais avançados 
quando comparadas às anteriores, ou em novas técnicas, como o uso de controle estatístico de 
processos no sistema Six Sigma, e cada uma destas fornecia retornos menores com o tempo. Nós 
sabíamos que era hora de começar a procurar algo novo.” 
Desafios em 2004 
Em 2004, a Wipro estava enfrentando tanto desafios estáticos quanto dinâmicos. Havia dois 
fatores estáticos que todos os fornecedores de serviços de software enfrentavam. Primeiro, o principal 
fator para o desenvolvimento de software era engenheiros de software talentosos. O estereótipo era 
de que os engenheiros de software eram pessoas cabeça dura e independentes, que acreditavam que 
 
1 Software Engineering Institute, “About theSEI”, website do Instituto de Engenharia de Software, 
http://www.sei.cmu.edu/about/about.html. Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
Grazi
Realce
Grazi
Realce
Grazi
Realce
Grazi
Realce
 O Sistema Lean na Wipro Technologie 612-P11 
5 
seu trabalho era uma arte e gostavam de fazer coisas de sua própria maneira. Muitos engenheiros de 
software concordavam que esta reputação era merecida. Segundo, serviços de software era 
inerentemente um negócio variável. Projetos eram customizados para cada cliente e, portanto, eram 
idiossincráticos 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 não 
apenas que sistemas estavam sendo integrados (algo mais ou menos consistente em todos os 
projetos), mas também por como o cliente havia implementado estes sistemas dentro de seus 
negócios (algo idiossincrático em todos os projetos). Além destas questões constantes, havia também 
mudanças dinâmicas acontecendo no mercado. 
 
Questões organizacionais 
Além do sentimento da empresa de que sua iniciativa de qualidade atual (Six Sigma) estava se 
estagnando, havia vários outros desafios organizacionais sendo enfrentados pela Wipro. No final de 
2003, a empresa tinha quase 18 mil funcionários, um aumento de 40% com relação ao ano anterior. 
Além do aumento geral de funcionários, a taxa de saída de funcionários na maioria das empresas de 
serviços de software da Índia (incluindo a Wipro) era de em média 10% a 20% por ano. A rápida 
entrada e troca de pessoal significava que qualquer processo de software utilizado na empresa 
precisava ser robusto o suficiente para fornecer a orientação necessária 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 responsáveis por criar um detalhado planejamento do 
projeto usando Microsoft Project e, em seguida, designar tarefas específicas para os membros da 
equipe. Como disse Alexis Samuel, “com nossa configuração atual, o poder latente dos engenheiros 
não é aproveitado”, e a empresa queria uma abordagem processual que iria “capturar alguns dos 
benefícios de dar poder aos membros das equipes”. 
Finalmente, a Wipro vivenciava variações substanciais em performance através das diferentes 
unidades de negócio da empresa. Embora parte desta variação fosse resultado de características 
básicas das indústrias que as unidades de negócio serviam, uma quantidade significativa não era. A 
empresa tinha um sistema de gerenciamento de conhecimento que foi usado com algum sucesso, mas 
ainda havia uma crença de que melhores práticas em uma área da empresa não estavam sendo 
reproduzidas com sucesso em outras unidades de negócio. 
 
Questões de competitividade 
Além dos desafios organizacionais, a empresa enfrentava um contexto estratégico dinâmico. 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 diferença estava diminuindo, já que a alta 
demanda por engenheiros de software talentosos na Índia estava aumentando seu valor (salários 
cresciam em média 12% ao ano), e concorrentes internacionais estavam expandindo sua presença na 
Índia para tirar vantagem de alguns dos recursos de baixo custo que a Wipro utilizava. Além disso, 
embora houvesse empresas menores em outros países com baixos salários pressionando a Wipro (por 
exemplo, China, Filipinas, Vietnã e Rússia), uma das maiores ameaças vinha de novas empresas 
indianas. Deb descreveu o desafio da seguinte forma: “A Índia forma mais de 380 mil engenheiros de Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
Grazi
Realce
Grazi
Realce
Grazi
Realce
Grazi
Realce
Grazi
Realce
612-P11 O Sistema Lean na Wipro Technologies 
6 
software qualificados, que falam inglês, por ano. Os recursos para executar uma estratégia simples, 
de baixo custo, estão se renovando constantemente na Índia.” 
Adicionalmente, embora o mercado reconhecesse a Wipro como líder em qualidade, seus 
concorrentes estavam diminuindo esta diferença. Diz Alexis: “Um grande desafio para nós é que, em 
comparação com três anos atrás, as pessoas estão alcançando a Wipro.” 
Finalmente, a Wipro acreditava que estava acontecendo uma mudança significativa no mercado. 
Havia uma visão interna de que o setor de TI estava deixando a produção artesanal para trás e havia 
uma oportunidade para se tornar líder em processos. Anurag descreveu assim a situação: 
“Na minha opinião, TI está na mesma situação que a indústria automobilística em 1910-1920. 
Hoje, cada organização faz seu trabalho de forma única; ainda estamos na fase da produção artesanal. 
No entanto, há tanta ineficiência que pode ser eliminada e o mercado é muito competitivo para que 
ela não seja eliminada. Nós vemos isso acontecendo. Toda a onda de terceirização e globalização é 
prova de que a transição está acontecendo. Hoje, você deve ser capaz de fornecer consistentemente 
para diversos tipos de clientes. Não sabemos como fazer isso com software ainda, mas o setor de 
manufatura sabe. A chave para o sucesso de uma fábrica não é comprar máquinas – é gerenciar 
pessoas. Então, agora, a chave torna-se fazer dez mil pessoas trabalharem juntas. Assim, se você 
supõe 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. 
Não podemos ser o líder de marca atualmente, por isso não temos escolha a não ser sermos os mais 
eficientes.” 
 
Questões ligadas a clientes 
Em adição às dificuldades organizacionais e ao ambiente competitivo em mudança, a empresa 
descobriu que a demanda dos clientes estava passando por mudanças perceptíveis. Primeiro, o foco 
da competição no mercado estava mudando para além de simplesmente alta qualidade. S.M. Bala, o 
chefe de qualidade em PES, descreveu assim a situação: 
“Clientes estão começando a ver a qualidade como algo natural ao invés de usar a qualidade como 
forma de medir a performance. Na medida em que os clientes ganham em sofisticação, eles estão 
começando a usar custos para impulsionar a performance de seu fornecedor de serviços de software 
terceirizado, ao invés de usar qualidade. Inicialmente, clientes queriam verificações e um foco em 
qualidade porque eles queriam ter certeza de que os fornecedores estavam fazendo seu trabalho 
corretamente. Agora, clientes esperam reduções de custos regulares com melhoria de qualidade. 
Adicionalmente, o mercado continua a ver uma mudança de contratos T&M, em que o cliente assume 
o risco de custos extras, para contratos FPP, nos quais nós assumimos os riscos.” 
Embora os clientes estivessem esperando preços menores com melhor qualidade, eles também 
estavam começando a procurar por um produto diferente. Em 2004, clientes queriam que seus 
fornecedores de serviços de software oferecessem uma vantagem de negócios. Soluções técnicas não 
eram mais suficientes, já que clientes queriam soluções de negócios. O desafio para a Wipro era que 
padrões atuais na empresa eram padrões de processo, não padrões de processos de negócios. Dada 
umaespecificação técnica, as rotinas existentes eram otimizadas para fornecer um produto de alta 
confiabilidade que fosse de encontro a esta especificação. Elas não eram tão bem capacitadas para 
fornecer uma solução de negócios para o cliente. S.M. Bala descreveu o problema desta forma: Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
Grazi
Realce
 O Sistema Lean na Wipro Technologie 612-P11 
7 
“Precisamos conectar foco em negócios e foco em processos. Através de sistemas como CMM, nos 
tornamos bastante bons em gerenciamento de processos. No entanto, não sabemos como gerenciar 
pessoas. Em nossas pesquisas de satisfação de clientes, nossos clientes nos dizem: ‘Vocês são muito 
bons em fazer o que eu peço. Se eu peço para vocês construírem uma mesa com três pés, vocês fazem 
isso, mas vocês nunca perguntam porque a mesa tem apenas três pés’. Nossos clientes querem que a 
gente forneça ideias inovadoras. Eles podem não saber ainda [o que eles querem], mas eles sabem 
quando a Wipro não está fazendo-o.” 
 
Implementação do Sistema Lean 
Devido a todos os fatores mencionados, no começo 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 inovação. Após debates internos, eles 
chegaram a uma lista de três alternativas: o critério Malcolm Baldridge National Quality Award, o 
TRIZ (sigla de Teoria da Solução Inventiva de Problemas em russo) e o sistema Lean. A primeira era 
muito focada em qualidade e a segunda era muito focada em inovação. A terceira opção, no entanto, 
parecia ideal. 
A diretoria sênior decidiu abordar o sistema Lean de uma forma diferente da que tinha sido usada 
na implementação da iniciativa anterior, Six Sigma. A seguir, Deb descreve o processo de 
implementação do Six Sigma: 
“Com o Six Sigma, nós fizemos tudo de baixo para cima. Foi uma explosão. Nós passamos muito 
tempo criando uma abordagem Six Sigma para software e, em seguida, nós a impusemos a toda a 
organização. As ideias que tivemos funcionavam, então a efetividade estava alta, mas o engajamento 
era baixo. Levou muito tempo para que a iniciativa fosse aceita pela equipe. Assim, com o Lean, nós 
decidimos fazer as coisas de outra maneira. Nós sabíamos que estávamos correndo o risco de que a 
iniciativa tivesse um menor impacto, mas nós esperávamos ter uma aceitação maior”. 
A Wipro iniciou o processo lean formando uma equipe nuclear de dez pessoas. Esta equipe incluía 
Deb, Alexis, Ravishankar Kuni, diretor do setor de produtividade e a sua equipe (o grupo de quatro 
membros que iria supervisionar a implementação do sistema à medida que este crescesse), e outros 
líderes de qualidade e membros da gerencia sênior. O primeiro objetivo da organização era aprender 
sobre o sistema Lean, para que eles pudessem descobrir como “transferi-lo” para o setor de serviços 
de software. A equipe principal começou lendo tudo que eles conseguiram encontrar sobre a filosofia 
Lean. De janeiro a março de 2004, eles visitaram diferentes fábricas na Índia que estavam usando 
processos lean. Estas visitas incluíram uma viagem para uma planta da Toyota nas redondezas, além 
de uma planta na região de Tamil Nadu, que havia ganho o prestigiado prêmio Deming. A seguir, a 
empresa entrevistou consultores para tentar encontrar alguém que pudesse ajudar a guiá-los pelo 
processo. Deb descreveu desta forma a reunião com uma grande empresa global de consultoria 
estratégica: 
“Eles deixaram claro que não tinham nenhuma experiência anterior em implementar estes 
conceitos na área de software e teriam que aprender junto conosco. Nós conversamos com alguns 
especialistas japoneses e eles disseram a mesma coisa. Assim, nós não poderíamos usar uma solução 
criada por especialistas, porque ninguém tinha usado Lean em software antes. Nós teríamos que fazê-
lo sozinhos.” Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
Grazi
Realce
612-P11 O Sistema Lean na Wipro Technologies 
8 
No fim das contas, a Wipro acabou trazendo do Japão 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 não forneceram soluções, mas estimularam discussões. 
Quanto mais perguntas fizemos, melhor nós ficamos. Cada interação ajudou-nos a fazer 
descobertas.” 
Deb resumiu o principal aprendizado da equipe durante o processo, “Não se trata de teorizar, 
trata-se de fazer.” Então, para começar, eles decidiram que cada membro da equipe iria encontrar um 
projeto, começar a implementá-lo e fornecer resultados em dois a três meses. A equipe tinha que fazer 
isso ao mesmo tempo em que continuavam a realizar seu trabalho normal. Eles não tinham 
autoridade formal para obrigar a participação 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 nós tivemos discussões 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 três semanas, eu estava muito confuso e não sabia dizer à minha equipe 
o que era Lean. Eu tinha reuniões semanais com a equipe e passei de 3 a 4 horas ensinando-lhes sobre 
o sistema. Nas reuniões, eu listava ideias do TPS para eles discutirem.” 
A equipe Lean montou uma sala de estratégia eletrônica para compartilhamento de experiências 
dos vários 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 
implementação. 
O próximo passo, em novembro de 2004, foi realizar uma sessão 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 assistência com qualidade e produtividade, 
além de monitorar a conformidade do processo. O representante de SQA normalmente trabalhava em 
cinco a dez projetos por vez. Depois da sessão de treinamento, os membros da equipe de SQA 
deveriam encontrar um projeto lean no qual trabalhar. Além disso, neste momento, Azim Premji, o 
presidente da Wipro, anunciou publicamente que a empresa estava usando uma abordagem lean para 
serviços de software e estava esperando obter uma significativa vantagem competitiva com a 
mudança. Como disse um gerente sênior: “Ele anunciou que nós estávamos usando Lean. Isso 
demonstrou compromisso da diretoria, mas pode ter sido prematuro. De qualquer forma, agora nós 
temos que ir em frente.” 
Em agosto de 2005, vinte meses após o início da iniciativa lean, a Wipro tinha 112 projetos lean 
concluídos ou em processamento, e em janeiro de 2006 este número tinha aumentado para 235 (veja 
no Anexo 4 um histórico da implementação dos projetos Lean e Six Sigma). Algumas unidades de 
negócio já tinham realizado sessões de treinamento lean de meio período para seus gerentes de 
projeto. Ravishankar Kuni, diretor de produtividade da empresa,descreveu desta forma o progresso: 
“Lean é um processo lento – é uma mudança no estilo de gerenciamento – é uma mudança de 
cultura.” 
 
2 Lean Thinking e The Toyota Way Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
Grazi
Realce
Grazi
Realce
 O Sistema Lean na Wipro Technologie 612-P11 
9 
O setor de produtividade desempenhou um importante papel na implementação 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 
informação para a organização sobre Lean. O setor de produtividade incubava muitos dos novos 
conceitos Lean em seu estágio inicial e ajudava a treinar os gerentes de projeto enquanto eles testavam 
novos experimentos. Kuni explicou: “Quando o horizonte estava nebuloso e nós não sabíamos o que 
lean significava para serviços de software, o setor de produtividade serviu como um ponto de 
encontro para a organização.” 
 
Lean na Wipro 
Procedimento operacional padrão 
Como discutido anteriormente, CMMI era a abordagem geral de melhoria que a Wipro usava3. 
Além disso, houve vários ciclos de vida para desenvolvimento de software (SDLC) em conformidade 
com CMMI que a empresa empregou para concluir projetos individuais. Exemplos incluíram 
cascatas, modelos iterativos e abordagens específicas 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 códigos, realizava testes nas unidades, integrava as diferentes partes do projeto, 
conduzia testes de sistema e, então, fornecia-o a um cliente. O processo continuou linearmente e se 
havia feedback no sistema, era apenas entre estágios sucessivos. A abordagem cascata foi reconhecida 
como previsível e escalonável, 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 necessários. 
 
Projetos Lean 
A empresa achou que a conformidade com o nível 5 do CMMI continuava a ser um importante 
padrão externo, então, em sua forma inicial, Lean foi operacionalizado no nível de projeto como um 
ciclo de vida que ia de encontro aos requisitos de CMMI. Não havia requisitos centralizados para um 
projeto ser considerado lean, mas a expectativa era que um projeto lean usasse várias das diferentes 
contramedidas lean. O setor de produtividade mantinha uma lista dos projetos lean e todos os meses 
eram feitas revisões destes projetos, em que as equipes apresentavam seu progresso. Algumas 
unidades de negócio incluíam líderes de negócio nestas reuniões, 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” metodológica acontecendo entre proponentes do CMMI e de métodos ágeis de 
programação (por exemplo, Extreme Programming (XP), Scrum, Crystal). Alguns proponentes dos métodos ágeis 
argumentavam que CMMI criava processos sem razão de ser e entregava software confiável e de alta qualidade que não 
satisfazia as necessidades do cliente. Por outro lado, alguns proponentes do CMMI respondiam que métodos á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 circunstância em 
que o uso deles poderia ser apropriado em seu negócio. Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
612-P11 O Sistema Lean na Wipro Technologies 
10 
resultados em dois a três 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 
intervenção 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, esforço 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 raciocínio por trás do objetivo de 10% ou mais: 
“Se estabelecêssemos 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 não seria 
sustentável. Precisávamos estabelecer um objetivo que só poderia ser atingido realmente mudando 
como trabalhamos.” 
Se um gerente de projeto quisesse lançar um projeto lean, o representante de SQA e um membro 
do setor de produtividade forneceriam apoio, incluindo reuniões, conversas telefônicas e artigos 
sobre contramedidas lean. Normalmente, quando uma nova equipe começava um projeto lean, era 
data ao gerente de projeto a opção de ter o representante de SQA conduzir uma curta sessão 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 não eram obrigados a conduzir projetos lean. Unidades de negócio tinham metas com 
relação ao número de projetos lean que deveriam ser concluídos, mas isto não 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 não houvesse uma abordagem única para Lean na Wipro, várias 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 não começava 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 produção necessários em sequência, 
um de cada vez, ao invés de utilizar o processamento em série. 
Em um projeto de conversão de um website, a Wipro estava atualizando e melhorando o site de 
uma grande empresa. O site antigo consistia de páginas construídas em cima de 680 páginas de 
servidor Java (JPSs). Cada página do site podia levar a múltiplas JPSs. No passado, em um projeto de 
conversão como este, o gerente de projeto designava alguns indivíduos para converter todas as JPSs, 
enquanto outros membros da equipe trabalhavam nas páginas do site que levariam a elas. Ao invés 
disso, neste projeto a equipe moveu cada página em um processo defluxo único, trabalhando em 
uma JPS somente quando uma página do site levava a ela. Ao usar esta abordagem, a equipe 
 
4 Ao descrever suas diferentes ferramentas e técnicas, a Toyota usa o termo contramedidas ao invés de soluções. 
Isso porque cada resposta é vista como um meio para um fim (por exemplo, redução de desperdício) ao invés de 
uma resposta por si só. Para mais informações, consulte Steven Spear e H. Kent Bowen, “Decoding the DNA of 
the Toyota Production System”, Harvard Business Review (Setembro/Outubro 1999): 97-106. Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
Grazi
Realce
Grazi
Realce
Grazi
Realce
Grazi
Realce
 O Sistema Lean na Wipro Technologie 612-P11 
11 
percebeu que 200 das JPSs (aproximadamente 30%) não estavam ligadas às paginas do site e, por isso, 
não precisavam ser convertidas. 
Aproximando problemas e soluções – Um dos principais objetivos do sistema Lean é unir o 
problema e a solução no tempo, no espaço 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 lição. 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. 
Iteração desempenhou um importante papel em um projeto de telecomunicações. O gerente 
estava lançando um novo projeto para um cliente estabelecido e decidiu incorporar princípios 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. Então, trabalhando com o cliente, eles 
priorizaram as partes em cada fase e começaram 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 mudança tanto de linguagem quanto de arquitetura). A equipe não tinha o 
conhecimento necessário sobre Java, por isso passou por um treinamento de duas semanas. Para 
maximizar o aprendizado específico do projeto, o gerente trabalhou com a equipe de treinamento 
para usar os resultados da fase 1 como exemplos e exercícios de treinamento. Como todos vinham 
trabalhando juntos na fase 1, isso fornecia um meio eficiente de ensinar o novo material (em oposição 
à abordagem anterior, onde indivíduos ainda estariam trabalhando em suas próprias partes e não 
teriam integrado seu trabalho). A combinação de princípios lean levou a um aprendizado mais rápido 
e a uma melhor performance. Assim, apesar da mudança de tecnologia, a equipe conseguiu concluir 
o projeto, programado para durar quinze meses, com três meses de antecedência. O gerente de 
projeto descreveu assim a mudança: “Nós costumávamos começar devagar e aí correr no final. O 
sistema Lean realmente diminuiu os períodos de espera e permitiu que nós concluíssemos 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 iteração. A literatura sobre engenharia de 
software não fornecia uma recomendação conclusiva, mas a empresa adaptou a matriz da estrutura 
de design (DSM) à tarefa. 
Uma DSM é uma matriz binária, quadrada, que no caso da Wipro usava a atividade ou 
funcionalidade requeridas como dados. Um número um é colocado na matriz para indicar uma 
dependência futura (colocada abaixo da linha diagonal) ou um loop de feedback (colocado acima da 
linha diagonal). Depois que a DSM inicial é preenchida, o próximo passo é dividir a matriz. Esta 
divisão é 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 
divisão da matriz, o objetivo é transformá-la em uma forma triangular inferior ou, se isso não é 
possível, pelo menos em uma forma triangular blocada. Finalmente, a DSM é “combinada” para que 
tarefas que devem ser programadas simultaneamente sejam destacadas5. Um representante de SQA 
descreveu o valor da DSM: 
 
5 Ver http://www.dsmweb.org para mais informações sobre DSM. Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
Grazi
Realce
Grazi
Realce
Grazi
Realce
Grazi
Realce
Grazi
Realce
612-P11 O Sistema Lean na Wipro Technologies 
12 
“Todas as abordagens de melhoria que utilizamos forçam 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 cabeça e colocá-lo no papel. Não dá para fazer 
tudo de cabeça”. 
O impacto da DSM pode ser visto em sua utilização em um contexto de intervenção na Wipro. 
Um grande cliente da empresa convocou uma pequena equipe para transferir o aplicativo de vendas 
móveis 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 começar, o cliente pediu 
que a equipe entregasse o trabalho em três 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, além de outros princípios lean (por exemplo, iterações e quadro de controle visual), 
eles recomendaram usar uma DSM. Os três sentaram-se com o líder técnico do projeto e preencheram 
a matriz DSM (veja no Anexo 5 uma cópia das DSM inicial, dividida e combinada). A DSM inicial 
mostra que o primeiro plano do gerente não levava em consideração todas as dependências do 
projeto (por exemplo, doze depende de quinze, mas doze está programado para antes de quinze). O 
gerente identificou estas contradições no processo de planejamento e as corrigiu com a DSM 
combinada. Com a aplicação da DSM e outros princípios 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 tão popular 
que Navneet Bhushan, um funcionário do setor de produtividade, disse: “Lean tornou-se sinônimo de 
DSM para muitas pessoas. O apelo é que a DSM oferece uma ferramenta onde alguém insere os 
dados, aperta um botão e, então, recebe uma resposta.” Além da DSM, a Wipro usou sua própria 
experiência para desenvolver uma ferramenta similar, um estimador de complexidade. Esta 
ferramenta permitia que os usuários considerassem a complexidade da funcionalidade quanto estão 
criando um plano de projeto. 
Quadro de controle visual – Quadros de controle visual (VCB) são usados no sistema Lean para 
aumentar a comunicação e destacar determinadas questões, para que o problema e a solução 
permaneçam juntos. Na Wipro, um VCB começava com o gerente de projeto dividindo o trabalho em 
sessões 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 início das linhas. O 
gerente então pregava o VCB na parede para quetodos os membros da equipe pudessem vê-lo. O 
trabalho que um engenheiro deveria concluir em um determinado dia era inserido na célula 
apropriada. No final de cada dia, um engenheiro anotava a porcentagem do trabalho que ele ou ela 
havia concluído. Se fosse menos de 100%, o número era escrito em vermelho. Se os engenheiros 
terminassem seu trabalho cedo, eles podiam começar o trabalho do dia seguinte. (O Anexo 6 mostra 
um VCB hipotético que a equipe havia concluído até quarta-feira.) 
Com o VCB, o gerente de projeto agora tinha um lugar para visualizar o status da equipe, ao invés 
de ter que ir até os líderes de módulos ou fazer pesquisas com os membros da equipe. Além disso, o 
quadro forçava o gerente a dividir o trabalho a ser concluído em sessões de um ou dois dias. Estes 
pedaços menores tornavam mais fácil monitorar o progresso e perceber problemas mais cedo. Para os 
membros da equipe, o quadro fornecia uma visão geral do projeto como um todo. Assim, eles sabiam 
onde o seu trabalho se encaixava dentro do projeto. Eles também ficavam sabendo de quem o seu 
trabalho dependia e podiam ir até esta pessoa diretamente se necessário. Finalmente, o VCB podia ser 
usado para que os membros da equipe iniciassem novos trabalhos se o trabalho atual havia sido 
concluído antes do previsto. Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
Grazi
Realce
Grazi
Realce
Grazi
Realce
Grazi
Realce
Grazi
Realce
 O Sistema Lean na Wipro Technologie 612-P11 
13 
Autonomação/Jidoka – Outro dos princípios do sistema Lean é criar testes simples e confiáveis 
para identificar problemas. A Wipro lidou com isso de duas formas. A primeira foi através de 
revisões de código periódicas. Embora estas já fossem parte do processo mandatório há bastante 
tempo, sua utilização aumentou após a introdução do sistema Lean. Idealmente, as revisões ocorriam 
diariamente, mas em alguns casos elas aconteciam com menor frequência. Como o nome sugere, em 
uma revisão diária de código alguém confere o código a cada dia. Esta revisão poderia ser uma 
análise visual em busca de erros ou um checagem de conformidade com os padrões de design. 
Algumas vezes, membros sênior da equipe faziam a revisão, 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 automáticos, criados 
individualmente. Os membros da equipe construíam esses casos de teste para checar se os módulos 
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 fábrica tem demanda de 72 unidades por dia, um tempo de 
ciclo de 10 unidades por hora e opera por oito horas, o método tradicional seria operar a fábrica a 
velocidade máxima por 7,2 horas para cumprir a demanda e aí gerar inventário extra ou encerrar as 
atividades do dia. Usando o princípio de heijunka, uma empresa iria, ao invés disso, operar a fábrica 
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 não estava apenas trabalhando com seu cliente, mas também 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 não 
estavam preparados para aceitar as recomendações da Wipro no início, a empresa perdeu sua 
vantagem enquanto esperava por seus parceiros. No projeto seguinte, os outros princípios lean foram 
incorporados, mas ao invés de tentar terminar o trabalho rapidamente, eles concluíram 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 não 
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 não. 
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 formulários automáticos para 
um banco e usavam a impressora para testar os resultados). Não apenas quatro pessoas diferentes 
estavam utilizando uma única impressora, o que resultava em esperas significativas, como também 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 períodos de tempo para cada engenheiro. 
Embora a Wipro tivesse usado o mapa de fluxo de valor com sucesso para reorganizar fluxos de 
processo, os benefícios de se concentrar no valor para o cliente foram se desenvolvendo mais Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
Grazi
Realce
Grazi
Realce
Grazi
Realce
Grazi
Realce
612-P11 O Sistema Lean na Wipro Technologies 
14 
lentamente. Um bom exemplo da dificuldade de mudar a mentalidade para identificar novas formas 
de fornecer valor ao cliente ocorreu em uma sessão de treinamento lean. A equipe estava 
desenvolvendo drivers de impressora e tentou definir o que significava valor para o cliente. Depois 
de uma longa discussão, eles acabaram determinando que o driver de impressora representava valor. 
Com a iniciativa em seu 24º mês, a diretoria queria ver resultados. Havia um desejo de ver e 
validar resultados reais. Uma comparação de projetos próximos com e sem a intervenção lean indicou 
que os projetos lean podiam ser capazes de lidar melhor com volatilidade de requisitos, com menos 
revisões de agenda. Embora as coisas estivessem indo em uma direção positiva, uma melhoria 
explosiva de produtividade ou grande redução de esforços não eram visíveis. Olhando para trás, 
Alexis e Deb acharam que o sistema Lean precisava impactar porções maiores de um projeto e 
também ser utilizado no nível de contas. 
 
Próximos Passos 
Deb e Alexis se despediram e entraram em seus carros. Enquanto se preparavam para enfrentar o 
trânsito de Bangalore, eles continuaram a pensar sobre quais deveriam ser os próximos passos para a 
empresa. Embora a implementação havia sido bem-sucedida até então, eles sabiam que ainda tinham 
muito chão pela frente. Havia outras contramedidas que eles deveriam introduzir na empresa? Se a 
chave do sistema Lean era incorporar múltiplas 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 estruturalean formal? Qual seria a melhor abordagem para 
estabelecer a diferença entre impor melhores práticas e deixar espaço para a experimentação? 
 
 
 
 
 
Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
6
12
-P
1
1 
-1
5
- 
 
Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
6
12
-P
1
1 
-1
6
- 
 
 
Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
6
12
-P
1
1 
-1
- 
 
Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
6
12
-P
1
1 
-1
- 
 
Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
6
12
-P
1
1 
-1
- 
Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
6
12
-P
1
1 
-
- 
2
0
 
 
Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
6
12
-P
1
1 
-
- 
 
Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860
6
12
-P
1
1 
-
- 
 
Do
 N
ot
 C
op
y 
or
 P
os
t
This document is authorized for educator review use only by Oscar Javier Celis Ariza, Estacio de Sa University until March 2016. Copying or posting is an infringement of copyright. 
Permissions@hbsp.harvard.edu or 617.783.7860