Porque projetos ERP's falham?

faelcavalcanti:

Bom dia, seguindo a mesma pergunta do recente artigo da publicado na computer world sobre fracasso de projetos ERP, me despertou interesse em compartilhar esta discussão no contexto de desenvolvimento de software, do porquê, tantos ERP’s falham!

Então, em IHMO, dos últimos fatores eu colocaria aspectos técnicos, dos primeiros seriam problemas culturais, gerenciais e burocráticos, mas qual o seu ponto de vista sobre o assunto e principais fatores que contribuiram para não obter o êxito final esperado?

Artigo : http://computerworld.uol.com.br/gestao/2009/08/18/porque-os-projetos-de-erp-fracassam/

Oi,

Não são apenas projetos de ERP que falham, todos os projetos de TI falham…

Na minha opinião os motivos principais são: inexistência de padrões de qualidade que sejam seguidos nas empresas - você não constrói uma ponte que não siga as normas de qualidade

Projetos de SW voltados para a entrega, não se preveem as necessidades de atualização, melhoria, correção de bugs, a única coisa que importa é cumprir um prazo estapafurdio que foi imposto por alguém que normalmente não tem a menor noção do que precisa ser feito e de quanto tempo precisaria ser gasto para construir um sistema de qualidade…

Tem uma outra coisa que eu acho que pode ser acrescentada também, falta de comunicação, muitas vezes as áreas não se comunicam, business não fala com desenvolvedores que não fala com gerência que não fala com suporte etc

outro link - que achei no artigo que postou - e que explica também muitas situações

as empresas não conseguem dimensionar o valor da TI, para o business muitas vezes o sistema nada mais é do que uma ferramenta, e como é deles que parte o dinheiro…

http://computerworld.uol.com.br/gestao/2009/08/11/empresas-ignoram-valor-da-tecnologia-para-os-negocios-diz-gartner/

Eu já acho que hoje em dia até que se falam, mas não se entendem. Estão mais preocupados com o “levar vantagem” do que com a empresa. E no tocante a isto tem o fato de que confundem muito sistemas em sua essencia com computação, primeiro deveriam melhorar “o sistema” depois coloca-lo em um mundo eletronico. Por isso muitas vezes acabam informatizando a bagunça.

À principio costuma a pensar (hoje nem tanto assim) que a TI não tráz dinheiro para dentro da empresa diretamente, a não ser que a empresa venda software, portanto ela é fonte de altas dispesas (e casos de insucessos) fazendo com que evitem bastante os investimentos e caiam nos contos de prazos curtos. Nesse tocam acho que faltam também um estudo para saber o real ganho do investimento na construção dos sistemas.

flws

Eu já acho que hoje em dia até que se falam, mas não se entendem. Estão mais preocupados com o “levar vantagem” do que com a empresa. E no tocante a isto tem o fato de que confundem muito sistemas em sua essencia com computação, primeiro deveriam melhorar “o sistema” depois coloca-lo em um mundo eletronico. Por isso muitas vezes acabam informatizando a bagunça.

Muito bem colocado.
Em uma disciplina da faculdade vimos casos onde houve exatamente essa informatização da bagunça onde levou a empresa pro buraco mais rapidamente, pois fez exatamente o que se propôs: acelerou o processo.
Ainda creio que em muitas empresas há falha de comunicação grave e é isso que justamente me tem chamado atenção no scrum, a comunicação entre os setores, muitos dos problemas que passo hoje seriam resolvidos por isso e evitaria MUITA refatoração.

Abraços!

Eu já acho que hoje em dia até que se falam, mas não se entendem. Estão mais preocupados com o “levar vantagem” do que com a empresa. E no tocante a isto tem o fato de que confundem muito sistemas em sua essencia com computação, primeiro deveriam melhorar “o sistema” depois coloca-lo em um mundo eletronico. Por isso muitas vezes acabam informatizando a bagunça.

Muito bem colocado.
Em uma disciplina da faculdade vimos casos onde houve exatamente essa informatização da bagunça onde levou a empresa pro buraco mais rapidamente, pois fez exatamente o que se propôs: acelerou o processo.
Ainda creio que em muitas empresas há falha de comunicação grave e é isso que justamente me tem chamado atenção no scrum, a comunicação entre os setores, muitos dos problemas que passo hoje seriam resolvidos por isso e evitaria MUITA refatoração.

Abraços!

eu penso que este jeito acelarado de ser tem tudo a ver com o modelo americano - workaholic - empresas de cultura européia acho que as coisas são um pouco diferentes

t

Software é uma doutrina recente e muito empírica…A preocupação de fazer algo organizado é de longa data, mas modelos, padrões, documentações e foco em projeto só tiveram ações efetivas nos últimos 10 anos.

Já trabalhei fora do Brasil, em empresas líder de segmento e não se ve nada muito diferente do que se vê por ai e do que foi citado: foco na entrega e péssimo planejamento.

Obviamente há uma preocupação em melhora, países como suécia já tem isso mais avançado, mas o mercado ainda tem muita gente no passado.

Criou-se a cultura de fazer tudo para ontem e hoje quando se tenta mostrar que qualidade exige prazo, ninguém aceita.

Os seniors do exterior são na maioria dissidentes de outras áreas: economistas, administradores, ex-soldados etc…que começaram a mexer com software. Ou seja, ninguém foi formado na ‘geração software’ onde as boas práticas e doutrinas já estavam se solidificando.

E o fato de software ser ‘soft’ (sem trocadilhos) é o que facilita a ‘zona’. Para se fazer um carro vai no ´mínimo 5 anos de projeto e ensaios porque se um ferramental errado ou erro nos cálculos vai ser uma dificuldade infinita corrigir, visto que metal é metal…não se ‘dobra’ não se dá gato etc etc.

Software, começa de um jeito e morre de outro totalmente diferente, por ser soft é facil gambiarriar.

Somando isso aos ERPs acho que tá mais que explicado, e ainda o fato que poucas pessoas realmente seguem os processos. Para seguir o jeitinho brasileiro, haja flexibilidade!

O negócio é simples como o amigo acima disse:

“A única coisa que importa é cumprir um prazo estapafurdio que foi imposto por alguém que normalmente não tem a menor noção do que precisa ser feito e de quanto tempo precisaria ser gasto para construir um sistema.”

Depois vem os cara querer pressionar os programadores do “pq vc n consegue fazer nenhuma tarefa no tempo q nosso ‘deus’ estipulou?”

Eu to cagando e andando pra tempo de tarefa.

diretor:

- Falta de uma camada de gerenciamento de projetos;

• Falha no planejamento do projeto;
• Processos críticos de negócios mal definidos;
• Falha em detalhar os processos nas pontas;
• Falta de envolvimento do pessoal das pontas;
• Falha em preparar o sistema para agüentar os picos de utilização;
• Evangelizar os patrocinadores do projeto;
• Iniciar a implantação antes de definir o escopo;
• Estouro do escopo;
• Grandes modificações de software padrão;
• Falhas de testes;
• Falta de treinamento;
• Falhas ao carregar os dados no sistema;
• Falha no “cut over” (chique, nao?));
• Falhas após o “go live” (com Visa);
• Deixar os testes para depois do “go live”.

Ou seja, o grande motivo eh que e o pessoal que anda envolvido nesses projetos eh bem ruim.

depois de dias, voltando a manter este assunto em pauta de discussão no fórum, vi que o Standish Group disponibilizou um artigo recente sobre o assunto:

Boston, Massachusetts, April 23, 2009 - New Standish Group report shows more project failing and less successful projects.

The Standish Group’s just-released report, “CHAOS Summary 2009,” “This year’s results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions” says Jim Johnson, chairman of The Standish Group, “44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used.”

“These numbers represent a downtick in the success rates from the previous study, as well as a significant increase in the number of failures”, says Jim Crear, Standish Group CIO, “They are low point in the last five study periods. This year’s results represent the highest failure rate in over a decade”

In the “CHAOS Summary 2009” report The Standish Group has re-examined 10 the CHAOS Success Factors. Each Success factor is supported by one of the Laws of CHAOS. The Standish Group’s “CHAOS Summary 2009” report is available free of charge to Standish Group subscribers. Non-subscribers may obtain copies directly from The Standish Group for $99.00 per copy and the offer also includes Jim Johnson’s book “My Life is Failure”.

About The Standish Group International, Inc. Since 1985 The Standish Group, the leader in spotting future trends, has been helping end users and vendors of technology solutions prepare for the future. The Standish Group delivers fast, consistent and reliable IT advice built on a solid foundation of primary research. For further information on project studies and other trends, visit our website at: www.standishgroup.com.

no entando, fiquei me perguntando dos seguintes questionamentos:

1. de uma forma geral, parece que não estamos evoluindo, pelo contrário, estamos em crescente aumento de projetos que não vem dando certo, e porquê será ?
2. o mercado está sendo exigente demais com softwares mais complexos, e nós com novas tecnologias, metodologias e processos não estamos conseguindo dar conta ?
3. será que os esforços estão sendo dirigidos para algo não relevante ou que devidamente importa ?
4. quanto de culpa você acha que o cliente tem nisto ?
5. estamos sendo amadores a profissionais, o que você acha ?
6. como continuará a ser o futuro, não deveríamos ter mais tempo livre após final de um projeto ou estamos sendo escravizados pela nossa ineficiência do que fizemos ou com quem fizemos ?
7. afinal, você tem medo do futuro do seu projeto que te espera logo em breve ?

achei interessante também compartilhar aqui uma nota de artigo de um colega da UFPE sobre o assunto, onde ele mencionou um ponto importante que destaco abaixo:

<blockquote>Outra causa do fracasso consiste na incapacidade de negociar conflitos entre os indivíduos envolvidos (equipe, cliente, usuários ou qualquer outro afetado pelo projeto). A esse problema, também estão relacionados:

? Objetivos nebulosos (não existe uma visão comum, compartilhada, entre o que o cliente deseja e o que a equipe do projeto está construindo);

? Expectativas irrealistas (o cliente ou usuários, por exemplo, podem não estar cientes do escopo a ser atingido dentro dos recursos e prazos existentes);

? Quebras de comunicação (como pouca documentação do processo e do produto em construção, informalidade excessiva e mal-entendidos, por exemplo).</blockquote>

Ola pessoal, mudando de assunto mas falando da mesma coisa:

Li em algum lugar (desculpem, não encontrei onde foi) que no Brasil é comum se fazer projetos com prazos impossíveis de cumprir para depois ficar se desculpando com o cliente, enquanto lá fora os cara fazem tudo com um prazo exagerado para que possam “surpreender” e entregar antes do previsto. Essa informação procede?

Um dos motivos que eu acho que os projetos de TI falham é que os nossos Caciques não estão preparados para serem caciques, e ai a indiarada fica tudo perdida! :lol:

eu sempre vi isto nos documentários da discovery channel e national geographic