Doug Hadden, VP de Produtos
O Inspetor Geral do Departamento de Defesa dos Estados Unidos publicou "Sistemas de planejamento de recursos empresariais, atrasos de cronograma e deficiências de reengenharia aumentam o risco para as metas de auditabilidade do DoD" em 13 de julho. Isso vem logo após o Government Accountability Office "Gestão financeira do DOD: Status relatado dos sistemas de planejamento de recursos empresariais do Departamento de Defesa" de 30 de março. (E, o Relatório do National Audit Office do Reino Unido e a pesquisa da Panorama que constatou que os excedentes de projetos de software de ERP são "assustadoramente comuns'.) O relatório do Inspetor Geral fornece mais detalhes financeiros sobre cinco dos projetos listados pelo GAO e acrescenta informações sobre outros dois projetos. Seis projetos foram abordados pelo GAO, mas não pelo Inspetor Geral.
Essas novas informações exigem uma atualização de uma postagem anterior do blog.
Estatísticas de custo vs. orçamento
- Os 13 projetos têm os acrônimos de: AF-IPPS, DAI, DEAMS, EBS-EC, EBS-Procurement, ECSS, GCSS-Army, GCSS-MC, GFEBS, IPPS-A, IPPS-Navy, LMP, Navy ERP
- 4 de 13 projetos de ERP devem custar entre 100% e 120% do orçamento original
- 4 de 13 projetos de ERP devem custar mais do que o dobro do orçamento original
- Todos os 13 projetos estão usando o software COTS ERP líder dos dois principais fabricantes, incluindo o pacote de RH líder adquirido por um dos principais fabricantes de ERP
- Os três projetos de RH estão usando a mesma configuração ou similar, o que pode explicar por que os projetos estão praticamente dentro do orçamento.
- O custo médio estimado do ciclo de vida dos projetos foi de $1,355B e o custo estimado atual do ciclo de vida (porque a maioria dos projetos ainda não foi concluída) é de $2,316B. Isso representa uma média de quase $1B por projeto - embora seja justo observar que dois projetos
- De acordo com o Inspetor Geral: "O DoD sofreu aumentos no custo do ciclo de vida de $8,0 bilhões e atrasos no cronograma que variaram de 1,5 a 12,5 anos durante o desenvolvimento e a implementação do sistema."
Conclusões do Inspetor Geral
O inspetor geral recomendou que "o DCMO do DoD e os CMOs do Exército, da Marinha e da Força Aérea desenvolvam procedimentos para analisar os processos de negócios e limitar o financiamento de programas que não estejam demonstrando uma reengenharia adequada dos processos de negócios". O relatório fornece boas evidências sobre a falta de articulação dos processos de negócios existentes e futuros e de sua aprovação.
Culpando a vítima
Parece haver uma suposição geral no mercado de que não há nada de errado em implementar no setor público um software de planejamento de recursos empresariais desenvolvido para o setor privado. O fracasso do projeto é atribuído à falha no gerenciamento do projeto.
Realmente precisamos considerar o valor real e a Custo total de propriedade real do uso do ERP no governo. E precisamos parar de culpar a vítima pelo fracasso do projeto. É claro que meu ponto de vista é tendencioso, pois sou fornecedor de software de Planejamento de Recursos Governamentais (GRP) específico para o governo. Aqui estão minhas conclusões:
- Os fabricantes de ERP, em projetos da ordem de 100 milhões de dólares, devem fazer parte da estrutura de governança e adaptar ativamente o software para atender às necessidades críticas do governo. Os integradores de sistemas e os especialistas em TI do governo não devem ser responsabilizados por uma personalização significativa.
- As chamadas "melhores práticas" para o governo claramente não estão implementadas nesses pacotes de ERP. Se essas práticas estivessem incorporadas ao software (sem mencionar as "práticas recomendadas" de cadeia de suprimentos e logística do setor privado), a "reengenharia de processos de negócios" teria sido um exercício de ajuste de modelos existentes. Apesar de todo o marketing sobre "mercados verticais", parece que os fabricantes de ERP têm pouco interesse em entender de fato as necessidades do Departamento de Defesa.
- Os projetos transformacionais que tentam mudar os processos de negócios e integrar vários sistemas devem ser liderados por especialistas em gerenciamento de domínios e mudanças, e não por especialistas em TI - essa é uma grande lição aprendida em nossa prática de gerenciamento financeiro público.