Embed Size (px)
DESCRIPTION
Este estudo procura mostrar que a adoção dessa nova tecnologia através de projetos de implantação de sistema de ERP não só mudam processos administrativos como também produtos, serviços e estruturas organizacionais e que a sua implantação se constitui em um grande projeto que envolve um número considerável de recursos e tempo das organizações.
Citation preview
FUNDAÇÃO GETULIO VARGAS ESCOLA BRASILEIRA DE ADMINISTRAÇÃO PÚBLICA CENTRO DE FORMAÇÃO ACADÊMICA E PESQUISA CURSO DE MESTRADO EXECUTIVO
ESTUDOS DE CASO: IMPLANTAÇÃO DE SISTEMAS ERP - UMA ANÁLISE CRÍTICA À
LUZ DA METODOLOGIA DE PROJECT MANAGEMENT
DISSERTAÇÃO APRESENTADA À ESCOLA BRASILEIRA DE ADMINISTRAÇÃO
PÚBLICA E DE EMPRESAS PARA OBTENÇÃO 00 GRAU DE MESTRE
MARIA GABRIELA SOBRAL GIL Rio de Janeiro 2002
FUNDAÇÃO GETULIO VARGAS
ESCOLA BRASILEIRA DE ADMINISTRAÇÃO PÚBLICA
CENTRO DE FORMAÇÃO ACADÊMICA E PESQUISA
CURSO DE MESTRADO EXECUTIVO
TÍTULO
ESTUDOS DE CASO: IMPLANTAÇÃO DE SISTEMAS ERP - UMA ANÁLISE
CRÍTICA À LUZ DA METODOLOGIA DE PROJECT MANAGEMENT
DISSERTAÇÃO DE MESTRADO APRESENTADA POR:
MARIA GABRIELA SOBRAL GIL
E
APROVADO EM 26 / 11 / 2002
PE A COMISSÃO EXAMINADORA
DOUTOR EM PESQUISA OPERACION
DoUTOR EM PLANEJAMENTO
DOUTOR EM ENGENHARIA DA PRODUÇÃO
IV
Ao meu marido, família e amigos que de alguma forma contribuíram para a conclusão deste
estudo.
v
AGRADECIMENTOS
Ao professor Alexandre Linhares pela sua coragem ao ter aceito o desafio de, à distancia, me
ajudar a finalizar este trabalho e por todo o incentivo e dicas que me deu.
Ao José Paulo e à equipe da secretaria do mestrado pela ajuda que sempre me deram, sem ela,
eu não estaria escrevendo estas palavras hoje. Muito Obrigada pela ajuda.
Aos membros da banca examinadora, por participarem de um momento tão especial como
este para mim.
Ao meu marido Marcelo e à minha família querida, pelas horas que deixei de lhes dar a
atenção merecida para poder estudar e preparar este trabalho.
Ao meu amigo Ulysses pelas horas dedicadas às discussões dos fundamentos de Project
Management.
A todos aqueles não mencionados anteriormente que, de alguma maneIra, direta ou
indiretamente, contribuíram para a realização desta dissertação.
VI
"Descobri como é bom chegar
quando se tem paciência.
E para se chegar a qualquer lugar,
descobri que não necessário dominar a força e sim a razão.
Descobri que acima de tudo é necessário
querer"
AmyrKlink
vii
suMÁRIo Página
LISTA DE FIGURAS Xl
LISTA DE TABELAS Xll
LISTA DE TERMOS E SUAS DEFINIÇÕES Xlll
RESUMO XVI
ABSTRACT XVll
1. INTRODUÇÃO 1
1.1. Contextualização do problema 1
1.2. Relevância do estudo 3
1.3. Delimitação do estudo 3
1.4. Objetivo 5
1. 5. Organização do Estudo 5
2. REFERENCIAL TEÓRICO 8
2.1. A metodologia de Project Management e os sistemas de ERP 9
2.1.1. A metodologia de Project Management 9
2.1.1.1. O que é Projeto 9
2.1.1.2. O gerenciamento de projetos e suas áreas de conhecimento 12
2.1.1.3. O processo de Project Management 19
2.1.1.4. Principais grupos envolvidos no projeto 26
2.1.2. Sistema de ERP 27
2.1.3. Um projeto de implantação de um sistema de ERP 32
2.2. Formação de Equipes e a Liderança 35
2.2.1. A formação de equipes de projeto 35
2.2.1.1. A estrutura da equipe de projeto 38
2.2.1.2. Criando uma identidade para a equipe de projeto 41
2.2.1.3. Processos motivacionais 42
V111
Página
2.2.1.4. Criando uma equipe de projeto de alta performance - uma
equipe de sucesso
2.2.1.5. A tomada de decisão na equipe
2.2.1.6. Conflitos na equipe de projeto
2.2.1.7. A desmobilização da equipe
2.2.2. Liderança
2.2.2.1. Principais características da Liderança
2.2.2.2. Liderança e Poder
2.2.2.3. Diferença entre gerentes de Projetos e Líderes
2.2.2.4. A liderança como diferencial na Gestão de Projetos
2.2.2.5. Algumas competências para um Líder de Projeto
2.3. A Mudança, o Change Management e algumas considerações sobre
Cultura Organizacional
2.3.1. Identificando os fatores motivadores da Mudança
2.3.1.1.Como a mudança na estrutura organizacional vem sendo tratada
43
46
47
49
51
51
54
55
57
58
63
63
pelos estudiosos 64
2.3.2. O que é Change Management 67
2.3.2.1. Fator Mudança 68
2.3.2.2. Um projeto de mudança e o processo de Change Management 70
2.3.2.3. Identificação dos Stakeholders 71
2.3.2.4. A comunicação 73
2.3.2.5. A formação de equipe e o Change Management 75
2.3.2.6. Outras considerações sobre liderança e a formação da equipe
~~~ ~
2.3.2.7. Problemas maIS comuns encontrados em um projeto de
mudança
2.3.3. Considerações sobre a Cultura Organizacional
2.3.3.1. A Cultura de uma Organização
2.3.3.2. A Cultura e os Projetos
79
83
83
84
2.3.3.3. A Cultura das Equipes de Projeto
2.3.3.4. Alguns impactos negativos da Cultura Organizacional em
projetos
3. METODOLOGIA
3.1. Introdução
3.2. Universo e Amostra
3.3. Seleção dos Sujeitos
3.4. Coleta de Dados
3.5. Tratamento dos Dados
4. DESCRIÇÃO DOS CASOS
4.1. Empresa A
4.1.1. Dados Gerais
4.1.2. Histórico da Implantação
4.1.3. Os fatores da Mudança, a seleção do Produto e as mudanças que a
Página
86
87
89
89
90
91
91
91
92
93
93
93
implantação do sistema exigiu da empresa 95
4.1.4. A Influência da Cultura da Empresa no Projeto, na Gerência e na
Equipe de Projeto 98
4.1.5. A metodologia de Formação da Equipe de Trabalho 100
4.1.6. Os Gerentes de Projeto e a Liderança 105
4.1.7. O processo de Change Management 111
4.1.8. A Finalização do Projeto 113
4.1.9. Os Resultados do Projeto 114
4.2. Empresa B 117
4.2.1. Dados Gerais 118
4.2.2. Histórico da Implantação 118
4.2.3. Os fatores da Mudança, a seleção do Produto e as mudanças que a
IX
implantação do sistema exigiu da empresa
4.2.4. A Influência da Cultura da Empresa no Projeto, na Gerência e na
Equipe de Projeto
4.2.5. A metodologia de Formação da Equipe de Trabalho
4.2.6. Os Gerentes de Projeto e a Liderança
4.2.7. O processo de Change Management
4.2.8. A Finalização do Projeto
4.2.9. Os Resultados do Projeto
5. ANÁLISE DAS INFORMAÇÕES COLETADAS
5.1. Histórico da implantação nas duas empresas
5.2. Os fatores da mudança, a seleção do produto e as mudanças que essa
Página
120
121
122
124
128
130
131
133
133
implantação exigiu da empresa 134
5.3. Influência da cultura das empresas no projeto, na gerência e na equipe de
projeto 135
5.4. Aspectos da metodologia utilizada por cada uma das empresas na
formação das equipes de trabalho 137
5.5. O perfil dos gerentes de projeto e da alta administração, os conflitos e os
aspectos de liderança no projeto 138
5.6. O processo de Change Management - a comunicação, a integração das
equipes e o treinamento 140
5.7. Os resultados obtidos pelo projeto - o processo de finalização e os
resultados obtidos em termos de escopo, prazos e custo. 140
6. CONCLUSÕES E RECOMENDAÇÕES 142
REFERÊNCIAS BIBLIOGRÁFICAS 155
ANEXO - QUESTIONÁRIOS PARA ENTREVISTAS 158
x
xi
LISTA DE FIGURAS
Página
Figura I - Restrição Tripla 10
Figura 11 -Áreas de Atuação do Project Management 14
Figura III - Ciclo de Vida de um Projeto 20
Figura IV - Inter-relacionamento entre os grupos de processos no desenvolvimento
~~~~ M
Figura V - Sobreposição de grupos de processos dentro das fases do projeto 25
Figura VI - Processo de gerenciamento e suas funções 25
Figura VII - Visão Geral do ERP 29
Figura VIII - Estrutura Proposta para um Projeto de ERP 33
Figura IX - Processo Decisório 47
Figura X - Detalhamento da estrutura de problemas mais comuns do encerramento
de um projeto 50
Figura XI - Caráter Organizacional 66
Figura XII - Mapeamento do apoio dos Stakeholders com referência à mudança
pretendida 72
Figura XIII - Estrutura de equipe peso pesado 78
Figura XIV - Equipe do Projeto de ERP da empresa A 107
Figura XV - Equipe do Projeto de ERP da empresa B 125
LISTA DE TABELAS
Tabela A - Características de Equipes de Projeto de Sucesso
Tabela B - Principais diferenças entre Gerentes e Líderes
Tabela C - Análise comparativa entre Bons e Maus Líderes
Tabela D - Principais conclusões:
Tabela E - Principais Recomendações
Página
44
56
60
142
153
Xli
xiii
LISTA DE TERMOS E SUAS DEFINIÇÕES
Best Practices - Como são conhecidas as melhores práticas de negócio.
Change Management - Técnicas que permitem o gerenciamento de projetos onde o processo
de mudança e transição ocorre, objetivando reduzir resistências e comprometer os recursos
envolvidos com o sucesso do projeto.
CPD - Centro de Processamento de Dados
Empowerment - processo no qual se criam condições e habilitam-se as pessoas de todos os
níveis da empresa para assumirem responsabilidades.
ERP - São sistemas integrados de software que integram todos os processos, regras e
aplicações para automatizar toda a cadeia de suprimentos; são baseados em tecnologia que
viabiliza a atuação e controle por processos em contraponto a atuação e controles
departamentais; fornecem uma arquitetura de informações que une toda a empresa, inclusive
suas diversas plantas e países. Por integrar as informações de todas as plantas, negócios e
departamentos da empresa através de uma base contábil única. Entre outras coisas, o ERP
viabiliza análises em tempo real de diversas questões fundamentais para a gestão de uma
empresa.
Fast Tracking - Com se chama o processo em que produtos (Deliverables) de uma fase de
projeto são iniciados quando outros ainda não foram concluídos. Isto ocorre quando os riscos
envolvidos no projeto são aceitáveis
Gap 's - Como são chamadas as diferenças existentes entre o "modelo" sistêmico desejado e o
disponível. Para minimizar tais diferenças, é necessário que o projeto recorrer a programação
adicional, conhecidas como customizações.
Go Live - É como se chama o momento em que o sistema, após parametrizado e testado, é
posto em funcionamento.
XIV
IT OU IT - Tecnologia de Informação
Kick Of! - Como são chamados os eventos onde se dá oficialmente por iniciado o projeto,
onde são apresentados os membros da equipe e são apresentados os objetivos do projeto.
Learning Meetings - É como são chamados os encontros de aprendizado realizados entre
todos os membros da equipe ao término do projeto (reuniões de encerramento), cujo objetivo
é avaliar permanentemente o aprendizado obtido com o mesmo.
Overheads - excesso de mão de obra.
Projetos - Um projeto pode ser entendido como uma combinação de recursos da organização
que, uma vez reunidos, permitirão a criação de algo inexistente previamente. Ele permitirá à
empresa, alcançar seus objetivos operacionais (no curto prazo), estratégicos (no longo prazo) e
organizacionais. Possuem ciclos de vida distintos e começam com uma idéia, definição do
desenho, execução e implantação.
Projetos de mudança - Projeto de mudança constitui-se em justificativas persuasivas em
favor de modificações que justifiquem seu esforço. Um projeto de mudança deverá ser claro,
conciso, articulado, lógico, bem documentado e motivador. Deve trazer um senso de urgência.
Deve incentivar as pessoal envolvidas a agir.
Project Management - Project Management são um conjunto de técnicas e processos que
permitem gerenciar Projetos. Segundo definição do Instituto de Project Management é "a arte
de dirigir e coordenar recursos humanos e financeiros".
PMI - The Project Management Institute
PMBOK - Project Management Book of Knowledge - referência bibliográfica básica para os
estudiosos de Project Management, editada e atualizada periodicamente pelo PMI,
compilando informações e dados resultados de pesquisa e pratica vivenciadas em projetos em
geral que se utilizam das técnicas de Project Management.
xv
Stakeholders - Stakeholders são indivíduos ou grupos que, em algum momento durante o
ciclo de mudança de um projeto, afetarão ou serão afetados pelo processo.
Sponsor - É como é chamado o patrocinador do projeto.
Standard - tenno em inglês para a palavra padrão.
Supply Chain - tenno em inglês para o conceito de cadeia logística integrada
Team Building - Construção de um espírito de Equipe
Trade Of! - tenno em inglês para a palavra troca em português.
xvi
RESUMO
Este documento constitui-se em uma dissertação de mestrado, requisito parcial para a
obtenção do grau de Mestre em Gestão Empresaria e Pública.
Este estudo procura mostrar que a adoção dessa nova tecnologia através de projetos de
implantação de sistema de ERP não só mudam processos administrativos como também
produtos, serviços e estruturas organizacionais e que a sua implantação se constitui em um
grande projeto que envolve um número considerável de recursos e tempo das organizações.
Este estudo procurar mostrar também que os impactos que tais projetos trazem, são mais
fortemente sentidos ou não pela organização de acordo com uma série de fatores, entre eles, a
resistência à mudança e o quanto a organização está preparada para enfrentar essas mudanças,
o medo da perda do emprego pela adoção de uma nova tecnologia, problemas com a falta de
comunicação das mudanças, questões relacionadas à cultura organizacional vigente, a falta de
envolvimento da alta administração, entre outras. Para gerenciar todas essas variáveis, as
organizações modernas adotam técnicas para garantir o sucesso da implantação dessas novas
tecnologias.
o estudo aqui proposto tem como objetivo determinar até que ponto a utilização de
metodologias e de técnicas de Project Management é o suficiente para que esses projetos
alcancem o sucesso esperado pelas organizações. A quantidade de variáveis que influenciam o
resultado de um projeto são muitas e cada uma delas possui um papel importante que deve ser
avaliado.
As conclusões desta pesquisa demonstram que o sucesso de um projeto nem sempre se resume
a atingir os objetivos inicialmente propostos, relativos ao cumprimento do prazo, escopo e
custo de um projeto, conforme define a metodologia de Project Management. Outros aspectos
considerados por essa metodologia, se melhor ou pior aplicados, também contribuem para o
sucesso ou fracasso de um projeto de implantação de um sistema de ERP sendo o seu fracasso
traduzido ou não, no cumprimento do prazo, do escopo inicialmente previsto ou no custo
inicialmente calculado. Outros aspectos que não apenas a aplicação correta da metodologia de
Project Management contribuem para os resultados alcançados pelo projeto.
XVll
ABSTRACT
This document constitutes a thesis for a partial fulfillment for getting a master's degree in
Public and Business Management.
Our subject is an analysis of two case studies about ERP's system implementation and the
techniques of Project Management used as a methodology for their implementation. The study
states that the use of the Project Management methodology by itself is not enough to
guarantee the success of an ERP's system implementation. Other issues, such as the way the
organization deals with change, the Change Management methodology presented on projects,
the project team management, as well as the building of a project team is dealt within a
project affects the success ofan ERP's system implementation. AIso, some cultural features of
the organization influence the results obtained as well as leadership of its project managers.
The main results of this study are the theoretical building of the thematic support conceming
ERP' s system implementation. The use of interviews aiming at verifying the way the issues
treated in this study are dealt on ERP' s system implementation projects and how those aspects
influence positively or negatively on the success of those projects.
The conc1usions from this research show that not only the use of the Project Management
methodology is enough to guarantee the success of such projects. The success is not always
reached by meeting the initial expectations of cost, time and budget as the Project
Management methodology states primarily. Other features treated in this research also
contribute to its failure or success such as the project team building, leadership, the Change
Management techniques as well as cultural elements.
1 INTRODUÇÃO
1.1 Contextualização do problema
As organizações modernas se vêem envolvidas num ambiente dinâmico e de incertezas, onde
mudanças ocorrem diariamente em uma velocidade não antes imaginada. "As sociedades em
geral (os indivíduos, as famílias) e não apenas as organizações, têm sofrido os impactos do
vendaval de mudanças que está sendo chamado de idade da informação, terceira onda,
sociedade pós-industrial, era da comunicação, sociedade de serviços ou ainda sociedade do
conhecimento" (Freitas, 1999:30). Estar preparado para essas mudanças é o desejo da maioria
dessas organizações.
A evolução da tecnologia de informação tem contribuído significativamente, não só como um
estímulo, mas também como uma ferramenta que possibilita essa mudança, permitindo às
empresas se prepararem para um futuro de incertezas. Temos acompanhado o processo vivido
mundialmente por organizações que têm procurado, como solução para as pressões
provocadas pelas mudanças de mercado e pela concorrência, os sistema integrados de gestão
ou seja, sistemas de Enterprise Resource Planning (ERP) devido à necessidade que elas tem
de serem mais ágeis não só no acompanhamento do seu negócio, como também no
lançamento de novos produtos, na avaliação de alternativas de negócio, na incorporação de
outras empresas adquiridas e na troca de informações com seus clientes e fornecedores. Os
sistemas de ERP são uma resposta da tecnologia de informação a esses desafios. A
substituição dos antigos pacotes de software não integrados por modernos sistemas de
informação e gestão integrados, cada vez mais ocupará espaço nas estratégias das
organizações modernas. Essas substituições, na maioria das vezes, não se restringem apenas a
mudanças de tecnologia. Com elas, as organizações são levadas a mudar processos, pessoas,
estruturas e culturas. Como gerenciar simultaneamente todos esses aspectos?
A metodologia de Project Management l tem sido uma grande e importante ferramenta que
veio possibilitar e ajudar as organizações no gerenciamento dessas mudanças. O conceito de
2
Project Management, de acordo com Cleland (1999), "surgiu na década de 60. Inicialmente
presente na construção civil, foi em seguida incorporado a projetos em outras áreas como, por
exemplo, na construção de armamentos militares,,2.
Inicialmente "reconhecido como uma filosofia, um processo de gerenciamento de atividades
em organizações caracterizadas por possuírem distintos ciclos de vida e que, além disso,
possuíssem um sistema de gerenciamento que se utilizasse de uma complexa matriz
organizacional,,3. A partir de 1957, outras técnicas específicas de planejamento, controle e
seqüênciamento de atividades surgiram, entre elas, destacamos o PER~, CPM5, etc. Sistemas
de informação e de controle de custos foram desenvolvidos para auxiliar no controle desses
projetos e até mesmo sistemas computacionais mais complexos passaram a ser utilizados
como ferramentas de gestão de projetos, como por exemplo, o MS Project da Microsoft.
o gerenciamento de projetos passou a ter também um papel estratégico no gerenciamento de
longo prazo e, em conjunto com outros elementos tais como estratégias funcionais, políticas,
procedimentos e planos de ação, permite que seja um elemento extremamente útil no
gerenciamento estratégico da empresa.
Atualmente, a metodologia de Project Management serve de referencial teórico para as
metodologias desenvolvidas por empresas de consultoria, especializadas na implantação de
sistemas de ERP.
1 Segundo 1. LeRoy Ward, em seu livro Project Management Terms - a working glossary, o Project Management é definido como a aplicação de conhecimentos, habilidades, ferramentas e técnicas nas atividades de um projeto de forma a alcançar ou superar as necessidades dos Stakeholderss e as expectativas previstas para um projeto.
2 CLELAND , David I. Project Management. Strategic Design and Implementation. 3M• Edition. Singapore:
McGraw-Hill,1999. 3 Idem. 4 Segundo 1. LeRoy Ward, em seu livro Project Management Terms - a working glossary, PERT significa
Program Evaluation and Review Technique. Técnica orientada a eventos, em técnicas de analise de uma rede de eventos baseada em probabilidades, usadas para estimar a duração de um projeto quando existe um elevado grau de incerteza em relação à duração das atividades de um indivíduo. PERT aplica o método do caminho crítico para mensurar uma estimativa de duração das atividades.
5 Segundo J. LeRoy Ward, em seu livro Project Management Terms - a working glossary, CPM significa Criticai Path Method sendo uma técnica utilizada para prever a duração de um projeto através da análise de uma seqüência de atividades que possuem pouca flexibilidade de tempo para serem concluídas.
3
1.2 Relevância do estudo
o presente estudo justifica-se a partir das seguintes constatações:
As organizações, ao optarem pela implantação de um sistema de ERP, acreditam que pelo
simples fato de selecionarem o melhor sistema disponível no mercado bem como uma
consultoria experiente que lhe dê suporte metodológico para a implantação desse sistema de
ERP, embasado em metodologia de Project Management, possuem as condições suficientes
para garantir o sucesso do projeto.
Entretanto, essas organizações se esquecem de atentar para outros fatores como, por exemplo,
se a organização está preparada para a mudança, se a metodologia de Project Management
está sendo bem empregada, se a consultoria está adotando as técnicas de Change Management
adequadas, entre outros. Fatores como esses, poderão contribuir para a obtenção de melhores
ou piores resultados quando nos referimos a um projeto de implantação de um sistema de
ERP.
Ao estudar as variáveis implícitas no Project Management, acreditamos estar contribuindo
para o aprendizado dessa técnica bem como para a melhoria dos processos de implantação de
projetos que se utilizam de alguma forma ou em algum grau, da metodologia de Project
Management.
1.3 Delimitação do estudo
As técnicas de Project Management incorporam um série de fases relacionadas ao seu
processo, organização e estrutura. O presente trabalho não pretende se aprofundar no
detalhamento de todas as fases do Project Management. As principais fases serão
apresentadas apenas para elucidar o assunto àqueles que não possuem domínio do tema.
4
Nossa abordagem irá procurar atentar para questões que tem despertado grande interesse de
estudo como: Gerenciamento da Mudança, Formação de Equipes, Liderança, Change
Management, bem como aspectos relacionados a Cultura Organizacional entre outros.
Nosso estudo irá se limitar a projetos de implantação de software ERP, uma vez que este tipo
de projeto implica, na sua maioria, em mudanças no desenho organizacional e no desenho de
processos das organizações o que por si só pode provocar profundas mudanças em uma
organização. Procuremos focar igualmente, que estratégias estão sendo adotadas pelas
organizações para suavizar o processo natural de mudança que se estabelece no momento em
que a empresa implanta um sistema de ERP.
Da mesma forma, a implantação de sistemas ERP, adotada pelas organizações como um
diferencial competitivo, envolve a alteração de seus processos, políticas internas e práticas de
gestão. Ela requer um tratamento específico dentro do contexto de transformação
organizacional uma vez que alcançar o sucesso na implantação desses sistemas, lhe confere
um diferencial competitivo, uma medida de sucesso ou fracasso na estratégia da organização
Como um desses instrumentos e com o objetivo de garantir o sucesso na implantação de
sistemas de ERP, é que as organizações passaram a adotar metodologias específicas de
gerenciamento de projetos. Estas metodologias foram adaptadas por diversas empresas de
Consultoria de Empresas, constituindo-se na base metodológica para suportar a implantação
de sistemas de ERP. Embora cada uma dessas metodologias adote um nome específico, de
acordo com empresa de consultoria que a aplica, todas elas possuem uma origem comum, a
metodologia de Project Management.
Este trabalho não tem como objetivo analisar detalhadamente cada uma dessas metodologias
nem compará-las à metodologia do PMI6• Mas sendo esta a base metodológica que suporta as
demais metodologias utilizadas para a implantação de sistemas de ERP, faremos uma revisão
6 The Project Management Institute
5
da bibliografia de Project Management existente de forma a permitir homogeneizar os seus
principais conceitos aos leitores deste trabalho.
1.4 Objetivo
Este trabalho tem como objetivo estudar casos reais de implantação de sistemas de ERP, que
utilizaram metodologias baseadas em técnicas de Project Management, com o intuito de
melhor compreender os problemas que estariam supostamente surgindo devido às falhas na
aplicação dessas técnicas, por parte da organização. Até que ponto a utilização das técnicas de
Project Management pode ser considerado o fator determinante que permitirá garantir o
sucesso da implantação de projetos de ERP.
o presente trabalho propõe uma análise crítica dessas técnicas levando-se em consideração,
por exemplo, que fatores levam as organizações a mudar, como a Organização trata a
Mudança, como o Gerenciamento da Mudança e o Gerenciamento da Comunicação afetam
o bom andamento e o sucesso de projetos de ERP. Adicionalmente, como a Formação de
Equipes é importante para garantir o sucesso de projetos de ERP. Se a questão da Liderança é
um fator crítico de sucesso para os projetos de ERP e por fim, como a Cultura
Organizacional pode influenciar um projeto de implantação de um sistema de ERP.
Ao longo do estudo, serão discutidas outras variáveis que afetam os resultados de projetos
gerenciados com base nas técnicas de Project Management.
Serão também apresentados os beneficios qualitativos do Project Management para o sucesso
de projetos de implantação de software ERP.
1.5 Organização do Estudo
Este estudo foi desenvolvido em 6 capítulos, estruturados da seguinte forma:
6
o Capítulo 1, introdutório, onde o trabalho é contextualizado. Onde os objetivos são
apresentados, seguidos da justificativa do estudo e da delimitação das suas fronteiras.
O capítulo 2 apresenta uma revisão do referencial teórico da dissertação. Esta revisão inclui os
principais fatores motivadores das mudanças dentro das organizações, uma revisão das
principais técnicas de Change Management e a importância da aplicação destas em um projeto
que envolve um elevado grau de mudança. Essa revisão aborda também os principais
conceitos de Project Management, a importância da formação das Equipes de Projeto e o fator
Liderança presente na equipe de projeto e nas características pessoais dos gestores e líderes de
projeto. A seguir, fazem-se considerações sobre a cultura dentro da organização, dentro do
projeto em si e dentro da própria equipe de projeto.
No capítulo 3, é descrita a Metodologia adotada, isto é, como o estudo foi feito, indicando o
desenho e o método da dissertação. Mais especificamente, este capítulo busca esclarecer e
justificar o método utilizado, identificar os tipos e as fontes de informações necessárias para
responder às questões da dissertação e os procedimentos para analisar as informações
coletadas.
No capítulo 4, são apresentados dois estudos de casos, relatando características e situações
ocorridas em de projetos de implantação de sistema de ERP em duas empresas. Esses casos
foram montados através de entrevistas com pessoas que tiveram uma participação ativa na
implantação desses sistemas nas 2 empresas analisadas. A empresa A é uma empresa do ramo
de papel e celulose. O sistema de ERP foi implantado nessa empresa em 1997 enquanto que a
empresa B é do setor de telecomunicações e esse mesmo sistema foi implantado em 1999.
No capítulo 5, objetiva-se a analisar as informações coletadas através desses estudos de caso,
buscando relacionar semelhanças e diferenças de padrão em cada uma dessas implantações.
Finalmente o capítulo 6 conclui e encerra o estudo, propondo recomendações para empresas
que pretendem implementar sistemas de ERP bem como trata de apontar situações e fatos que
merecem ser estudados com uma maior profundidade em pesquisas futuras.
7
Seguem-se as referencias bibliográficas e um anexo contendo o questionário utilizado nas
entrevistas realizadas, base para a elaboração dos estudos de caso.
8
2 REFERENCIAL TEÓRICO
Neste capítulo são apresentadas as contribuições de alguns dos principais estudiosos acerta
dos temas relacionados. Incluímos também bibliografia de autores não diretamente
relacionados à metodologia de Project Management mas que em seus estudos relatam temas
profundamente relacionados com a abordagem que este estudo procura dar ao tema gestão de
projeto de implantação de sistemas de ERP.
o estudo dos tópicos que integram o presente trabalho estabelece um referencial teórico
fundamental para a pesquisa e consolidação dos objetivos propostos neste trabalho. Sua
construção busca fornecer a compreensão necessária para a análise dos fatores relacionados
com o sucesso ou fracasso de projetos de implantação de sistemas de ERP.
Este capítulo está estruturado em 3 seções. Na primeira seção, faremos a fundamentação
teórica deste trabalho, assente na metodologia de Project Management, e por isso iniciamos a
revisão bibliográfica por este tema. Também apresentaremos uma conceituação sobre sistema
de ERP e faremos uma breve apresentação de um típico projeto de implantação de um sistema
deERP.
Em seguida, abordaremos questões relacionadas com a formação de equipes e como esta
questão influencia no sucesso de projeto de implantação de ERP. A seguir, trataremos o tema
Liderança, como a liderança dentro do projeto, principalmente relacionada à gestão e
coordenação de projeto, funciona como um diferencial não só para a equipe como para o
projeto em si.
Em seguida, iremos rever o que a teoria nos fala sobre a mudança e a resistência que esta
enfrenta dentro das organizações, principalmente nas organizações que se encontram em
processo de implantação de um sistema de ERP juntamente com uma análise das técnicas
Change Management e como a utilização destas técnicas vai contribuir para facilitar o
processo de mudança e a comunicação interna e externa ao projeto de ERP. Faremos também
algumas considerações sobre como a Cultura Organizacional é vista pelos estudiosos do
assunto e como ela afeta o projeto de implantação de sistemas de ERP.
9
2.1 A metodologia de Project Management e os sistemas de ERP
Esta seção tem como objetivo mostrar como se compõe a estrutura, organização e
operacionalização de um projeto bem como qualificar as principais fases do Project
Management. Nesta seção apresentamos também uma conceituação sobre sistemas de ERP e
apresentamos um típico projeto de implantação de um sistema de ERP.
2.1.1 A Metodologia de Project Management
2.1.1.1 O que é Projeto
De acordo com o PMBOK, um projeto é um empreendimento temporário com o objetivo de
criar um produto ou serviço único.7 Sua característica é temporária por possuir início, meio e
fim muito bem definidos e por seguir uma seqüência clara e lógica de eventos, os quais são
conduzidos por pessoas sempre respeitando os parâmetros de prazo, custo e qualidade. Estes
parâmetros também são conhecidos por "restrição tripla"s, de forma que são representados por
um triângulo conforme mostrado na Figura I - Restrição Tripla, a seguir:
7 Guia do PMBOK, © 2000 Project Management Institute - PMI 8 FRAME, J. Davidson. Gerenciando Projetos nas Organizações. 2001.
10
Custo
Qualidade
Figura I - Restrição Tripla9
Qualquer variação em um desses parâmetros influenciará o outro.
Um projeto chega ao seu fim quando os objetivos propostos em sua fase de concepção são
alcançados ou no momento em que a organização identifique que os objetivos não poderão ser
atingidos por alguma razão, como por exemplo, que o projeto não está mais de acordo com as
novas necessidades ou com a estratégia da empresa. Nesse momento, o projeto é encerrado
antecipadamente.
Os projetos são desenvolvidos em todos os níveis da organização. Eles podem envolver uma
única pessoa ou centenas delas. Podem envolver uma unidade isolada ou atravessar as
fronteiras organizacionais.
Os projetos envolvem algo que nunca foi desenvolvido antes, portanto são considerados
únicos e por isso, possuem um certo grau de incerteza. Eles são utilizados para capturar uma
oportunidade em um novo produto ou serviço e para aumentar a competitividade garantindo o
futuro e a sobrevivência da organização além de ser a forma pela qual as estratégias são
implementadas.
9 Idem.
11
Na fase de concepção, é fundamental a definição clara do seu objetivo de forma que os
participantes possam ter a mesma referência e somar seus esforços em uma única direção. Os
parâmetros prazo, custo e qualidade deverão servir de direcionadores permanentes durante
todo o desenvolvimento do projeto.
Atendê-los não é somente uma tarefa do gerente de projeto senão de todos os envolvidos nele.
Direcionar os esforços para que isso ocorra é fundamental. De acordo com o PMBOK IO, um
projeto se caracteriza por:
• Estar constituído por um conjunto determinado de trabalhos;
• Não ser repetitivo;
• Possuir objetivos claros e bem definidos;
• Dispor de tempo limitado;
• Dispor de orçamento fixo;
• Ser realizado por um grupo de pessoas ou uma equipe temporária que, ao final do
projeto, normalmente é liberada ou realocada em outras atividades ou diferentes
projetos.
Os objetivos do projeto devem ser claros e conhecidos assim como as alternativas devem ser
identificadas e as atividades devem ser descritas claramente. Um projeto é constituído por
uma série de tarefas. A cada tarefa são atribuídas responsabilidades para simplificar o seu
controle e assim poder se verificar, passo a passo, o cumprimento e a conclusão das tarefas
atribuídas. O resultado é um produto, serviço ou capacitação de um processo organizacional,
alinhado às necessidades operacionais da organização do ponto de vista do curto prazo e que,
se visto do ponto de vista do longo prazo, é estratégico. De acordo com o PMBOK, em
resumo, um projeto envolve:
• Tarefas
• Responsabilidades
• Orçamento (custos e tempo)
10 Guia do PMBOK, © 2000 Project Management Institute - PMI
12
• Recursos: financeiros e humanos
Projetos ficaram conhecidos pelos diferentes ciclos de vida e sistemas de gerenciamento que
forneciam uma formal e legítima integração de recursos através da organização. Linhas de
comando, motivação, liderança e técnicas de controle, surgiram para suportar os projetos
dentro da estrutura organizacional.
2.1.1.2 o gerenciamento de projetos e suas áreas de conhecimento
o Instituto de Project Management ll define "Project Management como a arte de dirigir e
coordenar recursos materiais e humanos, durante o ciclo de vida de projetos, através do uso de
técnicas modernas de gestão que permitam alcançar objetivos predeterminados de escopo,
custo, tempo, qualidade e satisfação dos participantes" 12.
Gerência de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas
destinadas ao controle de ações e atividades não repetitivas, únicas e complexas dentro de um
cenário de custo, tempo e qualidade determinado. Além disso, administrar projetos significa
tomar decisões e realizar ações de planejamento, organização e execução e que possibilitam o
desenvolvimento do ciclo de vida de projeto. Cada um destes cinco processos administrativos
-project process J3, é necessário para todo o projeto ou em cada uma de suas fases.
De acordo com o PMBOK podemos destacar alguns dos beneficios do Gerenciamento de
Projetos:
• Evita surpresas durante a execução dos trabalhos;
• Permite desenvolver diferenciais competitivos e novas técnicas;
• Antecipa as situações desfavoráveis;
• Adapta os trabalhos ao mercado consumidor e ao cliente;
11 The Project Management Institute - PMI 12 Brochure, Project Management Institute, 4 campus Blvd, Newtown Square, PA 19073 13 Guia do PMBOK, © 2000 Project Management Institute - PMI
13
• Agiliza as decisões;
• Aumenta o controle gerencial;
• Facilita e orienta as revisões da estrutura;
• Melhora a capacidade de adaptação;
• Otimiza a alocação de pessoas, equipamentos e materiais;
• Estrutura os custos de implantação;
• Documenta e facilita as estimativas para futuros projetos.
A utilização da metodologia de Gerenciamento de Projetos poderá ser aplicada sempre que a
empresa a julgue aplicável na consecução de sua estratégia. Projetos são para implementar
estratégias organizacionais, alcançar objetivos e contribuir para a realização da missão da
organização. A gerência de projetos está inserida em um ambiente mais amplo do que o
projeto propriamente dito, ou seja, a gerência de atividades diárias do projeto é necessária mas
não é o suficiente para alcançar o sucesso.
David I. Cleland (1999) 1\ em seus estudos, identificou que poucos livros retratavam o Project
Management como ferramenta de gestão dentro das organizações, ou seja, desde o desenho até
execução de projetos, que viabilizassem as estratégias organizacionais.
No seu livro Project Management. Strategic Design and Implementation15, o autor nos
apresenta uma conceituação moderna sobre o que seja Project Management, a qual será
utilizada como parte do referencial teórico neste trabalho. A Figura 11 - Áreas de Atuação
do Project Management demonstrada a seguir, resume as áreas de conhecimento do Project
Management e seus processos.
14 Ph.D. e professor de Engenharia da Universidade de Pittsburgh 15 (CLALAND, 1999)
Scope Management
Integration Management
~
? Procurement Management
Risk
\
Project Management
/
Time Management
I Cost
Management
Quality Management
Human Resources
Management
Management Communication Management
Figura 11- Áreas de Atuação do Project Management (Cleland (1999»
14
As áreas de conhecimento da Gerência de Projetos descrevem os conhecimentos e práticas
em gestão de projetos em termos dos processos que as compõe. Estes processos foram
organizados em nove áreas de conhecimentos detalhadas a seguir:
Integration Management ou Gerência da Integração do Projeto - Descreve o processo
necessário para garantir que os vários elementos do projeto se encontram devidamente
coordenados de forma a executar a fase de planejamento, a fase de execução e o controle de
mudanças do projeto. Envolve fazer compensações entre objetivos e alternativas com o
objetivo de atingir ou superar necessidades e expectativas dentro do projeto. Os processos
principais são:
15
• Desenvolvimento do plano do projeto - consiste em agregar resultados de outros
processos de planejamento e construir a documentação do projeto;
• Execução do plano do projeto - dar seqüência ao projeto de acordo com o que foi
planejado;
• Controle integrado de mudança - coordenar as mudanças através do projeto.
Uma das técnicas utilizadas, tanto para interagir vários processos quanto para medir o
desempenho, desde a iniciação até a conclusão, é a gerência de valor agregado (Earned Value
Management - EMV).
Scope Management ou Gerência do Escopo do Projeto - Descreve o processo necessário para
assegurar que o projeto inclui todas as fases e trabalho necessário para concluir o projeto de
forma satisfatória, atingindo os objetivos (escopo) propostos. Sua preocupação principal é
definir e controlar o que foi previamente definido e não agregar novos objetivos ao projeto. Os
principais processos são:
• Iniciação - consiste em autorizar o projeto ou fase em questão;
• Planejamento do escopo - desenvolver documentação do escopo para servir de base
para a tomada de decisões futuras que envolvem o projeto;
• Detalhamento do escopo - consiste em subdividir os principais subprodutos do projeto
em componentes menores e facilmente manejáveis;
• Verificação do escopo - formalização da aprovação do escopo do projeto;
• Controle de mudanças do escopo - controlar as mudanças de escopo no projeto.
Time Management ou Gerência do Prazo do Projeto - Descreve o processo necessário para
garantir que o projeto seja concluído no prazo estipulado. Os principais processos são:
• Definição das atividades - consiste em identificar as atividades específicas que devem
ser realizadas para produzir os subprodutos do projeto;
• seqüênciamento das atividades - documenta e identifica as relações de dependência
entre as atividades;
16
• Estimativa da duração das atividades - estima a quantidade de períodos de trabalho
que serão necessários para a implementação de cada atividade;
• Desenvolvimento do cronograma - analisa a seqüência das atividades, sua duração, e
os requisitos de recursos para criar o cronograma do projeto;
• Controle do cronograma - controla as mudanças que se façam necessárias no
cronograma do projeto.
Cost Management ou Gerência do Custo do Projeto - A gerência do custo do projeto envolve
os processos necessários para assegurar que o projeto será concluído dentro do orçamento
aprovado, consistindo fundamentalmente nos custos dos recursos necessários à
implementação das atividades do projeto. Em muitas áreas de aplicação, prever e analisar a
perspectiva de desempenho financeiro do produto do projeto é uma atividade que é feita fora
do ambiente do projeto. Já em outras, a gerência de custo executa este trabalho. Quando as
previsões são concluídas, a gerência do custo inclui processos adicionais e diversas técnicas
de administração como previsão de retomo de investimento, fluxo de caixa, entre outras. Os
principais processos são:
• Planejamento dos recursos - determinar quais recursos e sua quantidade devem ser
aplicados para executar as tarefas do projeto;
• Estimativa de custos - estimar aproximadamente os custos dos recursos necessários
para executar as atividades do projeto;
• Orçamento dos custos - alocar as estimativas de custos globais aos itens individuais de
trabalho;
• Controle dos custos - controlar as mudanças no orçamento do projeto.
Quality Management ou Gerência da Qualidade do Projeto - Descreve o processo necessário
para garantir que as necessidades que originaram seu desenvolvimento foram atendidas. Os
principais processos são:
• Planejamento da qualidade - consiste em identificar que padrões de qualidade são
relevantes para o projeto e determinar a melhor forma de atendê-los.
17
• Garantia da qualidade - proporciona a avaliação periódica do desempenho do projeto
visando assegurar a satisfação dos padrões de qualidade relevantes.
• Controle da qualidade - consiste em supervisionar os resultados do projeto
determinando se estão de acordo com os padrões de qualidade. Além disso deve-se
identificar as formas para eliminar as causas de desempenhos insatisfatórios.
Human Resources Management ou Gerência dos Recursos Humanos do Projeto - O
gerenciamento dos recursos do projeto inclui os processos necessários para tomar mais efetiva
a utilização dos recursos humanos envolvidos no projeto. Os principais processos são:
• Planejamento organizacional - identificar, documentar e designar os papéis,
responsabilidades e os relacionamentos de reporte no projeto;
• Montagem da equipe - conseguir que os recursos humanos necessários sejam
designados e trabalhem no projeto;
• Desenvolvimento da equipe - desenvolver competências individuais e de grupo para
elevar o desempenho do projeto.
Communication Management ou Gerência das Comunicações do Projeto - A gerência das
comunicações no projeto inclui os processos necessários que visam garantir a regular a
apropriada geração, coleta, disseminação, armazenamento e descarte final das informações do
projeto. Promove os relacionamentos entre a equipe, troca de idéias e informações necessárias
para obtenção do sucesso no projeto. Os principais processos são:
• Planejamento das comunicações - determina as informações e comunicações
necessárias às partes envolvidas. Define quem necessita das informações, quando
serão necessárias e como serão fornecidas;
• Distribuição das informações - consiste em tomar as informações acessíveis às partes
envolvidas no projeto;
• Relato de desempenho - coleta e dissemina as informações de desempenho. Inclui
relatórios de posicionamento, progresso do projeto e previsões;
• Encerramento administrativo - consiste em gerar, reunir e disseminar informações
para formalizar a conclusão de uma fase ou do projeto.
18
Risk Management ou Gerência dos Riscos do Projeto - É um processo sistemático para
identificar, analisar e responder aos riscos do projeto. Inclui maximizar a probabilidade e
conseqüência de eventos positivos e minimizar a probabilidade de eventos adversos aos
objetivos do projeto. Os principais processos são:
• Planejamento da gerência de risco - consiste em decidir como abordar e planejar a
gerência de risco no projeto;
• Identificação dos riscos - determina os riscos prováveis do projeto e documenta suas
características;
• Análise qualitativa de riscos - analisa qualitativamente os riscos e condições para
priorizar seus efeitos nos objetivos do projeto;
• Análise quantitativa de riscos - mensura a probabilidade e impacto dos riscos e estima
suas implicações nos objetivos do projeto;
• Planejamento da resposta aos riscos - desenvolve procedimentos e técnicas para
aumentar oportunidades e para reduzir a ameaça de riscos para os objetivos do projeto;
• Controle e monitoramento de riscos - monitora os riscos residuais, identifica novos
riscos, executa os planos de redução de risco e avalia sua efetividade durante todo o
ciclo de vida do projeto.
Procurement Management ou Gerência das Aquisições do Projeto - A gerência das
aquisições do projeto inclui os processos necessários à aquisição de bens e serviços externos à
organização. Os principais processos são:
• Planejamento das aquisições - determina o que se deve contratar e quando;
• Preparação das aquisições - documenta os requerimentos do produto e identifica os
possíveis fornecedores;
• Obtenção de propostas - obtém as propostas dos fornecedores;
• Seleção de fornecedores - elege entre possíveis fornecedores;
• Administração de contratos - gerencia o relacionamento com os fornecedores;
• Encerramento do contrato - liquida o contrato incluindo a resolução de qualquer ponto
pendente.
19
2.1.1.3 O processo de Project Management
Após entendermos quais são as áreas de atuação do Project Management, podemos entender
melhor o seu processo.
Para Cleland (1999), o processo de Project Management define a tônica da gerência de
projetos ou seja, a conceituação, o planejamento e a execução de um projeto, seus métodos e
políticas bem como o comprometimento dos recursos nele envolvidos. Entre o início e o seu
fim, o projeto sofre todo um desenvolvimento, estruturação, implantação e conclusão. Para
facilitar o controle gerencial do projeto, ele é dividido em várias fases proporcionando uma
melhor ligação com os processos operacionais, também conhecidos por ongoing operations.
Cleland (1999) chama essas fases de Ciclo de Vida de um projeto. Ao se elaborar o Ciclo de
Vida de um projeto, é possível prever o consumo de recursos demandados por ele, etapa por
etapa, durante todo o tempo. Permite-nos também criar um anteprojeto, um estudo de
viabilidade sobre o que se pretende desenvolver, sendo um instrumento valioso para
aprofundar idéias e conceitos a serem implementados. O Ciclo de Vida de um projeto
representa seu nascimento, desenvolvimento e consolidação até o seu encerramento conforme
demonstrado na Figura lU - Ciclo de Vida de um Projeto, a seguir:
R e c u r s O
Figura IH - Ciclo de Vida de um Projeto 16
20
Cada fase é marcada pela conclusão de um ou mais produtos (deliverables). Os produtos de
uma fase normalmente são aprovados antes do início da fase seguinte. Entretanto, quando os
riscos são aceitáveis, é possível iniciar a fase subsequente antes da aprovação dos produtos da
fase precedente. Esta técnica é chamada de fas! tracking. A seguir são descritas as principais
atividades em cada fase.
A Fase I, é a fase de Concepção, a fase inicial que marca o surgimento da necessidade de
projeto pelo usuário. Ela compreende o período desde o seu nascimento até a aprovação da
proposta para a sua execução. Nessa etapa, as principais atividades são:
• Identificação de necessidades e/ou oportunidades;
• Tradução dessas necessidades e/ou oportunidades em um problema;
• Equacionamento e definição do problema;
• Análise do ambiente do problema;
• Determinação dos objetivos e metas a serem alcançados;
• Definição do gerente do projeto;
• Análise das potencialidades ou recursos disponíveis;
BIBLIOTECA MARIO HENRIQUE SIMONSE" FUNDACAO GETULIO VARGAS
21
• Avaliação da viabilidade de atingimento dos objetivos;
• Estimativa dos recursos necessários;
• Elaboração da proposta e venda da idéia;
• Avaliação e seleção com base na proposta submetida;
• Decisão quanto à execução do projeto.
Para Menezes (2001) 17, na fase de concepção, as ações criadas a partir desse processo visam
dar uma visão de futuro do que se deseja obter do projeto. Desta forma quanto mais recursos
em termos de tempo, análise e planejamento forem dedicados a esta fase, maior será a
oportunidade de alcançar o êxito no futuro, além do fato de poder se planejar melhor a
formação da "equipe básica" do projeto e consequentemente promover a integração entre os
seus membros.
A Fase II é a fase de Planejamento e tem como preocupação central a estruturação e
viabilização operacional do projeto. A proposta de trabalho é detalhada por meio de um plano
de execução operacional cujas principais atividades são:
• Detalhamento das metas e objetivos a serem alcançados, com base na proposta
aprovada;
• Detalhamento das atividades e a estrutura de divisão de trabalho (WBS - Work
Breakdown Structure);
• Programação das atividades no tempo disponível e/ou necessário (através da
elaboração de Cronograma);
• Determinação dos marcos ou milestones a serem alcançados durante a
execução do projeto;
• Programação da utilização e aprovisionamento dos recursos humanos e
materiais necessários ao gerenciamento e à execução do projeto (alocação dos
recursos);
16 CLELAND (1999), David I. Project Management. Strategic Design and Implementation. 3rd. Edition. Singapore: McGraw-HiII, 1999.
17 MENEZES, Luis César de Moura. Gestão de Projetos. 10 Edição. São Paulo: Editora Atlas, 2001.
22
• Delineamento dos procedimentos de acompanhamento e controle a serem
utilizados na implantação do projeto (inclusive controle de custos);
• Estabelecimento da estrutura orgânica formal a ser utilizada para o projeto
(formação da equipe e matriz de responsabilidades);
• Estruturação do sistema de comunicação e de decisão a ser adotado (plano de
Comunicação);
• Designação e comprometimento dos técnicos que participarão do projeto
(Atividades de Change Management);
• Treinamento dos envolvidos com o projeto.
Em linha com o que diz Cleland (1999), Menezes (2001) complementa a análise nos dizendo
que a fase de planejamento permite detalhar o escopo do projeto e ainda as atividades
seguintes incluindo custo, prazo e qualidade. Ainda é possível, nesta fase, trabalhar no
planejamento da equipe, no detalhamento dos riscos e na identificação de ações para
minimizá-los assim como no planejamento da comunicação do projeto, no plano de contratos
com fornecedores e identificação dos suprimentos requeridos para essas contratações.
Já a Fase lI!, a fase de Execução, refere à execução do trabalho propriamente dito. Quase
sempre são necessários ajustes ao longo do trabalho com o objetivo de seguir o plano inicial
no que se refere a prazos e orçamento. Nesta fase, as principais atividades são:
• Ativar a comunicação entre os membros da equipe do projeto (pondo em
prática o Plano de Comunicação e dando manutenção às atividades de Change
Management);
• Executar as etapas previstas e programas de trabalho (atividades de controle);
• Utilizar os recursos humanos e materiais, sempre que possível, dentro do que
foi programado;
• Efetuar reprogramações no projeto segundo seu status quo, adotando os planos
e programas iniciais como diretrizes mutáveis.
• Garantir a qualidade mediante avaliações regulares do desempenho geral do
projeto de acordo com os padrões de qualidade estabelecidos (Quality
Assurance);
23
• Administração de contratos.
Complementando essa análise, podemos dizer que a fase de execução consiste em coordenar
pessoas e demais recursos para realizar o plano de ação simultaneamente com a fase de
controle. Nessa fase são necessárias não só habilidades técnicas mas também de
relacionamento humano, assim como o gestor do projeto deve possuir características de
liderança. Conhecer a equipe, suas necessidades e limites é muito importante. O controle é
realizado com acompanhamento das atividades, podendo-se utilizar diversas fontes: prazo,
custos, qualidade, escopo e riscos. Paralelamente, monitorar sistemas de garantia da qualidade
dos resultados e de controle do desenvolvimento do escopo são tarefas relevantes que ocorrem
durante esse período. Ao mesmo tempo, a disseminação das informações no projeto é
importante e não ocorre somente com a implementação de um Plano de Comunicação mas
também pela identificação e mapeamento do Stakeholders, com o emprego de técnicas e
feedback necessário junto à equipe de projeto, aos próprios Stakeholders e à organização
como um todo.
A Fase IV, de Conclusão, é a fase que corresponde ao término do projeto, fase visivelmente
identificada pelo desligamento gradual de pessoas e empresas envolvidas no projeto. Nesta
fase, as principais atividades que ocorrem são:
• Aceleração das atividades que não tenham sido concluídas;
• Realocação dos recursos humanos para outras atividades ou projetos;
• Elaboração da memória técnica do projeto (finalização da documentação do
projeto);
• Elaboração de relatórios e transferência dos resultados finais (Lessons
Learned);
• Emissão de avaliações globais sobre o desempenho da equipe do projeto e
resultados alcançados;
• Encerramento dos contratos.
24
A fase de conclusão ou fechamento, refere-se à aceitação formal do projeto e encerramento
deste, de forma organizada, incluindo o encerramento com os fornecedores e subcontratados.
Diversas outras atividades são importantes, como por exemplo, sessões de lições aprendidas,
avaliação e documentação final do projeto.
Na Figura IV - Inter-relacionamento entre os grupos de processos no desenvolvimento
de um projeto abaixo, as setas indicam a troca de informações entre os diversos processos.
~ceP~~------
Figura IV - Inter-relacionamento entre os grupos de processos no desenvolvimento de
um projeto. I8
Além disso, esses grupos de processos não são separados ou descontínuos assim como
também não ocorrem uma única vez. Eles são formados por atividades que se sobrepõe,
ocorrendo em intensidade variável ao longo de cada projeto. A Figura V - Sobreposição de
grupos de processos dentro das fases do projeto abaixo, ilustra como os grupos de
processos se sobrepõem e variam dentro de cada uma das fases do projeto.
18 MENEZES, Luís César de Moura. Gestão de Projetos. 1° Edição. São Paulo: Editora Atlas, 2001.
v
m e
A t i
Processos de planejamento
Processos de execuçlo
Processos de fechamento
Tempo
Figura V - Sobreposição de grupos de processos dentro das fases do projeto
(Menezes(2001»
25
A visão macroscópica do Ciclo de Vida de um projeto é muito importante pois através dela os
envolvidos podem avaliar as dimensões do projeto pretendido. Nesse contexto, as funções
demonstradas na Figura VI - Processo de gerenciamento e suas funções devem ser
analisadas ao se falar em Project Management.
Control
o;"",lIng r=!5 ManagementJ
Process
Motivation ~
Organization
Figura VI - Processo de Gerenciamento e suas funções (Cleland (1999»
Todos estes fatores são interdependentes, tanto em uma organização como na gerência de um
projeto. Durante a fase de planejamento (Planning), a organização deverá estabelecer e
determinar a missão, os objetivos, as metas e as estratégias do projeto. A organização
(Organization), refere-se aos recursos envolvidos, sejam eles humanos ou financeiros e como
esses recursos serão usados ou estarão alinhados ao projeto. A definição da autoridade
(Directing) e responsabilidades manterão o curso do projeto. A motivação (Motivation) é vista
26
como o fator que permite trazer à tona o que há de melhor nas pessoas. Monitoramento,
avaliação e controle (Controlling) fornecem os meios para determinar o quanto os projetos e
as estratégias organizacionais estão sendo bem utilizadas no atingimento dos objetivos e
metas no emprego de predeterminada estratégia.
2.1.1.4 Principais grupos envolvidos no projeto
Dentre as pnnClpalS pessoas envolvidas em um projeto, Cleland (1999)19 destaca os
Stakeholders, indivíduos ou empresas envolvidas no projetos ou aqueles cujos os interesses
podem ser afetados no decorrer do projeto ou até mesmo após sua conclusão.
Têm-se também a equipe de projeto, cujo processo de formação é muito importante pois seus
membros estarão relacionando-se entre si durante o período de desenvolvimento do projeto.
Sua interação é importante para o atingimento dos objetivos. Os membros da equipe do
projeto são conhecidos como especialistas e são os responsáveis pela execução das tarefas do
projeto, na sua área de especialização técnica.
O Cliente é indivíduo ou grupo que fará uso do projeto.
Em todo projeto estão igualmente envolvidos o patrocinador do projeto ou Sponsor, indivíduo
ou grupo dentro da organização executora que provê os recursos financeiros para o projeto.
Como parte integrante do projeto, o patrocinador passa a ser um estimulador das negociações
entre as partes, incentivando o diálogo e a participação na identificação do problema e na
busca da solução. Também é responsável pela posta em prática das decisões acordadas.
O gerente do projeto é o indivíduo responsável pela condução do projeto e deverá possuir uma
visão integrada do mesmo. É o ponto focal de uma rede de comunicação entre os membros do
projeto, que pode envolver pessoas internas e externas à empresa, conhecidos como
19 CLELAND (1999), David I. Project Management. Strategic Design and Implementation. 3rd. Edition. Singapore: McGraw-Hill, 1999.
27
Stakeholders. Ele também é responsável por diversos elementos chave oriundos das atividades
do projeto, são eles:
• Organizar a equipe e demais recursos para suportar o objetivo do projeto, as metas e as
estratégias;
• Planejar a utilização dos recursos nas diversas fases do ciclo de vida do projeto;
• Identificar e utilizar informações relevantes para gerenciar o projeto;
• Liderar os membros da equipe do projeto;
• Conduzir avaliações periódicas dos resultados obtidos e redirecionar ou reprogramar
os recursos conforme a necessidade mantendo o projeto conforme o planejamento
inicial;
• Utilizar modernas ferramentas e técnicas de gestão visando facilitar o processo de
gerenciamento;
• Manter o usuário informado;
• Manter o proprietário do projeto informado do andamento do projeto de forma que
tenha a consciência de quanto o projeto está em conformidade com as estratégias da
organização.
O gerente funcional será responsável pode ceder os recursos ou especialistas para participarem
do projeto. Possui a responsabilidade reduzir o impacto das mudanças trazidas pelo projeto
para a empresa, redistribuindo os recursos restantes de sua área e suas respectivas atividades
aos recursos remanescente na áreas funcionais.
2.1.2 Sistemas de ERP
O conceito de ERP (Enterprise Resource Planning) passou a ser o novo paradigma que
direcionou o desenvolvimento de sistemas aplicativos. Empresas industriais e comerciais
passaram a adotar esta tecnologia tão rápido quanto possível. Lozinsky (l996io, destacou os
seguintes beneficios mais perceptíveis:
2°LOZINSKY, SERGIO, Software: Tecnologia do Negócio, Imago Editora Ltda, São Paulo, Brasil, 1996
• habilidade de suportar a revisão de processos;
• maior visibilidade e controle sob a cadeia de suprimentos;
• consistência e robustez dos sistemas do ponto de vista tecnológico;
• redução dos custos diretos com tecnologia de informação.
Não existe uma única definição formal para sistemas ERP. Jones (1997)21 os define como
sistemas integrados de software que:
28
• integram todos os processos, regras e aplicações para automatizar toda a cadeia de
suprimentos;
• são baseados em tecnologia viabilizadora da atuação e controle por processos em
contraponto à atuação e controles departamentais;
• fornecem uma arquitetura de informações que une toda a empresa, inclusive suas
diversas plantas e países.
Alguns dos fatores que levam os sistema de ERP a ser um dos tópicos mais discutidos nesse
momento, independente da indústria, foram: maior competição, necessidade de incrementos
de qualidade e variedade nos produtos, bem como a redução dos tempos e dos custos de
desenvolvimento de novos aplicativos, no custo da tecnologia, na redução do volume de
pessoal (tanto em níveis gerenciais e como nos overheads).
Outro fator relevante que propiciou a migração para sistemas de ERP, foi o aumento das
fusões e aquisições observado em praticamente todas as indústrias. As empresas necessitam
de tecnologias que possibilitem rapidamente acomodar este tipo de mudança, que possam ser
rapidamente aplicadas às suas novas divisões, plantas ou negócios.
2I JONES, C., Planning Guidelines for Implementing ERP, Part 1 & 2,Gartner Group Research, Stanford, CT, USA,27/03/97
Troca Eletrônica de Documentos
Processos Operacionais
Processos de Suporte
Figura VII - Visão Geral do ERP22
I
;1roca Eletrônica de Documentos
29
À medida que o tempo passa, observa-se que os sistemas de ERP incorporam maIS
características que permitem análises em tempo real, previsão de tendências e otimização de
processos, rotas de distribuição (Logística) e controles. Por integrar as informações de todas as
plantas, negócios e departamentos da empresa, através de uma base contábil única, o ERP
viabiliza análises em tempo real de diversas questões fundamentais para o negócio da
organização como a quantidade e qualidade dos produtos, dos insumos em estoque, a
satisfação dos clientes, os níveis de rentabilidade por produto e segmento de clientes, entre
outros.
Alguns sistemas de ERP permitem também a realização de simulações dessas variáveis, muito
antes do planejamento da produção ser realizado. Módulos financeiros e de planejamento
recebem informações diretamente dos módulos de manufatura, distribuição e suprimentos
permitindo que decisões sejam tomadas de modo rápido e eficiente.
Para suportar este sonho de integração, os fornecedores de software foram obrigados a valer
se do que há de melhor em termos de tecnologia de software. Em 1994, segundo Bond
22 LOZINSKY, SERGIO, Software: Tecnologia do Negócio, Imago Editora Ltda, São Paulo, Brasil,1996
30
(1996)23, as palavras de ordem eram Cliente-Servido~4 e Interface Gráfica com Usuári025
(GUI). A partir de 1995 essas tecnologias continuaram dominando o mercado e absorvendo
parte significativa dos investimentos dos produtores de software. Mas uma nova tecnologia
passou a ser o maior foco de atenção dos fornecedores deste tipo de produto: a orientação a
objeto. Fornecedores que não concentraram seus esforços em adaptar seus produtos a estas
tecnologias provavelmente não estão no mercado hoje nem estarão nos próximos anos26. A
tecnologia utilizada pelo fornecedor deve ser um fator determinante no produto de ERP a ser
utilizado por uma empresa. Provavelmente o direcionador mais claro para adoção de sistemas
de ERP tenha sido, de acordo com Bond (1996), o conceito de cadeia logística integrada
(Supply Chain). Porter (1992)27, no mesmo livro que enuncia este conceito, propõe que um
dos requisitos para se obter vantagens através da utilização desse conceito é justamente a
utilização de sistemas integrados de gestão. Porter (1992) define a cadeia logística integrada,
ou cadeia de valor, como o "instrumento que representa uma empresa através das suas
atividades estratégicas e de suporte e que é usado para compreender o comportamento dos
custos, as fontes desses custos e os potenciais de diferenciação da empresa,,28. Isto é, um
modelo que representa as atividades da empresa com a finalidade de compreender seu
relacionamento e interação e otimizá-los na busca de vantagens competitivas. De acordo com
Porter (1992), para alcançar a vantagem competitiva através deste instrumento seriam
necessários, o entendimento e difusão do conceito e estratégia de gerenciamento por processos
(atividades) em contraposição ao gerenciamento por departamentos, a revisão das formas de
acompanhamento e controle da empresa em função da nova visão - "Administração por
Processos", a revisão da estrutura organizacional para "quebrar" ou abrandar as barreiras
departamentais, a integração com fornecedores e clientes e a integração dos sistemas de
informação.
23BOND, B., ERP Market Trends: Vendors Struggle to Stay Competitive, Gartner Group Research, Stanford, CT, USA, 18/11196
24Tecnologia pela qual se torna possível conectar diversos computadores e distribuir ordenadamente as tarefas a serem realizadas entre eles. Pode-se por exemplo ter um SERVIDOR de banco de dados, ie um computador que gerencia e mantém o banco de dados, conectado a uma estação (computador) CLIENTE que tem os programas que permitem a consulta e manipulação desses dados.
250 padrão anterior para interação do usuário com os sistemas era a interface orientada a caracteres, onde o usuário compunha suas instruções e recebia suas respostas exclusivamente através de textos. A interface gráfica permite a utilização de ícones, janelas, imagens para que o usuário interaja com seus sistemas.
26BOND, obra cit. 27pORTER, Michael E., Vantagem Competitiva: criando e sustentando um desempenho superior, Editora
Campus, Rio de Janeiro, 1992.
31
Toda cadeia logística se inicia no relacionamento com fornecedores e termina no
relacionamento com os clientes. No passado, as empresas se esforçavam por isolar os seus
clientes do seu processo de produção mantendo-os, no máximo, ao nível do seu serviço de
atendimento a clientes. Hoje as empresas, para manterem sua competitividade, buscam maior
integração com seus parceiros de negócios. Adicionalmente, a necessidade de sincronização
dos processos de suporte aos processos operacionais da empresa é um fator de incentivo à
adoção dos sistemas do ERP. Anteriormente, os executores dos processos de suporte como
contabilidade, tesouraria, planejamento financeiro, entre outros, não estavam diretamente
integrados ao processo de produção e distribuição dos produtos da empresa. Com os sistemas
ERP esses grupos passaram a ter uma visão mais ampla do processo produtivo a partir da
disponibilização de informações que antes estavam disponíveis apenas para o pessoal
"operacional". A implantação de sistema de ERP portanto, rompe barreiras departamentais e
exige freqüentemente mais mudanças do que apenas a troca de tecnologia29.
Outro fator que contribui para o sucesso das ferramentas de ERP foi a necessidade de
ferramentas adequadas para o gerenciamento da distribuição de produtos. Os sistemas de ERP
são úteis, no sentido que permitem a consideração de todos os fatores de custos, necessidades
de transporte para todas as ordens e disponibilidade de canais de distribuição. Os sistemas de
ERP permitem, por exemplo, determinar se é preferível atender pedidos a partir de estoques
existentes ou utilizando a capacidade ociosa de uma planta para produzir o pedido a partir do
zero.
Para implementar o conceito de ERP, tanto é possível adquirir os diversos componentes
(módulos) de mais de um fornecedor, escolhendo possivelmente os melhores produtos para
cada funcionalidade (contabilidade, planejamento de produção, comercialização, suprimentos,
qualidade, etc.), quanto optar por um fornecedor único, privilegiando a integração a aquisição
da melhor em cada área. Um número cada vez maior de empresas vem fazendo a segunda
opção, contratando seu sistema de ERP de um único fornecedor.
28 Idem p.33 29 KELLER, E., The Four R's ofERP, Gartner Group Research, Stanford, CT, USA, 29/11/95
32
Naturalmente, decisões sobre investimentos desta natureza não se limitam a estudos
financeiros. Usualmente consideram também aspectos estratégicos e tecnológicos do negócio.
Entretanto, na maior parte das vezes, tais decisões implicam em mudanças na estrutura
organizacional e nos processos de negócio da empresa, provocando mudanças nas rotinas e,
eventualmente, na sua cultura. Nem sempre a organização está preparada para enfrentar e lidar
com essas mudanças. Atualmente, os processos de mudança "constituem uma dinâmica
própria de cada organização,,3o e costumam ser subestimados quanto à importância que a
contínua mudança nos processos têm sobre a dinâmica própria de cada Organização.
2.1.3 Um projeto de implantação de um sistema de ERP
A implantação de soluções de ERP requer o apoio de empresas especializadas de consultoria.
Essas empresas atuam não só no aporte de conhecimento técnico sobre o produto, mas
principalmente na orientação metodológica e no gerenciamento do projeto. A metodologia a
ser empregada no projeto em questão prevê que o esforço de implantação seja organizado em
sete frentes de trabalho sendo elas:
A equipe de infra-estrutura tecnológica, responsável por implantar os meios fisicos para
operação do sistema (servidores, redes, canais de comunicação, microcomputadores, etc.), os
procedimentos para sua operação, controle e manutenção e selecionará eventualmente o
software necessário para complementar a funcionalidade do sistema de ERP (ferramentas para
usuário final, por exemplo). A equipe de desenvolvimento será responsável pelo
desenvolvimento de programas de interface, conversão de dados, relatórios, adaptações e
complementos para o sistema de ERP. A equipe funcional será responsável pela realização da
revisão dos processos de negócio e da configuração do sistema de ERP. A equipe de
gerenciamento de mudança que tratará da integração do time de trabalho e da resolução de
problemas interpessoais, do plano de comunicação, da elaboração e execução do treinamento,
da revisão da estrutura organizacional, da revisão de cargos e salários e da administração de
30Mudança e Transformação Organizacional, Prof. Dra. Rosa Maria Fisher - Mudando os Paradigmas da Mudança.
33
expectativas e ansiedades dos principais Stakeholders afetados pelo projeto. A equipe de
gerenciamento de riscos associados ao sistema que será responsável por identificar e gerenciar
os riscos associados às mudanças de processo sugeridas e às interfaces com outros sistemas.
Especificará e implementará os mecanismos de controle de acesso do sistema de modo a
garantir o respeito a normas de aprovação de documentos e a segregação de funções entre
funcionários. O grupo de garantia da qualidade, que acompanhará o desenvolvimento das
atividades das frentes de trabalho anteriores, comparando-as com as melhores práticas na
implantação de sistemas de ERP. Avaliará também o grau de cumprimento das tarefas e da
qualidade da documentação do projeto e acompanhará a evolução de indicadores de qualidade
do projeto, fornecendo subsídios para decisões da gerência de projeto. E por fim, a gerência de
projeto que será responsável pela gestão dos recursos do projeto de modo a concluir as tarefas
necessárias com qualidade, no prazo e no custo estimados. Garantirá também a integração e o
sincronismo das tarefas das demais equipes.
Cada uma destas frentes de trabalho serão formadas por: consultores, representantes das áreas
usuárias, representantes da área de informática e/ou representantes da sistema de ERP.
Uma estrutura tradicional de um projeto de ERP, numa fase inicial de projeto pode ser
representada pela Figura VIII - Estrutura Proposta para um Projeto de ERP, a seguir:
Infraestrutura Tecnológica
•••••
Gerência de Projeto
••• Gerência Geral e de Integração
Gerenciamento Gerenciamento Garantia da da Mudança de Riscos de Qualidade
Sistema •••• • •••• • Cliente .lnfonniüc.
• CllenCe - Usuirtos
• eo ... ultItrN
l1li 'A.
34
Figura VII - Estrutura Proposta para um Projeto de ERP31
Nota: Cada quadrado colorido no gráfico representa um profissional.
Em um projeto de implantação de software, como em qualquer outro, a equipe precisa ser
capacitada para exercer suas atividades. Em um projeto de implantação de sistema de ERP, a
capacitação assume um papel ainda mais relevante. Conhecer um software da sua magnitude
exige o investimento de diversas semanas em cursos formais e muito auto-estudo. Os
consultores alocados ao projeto, por exemplo, passam por um mínimo de cinco semanas de
treinamento técnico e ao termino desse período participam de um exame de proficiência
aplicado pelo fornecedor do software para se habilitarem a participar. A isso deve-se ainda
acrescentar treinamento na localizaçã032 do software, quando é o caso, na metodologia e
ferramentas de trabalho e um período mínimo de treinamento de campo. O treinamento da
equipe do cliente é usualmente menos profundo do que o dos consultores. Deve entretanto
abordar outros aspectos que não somente o conhecimento do software, metodologia e
ferramentas: trabalho em equipe, gerência de projetos, habilidades de comunicação e técnicas
de apresentação, por exemplo.
O gerenciamento de um projeto requer que o foco interfuncional e interorganizacional seja
estabelecido dentro da organização. Tanto a liderança e a capacidade gerencial são necessárias
para a conclusão com sucesso de um projeto assim como o sucesso de um projeto está
relacionado ao atingimento dos parâmetros estabelecidos para a performance tecnológica,
custo e prazos (e devem estar alinhados com os objetivos e/ou propósitos operacionais e
estratégicos de uma organização.
31 LOZINSKY, SERGIO, Software: Tecnologia do Negócio, Imago Editora Ltda, São Paulo, Brasil, 1996 32 Também conhecido no meio como tropicalização
35
2.2 Formação de Equipes e a Liderança
Entendidos os principais conceitos de Project Management, vamos agora nos aprofundar na
revisão bibliográfica de temas específicos relacionados à metodologia apresentada na seção
anterior e que irão constituir o foco da análise crítica deste estudo como a formação de
equipes e a questão da liderança.
2.2.1 A formação de equipes de projeto
Formar uma equipe para a implantação de um projeto, não é um tarefa fácil. A formação da
equipe, é um fator muito importante para garantir o sucesso de um projeto. Ela geralmente
ocorre no início do processo de planejamento do projeto. Esses recursos tendem a ser um dos
fatores mais escassos em um projeto. De acordo com Frame (1995)33, um projeto
normalmente não falha por falta do emprego de técnicas e sim por que o nível de qualificação
da equipe do projeto não era o apropriado para as necessidades desse mesmo projeto ou
porque a gerência dava instruções irrealistas para a equipe de projeto ou porque havia ainda,
falta de liderança na implantação do projeto.
Ainda segundo Frame (1995), a equipe é definida como a reunião de indivíduos que trabalham
juntos para atingir um objetivo comum e, para que eles trabalhem juntos, os esforços
individuais devem ser bem coordenados. No processo de planejamento de um projeto, em
determinado momento, é necessário "identificar e quantificar a quantidade de pessoas
necessárias para executar o projeto, suas atribuições e funções, as suas responsabilidades e os
recursos materiais necessários".34 De acordo com Valeriano (1998), antes de se iniciar a
contratação dos recursos humanos é importante, no mínimo, que as tarefas e atividades
básicas do projeto estejam definidas (fase de planejamento, de acordo com a metodologia de
Project Management) para que seja possível não só "comunicar as necessidades do projeto, as
33FRAME, J. Davidson, Managing Project in Organizations, How to make the best use oftime, techniques and People, Jossey-Bass Inc. San Francisco, California, 1995.
36
responsabilidades e a estrutura de reporte entre os membros da equipe bem como para
gerenciar a expectativa que normalmente se cria antes do início do projeto,,35
o processo de "aquisição do pessoal pode ocorrer na própria organização ou fora dela. A
maior preocupação deve ser a de obter as pessoas com os exatos requisitos necessários para o
projeto... se as pessoas pertencem à organização, o gerente do projeto deverá proceder às
negociações com seus chefes ou gerentes funcionais e com as próprias pessoas para obter o
seu consentimento e garantir a sua conseqüente participação no projeto. Nos casos em que a
organização não disponha do perfil necessário, o pessoal que irá compor a equipe deverá ser
suprido mediante contratações extemas,,36.
A pressa e pressão imposta pelo próprio projeto na escolha da equipe normalmente é
responsável pela qualidade da performance dessa mesma equipe e, o resultado da escolha de
pessoal, não necessariamente mais adequados para as tarefas a serem efetuadas, poderá
resultar na perda de qualidade do projeto.
Para Frame (1995)37, as pessoas em um projeto são o seu ativo mais importante. Ele menciona
o fato de um vice presidente de um empresa americana, da lista das 500 maiores empresas
mencionadas em edições da revista Fortune, comentar que se orgulhava da sua capacidade
para selecionar os recursos para seus projetos. Seu segredo estava no fato de sempre
selecionar aqueles profissionais que estavam mais ocupados naquele específico momento. Por
alguma razão, essas pessoas sempre conseguiam fazer as coisas acontecerem e por isso, seus
serviços eram sempre demandados para novos projetos. Colocações deste tipo nos fazem
refletir sobre a importância da seleção dos melhores recursos humanos para um projeto.
34y ALERIANO, Dalton L., Gerenciamento Estratégico e Administração de Projetos, Makron Books, São Paulo, SP,2001.
35HANS J. Thamhain em CLALAND, David I. Project Management. Strategic Design and Implementation. 3,d. Edition. Singapore: McGraw-Hill, 1999.
36y ALERIANO, Dalton L., Gerenciamento Estratégico e Administração de Projetos, Makron Books, São Paulo, SP,2001.
37 FRAME, J. Davidson, Managing Project in Organizations, How to make the best use oftime, techniques and People, Jossey-Bass Inc. San Francisco, Califomia, 1995.
37
Independentemente de se identificar os recursos para a equipe de projeto dentro da própria
organização ou fora dela, através de contratações, a seleção dos recursos poderá ser feita
através da análise dos Tipos Psicológicos38.
Testes desse tipo, entretanto, podem falhar por não conseguirem medir a inteligência, a
motivação ou a competência técnica dos recursos a serem selecionados. Além do mais, de
acordo com Frame (1995), não é prático confiar cegamente nesses testes para alocar os
recursos a um projeto quando muitos são os fatores - incluindo disponibilidade de pessoal e
problema políticos - que precisam ser levados em consideração ao se lecionar tal equipe.
Na impossibilidade de se encontrar o recurso perfeito para cada projeto, os gerentes de projeto
deverão utilizar uma série de ferramentas para extrair o melhor de cada um dos recursos
disponíveis, através da aplicação de métodos e ferramentas que façam a produtividade da
equipe aumentar.
De acordo com Menezes (2001 )39, existem quatro categorias básicas de profissionais que se
envolvem desde o início do projeto sendo elas: o gerente geral, o gerente funcional, o gerente
de projeto e os especialistas. Cada um deles possui um conjunto de atribuições específicas
sendo elas:
Gerente Geral, é visto como o patrocinador do projeto, cabendo a ele ser o árbitro dos
conflitos que não puderam ser solucionados pelos demais gerentes (funcionais e de projeto).
Ele incentiva o diálogo e a negociação entre as partes. Ele também pode assumir o papel de
Sponsor do projeto.
38 "Carl Yung, o famoso psicanalista suíço se interessou em categorizar as pessoas no que ele chamou de Tipos Psicológicos. Em 1923 ele publicou um trabalho descrevendo esses tipos. Seu trabalho foi melhorado com pesquisa posterior realizada por Katharine C. Bridges, que pegou a teoria Junguiana e a complementou com suas idéias. Por fim, suas idéias foram refinadas por sua filha, Isabel Brigs Myers. O resultado final foi o Indicador de Tipos Myers-Briggs, que é operacionalizado em uma série de testes psicológicos criados para determinar o tipo psicológico de uma pessoa" in FRAME, J. Davidson, Managing Project in Organizations, How to make the best use oftime, techniques and People, Jossey-Bass Inc. San Francisco, California, 1995.
39 MENEZES, Luiz César de Moura, Gestão de Projetos, Atlas, São Paulo, SP, 2001
38
Gerente do Projeto, é o responsável pela sua condução, tendo uma visão integrada do mesmo.
Procura assegurar que os recursos que irão participar de seu projeto estejam disponíveis nas
áreas funcionais e de apoio. Seu poder de influência é limitado, reservado normalmente aos
assuntos da coordenação, à integração das atividades, ao cumprimento dos prazos e ao
cumprimento dos orçamentos, requerendo dele capacidade de relacionamento interpessoal
com todas as pessoas da equipe e da organização.
Gerente Funcional, é o principal responsável pela execução das atividades de sua área
específica de conhecimento. Seu papel é o de amortecer as excessivas demandas sobre os
executantes, procurando distribuir e compartilhar os recursos existentes. Ele absorve parte das
pressões que poderiam recair sobre os seus subordinados, executantes das tarefas.
Especialistas, são aqueles encarregados de executar as tarefas do projeto na área de sua
especialidade técnica.
2.2.1.1 A estrutura da equipe de projeto
o principal objetivo na hora de se definir a estrutura da equipe de projeto é poder obter dela a
maior eficiência possível. De acordo com Menezes (2001), uma estrutura de equipe que
melhor se adapta à estrutura de projetos é a matricial. Esta estrutura é conceituada como uma
forma que permite manter as unidades funcionais, através da criação de relações horizontais
que agilizam a comunicação entre elas· Segundo ele, numa estrutura matricial, identificam-se
baixo nível de formalização, multiplicidade de comando, diversificação elevada e
comunicação horizontal, vertical e diagonal. Sua implantação exige preparo por parte das
pessoas que estarão trabalhando dentro desse tipo de desenho organizacional. Sua implantação
deve ser acompanhada de uma série de ações sobre sistemas de comunicação e sistemas de
tomada de decisão. Uma estrutura matricial também é conhecida como Matricial-Projetos (ou
matriz forte) quando, em geral, é proveniente de uma estrutura organizada por projetos em que
o gerente tem um elevado grau de poder dentro da equipe bem como sobre os gerentes
39
funcionais da organização. Nessas circunstâncias, embora exista um desequilibro de poderes,
fica facilitada a obtenção de resultados para o projeto." 40
Para Frame (1995)41, projetos utilizando a estrutura matricial freqüentemente carregam em si
alguma ineficiência. Por exemplo, a falta de continuidade da equipe de projeto funciona como
um fator desmotivador da equipe, contribuindo para o aumento da falta de comprometimento
desta para com o projeto. Ele identifica também os problemas de comunicação como fatores
que geram ineficiência em um projeto por meio da burocratização das comunicações, à
medida que aumentam os canais de comunicação dentro do projeto, assim como a
comunicação também fica prejudicada pela existência de mensagens truncadas. Por último,
Frame (1995) menciona o fato desse tipo de projeto proporcionar pouca integração entre os
membros da equipe, sendo importante fomentar a criação de mecanismos que propiciem a
integração entre as partes envolvidas.
Uma forma de se estimular a equipe dentro de uma estrutura matricial é através de um sistema
de recompensas. A recompensa pode ser financeira, uma oportunidade de desenvolvimento de
carreira dentro da organização, o simples reconhecimento por um bom trabalho realizado, a
simples satisfação no emprego ou muitos outros valores pessoais tangíveis e intangíveis. Mas
as recompensas para serem verdadeiras dentro de um projeto, deverão estar baseadas em
metas e indicadores que permitam medir o grau de cumprimento dessas mesmas metas. "Nada
é capaz de atrapalhar mais o esforço da mudança organizacional do que o conflito entre os
objetos (metas) e seus indicadores"42.
Frame (1995) ressalta que o sistema de recompensas, em uma estrutura matricial, nem sempre
encoraja a equipe de projeto. Ao invés do sistema de recompensas, Frame (1995) sugere que a
implementação de outras ações como a criação do horário flexível como recompensa pelo
bom trabalho realizado e o esforço extra dedicado ao projeto. Sugere também que se faça o
reconhecimento publicamente do bom trabalho realizado por determinado membro da equipe
40 MENEZES, Luiz César de Moura, Gestão de Projetos, Atlas, São Paulo, SP, 2001 41 FRAME, J. Davidson, Managing Project in Organizations, How to make the best use oftime, techniques and
People, Jossey-Bass Inc. San Francisco, Califomia, 1995. 42THE PRICE W ATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995.
40
e/ou que, ao término do projeto, o gerente escreva cartas de recomendação a serem enviadas
para os supervisores desses membros da equipe tão logo estes retomem a seus postos de
origem, entre outros.
Complementando a análise de Frame (1995), fazemos referência ao mencionado por Menezes
(2001) quando este diz que o sucesso da estrutura matricial em um projeto depende de fatores
intrínsecos à organização como por exemplo, características intangíveis da equipe e seus
membros das quais podemos destacar a capacidade e autoridade por parte dos membros da
equipe, da cooperação das pessoas com o projeto na quantidade certa e no momento adequado
para poder obter os melhores resultados. Da capacidade dos membros da equipe para se
adaptarem a novos grupos pois os projetos são finitos e por vezes as pessoas devem
desempenhar seus papéis em vários projetos simultaneamente. Os membros da equipe devem
também ter capacidade para desempenhar múltiplos papéis haja vista que nos projetos, dentro
de uma estrutura matricial, não são exigidos unicamente conhecimentos que lhes permitam
executar o trabalho mecanicamente mas sim fazer um balanço do trabalho realizado e avaliar
os resultados que estão sendo obtidos. Também devem ter atitude de colaboração pois a
canalização de esforços é fundamental para a obtenção de resultados para o projeto. A equipe
deve ter preferência por abrangência de tarefas pois mesmo sendo composta por especialistas,
o colaborador passa a ter que entender mais da interface de seu trabalho com a de outros
colaboradores, além ser necessário possuir experiência matricial para melhor entender a
distribuição de responsabilidades e poder entender também a autonomia que existe em uma
estrutura desse tipo. Além disso, a equipe do projeto precisa ter habilidade política, pois em
inúmeras circunstâncias são exigidas do participante, e ainda mais do gerente do projeto,
habilidades políticas na negociação de recursos e de prazos rumo à obtenção de resultados.
Deve ter capacidade para suportar ambigüidades pois existem inúmeras subordinações em
estruturas matriciais e isso provoca, especialmente nos executores, muito estresse. Ressalta-se
a capacidade de comunicação para o contato e transmissão de informações sobre o
desenvolvimento e o estado do projeto. E por fim, a liderança deve estar presente na gerência
do projeto para poder fazer o projeto acontecer por meio dessas pessoas.
Vergara (1999) entretanto alerta para o fato de que "a liderança não necessariamente precisa
ser sempre a mesma, ... , é natural que os diferentes membros da equipe assumam a liderança,
41
conforme a tarefa que se lhes coloca,,43. Com esta afirmação, Vergara (1999) reforça o fato do
poder, em uma equipe, necessitar ser compartilhado para garantir a obtenção de melhores
resultados no projeto.
Vergara (1999) ressalta também a importância de se identificar nos membros da equipe,
quando se trabalha em equipes, as seguintes características: a negociação, a humildade
intelectual (reconhecimento de que é preciso aprender sempre), o comportamento ético (que
desestimula uma pessoa a guardar informações fundamentais aos processos de trabalho por
medo de perder o poder e o controle) e o estimulo para avaliar situações em conjunto com os
demais membros da equipe e a buscar formas de corrigir erros, aprender com eles e a
aperfeiçoar acertos.
2.2.1.2 Criando uma identidade para a equipe de projeto
Além de se pensar em como selecionar os membros de uma equipe de projeto, é importante
pensar de que forma se conseguirá criar uma identidade para essa equipe uma vez que ela é
constituída pelos mais distintos tipos de pessoas, com as mais variadas experiências e
conhecimentos.
o que muitas vezes une as pessoas em um projeto é a capacidade que o gerente de projeto tem
de, com sua personalidade e seu especial estilo pessoal ou da experiência que possui em
projetos anteriores, unir o grupo num objetivo comum. Dessa forma, a equipe se sentirá
honrada em trabalhar com essa pessoa.
Frame (1995)44 menciona que dar um nome ao time bem como promover encontros informais
entre os membros da equipe, é uma forma de que todos percebam que não estão trabalhando
sozinhos. Por isso é importante realizar sempre um evento de kick-off do projeto e com
freqüência realizar reuniões para revisão do status do projeto onde cada membro da equipe
43 VERGARA, Sylvia Constant. Gestão de Pessoas. São Paulo: Atlas, 1999. 44FRAME, J. Davidson, Managing Project in Organizations, How to make the best use oftime, techniques and
People, Jossey-Bass Inc. San Francisco, Califomia, 1995.
42
possa comentar suas necessidades, problemas ocorridos, soluções adotadas, bem como entre o
grupo, poderão ser solucionados problemas que individualmente seriam mais diflceis de se
solucionar por si só.
Ter a equipe trabalhando toda junta em um local comum também facilita o processo de
identidade do grupo. Menezes (2001)45 também entende que a existência de um local de
trabalho específico para a equipe de projeto é um fator que deve ser considerado pois,
proporcionando adequado local de trabalho e dispondo de meios e modos para que a
comunicação (formal e, principalmente, a informal) seja favorecida, fará com que a equipe se
sinta bem, fazendo parte de um ambiente de franca cooperação e facilitando assim o processo
de integração da mesma. O resultado obtido quando se favorece o trabalho em equipe, será
medido através de avaliações de desempenho pessoal de cada um dos membros da equipe.
2.2.1.3 Processos motivacionais
A motivação é algo intrínseca ao ser humano e as razões que levam uma pessoa a se motivar
diferem de pessoa para pessoa. Mudanças no ambiente externo do projeto, poderão afetar a
motivação da equipe. Lidar com essas diferenças é uma habilidade que deve possuir um bom
gestor de projetos. Antes de mais nada o gestor precisa aceitar a existência dessas diferenças.
O gestor, como líder do projeto, precisa estar atento a essas mudanças dentro da equipe de
forma a reagir prontamente com ações que garantam a continuidade motivacional da equipe de
projeto.
A motivação está diretamente relacionada ao reconhecimento pelo esforço empreendido em
uma tarefa, um trabalho ou um projeto. Saber dar reconhecimento à equipe pelo trabalho
realizado ou até mesmo dar feedback durante o processo de elaboração do projeto, garante a
continuidade e a qualidade do resultado a ser obtido. É importante fazer com que as pessoas se
orgulhem daquilo que fazem. Portanto, estimular e exigir da equipe e seus membros a busca
por altos padrões qualidade, estipulando altas medidas de desempenho também os estimula a
45 MENEZES, Luiz César de Moura, Gestão de Projetos, Atlas, São Paulo, SP, 2001
43
desenvolver e mostrar todo o seu potencial, funcionando como um fator motivacional para
todo o grupo.
Quando se realiza um determinado trabalho e não se recebe uma recompensa ou se é
reconhecido pelo esforço empreendido, ocorre normalmente um processo de frustração. Para
essa frustração, as pessoas criam mecanismos de defesa que vão desde mecanismos
psicológicos até químicos. Ao contrário, quando ocorre o reconhecimento, ocorre a plenitude,
a liberação de talentos, as pessoas extravasam características pessoais ocultas que não tinham
conhecimento de que as possuíam. Manter as pessoas motivadas não é tarefa fácil. Identificar
que ações ou que circunstâncias fazem com que uma pessoa ou uma equipe se mantenha
motivada, é uma tarefa e um objetivo que deve ser perseguido pelo líder do projeto.
A motivação pode vir através de uma recompensa financeira, pelo simples desejo de sentir-se
competente executando o seu trabalho, pelo fato de saber que está desenvolvendo tarefas e
atividades altamente complexas e desafiadoras, enfim, as motivações são várias e diferem de
pessoa para pessoa. As equipes de projeto são formadas por pessoas as quais são
freqüentemente retiradas das suas rotinas operacionais e levada para formar parte dessa equipe
de projeto, por um determinada período de tempo que, de acordo com a necessidade, poderá
ser curto ou longo ou podem até mesmo participar simultaneamente de vários projetos ao
mesmo tempo. Essa alternância poderá fazer com que elas não se sintam efetivamente parte da
equipe, tenham dificuldade para desenvolver um Team Building. Também poderá fazer com
que se comprometam menos com os resultados do projeto. Se isto ocorrer, irá dificultar
bastante o trabalho do gerente de projeto.
2.2.1.4 Criando uma equipe de projeto de alta performance - uma equipe de sucesso
Cleland (1999) menciona que "uma equipe de sucesso e de alta performance apresenta no seu
cerne uma série de aspectos culturais que representam um diferencial de sucesso em um
projeto. Normalmente se encontra nessas equipes um tipo de performance onde não se
sobressaem os egos, onde seus membros compartilham os mesmo interesses e onde se
44
identifica uma grau de confiança muito elevado entre eles,,46. "Equipes de alta performance
devem desenvolver uma forte confiança entre os seus membros, devem confiar no próximo,
contar com o apoio de todos, confiar no constante compromisso dos demais membros da
equipe e prometer apenas o que pode ser efetivamente entregue,,47.
Thamhain(1999) 48 identifica características chave presentes em uma equipe de sucesso. Essas
características são resumidas na Tabela A - Características de Equipes de Projeto de
Sucesso apresentada a seguir:
Tabela A - Características de Equipes de Projeto de Sucesso
•
Características da Equipe
Alta Performance Os • membros da equipe consistentemente trabalham duro e demonstram um alto • grau de interesse, dedicação e motivação no projeto, junto a seus colegas
• Bem Organizada - Papéis e responsabilidades, autoridade • e fluxo de informação são bem definidos e entendidos por todos. Além disso, existe pouco ou nenhum conflito relacionado com os • procedimentos do projeto e sua administração
• Bem Planejada - O projeto possui objetivos claramente definidos e planos bem estabelecidos assim como, cronogramas, orçamento,. sistemas de monitoramento e reporting
• Boa Interdependência da
Características do Líder da Características dos Membros da Equipe Equipes
Deverá estar confortável com. Deverão ter a habilidade de um ambiente de incertezas rapidamente se adequar às
mudanças Deverá estar orientado à solução de problemas. Deverão ser tolerantes e ter (técnicos, administrativos, de motivação e muita energia cronograma e custos) e deve obter satisfação pela resolução. Deverão ter uma performance desses problemas consistente
Deverá ter uma postura. positiva e a habilidade de demonstrar entusiasmo e. energia
Deverá ter experiência e. conhecimento da organização, do mercado e da tecnologia envolvida no projeto assim como de princípios de gestão, • sistemas e metodologias de gestão de projetos
Deverá ter qualificações suficientes e aplicar seu conhecimento e expertise ao projeto e seus problemas
Deverão ser organizados
Possuir uma visão otimista das coisas
Estar interessados no seu desenvolvimento crescimento pessoal
e
Possuir uma vida pessoal estável
46CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd. Edition. Singapore:
McGraw-Hill, 1999. 47Idem. 48HANS J.Thamhain é professo de Administração no Bentley College em Massachusetts e é o redator do
Capítulo 17 - Trabalhando com Equipes de Projeto, em CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd
. Edition. Singapore: McGraw-Hill, 1999.
45
Características da Equipe Características do Líder da Equipe
Características dos Membros da Equipes
Equipe - Os membros da equipe estão comprometidos com os objetivos do projeto e metas, demonstram um elevado grau de confiança e promovem um ambiente que propicia um bom fluxo de informação e comunicação.
Fonte: J. Tuman, Jr., Success Modeling: A Technique for Building a Winning Project Team, paper apresentado no Seminário/Simpósio do Project Management Institute, Montreal, Canada, Setembro de 1986, p.97.
De acordo com Thamhain (1999t9 um fator de diferenciação para uma equipe de sucesso é o
Team Building50, sendo um processo contínuo que requer qualidades de liderança e
entendimento da organização, suas interfaces, autoridade, estruturas de poder e fatores
motivacionais, crucial em ambientes onde atividades multidisciplinares complexas requerem a
integração de qualificações de muitos especialistas funcionais bem como sustentam grupos
com diversas culturas organizacionais e valores. Antes de 1980, os estudos sobre a dinâmica
de formação de grupos de trabalho e critérios para formação de equipes de alta performance
levavam em consideração apenas o comportamento dos membros da equipe dando atenção
limitada para questões como ambiente organizacional e liderança de equipes. De lá para cá,
esses estudos se aprofundaram em questões como planejamento, treinamento, estrutura
organizacional, natureza e complexidade das tarefas e suporte da gerência sênior entre outros,
passando a serem melhor analisadas.
A criação de equipes de alta performance está intimamente ligada à capacidade dos líderes de
projeto criarem um ambiente que atenda às necessidades da equipe bem como promovam um
ambiente de trabalho e uma cultura dentro da equipe que permita a obtenção dos melhores
resultados dentro do projeto. Isto por, sua vez, vai requerer dos próprios gestores e líderes de
projeto, habilidades cada vez maiores para lidar com este tipo de situação. Eles não
necessitam apenas possuir excelentes qualidades técnicas e boa liderança mas será necessário,
49HANS J. Thamhain é professo de Administração no Bentley College em Massachusetts e é o redator do Capítulo 17 - Trabalhando com Equipes de Projeto, in CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd
• Edition. Singapore: McGraw-Hill, 1999. 50Espírito de equipe para Thamhain pode ser descrito como um processo onde se reúnem uma série de indivíduos
com diferentes necessidades, históricos e experiências a transformá-los em um grupo integrado, em uma força tarefa eficaz.
46
por parte da organização, facilitar o ambiente organizacional adequado para gerenciar essas
equipes de forma eficiente.
Thamhain (1999) menCIOna o fato de hoje, o Team Building ser considerado por muitos
especialistas em gestão de projetos uma das mais críticas características e qualidades
necessárias para a o sucesso de um projeto, dependendo em grande parte não só do esforço
posto na montagem da equipe bem como na integração das atividades dos diversos
especialistas funcionais.
2.2.1.5 A tomada de decisão na equipe
A tomada de decisão dentro de uma equipe de projeto é algo que nem sempre fica muito claro.
As decisões em uma equipe, acabam sendo tomadas por uma série de indivíduos, acaba sendo
algo compartilhado pela própria equipe de acordo com a fase em que o projeto se encontra.
Por exemplo, o início ou não de um projeto normalmente é definido pelo Comitê Executivo
do Projeto. Já decisões durante a fase de planejamento normalmente são realizadas pelas
equipes funcionais, especialistas em temas específicos do projeto. Enquanto que, na fase de
implantação do projeto em si, a tomada de decisões está nas mãos do gerente de projeto.
Delegar responsabilidades e poder em um projeto, entretanto, tem um impacto positivo no seu
próprio andamento. Portanto, na opinião de Cleland (1999), "sempre que as decisões a serem
tomadas individualmente não gerem um impacto maior no orçamento, cronograma e na
utilização dos recursos disponíveis e além disso, se elas não criarem maiores problemas
políticos,,51, poderão ser tomadas pelos especialistas membros da equipe do projeto. Apenas
as questões mais cruciais deverão requer o envolvimento direto do gerente de projeto.
Frame (1995)52 também compartilha dessa opinião e caracteriza esse processo através da
Figura IX - Processo Decisório53 apresentada a seguir:
51CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd. Edition. Singapore:
McGraw-Hill, 1999. 52FRAME, J. Davidson, Managing Project in Organizations, How to make the best use of time, techniques and
People, Jossey-Bass Inc. San Francisco, Califomia, 1995.
2.2.1.6
Especialista da Equipe de Projeto
Haverá mudança significativa
no cronograma?
Não
Haverá mudança significativa
no orçamento?
Não
Haverão desvios significativos nas
especificações originais?
Não
A decisão em questão pode se tornar
um problema político?
Não
Tome a Decisão
Gerente do Projeto
Figura IX - Processo Decisório (Frame(1995»
Conflitos na equipe de projeto
47
Quando um grupo de pessoas se reúne em um projeto, considerando-se as características dessa
equipe - normalmente formada por pessoas das mais diversas especialidades e áreas da
organização - e do processo de sua constituição, o surgimento de conflitos é inevitável. Os
conflitos podem surgir por diversas razões, pela dificuldade de especialistas comunicarem aos
demais membros da equipe, o modo como as coisas deveriam ser feitas, pelo fato de certas
pessoas não quererem ou não gostarem de se relacionar com outras da mesma equipe por
preconceito, ou por outra razão qualquer. Lidar entretanto com esse tipo de conflito é tarefa do
gerente de projeto. "Estudos mostram que o gestor de projetos passa aproximadamente 20%
53Idem.
48
do seu tempo lidando com os conflitos dentro da equipe"s4. É possível entretanto, para o
gerente de projeto, extrair algum tipo de beneficio desse conflito. Através da discussão das
causas desse conflito podem surgir formas alternativas de resolve-los e se poderá aprender de
que forma se trabalhar melhor em equipe.
De acordo com Cleland (1999), o próprio conflito ajuda a desenvolver uma cultura dentro da
equipe na qual existe uma motivação em se trabalhar juntos na busca do consenso. O conflito
por sua vez, ajuda a equipe a se acostumar com o habitual e dinâmico andamento do projeto e
com as demandas que são impostas pelos Steakholders do projeto.
Algumas das típicas causas de conflitos são, de acordo com Cleland (1999), a competição
pelos recursos disponíveis, a não compreensão dos papéis a serem desempenhados
individualmente e coletivamente pela equipe de projeto, a discordância quanto aos objetivos,
metas e estratégias do projeto bem como a quebra de etiqueta e protocolo pelos membros da
equipe. Existem também os preconceitos pessoais, éticos e morais ou atitudes que
comprometem ou quebram o bom relacionamento interpessoal. A falta de entendimento do
sistema e metodologia de gerenciamento do projeto que está sendo usada como referência para
o projeto em andamento também influencia significativamente o bom andamento deste e
potencializa o surgimento de conflitos. A não concordância ou inexistência de sistema de
recompensas e promoções para os bons resultados obtidos no projeto também gera conflitos
entre os membros da equipe. A falta ou precariedade dos canais de comunicação bem como a
falta de entendimento da estrutura matricial da organização são mais alguns dos fatores que
tipicamente propiciam o surgimento de conflitos nos projetos.
O surgimento do conflito normalmente gera frustração ou um profundo sentimento de
insegurança e insatisfação principalmente quando este não é solucionado. Quando não
resolvido, as pessoas tendem a se preocupar com os caminhos que esse conflito possa tomar.
Mesmo no momento em que uma solução para o conflito é encontrada, sempre fica um
resíduo emocional no ar pois as pessoas nem sempre conseguem esquecer ou perdoar as
54K.W. Thomas and W.H Schmidt, "A Survey of Managerial Interests with Respect to Conflict", Academy of Management Joumal, 10, 1976, pp.315-318 em CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd
• Edition. Singapore: McGraw-Hill, 1999.
49
questões que levaram ao conflito. Pinto e Kharbanda (1995)55 sugerem alguns modos de
solucionar ou tratar os conflitos e eles devem ser avaliados e implementados pelo gestor do
projeto. São eles evitar o conflito ignorando as causas de sua existência permitindo que ele
continue sob circunstâncias controláveis. Não prestar atenção ao conflito, limitar a sua
interação no conflito ou apenas separar fisicamente os causadores do conflito. Deixar esfriar,
ou seja, dar tempo ao tempo até que as partes envolvidas consigam tratar o conflito de uma
forma mais racional. Confrontação através de encontros frente a frente com os envolvidos no
conflito para um "acerto de contas" ou "lavagem de roupa suja". Cada um dos métodos
acima deverá ser utilizado de acordo com a circunstância apresentadas em cada projeto. Sua
opinião é que o envolvimento da alta gerencia do projeto nestas questões não deve ser
freqüente pois normalmente ela não está inteiramente a par dos detalhes que geraram o
conflito, valendo a pena deixar a equipe, que está mais envolvida, funcionar como um
intermediador na busca da solução para esse conflito.
2.2.1.7 A desmobilização da equipe
A desmobilização da equipe consiste no retomo das pessoas às suas áreas funcionais de
origem, quando os recursos são internos à organização ou o encerramento de contratos, com a
conseqüente dispensa da equipe alocada ao projeto para que esta possa ser realocada a outros
projetos, quando os recursos são externos. Sendo tanto os recursos internos como externos,
faz parte do processo de encerramento a elaboração de relatórios de desempenho e a
comunicação ifeed back) aos membros da equipe do projeto do desempenho obtido durante o
mesmo. Esta etapa às vezes é dificil pois gera muita ansiedade e expectativa nos membros da
equipe quanto ao seu futuro e possível realocação nas áreas de origem ou em novos projetos,
devendo o gestor do projeto ser muito cauteloso e estar muito atento às reações da equipe
nesse momento. Quando o processo de encerramento ocorre em etapas, é necessário ter
cuidado adicional para que as atividades remanescentes a serem desempenhadas sejam
concluídas e para que a equipe que permanece não perca o interessa por elas.
55 JEFFREY K. Pinto e OM P. Kharbanda, "Project Management and Conflict Resolution", Project Management Joumal, Dezembro de 1995, pp. 45-54
50
Outras situações que podem ocorrer segundo Cleland (1999), são a perda da identidade da
equipe, o medo pela possibilidade de não ser novamente integrado no local de origem ou a um
novo projeto, entre outras. A seguir, apresentamos na Figura X - Detalhamento da estrutura
de problemas mais comuns do encerramento de um projeto, onde Cleland (1999) resume
esses problemas.
Figura X - Detalhamento da estrutura de problemas mais comuns do encerramento de
um projeto
I
Problemas da Tenninação de Projetos
I I
I Emocionais I I Intelectuais I I Equipe I
• Medo de não ter trabalhos futuros
• Perda do interesses nas atividades remanescentes
• Perda da motivação no projeto
• Perda de identidade da equipe
• Metodologia de realocação de pessoas
• Divisão de esforços
• Seleção dos recursos a serem realocados
I Cliente I • Mudança de atitude
• Perda de interesse no projeto
• Indisponibilidade de pessoas chave
I Internos I • Identificação dos
produtos restantes a serem entregues
• Controle dos custos do projeto
• Encerramento de ordens de trabalho ou pacotes de trabalho (tarefas remanescentes)
• Recompilação da documentação do projeto
I Externos I • Acordos com o cliente
sobre produtos pendentes de serem concluidos
• Comunicação do encerramento do projeto à organização e fornecedores externos
• Fechamento das instalações fisicas do projeto
De acordo com Valeriano (1998), esse processo deve ser feito "com critério, sem traumas nem
ressentimentos a fim de não prejudicar formações futuras de equipes.,,56
Durante o processo de encerramento do projeto e desmobilização da equipe, normalmente
ocorrem os chamados learning meetings 57, ou encontros de aprendizado, como são chamadas
as reuniões que ocorrem durante o encerramento do projeto e cujo objetivo é avaliar
56 V ALERIANO, Dalton L., Gerenciamento Estratégico e Administração de Projetos, Makron Books, São Paulo, SP,2001.
57 MENEZES, Luiz César de Moura, Gestão de Projetos, Atlas, São Paulo, SP, 2001
51
permanentemente o aprendizado obtido com o mesmo. Nelas são analisados os erros
cometidos, por exemplo, no gerenciamento do projeto, no cumprimento dos prazos e dos
custos do projeto, na qualidade, escopo e os riscos pelos quais passou o projeto. Também são
propostos planos de ação para a eliminação de situações insatisfatórias que tenham ocorrido
no projeto. Essas reuniões são importantes, de acordo com Menezes (200 I), para que possam
ser analisados os erros e os acertos cometidos e cada fase do projeto. Não são eventos fáceis
pois costumam haver "ataques" por parte dos membros da equipe como uma forma de defesa
para possíveis erros cometidos. Alternativamente, é possível a aplicação de questionários ao
invés de reuniões. Essas reuniões são úteis não só durante o próprio projeto como também
para evitar que se cometam os mesmo erros em projetos futuros.
2.2.2 Liderança
Até agora discutimos a formação da equipe de projeto e as responsabilidades do gerente de
projeto na gestão dessa equipe. Entretanto, o processo de montagem da equipe e do
desenvolvimento de um Team Building vai requerer do gerente do projeto capacidades que
vão além das tradicionalmente necessárias para a gestão de um projeto. Passaremos agora a
discutir como a questão da liderança influencia na gestão de pessoas e de equipes e a sua
influência nos resultados dos projetos. Como a variável Liderança irá funcionar como
diferencial de sucesso.
2.2.2.1 Principais características da Liderança
Existem uma série de definições para a palavra liderança. Entretanto, o Professor Thamhain
(1999) 58 ressaltou que, em se referindo à questão gestão de projetos, um líder precisa possuir
atributos e habilidades em 3 áreas específicas, sendo elas: relações interpessoais, qualidades
técnicas e administrativas.
58HANS J. Thamhain, "Deve1oping Project Management Skills", Project Management Joumal, September 1991, pagina 39-44.
52
Enquanto alguns estudiosos tratam a questão da liderança referindo-se à figura de um líder
como um super herói, outros vêem a liderança como sendo uma questão de características
pessoais que um indivíduo possui, ou seja, características como carisma, inteligência, energia,
estilo, comprometimento, entre outras. Líderes são pessoas que possuem habilidades para
promover mudanças não só em indivíduos bem como em grupos de pessoas ou nas próprias
organizações. A característica de liderança fica mais ressaltada no momento em que as
pessoas e a organizações apresentam resistência à mudança proposta, fazendo com que seja
dada mais ênfase na liderança democrática e participativa.
De acordo com McGregor (1960)59, existem quatro características que estão diretamente
relacionadas com a questão da liderança e delas dependerá a performance alcançada pelo líder
do projeto. As características pessoais do próprio líder, as atitudes, necessidades e outras
características pessoais dos seus seguidores (membros da equipe, etc.), as próprias
características da organização como por exemplo, seus objetivos como empresa, a sua
estrutura organizacional e a natureza das tarefas a serem desenvolvidas e o ambiente social,
econômico e político no qual o projeto está inserido. Olhando por este aspecto, podemos
perceber que "a questão da liderança, não é uma questão de propriedade de um indivíduo
específico e sim uma complexa inter-relação de variáveis,,6o
Outro enfoque que pode ser dado para explicar a questão liderança, são os tipos de
comportamento dos lideres tratados pela Teoria dos Estilos de Liderança61 . Esses
comportamentos podem ser Ditatorial, Autocrático, Democrático e Laissez-faire.
O líder Ditatorial62 é aquele que consegue que o trabalho seja realizado pela pressão e pela
imposição e o medo.
O líder Autocrático é aquele que centraliza as decisões na sua pessoa, não se interessa, por
exemplo, no feedback da equipe de projeto. Embora ele possa manter uma política de portas
59DOUGLAS McGregor, the Human Side ofEnterprise, New York: McGraw-Hill, 1960 6°Idem. 61YERGARA, Sylvia Constant. Gestão de Pessoas. São Paulo: Atlas, 1999. 62CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd
. Edition. Singapore: McGraw-Hill,1999.
53
abertas e escutar todas as opiniões da equipe, ele não as utiliza na sua tomada de decisão.
Frame (1995)63é de opinião que se formos analisar este estilo, "vendo pelo lado positivo, o
estilo autocrático é apropriado em um projeto rotineiro, de baixo risco, aonde a equipe
simplesmente tem a função de executar as tarefas exatamente como especificado ... quando
decisão rápidas são necessárias e, uma vez que os autocratas não estão preocupados em obter
o consenso da equipe nem em reunir uma quantidade suficiente de informações para basear as
suas decisões, eles mesmos podem decidir rapidamente,,64.
o líder Laissez-faire é aquele que atribui ao grupo a responsabilidade de estabelecer as suas
próprias metas e tomar as suas próprias decisões. O estilo Laissez-faire poderá ser eficaz em
um projeto onde o estado da arte impera, onde os gerentes necessitam deixar a equipe criar.
Em equipes que não podem ou não gostam de estar sob constante supervisão esse estilo
produz resultados bastante satisfatórios, entretanto esse estilo de liderança poderá ser um total
fiasco quando se requer uma rápida tomada de decisão.
O líder Democrático é aquele que descentraliza o processo decisório e "busca o input da
equipe para a tomada de decisão ... o qual aumenta o comprometimento da equipe na execução
das decisões tomadas uma vez que ela mesma participou do processo decisório".65
O estilo democrático é mais permissivo, busca consenso e participação da equipe, está mais
centrado nas pessoas enquanto que o estilo autocrático está mais centrado nas tarefas, sendo
este mais restritivo e socialmente distante. Cada uma destas características apresenta pontos
positivos e negativos. Enquanto os estilos democrático e o laissez-faire tendem a manter o
grupo coeso, eles não necessariamente garantem o aumento da produtividade enquanto o
autoritário sim. Entretanto este tende a desmotivar a equipe. Em resumo, não é uma tarefa
fácil manter um equilíbrio desses dois fatores.
63FRAME, J. Davidson, Managing Project in Organizations, How to make the best use of time, techniques and People, Jossey-Bass Inc. San Francisco, Califomia, 1995.
64Idem. 65 FRAME, J. Davidson, Managing Project in Organizations, How to make the best use oftime, techniques and
People, Jossey-Bass Inc. San Francisco, Califomia, 1995.
54
Estabelecer quais devem ser as características de um verdadeiro líder em um projeto, não é
realmente uma tarefa simples, entretanto, algumas características se mostraram, ao longo do
tempo e após diversos estudiosos analisarem e compararem os estilos de liderança de diversos
gestores de projetos, reincidentes e valem a pena ser mencionadas.
São elas, por exemplo, a ambição pessoal do líder e que o leva a obter o sucesso
simultaneamente à conquista do sucesso da sua empresa, ou seja, coincidem ambos objetivos,
os da empresa e os seus objetivos pessoais. Os líderes estão presentes para suas equipes e
ninguém duvida de quem está no comando, eles escutam, debatem, e estão prontos a executar
o que tiver que ser feito para alcançar os objetivos. O verdadeiro líder identifica e premia os
vencedores, evita fazer ou tomar as coisas complexas, é justo e paciente, humano ... pois
reconhece que é líder apenas porque seus subordinados assim o permitem manter-se no papel
de líder e trabalha duro para garantir os recursos necessários para que o projeto alcance os
resultados esperados.
Em um projeto, o líder deve estar consciente e atento para o fato de que ele deverá se
relacionar não só com seus superiores bem como com seus subordinados e pares e com todo o
resto da organização. Além disso, precisa estar atento a fatores como duração do projeto,
cronograma, metas, disponibilidade de recursos, entre outros. Acima de tudo ele, como líder,
precisa ser flexível e possuir a capacidade de se adaptar a diversos cenários e circunstâncias e
principalmente deverá estar atento e perceptivo às necessidades de seus liderados uma vez que
seu comportamento e sua performance, por tabela, também afeta a equipe liderada por ele.
2.2.2.2 Liderança e Poder
Existe uma linha tênue entre liderança e poder. Segundo Vergara (1999) 66, no mundo atual,
uma nova forma de ver e lidar com o poder se faz necessária, o que implica mudanças nos
modelos mentais. O mundo atual está a exigir o compartilhamento assumido e construtivo do
66 VERGARA, Sylvia Constant. Gestão de Pessoas. São Paulo: Atlas, 1999.
55
poder. Compartilhar poder é mais do que delegar. O gestor amplia seu poder quando libera as
pessoas para serem o que elas podem ser.
Nos dias de hoje, a palavra que mais se aproxima do conceito de compartilhamento de poder é
empowerment, um processo no qual se criam condições e habilitam-se as pessoas de todos os
níveis da empresa para assumirem responsabilidades na satisfação de seus clientes.
Compartilhar poder significa abrir-se para o diálogo.
2.2.2.3 Diferença entre gerentes de Projetos e Líderes
Frame (1995) comenta que se perguntassem a cada gerente de projeto quaIs as suas
responsabilidades, ele provavelmente responderia que são: "executar o trabalho no prazo,
dentro do orçamento e de acordo com as especificações. Mas é claro que as atribuições de um
gerente de projeto vão além disso. Ele também é responsável pelo desenvolvimento da equipe,
serve de intermediário entre a alta administração e a equipe de projeto e transmite à
organização as lições aprendidas durante o projeto,,67.
A gerencia de projeto é uma atividade muito mais ampla. Um gerente de projeto possui muito
mais atribuições e responsabilidades do que somente liderar. Já a liderar, é parte da gestão de
projetos. Por sua vez, enquanto de um gerente se espera que faça o planejamento e organize as
tarefas do projeto, garantindo a sua execução, de um líder se espera que ele faça os outros o
seguirem. "Liderança é a habilidade de persuadir o grupo a perseguir os objetivos traçados
com entusiasmo. É o fator humano que reúne o grupo e o motiva para alcançar os objetivos
estabelecidos. Atividades gerenciais são casulos adormecidos até o momento em que o poder
da motivação guia as pessoas em direção aos objetivos.,,68 Pode-se dizer que um gerente faria
as coisas bem feitas (com eficiência) enquanto um líder faria a coisa certa (com eficácia).
Entretanto, gestores de projetos não podem ser apenas gestores, eles precisam ser também
líderes.
67FRAME, 1. Davidson, Managing Project in Organizations, How to make the best use of time, techniques and People, Jossey-Bass Inc. San Francisco, California, 1995.
68KEITH Davis, Human Relations at Work, 3rd ed. New York, McGraw-Hill, 1967
56
De acordo com Cleland (1999)69, podemos resumir na Tabela B - Principais diferenças
entre Gerentes e Líderes, a seguir, as principais características que diferenciam gerentes de
líderes de projetos:
Tabela B - Principais diferenças entre Gerentes e Líderes
•
•
•
•
Gerentes Colabora com o desenho, desenvolvimento e • operacionalização dos sistemas que irão suportar o projeto.
Mantém o controle sobre a eficiência e a eficácia • dos recursos utilizados no projeto e os sistemas de controle que suportam o uso desses recursos.
Desenha e executa as operações de planejamento, • organização e controle do projeto.
Preocupa-se com a eficiência no uso dos recursos • do projeto.
Líderes Encontra ou desenvolve uma visão de futuro para o projeto e a vende para a equipe de projeto e os demais Stakeholder.
Constrói uma rede de interesses com os Stakeholders, desenvolvendo estratégias que garantam o seu apoio ao projeto.
Dá o direcionamento geral ao projeto.
Promove condições necessárias à volta do projeto que motivam e garantem o comprometimento dos Stakeholders com o projeto.
• Mantém os Stakeholders informados do. Toma-se um símbolo do projeto e seus objetivos. progresso ou atraso do projeto.
• Realoca recursos onde necessário para garantir o • suporte à equipe de projeto.
• Assegura o bom funcionamento do sistema de • comunicação utilizado no projeto.
Constrói um ambiente de suporte político para o projeto entre os Stakeholders.
Mantém constante preocupação com o uso eficiente dos recursos do projeto.
• Provê monitoramento, treinamento e outros. É capaz de tomar decisões. meios que permitam o desenvolvimento individual e coletivo das competências necessárias à equipe do projeto.
• Fonte: CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd
• Edition. Singapore: McGraw-Hill, 1999
Nem todas as características mencionadas acima serão encontradas em um gestor de projetos
mas quantas mais dessas características ele possuir, maior probabilidade haverá de que o
projeto alcance os objetivos esperados quando da sua conclusão.
69CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd• Edition. Singapore:
McGraw-Hill, 1999.
57
2.2.2.4 A liderança como diferencial na Gestão de Projetos
De acordo com Cleland (1999), o fator que impulsiona a equipe de projeto e no limite
determina qual projeto irá falhar ou irá obter sucesso, é a liderança implícita no projeto em
todos os níveis da organização. Quando um projeto está em processo de implantação, a chave
para fazer com que ele aconteça é a qualidade da sua Liderança.
Quando um líder possui uma visão ampliada do projeto, ele se antecipa identificando as
possíveis necessidades de recursos para o projeto, provê inspiração e motivação para a equipe.
Trabalha e organiza o projeto de forma a que os objetivos de tempo, escopo e custo sejam
satisfatoriamente alcançados ao término do projeto.
Warren Banis em seus estudos, identificou certas competências de liderança que fazem
substancial diferença quando identificadas em gestores de projetos. Para ele, o gerente precisa
ser capaz de gerenciar a atenção da equipe. Com isso, ele quer dizer que os lideres de sucesso
tem a capacidade de atrair a atenção da equipe em relação ao objetivo do projeto. Devem
possui a capacidade de visualizar e principalmente transmitir essa visão e envolver as pessoas
com os objetivos do projeto. O gerente de projeto precisará também ser capaz de dar um
sentido ao projeto e correlacioná-lo com os objetivos estratégicos da empresa. Isso quer dizer
dar um sentido, uma razão ao projeto. Dessa forma, não só ficará mais fácil para a
organização aceitar e "comprar" esse projeto como também para a equipe de projeto.
Confiança é outra característica que deverá estar presente nos gestores de projetos. Ele deverá
transmitir confiança pois nele também será depositada a confiança da organização bem como
a confiança da equipe de projeto. Essa confiança poderá ser transmitida através do
estabelecimento, por ele, de altas medidas de performance as quais espera que sejam atingidas
pela equipe de projeto que, estimulada, reaja a essa solicitação prontamente.
Mas acima de tudo, tanto gestor quanto equipe necessitam demonstrar estar comprometidos
com os resultados estabelecidos para o projeto. E por fim, outra característica importante dos
gestores, é ser capaz de gerenciar a si mesmos. Manter-se motivado e demonstrar motivação e
58
comprometimento com os resultados do projeto é crítico. Como diz Bennis (1984) "Como
médicos incompetentes, gerentes incompetentes podem até tomar a vida pior do que ela já é,
podem fazer as pessoas ficarem doentes ... alguns gerentes provocam ataques cardíacos e crises
nervosas a si mesmos e o que é pior, nos membros de suas equipes,,7o. Erros podem ser
cometidos mas os verdadeiros líderes aprendem com eles e rapidamente recomeçam
novamente.
Como mencionado por Bennis (1984), em projetos onde são encontrados líderes, as pessoas se
sentem parte do um todo, cada uma faz diferença no sucesso do projeto ou da organização. O
aprendizado e a competência fazem a diferença, não existem erros mas sim a aceitação desses
erros e o aprendizado que se obtém através deles. As pessoas fazem parte do conjunto, como
uma grande família e o trabalho se toma excitante, estimulante, desafiador e principalmente
divertido.
2.2.2.5 Algumas competências para um Líder de Projeto
Além de todas as características já mencionadas Bennis (1984) adiciona ainda que um líder de
projeto deve entender a tecnologia envolvida no projeto. Mas a que nível de profundidade
alguns podem se perguntar, o suficiente para fazer as perguntas certas e avaliar se as respostas
dadas apresentam ou não coerência. Se um grau mais profundo de conhecimento for
necessário, o líder de projeto deverá se valer da ajuda dos especialistas que, com certeza,
fazem parte da equipe de projeto. Deverá ter conhecimento do processo de gestão ou seja, ter
conhecimentos e experiência básica em cargos de gerencia. Ter noções de planejamento,
organização de tarefas, técnicas motivacionais, direção e controle bem como a habilidade para
visualizar o contexto do sistema a ser implantado dentro da estratégia do projeto. Um projeto
é composto de um seqüênciamento de subprojetos e atividades e uma alteração, atraso ou
problema ocorrido em um desses subprojetos, irá afetar os demais. Ao identificar problemas,
o gestor de projetos precisa saber tomar decisões dentro do contexto do projeto. Necessita
saber coletar dados suficientes para poder avaliar as possíveis decisões e implementá-las.
70 WARREN Bennis, "Good Managers and Good Leaders", Across the Board, October 1984.
59
Precisa saber considerar meios alternativos para atingir os objetivos do projeto e entregar
produtos que agreguem valor para os clientes, traduzidos em produtos, processos ou serviços.
Deverá sempre ter uma atitude positiva, nas horas boas e principalmente nas horas más do
projeto. Precisa saber estimular a equipe e os Stakeholders, enfim, ser o mentor da equipe, seu
professor, seu coacher. Às vezes ele acaba por fazer mais o papel de facilitador, trabalhando
focado na equipe e nos Stakeholders para alcançar os resultados.
É necessário ter habilidade para assumir riscos na gestão do projeto. Quanto mais complexo o
projeto, maior é o seu risco. É importante identificar dentro do projeto aqueles membros na
equipe capazes de avaliar e mensurar apropriadamente o risco bem como trabalhar com
especialistas em desenhar estratégias que reduzam esse risco. Deve ser persistente porém
tendo o cuidado de não gerar um abismo entre a realidade e o sonho.
Um gestor de projeto deverá possuir atributos favoráveis ao relacionamento interpessoal que o
tomem capaz de não só selecionar a equipe de projeto, bem como trabalhar com esta e os
demais Stakeholders do projeto, estabelecendo uma cultura de comprometimento, lealdade,
respeito, confiança e dedicação. Deverá ter a capacidade de trabalhar através e com pessoas,
ganhando delas a confiança e o suporte em todas as circunstâncias do projeto. Um dos fatores
que causam a maior parte das falhas dos gerentes de projeto é o fato deles não possuírem
habilidades de relacionamento interpessoal.
o sucesso de um projeto, dependente em grande grau da interatividade entre equipe de
projeto, Stakeholders e a Organização. Muitas vezes a rede de relacionamentos existente na
organização é uma variável que conta quando se necessita ter algo feito e vai muitas vezes
além da autoridade do gestor de projetos. No inicio do projeto, o líder de projeto dedica uma
boa parte do seu tempo além do planejamento, à criação de uma rede de relacionamentos,
identificando pessoas que ele entenda que possam ser úteis em algum momento do projeto
para fazer as coisas acontecerem. Estas atividades estão ligadas também a atividades de
Change Management, especificamente no mapeamento dos Stakeholders, tema que será
tratado com mais detalhes na seção 2.5.
60
Por fim, a habilidade mais esperada de um gestor e líder de projetos, é a capacidade de
produzir resultados atingindo os objetivos propostos no tempo, dentro do custo e dentro do
escopo.
A pessoa que gerencia um projeto necessita ser simultaneamente, um bom líder e um bom
gerente, reunindo o maior número de características mencionada até aqui.
Cleland (1999) em seu livr07l comenta que em um encontro de gerentes seniores experientes
em gestão de projetos de uma empresa de sistemas, nove participantes foram solicitados a
escrever em palavras ou frases, as características que eles observaram em bons líderes de
projetos com os quais eles se depararam durante suas carreiras. Outros 8 desses mesmos
gerentes foram solicitados em seguida, a comentar as características observadas em maus
líderes de projetos. Os resultados dessa análise apresentamos na Tabela C - Análise
comparativa entre Bons e Maus Líderes a seguir:
Tabela C - Análise comparativa entre Bons e Maus Líderes
Bons Líderes de Projetos Maus Líderes de Projetos
• Possuem atitude positiva. • Se utilizam do cargo e da autoridade para orientar a equipe.
• Possuem interesse nos aspectos pessoais dos • membros da equipe.
• Antecipam-se aos problemas antes de que eles se • tomarem evidentes.
• Comunicam claramente a visão de futuro que o • projeto necessita alcançar e comunicam essa visão para a equipe envolvida no projeto, permitindo que esta faça contribuições para o alcance dos objetivos.
Não aceitam sugestões e/ou rejeitam sugestões não politicamente corretas.
Mudam o direcionamento do projeto e/ou o escopo pela sua própria vontade culpando os outros pelo que foi feito de errado.
Não pedem ajuda, não dão o exemplo e desconhecem os aspectos técnicos do processo.
• São também gerentes orientados a resultados. • Não parabenizam, apenas criticam. Não sabem dar os parabéns por um trabalho bem feito.
• Orientam seus subordinados no direcionamento. Não transmitem a visão de futuro e não explica o do trabalho permitindo o seu crescimento focado porque.
71CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd. Edition. Singapore:
McGraw-Hill, 1999.
61
Bons Lideres de Projetos Maus Líderes de Projetos
em objetivos.
• Exercem o papel de mentor e não de mestre. • Não se posicionam com relação aos problemas quando eles surgem.
•
•
Escutam sugestões e idéias dos seus subordinados • membros da equipe.
Pedem sugestões e idéias sobre como solucionar • problemas.
Não escutam novas idéias, não sabe com o fazer críticas construtivas. Esperam a perfeição.
Estão pouco interessado nas pessoas.
• Enfatizam o trabalho em equipe. • São completamente focados na autopromoção.
• São sensíveis ao efeito que certas decisões • provocam na equipe envolvida com o projeto.
• Reconhecem as contribuições individuais e as do grupo.
• Saem do escritório e vão ao campo acompanham o projeto in loco.
• Permitem aos seus subordinados a participação em subprojetos de sua escolha.
Se comunicam com a equipe utilizado termos negativos, gritando e gesticulando.
Fonte: CLALAND, David I. Project Management. Strategic Design and Implementation. 3,d. Edition. Singapore: McGraw-Hill, 1999
Vergara (1999) em seu livro "Gestão de Pessoas"n descreve resume uma lista de ações que
um gestor pode fazer para provocar a motivação das pessoas. Curiosamente, a maioria dessas
ações estão diretamente relacionadas com as características às quais os gerentes seniores e
experientes gerentes de projeto apontaram como características dos bons lideres. Isso reforça o
fato de que procurar ter atitudes como aquelas as mencionadas pelos experientes gestores de
projetos, realmente faz uma grande diferença durante a implantação de um projeto ou na
realização de um trabalho.
Complementando o que foi mencionado anteriormente, adicionamos algumas outras
características de líderes de projeto mencionada por Vergara (1999) 73:
72 VERGARA, Sylvia Constant. Gestão de Pessoas. São Paulo: Atlas, 1999. 73 Idem.
62
• Reconhecer o trabalho realizado. Às vezes basta um simples parabéns;
• Explicitar as recompensas individuais e as grupais oferecidas pela empresa em um
processo de reconhecimento pelo esforço despendido;
• Aceitar as possibilidades e os limites das pessoas. Todos nós, indistintamente, temos
forças e fraquezas;
• Compartilhar autoridade. As pessoas tem a tendência de delegar tarefas sem compartilhar
a autoridade necessária para a sua realização, desprezando assim a força do
comprometimento embutida na autoridade. Comprometimento funciona como
cumplicidade na busca e na realização dos objetivos empresariais;
• Permitir que as pessoas errem e incentivá-las a aprenderem com os erros. A questão
crucial não é errar mas insistir no erro;
• Respeitar o tempo das pessoas;
• Educar, sobre tudo dando o exemplo. O exemplo é, indubitavelmente, a forma mais eficaz
de educar;
• Nunca constranger uma pessoa na frente da outra. Isso dói muito, humilha e fere a auto
estima.
• Dar às pessoas o direto de expressar os seus sentimentos.
• Fazer com que o discurso corresponda a uma ação. Quando as palavras correm para um
lado e as ações para outro, o que se transmite é incoerência, desconfiança e insegurança.
63
2.3 A Mudança, o Change Management e algumas considerações sobre Cultura
Organizacional
Nas seções anteriores foram apresentadas conceituações relativas a Project Management,
sistemas de ERP e foi apresentado um típico projeto de implantação de sistemas de ERP. Foi
também discutida a importância da formação da equipe de projeto e foram apresentados temas
relacionados com a questão da Liderança relacionadas aos gestores de projetos. Nesta Seção
vamos fazer uma revisão sobre a Mudança, os fundamentos da metodologia de Change
Management e faremos também algumas considerações sobre a Cultura Organizacional das
empresas e dos projetos.
2.3.1 Identificando os fatores motivadores da Mudança
A globalização e tudo o que ela trás consigo, tem provocado, não só nas sociedades como
também nas organizações modernas, grandes mudanças. As organizações têm procurado se
preparar para um novo ambiente onde a concorrência e a constante busca pela produtividade
as têm levado a dedicar grandes esforços no sentido adaptar suas estruturas organizacionais e
mecanismos de produção às novas demandas. O domínio da informação representa, cada vez
mais, uma nova forma de poder. Aquele que detém a informação, possui uma vantagem
competitiva. Para isso, as empresas se interligam, em todo o mundo, através de redes e cabos,
para dominar a informação e conquistar uma eficiência cada vez maior. A organização
moderna, ganhou uma enorme eficiência com a inovação tecnológica. A implantação de novos
sistemas de gestão como os sistemas de ERP- Enterprise Resource Planning, tomou-se uma
prática comum nas grandes organizações como variável na garantia de um diferencial
competitivo. Para as empresas serem bem sucedidas diante dessa realidade, necessitam de
sistemas de informação flexíveis, capazes de atender àquilo que o mercado determina em
tempos compatíveis com a velocidade em que o negócio muda. Esta é a justificativa para a
proliferação de sistemas de ERP a partir da década de 90. Cada vez com mais freqüência,
pacotes de software como soluções integradas são vistos pelas empresas como a resposta às
suas necessidades de informatização por diversos fatores. Dentre esses fatores, podemos
destacar a redução do tamanho e do custo da área de informática pela uniformização de
64
ambientes de processamento e terceirização do desenvolvimento e manutenção de sistemas
informáticos, a descentralização do processamento das informações e da redução da
dependência do CP074.
Também, a necessidade de simplificação das funções contábeis, financeiras, fiscais,
administrativas e de confecção de relatórios gerenciais bem como a necessidade de reduzir
custos operacionais necessários e o desejo de manter os processos e gestão do negócio sob
controle bem como o abastecimento das áreas de vendas, de compras e de assistência técnica
são outros fatores que favoreceram a proliferação de sistemas de solução integrada.
Evitar duplicidades, assegurar sinergias e gerar indicadores que permitam avaliar melhor o
desempenho do negócio, assim como o desejo de padronizar procedimentos e tecnologias nas
diversas unidades de negócio da organização e de suas filiais em diversos países, pela
utilização de um mesmo sistema de informação que suportasse as operações da empresa em
todos esses locais, facilitando assim o atendimento das exigências de seus principais clientes
na troca de informações e pedidos bem como na simplificação do processo de obtenção de
informações e na utilização dos mesmos sistemas de informação que eles. E mais do que tudo,
ser pioneiro na utilização de novas tecnologias, ou aplicar tecnologia similar àquela utilizada
por seus principais concorrentes.
Esta tendência se consolidou a partir do início dos anos 90, suportada pela disponibilidade
cada vez maior de produtos desta natureza (para todos os tipos de aplicações, plataformas de
hardware e ambientes operacionais e capacidades de investimento) e pela pressão crescente
para a redução de custos, necessidade de rapidez na resposta às demandas de diversas áreas de
negócio e seus usuários e pela incorporação de Best Practices aos sistemas de informação
comercializados.
2.3.1.1 Como a mudança na estrutura organizacional vem sendo tratada pelos
estudiosos
74 CPD - Centro de Processamento de Dados
65
De acordo com a Prof. Fisher (2002), a escola de administração científica (Taylor e Ford),
genericamente considerada o berço do surgimento da administração como teoria, dá um
tratamento superficial e desinteressado ao tema "Mudança Organizacional". Esta linha de
pensamento tem uma visão mecanicista, onde as peças de uma engrenagem são substituídas
ou racionalmente alteradas para apresentarem um desempenho o mais próximo possível do
esperado. Ou seja, ações de mudança consistem em alterar a configuração de processos de
trabalho com o objetivo de aumentar a sua racionalidade. Elas são tratadas como um projeto
específico.
Já a escola de Relações Humanas (Mayo ; McGregor), muda "o foco da gestão para as pessoas
e suas relações com o ambiente organizacional, contrapondo-se à visão mecanicista, tendo
sido enriquecida com o surgimento da abordagem sócio-técnica que compatibiliza os
determinantes técnicos do trabalho com a configuração das relações sociais, a qual possibilita
a criação de técnicas e métodos inovadores de gerenciamento da mudança, baseada em
conhecimentos adquiridos sobre a dinâmica dos pequenos grupos - Team Building (Escola de
Desenvolvimento Organizacional). Seu mérito está em associar o conceito de mudança ao
conceito de desenvolvimento, removendo, em parte, as características negativas - de crise e
conflito, o caos dificil de ser administrado - que o conceito carregava em sua origem,,75.
Mas foi na década de 70 e 80, que o avanço tecnológico, a competitividade e o novo
comportamento dos consumidores, fatores externos à organização, motivaram o
redirecionamento estratégico das empresas, levando-as a mudanças organizacionais, que
exerceram um papel determinante nos fatores motivadores da mudança. Esta, passou a ser
vista como uma estratégia empresarial, provocando profundas transformações organizacionais
e obrigando as organizações empresariais a reverem os seus modelos de gestão pois as
empresas deixaram de viver processos nos quais as mudanças não eram apenas lineares e
incrementais mas abrangentes e transformadoras pois não afetavam apenas algumas áreas
organizacionais mas sim os seus processos como um todo.
75 Mudança e Transformação Orghanizacional, Prof. Dra. Rosa Maria Fisher - Mudando os Paradigmas da Mudança.
66
"Impressionados com a amplitude desses processos de mudança, alguns autores dos anos 70 e
80 conceituaram-nos como Mudanças de Larga Escala definindo-as como uma transformação
durável no caráter organizacional que altera significativamente a performance da
organização,,76. Quando falam deste caráter organizacional, conforme demonstrado na Figura
XI - Caráter Organizacional, os autores desta linha de pensamento estão se referindo ao que
se poderia denominar de "Características Genéticas da organização: a natureza dos produtos
ou serviços que justificam a sua existência; os processos produtivos que adotam para realizá
los assim como os procedimentos administrativos e práticas gerenciais com que conduzem
tais atividades, a distribuição de responsabilidades, os critérios de integração, coordenação e
diferenciação com os quais determinam os padrões de relações internas; os canais de
relacionamento que estabelecem com o ambiente em que estão inseridas, com os Stakeholders
com os quais interagem e com as comunidades sociais que estão em seu entorno,,77.
Cartiter Ol1lt:m;t.llc;onlll Caracterlsticas Geneticas tia OrgallizaçiJo
I I I Produtos Processo Práticas e Serviços Produtivos Gerenciais
Atribuições e Relações com Responsabilidades Stakeholders
Figura XI - Caráter Organizacional
Considerando todos estes aspectos, constata-se que a mudança organizacional não poder ser
encarda como uma projeto isolado que ocorre esporadicamente no cotidiano organizacional.
Sendo tão abrangente, profunda e multidimensional, a mudança necessita ser conceituada,
concebida e gerenciada como um processo de transformação contínuo. A transformação
organizacional, como um dos processos organizacionais, está diretamente relacionada à
76LA WER I1I, E.E. et aI.. The Phenomenon ofLarge Scale Organizational Change. In Lawer III E.E. (org.) Large Scale Organizational Change. San Francisco. CA. Jossey-Bass Inc. 1989.
77Mudança e Transformação Organizacional, Prof. Dra. Rosa Maria Fisher - Mudando os Paradigmas da Mudança.
67
dinâmica de funcionamento de uma organização bem como às suas estratégias de ação. Ela
funciona como um processo contínuo de aprimoramento de seus sistemas, processos, políticas
e práticas de gestão, entre outros e deve ser gerenciada e modelada com instrumentos que
asseguram a sua intemalização por todos os níveis e esferas da organização.
2.3.2 O que é Change Management
Com o aumento dos processos de mudança ocorridos nas empresas, a partir dos anos 90,
muito passou a se estudar sobre este tema. Da primeira onda de projetos que envolviam
mudanças de alguma forma, sejam essas mudanças de processos ou de sistemas, muito se
pode aprender sobre os erros e acertos desse processo.
De acordo com a equipe de consultores da PWC, o Change Management é o processo de
gerenciamento da transição em qualquer tipo de projeto que envolva alguma forma de
mudança, objetivando reduzir resistências e obter o maior comprometimento por parte dos
envolvidos de alguma maneira com essa mudança. A equipe de Change Management tem a
responsabilidade de captar dentro da organização e da equipe de projeto, quais as percepções
dos seus membros quanto às mudanças tratadas pelo projeto. E durante todo o período do
projeto, implementar ações e atividades que tem como objetivo reduzir as barreiras desses
indivíduos às mudanças propostas no decorrer do projeto.
Se a mudança for gerenciada, ela será implementada com mais sucesso gerando menos
desespero nos envolvidos.
o Change Management aborda as seguintes atividades durante o projeto:
• Identificar e gerenciar os Stakeholders;
• Elaborar o Plano de Comunicação;
68
• Transferir habilidades e conhecimento através da implementação do Plano de
Treinamento contemplando habilidades e conhecimentos técnicos trazidos pelo projeto;
• Dar apoio e suporte à gerencia do projeto na identificação dos perfil dos recursos
necessários para o projeto, na seleção desses mesmos recursos e na integração da equipe
do projeto; e
• Acompanhar a liderança do projeto durante o seu desenvolvimento.
2.3.2.1 Fator Mudança
Nem todas as mudanças provocadas pela implantação de um projeto são facilmente aceitas
pela organização principalmente porque esses projetos alteraram a forma como cada indivíduo
está acostumado a se relacionar com o seu trabalho e as suas rotinas diárias. Alterar esse status
quo, na maior parte das vezes, provoca fortes movimentos de resistência à mudança. Os
fatores são muitos mas podemos dizer que o medo das mudança, da perda que virá com ela,
são as principais razões que geram resistência.
A equipe de Change Integration78 da Price Waterhouse79, elaborou um trabalho consolidando
uma série de observações relativas a experiências adquiridas durante a implantação de
projetos relacionadas ao processo de mudança enfrentado pelas organizações nas quais
implantou, entre outros, sistemas de ERP. Como resultado desse trabalho, codificaram uma
série de situações que se repetiam em seus projetos e que valem a pena ser analisadas e
consideradas como material de análise neste trabalho, sendo importante levá-las em
consideração quando se tiver interesse em garantir o sucesso de projetos de mudança como
por exemplo, um projeto de implementação de sistemas de ERP.
O primeiro deles diz respeito à aceitação do fato de que as empresas nos dias de hoje não são
imutáveis, a mudança é uma constante e que o fato das organizações estarem constantemente
buscando maior produtividade, faz com que internamente suas estruturas sejam
78THE PRICE W A TERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for Transforming your Organization. USA: Irwin Professional Publishing, 1995.
79 Antes da fusão com a Coopers & Lybrand
69
freqüentemente remodeladas e ajustadas às novas necessidades do negócio, modificando
assim processos e implantando novas ferramentas de trabalho e de gestão.
A preparação do terreno para a mudança se inicia buscando consenso dentro da organização.
Normalmente este processo se inicia com a alta administração e, em seguida, baixa-se para o
escalão inferior da companhia. Se a alta administração der o exemplo com o seu
comprometimento com o projeto, obter o mesmo comprometimento das demais esferas da
organização se toma uma tarefa mais fácil.
A mudança deve estar sustentada por uma gestão forte. A alta administração deverá estar
comprometida e profundamente envolvida nos projetos internos devendo dar apoio ao líder do
projeto fazendo ver ao resto da organização o quanto este ou aquele projeto é prioritário e
quanto esforço as diversas áreas da empresa deverão concentrar nessa empreitada. Deverá
procurar medir e melhorar o desempenho das áreas mais importantes da organização definindo
o escopo de atuação dessas áreas pois a mudança trazida com o projeto, fará com que seja
necessário rever o atual sistema de avaliação de desempenho da organização.
Dentro de toda organização formam-se grupos de interesse, interesses esses que nem sempre
são compartilhados por todas as áreas da organização. Se esses grupos não estiverem
comprometidos com a mudança, poderão representar um sério obstáculo para o sucesso do
projeto. É importante mapear o terreno identificando quem são esses grupos e quais os seus
motivos para apoiarem ou não o projeto para então definir uma estratégia de ação sobre esses
grupos (mapeamento dos Stakeholders).
A organização necessita não só concentrar esforços aonde o retomo for maior, bem como
precisa definir suas prioridades. Não tentar implantar simultaneamente milhares de projetos
que afetam profundamente a organização sob a pena de terem não só esses projetos mas
também a performance da organização prejudicada.
Com a implantação, por exemplo, de um projeto de ERP, áreas que antes pouco se
relacionavam entre si, passam a ser obrigadas a se comunicar pois os processos antes
executados individualmente, claramente passam a se interrelacionar fazendo com que cada
70
vez mais cada uma das áreas da organização dependam umas das outras. Portanto, a
capacidade que a organização, seus altos executivos e seus multiplicadores tiverem para
aceitar a mudança, será a chave do sucesso na implantação de um sistema de ERP nessa
organização. Essa mudança precisa e deve ser gerenciada e para isso são estabelecidos
Projetos de Mudança. Se a organização deixar o cliente (interno e externo) conduzir a
mudança, se eles perceberem que a mudança trazida pelo projeto vem ao encontro das suas
necessidades, eles serão os primeiros a conduzir a própria mudança.
A comunicação feita à organização e àqueles envolvidos direta ou indiretamente com o
projeto é fundamental para que o projeto dê certo. Em um projeto de implantação de um
sistema de ERP por exemplo, a comunicação, à medida que as mudanças ocorrem, deve ser
uma constante. As mudanças que surgem com os projetos alteram o status quo da empresa,
permitindo mostrar onde estão os velhos problemas e revelar aonde podem estar as novas
soluções. Incentivar a equipe a pensar grande e a inovar, a externar suas idéias é importante.
Novas tecnologias e ferramentas de gestão requerem pessoas mais qualificadas para manuseá
las, tirando delas o maior proveito possível portanto, investir no capital humano, desenvolver
habilidades nos recursos da organização, em todos os níveis, principalmente daqueles que
estão na linha de frente do projeto, é fundamental.
E acima de tudo, é necessário planejar a mudança detalhadamente através da elaboração de
um plano de ação detalhado, registrando as mudanças de processos, de sistemas, de pessoas e
necessidades de treinamento.
2.3.2.2 Um projeto de mudança e o processo de Change Management
o processo de Change Management é constituído por uma série de etapas começando pela
identificação das necessidades de mudança. "Um projeto de mudança é constituído
basicamente por uma justificativa poderosamente persuasiva em favor das modificações a que
71
se propõe. Deve trazer consigo um senso de urgência e deve estimular as pessoas a agirem"so.
Como por exemplo, em uma organização, a identificação da necessidade da troca de sistemas
não integrados por sistemas de sistema de ERP como conseqüência da necessidade de
melhorar os processos da organização ou melhorar a produtividade. Em seguida, é necessário
preparar o terreno para uma mudança dessa magnitude. Preparar a cabeça da organização e
fazê-la ver que uma mudança como essa é necessária. "Um terreno bem preparado para a
mudança apresenta uma proposta clara e persuasiva do direcionamento estratégico juntamente
com as medidas específicas de suporte"Sl. Em paralelo à criação de uma equipe de projeto
para a implantação de um sistema de ERP, deverá se criar uma equipe de Change
Management. Essa equipe será responsável pela gestão da mudança originada pelo projeto
dentro da organização.
2.3.2.3 Identificação dos Stakeholders
o apoio dos grupos de interesse (Stakeholders) é o maior obstáculo que se entrepõe entre o
um projeto de mudança na teoria e o que efetivamente na prática está sendo implementado.
Motivar pessoas para que defendam o projeto como se fosse delas, não é uma tarefa fácil
principalmente em função do número de pessoas envolvidas no projeto e, principalmente, se
houver um histórico de fracasso em projetos ocorridos anteriormente na organização.
Identificar os Stakeholderi2, seus desejos e necessidades é uma atribuição da equipe de
Change Management e é uma condição necessária para garantir o seu compromisso com
relação à mudança trazida pelo projeto. Desta forma, na fase inicial do projeto, é importante
identificar um conjunto inicial de pessoas envolvidas no projeto (os Stakeholders), procurando
compreender como elas percebem a mudança proposta pelo projeto. Esses Stakeholders
podem ser empregados, acionistas, diretores e gerentes, eles podem ser inclusive fornecedores
SOTHE PRICE WATERHOUSE CHANGE INTEGRATION TEAM. Better Change: Best Practices for Transforrning your Organization. USA: Irwin Professional Publishing, 1995.
slIdem. S2Stakeholder pode ser entendido como indivíduo ou grupo que em algum momento durante o ciclo de mudança,
afetarão ou serão afetados pelo processo de mudança (estes poderão ser entendidos como: empregados, clientes, acionistas, fornecedores e outros parceiros de negócio) in THE PRICE WATERHOUSE CHANGE
72
e clientes. Será importante identificar aqueles que apostam na mudança bem como aqueles
que serão mais ou menos afetados pela mudança, pois dependendo do grau que a mudança
proposta pelo projeto venha a afetar esses Stakeholders, eles terão uma postura positiva ou
negativa para com o projeto. A equipe da PWC sugere a utilização da matriz abaixo para
mapear os Stakeholders. A lista de Stakeholders pode ser dividida em dois grandes grupos,
conforme ilustrado na Figura XII - Mapeamento do apoio dos Stakeholders com
referência à mudança pretendida, a seguir:
...... ..10_"__ AlIo p ............
Figura XII - Mapeamento do apoio dos Stakeholders com referência à mudança pretendidas3
•
Em primeiro lugar, é necessário entender os objetivos e características dos Stakeholders.
Existem duas classes de Stakeholders. Aqueles que apoiam a mudança e os são motivados
pela mudança. Os primeiros, poderão se transformar em agentes de mudança e irão buscar e
lutar por obter o compromisso de toda a organização. Os segundos, expressarão suas
percepções negativas, ficarão distantes e tentarão minar os projetos. Existe ainda o grupo de
pessoas que já participou de projetos semelhantes, entretanto mal executados e mal sucedidos
e que se mostram contra os demais projetos. Essas pessoas precisarão ser trabalhadas,
preparadas para aceitas o projeto.
INTEGRA TION TEAM. Better Change: Best Practices for Transforming your Organization. USA: Irwin Professional Publishing, 1995.
8\n THE PRICE W A TERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for Transforrning your Organization)
73
Será necessário identificar cada um dos Stakeholders de acordo com o alto ou baixo impacto
em que as mudanças contempladas em um projeto o afetarão e o quanto se avalia que eles o
apoiarão quanto às mudanças pretendidas pelo projeto. Como base nesse mapeamento,
deverão ser pensadas ações para trazer e comprometer esses Stakeholders com o projeto e
acompanhar os resultados e a evolução dessas ações.
À medida que o projeto avança, a equipe de projeto irá i~entificar as barreiras que
provavelmente irão interferir na velocidade e no andamento do projeto. O grau de esforço
necessário para romper essas barreiras será considerável. Quanto mais rápido se identificar
junto aos Stakeholders quais são essas barreiras, mais rapidamente o projeto irá para a frente.
Uma técnica valorizada é a de fazer pressão contínua ignorando algumas dessas barreiras.
Entretanto, é conveniente manter-se um certo limite político e de preferência, com sustentação
do patrocinador, para não criar mais resistências e barreiras na organização. A melhor forma
de garantir o apoio é envolver um executivo chave para cada processo envolvido no projeto de
forma a exercer influencia junto aos demais membros da organização.
Para que tudo isso possa surtir resultados, "o gestor de um projeto de mudança deverá
procurar estar assessorado por uma equipe altamente credenciada e respeitada dentro da
empresa, para que o acesso a esses grupos e sua influencia sobre eles possa ser considerável"s4
2.3.2.4 A comunicação
O processo de mudança deve ser difundido por toda a empresa. Desde a alta administração até
o funcionário de menor nível hierárquico. Deve ser bem comunicado, com franqueza, através
de canais formais e informais, pois um empregado não modificará seu comportamento
enquanto a administração não prometer honestamente melhorar a situação e comunicar
convincentemente que o projeto de mudança que está a caminho é parte da solução para esse
próprio indivíduo. A credibilidade é a base da comunicação eficiente devendo-se evitar a
84 THE PRICE W ATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for Transforming your Organization. USA: Irwin Professional Publishing, 1995. Pág.73
74
disseminação de informações enganosas, independente de interesses políticos ou operacionais,
sob o risco de denegrir a imagem e confiança no processo de comunicação do projeto. As
melhores mensagens são simples e diretas. "É sensato avaliar o grau de confiança que os
interessados depositam nos patrocinadores e nos líderes executivos do projeto. Se a
credibilidade for baixa, a estratégia de comunicação deve ser mais voltada para o exemplo do
que para as palavras. As ações devem ser cuidadosamente selecionadas, visando sustentar a
mensagem que se pretende transmitir e demonstrar que a administração age conforme prega.
Empregados precisam sentir confiança na administração, porém, o exemplo e não as palavras
é que é a base de tudO.,,85
Nada de segredos. Na maior parte das vezes, os segredos resultam em comprometimento da
verdade e resultam na "diminuição do compromisso e da motivação do interessados".86 A
rádio corredor é uma realidade e se não for bem administrada poderá minar o projeto.
Entretanto, será possível se valer da radio corredor se através dela for transmitida a mensagem
do que a empresa está fazendo e o que pretende fazer. "Comunicação é a sombra por trás de
tudo o que se faz no processo de transformação: não é o primeiro elemento que existe na
mente de uma pessoa, mas não se pode ir a lugar nenhum sem ela. Comunicação é
fundamental na produção da mudança.,,87
Um programa de comunicação bem formulado deve dirigir-se para as preocupações das
pessoas envolvidas de alguma forma com o projeto, comunicar o progresso conseguido,
sustentando o entusiasmo das pessoas da equipe de projeto e da organização. O programa
precisa transmitir uma mensagem clara, com conteúdo e que focalize a lógica da mudança.
85 THE PRICE WATERHOUSE CHANGE INTEGRATION TEAM. Betler Change: Best Practices for Transforming your Organization. USA: Irwin Professional Publishing, 1995. Pág. 98
86 "Um fabricante de video-games descobriu a futilidade de guardar segredos ao planejar demissões. A administração ameaçou processar qualquer membro da equipe de planejamento que deixasse vazar qualquer tipo de informação. Todas as reuniões eram encerradas com uma sessão de destruição de papéis, visando minimizar a possibilidade de exposição acidental. Quando as demissões foram finalmente anunciadas, todos ficaram boquiabertos aos saber que os empregados já sabiam de tudo havia muito tempo - incluindo detalhes, como nome e quantidade de empregados a ser demitidos! No final, a administração saiu perdendo por três motivos: causou estresse desnecessário a seus membros, perdeu credibilidade junto à força de trabalho, que se inteirou das notícias indiretamente, e qualquer beneficio relacionado à oportunidade da divulgação foi perdido." In THE PRICE WATERHOUSE CHANGE INTEGRATION TEAM. Better Change: Best Practicesfor Transformingyour Organization. USA: Irwin Professional Publishing, 1995, Pág. 100
87 THE PRICE W ATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for Transforming your Organization. USA: Irwin Professional Publishing, 1995.Pág. 94
75
É importante entretanto, entender que "a eficiência da comunicação está intimamente
relacionada à cultura organizacional de empresa. 88
Existem algumas qualidades para a elaboração de um plano de comunicação eficiente sendo
elas honestidade, apresentação do panorama geral juntamente com a relevância do projeto
para a organização, a adoção por parte da empresa de uma postura construtiva, a garantia de
uma consistência verbal, escrita e de comportamento e a garantia da continuidade, reforçando
constantemente o compromisso com a iniciativa de mudança.
2.3.2.5 A formação da equipe e o Change Management
A contribuição da equipe de Change Management na formação da equipe de projeto está
relacionada com o acompanhamento da definição da estrutura do projeto, da formação do
comitê gestor do projeto e no monitoramento constante do cliente dentro do comitê.
Adicionalmente, ela apoia o gestor na definição do perfil dos recursos necessários para a
equipe, procurando-os dentro da própria organização, com aderência ao perfil definido, com o
conhecimento técnico ou do negócio necessários para participar da equipe de projeto, pela
duração deste. Ela ajudará também a definir a quantidade de recursos necessária.
Em seguida, a equipe de Change Management coordena o processo de integração dos
membros selecionados à equipe do projeto. Sua participação vai desde o convite à
88 "quando uma grande fabricante de brinquedos decidiu introduzir laptops para assistir a força de vendas no desenvolvimento de pedidos planejados, vendedores muito experientes acharam que a administração estava pretendendo alterar a sua maneira de trabalhar. Para se livrar da resistência e da negatividade que provavelmente surgiram, o presidente da empresa decidiu transformar a entrega dos laptops em um evento, associando-o à feira anual de brinquedos, a exposição mais importante do setor. Os vendedores ficaram encantados com a demonstração do sistema, A participação nessa demonstração fez com que cada vendedor recebesse um botton com os dizeres: EU VI FUNCIONANDO ! Os que concordaram em experimentar a ferramenta nova e fazer a encomenda de uma unidade recebiam outro botton que dizia: ADOREI! Em muitos outros ambientes essa abordagem poderia ter parecido banal, para essa força de vendas em particular, funcionou". In THE PRICE WATERHOUSE CHANGE INTEGRATION TEAM. Better Change: Best Practicesfor Transforming your Organization. USA: Irwin Professional Publishing, 1995. Pág. 99
76
confirmação da aderência deste perfil às necessidade iniciais, continuando com os eventos de
integração até o final do projeto.
Os eventos mais comuns realizados pela equipe de Change Management são o Kick OjJ, onde
a equipe participa do primeiro evento de integração, bem como eventos de integração
periódicos. Ela deverá participar também da fase de encerramento fazendo o acompanhamento
do desligamento da equipe de projeto.
2.3.2.6 Outras considerações sobre liderança e a formação da equipe de projeto
Embora estes temas já tenham sido bastante analisados em seções anteriores, aonde
analisamos detalhadamente cada um desses conceitos e revisamos a bibliografia existente
sobre o tema, complementamos sua análise fazendo referencia a questões comentadas
especificamente pelos especialistas em Change Management da Price Waterhouse, como
resultado de sua análise de projetos de mudança.
Em projetos de implantação de sistema de ERP, que envolvem uma grande mudança, é
necessário que os gestores possuam habilidades e experiência compatíveis com a tarefa em
questão. "A habilidade política é um requisito básico, vindo em seguida uma certa
combinação de inteligência, experiência, formação e pulso firme. Os lideres da mudança
escolhidos precisarão ser capazes de estudar as linhas de processo, ser profissionais com seu
foco bastante voltado para o cliente, ... , deverão ser capazes de perceber problemas e
oportunidades de maneira singular. Respeitarão o fato de que as decisões tomadas por eles
afetarão a sorte de toda a empresa mas sabem que esse impacto não deverá impedi-los de
tomar tal decisão nem deverá tomá-los egocêntricos" 89. Identificar, designar e conservar um
time de gerentes de primeira classe é vital - mas não menos crítico do que a estrutura da
equipe do projeto em si.
89 THE PRICE W A TERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for Transforming your Organization. USA: Irwin Professional Publishing, 1995. Pág. 34.
77
Desta forma, a formação da equipe deve levar em consideração a qualidade e formação do
grupo de trabalho pois "a implantação de mudanças abrangentes requer combinação de
habilidades técnicas, influencia interna, e estilos pessoais"90. Além disso, é necessário pensar
que poderá ser preciso mudar a equipe de trabalho ao longo do projeto, dependendo de
necessidades ou habilidades específicas que se façam necessárias. A própria duração do
projeto faz com que por vezes a troca seja uma questão relevante visto que normalmente esses
projetos tem duração superior a 1 ano. É comum a troca de membros da equipe de
implantação embora não seja recomendável mudanças constantes uma vez que se perde um
pouco a continuidade do projeto.
Com relação à composição dos membros da equipe, os especialistas da Price Waterhouse
comentam que ela poderá contar também com membros internos da organização desde que "a
maioria da equipe seja formada por indivíduos respeitados na organização. Consultores
podem ser úteis, mas não devem dominar o grupO,,91. A consultoria trás a experiência
adquirida em outros projetos mas a equipe interna da organização é fundamental para garantir
a aceitação do projeto e das mudanças trazidas por este dentro da organização. "Quando o
grupo é formado inteiramente por pessoas de fora, os Stakeholders tendem a perceber a
mudança como algo imposto ao invés de uma iniciativa que brotou a partir dos conhecimentos
internos e das necessidades organizacionais - e nesse caso, estão pouco propensos aceitá-Ia,,92.
A equipe formada por membros do cliente patrocinador do projeto deverá ser logo posta a
trabalhar e, de preferência, em um local novo, longe de seus antigos locais de trabalho e do
ambiente ao qual estavam acostumados. Isso fortalecerá os laços da equipe, favorecendo o
processo de integração entre os membros e diminuirá o vínculo de lealdade com a
organização, que normalmente durante o projeto tenderá a atrapalhar o andamento do trabalho
uma vez que essas pessoas não conseguem desvincular as necessidades do projeto dos
interesses da organização. Essa distância facilita o processo de implantação e estabelece o
foco nas necessidades do projeto.
90 Idem Pág. 165 91 THE PRICE WATERHOUSE CHANGE INTEGRATION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995. Pág 169 92 THE PRICE W ATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995. Idem. Pág. 35
78
Os membros da equipe tanto interna como externa93, deverão ser encorajados a pensar
abertamente e sugerir. Constantemente pensar "E se ... ". É importante dar a chance à equipe
de projeto de propor inovações de processos e de métodos de trabalho entre outros.
Estabelecer metas de desempenho agressivas para a equipe de projeto possibilita melhores
resultados. As pessoas se sentem mais motivadas quando se vêem diante de uma meta
desafiadora.
A equipe da Price Waterhouse propõe uma estrutura de projeto ideal para a administração de
projetos de mudança complexa e multifuncional e a chamou de "Estrutura de Equipe Peso
Pesado,,94, conforme demonstrada na Figura XIII - Estrutura de Equipe Peso Pesado, a
seguir:
Figura XIII - Estrutura da Equipe Peso Pesado 9S
Nela, o gerente de projeto "é um profissional de nível sênior, um indivíduo bem respeitado.
Essa pessoa é liberada da estrutura funcional e se reporta diretamente ao responsável pelo
projeto".96
93 Equipe externa considerada com a equipe de consultores externos. 94. Idem. Pág. 35 95 THE PRICE W ATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995. Idem Pág. 170
79
Outro aspecto importante na formação de equipes internas é a delegação de poderes, ou seja,
"a criação de um ambiente em que os empregados da organização, de todos os níveis, sintam
que exercem influência verdadeira sobre os padrões de qualidade e eficácia de negócios,
dentro de suas áreas de responsabilidade,,97. Todos os empregados envolvidos no processo de
mudança que participam do projeto, tem poder para influenciar na qualidade dos produtos e
processos da organização. Os membros da equipe necessitam ter este conceito claro dentro do
processo de Change Management. A delegação de poderes aos membros da equipe, por sua
vez, provoca mudanças de comportamento uma vez que o indivíduo passa a se sentir
fortalecido pela responsabilidade que lhe foi atribuída.
2.3.2.7 Problemas mais comuns encontrados em um projeto de mudança
Todo projeto precisa ter uma vós de comando da mudança, ou seja, um líder, um responsável
que tem a responsabilidade de integrar projeto e as mudanças e inseri-las na mente das
pessoas e da organização. Se essa pessoa não estiver completamente envolvida e
comprometida, o sucesso do projeto poderá estar comprometido. Essa vós de comando deve
possuir todo o suporte da alta administração.
É importante analisar também um outro aspecto, as pessoas tendem a encarar as mudanças em
nível pessoal e por essa razão resistem ainda mais a elas. É portanto necessário, o mais rápido
possível, comunicá-las das vitórias ou beneficios que estas terão acesso como resultado das
mudanças propostas. Se elas conseguirem rapidamente visualizar esse ganho, deixarão de
constituir-se numa barreira resultando assim num grande ganho para o projeto.
A falta de definição de prioridades bem como fazer de tudo uma prioridade são causas que
levam um projeto ao fracasso bem como a existência de projetos concorrentes como
Qualidade Total, Reengenharia entre outros, e a omissão da alta administração em conciliar e
integrar projetos concorrentes entre si, poderá levar ao desperdício de recursos financeiros e
humanos bem como de tempo precioso da equipe e da organização. "A energia e lealdade de
96 Idem Pág. 169 97 Idem Pág. 121
80
profissionais valiosos que competem uns com os outros, com o objetivo de manter sua área de
influência e/ou seus programas, constituí-se em um desperdício. A destruição causada por
batalhas dessa natureza, pode ser tão prejudicial que nenhum outro projeto atinge o resultado
pretendido,,98.
Um participante de uma conferência realizada na Harvard Business School, sobre
"administração de Negócios em Transformação" analisou que a própria existência de esforços
múltiplos é uma problemática para a empresa, muitas vezes eles são conflitantes entre si e
confusos além de mal compreendidos pelos empregados. Neste caso, faz-se necessário um
agente de mudança experiente para priorizar as metas, racionalizar atividades e tomar
decisões, mesmo que essas decisões sejam dificeis. "Deve-se trabalhar para garantir que os
melhores recursos sejam canalizados para os melhores projetos em prol da empresa como um
todo,,99 delegando responsabilidades aos demais líderes de projetos não só para que assumam
a liderança dentro do seu campo de domínio como também na missão mais ampla de integrar
esforços.
Adicionalmente, "a omissão em formar uma equipe talentosa e diversificada que represente
todos os interesses, é a causa do fracasso de muitos projetos. Equipes eficientes na condução
da mudança devem ser formadas por conhecidos inovadores e não pessoas comuns"IOO.
Devem ter diversidade de estilo e formação mas, acima de tudo, devem ter disposição para
cooperar. Treinar essa equipe, dedicar-lhe tempo e prepará-la para que esta assuma um papel
de integrador de esforço em seus projetos bem como em outros projetos que, por ventura,
possam estar em curso na organização.
Obter o apoio de grupos de pessoas envolvidas de alguma forma com a mudança trazida pelo
projeto, é um dos principais obstáculos para o sucesso de um projeto. Os próprios
Stakeholders se desmotivam a determinada altura do projeto. Existem algumas ferramentas e
métodos, que foram identificados e desenvolvidos no decorrer de projetos que procuram
98THE PRICE WATERHOUSE CHANGE INTEGRATION TEAM. Better Change: Best Practices for Transforming your Organization. USA: Irwin Professional Publishing, 1995. Pág. 39
99 idem Pág. 147 100 THE PRICE W ATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for
Transforming your Organization. USA: Irwin Professional Publishing, 1995. Idem Pág. 42
81
facilitar esse processo de motivação e o envolvimento dos Stakeholders. Um dos maIS
comuns, é a formação de grupos de discussão. Eles farão com que os interessados contribuam
para o processo de mudança pessoalmente. Nesse momento será possível identificar mudanças
de postura em relação ao projeto ou seja, os pró-ativos poderão se tomar à medida que o
projeto avança, em reativos e vice versa.
Foi mencionado anteriormente o problema que surge quando os envolvidos assumem uma
postura pessoal em relação às mudanças. Nesse caso, uma das possíveis soluções é
transformar o membro problemático em um multiplicador, ou seja, atribuir-lhe a
responsabilidade por mais 3 ou 4 pessoas do grupo, com a responsabilidade de que ele se
relacione com eles e divulgue o projeto de mudança, pois os indivíduos motivados, adotam
uma postura pró-ativa e geram um efeito multiplicador.
A paciência é outra ferramenta que deve estar presente em todos os projetos. Em um projeto
de mudança, é necessário dedicar tempo e atenção aos Stakeholders, eliminando neles os
possíveis focos de ansiedade que poderão surgir com o decorrer do projeto. Para evitar a
inércia, é importante manter sempre ativos os canais de comunicação. Manter as pessoas da
equipe e os multiplicadores envolvidos. Convidá-los para se engajar em tarefas do projeto, em
ações que se façam necessárias durante o processo é outra possibilidade. À medida que um
projeto de mudança avança, as pessoas experimentam algo parecido com a dinâmica da curva
de mudança. Essa curva apresenta 6 estágios pelos quais passa uma pessoa envolvida em um
processo de mudança. A primeira fase é a da Pré Conscientização, fase na qual surge a
sensação de que algo precisa ser feito mas não se sabe exatamente o quê. Em seguida, vem a
fase da Conscientização onde se identifica que as mudanças são necessárias mas ainda não se
sabe como e aonde se quer chegar. A terceira fase, a da Preocupação Pessoal, é a fase onde os
detalhes da mudança passam a ser conhecidos e é quando surge a verdadeira preocupação:
"como é que isto vai me afetar?" Em algum ponto entre o auto questionamento e a busca de
soluções, começa o processo de aceitação. A quarta fase, a de Tentativa Mental, é quando se
nota que as mudanças começam a ser percebidas como inevitáveis, quando se tenta imaginar
como a mudança pode funcionar a seu favor. A quinta fase, a das Mãos à Obra, a fase dos
82
pilotos. O ponto sem retomo surge entre esta e a fase seguinte, a sexta fase, onde ocorre a
Aceitação e o novo ambiente é aceito e implantado"lOl. No início, este processo requer um
esforço maior da equipe de projeto e da equipe de Change Management. "O verdadeiro
indicador de aceitação é o momento em que as pessoas mudam o modo de realizar seus
trabalhos e os resultados mensuráveis são atingidos,,102.
No caso da perda ou redução do envolvimento e do interesse, por parte dos envolvidos no
projeto, durante a evolução, o que pode ocorrer e normalmente ocorre em projeto de maior
duração é que não se deve fingir que não houve uma queda no entusiasmo da organização ou
da própria equipe. É importante trazer novamente o Stakeholder para dentro do processo,
envolvendo-o novamente nas atividades do projeto montando novamente grupos de discussão.
Nesse momento é importante procurar saber o que os membros da equipe e da organização
acham. A equipe da PWC sugere nesse caso que se crie um "terremoto" 103 , ou seja, que se
comunique algo na empresa que faça com que as pessoas acordem para a situação atual. As
atividades de Change Management em um projeto devem ser vistas como um investimento a
longo prazo pois o retomo dessas ações poderá levar mais tempo do que o previsto para surtir
o resultado esperado não são resultados que possam facilmente ser percebidos no curtíssimo
prazo.
101 THE PRICE W ATERHOUSE CHANGE INTEGRA TION TEAM. Better Change: Best Practices for Transforming your Organization. USA: Irwin Professional Publishing, 1995.
102 Idem Pág. 86 103 Terremoto neste caso refere-se à criação de um problema maior que procure abalar o status quo e trazer
novamente as pessoas à realidade, fazendo com que elas "despertem" da situação anterior.
83
2.3.3 Considerações sobre a Cultura Organizacional
Apesar do emprego de modernas técnicas de gestão de projetos e todo o enfoque dado à
questão da liderança, da formação de equipes e a questões relacionadas a Change
Management, temos observado que grande parte dos projetos de implantação de sistemas de
ERP, desde o seu boom na década de 90, não obtiveram o sucesso esperado.
Algumas das possíveis razões para tal fato possam ser a má aplicação da metodologia, ou até
mesmo o fato das próprias organizações não estarem ou não se terem preparado para a
mudança que tais implantações trazem para os processos, políticas e as práticas de gestão da
Organização como um todo. Ou até mesmo porque as consultorias contratadas para gerir o
projeto não tenham sido capazes gerenciá-lo bem. Adicionalmente, observamos que o
processo de mudança envolvido em um projeto de implantação de um sistema de ERP nem
sempre leva em consideração algo tão importante dentro de uma organização como a sua
Cultura.
Transformar e modernizar uma organização com a implantação de um sistema ERP, mesmo
utilizando as técnicas do Project Management, não garante o sucesso dessa implantação se a
própria organização não encontrar o modo mais adequado de como mudar e o que mudar.
"Este como mudar, é próprio das especificidades de cada organização e do desejo de mudança
expresso em seus objetivos estratégicos. Por isso, o como mudar passa, necessariamente, pelo
desenvolvimento das pessoas, pela capacidade que elas tenham para compreender e
internalizar os valores da mudança, transformando-os em práticas organizacionais que
concretizem o desejo de transformação" 104. Organizações mais reativas a processos de
transformação organizacional, tendem a dificultar e criar barreiras ao processo de implantação
de sistemas de ERP, influenciando diretamente no seu sucesso ou fracasso.
2.3.3.1 A Cultura de uma Organização
104 Mudança e Transformação Organizacional, Prof. Dra. Rosa Maria Fisher - Mudando os Paradigmas da Mudança.
84
Como definir Cultura? Poderíamos dizer que Cultura é um conjunto de refinados
comportamentos que as pessoas possuem em sociedade. De acordo com o antropologista E. B.
Taylor (1958), "Cultura inclui uma totalidade de conhecimentos, crenças, moral, leis,
costumes e outras capacidades e hábitos adquiridos pelos indivíduos como membros de uma
sociedade,,105. Adaptando melhor esse conceito às organizações, poderíamos dizer que
Cultura é a sinergia que se estabelece no compartilhamento de idéias e crenças associadas
com o modo de vida de uma organização. De acordo com Cleland (1999), Cultura
Organizacional consiste em acordos explícitos ou implícitos compartilhados pelos membros
dessa organização, os quais são expressos em valores, crenças e padrões bem como práticas
sociais e gerenciais. A Cultura desenvolvida, e que se toma característica dessa organização,
afeta o planejamento estratégico, sua implementação e consequentemente, a gestão de projetos
dentro da organização. "É possível identificar aspectos Culturais comuns que influenciam
positiva ou negativamente a prática gerencial e a condução de questões técnicas em uma
organização, como por exemplo: o exemplo dado pelos seus líderes, as atitudes demonstradas
versus as praticadas, as competências gerenciais e profissionais de seus recursos humanos, as
características percebidas a respeito da organização, a qualidade e quantidade de recursos
disponíveis para alcançar a missão, objetivos, metas e estratégias, os padrões de comunicação,
os papéis formais e informais, entre outros" .106
A Cultura Organizacional pode ser mudada de acordo com as modificações estruturais que se
produzem na organização. Ao estabelecer a sua missão, uma organização procura refletir ou
até mesmo às vezes criar uma identidade. Essa identidade por sua vez se expressa através da
sua Cultura, sendo esta uma forma poderosa de se manter uma Empresa unida.
2.3.3.2 A Cultura e os Projetos
105 Trecho extraído de E.B. Taylor, The Origins of Culture (New York: Harper & Row, 1958) em CLALAND, David I. Project Management. Strategíc Desígn and Imp/ementatíon. 3rd
. Edition. Singapore: McGraw-Hill, 1999.
106 CLALAND, David I. Project Management. Strategíc Desígn and Imp/ementatíon. 3rd. Editíon. Singapore:
McGraw-Hill,1999.
85
Projetos podem falhar ou ser bem sucedidos de acordo coma a Cultura de uma organização. É
quase impossível implementar um projeto que não seja consistente com a Cultura da
organização bem como ela tem um grande impacto no sucesso de qualquer coisa que a
organização queira fazer, muito mais do que qualquer Best Practice gerencial possa dar jeito.
Tanto a Cultura da empresa como a Cultura de um projeto dentro de uma empresa, são
mutuamente interdependentes influenciando um ao outro, de acordo a fase do seu
desenvolvimento.
Cada projeto possui uma cultura distinta embora esta seja reflexo de uma cultura universal
encontrada em todos os projetos. Cleland (1999) relaciona uma série de aspectos culturais
universais encontrados em quase todos os projetos. Segundo ele, além da equipe de projeto
"possuir um propósito comum, que é a entrega dos resultados esperados do projeto em termos
de cumprimento de prazos e orçamento, de forma a garantir o alcance das estratégias
organizacionais estabelecidas, ela deve ser constituída e organizada como uma força tarefa
orientada à melhoria contínua e à inovação dos processos organizacionais, produtos e serviços
como forma de garantir a própria sobrevivência da organização"I07.
Podemos dizer então que ocorre uma mudança cultural na empresa toda a vez que forças de
mudança aparecem na organização, forças que propõe mudanças no seu status quo como por
exemplo, projetos de implantação de ERP ou projetos de reengenharia108 os quais resultam em
redução da estrutura organizacional bem como realinhamento de processos. O maior desafio
para o gerente de projetos, nestes casos, é conseguir avaliar o quanto a mudança proposta em
cada um desses projetos irá afetar ou impactar a Cultura dessa organização, facilitando dados
à alta administração para que esta possa prever as ações que irão contrabalançar esses
impactos
Adicionalmente, essas mudanças também irão afetar a equipe de projeto e, sendo assim,
também é responsabilidade do gerente de projeto avaliar de que forma o projeto irá impactar a
107CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd• Edition. Singapore:
McGraw-Hill, 1999. 108 Tradicionalmente, projetos de implantação de sistemas de ERP são precedidos ou são implementados em
paralelo com projetos de reengenharia de processos os quais preparam o terreno, através da revisão e melhoria dos processos organizacionais, para a entrada do novo sistema de ERP.
86
própria equipe do projeto. Em conjunto com especialistas e demais gerentes de projeto, poderá
avaliar que tipo de orientação será necessário dar à organização (como por exemplo,
necessidades de treinamento) e à própria equipe de projeto para melhorar a adaptação às
conseqüências trazidas pelo projeto de implantação do sistema de ERP.
2.3.3.3 A Cultura das Equipes de Projeto
A equipe de projeto é formada por um grupo de pessoas advindas de várias áreas de atividade
de uma organização, com diferentes especialidades e experiências. No início do projeto existe
em comum entre elas apenas o objetivo de criar algo que ainda não existe e dessa forma, a
equipe de projeto irá necessitar criar uma cultura própria. A forma como os empregados da
empresa se associam entre si, por sua vez, poderá influenciar a cultura da equipe de projeto.
Uma vez desenvolvida a cultura na equipe de projeto, esta os manterá unidos. "A Cultura de
uma equipe de projeto é um padrão de interação social que surge do compartilhamento de
interesses, obrigações mútuas, desafios, cooperação e amizades"I09. Para melhorar cada vez
mais a cultura da equipe de projeto, de acordo com Cleland (1999), o gerente de projeto
deverá manter os membros da equipe regularmente informados sobre o status do projeto,
inclusive reportando as boas e a más notícias, com uma certa regularidade. Precisará
promover a troca de idéias, problemas, oportunidades e interesses entre os membros da
equipe, principalmente aqueles novatos no projeto, o que lhes dá uma sensação de pertencer
àquele grupo de trabalho desde o seu início. Deverá encorajar também atividades sociais como
almoços, coffee breaks e jantares entretanto, sem super envolver a equipe nessas atividades de
forma que elas não ultrapassem os limites do próprio projeto e comecem a interferir na vida
pessoal de cada membro. É bom cultivar o uso dos primeiros nomes de cada membro da
equipe ou apelidos, reduzindo as formalidades no lidar com os membros da equipe.
109 CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd. Edition. Singapore:
McGraw-HiII, 1999.
87
o objetivo aqui é manter a equipe motivada e razoavelmente feliz, permitindo que as pessoas
atinjam seus objetivos pessoais e aspirações bem como os objetivos do projeto. Uma
característica entretanto que Cleland (1999) ressalta como sendo uma questão chave para a
cultura de uma equipe de projeto é a confiança, "a segurança que se sente em relação à
habilidade, integridade e o caráter das pessoas associadas com o projeto") lO. Essa confiança
não se dá apenas entre os membros da equipe mas também entre a equipe e a alta gerência
o desenvolvimento de uma Cultura na equipe, irá facilitar no processo de "criar ideais que
ajudarão a guiar o comportamento do grupo"))) e "ajudar a alinhar objetivos e metas
individuais e organizacionais,,))2
2.3.3.4 Alguns impactos negativos da Cultura Organizacional em projetos
Freqüentemente ocorrem casos onde seria melhor abandonar ou encerrar um projeto ao invés
de dar-lhe continuidade. Por exemplo, gerentes com histórias de sucesso que se recusam a
encerrar ou sugerir o encerramento ou abandono do projeto simplesmente porque estão
acostumados a vencer e simplesmente não conseguem aceitar a perda, investindo cada vez
mais tempo e recursos em projetos que estão fadados ao fracasso. Algumas das razões que
levam gerentes e/ou organizações a darem continuidade a esses projetos estão relacionadas a
questões culturais presentes tanto na cultura preexistente das equipes de projeto ou na própria
cultura da organização. Em outras circunstâncias, o projeto passa a se tomar parte da rotina da
organização e esta não consegue dá-lo por terminado ou desmobilizar a equipe envolvida no
projeto por que já se acostumou a ele.
Esses são exemplos em que a Cultura da empresa ou da equipe de projeto funcionam como
fator negativo na gerencia de projeto.
110 CLALAND, David I. Project Management. Strategic Design and Implementation. 3'd. Edition. Singapore: McGraw-Hill, 1999.
111 M.R.LOUIS, "Organization as Cultural Bearing Milieux", em CLALAND, David I. Project Management. Strategic Design and Implementation. 3rd
. Edition. Singapore: McGraw-Hill, 1999.
88
112 R. HARlSSON, "Strategies for a New Age" in CLELAND (1999), David I. Project Management. Strategic Design and Implementation. 3rd
. Edition. Singapore: McGraw-Hill, 1999.
89
3 METODOLOGIA
3.1 Introdução
o objetivo deste capítulo é documentar o desenho e os métodos da dissertação que serviram
de base para a elaboração desta pesquisa sobre Sistemas ERP - a metodologia de gestão de
projetos como fator determinante para o sucesso ou o fracasso na implantação de sistemas de
ERP, a partir de uma análise comparativa entre dois projetos de implantação de sistemas de
ERP.
Para a realização dos objetivos propostos nesta pesquisa, utilizou-se um método estruturado
em duas etapas. De acordo com a classificação proposta por Vergara (1998), esta pesquisa
pode ser classificada, quanto aos fins em:
a) Pesquisa descritiva, pois este estudo pretende expor características de projetos de
implantação de sistemas de ERP, estabelecendo uma correlação entre as características
semelhantes existentes nesses projetos através da observação das técnicas de Project
Management, utilizadas nesses projetos de implantação de software ERP, que
contribuíram para o sucesso de sua implantação. E ainda, procurará mostrar a
correlação dessas técnicas com as demais variáveis analisadas neste estudo.
b) Pesquisa explicativa, pois visa esclarecer quais os fatores que contribuíram, de alguma
forma, para o sucesso ou fracasso de projetos de implantação de sistemas de ERP.
Como por exemplo, de que forma as técnicas de Project Management utilizadas e as
demais variáveis analisadas contribuem, de alguma forma, para o sucesso ou fracasso
da implementação de projetos.
Quanto aos meios de investigação, a pesquisa pode ser classificada como pesquisa
bibliográfica e estudo de caso.
A escolha da pesquisa bibliográfica teve como objetivo levantar as contribuições atuais sobre
a metodologia de Project Management, Gestão de Pessoas, Gestão da Mudança, Liderança e
90
Cultura Organizacional, entre outros, a projetos em geral bem como aos projetos de
implantação de sistemas de ERP.
Dentro da abordagem da pesquisa qualitativa, são utilizados os estudos de caso, onde, a partir
de fontes internas e levantamento feito in loco, são apresentadas informações aprofundadas
sobre as empresas participantes da amostra.
Segundo YIN (1994), para estudos de caso são especialmente importantes cinco componentes
de um projeto de pesquisa:
i) questões para um estudo, quando são necessárias respostas a perguntas do tipo:
"Qual(is)", "Como" e "Por que";
ii) suas suposições, se existirem;
iii) sua unidade de análise;
iv) a lógica que une as informações às proposições; e
v) o critério para interpretar os resultados.
YIN (1994) argumenta que o estudo de caso, apesar da sua ampla divulgação e utilização na
comunidade científica, apresenta uma série de limitações, como a possibilidade de introdução
de viés por parte do pesquisador, não haver tratamento estatístico na amostra a ser estruturada,
além de não ser possível a generalização dos resultados obtidos.
3.2 Universo e Amostra
O universo da pesquisa são dois projetos onde ocorreu a implantação de sistemas de ERP. As
empresas selecionadas são classificadas doravante de A e B. A empresa A, do setor de
telecomunicações, teve seu sistema de ERP implantado em 1999 enquanto na empresa B, uma
empresa do ramo de papel e celulose, o sistema de ERP foi implantado em 1997. Essas duas
empresas foram escolhidas para o presente estudo em função do critério de acessibilidade e
pelo fato de seus projetos de implantação terem apresentado características relevantes para o
estudo em questão.
91
3.3 Seleção dos Sujeitos
Os sujeitos da pesquisa foram consultores e membros da equipe de projeto diretamente
envolvidos nos projetos de implantação do sistema de ERP nas empresas.
3.4 Coleta de Dados
O procedimento adotado para a coleta de dados foi:
a. pesquisa bibliográfica em livros, artigos, teses, dissertações, internet e periódicos
especializados; e
b. entrevistas focadas nos temas propostos, através da aplicação de um questionário contendo
perguntas estruturadas e não estruturada e abertas para que os participantes dos projetos
selecionados pudessem manifestar a sua opinião a respeito dos temas do estudo em
questão.
3.5 Tratamento dos Dados
As informações coletadas através das entrevistas, foram tratadas, organizadas e ordenadas
para facilitar a análise e interpretação dos dados. Em seguida, foram construídos estudos de
caso relativos a cada uma das implantações nas empresa A e B que permitissem ao leitor deste
estudo entender as questões identificadas em cada um dos projetos de implantação de sistemas
de ERP analisados.
92
4 DESCRIÇÃO DOS CASOS
Este capítulo contém informações referentes às duas empresas selecionadas na pesquisa e
relata de que forma as questões tratadas neste estudo foram abordadas nos projetos de
implantação de sistemas de ERP das empresas A e B. Em cada um dos estudos de caso são
descritas características específicas de cada implantação e como foram abordadas nesses
projetos, questões do tipo: que motivos levaram a organização a mudar e se a escolha da
seleção do sistema foi precedida por um levantamento técnico da aderência desse sistema às
necessidades da empresa. Aborda também considerações sobre a cultura da organização bem
como o processo de seleção das equipes, não só de consultores como também da equipe de
projeto interna da empresa e do seu treinamento. Aborda a questão da liderança no grupo
gestor do projeto e temas relacionados a Change Management como a Comunicação. Por fim,
são comentados os resultados alcançados nos projetos em questão.
Nossos entrevistados são pessoas que tiveram uma participação efetiva nos projetos em ambas
empresas assim como o autor deste estudo teve participação nesses projetos de implantação de
sistemas de ERP. Na empresa A, sua participação limitou-se a o papel de usuário final do
projeto, acompanhando o processo de implantação do sistema. Na empresa B, seu papel foi de
consultor de um dos módulos implantados. Entretanto, sua participação não aconteceu até o
final do projeto tendo se limitado a apenas 30% do tempo inicial de sua duração.
Na empresa A, nossos entrevistados são um consultor interno da empresa, da área de
Tecnologia ClT) e um gerente de projeto. A metodologia de coleta de dados foi através de uma
entrevista pessoal e gravada para ambos os entrevistados.
Já na empresa B, nosso entrevistado foi o líder do módulo de finanças da equipe interna da
empresa. A metodologia de coleta dos dados foi através do envio do questionário C em Anexo)
via Internet que o entrevistado respondeu por escrito tendo utilizado o mesmo meio de envio
em virtude da distância e a pouca disponibilidade de tempo.
Ambas as entrevista ocorreram no mês de agosto de 2002.
93
4.1 EMPRESAA
4.1.1 Dados Gerais
A empresa, do ramo de telecomunicações, possui filiais na Europa, Marrocos e América
Latina e se encontra entre as primeiras companhias de telefonia celular no mundo, com
operações em mais de 14 países e que representam um mercado potencial de 514 milhões de
habitantes. Ao final de Setembro de 2002 ela contava com 33,4 milhões de clientes
gestionados em todo o mundo.
Ela presta uma completa gama de serviços na área de comunicações que inclui desde telefonia
fixa à transmissão de dados e outros serviços de valor agregado bem como soluções
corporativas, acesso a Internet, serviços de CRM e conteúdo. Se considerarmos todas as suas
linhas de negócio e não apenas a de telefonia móvel, podemos dizer que esta possui mais de
80 milhões de clientes em todo o mundo. Seu número de empregados se situa em
aproximadamente 161,5 mil em todo o mundo.
No Brasil, a empresa se agrupa em 3 companhias em 5 estados. No decorrer do ano de 2001,
ela concentrou os seus esforços na expansão e modernização das redes de telefonia móvel e no
desenvolvimento de mais serviços de qualidade para seus clientes garantindo com isso um
crescimento de 5,6 milhões de cientes no final de 2001. Em 2002, seus esforços estão voltados
para um crescimento mais rentável, baseado em ações de fidelização de clientes e otimização
de seus processos operacionais.
4.1.2 Histórico da Implantação
A empresa "A" iniciou o processo de implantação do seu sistema ERP em 1999. O sistema foi
implantado nas suas 3 unidades formadas por 5 empresas espalhadas por todo território
nacional. Ela implantou os módulo de materiais, vendas, controladoria, finanças e projetos. A
94
empresa de Consultoria contratada para a implantação foi a Arthur Andersen que utilizou a
metodologia de implantação de sistemas e gestão de projetos ASAP. A implantação durou
aproximadamente 7 meses tendo entrado em produção em Janeiro de 2000. A arquitetura
básica do sistema envolve 3 máquinas independentes, uma para cada unidade regional, que
fisicamente se encontram localizadas no Rio de Janeiro. A área de desenvolvimento,
responsável pela manutenção do aplicativo bem como dos novos desenvolvimento também se
encontra fisicamente localizado no Rio de Janeiro.
A utilização de uma metodologia de gestão de projetos dentro da empresa é fato recente (com
início no final de 200 I), quando a empresa passou a treinar seus usuários chave, tanto de áreas
funcionais como da área de ITI13, na metodologia PMI para ser aplicada a todos os projetos
em curso na organização. Essa metodologia também deverá ser aplicada ao projeto, que será
iniciado em breve, de migração da versão atualmente implantada do sistema de ERP para uma
versão mais recente.
No início da implantação do sistema de ERP a empresa não tinha nenhuma diretriz específica
para que fosse utilizada uma metodologia em particular, fato comum na época com grande
parte das empresas que começavam a implantar sistemas de ERP. Tendo identificado essa
carência por parte das empresas e dado a complexidade da implantação de um sistema de
ERP, a empresa fornecedora desenvolveu uma metodologia que mostrava os caminhos mais
curtos 114 para se configurar o sistema. Ela funciona como um guia para se implantar as
funcionalidades básicas do sistema, ou seja, as funcionalidades standard. Esta ferramenta não
se adapta a implantações que requeiram desenvolvimentos e customizações adicionais, mais
complexas. Portanto, a condição fundamental para utilizar essa metodologia e por própria
recomendação da empresa fornecedora, é que a empresa implante o standard do sistema de
ERP, não se distanciando muito do que lhe é oferecido nos módulos standard. Algo mais
específico que seja necessário desenvolver deverá ser desenvolvido em linguagem de
programação própria, sem que se altere muito o módulo standard. Caso a empresa opte por
113IT - Infonnation Technology, também conhecido por TI - Tecnologia da Infonnação 114Com base em fonnulários específicos, onde o usuário marcava as funcionalidades que desejava implantar, os
resultados mostravam o caminho dentro do sistema e o que precisava ser configurado para que essas funcionalidades selecionadas pudessem ser utilizadas.
95
modificações que alterem a versão standard, sem o prévio conhecimento e consentimento da
empresa fornecedora, esta deixa de garantir a qualidade e as funcionalidades do produto.
4.1.3 Os fatores da Mudança, a seleção do Produto e as mudanças que a implantação
do sistema exigiu da empresa
Se as empresas nos dias de hoje optassem por desenvolver seus próprios sistemas,
principalmente sistemas do porte de um sistema de ERP, demorariam muito tempo para o
fazerl15 e teriam um custo bastante elevado. Por sua vez, desenvolver sistemas independentes
implica na construção de interfaces entre eles para interligá-los e isto era justamente o que
existia antes do surgimento dos sistemas de ERP; era esse exatamente o cenário do qual as
grandes e médias empresas procuravam distanciar-se, não só pelo alto custo de sua
manutenção como pela falta de capacidade para incorporar todas as novas funcionalidades,
novas práticas de gestão, ou seja, as Best Practices l16 que sistemas integrados de ERP
fornecem automaticamente no próprio processo de atualizações periódicas (upgrades) de
novas versões, incluídas nos pacotes.
o risco de desenvolver internamente, por sua vez, levava a empresa a não ter garantia dos
prazos de desenvolvimento desse sistema, o que elevaria consideravelmente o custo de
desenvolvimento de um sistema desse porte. Além disso, a manutenção desses sistemas
envolvia o emprego de um elevado número de funcionários específicos para essa atividade, o
que também elevava os custos operacionais da empresa.
No caso da empresa em questão, os sistema existentes anteriormente não eram integrados, o
que obrigava a empresa a realizar muitos trabalhos manuais de digitação de dados, gerando
retrabalho e requerendo um elevado volume de mão de obra para seus trabalhos rotineiros. E
115Estima_se que o desenvolvimento de um aplicativo com as funcionalidades de um sistema de ERP demande aproximadamente 5 anos para ser concluído.
116 Best Practices - Melhores Práticas
96
ainda, a situação anterior não garantia a qualidade e confiabilidade dos dados imputados nos
sistema legados 117
o sistema anterior atendia em parte às necessidades da empresa, pois ele havia sofrido uma
série de adaptações para atender às suas necessidades operacionais porém, dado ao volume
crescente de operações da empresa, o custo de sua manutenção e a carência de funcionalidades
específicas que atendessem às novas necessidades do negócio que foram surgindo, ele deixou
de atender à empresa. Portanto, havia necessidade de substituir esse sistema.
o sistema escolhido para substituir o anterior foi considerado pelo entrevistado como uma boa
opção embora não tenham sido utilizadas na empresa todas as funcionalidades disponíveis que
poderiam ser implementadas 118.
Para o entrevistado, o melhor ou pior uso de sistemas dessa natureza ocorre de acordo com o
treinamento ou com o interesse que a organização desperta por esse sistema. Aproveitando o
próprio momento do projeto, a empresa aproveitou para rever seus processos, selecionar seus
melhores recursos com o perfil mais adequado para manusear esse sistema bem como passou
a investir mais na sua qualificação. Desta forma, pôde tirar mais proveito do sistema de ERP
implementado.
Conforme nos comentou o entrevistado, os fatores levados em consideração para a seleção
desse sistema foram o fato do sistema em questão já ser um sistema corporativo, ou seja, ele
era o aplicativo selecionado como diretriz corporativa, já tendo sido previamente comparado a
outras soluções diferentes pela área de sistema da holding internacional.
Entretanto, houve um estudo técnico das qualidades do sistema em dois momentos, o
primeiro, quando este foi definido como solução corporativa para o grupo e, posteriormente
no Brasil, nas Fases I e 11 do projeto local, onde se analisaram as qualidades do sistema em
117 Sistemas legados são considerados os sistema que existiam previamente à implantação do novo sistema. 118 Por exemplo, o módulo de controladoria não foi como completamente utilizado.
97
relação às necessidades da empresa e se fez um Gap AnalysisJJ9• Também foram consultadas
empresas que já fossem usuárias desse sistema, bem como foram feitas visitas a essas
empresas, já usuárias do sistema, para poder avaliar o seu desempenho, além dos responsáveis
pela implantação terem participado de congressos e debates com outras empresas com
processos de implantação e características semelhantes, para comparar e trocar impressões a
respeito do produto e dos beneficios (ou não) desta solução para os seus respectivos negócios.
Os pontos que geraram mais polêmica na altura foram: a complexidade do sistema, o grau de
treinamento requerido para o manuseio do sistema pelos usuários, a qualidade do trabalho das
consultorias com pouca experiência para implantar o sistema que, na ocasião, era muito
questionável, a própria metodologia de formação da equipe de projeto era uma questão que
preocupava a organização e as empresas consultadas. Todo esforço necessário para
programação adicional ao módulo standard do sistema, a subsequente necessidade de
manutenção e, principalmente, os projetos deveriam estar restritos ao módulo standard do
sistema. Para selecionar o sistema em questão, também foram feitas apresentações de
demonstração pelo fornecedor e pela consultoria que iria implantar o sistema.
Ao ser questionado sobre a existência de um estudo/levantamento prévio, suficientemente
profundo e abrangente, relativo aos requisitos funcionais do sistema e sua aderência às
necessidades operacionais da organização, o entrevistado comentou que na prática, este tipo
de estudo acaba por ser esquecido, uma vez que a estratégia comercial do fornecedor apela
para o fato de que o sistema que a empresa está adquirindo já ser um sistema testado e
utilizado por uma série de empresas em todo o mundo, e que ele carrega em si todos os
desenvolvimentos adicionais feitos para essas empresas bem como já contempla as melhores
práticas de negócio. Sendo assim, essa apresentação acaba por dispensar, de certo modo, uma
análise mais profunda dos requisitos funcionais do sistema. Além disso, ele acaba
direcionando a implantação para a adoção de sua própria metodologia, a qual reforça a idéia
de que não é o sistema que deverá se moldar às necessidades da empresa e sim a empresa que
deverá rever os seus processos para se adequar ao sistema que, em si mesmo, já trás o que há
de melhor em termos de práticas gerenciais, tendo sido testado e aprovado por várias das
maiores e melhores organizações em todo o mundo.
119 Análise comparativa entre as necessidades da empresa e do negócio e as funcionalidades disponíveis no sistema de ERP.
98
Questionado sobre a realização de um levantamento prévio dos processos da empresa e da
necessidade de readequação desses processos ao novo sistema, o entrevistado comentou que
no caso da empresa em questão, por se tratar de uma empresa muito nova, seus processos
ainda não estavam completamente definidos. Portanto, uma série de procedimentos novos
foram criados simultaneamente ao desenvolvimento do projeto, aproveitando-se inclusive as
próprias funcionalidades existentes na ferramenta bem como o fluxo de processos standard
disponível no sistema, sem que houvesse a necessidade de se fazer uma grande reengenharia
de processos. Apenas em casos muito específicos a empresa necessitou rever alguns de seus
processos para se adaptar à nova ferramenta.
4.1.4 A Influência da Cultura da Empresa no Projeto, na Gerência e na Equipe de
Projeto
Na opinião do entrevistado, ao ser questionado sobre o fato da empresa ter uma cultura
voltada para a promoção de mudanças, de estar costumada a estar na vanguarda de novos
processos de gestão, bem como na adoção de novas ferramentas tecnológicas, sua opinião foi
de que, apesar de ser uma empresa de alta tecnologia, internamente ela não primava por estar
na vanguarda de novos processos de gestão nem na adoção de novas ferramentas tecnológicas
focadas em questões gerenciais. Talvez por ser ainda uma empresa muito nova e de criação
muito recente e recém privatizada. Quando estatal, esta não recebia grandes investimentos por
parte do governo. Como empresa privatizada, à época, ainda não tinha havido tempo para a
alta administração se atentar para essas questões administrativas. A iniciativa de se implantar
um sistema de ERP foi o início do processo de busca por novas metodologias e modernas
ferramentas gerenciais. A escolha e execução desse projeto foi resultado de um processo
natural de adequação da empresa no Brasil ao padrão das demais empresas do grupo no
exterior.
Mas aos olhos dos funcionários, internamente, a cultura da empresa fica mais caracterizada
como sendo mais reativa do que pró-ativa, no que diz respeito à inovação.
99
Quanto à aceitação das mudanças, por parte da organização (funcionários, gerentes e alta
administração), a opinião do entrevistado é de que em geral, em qualquer empresa, qualquer
processo de mudança como o que é promovido pela implantação de um sistema de ERP, é
sempre um pouco traumático. Ao analisar as reações de cada um desses grupos dentro da
empresa, o entrevistado nota que culturalmente a empresa reage negativamente à mudança
num primeiro momento. O pensamento dos funcionários da empresa, no início do projeto, foi
de que eles iriam perder os seus empregos, o que criou uma barreira de resistências contra o
próprio projeto. Mas com a continuidade do projeto, quando os funcionários começaram a ver
que eles estavam tendo acesso e manuseando uma nova tecnologia de vanguarda como é o
caso de sistema de ERP, percebiam que ao mesmo tempo elas também estavam se
qualificando e se valorizando como profissionais e essa resistência com o tempo foi
desaparecendo.
No caso dos gerentes, o que se percebe é que o medo está no fato de que o conhecimento que
eles haviam adquirido com os processos anteriores seria perdido pela entrada de uma nova
ferramenta. Dessa forma, a questão está mais voltada para o medo da perda do poder pela
perda do domínio da informação. A informação deixa de estar centralizada em apenas uma
cabeça. O sistema passa a dominar a informação como um todo e ela passa a estar disponível e
a ser acessível a mais pessoas dentro da organização.
A própria entrada de um sistema tão "poderoso" como um sistema de ERP, exige por sua vez,
mais qualificações do próprio gerente para poder lidar não só com a nova ferramenta como
com as dificuldades e angústias que, no início, surgem dentro da sua equipe. Isto para ele
também acaba sendo um grande desafio e, de cara, faz com que ele resista à mudança. Mas a
tendência é que com o tempo, essa resistência desapareça. Já para a alta administração, a
mudança foi vista com bons olhos. Questionado sobre se a alta administração fomenta na
organização mudanças de processos e métodos de trabalho, o entrevistado respondeu que não,
que ela não se envolve muito com o operacional. Entretanto, neste projeto, verificou-se que
apenas o Sponsor do projeto, devido às suas características pessoais, acabou tendo uma
participação mais detalhista e não a alta administração como um todo.
100
Perguntado se a organização (alta administração, funcionários e gerentes) busca e propõe
mudanças como melhorias de processos, novas metodologias e ferramentas de trabalho, o
entrevistado respondeu que não existe a cultura de todos os setores e departamentos da
empresa proporem, generalizadamente, mudanças, a não ser a existência de ações isoladas de
uma ou outra diretoria e não da organização como um todo. E até mesmo essas pequenas
mudanças não são bem aproveitadas como base para mudanças maiores. Uma das falhas, na
sua opinião, é que faz falta que um usuário se dedique especificamente a identificar
constantemente oportunidades de mudança nos processos de negócio e de gestão no sistema.
Uma pessoa que esteja fora das rotinas operacionais diárias, que possa se ocupar
exclusivamente da busca e identificação de oportunidades de melhoria através de propostas de
pequenas ou grandes mudanças, sejam de procedimentos sejam de ferramentas de trabalho.
4.1.5 A metodologia de Formação da Equipe de Trabalho
A equipe de projeto na empresa foi formada por membros das áreas funcionais e da área de IT
da própria empresa e por uma equipe de consultores com as seguintes características:
especialistas em IT, especialistas em programação, especialistas em processos e um
especialista em Change Management.
A equipe formada para o projeto de implantação do sistema de ERP apresentou características
peculiares, distintas dos demais projetos empresa. Na empresa, de forma geral, os projetos
envolvem apenas usuários da área de IT. No caso da implantação do sistema de ERP, por
iniciativa da própria gerente geral do projeto e da recomendação do próprio fornecedor do
sistema de ERP é que fossem envolvidos usuários das áreas funcionais, pois se entendeu ser
impossível que em um projeto desse porte, a empresa fosse cumprir o cronograma quando o
projeto em si envolvia uma séria de mudanças que impactavam direta e profundamente as
rotinas dos usuários de áreas funcionais sem que eles mesmos tivessem uma participação
direta e efetiva no projeto. Ainda hoje, a empresa não possui a cultura de montar equipes
101
multi funcionais como essa em todos os seus projetos, o que o entrevistado lamenta, em função
dos benefícios obtidos.
Com relação à escolha da Equipe de consultores, ao ser questionado sobre os fatores que
foram levados em consideração para a seleção da equipe que participou e/ou conduziu o
processo de implantação do sistema de ERP, o entrevistado respondeu que foi devido ao
relacionamento preexistente entre a Consultoria e a Organização. A consultoria selecionada já
era, na época, a consultoria da empresa em todo o mundo.
Em relação à qualidade e preparação da equipe de consultores ou staff, comentou que é de
praxe solicitar o currículo dos consultores que serão alocados ao projeto e com base nele,
analisar sua experiência anterior, por quantos projetos já passaram, em que áreas atuaram e
principais atividades executadas. Mas que na prática, isso acaba sendo muito difícil de
acontecer, pois normalmente a consultoria mistura, em uma mesma equipe, recursos mais
experientes com outros menos experientes para que estes possam aprender e treinar durante o
próprio projeto. Não ocorreu nada diferente no projeto em questão. Quanto à gerencia, o nível
foi considerado razoável.
Com relação ao fato da consultoria possuir experiência anterior em outros projetos de
implantação de sistemas de ERP, nos foi dito que sim, que já tinham implantado o sistema em
outras empresas, entretanto, em segmentos de atividades distintos.
Quanto à equipe formada por membros internos da empresas, foi comentado que houve a
preocupação em se reunir uma pessoa de cada área funcional da empresa para cada um dos
módulos a serem implantados (eram 5 empresas em 3 regiões operacionais) e mais uma
pessoa de ITl2o.
120 Particularidade da Empresa A - a área de informática, dentro da Empresa e dentro da estrutura de desenvolvimento de projetos, desempenha ainda hoje um papel de integrador das 3 empresas, principalmente no que diz respeito aos novos desenvolvimento e melhorias ou customizações que têm sido necessário fazer após a implantação do sistema, uma vez que os usuário das áreas funcionais das três empresas não tem a cultura de se comunicarem previamente para discutir um processo único ou uma solução única a ser implantada que venha a atender simultaneamente às 3 empresas. Isto ocorre na Empresa A porque dentro da área de informática existe uma equipe específica cuja responsabilidade é dar apoio à área usuária nas melhorias e modificações que se façam necessárias na ferramenta. Se essa estrutura desaparecesse, e pelo fato
102
A negociação dos recursos foi feita diretamente pelo gerente do projeto com os gerentes e
diretores das áreas funcionais. Mas em alguns casos, notou-se uma certa resistência e medo
por parte da pessoa selecionada em participar do projeto. A razão identificada era o medo que
ela tinha, a incerteza do que iria ocorrer quando terminasse o projeto e ela tivesse que retomar
à área de origem após o término do projeto. O que iria acontecer com ela?
Com relação à contribuição dada pela participação de membros de áreas funcionais na equipe
de projeto, a opinião do entrevistado foi que essa participação contribuiu positivamente para o
sucesso do projeto. Mesmo que ele (recurso indicado, oriundo da área funcional) não tenha
sido a pessoa mais indicada para participar do projeto, porque nem sempre é possível trazer
para a equipe do projeto a pessoa mais indicada, com certeza ela pôde contribuir para o
projeto, dando mais confiabilidade ao que estava sendo proposto e implementado. A
credibilidade decorre do fato de que a empresa, na figura de seus empregados, percebe que
uma pessoa que depois de participar do projeto e que estará manuseando o próprio sistema,
sendo ele futuramente o próprio usuário desse sistema, não poderia estar propondo
modificações ou processos inviáveis de serem operacionalizados.
Com relação ao processo de seleção dos membros da equipe internos à organização, este foi
feito pelo responsável da área usuária. As pessoas selecionadas deveriam ser pessoas
experientes e conhecedoras do trabalho despenhado na área e que normalmente acabavam
sendo escolhido(s) o(s) melhor(es) funcionário(s) dessa área, devendo ter qualificações acima
da média para assim poder contribuir positivamente com o projeto. Desta forma os
responsáveis mostravam resistência em liberar o funcionário uma vez que eles sabiam que
iriam perder um recurso especializado. Por sua vez, como temiam também que após o término
do projeto não poderiam mais contar com aquele recurso, inicialmente demonstraram
resistência em ceder o funcionário.
de existirem 5 empresas e 3 máquinas diferentes, se perderia o controle das modificações feitas no sistema como um todo.
103
A comunicação da saída desses membros das áreas funcionais à equipe em que eles estavam
inseridos foi realizada diretamente pelo Sponsor do projeto. Houve o apoio da equipe de área
de Recursos Humanos da Organização nesse momento pois havia demasiada insegurança
relativa, principalmente, ao retomo às áreas de trabalho ao término do projeto e perspectivas
futuras de existirem outras atividades ou não para eles ao término do projeto. Surgiram
também questões como a equiparação salarial com toda a equipe de projeto, uma vez que
haviam diferenças substanciais entre os salários dos recursos de informática e das áreas
funcionais envolvidas. O entrevistado manifestou sua opinião quanto à importância da
participação ativa de área de Recursos Humanos da Organização nesse processo e da definição
de um plano de ação comunicando à equipe de projeto como serão os procedimentos de
movimentação dos recursos humanos durante o projeto, entendendo também que no caso de
persistirem as dúvidas dentro da organização, seria interessante a realização de um workshop
específico para debater os temas com todos os envolvidos, não deixando que permaneçam
dúvidas a respeito do tema, no decorrer do projeto. Já a aceitação pelos demais membros do
grupo, da saída dessa pessoa para a equipe do projeto provocou, em algumas áreas, frustração
para os que ficaram.
Questionado quanto ao processo de integração entre a equipe de projeto da empresa e a equipe
de projeto da consultoria, o entrevistado nos respondeu que houve apenas um evento de Kick
Oi!'21 no início do projeto, coordenado pela equipe de Change Management, onde durante
uma tarde, fora das instalações da empresa, mais especificamente num salão de um hotel,
ocorreu um encontro de apresentação das equipes e nada mais.
Com relação à existência de equipes mistas, o entrevistado é da opinião que, de uma forma
geral, o resultado é positivo, pois a existência de um consultor externo, que trás consigo a
experiência de outros projetos, adicionada à experiência da equipe de TI, que possui um
conhecimento não só dos sistemas da empresa como o seu negócio, assim como os usuários
das áreas funcionais (que tem a responsabilidade de passar para os consultores as suas
121 Kick-Of! - Como é chamado o evento de lançamento do projeto, ou seja, quando se dá oficialmente o início do projeto.
104
necessidades, que serão transmitidas para os novos processos a serem implantados com a nova
ferramenta), agrega bastante valor ao projeto de implantação do sistema de ERP.
Com relação à existência de conflitos, o entrevistado foi questionado quanto aos tipos de
conflito que ocorrem no projeto pela existência de equipes mistas. Sua resposta foi que ao
longo do projeto ocorreram conflitos. Sempre ocorrem conflitos, como por exemplo, ser
solicitado pela equipe ou gerente de projeto da empresa, a substituição de consultores que não
estão agregando valor ao projeto. O conflito também surge da cobrança, por parte da
consultoria, aos membros da equipe funcional da empresa (não tanto da equipe de IT da
empresa pois estes já possuem por natureza um sentido de autonomia em função das
características de seu trabalho) quanto ao cumprimento das tarefas do cronograma. Essa
cobrança, por sua vez, é decorrência da necessidade que a consultoria tem de cumprir prazos e
manter o projeto dentro do custo previsto.
É comum ocorrer também, por parte da equipe funcional da empresa, uma sensação de
dependência futura em relação à própria consultoria pois, em virtude do volume de atividades
que ocorrem no projeto, nem sempre a equipe funcional da empresa consegue estar atenta e
acompanhar tudo o que a consultoria faz. E um dia, a consultoria irá embora e quem ficará
para dar manutenção e continuidade no manuseio do sistema será a equipe de projeto da
empresa.
Já com relação ao fato da existência de conflitos de interesses pela existência de equipes
mistas, o entrevistado é de opinião que com certeza esse conflito existe. Normalmente os
membros da equipe das área funcionais da empresa bem como os membro TI, estão muito
preocupados com a qualidade e os detalhes do que está sendo parametrizado e planejado
enquanto os consultores estão mais preocupados em fazer uma implantação básica e rápida
para atender ao cronograma e a viabilidade financeira do projeto. Nem sempre esses objetivos
coincidem, o que gera conflitos. Embora o objetivo comum a todos eles seja concluir de forma
satisfatória do projeto, cumprindo os objetivos propostos inicialmente pelo projeto, os
caminhos a serem trilhados para se alcançarem esses objetivos nem sempre são os mesmos
para cada um dos membros da equipe.
105
Em relação à forma como foram administrados os conflitos, o entrevistado nos comentou que
na maioria das vezes esses conflitos foram resolvidos internamente na equipe contando no
máximo com o apoio do líder do módulo, não sendo necessário envolver o gerente. Ele nos
disse que o que se acaba percebendo é que nesse momento, cada grupo recorre ao seu líder ou
gerente, ou seja, o grupo de pessoas da equipe funcional da empresa recorre ao responsável da
empresa enquanto que o grupo da consultoria recorre ao líder ou gerente da consultoria. E
quando a equipe de Change Management é chamada a interferir por fim, o acaba fazendo não
para buscar as causas ou as origens do problema mas sim, para dar a solução final, a
substituição do causador do conflito. Ou seja, não se envolve muito na prevenção dos
conflitos e sim, apenas em soluções rápidas e imediatas.
Na opinião do entrevistado, o fato de existirem esses conflitos, se acaba sendo benéfico ou
prejudicial ao projeto, ele entende que quando discutidos abertamente dentro da equipe, os
conflitos se mostraram benéficos pois, após serem solucionados pela própria equipe, verifica
se uma melhora no relacionamento entre seus membros e no próprio andamento do projeto.
Mas quando não se encontra uma solução para os conflitos, ele se mostra maléfico pois vai
deteriorando o ambiente dentro do projeto e a solução final acaba por ser a eliminação does)
causador(es) do conflito.
Mesmo assim, o entrevistado é favorável à existência de equipes mistas em todos os projetos
de implantação de sistema de ERP.
4.1.6 Os Gerentes de Projeto e a Liderança
Gerentes de Projeto Externos
A equipe de gerentes externos era composta por 3 gerentes sendo um deles operacional,
participando full time do projeto e com responsabilidades mais operacionais dentro deste. O
segundo era responsável pelas atividades comerciais do projeto ou seja, acompanhamento das
necessidades adicionais de recursos e seu subsequente faturamento, responsável pela
identificação de oportunidades de venda de projetos adicionais e complementares ao projeto
106
principal, etc. O terceiro gerente tinha a responsabilidade das atividades de Change
Management porém, não tinha participação full time no projeto, apenas quando necessário.
Os trabalhos eram distribuídos entre a equipe de gerentes da seguinte maneira: a gerente mais
experiente da empresa tinha como responsabilidade participar dos Comitês Executivos do
Projeto bem como participava de algumas atividades operacionais do projeto. O gerente mais
jovem tinha as responsabilidades operacionais do projeto, tinha uma participação full time
sendo ele também o canal de comunicação com os Comitês Executivos.
Entretanto, devido à enorme carga de trabalho, todas as equipes possuíam líderes que eram
chefes do projeto em seu módulo específico, o que apoiava bastante aos gerentes nas
atividades operacionais e diárias do projeto.
A formação da Equipe de Projeto é descrita na Figura XIV - Equipe do Projeto de ERP da
empresa A, a seguir:
Nivel de Decisão
Nivel de Coordenação
Nivel de Execução
I
~entes da Equipe da Empresa
Figura XIV - Equipe do Projeto de ERP da empresa A
Analise do Perfil da gerencia da equipe de consultores
107
Quando questionado sobre a capacidade do gerente da consultoria se relacionar com a sua
equipe, o entrevistado respondeu que era "razoável". Ficou claro para ele que a gerência da
consultoria somente exerce algum tipo de influência sobre a sua própria equipe enquanto que,
por sua vez, a equipe da empresa apenas responde à gerência da própria empresa, não
aceitando muito bem a liderança do gerente de consultoria. Já em relação ao relacionamento
do gerente da equipe da consultoria com a média gerência da empresa (seus contrapartes), ele
mencionou que não havia um bom relacionamento, pois constantemente se observavam
reclamações de ambas as partes. Em resumo, haviam atritos. Com a alta administração da
empresa, devido ao relacionamento prévio da consultoria e com a organização, nunca foi
108
observado nenhum problema, caraterizando-se assim um bom relacionamento entre a gerencia
do projeto e a alta administração da empresa.
Entretanto, com relação às suas habilidades e conhecimentos técnicos a respeito do projeto
que estava sendo implantado, o entrevistado comentou que o gerente da equipe de consultores
possuía mais experiência técnica do que necessariamente habilidades gerenciais para
administrar o projeto como um todo. Quando ocorriam dificuldades como, por exemplo,
pequenas alterações no cronograma que não impactavam no conjunto do projeto, as mesmas
terminavam por ser tratadas diretamente pela equipe. Apenas os grandes atrasos identificados
eram apresentados ao gerente, o que fazia com que ele não se envolvesse muito no dia a dia
do projeto. Quando ocorriam crises entre as equipes da empresa e os consultores, ele também
pouco se envolvia pois os problemas acabavam sendo resolvidos dentro do próprio grupo.
Ele também não era uma pessoa carismática para sua própria equipe assim como para a
empresa, embora demonstrasse interesse e comprometimento com os objetivos do projeto.
Quando queria conseguir que as tarefas fossem executadas, tendia a usar a negociação, mas às
vezes era realmente necessário usar a força e o poder que tinha como gerente para que as
tarefas fossem cumpridas.
Ele costumava delegar responsabilidades aos demais membros da equipe, mesmo porque num
projeto desse porte, na opinião do entrevistado, era impossível não se delegar
responsabilidades, pois o gerente acabava por não ser capaz de dar conta de todas as
atividades e obrigação para com o projeto.
o gerente da equipe de consultores, embora com pouca freqüência, negociava metas e prazos
para o projeto com os demais membros das equipes multifuncionais.
As necessidades de treinamento foram identificadas no início do projeto e foram ministradas.
Ao ser questionado sobre o fato do gerente premiar os resultados obtidos, o entrevistado
respondeu que este não o fazia, bem como não estava atento às necessidades e problemas
pessoais de sua equipe.
109
Com relação aos canais de comunicação, o único canal formal estabelecido pela gerência da
consultoria era com sua própria equipe e com o gerente da equipe da empresa. Problemas
rotineiros identificados na equipe acabam sendo tratados ou delegado pelo próprio gerente aos
seus subordinados para que os resolvessem entre si, o que gerava desconforto para a própria
equipe que se sentia meio desamparada pelo gerente para resolver os conflitos no projeto.
Analise do Perfil da gerência de equipe da empresa
Ao ser questionado se ela demonstrava que o sucesso do projeto que ela coordenava garantiria
o seu próprio sucesso e ascensão na organização, o entrevistado respondeu positivamente.
Como haviam dois gerentes, um mais experiente e outro mais iniciante, aquele iniciante
conseguia visualizar os frutos que poderia colher de um bom trabalho realizado no projeto, o
que acabou acontecendo. Quanto ao gerente mais experiente, portanto com menos
expectativas de desenvolvimento de carreira, tal fato não impediu que também se dedicasse
com a mesma garra ao projeto. Eles escutavam as necessidades da equipe e, sempre que
possível, tentavam atender.
Entretanto, com relação ao reconhecimento e agradecimento pelos resultados obtidos pela
equipe e sua respectiva premiação e recompensas, eles eram muito frios. A premiação era
muito rara.
Ao ser questionado sobre o desenvolvimento, durante o projeto, de uma rede de
relacionamentos com as demais áreas da empresa ou para conseguir atingir os objetivos ou
completar tarefas exigidas pelo projeto, o entrevistado respondeu que sim, que foram criadas
redes de relacionamento. Sem esse bom relacionamento, algumas tarefas simplesmente não
aconteciam, principalmente no momento de se obter o comprometimento e a colaboração das
áreas funcionais da empresa.
Adicionalmente, comentou que durante o projeto criou-se um canal de comunicação com a
equipe e demais gerentes do projeto embora esses canais não tenham sido utilizados na
110
solução de conflitos. Eles também acabavam delegando para a equipe algumas tarefas que se
entendia serem deles próprios, constrangendo os membros da equipe e deixando-os em uma
dificil posição frente aos outros membros da equipe da consultoria e às vezes da própria área
funcional. Às vezes, repassavam ao membro de sua equipe a responsabilidade de cobrar pelo
andamento de certas tarefas, cobrança essa que cabia a eles fazerem como gerentes de projeto.
Entretanto, eram ágeis na tomada de decisões. Estavam sempre atentos às necessidades do
projeto, demonstrando interesse e comprometimento com os objetivos gerais do mesmo.
Quando surgia um problema na equipe, não conseguiam identificar rapidamente uma solução
e implantá-la. Dessa forma, se observou a formação de pequenos grupos dentro das equipes.
Havia o grupo da equipe dos consultores e o grupo da equipe da empresa. Eventuais 'broncas'
eram dadas pelos respectivos gerentes a suas equipes enquanto que cada vez que era
necessário se discutir algum problema, eram os gerentes da consultoria e da empresa que se
falavam entre si e dessa conversa, cada um deles saía para transmitir o resultado das reuniões
para suas equipes. Ou seja, não havia muita integração entre as equipes de consultoria e da
empresa.
Como observado na equipe de gerentes dos consultores, a equipe de gerentes da empresa
também não premiava os resultados alcançados pela sua equipe.
Analise do perfil da alta administração
Quando questionamos ao entrevistado se a alta administração conseguiu transmitir à equipe a
importância do projeto para a estratégia escolhida pela organização, ele mencionou que
durante o projeto houve pouca comunicação entre a alta administração, Sponsor e
Stakeholders do projeto, com a equipe funcional. O diálogo era limitado aos gerentes do
projeto, tanto por parte da consultoria quanto por parte da organização e como mantinha
contato apenas com a gerência do projeto, não demonstrava muita preocupação
especificamente com as necessidades da equipe.
111
Entretanto, a alta administração defendia o projeto junto às demais áreas da empresa afetadas
por este. Fez algumas visitas a outras empresas usuárias do sistema bem como, durante o
projeto, desenvolveu com estas uma rede de relacionamentos para obter beneficios para o
projeto.
A alta administração era também muito cobrada por mais recursos, por parte da gerência de
projeto, e quando era chamada a resolver questões específicas, atendia com prontidão sendo
bastante eficaz. Assim como os gerentes da equipe de consultores e da própria empresa, não
agradecia nem premiava ou recompensava os esforços e os resultados obtidos pela equipe.
4.1.7 O processo de Change Management
A Comunicação
No projeto da Empresa "A", a comunicação ficou a cargo da equipe de Change Management
que, adicionalmente, se envolveu também em questões ligadas a treinamento.
Quando questionado sobre a forma como as novidades em geral eram comunicadas na
organização, o entrevistado comentou que na sua opinião, elas tardavam um pouco e quando
acontecia eram utilizados canais como Intranet, Jornal Interno, etc.
Em relação ao projeto, ele comentou que a comunicação da aquisição de um novo sistema foi
feita através dos canais tradicionais da empresa e que não foi feito muito alarde.
Quanto à comunicação da formação da equipe de trabalho do projeto, comentou que esta foi
feita individualmente, de forma formal e fria, sem aproveitar a ocasião para envolver e
comprometer a equipe no projeto como um todo, com os resultados esperados. Foi também
publicada a formação da equipe no jornal da empresa. Para comunicar o andamento do
projeto(em todas as suas fases), foi criado um site na Intranet onde eram divulgadas
constantemente as informações relacionadas ao projeto bem como o andamento do mesmo,
tendo esses canais sido considerados eficientes.
112
A Integração da Equipe
Como comentado anterionnente, a equipe de Change Management participou apenas do Kick
Off do projeto, não tendo participado do processo de reintegração dos membros da equipe da
empresa às suas áreas de origem.
o Treinamento
Ao ser questionado sobre a qualidade do treinamento recebido pela equipe funcional da
empresa para operar e parametrizar o sistema a ser implantado, o entrevistado respondeu que
este foi adequado. A equipe recebeu treinamento não apenas no próprio módulo em que iria
trabalhar como também em outros módulos e outras funcionalidades para que pudessem ter
uma visão geral do sistema e assim, propor soluções integradas entre os demais módulos.
Quanto aos demais funcionários da empresa, estes receberam treinamento apenas no final do
projeto, quando nonnalmente ocorre a fase de treinamento de todos os usuários que irão
manusear o sistema específico para as atividades.
Quando questionado se foi desenvolvido e implantado um processo de treinamento periódico
na empresa para os novos funcionários ou se o treinamento era feito on the job por seus
demais colegas, o entrevistado nos contou que a empresa não implantou esse procedimento.
Nonnalmente os novos funcionários recebem um treinamento ministrado pelos próprios
colegas. Eventualmente, treinamentos adicionais podem ser solicitados por um ou outro
gerente que identifique uma necessidade especifica, nonnalmente após um processo de grande
turn over de funcionários na área. Nosso entrevistado entende que, como conseqüência, as
pessoas se acostumam a usar maio sistema e às vezes isso gera erros que tendem a se agravar
com o tempo. No caso, a empresa implantou um Help Desk para tirar dúvidas e dar
atendimento imediato aos problemas mais emergenciais. O que se verifica é que a falta de
treinamento das pessoas acaba sobrecarregando o trabalho desse Help Desk, que passa a não
113
mais ser consultado esporadicamente e sim, começa a ser fonte de consulta constante devido à
carência de treinamento dentro da própria organização.
4.1.8 A Finalização do Projeto
Quanto ao acompanhamento, por parte do fornecedor e da consultoria de implantação durante
o início da utilização do software - Go Live, o entrevistado respondeu que sim, que houve
suporte no processo de Go Live . Neste momento, é importantíssimo o acompanhamento da
consultoria para garantir que os problema que possam por ventura ter passado desapercebidos
antes desse momento, possam ser corrigidos. O tempo que a consultoria permaneceu na
empresa após Go Live foi considerado suficiente.
Foi também elaborado material e documentação adequados para administrar treinamento à
organização. Entretanto, esse material não é freqüentemente utilizado pela organização.
Embora a equipe de IT, responsável pela manutenção do sistema de ERP na empresa, tenha o
cuidado de constantemente estar atualizando o material de treinamento, o mesmo não é
divulgado na organização, ficando este guardado apenas para eventual consulta.
Com relação à reintegração desses membros, após o término do projeto, à equipe anterior, nos
foi dito que houve muita ansiedade, por parte dos participantes do projeto, quanto à sua volta.
Mas de uma forma geral, no caso da empresa analisada, ao final do projeto acabam ocorrendo
diversas situações com por exemplo:
a) Alguns membros da equipe foram recebidos novamente em suas áreas de origem,
retomando às suas antigas funções só que agora, manuseando a nova ferramenta e
assumindo o papel de multiplicadores da nova tecnologia dentro de suas áreas;
b) Outros foram promovidos e/ou transferidos para outras áreas, expostos a novos
desafios profissionais;
c) Outros não quiseram retomar à área funcional. Preferiram continuar fazendo parte da
equipe de IT que passou a dar manutenção ao sistema e a implementar as melhorias
que se seguiram ao projeto original;
114
d) Outros não se adaptaram e foram dispensados logo após o término do projeto ou meses
depois.
4.1.9 Os Resultados do Projeto
Escopo
Questionado quanto à proposta inicial do projeto ter sido atendida, o entrevistado entende que
sim, que a proposta era de uma implantação rápida e simples, com as funcionalidades básicas
que permitissem à empresa dar continuidade às suas atividades sem impactar no seu dia a dia.
Não foi prevista nenhuma grande customização no projeto, pois o objetivo era que fosse
realizada uma implantação, num curto espaço de tempo. E, dessa forma, os objetivos
comunicados no início do projeto foram alcançados.
Quando perguntamos se tudo o que inicialmente foi previsto fazer foi feito ou se foi deixada
alguma parte para uma fase posterior, o entrevistado respondeu que, na verdade, como a
proposta inicial era se fazer apenas o básico, os desenvolvimentos mais complexos e as
melhorias necessárias ocorreriam numa fase posterior. Normalmente, a implantação de um
sistema de ERP se divide em fases ou "ondas". No caso da empresa A, optou-se por fazer o
básico e, com as manutenções subsequentes, foram-se incluindo as melhorias necessárias e os
desenvolvimentos adicionais l22. Isso aconteceu porque não eram prioridades para o
funcionamento básico da empresa a implementação de todas as funcionalidades do sistema
selecionado. Na opinião do entrevistado, tal procedimento não foi prejudicial (nem benéfico)
ao projeto porque naquele momento não era indispensável para o funcionamento básico da
empresa a implantação de todas as funcionalidades disponíveis no sistema. Além do mais, é
importante se limitar o escopo da implantação se não ela se toma interminável.
122 Nas "ondas" seguintes poderão ser incluídos módulos como Análise de Rentabilidade, Gestão de Caixa, Recursos Humanos, etc.
115
Questionamos o entrevistado quanto ao fato das mudanças nos processos da empresa e no seu
próprio negócio terem continuado a exigir que fossem feitos desenvolvimentos contínuos no
sistema, posteriores ao encerramento, e o mesmo nos respondeu que sim.
Continuam havendo pequenos novos projetos como conseqüência do primeiro projeto. Foram
incluídas novas funcionalidades, foram adicionados e integrados outros módulos, já que são
sempre identificadas necessidades de melhoria. Algo que se leva em consideração é a própria
necessidade que a empresa tem de se acostumar à nova ferramenta e aos poucos, quando
aprende a manuseá-la e já a domina melhor, passa-se a implementar novas funcionalidades.
Nos disse que as pessoas acabam ficando mais críticas e, conhecendo melhor o seu negócio,
elas passaram a exigir mais qualidade nos processos da empresa, propondo mais melhorias e
novos desenvolvimentos.
Neste momento a empresa se prepara para a migração da versão implantada em 1999 para
uma mais recente, por orientação da própria empresa fornecedora. Neste momento, as pessoas
estão mais ávidas por mudanças maiores e por isso, é preciso conter um pouco as expectativas
da empresa para não correr o risco de tornar o projeto tão complexo dificultando a sua própria
migração no prazo previsto (dead line previsto para janeiro de 2003)
Prazo
Questionado quando ao cumprimento do prazo previsto para o projeto, nosso entrevistado
comentou que foi praticamente concluído no prazo. O prazo inicial era Novembro de 1999 e
foi concluído em Janeiro de 2000. Segundo ele, dado o tamanho do projeto, se poderia dizer
que o atraso foi pequeno.
Por menor que tenha sido, ocorreu em parte devido ao grande volume de coisas que se propôs
implantar no prazo inicialmente determinado. Isso fez com que a fase de testes, muito
importante para evitar que problemas ocorram na fase de produção, fosse subestimada, não
tendo sido suficiente para fazer todos os testes integrados, o que provocou o atraso no projeto.
116
Em resumo, todas as tarefas foram cumpridas, sendo o tempo requerido subestimado para
elas.
Custo
Quanto ao custo, o que se pode identificar é que não foi cumprido, em função de se ter
subestimado o custo dos equipamentos.
117
4.2 EMPRESA B
4.2.1 Dados Gerais
A Empresa B é uma empresa brasileira do ramo de papel e celulose, que produz e
comercializa celulose de eucalipto branqueada e papel de imprimir e escrever. A empresa
oferece dois tipos de celulose ao mercado: standard e ECF (livre de cloro elementar). Os
papéis produzidos pela empresa são de alta qualidade com elevadas alvura e opacidade.
Fabricados, desde julho de 2000, com colagem alcalina, são oferecidos em bobinas de
dimensões industriais (com gramatura desde 56 até 110 gramas por metro quadrado) ou
cortados em folhas (folio size).
A empresa atualmente possui ações negociadas na Bolsa de Valores de São Paulo e nos
Estados Unidos por intermédio de programa ADR nível 1.
A organização atenta para a qualidade dos produtos fabricados, em sintonia com o conceito de
desenvolvimento sustentável, bem como os níveis de serviço oferecidos são atestados pela
ampla aceitação e reputação em todos os mercados e o estabelecimento de relações duradouras
com importantes clientes.
A organização é conhecida por algumas características que defende como por exemplo, a
produtividade florestal, a auto-suficiência em madeira, a geração própria de energia, a
proximidade dos plantios em relação à fábrica (distância média de 61 km), a aplicação de
modernas tecnologias e padrões internacionais de gestão da qualidade e do meio ambiente -
ISO 9002 e ISO 14001, possuindo um centro de pesquisa e desenvolvimento, com serviços
direcionados ao atendimento das necessidades dos seus clientes.
Sua unidade industrial, localizada no extremo sul do Estado da Bahia, produz celulose e papel
a partir da madeira do eucalipto, matéria-prima obtida por meio de plantios próprios. Dos 130
mil hectares de sua área total, 76 mil são reservados à cultura do eucalipto, cujo plantio está
distribuído em áreas descontínuas, em nove municípios, nos estados da Bahia e Espírito
Santo. As áreas destinadas à preservação de matas nativas e mananciais totalizam 46 mil
118
hectares. Seu compromisso com a preservação ambiental está presente desde a concepção do
projeto e tem sido reconhecido internacionalmente pelas certificações e prêmios conquistados,
desde 1995, quando tomou-se a primeira empresa do setor, no mundo, a obter a certificação
pela norma inglesa BS 7750 (Environmental Management System), mantendo também um
sistema integrado de gestão da qualidade, com certificação pelas normas ISO 9002 e ISO
14001.
A empresa tem especial atenção com seus recursos humanos e dentro de seus objetivos inclui
ações de desenvolvimento e capacitação de equipes, de melhoria contínua de seus processos e
da comunicação na organização, buscando sempre ser uma empresa atrativa para se trabalhar.
Encontra-se em processo de definição de um modelo de competências a ser aplicado a todos
os níveis hierárquicos da empresa. Possui programas de treinamento e desenvolvimento,
programas de MBA para os executivos bem como realizou em 2001 seu primeiro programa de
"trainees" tendo contado com a participação de 2.500 candidatos para 8 vagas disponíveis.
4.2.2 Histórico da Implantação
A empresa B iniciou o processo de implantação do sistema ERP em Julho de 1997. Ela
implantou os módulo de materiais, vendas, controladoria, financeiro, planejamento da
produção, planejamento de materiais e recursos humanos, à exceção da folha de pagamento,
work flow e geração de relatórios e informações gerenciais A implantação durou
aproximadamente 18 meses, tendo entrado em produção em Março de 1999, incluindo um
mês de suporte pós implantação. A versão implantada já havia sido "localizada" para as
necessidades brasileiras.
A empresa B não possuía uma metodologia específica para gerenciar o projeto de implantação
do sistema ERP. Sendo assim, contou com a experiência e o apoio metodológico de uma
empresa de consultoria assim como, eventualmente, com o suporte metodológico da própria
empresa fornecedora. A metodologia utilizada foi a SAP Enable Reengineering da Ernst &
Young Consulting que se divide em 3 fases: Fase I - Planejamento e Levantamento da
Situação Atual, Fase 11 - Visão de Futuro (que contempla o Desenho e Modelagem da Visão
119
de Futuro) e a Fase m - Implantação e Acompanhamento (que contempla o Suporte Pós
implantação).
A metodologia prevê também a avaliação do risco do projeto, levando em consideração 5
tópicos. O primeiro deles refere-se à extensão do projeto (cujo grau de risco calculado foi
66%), a experiência (cujo grau de risco calculado foi 64%), a tecnologia (cujo grau de risco
calculado foi 54%), a organização do projeto (cujo grau de risco calculado foi 35%) e as
condições operacionais (cujo grau de risco calculado foi 40%). Na média, o projeto alcançou
um score de 49% de risco como um todo, sendo considerado um projeto de médio risco.
O projeto previa também o treinamento para a equipe de projeto bem como para toda a
organização que estaria manuseando a ferramenta. O treinamento era considerado um pré
requisito para motivar os funcionários no uso efetivo do novo sistema bem como na
transferência de know-how.
Como premissas para o sucesso do projeto, era necessário um bom planejamento do mesmo, a
clara definição das responsabilidade entre os membros da equipe de projeto bem como dos
gerentes, a clara priorização das tarefas programadas no cronograma de implantação, bem
como era primordial que a equipe estivesse dedicada full-time ao projeto, não sendo aceitável
o envolvimento da equipe de funcionários chave com as atividade rotineiras da empresa.
A implantação teve como premissa a customização ZERO, restringindo as necessidades de
customização ao mínimo, permitido apenas as customizações padrão do sistema. Algo mais
específico que fosse necessário desenvolver deveria ser desenvolvido na própria linguagem de
programação do sistema para que não se alterasse muito o módulo standard. No caso das
empresas que compram o sistema optarem por modificações que alterem o sistema standard,
sem o prévio conhecimento e consentimento da empresa fornecedora, esta deixa de garantir a
qualidade e funcionalidades do produto.
O projeto previa também, dentro das atividades de Change Management, um Plano de
Comunicação detalhado para garantir a fluidez da comunicação durante o projeto.
120
4.2.3 Os fatores da Mudança, a seleção do Produto e as mudanças que sua implantação
exigiu da empresa.
Ao ser questionado sobre os motivos que levaram a organização a buscar um sistema de ERP,
o entrevistado nos contou que foi a busca pela integração das informações da empresa,
buscando-se eliminar o retrabalho e garantindo uma maior agilidade e confiabilidade aos
processos da organização. Na organização, não existia sistema semelhante anteriormente. Os
sistemas legado/23 eram independentes, alguns deles inclusive, contavam com interfaces
desenvolvidas para integrá-los entre si. Esses sistemas, de acordo com o entrevistado, não
atendiam às necessidades da empresa, tanto que foram substituídos pelo novo sistema de ERP.
De acordo com o entrevistado, havia uma real necessidade de substituição do sistema anterior,
alguns sistemas já estavam muito 'retalhados' e necessitavam de uma revisão ou atualização
de versão ou ainda não atendiam plenamente às necessidades dos usuários. O custo envolvido
nesse processo estimulava a empresa a partir para um produto mais moderno, reconhecido
pelo mercado e pela concorrência como um sistema que atenderia melhor às necessidades da
organização.
Quando questionado sobre o que achava da opção pelo sistema selecionado, ele acredita que
tenha sido uma boa escolha. Para a seleção desse sistema, o entrevistado nos contou que o
fator primordial levado em consideração foi a necessidade de integração. Buscava-se a
simplificação de processos, que eliminassem o retrabalho existente dentro da organização,
dando-lhe assim maior competitividade.
Com relação à existência de um estudo prévio das qualidades do sistema, o entrevistado nos
contou que inicialmente selecionaram-se alguns sistemas de ERP e por fim, optou-se por um
deles. Foram consultadas outras empresas usuárias do sistema selecionado. Entretanto, de
acordo com o entrevistado, no segmento de negócio em questão (Papel e Celulose), já quase
todas as grandes organizações concorrentes estavam optando pelo sistema de ERP em questão
123 Sistemas Legados são aqueles sistema que existiam previamente ao sistema que se está implantando.
121
como solução tecnológica portanto, suas opiniões foram consideradas na hora de se optar pelo
sistema de ERP selecionado.
Entretanto, em ralação à existência de um estudo/levantamento suficientemente profundo e
abrangente dos requisitos funcionais do sistema e da sua aderência às necessidades
operacionais da organização, o entrevistado nos respondeu que não necessariamente houve
esse estudo. O que aconteceu é que existia uma necessidade de mudança e a escolha do
sistema de ERP era uma condição para que essa mudança ocorresse já que esse ERP, no seu
bojo, trazia em si embutidas as melhores praticas de negócios em voga. Dessa forma, a
organização estava preparada para se adaptar ao novo sistema e não ao contrário. Entretanto,
foi feito um levantamento prévio dos processos em uso e da necessidade de readequação
desses processos ao novo sistema. Os processos em uso foram mapeados e, posteriormente,
foram redesenhados novos processos.
4.2.4 A Influência da Cultura da Empresa no Projeto, na Gerência e na Equipe de
Projeto
Na opinião do entrevistado, a empresa possui uma cultura de promover mudanças, e está
acostumada a estar na vanguarda de novos processos de gestão bem como na adoção de novas
ferramentas tecnológicas. Na sua opinião, a empresa está sempre em processo de mudança,
buscando sempre o que há de melhor no mercado. A organização procura envolver os
funcionário nessas mudanças uma vez que eles são sempre chamados a participar das
mudanças. Desta forma, as mudanças são encaradas como uma coisa natural, útil e necessária
dentro da organização. A alta administração fomenta na organização mudanças de processos e
métodos de trabalho assumindo um papel de patrocinadores em todas as questões de mudança
propostas pelos empregados. Por sua vez a organização, na figura de seus funcionários e
gerentes, aceita bem a implantação de novos procedimentos de trabalho e novas ferramentas
de trabalho, principalmente ferramentas tecnológicas como as de ERP. Muitas dessas
mudanças partem dos próprios donos dos processo, ou seja, das próprias áreas usuárias. A
organização busca e propõe melhorias de processos, novas metodologias e ferramentas de
trabalho pois para ela a mudança é vista como uma questão de sobrevivência.
122
Mas ao ser questionado se os usuários se sentiram ameaçados pela entrada do novo sistema, o
entrevistado nos contou que sim embora esse medo tenha acabado durante o projeto.
4.2.5 A metodologia de Formação da Equipe de Trabalho
A equipe de projeto foi formada por membros das área funcionais e da área de IT da própria
empresa, conhecedores dos sistemas legados e dos processos de negócio da empresa. Esses
membros de IT também adquiriram habilidades, através de treinamentos específicos de
programação na linguagem própria do sistema para dar-lhe suporte e manutenção. A equipe de
consultores contou com profissionais com as seguintes características: especialistas em
Processos e um especialista em Change Management. Pontualmente, era envolvido um ou
outro especialista em IT.
A equipe de Change Management teve uma formação diferenciada pois contou com vários
membros de Recursos Humanos da empresa e com um consultor externo de RH, especializado
em temas como na integração de equipes, contratado especialmente pela empresa para
participar do projeto nas atividades relacionadas a Change Management. A consultoria
também disponibilizou um recurso especializado em Recursos Humanos para a formação do
grupo de Change Management.
Com relação à escolha da equipe de consultores, o entrevistado nos contou que os fatores que
foram levados em consideração na sua seleção foram a experiência prévia e a qualificação dos
profissionais da consultoria. O entrevistado considera a qualidade e preparação da equipe de
consultores um fator muito importante para o alcançe dos objetivos iniciais do projeto, caso
contrário ele pode se estender por muito tempo e cair em descrédito dentro da organização.
Entretanto, preferiu não comentar a qualidade da equipe de projeto e da gerência da empresa
de consultoria.
Com relação à experiência que a empresa de consultoria possuía em outros projetos de
implantação de sistemas de ERP, o entrevistado nos comentou que esta possuía pouca
123
experiência porque na época (em 1997), haviam poucos projetos implantados ou em processo
de implantação.
A seleção dos membros da equipe internos à organização ocorreu da seguinte maneira:
"escolhemos os melhores de cada área e negociamos com os respectivos gestores a liberação
dos mesmos para o projeto. A comunicação de sua entrada na equipe foi feita com a
recomendação de que deveriam se dedicar exclusivamente a esse trabalho e que deveriam
mudar o que fosse necessário mudar, focando sempre a simplificação e otimização dos
processos". Uma vez comunicado que o mesmo participaria do projeto, suas atividades foram
repassadas para outras pessoas e ele se incorporou fisicamente, junto com os demais membros
da equipe, ao projeto para o início dos trabalhos. O entrevistado acredita que o processo de
comunicação e a transição das pessoas à equipe de projeto foi tranqüilo e que dessa forma
tenha sido satisfatório.
Com relação ao processo de aceitação pelos demais funcionários das áreas funcionais, da
saída dessa pessoa para a equipe do projeto, nos comentou que este foi tranqüilo, mesmo
porque em algum momento os demais funcionários iriam ser envolvidos no projeto e dariam a
sua parcela contribuição e ajuda para o projeto.
Em relação à equipe de projeto de TI, na sua opinião, a participação de usuários da empresa na
equipe de projeto contribuiu positivamente para o alcance dos objetivos iniciais do projeto,
sem a presença deles, o entrevistado acredita que não se teria alcançado os objetivos
inicialmente proposto para o desenho e a implementação do sistema.
Na opinião do entrevistado, a existência de equipes mistas é bastante útil, inclusive necessária
para a continuidade do processo pós implantação, através da identificação das melhorias nos
processos de negócio. Além disso, com a existência de uma equipe mista, permite que a
consultoria por um lado aporte ao projeto o conhecimento técnico do sistema e por outro, a
equipe funcional da empresa aporte ao projeto o conhecimento do negócio. É essa associação
que faz o sucesso do projeto. Na sua opinião, todos os projetos de implantação de ERP
124
deveriam contar com equipes mistas. Sem isso, não há como incorporar novas
funcionalidades, mesmo que a equipe interna tenha conhecimento do sistema e consiga fazer a
implantação sozinha.
Ele alerta entretanto, que é importante levar em consideração que, para o desenvolvimento do
projeto, o primordial é ter planejamento e acompanhar o cronograma e isso é melhor
gerenciado por uma equipe de consultores externos com experiência em gestão de projetos.
Sobre se a existência de equipes mistas gerar conflitos de interesses durante o projeto, na sua
opinião é de que tal fato não deveria existir. Caso ocorra, a gerência responsável pelo projeto
deveria interferir para correção de rota do projeto. No caso do projeto em questão, ele nos
comentou que sempre que foi identificado um conflito e que houve necessidade de uma
intervenção da equipe gestora, prevaleceu o bom senso. Em casos mais drásticos, a solução foi
mudar as pessoas da equipe envolvidas no conflito.
Sobre a sua opinião quanto aos benefícios ou malefícios do surgimento de conflitos no
projeto, nos comentou que tais conflitos provocam sempre uma mudança no curso do projeto.
E as mudanças, sempre que necessárias, devem acontecer preservando sempre o objetivo
principal do projeto.
4.2.6 O Gerente de Projeto e a Liderança
A formação da Equipe de Projeto é descrita na Figura XV - Equipe do Projeto de ERP da
empresa B, a seguir:
125
Nivel de Decisão
I Nivel de Coordenação
~rentes de Equipe _ da Empresa
Nivel de Execução
Figura XV - Equipe do Projeto de ERP da empresa B
Analise do Perfil da gerencia da equipe de consultores
A divisão de trabalho e das tarefas entre a equipe de Coordenação o Comitê Executivo da
equipe era a seguinte: o gerente interno cuidava das questões relacionadas a processos,
comunicação e o cumprimento do cronograma. Cuidava também para que a unidade da equipe
estivesse sempre preservada. O gerente da consultoria, por sua vez, atentava para as questões
técnicas do sistema, resolvendo problemas como, por exemplo, a não aderência do sistema às
necessidades da empresa - os gaps - e atividades ligadas ao controle geral do projeto.
O entrevistado comentou que o projeto envolvia a organização como um todo e portanto,
havia a necessidade de se manter a comunicação com os demais membros da equipe sempre.
126
Entretanto, ocorre que o gerente de consultoria do projeto em questão vinha de uma outra
empresa, não tendo experiência prévia em consultoria e isso foi um pouco complicado se
relacionar com a equipe da empresa. Se não houver uma sintonia entre gerência de projeto,
equipe e gestores das áreas funcionais, o projeto perde sua importância e deixa de existir
comprometimento por parte dos gestores como um todo. Dessa fonna, o gerente do projeto
tem que ser uma pessoa fortemente agregadora.
Com relação às suas habilidades e conhecimentos técnicos a respeito do projeto que estava
sendo implantado, o entrevistado entende que ele sabia da importância do projeto e tinha
consciência de sua responsabilidade porém como era uma experiência nova para ele, o
andamento do projeto o colocava à prova a todo instante.
Com relação à sua capacidade de administrar as atividades inerentes ao projeto como
cronograma, recurso humanos e financeiros, crises entre os diversos membros da equipe e/ou
entre equipe de consultoria e da empresa, o entrevistado nos disse que de fonna geral, todas as
dificuldades inerentes ao projeto no tocante à sua administração foram solucionadas de
maneira coerente e com bastante participação dos patrocinadores, que eram os diretores da
organização.
Para ele, na maioria das vezes, o gerente do projeto da consultoria era uma pessoa carismática
para a equipe e para o cliente mas quando era obrigado a tomar decisões, a situação mudava
de figura. Demonstrava interesse e comprometimento com os objetivos do projeto e
costumava delegar responsabilidades aos demais membros da equipe. Sempre que necessário,
solicitava treinamento, embora os participantes de um projeto de implementação de ERP
estejam sempre sendo treinados pelo fato de estarem contribuindo para as mudanças na
organização.
Com relação aos canais de comunicação, comentou que a comunicação no projeto se realizava
através de reuniões específicas para tratar de questões relativas ao projeto. Nessas reuniões, as
pessoas comunicavam suas dificuldades, apreensões e davam sugestões.
127
o gerente da equipe de consultores era ágil na tomada de decisões. Em um projeto, não se
pode demorar para tomar decisões, o cronograma não pára, as coisas têm que ser decididas
rapidamente, independentemente da vontade da equipe. As decisões relativas ao projeto
sempre eram tomadas em conjunto com o gerente da empresa e tinham que ser ágeis. Ao
identificar um obstáculo ou problema, este negociava os novos rumos compartilhando as
decisões com a equipe e os donos do processo.
Quando questionado quanto ao fato do gerente da equipe de consultores ter o hábito de
premiar os resultados obtidos, ele nos disse que não.
Analise do Perfil da gerência da equipe da empresa
Ao ser questionado se ele demonstrava que o sucesso do projeto que ele coordenava garantiria
o seu próprio sucesso e ascensão na organização, o entrevistado respondeu positivamente. Isso
era imprescindível para o seu sucesso. A garra, motivação e empenho são fundamentais para a
carreira profissional.
Quanto a escutar as necessidades da equipe, nos disse que isso ocoma sempre que era
possível, embora no auge do projeto as coisa tivessem ficado um pouco tumultuadas em
função das tarefas terem que ser executadas em um curto espaço de tempo. O agradecimento e
a premiação costumavam acontecer sempre que a equipe merecia. De uma maneira ou de
outra, acontecia o reconhecimento.
Sempre que necessário, desenvolveu uma rede de relacionamentos com as demais áreas da
empresa e com outras empresas para conseguir atingir os objetivos ou completar tarefas
exigidas pelo projeto. Criou um canal de comunicação com a equipe e demais gerentes do
projeto pois isso era fundamental, sem essa comunicação o projeto não atingiria seu objetivo.
128
Analise do Perfil da alta administração
Quando o questionamos se a alta administração conseguiu transmitir à equipe a importância
do projeto para a estratégia escolhida pela organização, ele mencionou que sim. Além disso,
tanto a equipe do projeto como o gerente tinham um canal aberto com a alta administração.
Durante o projeto criou-se um canal de comunicação permanente com a equipe e gerentes do
projeto através da realização de reuniões periódicas para discutir-se assuntos relacionados
com o projeto.
A rede de relacionamentos com as demais área da empresa ou outras empresas para conseguir
atingir os objetivos ou completar tarefas exigidas pelo projeto também foi sempre uma
constante por parte da alta administração.
Poderíamos dizer que o projeto contou com um grande patrocínio da alta administração da
empresa. O seu apoio foi de suma importância para o sucesso do projeto. Sem isso, ficaria
quase impossível o comprometimento de todos dentro da organização. Sempre que era
solicitada, a alta administração era ágil na tomada de decisões
A alta administração sempre demonstrava preocupação com as necessidades da equipe e dos
gerentes do projeto pois tinha o maior interesse de que tudo desse certo. Na medida do
possível, lutava por mais recursos para o projeto.
Quanto a agradecer e premiar os esforços e os resultados obtidos pela equipe, nos disse que
isso é pratica comum na organização. As equipes são premiadas por resultados satisfatórios.
4.2.7 O processo de Change Management
Na Comunicação
129
De acordo com o entrevistado, a comunicação na empresa se dá normalmente através do
jornal interno, por publicações específicas e ou reuniões entre empresa e funcionário, e na sua
opinião, tem funcionado satisfatoriamente. Com relação ao projeto especificamente, a
comunicação da aquisição do novo sistema se deu primeiro através de uma reunião de
diretoria com os gerentes e em seguida a notícia foi repassada para a equipe.
Durante o andamento do projeto, em todas as suas fases, a comunicação ocorreu através de
um jornal interno específico sobre o projeto ou através de reuniões com as áreas envolvidas.
Este canal foi considerado eficiente pelo entrevistado embora ele tenha sugerido outros como
a Intranet, a Internet e a participação da equipe em eventos corporativos.
o Treinamento
Sobre a qualidade do treinamento recebido pela equipe funcional para operar e parametrizar o
sistema a ser implantado o entrevistado comentou que, na sua opinião, os treinamentos
costumam ser ministrados esperando-se obter o melhor resultado para a equipe, mas nem
sempre acontecesse o melhor, ou seja, no tempo disponível para os treinamentos da equipe
funcional nem sempre se conseguem os melhores resultados. Ás vezes, o membro da equipe
não consegue absorver todo o conhecimento necessário para sozinho implantar o sistema. Por
isso, a equipe mista é sempre bem vinda.
Quanto ao fato dos demais usuários, em todas as áreas da organização afetadas pela
implantação do ERP, terem sido treinados para manusear o novo software, o entrevistado nos
comentou que estes receberam treinamento porém sempre falta muito a aprender. Quando os
usuários se deparam com as rotinas do dia-a-dia é que identificam que ainda há muito a
aprender. Por isso, é importante treinar novamente a equipe após alguns meses do sistema ter
entrado em produção. Porém, durante o projeto, foi elaborado material e documentação
adequados para administrar treinamento à Organização através de manuais de usuários, e esse
material é freqüentemente utilizado pela organização.
130
Quanto ao desenvolvimento e implantação de um processo formal de treinamento periódico
na empresa, para os novos funcionários, nosso entrevistado nos comentou que o treinamento
para novos usuários é sempre ministrado pela própria área, ou seja, o seu treinamento é feito
on the job por seus demais colegas. Questionado sobre o fato desse procedimento afetar a
qualidade do trabalho e a utilização das funcionalidades do sistema, na sua opinião, o
entrevistado entende que às vezes é prejudicial, por que essa forma de transmitir o
conhecimento carrega os vícios previamente existentes na área. Mas o mesmo observa que na
prática, na maioria das vezes, tem dado certo.
o entrevistado nos disse que houve um acompanhamento dos usuários e do sistema, após a
implantação por parte da própria empresa. Entretanto, em relação à consultoria, como é
estipulado em contrato quanto tempo ela ficará no período de pós-implantação, esta não
permaneceu dando suporte por muito mais tempo.
A Integração
Durante todo o projeto, o entrevistado nos contou que para proporcionar a integração entre a
equipe de projeto da empresa e da consultoria, foram ministrados diversos cursos internos e
eventos de integração com todos os participantes.
4.2.8 A Finalização do Projeto
Com relação à volta dessas pessoas às suas funções rotineiras após a conclusão e
encerramento do projeto, o entrevistado nos contou que poucos voltaram às suas rotinas.
Alguns ficaram em TI e outros retomaram para as áreas em funções diferentes, com olhos
voltados às melhorias que deveriam ocorrer após o fim da primeira "onda" de mudanças
implementadas pelo projeto.
131
Segundo o entrevistado, agora essas pessoas possuíam mais responsabilidade já que agora eles
tinham a missão de estar com os olhos voltados para a identificação de oportunidades de
melhorias contínuas dentro de suas respectivas áreas.
4.2.9 Os resultados do Projeto
Escopo
Com relação à proposta inicial do projeto ter sido atendida, o entrevistado entende que o
projeto atingiu aproximadamente 70% os resultados esperados. Não deu tempo de fazer tudo o
que foi comunicado nem foi possível implantar todas as funcionalidades do sistema. Foi
apenas possível implantar o que havia sido comunicado em termos de funcionalidades.
Foi deixada alguma coisa para se fazer após o projeto entrar em produção. Por exemplo, toda
a área florestal foi postergada porque não era possível postergar a entrada em operação.
Entretanto, ressaltou que as coisas que ficaram pendentes não prejudicaram a entrada do
sistema em operação. Na opinião do entrevistado, o atraso também aconteceu por que foram
identificadas novas oportunidades de melhoria, no decorrer do projeto, que eram impossíveis
de ser implementadas no prazo determinado para a sua conclusão. Ao ser questionado sobre
tal procedimento ter sido prejudicial ou benéfico ao projeto, na sua opinião o projeto não foi
afetado pela não inclusão de alguns processos.
Desde a conclusão do projeto, continuam havendo vários pequenos projetos pois após a
implantação foram identificadas várias oportunidades de melhoria, que foram implementadas
após o início da entrada em operação do sistema. Na opinião do entrevistado, isto ocorre
porque, na medida em que se conhece melhor as potencialidades do sistema, o escopo vai se
alterando. Porém, sua aplicabilidade acaba sendo postergada para uma fase posterior. No caso
da empresa B, foi isso que aconteceu.
132
Prazo
Quanto ao cumprimento do prazo previsto para o projeto, houve atraso de 2 meses. O atraso
ocorreu em primeiro lugar devido ao fato da equipe funcional e dos próprios consultores não
conhecerem suficientemente o sistema. Em segundo lugar devido à pouca experiência da
equipe, tanto funcional como da de consultores, em projeto de implementação de sistemas de
ERP em empresas de grande porte na época. Em terceiro lugar, o atraso também foi
influenciado pelas modificações que foram ocorrendo no escopo do projeto.
133
5 ANÁLISE DAS INFORMAÇÕES COLETADAS
o escopo deste capítulo é analisar os dois casos descritos anteriormente tendo como base o
modelo proposto na revisão bibliográfica. Objetiva-se fazer análises comparativas entre as
duas empresas pesquisadas, buscando identificar semelhanças e diferenças de padrão nas
implantações de sistemas de ERP ocorridas nessas duas empresas.
Seguindo a linha de formatação da apresentação dos estudos de caso, a análise destes dois
casos ser dará em seis partes, sendo a primeira, uma comparação entre o histórico da
implantação nas duas empresas. Em seguida, compararemos os fatores da mudança, a seleção
do produto e as mudanças que essa implantação exigiu da empresa, como a se deu a influência
da cultura das empresas no projeto, na gerência e na equipe de projeto, os aspectos da
metodologia utilizada por cada uma das empresas na formação das equipes de trabalho,
faremos uma comparação entre perfil dos gerente de projeto em cada uma delas, os conflitos e
os aspectos de liderança observados em cada uma das implantações bem como faremos uma
análise comparativa entre o perfil da alta administração em cada uma delas. Como o processo
de Change Management, ou seja, o treinamento, a comunicação e a integração das equipes foi
abordado em cada uma das empresas e por fim, os resultados obtidos pelo projeto, ou seja, o
processo de finalização e os resultados obtidos em termos de escopo, prazos e custo.
5.1 Histórico da implantação nas duas empresas
Embora as duas empresas tenham optado pelo mesmo sistema, a empresa A optou pela
implantação de uma quantidade menor de funcionalidades - módulos, do que a empresa B o
que, em termos de duração e riscos para o projeto, aumenta à medida que aumentam as
funcionalidades selecionadas para essa implantação.
A época na qual ocorreram essas implantações também é um diferencial que deve ser levado
em consideração uma vez que quanto mais cedo ocorriam as implantações mais difícil era
dispor de recursos treinados e conhecedores das funcionalidades do sistema, o que elevava
134
consideravelmente o risco do projeto. Embora dois anos de diferença entre cada um dos
projetos possa parecer para os leigos pouco tempo, na prática o que se observa é que à medida
que o tempo passava, e mais projetos no Brasil iam acontecendo, mais e mais pessoas
passavam a conhecer o produto, incluindo até mesmo o próprio fornecedor do sistema, e mais
curtos se tomavam os projetos subsequentes.
Da mesma forma, as versões utilizadas em cada uma das implantações, incluíam, dependendo
da época, mais ou menos "Tropicalizações,,124 e portanto, mais aderência possuía o produto às
necessidades da empresa e menos customizações eram necessárias.
Poderíamos dizer que o tempo de duração dos projetos analisados depende diretamente da
quantidades de funcionalidades ou módulos do sistema implantados.
Outra conclusão a que se pode chegar comparando os dois casos é que as empresas não
possuíam conhecimentos nem metodologias apropriadas para a implantação de um sistema tão
amplo e complexo como esse e por isso, ambas necessitaram do apoio de uma empresa de
consultoria externa, com a metodologia, recursos e conhecimento necessários para suportar o
projeto de implantação do sistema de ERP.
Ambas tiveram como premissa para essa implantação, customização ZERO, condição
fundamental para reduzir os riscos e a complexidade do projeto.
5.2 Os fatores da mudança, a seleção do produto e as mudanças que essa implantação
exigiu da empresa
Embora os objetivos das duas empresas ao selecionar o sistema de ERP possam parecer
diferentes se comparadas as respostas dadas pelos entrevistados, por trás dessa seleção havia a
124 Tropicalizações é como ficam conhecidas as adaptações necessárias ao produto original uma vez que o sistema de ERP em questão, não teve sua origem no Brasil e adaptações a questões tributárias e processos específicos do Brasil, por exemplo, foram necessários para que o produto melhor se adaptasse às necessidades das empresas às quais era oferecido e vendido.
135
necessidade principal de se reduzir custos. A escolha desse sistema especificamente, envolve
também questões e desejos intangíveis com por exemplo, a empresa B queria ter o mesmo
sistema utilizado por suas concorrentes enquanto a empresa A tinha esse sistema definido
como uma diretriz corporativa. Fato é que o sistema em questão era o sistema mais vendido e
mais comercializado na época, portanto o mais caro e de implantação mais cara, como
conseqüência do volume de recursos humanos envolvidos, da necessidade do suporte de
consultorias e dependendo das customizações necessárias, o mais arriscado e mais demorado.
Os gaps identificados entre o sistema e as necessidades da empresa, em ambos os casos,
foram resolvidos com customizações através da programação de interfaces ou
desenvolvimento de aplicativos adicionais que substituíssem ou complementassem as
necessidades adicionais da organização, utilizando, como pré-condição, a mesma linguagem
de programação do sistema. Em ambos os casos, foram as empresas que se adaptaram ao
sistema e não o sistema que se adaptou às empresas.
5.3 Influência da cultura das empresas no projeto, na gerência e na equipe de projeto
Neste aspecto, podemos observar duas atitudes completamente distintas entre as duas
empresas analisadas. A empresa A não possui tradição e cultura voltada para a mudança, o
que parece estranho se formos pensar que esta é uma empresa da área de telecomunicações,
segmento onde novos desenvolvimentos tecnológico, que envolvem um elevado grau de
mudança, são uma constante e uma premissa para o seu core business.
Já para a empresa B, a mudança fazia parte de sua cultura, do seu contexto. Ressalta-se o fato
de não só a equipe do projeto como todos os funcionários da fabrica da Bahia possuírem
histórias de motivação por terem aceitado o desafio de sair de São Paulo para estabelecer a
nova fábrica no interior da Bahia. São portanto pessoas motivadas e dispostas a inovar e a
aceitar as mudanças. E que no caso do projeto de implantação do sistema, estavam muito
motivadas com a possibilidade de mudança.
136
A empresa B no projeto em questão, delegou aos membros da equipe o poder para decidir e
mudar o que fosse necessário para que se obtivessem os melhores resultados do projeto. Esta
delegação de responsabilidades os estimulou a buscar e a extrair os melhores resultados do
sistema de ERP e do projeto em si.
Entretanto, nem toda esta motivação na empresa B foi suficiente para que as pessoas
envolvidas no projeto não tivessem medo de perderem seus empregos ou suas funções dentro
da organização após a entrada em produção do novo sistema, como ocorreu na empresa A. Em
todos os casos, após a entrada em produção dessa nova ferramenta, as pessoas, tanto
funcionários quanto gerentes, acabaram por ver que, sendo ela inevitável, eles tinham agora
pela frente o desafio de dominarem esse novo conhecimento. Pois dominar esse novo
conhecimento era a garantia também da sua permanência na empresa e por isso, precisava
conhecer e desenvolver mais seus conhecimentos nessas novas funcionalidades, já que eles
não poderiam ficar para trás sob a pena de ficarem ultrapassados e de serem, futuramente,
substituídos pela própria organização. Neste momento, a equipe de Change Management tem
um papel fundamental no processo, reduzindo as expectativas das pessoas, montando um bom
plano de comunicação do projeto para a organização.
No caso da alta administração, em ambos os casos, percebemos que ela acaba tendo uma visão
mais estratégica do quanto a inovação, com a implantação do novo sistema, será benéfica para
a organização como um todo e, por isso, ela fomenta a mudança. Entretanto foi comentado
pelo entrevistado na empresa A que às vezes a alta administração não conseguiu visualizar os
impactos que a mudança proposta pelo sistema de ERP trazia para a empresa, como por
exemplo no caso da empresa A, o impacto que a implantação do módulo de Vendas, pelo fato
deste estar integrado com a área financeira, teria diretamente nas atividades da área financeira
e ela, por sua vez, deveria estar preparada para a mudança e não estava.
A organização naturalmente leva um certo tempo para se adaptar. O que acaba ocorrendo é
que depois da primeira "onda" de mudanças trazidas pelo novo sistema, é normal que em
projeto subsequentes sejam incorporadas novas funcionalidades mais específicas e complexas
que trarão mais mudanças, num ciclo contínuo.
137
5.4 Aspectos da metodologia utilizada por cada uma das empresas na formação das
equipes de trabalho
Nos dois casos analisados, a equipe de projeto contou com membros internos da organização
em cada equipe. Este procedimento difere de outros tipos de projeto, como comentado pelo
entrevistado na empresa A. Mas ambos entrevistados foram da opinião de que a existência de
equipes mistas foi fundamental para os bons resultados obtidos pelos respectivos projetos.
Entretanto, na empresa A, pôde-se reparar que houve mais resistência, por parte dos gerentes
funcionais da empresa, em liberar recursos para o projeto, por medo de perder esses recursos
ou do desaparecimento de suas vagas.
Outro aspecto ressaltado pelo dois entrevistados, tanto na empresa A quanto na empresa B, foi
a volta à área de origem após o término do projeto. Do ponto de vista daqueles que deixaram
suas áreas para participar do projeto, foi identificado nos dois projetos, que houve por parte
dessas pessoas, medo de que ao término do projeto elas não mais tivessem condições de serem
recolocadas nas suas respectivas áreas ou funções anteriores. E como pôde ser observado,
houve pouca contribuição por parte da equipe de Change Management do projeto da empresa
A para reverter essa sensação nas pessoas que foram participar do projeto. O entrevistado da
empresa A deu exemplos inclusive de como essa volta acaba sendo um pouco traumática,
dando com o exemplo algumas situações como por exemplo, o medo de voltar à equipe antiga
depois de tanto tempo, das piadas relacionadas com o sistema implantado por parte daqueles
que ficaram cada vez que ocorre um erro no sistema como se o fato de ter ocorrido um erro
fosse culpa da pessoa que esteve participando no projeto. Para a pessoa que retoma à área
acaba sendo um pouco mais dificil a readaptação. Nem todas voltam como foi comentado no
estudo de caso da empresa A. Mas ambos são da opinião que, em geral, a participação em um
projeto desse porte é uma grande oportunidade para quem participa dele e depende de cada um
o resultado que pessoa poderá obter dessa participação.
138
Enquanto no projeto B, não se comenta a qualidade dos recursos selecionados, no projeto A o
entrevistado mencionou que os recursos disponibilizados para o projeto não foram os
melhores disponíveis na empresa, ressaltando entretanto que mesmo assim, os resultados
foram bons.
Com relação à equipe de consultores participante do projeto, o entrevistado da empresa B
preferiu não manifestar a sua opinião quanto à qualidade destes recursos. Desta forma, o que
se pode concluir, através das opiniões manifestadas e identificadas nos dois casos analisados,
é que a equipe de consultoria possuía pouca experiência em projetos desse porte.
Com relação ao comprometimento da equipe com os resultados do projeto, o entrevistado da
empresa A comentou que esse comprometimento, por parte da equipe de consultores, nem
sempre é o mais adequado e sugeriu que uma forma de melhorar o grau de comprometimento
desses consultores seria o estabelecimento de bônus e premiações vinculados aos resultados
dos trabalho. Como comentado na revisão bibliográfica específica sobre o tema, são sugeridas
outras alternativas.
5.5 O perfil dos gerentes de projeto e da alta administração, os conflitos e os aspectos
de liderança no projeto
Foi identificada a existência de conflitos nos dois projetos. O entrevistado da empresa A fez
uma análise das razões para os conflitos entre, principalmente, a equipe funcional da empresa
e a equipe de consultoria, focando principalmente a existência de objetivos distintos entre
esses dois grupos. Os consultores necessitam otimizar o custo, o cronograma e a rentabilidade
do projeto e para isso, acabam reduzindo o escopo, ao contrário da equipe composta por
membros da empresa, que está disposta a garantir a qualidade e a manutenção do escopo,
penalizando um pouco mais a rentabilidade do projeto, principalmente se o projeto tiver para a
empresa um custo fixo não atrelado à sua duração e sim a pacotes de atividades concluídas, o
que normalmente ocorre em projeto desse tipo. A solução dos conflitos, em ambos os casos,
foi alcançada com a substituição das pessoas envolvidas no conflito.
139
Por sua vez, ficou mais caracterizada a falta de características de liderança na equipe gestora
do projeto da empresa A, enquanto que a inexistência dessas mesmas características nos
gestores da empresa B passou um pouco mais desapercebida. Mas de uma forma geral, pôde
se concluir que, nos dois casos, a equipe gestora carecia de habilidades gerenciais.
No caso da empresa A, essa carência foi um pouco minimizada pelo fato de, na formação das
equipes, cada módulo a ser implantado contar com um recurso experiente e conhecido da
organização. Para o entrevistado da empresa A, o diferencial na questão da liderança é que os
líderes das equipes de projeto venham das áreas usuárias, ou seja, que sejam pessoas
respeitadas por seu know how e experiência, e que os membro de TI dentro da equipe
funcionem, neste caso, apenas como uma equipe de suporte, que intervém nas questões mais
técnicas do sistema sempre que necessário.
Nos dois casos, observou-se que os gerentes delegavam responsabilidades aos líderes ou
responsáveis pelas equipes funcionais. Mas em ambos os casos é ressaltado o fato de que, em
função do volume de tarefas compreendidas no projeto, essa delegação era uma exigência do
próprio projeto.
Foi observado que a gerência da consultoria da empresa A não premiava ou recompensava a
equipe pelos resultados obtidos. Apenas o gerente da equipe funcional da empresa B tinha
essa atitude, reforçada pela própria cultura da empresa de premiar os resultados alcançados.
A comunicação dos líderes de projeto com o resto da equipe é identificada mais na empresa B
do que na empresa A. A equipe de projeto teve mais acesso à alta administração na empresa B
do que na empresa A, cujo acesso à alta administração estava restrito ao gerente de projeto
mais experiente. Em ambos os casos, os gerentes de projeto tinham acesso à alta
administração.
Nos dois casos, também foi formada uma rede de relacionamentos interdepartamental e entre
empresas que se encontravam em processo de implantação ou que já tinham passado por esse
processo visando melhorar não só o relacionamento entre eles e a troca de experiências como
também garantir melhores resultados para o projeto.
140
5.6 O processo de Change Management - a comunicação, a integração das equipes e o
treinamento
A participação da equipe de Change Management na empresa A se limitou ao evento de Kick
Of! do projeto e à preparação do plano de comunicação e do treinamento. Foi considerada uma
participação limitada, com pouco envolvimento nos momentos de conflito e com pouco
suporte à equipe de projeto. Conforme comentado pelo entrevistado, a participação da área de
Recursos Humanos da própria empresa por vezes substituiu a equipe de Change Management
nesse papel integrador.
Com relação à empresa B, a participação da equipe de Change Management foi mais ativa
porém assim o foi porque a área de Recursos Humanos da empresa atuou intensamente
contando inclusive com o apoio de um consultor externo, contratado por esta, nos processos e
principalmente nos eventos de integração das equipes.
Nos dois casos, ficou evidente que o processo de treinamento na empresa A se limitou àquele
realizado previamente à entrada do sistema em produção e que, embora o material tenha sido
preparado para esse momento específico, não se definiu um procedimento posterior como
rotina para a revisão dos conhecimentos do sistema através da formalização de um
treinamento periódico na empresa visando a reciclagem de seus usuários.
Nos dois casos, foram criados canais formais de comunicação dos resultados do projeto à
organização.
5.7 Os resultados obtidos pelo projeto - o processo de finalização e os resultados
obtidos em termos de escopo, prazos e custo.
Ficou evidente que nos dois casos, as empresas começaram o projeto com uma diretriz clara
de limitarem o escopo do seu projeto às funcionalidades standard do sistema como forma de
141
garantir a conclusão do mesmo dentro do prazo e do custo pretendidos. Conforme já
comentamos, a diretriz dada foi customização ZERO.
Entretanto, um dos fatos comentados pelo entrevistado da empresa A com respeito à sua
opinião sobre os fatores que afetaram o resultado do projeto da empresa A, ele destacou que
este se distanciou das funcionalidades standard disponíveis no sistema, não tendo seguido a
diretriz inicial de customização ZERO, tendo sim realizado customizações em excesso.
Já no caso da empresa B, esta comentou que foi uma opção deixar de implementar certas
funcionalidades e deixar de efetuar desenvolvimentos adicionais visando garantir o
cumprimento dos prazos, deixando essas funcionalidades para serem implementadas em
projetos futuros, para não estender mais o projeto inicial.
Em ambos os casos, a falta de experiência da consultoria e da equipe de projeto foi ressaltada
como um fator que limitou o desenvolvimento e aplicação de novas funcionalidades no
projeto e foi apontado como justificativa para o fato do projeto não ter sido concluído no
prazo.
Consequentemente ambos não cumpriram o custo inicialmente previsto.
Nos dois casos, continuaram havendo novos projetos como conseqüência do primeiro projeto
onde então foram incluídas novas funcionalidades por que sempre são identificadas
necessidades de melhoria como uma conseqüência do próprio processo de implantação.
Novamente, cabe lembrar que, como restrições e limitações apresentadas neste estudo,
destacam-se a pequena amostragem, o não tratamento estatístico dos dados, a possibilidade de
introdução de viés tanto por parte do entrevistado quando do entrevistador, além de não ser
possível a generalização dos resultados obtidos. Entretanto, tais fatores limitantes não
invalidam este estudo de caráter exploratório que poderá servir como ponto de referência para
futuras implantações de sistema de ERP e estudos subsequentes, devendo constituir, portanto,
elementos encorajadores para novos estudos nesta fascinante área de gestão de projetos.
142
6 CONCLUSÓESERECOMENDAÇÓES
As análises comparativas das empresas entrevistadas para os estudos de caso, escopo principal
deste estudo e apresentadas no capítulo anterior, evidenciam pontos importantes no que diz
respeito à implantação de sistemas de ERP.
o presente estudo sobre a utilização de metodologias de Project Management como um
diferencial na implantação de sistemas de ERP evidenciou que o simples fato do projeto
utilizar uma metodologia de gerenciamento de projetos, através da contratação de uma
consultoria, contratada pelo seu know how e metodologia de gestão de projeto e
conhecimentos técnicos do sistema, não garante o que ao termino do projeto, todos os
objetivos previsto inicialmente no que diz respeito ao cumprimento do prazo, escopo e custo
previstos, sejam alcançados sem que um trade of! ocorra. Os resultados obtidos ao final do
projeto de implantação do sistema de ERP são afetados por uma série de outros fatores que
estão mais ligados a questões relacionadas com as variáveis ressaltadas neste estudo como
liderança, formação de equipes, as técnicas de Change Management adotadas e os aspectos da
cultura da organização. A utilização da metodologia garante sim que o projeto chegue ao seu
final, entretanto, esses outros fatores serão o diferencial de "sucesso ou fracasso" dos projetos
de implantação de sistemas de ERP.
Desta forma, algumas conclusões podem ser tiradas deste estudo. Na Tabela D - Principais
Conclusões a seguir, relacionamos as principais conclusões obtidas neste estudo e a seguir
faremos alguns comentários e resumiremos a principais conclusões alcançadas.
Tabela D - Principais conclusões:
PRINCIPAIS CONCLUSÓES
• As empresas não possuem metodologia nem conhecimento suficientes para implantar um sistema de ERP de grande porte sozinhas;
• Algumas empresas selecionam o sistema objetivando alcançar um status na sua área de atuação;
143
PRINCIPAIS CONCLUSÕES
Contratam consultoria por acreditar que esta possui não só uma metodologia de Gestão de Projeto adequada como também experiência em implantação desses sistemas de ERP; • Entretanto, ficou claro que quanto mais cedo ocorreram essas implantações, menos
conhecimento e experiência possuíam as empresas de consultoria assim como menores eram as Tropicalizações do sistema resultando assim em maiores atrasos e maior quantidade de problemas ocorreram nos projeto;
• Os riscos e tempo de duração do projeto aumentam à medida que aumenta a quantidade de módulos a serem implantados assim como aumentam os gap's entre as necessidades da empresa e as funcionalidades disponíveis no modulo standard devendo-se antes de se iniciar o projeto, fazer um Gap Analysis. Dependendo desse resultado, aumenta-se ou se diminui a quantidade de customizações (programações específicas adicionais). O fornecedor sugere customização ZERO para minimizar o tempo e os riscos dos projetos;
• O Gap Analysis normalmente acontece depois de contratada a consultoria, fazendo parte das atividades do projeto, quanto o preço (custo do projeto) já foi negociado bem como tempo de duração deste. Após a analise de gap 's é que será possível ter uma real noção se o projeto cumprirá o tempo e o custo planejado ou se terá que se comprometer, por exemplo, o seu escopo;
• A facilidade com que a empresa encara a mudança vaI facilitar o processo de implantação do sistema de ERP;
• A equipe se forma com Consultores (alguns experientes e outros inexperientes) e membros da empresa como forma de minimizar o abismo entre o conhecimento necessário do negócio, o tempo disponível para a implantação bem como a falta do domínio técnico do sistema a ser implantado por parte da empresa que o está implantando;
• A participação de membros internos da empresa, das áreas funcionais e especialistas no processo de negócio que está sendo implantando, permite obter melhores resultados na implantação da ferramenta, de forma mais alinhada às necessidades da empresa. Sua participação também encurta o tempo necessário para o entendimento das atividades e permite agilizar o processo de parametrização do sistema;
• Os membros da equipe interna da empresa funcionam ao mesmo tempo como multiplicadores e como "quebra-gelo" na divulgação da nova ferramenta dentro da empresa, dando mais confiabilidade ao novo sistema e processo que está sendo implantado;
• Inexperiência e desconhecimento da Consultoria interfere nos resultados do projeto;
144
PRINCIPAIS CONCLUSÕES
• Equipes Mistas e projetos complexos como as implantações de sistemas de ERP requerem: um gerente com características de líder, muito trabalho e a realização de atividades de Change Management (Kick Off, eventos de integração, reuniões de posicionamento e de status, treinamento, mapeamento e tratamento dos Stakeholders, etc .. );
• Tanto na seleção quanto no encerramento e retorno dos participantes às suas áreas funcionais, a participação da equipe de Change Management (RH) funciona como um facilitador do processo. Nem sempre isso ocorre;
• A saída e retorno dos membros da equipe funcional, traz insegurança ao membros internos da organização, participantes do projeto pois: não sabem se teriam de volta suas vagas, se ainda teriam espaço na empresa, se teriam equiparação salarial entre os demais membros da equipe, entre outros medos;
• A existência de um plano de comunicação ativo facilita o processo de divulgação das ações do projeto e das mudanças em curso na organização, decorrentes do próprio projeto;
• Atividades de Integração entre a equipe de consultores e a equipe funcional também facilita e melhora o relacionamento e permite obter melhores resultados no projeto;
• Se não houver bastante intervenção ou ações de Change Management sobre as equipes de consultores e as equipes funcionais nos projetos, essas equipes tendem a se distanciar entre si formando 2 grupos separados, que respondem apenas aos seus gerentes diretos, aumentando assim a probabilidade de surgimento de conflitos e comprometendo assim os resultados do projeto;
• O conflito acontece e nos casos analisados foi tratado com pouca intervenção da equipe de Change Management. A origem do conflito normalmente está na divergência de objetivos do projeto em termos de prazo x custo x qualidade (escopo). Embora todos tenham um objetivo comum: concluir o projeto com sucesso, o problema reside nos meios utilizados;
• Em relação à postura dos Gerentes de projeto:
1. a premiação e o reconhecimento pelo esforço e trabalho da equipe influencia os resultados e a dedicação desta ao projeto (o que nem sempre ocorre);
2. delegar responsabilidade e concomitantemente autoridade e "poder" à equipe funcional, garante maior cobrança em termos de qualidade dos resultados obtidos pelo projeto (como no caso da empresa B e como mencionado por Vergara 125
125 "Compartilhar autoridade. As pessoas tem a tendência de delegar tarefas sem compartilhar a autoridade necessária para a sua realização, desprezando assim a força do comprometimento embutida na autoridade.
145
PRINCIPAIS CONCLUSÕES
(1999), a delegação de poder permitiu a obtenção de melhores resultados na implantação do sistema de ERP);
3. a não identificação rápida dos problemas e a respectiva tomada de decisão por parte do gerente, potencializa os problemas propiciando o aumento de conflitos;
• Em relação ao perfil dos Gerentes de projeto, caracterizou-se:
1. a falta de características de liderança; 2. se apoiam na figura do especialista da área funcional, líder de módulo por ser
este uma pessoa com muito know how e respeitada na organização;
• Em relação à postura da Alta Administração:
1. possuem visão mais estratégica da importância da mudança e da implantação desse sistema mas não acompanham as mudanças no ambiente micro da empresa;
2. o maior acesso da equipe de projeto à alta administração aumenta o comprometimento e facilita a divulgação de mensagens e os objetivos do projeto;
• A inexistência de treinamento periódico para reciclagem e treinamento de novos usuários no manuseio do sistema compromete os resultados obtidos do sistema e potencializa a repetição e manutenção de erros no manuseio deste;
• Principais fatores responsáveis pelos resultados insatisfatórios nos projeto:
1. inexperiência dos consultores; 2. excesso de funcionalidades implantadas num primeiro momento; 3. grande volume de customizações (distanciamento da sugestão dada pelo próprio
fornecedor da solução: customização ZERO);
Com relação à seleção da equipes, de acordo com Frame (1995)126, um projeto falha
normalmente não pela falta do emprego de técnicas e metodologias mas sim, pela falta de
qualificação da equipe de projeto. Como mencionado, a equipe de Change Management, junto
com a gerencia do projeto, devem identificar o perfil dos recursos necessários para o projeto e
Comprometimento funciona como cumplicidade na busca e na realização dos objetivos empresariais" in VERGARA, Sylvia Constant. Gestão de Pessoas. São Paulo: Atlas, 1999.
126 FRAME, 1. Davidson. Gerenciando Projetos nas Organizações. 2001.
146
identificar dentro da organização ou fora dela, aqueles recursos que apresentem a melhor
aderência às necessidades do projeto. Pelo que foi observado nos estudos de caso, os projetos
em questão contaram com pessoas inexperientes e com pouco conhecimento do sistema que
estava sendo implantado, principalmente da consultoria. Tentou-se minimizar essa carência
através de treinamento e trazendo para o projeto, a participação de pessoas conhecedoras dos
processos da empresa onde o sistema estava sendo implantado, pessoas vistas como líderes
em suas áreas de atuação e que talvez tenha sido esse o diferencial que fez com que o projeto
não tenha fracassado logo desde o seu início. Como comentado pelos entrevistados, nem
sempre puderam ser selecionados os melhores recursos humanos, por não estarem disponíveis
mas, ainda assim, os recursos selecionados puderam contribuir para o sucesso do projeto,
dando mais confiabilidade ao que estava sendo proposto e implementado, pois seus colegas
percebiam que uma pessoa que posteriormente estaria manuseando o próprio sistema, sendo
ele o seu próprio usuário no futuro, não poderia estar propondo modificações nos processos ou
implementado funcionalidades inviáveis de serem operacionalizadas.
o perfil de especialistas em implantação de sistemas e o conhecimento metodológico, não
disponíveis na organização, foi obtido através da contratação de empresas de consultoria com
know how e experiência em projeto dessa natureza. A própria consultoria, nos dois casos
analisados, não dispunha de recursos 100% treinados, tendo formado sua equipe com pessoas
experientes e outras menos experientes, que necessitaram de um acompanhamento mais direto
por parte dos consultores mais experientes. Esta inexperiência, em muitos casos, fez com que
o cronograma ficasse comprometido, pois treinamento adicional foi necessário inclusive tendo
sido necessário enviar consultores ao estrangeiro, no caso da empresa B, para se
especializarem em funcionalidades que precisavam ser implantadas.
De forma a garantir que a equipe e seus recursos dessem o melhor de si, foi necessária muita
comunicação. Haviam reuniões periódicas de acompanhamento do projeto onde os problemas
eram apresentados, onde as soluções pudessem ser encontradas em conjunto, pois faz parte da
metodologia empregada pelas empresas de consultoria contratadas, a existência de reuniões
específicas para essas discussões.
1
147
Também foi apontado por Frame (1995)127 a necessidade de existirem canais de comunicação
abertos entre a equipe e a gerência como fatores para reduzir a ineficiência em projetos. Foi
identificado que esses canais existiam nos casos analisados, tendo contribuído positivamente
para os resultados dos projetos embora nem sempre os problemas específicos de um ou outro
membro da equipe tenham podido ser sempre resolvidos.
As recompensas também são apontadas por Frame (1995)128 como uma forma de estimular a
equipe. No caso da empresa A, a inexistência de recompensas foi apontada como um fator que
desestimulou a equipe a dar o melhor de si no projeto. O estabelecimento de metas e
consequentemente de recompensas pelo seu atingimento deve ser pensado pelos gestores de
projetos como um diferencial que deve ser considerado em futuros projetos de implantação de
sistemas de ERP.
Na revisão bibliográfica, foi mencionada a importância de se criar uma identidade na equipe
de Projeto. Essa identidade é obtida com eventos de integração das equipes. Como observado
nos dois projetos, a realização desses eventos era uma responsabilidade da equipe de Change
Management. Enquanto que na empresa B esses eventos ocorreram com freqüência, na
empresa A houve apenas um evento de Kick Off. Podemos observar que as questões
relacionadas a conflitos entre os membros da equipe foi mais abordada na entrevista com a
empresa A e assim, observar que o conflito, dentro da equipe, é ressaltado sempre que existe
menos integração entre os seus membros. Projetos dessa natureza geram naturalmente
conflitos decorrentes do volume de trabalho existente, da falta de domínio de 100% das
funcionalidades disponíveis no sistema, da urgência em se cumprirem prazos e do próprio
conflito de interesses existente entre a equipe de consultores e a equipe da empresa 129. Se na
empresa A tivessem havido mais eventos de integração coordenados pela equipe de Change
Management, talvez não tivessem ocorrido tantos conflitos entre os membros da equipe de
consultores e membros das equipes funcionais como de fato ocorreu, não sendo necessária a
127 FRAME, J. Davidson. Gerenciando Projetos nas Organizações. 2001. 128 Idem.
129 Como mencionado, a equipe de consultores está mais preocupada com a rentabilidade do projeto, querendo se limitar às funcionalidade standard enquanto que a equipe funcional da empresa está mais preocupada com a qualidade e a adoção de funcionalidades mais avançadas, na tentativa de tirar melhores resultados do sistema a ser implantado
148
substituição de pessoas, fator que também compromete a qualidade e continuidade do projeto
como comentado na revisão bibliográfica.
A motivação foi abordada na revisão bibliográfica como sendo algo que está diretamente
relacionado com o reconhecimento pelo esforço empreendido em uma tarefa ou um trabalho
em um projeto. Nas entrevistas, tomou-se claro que no projeto da empresa A, esse
reconhecimento não acontecia nem na equipe funcional nem na equipe de consultores. Já na
empresa B, o reconhecimento acontecia apenas por parte da gerência funcional, como parte da
cultura da própria organização, conforme foi ressaltado pelo próprio entrevistado. Nesse caso,
onde havia a prática de premiação, os resultados obtidos foram mais satisfatórios.
Uma grande preocupação ressaltada por Frame (1995)\3°, é o fato das equipes de projeto
serem formadas por pessoas as quais são freqüentemente retiradas das suas rotinas
operacionais e levadas para formar parte dessa equipe de projeto, por um determinado período
de tempo que, de acordo com a necessidade, poderá ser curto ou longo, ou podem até mesmo
participar simultaneamente de vários projetos ao mesmo tempo. Essas pessoas precisam ser
trabalhadas pela equipe de Change Management tanto no momento da retirada das áreas
funcionais como também no momento do seu retomo. E precisam da atenção especial dos
gerentes de projeto no sentido de motivá-las. Em ambos os casos, vimos que a equipe de
Change Management pouco participou do processo de retirada da pessoas das suas atividades
nas áreas de origem e na sua integração com o projeto, bem como os gerentes não primaram
pela atenção e motivação de suas equipes.
A equipe de projeto mista foi um diferencial positivo para os resultados alcançados pelos
projetos, conforme confirmado pelos entrevistados das empresas A e B.
Como ressaltado por Cleland (1999)J3J, a delegação de responsabilidades em um projeto tem
um impacto positivo no seu próprio andamento e, na sua opinião, sempre que as decisões a
serem tomadas individualmente não gerem um impacto maior no orçamento, cronograma e na
utilização dos recursos disponíveis e além disso, se elas não criarem maiores problemas
130 FRAME, 1. Davidson. Gerenciando Projetos nas Organizações. 2001.
149
políticos, poderão ser tomadas pelos especialistas membros da equipe do projeto. Apenas as
questões mais cruciais deverão requerer o envolvimento direto do gerente de projeto. Desta
forma, o fato da alta administração ter delegado poderes à equipe do projeto B para buscar os
melhores resultados do projeto através da simplificação de processos internos e a adoção das
melhores praticas e processos mais aderentes às funcionalidades do sistema, fez com que
fosse possível implantar mais módulos e obter melhores resultados no projeto. Às vezes foi
até necessário conter a ansiedade de alguns de seus membros pois acabavam querendo o
impossível de ser alcançado o que por sua vez também faz aumentar os riscos no projeto.
A metodologia de Project Management ressalta a importância do processo de análise e
seleção do sistema na fase de concepção do projeto. Quando este processo não é feito com o
critério adequado, acaba sendo substituído, depois que o sistema é comprado, por um processo
análise de gaps. Nesse processo, são identificadas as diferenças entre as necessidades da
empresa e as funcionalidades disponíveis no sistema. A partir desta análise são planejados os
desenvolvimentos adicionais que necessitam ser efetuados no sistema através de
customizações. Desta forma, o projeto já se inicia com o prazo comprometido pois
normalmente a análise de gap 's é feita após a contratação do projeto à empresa de consultoria
que normalmente acaba por subestimar o prazo necessário para a implantação do sistema.
No estudo de casos tanto da empresa A quanto da empresa B, foi dito que essa análise de gaps
aconteceu em algum momento. Mesmo sendo o sistema na empresa A considerado como
corporativo, em algum momento a sua aderência às necessidades da organização foi
considerada. Entretanto, não foi feito um estudo mais profundo dos requisitos funcionais do
sistema antes de adquirir o produto no Brasil. Esse fato tomou necessário o desenvolvimento
de customizações adicionais, fazendo com que o projeto se desviasse do curso inicial.
Segundo o entrevistado, na Empresa A, a revisão de processos especificamente não se refletiu
em um verdadeiro problema para o projeto pois pelo fato da empresa não estar com seus
processos bem definidos, essa necessidade acabou por promover uma melhoria nos processos
ao invés de prejudicar o andamento dos trabalhos. Mas no caso de ser uma empresa mais
13l CLELAND (1999), David I. Project Management. Strategic Design and Implementation. 3rd. Edition. Singapore: McGraw-Hill, 1999.
150
estruturada e com seus processos mais amadurecidos, a falta de análise desses requisitos
versus processos, pode prejudicar muito mais do que facilitar o processo.
Uma forma de minimizar esses efeitos é limitar o projeto à implantação das funcionalidades
standard do sistema, diretriz dada à equipe de projeto nos dois casos. Entretanto, no caso da
empresa A, nosso entrevistado confirmou que o atraso do projeto deu-se também ao fato da
empresa ter excedido a quantidade de customizações necessárias.
A partir da revisão bibliográfica, identificou-se a importância que a gerência do projeto tem
como diferencial para o sucesso de projeto de implantação de sistemas de ERP. Comparando
as características existentes nos gestores dos projetos das empresas A e B com aquelas
apontadas pelos estudiosos do tema, vemos que existe um grande abismo entre os dois.
Nossos entrevistados apontaram a pouca experiência gerencial dos gerentes do projeto, tanto
da consultoria como dos gerentes funcionais. Tal fato, acreditamos, contribuiu negativamente
para os resultados do projeto. Através da análise dos estudos de caso ficou caracterizada a
inexistência de características de liderança nos gerentes de projeto das empresas A e B.
A revisão bibliográfica da metodologia de Change Management nos explica as principais
atividades de uma equipe de Change Management em um projeto como sendo a identificação
e gerenciamento dos Stakeholders, a elaboração do plano de comunicação, a elaboração de um
plano de treinamento e o apoio à gerência do projeto na identificação do perfil, seleção e
integração desses membros bem como possui um papel importante no apoio à liderança do
projeto durante a execução do mesmo.
Observamos que a equipe de Change Management, em ambos os projetos, teve participação
na concepção tanto do plano de comunicação quanto do plano de treinamento. Apenas teve
uma participação mais efetiva nas atividades de integração de equipes na empresa Bonde
realizou mais eventos de integração, o que fez uma diferença na hora de conseguir obter os
melhores resultados da equipe de projeto bem como na solução de conflitos.
Com relação a treinamento, existem diferentes momentos em que as necessidades de
treinamento são identificadas no projeto. O primeiro destes é durante o próprio projeto,
151
quando se identifica a necessidade de capacitar os membros da equipe de implantação no
manuseio da ferramenta para proceder à sua configuração. Com relação a esse tipo de
treinamento, foi identificado que eles não são suficientes para capacitar uma pessoa da área
funcional da empresa a parametrizar o sistema sozinha. Esses treinamentos apenas dão ao
membro da equipe de projeto da área funcional da empresa uma visão geral do módulo para
poder fazer contribuições de forma mais eficaz durante a parametrização do sistema. E sendo
assim, se faz mais necessária a participação de consultores experientes no projeto.
o segundo momento ocorre já no final do projeto, quando o sistema está para entrar em
produção. É quando todos os funcionários da empresa que irão manusear a ferramenta deverão
receber treinamento específico para o poder fazer. É responsabilidade da equipe de Change
Management, junto com o gerente do projeto e os gerentes das áreas funcionais da empresa,
identificar quais serão os usuários que deverão receber o treinamento e em quais módulos.
Acontece que nem sempre o usuário de determinada atividade recebe o treinamento adequado
ou seja, não se consegue identificar que tipo de treinamento é necessário para um ou outro
funcionário especificamente. Acabam por ocorrer erros na alocação de treinamento às pessoas
da empresa por falha, na hora de selecionar quem deverá ser treinado, da equipe de Change
Management ou dos próprios gerentes. Normalmente porque a alocação dos funcionários aos
treinamentos é feita por pessoas que não conhecem de ante mão o que será ensinado em cada
um desses treinamentos. Uma forma de minimizar essas falhas é fazer com que o líder de
equipe funcional de cada módulo, que conhece também as atividades de cada área, sugira essa
alocação.
E finalmente, o terceiro momento é aquele em que a equipe de Change Management prepara o
material de treinamento e deixa a empresa responsável pela sua atualização e a sua aplicação
através da implantação de um plano formal de treinamento. Neste caso, a equipe de Change
Management teve uma participação mais limitada no que diz respeito à questão do
treinamento tanto na empresa A quanto na empresa B, não tendo deixado um plano de
treinamento definido, contemplando a reciclagem periódica dos usuários do sistema através de
procedimentos formais de revisão de processos e treinamento, o que acaba comprometendo a
qualidade e os resultados a serem extraídos do sistema por parte dos usuários. A falta de
treinamento periódico nas novas funcionalidades do sistema, que vão mudando após as
152
melhorias implementadas nas fases seguintes ao projeto, faz com que vícios adquiridos
anteriormente se mantenham. E que erros cometidos no manuseio do sistema pelos atuais
funcionários acabem se repetindo quando são os próprios colegas de trabalho que terminam
por dar treinamento aos novos funcionários.
No que diz respeito ao mapeamento e gerenciamento dos Stakeholders, as duas equipes de
Change Management não realizaram nenhuma atividade subsequente nesse sentido. Foi
apenas feito um mapeamento inicial e nada mais foi desenvolvido.
As probabilidades de que se obtenham melhores resultados de um projeto que envolve um
elevado grau de mudança na organização aumentam ou diminuem em função da clareza, do
compromisso compartilhado por todos, da justificativa para as modificações propostas e do
processo como essa mudança é conduzida. Após implementada a mudança e concluído o
projeto, ao olhar para trás e analisar o que foi feito, com certeza se verá que muito ainda está
por fazer, muito ainda poderia ser melhorado, que algo sempre se poderia ter feito de outra
maneira. Entretanto, às vezes, algumas funcionalidades têm que ser deixadas para fases
seguintes, quando a empresa já tem mais cultura e domínio sobre a ferramenta implantada. A
empresa tem de se acostumar à nova ferramenta e, aos poucos, quando aprende a manuseá-la e
já a domina melhor, poderá implementar novas funcionalidades, pois se insistir em
implementar cada vez mais funcionalidades na primeira onda ou fase do projeto, se não se
detiver no escopo inicialmente previsto, o projeto não será concluído nunca. Sempre existirão
novos projetos como decorrência do projeto original pois o sistema é amplo e assim o permite.
A empresa B tinha muitas expectativas com relação aos resultados e às potencialidades
disponíveis no sistemas ERP que estava sendo implantado. Entretanto, dada a inexperiência
tanto da equipe de consultores nas funcionalidades existentes como da equipe funcional,
foram deixando de lado aquelas funcionalidades mais complexas para um momento futuro,
para quando tanto os usuários estivessem mais ambientados na ferramenta, como quando
houvesse conhecimentos por parte dos especialistas nos sistemas para implantar tais
funcionalidades, passando a se deterem mais nas funcionalidades standard para não
comprometer o projeto como um todo. Suas expectativas eram altas por que sua cultura estava
voltada para aceitar e propor mudanças com mais facilidade do que a empresa A. E por isso, a
153
empresa sempre exigiu muito tanto dos consultores como dos seus funcionários, participantes
do projeto, bem como uma maior dedicação e os melhores resultados. Entretanto, teve que
fazer um trade of! pois para alcançar esses objetivos teria que comprometer prazo e o custo do
projeto.
Como também comentado pelo entrevistado da empresa A, este disse que a partir do primeiro
projeto, as pessoas ficaram mais críticas e, conhecendo melhor o seu negócio, elas passaram a
exigir mais qualidade nos processos da empresa e passaram a propor mais melhorias e novos
desenvolvimentos que se sucederam à primeira onda da implantação do sistema de ERP.
A partir do que foi comentado anteriormente, é possível resumirmos na Tabela E -
Principais Recomendações a seguir, algumas recomendações importantes que poderão ser
consideradas por aqueles interessados em implantar sistemas de ERP futuramente.
Tabela E - Principais Recomendações:
PRINCIPAIS RECOMENDAÇÕES
• É importante dedicar tempo e ter critério na seleção da equipe (interna e de consultores), não tendo pressa na sua formação. É importante definir previamente o perfil necessário da equipe para o projeto;
• A constituição de equipes mistas minimiza a distância entre o conhecimento do negócio por parte dos consultores e o desconhecimento de metodologias de gestão de projetos e do sistema a ser implantado por parte da empresa, favorecendo os resultados a serem obtidos pelo Projeto de Implantação de sistemas de ERP;
• É importante investir na preparação da equipe (treinamento e desenvolvimento) pois ela será o futuro usuário e multiplicador do conhecimento do sistema dentro da organização;
• Investir no desenvolvimento gerencial do gerentes de projeto buscando despertar neles características de líderes;
• A delegação de poder favorece os resultados do projeto e incentiva o desenvolvimento gerencial dos líderes e da equipe;
• O estabelecimento de metas claras e o seu atingimento deverá ser compensado com recompensas durante o andamento do projeto como forma de motivar a
154
PRINCIPAIS RECOMENDAÇÕES
equipe;
• Se o projeto não for bem planejado e se forem identificados muitos gap's após o início deste, será necessário fazer um trade off entre escopo, tempo e custo e deixar as melhorias e funcionalidade mais complexas para projetos futuros;
• É importante buscar o apoio da equipe de Change Management que possui um perfil e foco em gestão de pessoas, para esse trabalho (definição de perfil, seleção, treinamento, acompanhamento durante o projeto e devolução do membro da equipe à sua área quando do encerramento do projeto);
• O retorno dos membros da equipe interna da empresa de volta às suas áreas após o encerramento do projeto necessita de acompanhamento da equipe de Change Management, apoiada pelo RH da empresa de forma a minimizar os impactos desses membros na reincorporação às suas antigas posições ou nos novos desafios;
• Proporcionar diversos em eventos de integração entre as equipes do projeto permitirá obter melhores resultados durante o mesmo;
• Investir num bom plano de Comunicação favorece a obtenção de melhores resultados no projeto não só em relação à equipe de projeto como em relação à empresa onde o sistema está sendo implantado, minimizando as resistências para com o projeto a partir de clara comunicação das metas e objetivos a serem alcançados com o mesmo;
• A identificação dos Stakeholders ajuda a mapear as áreas de resistência à mudanças trazidas pelo projeto e permite propor ações e atividades para romper essas barreiras e envolver a organização e seus membros nas mudanças e objetivos do projeto;
Como conclusão, poderíamos dizer que a utilização da metodologia de Gestão de Projeto
garante sim que o projeto chegue ao seu final, entretanto, outros fatores com os comentados
anteriormente serão o diferencial de sucesso ou fracasso dos projetos de implantação de
sistemas de ERP.
155
REFERÊNCIAS BIBLIOGRÁFICAS
BOND, B., ERP in 1996: Transition Begins and Risk Acce1erates, Gartner Group Research,
Stanford, CT, USA, 28/01/97
BOND, B., ERP Market Trends: Vendor Conso1idation, Gartner Group Research, Stanford,
CT, USA, 18/11/96
BOND, B., and ERP Markets Trends: Vendors Strugg1e to Stay Competitive, Gartner Group
Research, Stanford, CT, USA, 18/11/96
BOND, B., ERP Vendor Guide 1997: Overview and Reference, Gartner Group Research,
Stanford, CT, USA, 23/06/97
BOND, B., The ERP Midmarket: Questions and Answers, Part 1 & 2,Gartner Group
Research, Stanford, CT, USA, 19/07/96
BOND, B., ERP Vendor Guide 1995, Parts 1-5,Gartner Group Research, Stanford, CT, USA,
19/12/95
CARV ALHAL, Eugênio et FERREIRA, Geraldo. Ciclo de Vida das Organizações:
peopleware, liderança transformadora e desenvolvimento de equipes de alto
desempenho. Rio de Janeiro: Editora Fundação Getúlio Vargas, 1999.
«l CLELAND, David I. Project Management. Strategic Design and Implementation. 3rd. Edition.
Singapore: McGraw-Hill, 1999.
DAFT, Richard L. Teoria e Projeto das Organizações. Rio de Janeiro: LTC-Livros Técnicos e
Científicos Editora S.A, 1999.
FISHER, Prof. Dra. Rosa Maria. Mudança e Transformação Organizacional, - Mudando os
Paradigmas da Mudança, 2002.
FRAME, J. Davidson, Managing Project in Organizations, How to make the best use of time,
techniques and Peop1e, Jossey-Bass Inc. San Francisco, Ca1ifomia, 1995.
FREITAS, Maria Ester de. Cultura Organizacional: Identidade, Sedução e Carisma? Rio de
Janeiro: Editora FGV, 1999.
Qfl GUIA DO PMBOK, Project Management Institute, PMI, 2000
JONES, c., Custom ERP Functiona1ity: A Tactica1 Strategy, Gartner Group Research,
Stanford, CT, USA, 19/06/96
156
JONES, c., Deploying ERP: Compromise for Large/Complex Enterprises, Gartner Group
Research, Stanford, CT, USA, 29/04/97
JONES, c., ERP Scalability: Not a Given, Gartner Group Research, Stanford, CT, USA,
29/04/97
JONES, c., Larger-User ERP Market Update: Improved Execution, Gartner Group Research,
Stanford, CT, USA, 29/05/97
JONES, C., Larger-User ERP Market: 3Q96 Review, Part 1 & 2,Gartner Group Research,
Stanford, CT, USA, 11/10/96
JONES, c., The ERP Market Had Growing Pains During 1995,Gartner Group Research,
Stanford, CT, USA, 17/01/96
JONES, C., Do ERP Vendors Have Re-engineering Functionality? Gartner Group Research,
Stanford, CT, USA,27/12/95
JONES, c., Planning Guidelines for Implementing ERP, Part 1 & 2,Gartner Group Research,
Stanford, CT, USA, 27/03/97
KELLER, E., A Moming With SAP's Chairman, Gartner Group Research, Stanford, CT,
USA, 28/05/97
KELLER, E., Enterprise Wide Applications 1998: The "No Growth" Year?, Gartner Group
Research, Stanford, CT, USA, 25/09/96
KELLER, E., Enterprise Wide Applications 1998-2001: Shake-Out Time, Gartner Group
Research, Stanford, CT, USA, 25/09/96
KELLER, E., ERP 1996: Increased Focus and Competition, Gartner Group Research,
Stanford, CT, USA, 24/01/96
KELLER, E., Microsoft and SAP: Best of Friends?, Gartner Group Research, Stanford, CT,
USA, 20/03/97
KELLER, E., Revision: ERP Strategic Matrix: A 4Q95 Review, Gartner Group Research,
Stanford, CT, USA, 20/12/95
KELLER, E., SAP's Long-Term Focus: Market Domination, Gartner Group Research,
Stanford, CT, USA, 15/05/96
1 I
157
KELLER, E., SAP's Short-Tenn Focus: Client Satisfaction, Gartner Group Research,
Stanford, CT, USA, 15/05/96
KELLER, E., The Four R's ofERP, Gartner Group Research, Stanford, CT, USA, 29/11/95
LOZINSKY (1996), SERGIO, Administração do escopo do Projeto, Marketing SAP Brasil,
São Paulo, Brasil, SAPerspectiva, junho 97
LOZINSKY (1996), SERGIO, Software: Tecnologia do Negócio, Imano Editora Ltda., São
Paulo, Brasil, 1996
MARTINS, Gilberto de Andrade. Manual para Elaboração de Monografias e Dissertações.
São Paulo: Atlas, 1994.
. MOTTA, Paulo Roberto. Gestão Contemporânea: a ciência e a arte de ser dirigente. Rio de
Janeiro: Record, 1999.
MOTTA, Paulo Roberto. Transformação Organizacional. A teoria e a prática de inovar. Rio
de Janeiro: Qualitymark, 1999.
PFEFFER, Jeffrey. Vantagem Competitiva através de Pessoas. São Paulo: Makron Books,
1994.
PORTER, MICHAEL E., Vantagem Competitiva: criando e sustentando um desempenho
superior, Rio de Janeiro, Editora Campus, 1992,
SOARES, T. Diana. Práticas Gerenciais das Empresas Líderes no Brasil. Rio de Janeiro:
Qualitymark, 1996.
THE PRICE W ATERHOUSE CHANGE INTEGRA TION TEAM. Befter Change: Best
Practices for Transforming your Organization. USA: Irwin Professional Publishing,
1995.
VERGARA, Sylvia Constant. Gestão de Pessoas. São Paulo: Atlas, 1999.
V ALERIANO, Dalton L., Gerenciamento Estratégico e Administração de Projetos, Makron
Books, São Paulo, SP, 2001.VERGARA, Sylvia Constant. Projetos e Relatórios de
Pesquisa em Administração. São Paulo: Atlas, 1998.
~YIN, R.K. Case study research: design AND METHODS.2.ED.London:Sage,1994.
W ARD, J. LeRoy. Project Management Tenns - A Working Glossary. Arlington, Virginia.
ESI International, 1999.
1 !
158
ANEXO - QUESTIONÁRIOS PARA ENTREVISTAS
Data da entrevista: _____ ,/ _____ --'/ _____ _ Horário: Início: Fim: ---------
Empresa: ________________________________ _ Nome da Pessoa Entrevistada: ---------------------------Posição do entrevisto no Projeto: _______________________ _
PERGUNTAS
I. Os motivos
Responda o que você acha sobre:
1. Que levou a organização a mudar (no sentido de buscar um sistema ERP)? 2. Existia na organização sistema semelhante anteriormente? 3. Havia necessidade da substituição do sistema anterior? 4. O que você acha da opção pelo sistema selecionado? 5. Que fatores você acha que foram levados em consideração para a seleção desse sistema
(atribuições técnicas, o fato dele possuir um nome reconhecido pelo mercado, etc .. )
11. Levantamento técnico das necessidades
Na sua opinião, você acha que:
1. Houve um estudo prévio das qualidades do sistema? 2. Foram consultadas empresas que já fossem usuárias desse sistema? 3. Qual foi a opinião manifestada por elas? Qual o feedback e quais as recomendações que elas
fizeram? 4. As opiniões dessas empresas foram consideradas na hora de se optar pelo sistema ERP? 5. Foi feito um estudo/levantamento suficientemente profundo e abrangente dos requisitos
funcionais do sistema e sua aderência às necessidades operacionais da organização? 6. Foi feito um levantamento prévio dos processos em uso e da necessidade de readequação
desses processos em vigor ao novo sistema?
Se suas respostas forem negativas, na sua opinião, de que forma você acha que esses fatores possam ter influenciado negativamente no resultado do projeto?
111. A cultura da empresa
Responda o que você acha sobre:
1. Se a sua empresa costuma estar na vanguarda de novos processos de gestão, na adoção de novas ferramentas tecnológicas?
2. A organização (funcionários, gerentes e alta administração) aceita bem as mudanças? (Se necessário, analise separadamente cada um dos 3 grupos de usuários envolvidos).
3. A alta administração fomenta na organização mudanças de processos e métodos de trabalho?
l
159
4. A organização (funcionários e gerentes) aceitam bem a implantação de novos procedimentos de trabalho e novas ferramentas, principalmente tecnológicas como as ferramentas de ERP?
5. A organização (alta administração, funcionários e gerentes) busca e propõe melhorias de processos, novas metodologias e ferramentas de trabalho?
6. Os funcionários se sentiram ameaçados pela entrada do novo sistema?
A METODOLOGIA DE PLANEJAMENTO, FORMAÇÃO E GESTÃO DO PROJETO
IV. A escolha da Equipe de Consultores
Comente o que você acha sobre:
1. Os fatores que foram levados em consideração na seleção da equipe de consultores que participou e/ou conduziu o processo de implantação do sistema de ERP
2. A qualidade e preparação da equipe de consultores • equipe funcional (consultores)
• gerencia 3. A consultoria possuía experiência em outros projetos de implantação de sistemas de ERP?
Aproximadamente quantos?
V. A equipe de Projeto
1. Na sua opinião, como foi o processo de formação da equipe de projeto? 2. A equipe contou com membros internos à organização? 3. Caso positivo, você acha que essa participação contribuiu positiva ou negativamente para
o sucesso do proj eto? 4. Como foi o processo de seleção dos membros da equipe internos à organização? 5. Como foi a comunicação da saída desses membros à equipe em que eles estavam
inseridos? 6. E como foi o processo de aceitação dos demais membros do grupo à saída dessas pessoas
para a equipe do projeto? 7. Após o término do projeto, como foi o processo de reintegração desses membros à equipe
anterior?
Durante o projeto,
8. Como foi a integração entre a equipe de projeto do cliente e a equipe de projeto da consultoria?
9. Existiu algum "movimento formal" para a integração das equipes? 10. Qual a sua opinião a respeito dessas equipes mistas? 11. De que forma a existência de equipes mistas influencia (positiva ou negativamente) no
resultado dos projetos? 12. A existência de equipes mistas gera conflitos de interesses durante o projeto? (equipe do
cliente x equipe de consultores)? 13. Como foram administrados os conflitos? 14. Na sua opinião, de que forma esses conflitos foram benéficos ou prejudiciais ao projeto? 15. Na sua opinião, todos os projetos de implantação de ERP deveria contar com equipes
mistas?
1
160
VI. Treinamento
Na sua opinião, comente:
1. A equipe funcional da empresa recebeu treinamento adequado para operar e parametrizar o sistema a ser implantado?
2. Os demais usuários, em todas as áreas da organização afetadas, foram treinados para manusear o novo software?
3. Houve acompanhamento por parte do fornecedor e da consultoria de implantação durante o início da utilização do software?
4. Foi elaborado material e documentação adequados para administrar treinamento à organização?
5. Esse material é freqüentemente utilizado pela organização? 6. Foi desenvolvido e implantado um processo de treinamento periódico na empresa, para os
novos funcionários ou o seu treinamento é feito on the job por seus demais colegas? 7. Em que esse procedimento afeta a qualidade do trabalho e a utilização das funcionalidades do
sistema?
VII. A Gerencia de Projetos e a Liderança
• Gerentes de Projeto Externos
Dê a sua opinião, em relação ao (s) gerente (s) de projeto, a respeito de:
1. Quantos gerentes existiam no projeto? 2. Descreve um pouco a divisão de trabalho/tarefas entre eles caso houvesse mais de um
gerente. 3. Como você via o gerente de projeto em relação à sua capacidade de se relacionar com:
• a equipe • a média gerência do cliente (seus contrapartes)? • a alta administração do cliente
4. Suas habilidade e conhecimentos técnicos a respeito do projeto que estava sendo implantado?
5. Sua capacidade de administrar as atividades inerentes ao projeto como cronograma, recurso humanos e financeiros, crises entre os diversos membros da equipe e/ou entre equipe de consultoria e cliente?
6. Ele era uma pessoa carismática para a equipe e para o cliente? 7. Demonstrava interesse e comprometimento com os objetivos do projeto? 8. Qual era o seu estilo para conseguir que as tarefas fossem executadas (pela força
Ditatorial, pela negociação)? 9. Ele costumava delegar responsabilidades aos demais membros da equipe? 10. Negociava metas e prazos para o projeto com os demais membros das equipes
multifuncionais? 11. Premiava os resultados obtidos? 12. Lutava por mais recursos (humanos, financeiros, etc.) para o projeto?
l
161
13. Solicitava treinamento e proporcionava o continuo desenvolvimento dos membros da equipe e subordinados através não só de treinamentos como também através da participação em outros subprojetos do seu interesse?
14. Estava atento às necessidades e problemas pessoais da equipe? 15. Durante o projeto criou um canal de comunicação com a equipe e demais gerentes do
projeto? 16. Era ágil na tomada de decisões? 17. Ao identificar um obstáculo ou problema, conseguia identificar rapidamente uma solução
e implantá-la?
Caso suas respostas tenham sido negativas, de que forma você acha que esses fatores influenciaram o projeto (negativa ou positivamente)?
• Gerentes de Projeto da empresa
1. Ele demonstrava que o sucesso do projeto que ele coordenava garantiria o seu próprio sucesso e ascensão na organização?
2. Escutava as necessidades da equipe? 3. Agradecia e premiava/recompensava os esforços e os resultados obtidos pela equipe? 4. Desenvolveu durante o projeto um rede de relacionamentos com as demais área da
empresa ou outras empresas para conseguir atingir os objetivos ou completar tarefas exigidas pelo projeto?
5. Durante o projeto criou um canal de comunicação com a equipe e demais gerentes do projeto?
6. Era ágil na tomada de decisões? 7. Demonstrava interesse e comprometimento com os objetivos do projeto? 8. Premiava os resultados obtidos? 9. Lutava por mais recursos (humanos, financeiros, etc.) para o projeto? 10. Ao identificar um obstáculo ou problema, conseguia identificar rapidamente uma solução
e implantá-la? 11. A alta administração - Stakeholders 12. Conseguia transmitir à equipe a importância do projeto para a estratégia escolhida pela
organização? 13. Defendia o projeto junto às demais áreas da empresa afetadas por este? 14. Demonstrava preocupação com as necessidades da equipe e gerentes do projeto (tanto
gerentes e equipe externa quanto à equipe interna da organização)? 15. Lutava por mais recursos para o projeto? 16. Agradecia e premiava/recompensava os esforços e os resultados obtidos pela equipe? 17. Desenvolveu durante o projeto uma rede de relacionamentos com as demais área da
empresa ou outras empresas para conseguir atingir os objetivos ou completar as tarefas exigidas pelo projeto?
18. Durante o projeto criou um canal de comunicação com a equipe e gerentes do projeto? 19. Era ágil na tomada de decisões?
VIII. A Comunicação
Na sua opinião, o que você acha:
1. Da forma como as novidades são comunicadas na organização?
162
2. Da forma como foi comunicada na empresa a aquisição de um novo sistema? 3. Da forma como foi comunicada a formação da equipe de trabalho do projeto? 4. Da forma como foi comunicado o andamento (em todas as suas fases) do projeto? 5. Da forma como foi o processo de retomo dessa equipe às suas funções rotineiras após a
conclusão e encerramento do projeto? 6. Do formato do Canal de Comunicação utilizado pela empresa para divulgar as notícias do
projeto e o seu andamento? 7. Na sua opinião ele era eficiente? 8. O que você poderia sugerir como um bom Canal de Comunicação?
IX. O resultado
Na sua Opinião, como foram os Resultados alcançados pelo Projeto em termos de:
• Escopo 1. A proposta inicial do projeto foi atendida? 2. Os objetivos comunicados no início do projeto foram alcançados? 3. Ao concluir o projeto, tudo o que inicialmente foi previsto fazer foi feito ou foi
deixada alguma parte para uma fase posterior? 4. Na sua opinião, porquê isso aconteceu? 5. Foi prejudicial ou benéfico ao projeto? 6. Continuam havendo pequenos novos projetos como consequencia do projeto
inicial? Por que motivo? Porque ficou faltando fazer alguma coisa ou por quê uma coisa puxa a outra e se identificou ser necessário estender algumas funcionalidades do sistema e usá-las no dia a dia?
7. Na sua opinião, as mudanças nos processos da empresa e no seu próprio negócio, continuaram exigindo que fossem feitos desenvolvimentos contínuos no sistema, posteriores ao encerramento,
• Prazo 1. O projeto foi concluído no prazo? 2. Porquê (do atraso ou do cumprimento do prazo)?
• Custo 1. O projeto foi concluído dentro do custo previsto? 2. Qual o percentual de desvio entre o custo inicial e o efetivamente cumprido? 3. Porquê?
