Traduzido do Inglês para o Português - www.onlinedoctranslator.
com
Odisséia de Planejamento de Recursos Empresariais (ERP) da Nestlé
Por Ben Worthen | 15 de maio de 2002, 8h
(http://www.cio.com/article/2440821/enterprise-resource-planning/nestl--s-enterprise-resource-planning--erp--odyssey.html )
Em Junho de 2000, a Nestlé SA assinou um contrato muito divulgado
de 200 milhões de dólares com a SAP e investiu 80 milhões de dólares
adicionais em consultoria e manutenção para instalar um sistema
ERP na sua empresa global. A gigante suíça de bens de consumo
pretende utilizar o sistema SAP para ajudar a centralizar um
conglomerado que possui 200 empresas operacionais e subsidiárias
em 80 países.
Não é de surpreender que um movimento desta magnitude tenha
despertado ceticismo. Anne Alexandre, analista que cobre a Nestlé
para o HSBC Securities em Londres (a empresa é negociada apenas
na Europa), rebaixou a sua recomendação sobre as ações da Nestlé
um ano após o anúncio do projeto. Embora ela diga que o sistema
ERP provavelmente trará benefícios a longo prazo, ela está
preocupada com o que o projeto trará à empresa ao longo do
caminho. “Isso toca a cultura corporativa, que é descentralizada, e
tenta centralizá-la”, diz ela. "Isso é arriscado. É sempre um risco
quando você toca na cultura corporativa."
É um risco que Jeri Dunn, vice-presidente e CIO da Nestlé EUA, a
subsidiária norte-americana avaliada em 8,1 mil milhões de dólares,
conhece muito bem. Em 1997, a empresa sediada em Glendale, Califórnia,
embarcou num projecto SAP com o nome de código Best (excelência
empresarial através da tecnologia de sistemas). Quando chegar à linha de
chegada, a Best terá engolido seis anos e mais de US$ 200 milhões (a
mesma quantia que sua controladora global pretende gastar). Dunn
agora diz que vê a luz no fim do túnel. As últimas implementações terão
lugar no primeiro trimestre de 2003. Mas a implementação tem estado
repleta de becos sem saída e erros dispendiosos. É um conto de
advertência, cheio de lições não apenas para sua controladora suíça, mas
para qualquer empresa Fortune 1000 que pretenda implementar software
em toda a empresa.
“Peguei oito ou nove divisões autônomas e disse que
usaríamos processos, sistemas e estruturas
organizacionais comuns”, diz Dunn. "[A Nestlé SA está]
olhando para 80 países autônomos e dizendo a mesma
coisa. Eles estão apenas elevando a situação. Se eles
adotarem uma atitude de que não haverá resistência e
dor, eles serão desapontado."
O projecto SAP global da Nestlé, que está ligado a uma remodelação de
centro de dados de hardware e software de 500 milhões de dólares, será
integrado com o ERP da sua subsidiária americana, que será concluído em
breve. E Dunn está até emprestando 70 de seus funcionários para a
iniciativa global, bem como alguns de seus conhecimentos arduamente
conquistados. Mas embora o veredicto sobre o projecto global ainda não
tenha sido dado, a dor e a raiva dos funcionários, a reengenharia
dispendiosa e os longos períodos em que parecia que o projecto nunca
terminaria valeram a pena para a Nestlé EUA, diz Dunn. Até o momento,
afirma ela, o projeto Best economizou US$ 325 milhões para a empresa.
(Como a Nestlé está sediada fora dos Estados Unidos, não tem de divulgar
as suas informações financeiras à SEC.)
Independentemente do ROI exato do projeto, as lições aprendidas
são reais. A principal lição que Dunn diz ter aprendido com o projeto
é esta: nenhuma implementação importante de software é realmente
sobre software. É sobre gerenciamento de mudanças. "Se você
Se você não estivesse preocupado com o funcionamento do negócio,
provavelmente poderia [instalar o software ERP] em 18 a 24 meses”,
diz ela. Então, “provavelmente estaria na fila do desemprego em 19 a
25 meses”.
A Nestlé aprendeu da maneira mais difícil que uma implementação em toda a
empresa envolve muito mais do que simplesmente instalar software. “Quando
você muda para SAP, você muda a maneira como as pessoas trabalham”, diz
Dunn. “Você está desafiando seus princípios, suas crenças e a maneira como
eles têm feito as coisas por muitos e muitos anos”.
O problema: 29 marcas de baunilha
A baunilha pode ser o ingrediente menos excitante do mundo; a
palavra é até sinônimo de insípido. Mas esse não foi o caso da Nestlé
nos EUA, onde a baunilha representava uma infinidade de
ineficiências e oportunidades perdidas.
Antes de 1991, a Nestlé era simplesmente um conjunto de marcas
que operavam de forma independente, como a Stouffer's e a
Carnation, propriedade da empresa-mãe com sede na Suíça. Em
1991, as marcas foram unificadas e reorganizadas na Nestlé USA.
Mesmo assim, a nova empresa continuou a funcionar mais como
uma holding do que como uma entidade única. As divisões ainda
tinham sedes geograficamente dispersas e eram livres para tomar as
suas próprias decisões de negócios, embora agora reportassem aos
executivos corporativos da Nestlé EUA em Glendale, em vez de em
Vevey, na Suíça. A nova empresa tentava introduzir economias de
escala e práticas comuns, mas anos de operação autónoma
revelaram-se um obstáculo quase intransponível.
Em 1997, uma equipa que examinou os vários sistemas da empresa
descobriu, entre muitas outras redundâncias preocupantes, que as
marcas da Nestlé nos EUA pagavam 29 preços diferentes pela
baunilha ao mesmo fornecedor. “Cada fábrica compraria baunilha do
vendedor, e o vendedor receberia tudo o que achasse que poderia
conseguir”, diz Dunn. “E a razão pela qual não pudemos nem verificar
é porque cada divisão e cada fábrica tinham o nome vanilla do que
quisessem. Então você poderia chamá-lo de 1234, e poderia ter uma
especificação completa por trás dele, e eu poderia chamá-lo de 7778.
Não tínhamos como comparar."
Embora as marcas americanas estivessem dispostas a continuar os
seus negócios como empresas autónomas, danem-se as dores de
cabeça, a empresa-mãe suíça sabia que problemas semelhantes
continuariam. Em 1991, mesmo ano em que a Nestlé EUA foi criada,
Dunn, então diretor associado de sistemas de aplicação dos Hotéis
Stouffer's, uma das muitas marcas da Nestlé, foi à Suíça para ajudar a
implementar uma metodologia comum para projetos da Nestlé em
todo o mundo. Em 1995, foi promovida a vice-presidente assistente
de tecnologia e padrões da Nestlé SA, onde elaborou padrões
tecnológicos a serem seguidos por todas as empresas Nestlé. Dunn
imaginou que os sistemas comuns em todo o império Nestlé criariam
poupanças através do poder de compra do grupo e facilitariam a
partilha de dados entre subsidiárias.
No entanto, quando Dunn regressou aos Estados Unidos para assumir o cargo
mais prático de CIO na Nestlé EUA em 1997, descobriu que poucos dos seus
recomendações foram postas em prática. “Minha equipe poderia
nomear os padrões, mas a implementação ficou a critério das
empresas”, disse ela durante uma entrevista recente em seu
escritório escassamente decorado no quarto andar em Glendale.
Dunn faz pausas para fumar em todas as oportunidades possíveis e
não tem medo de vestir saia e blusa com estampa de leopardo. Aos
47 anos, ela é uma sobrevivente que é aberta sobre seus erros e é
respeitada em toda a empresa. Sua equipe fala dela em tom quase
reverencial.
A Proposta: Uma Nestlé, Sob SAP
A chegada de Dunn na primavera de 1997 ocorreu alguns meses depois que o
presidente e CEO da Nestlé EUA, Joe Weller, cunhou o termo One Nestlé para
refletir seu objetivo de transformar as marcas separadas em uma empresa
altamente integrada. Em junho, Dunn juntou-se a executivos responsáveis
pelas finanças, cadeia de abastecimento, distribuição e compras para formar
uma equipa de stakeholders chave e estudar o que havia de certo e de errado
na empresa. Quando chegou a altura, os principais intervenientes tiveram
inicialmente um pouco mais de duas horas para apresentar as suas conclusões
a Weller e a outros altos funcionários da Nestlé.
A equipe recusou o limite de tempo. “Eu disse a eles que ou
me expulsariam nos primeiros 15 minutos ou cancelariam o
resto do dia, e teríamos realmente uma ótima discussão”,
disse Dick Ramage, vice-presidente de cadeia de
fornecimento da Nestlé EUA e membro do time. "Demoraram
uma hora, mas cancelaram o resto do dia."
“Acho que eles não sabiam o quão feio era”, diz Dunn, referindo-se à
situação da empresa. "Tínhamos nove livros contábeis diferentes e 28
pontos de entrada de clientes. Tínhamos vários sistemas de compras.
Não tínhamos ideia de quanto volume estávamos fazendo com um
determinado fornecedor porque cada fábrica definia seus próprios
fornecedores e comprava por conta própria."
Logo a equipe de partes interessadas apresentou a Weller um plano
para grandes mudanças que eles achavam que poderiam ser feitas
dentro de três a cinco anos. Embora a base da recomendação fosse
um pacote SAP, Dunn diz: "Deixamos bem claro que isso seria uma
reorganização de processos de negócios e que não seria possível
fazê-lo sem mudar a maneira como você fazia negócios. Iria ser
doloroso envolvido, seria um processo lento e não era um projeto de
software."
Apesar desse aviso, mais tarde tornar-se-ia evidente que nem Weller
nem as principais partes interessadas compreenderam realmente até
que ponto o projecto Best alteraria os processos empresariais da
Nestlé ou a quantidade de sofrimento que causaria. “Eles ainda
pensavam que se tratava apenas de software”, diz Dunn.
Em outubro de 1997, uma equipe de 50 executivos de alto nível e 10
profissionais seniores de TI foi reunida para implementar o projeto SAP. O
objectivo da equipa era apresentar um conjunto de melhores práticas que
se tornariam procedimentos de trabalho comuns para todas as divisões
da Nestlé. Todas as funções divisionais de produção, compras,
contabilidade e vendas teriam de abandonar as suas antigas abordagens
e aceitar a nova abordagem pan-Nestlé.
Do lado técnico, uma equipe menor passou 18 meses examinando
todos os dados dos itens em cada divisão, a fim de implementar uma
estrutura comum em toda a empresa. De agora em diante, vanilla
seria o código 1234 em todas as divisões. O SAP
O sistema seria personalizado em torno dos processos de negócios
uniformes. No caso da cadeia de abastecimento, a equipe decidiu não
usar o SAP porque o módulo de cadeia de abastecimento da empresa ERP,
Advanced Planner and Optimizer ou APO, era totalmente novo e,
portanto, arriscado. Em vez disso, a Nestlé recorreu à Manugistics, na
época parceira da SAP. O módulo de cadeia de suprimentos da
Manugistics seguiu todos os padrões SAP e pode ser facilmente integrado.
Em Março de 1998, os principais intervenientes tinham um plano em
vigor. A Nestlé implementaria cinco módulos SAP de compras,
finanças, vendas e distribuição, contas a pagar e contas a receber e o
módulo de cadeia de suprimentos da Manugistics. Cada um seria
implantado em todas as divisões da Nestlé. Por exemplo, o grupo de
compras de confeitos seguiria as mesmas melhores práticas e dados
que o grupo de compras de bebidas.
O trabalho de desenvolvimento começou em julho de 1998. O prazo para
quatro dos módulos era o ano 2000. Os novos sistemas teriam que
funcionar como correções de código e estar em vigor para a mudança
milenar. A Nestlé EUA cumpriu o prazo. Mas a sua pressa criou quase
tantos problemas como resolveu.
O Processo: A Crise da Nestlé
Mesmo antes de três dos módulos SAP e Manugistics serem
lançados no final de 1999, já havia rebelião nas fileiras. Grande
parte da resistência dos funcionários pode ser atribuída a um
erro que remonta ao início do projeto: nenhum dos grupos que
seriam diretamente afetados pelos novos processos e sistemas
estava representado na equipe das principais partes
interessadas. Conseqüentemente, Dunn diz: "Sempre
surpreendíamos [os chefes de vendas e das divisões] porque
trazíamos algo ao comitê de direção executiva que eles não
tinham conhecimento". Dunn chama isso de erro quase fatal.
No início de 2000, a implementação desabou no caos. Os
trabalhadores não só não entendiam como usar o novo sistema,
como nem sequer entendiam os novos processos. E os executivos
divisionais, que estavam tão confusos quanto seus funcionários e
ainda mais irritados, não se esforçaram para ajudar. Dunn diz que
suas ligações para o suporte técnico chegaram a 300 por dia. “Fomos
realmente ingénuos no sentido de que estas mudanças tinham de ser
geridas”, admite agora.
Ninguém queria aprender a nova maneira de fazer as coisas. O moral
caiu. A rotatividade entre os funcionários que prevêem a procura de
produtos Nestlé atingiu 77%; os planejadores simplesmente eram
relutantes ou incapazes de abandonar suas planilhas familiares pelos
modelos complexos da Manugística.
Um problema técnico logo surgiu também. Na pressa de cumprir
o prazo do Y2K, a equipe do projeto Best ignorou os pontos de
integração entre os módulos. Todos os departamentos de
compras usavam agora nomes e sistemas comuns e seguiam um
processo comum, mas o seu sistema não estava integrado com
os grupos financeiro, de planeamento ou de vendas. Um
vendedor, por exemplo, pode ter dado a um cliente valioso uma
taxa de desconto e inserido-a no novo sistema, mas o
departamento de contas a receber não saberia disso. Assim,
quando o cliente pagasse a taxa com desconto, pareceria ao
operador de contas a receber que a fatura foi paga apenas
parcialmente. Na pressa de unificar as marcas separadas da
empresa, a equipe do projeto basicamente substituiu os silos
divisionais por silos de processo.
Em junho de 2000, o projeto foi reorganizado. O líder do projeto,
Mark Richenderfer, foi promovido para um novo cargo na Suíça,
trabalhando na implementação global de SAP da Nestlé e em
iniciativas de melhoria de processos de negócios. Dunn recebeu total
responsabilidade pelo projeto. Era hora do auto-exame. Em Outubro
de 2000, Dunn reuniu 19 principais intervenientes e executivos de
negócios da Nestlé EUA para um local externo de três dias no
DoubleTree Hotel em Pasadena, Califórnia, a cerca de 16 quilómetros
da sede da Nestlé.
José Iglesias, diretor de sistemas de informação, diz que o retiro
começou como uma sessão de queixas. As limitações de tempo
exigidas pelo Y2K colocaram demasiada pressão sobre as pessoas
responsáveis pela execução das mudanças. A equipe do projeto
havia perdido a visão geral de como os vários componentes
funcionariam juntos. E ainda havia trabalho a ser feito. Os módulos
existentes tiveram que ser integrados e a equipe ainda precisava
implementar mais dois módulos SAP de vendas e distribuição no lado
doméstico e contas a receber, bem como um novo módulo para a
cadeia de suprimentos. Desde que Dunn rejeitou o módulo SAP
Supply Chain, dois anos antes, ele melhorou e foi nomeado padrão
global da Nestlé pelo antigo grupo de padrões de Dunn na Suíça.
Então ela decidiu substituir todas as partes do sistema Manugistics
pelo APO, exceto algumas partes. Dunn estima que a troca de última
hora foi responsável por 5% do custo de US$ 210 milhões da Best.
Os membros do grupo externo decidiram que, para concluir o projeto,
precisariam começar do início, começando com os requisitos de negócios
e chegando a uma data final, em vez de tentar encaixar o projeto em um
molde moldado por uma data final predeterminada. Eles também
concluíram que precisavam fazer um trabalho melhor para garantir que
contassem com o apoio dos principais chefes de divisão e que todos os
funcionários soubessem exatamente quais mudanças estavam ocorrendo,
quando, por que e como.
O jogo final: mais triste, mas mais sábio
Em Abril de 2001, o projecto final estava concluído, dando à equipa
do projecto um roteiro altamente detalhado a seguir. Um mês depois,
Tom James assumiu o cargo de diretor de mudança de processo do
projeto Best, tendo a responsabilidade exclusiva de atuar como elo
de ligação entre as divisões e a equipe do projeto. James diz que ficou
chocado com o relacionamento ainda fraco entre as divisões e a
equipe do projeto. Ele e Dunn começaram a se reunir com mais
chefes de divisão. Também começaram a realizar pesquisas regulares
sobre como os funcionários afetados pelos novos sistemas estavam
lidando com as mudanças.
Eles não tiveram medo de reagir ao que encontraram. Dunn diz que a
Nestlé atrasou recentemente o lançamento de um novo pacote de co-
fabricação por seis meses com base no feedback que indicava que os
potenciais utilizadores não estavam preparados para fazer as
alterações de processo envolvidas.
Os projetos de ERP são notórios por levarem muito tempo e muito
dinheiro. Jennifer Chew, analista da Forrester Research, com sede em
Cambridge, Massachusetts, descobriu que 54% dos entrevistados em
uma pesquisa recente disseram que seu projeto durou mais de dois
anos (os outros 46% concretizaram o seu em menos de dois anos). O
projecto da Nestlé EUA “parece positivo” tanto em termos de tempo
como de dinheiro, diz Chew. Ainda assim, o sucesso é, em última
análise, medido pelo que o projeto realiza. Chew ressalta que a Kmart
teve que amortizar US$ 130 milhões para um projeto de ERP que
nunca foi concluído.
A própria Dunn não se envergonha da duração do projeto ou dos
numerosos becos sem saída. Ela insiste que devagar e sempre
vence a corrida. A Nestlé EUA já alcançou um ROI significativo, diz
ela, com a maior parte das poupanças resultantes de uma melhor
previsão da procura. "O processo antigo envolvia um vendedor
que dava um número ao planejador de demanda, que dizia:
'Esses caras não sabem do que diabos estão falando; vou dar
esse número a eles'", diz Dunn. “O planejador de demanda
entrega [esse número] à fábrica, e a fábrica diz que o planejador
de demanda não sabe do que está falando.” Então a fábrica muda
o número novamente.
Com a implementação do SAP, bases de dados e processos de negócio comuns
levam a previsões de procura mais fiáveis para os vários produtos da Nestlé.
Além disso, como toda a Nestlé nos EUA utiliza os mesmos dados, diz Ramage,
a Nestlé pode fazer previsões até ao nível do centro de distribuição. Isso
permite à empresa reduzir o estoque e as despesas de redistribuição que
ocorrem quando uma quantidade excessiva de um produto é enviada para um
local e uma quantidade insuficiente para outro. Ramage diz que as melhorias
na cadeia de abastecimento foram responsáveis por uma grande parte dos
325 milhões de dólares que a Nestlé afirma ter poupado à SAP.
Se Dunn fizesse tudo de novo, ela se concentraria primeiro na
mudança dos processos de negócios e na obtenção de adesão
universal, e só então, e somente então, na instalação do software. “Se
você tentar fazer isso primeiro com um sistema, terá uma instalação,
não uma implementação”, diz ela. “E há uma grande diferença entre
instalar software e implementar uma solução.”