De modo geral, um ERP consiste em um sistema/software que auxilia os usuários e gestores a administrarem toda a empresa, incluindo processos de finanças, recursos humanos, produção, cadeia de suprimentos, serviços e outros.
É um sistema que integra grande parte das operações da empresa, facilitando muito a vida das organizações, inclusive em cumprimentos tributários e legais.
Cada vez mais as empresas estão investindo em informatização, dependendo fortemente de sistemas ERPs como ferramenta vital de apoio para que seus processos rotineiros sejam executados com mais agilidade e exatidão, mitigando diversos riscos à saúde da organização.
Geralmente os clientes buscam estas soluções no mercado, fazendo orçamentos com implantadoras quer trazem o software a ser implantado, assim como fazendo orçamentos diretamente com os fabricantes e proprietários intelectuais destes sistemas, que podem ou não indicar implantadores parceiros autorizados comerciais, dependendo o caso.
Ainda existe a possibilidade, antes de qualquer contratação, da empresa licitante contratar uma terceirizada independente para realizar uma análise de aderência prévia, assim como levantar requisitos para entregar, posteriormente, estes elementos prontos na mão da implantadora escolhida, determinando se é mais fácil a empresa ficar aderente ao sistema escolhido utilizando suas funcionalidades nativas ou, se é necessário customizar tal solução, para esta passar a ser aderente as necessidades da empresa.
Neste ponto, vale ressaltar que de acordo com Gartner, resumidamente e por aproximação, 70% dos projetos falham no cumprimento de cronograma, custos e metas de qualidade e 50% são executados acima do orçamento.
Pesquisas da KPMG destacam que menos de 40% dos Projetos de TI alcançaram os objetivos de negócios um ano depois.
De acordo ainda com Chaos Report, mais de 30% dos Projetos poderão ser encerrados antes do seu término. Ainda existem resultados mostrando que mais de 50% dos Projetos custarão quase 200% do valor estimado antes do início dos trabalhos.
Em relação ao processo de venda ou comercialização de um ERP para um cliente, fica claro o quanto as expectativas de uma grande porcentagem de clientes não são atendidas, não só em relação as funcionalidades, mas também relacionadas a prazo e custo.
É com base na relação “prometido versus entregue” que ocorrem muitas das discussões judiciais relacionadas a implantação de sistemas ERPs.
O “Chaos Report” apresenta conceitos e dados elucidativos para o caso em tela, muitas vezes provenientes de uma venda malfeita e um contrato malfeito ou ainda mal revisado.
Vale destacar que o “The Standish Group”, renomada organização de pesquisa, a décadas atrás já havia emitido diversas publicações correlatas a este tema, auxiliando os envolvidos neste mercado a levantarem inclusive indicadores relacionados aos problemas e impactos destes projetos quando fracassam.
Fez parte das avaliações os números de fracassos de Projetos em inúmeras empresas. Para este estudo, menos de 10% dos Projetos de empresas grandes foram bem-sucedidos. Em relação a empresas de médio porte, entre 15% e 30% foram um pouco mais bem-sucedidos. O restante dos Projetos, todos sofreram questionamento, ultrapassando a margem dos 60% de projetos questionados e, muitos destes certamente fazem parte das estatísticas dos Projetos sem sucesso que foram parar no Poder Judiciário.
Com isso, pode-se concluir que Projetos em empresas de porte grande falham em aproximadamente 30% dos casos, seja por custo mais alto, prazo, qualidade e, o mais importante, a grande totalidade destes Projetos não tiveram um contrato bem definido, ou seja, não ficou claro para as partes, em sua totalidade, deixando margem para uma posterior discussão no Poder Judiciário.
Ainda há trabalho a ser feito em torno de alcançar resultados bem-sucedidos de projetos de desenvolvimento de software e, isso inclui a formulação de bons contratos, prevendo exatamente o que ambas as partes desejam. Tal estudo resume os resultados dos projetos nos últimos cinco anos, utilizando a definição de fatores de sucesso.
Como resultado do estudo, índices foram criados, a exemplo do índice “projeto de sucesso”, “projeto desafiado” e “projeto prejudicado”, do qual é discutido aqui.
Desta forma, o que muitas vezes acaba restando as partes, no final, para discussão, é o contrato e o que consta nele, exceto cenários específicos.
Um projeto, antes de ser iniciado, quando de sua comercialização ou venda, trata de algo que irá envolver a todos: o alinhamento de expectativas.
Neste momento, é de suma importância, tudo que for definido, posteriormente constar em contrato, do qual deverá ser revisado pelas partes e o que lá não constar, deverá ser questionado, para evitar futuros desentendimentos do tipo: “não foi isso que eu te vendi” ou “não foi isso que eu comprei”.
De acordo com Robert L. Glass (2002), em seu livro fatos e falácias da engenharia de software, assim como com os comentários de Elias Dornelas (2012),
- “O fator mais importante no trabalho com software não são as técnicas ou ferramentas usadas pelos desenvolvedores, e sim a qualidade dos próprios desenvolvedores. Esse fato é sabido, evidenciado e documentado desde os anos 70. Apesar disso, muita gente decide "cortar custos" na hora de contratar desenvolvedores e depois tenta instigar qualidade com metodologias, processos e ferramentas. Seguidamente aparecem abordagens mesmo anti-pessoas, que tentam transformá-las em engrenagens numa linha de montagem, e serem facilmente substituíveis. Um exemplo famoso é o CMM - Capability Maturity Model do Software Engineering Institute (SEI), que se alastrou nas empresas públicas americanas (e vem fazendo o mesmo nas brasileiras...), que é baseado na percepção errônea de que o caminho para bom software é um bom processo. Not so! Mas veja o site do CMMI... O hype lá cativa qualquer gerente!”
- “As duas maiores causas de projetos saírem do controle são (a) péssimas estimativas e (b) requisitos instáveis. Estimativas são frequentemente feitas pelas pessoas erradas (que não têm conhecimento o suficiente sobre como software é construído), no momento errado (no início do projeto, antes de qualquer trabalho pra descobrir exatamente o que será feito), nunca são ajustadas ao longo do projeto, e apesar disso tudo ainda são levadas a sério por todo mundo -- isso acaba gerando expectativas inalcançáveis desde o início, estresse desnecessário e moral-baixa das equipes. Já requisitos instáveis é um problema mais complicado, e a engenharia de software vem tentando abordagens diferentes em busca de soluções (depois de falhar miseravelmente tentando achar um jeito de obter um conjunto fechado de requisitos no início do projeto). Hoje, já é aceito como natural os requisitos sofrerem alterações ao longo do projeto, e a controvérsia está mais em como lidar nessas circunstâncias.
Não é preciso um entendimento tão profundo para concluir que levantamento de requisitos e contratos de venda e implantação de sistemas incompletos ou mal elaborados estão sujeitos a auditoria e posterior identificação e divisão de responsabilidades em casos de prejuízos que porventura o cliente possa sofrer em decorrência disso.
REFERÊNCIAS
NORMAS ABNT. Metodologia científica. Disponível em: https://www.normasabnt.org/metodologia-do-trabalho-cientifico/. Acesso em: 20 jun. 2022.
GLASS R.L. Facts and Fallacies of Software Engineering, Journal of Object Technology, Volume 2, no.1 2002.
MUNDO PP. Disponível em: http://www.mundopm.com.br/noticia.jsp?id=280. Acesso em: 20 jun. 2022.
INFOQ. Disponível em: https://www.infoq.com/articles/standish-chaos-2015. Acesso em: 20 jun. 2022.
PMFSCR2015. Disponível em: https://www.linkedin.com/pulse/project-management-failures-standish-chaos-report-2015-dunbar. Acesso em: 20 jun. 2022.
DORNELES E. Disponível em: https://eliasdorneles.com/2012/12/03/fatos-e-falacias-da-engenharia-de-software---notas-do-livro.html. Acesso em: 20 jun. 2022.
Prof. Fabio Vivan Grigollo - Doutorando em Projetos - APEJESP 1794
contato@iconsys.org - +55 (11) 98281-3008
http://lattes.cnpq.br/8762946224709802