Anatomia de uma classe de falha de folha de pagamento de ERP=

Anatomia de uma falha na folha de pagamento do ERP

É uma história triste. Um governo que busca substituir a tecnologia legada, mitigando riscos e economizando dinheiro público ao modernizar a folha de pagamento. O resultado: mais de ¼ dos funcionários públicos têm problemas de remuneração - em sua maioria, são mal pagos. Alguns não foram pagos de forma alguma. Um observador chamou isso de "desastre. Isso se tornou altamente politizado, com histórias diárias na imprensa canadense.

Para aqueles que não estão familiarizados com os problemas do sistema chamado "Phoenix", confira a linha do tempo do Corporação Canadense de Radiodifusão (CBC).

Todos nós reconhecemos que a mídia pode se concentrar mais no sensacionalismo e menos nos detalhes técnicos do projeto e do software. O governo atual festao governo anterior festa e o integrador de sistemas foram todos culpados. O objetivo deste registro é fornecer uma análise mais imparcial.

O que está faltando na cobertura da mídia é que esse tipo de problema não é incomum. Os Estados Unidos Escritório de Prestação de Contas do Governo conclui "os projetos federais de TI frequentemente incorrem em excessos de custos e atrasos no cronograma, contribuindo pouco para os resultados relacionados à missão." As complexidades na gestão financeira pública e a dimensão política levam a mais problemas na projetos de TI do governo do que no setor privado.

Decisões racionais e humanas tomadas

Sejamos claros: as decisões tomadas pelos funcionários públicos na aquisição e na implementação são racionais e estão dentro do padrão típico das decisões de tecnologia da informação tomadas por governos e grandes empresas. Isso inclui:

  1. Seleção do sistema ERP (Enterprise Resource Planning) mais bem-sucedido para recursos humanos e folha de pagamento: Oracle PeopleSoft: O Phoenix é um módulo do PeopleSoft 9.x, o que dá ao governo do Canadá um forte motivo para transformar 70 sistemas diferentes de gerenciamento de recursos humanos atualmente em uso nos departamentos do governo federal em um único PeopleSoft 9.x (MyGCHR).”

  2. Concorrência entre empresas integradoras de sistemas estáveis e comprovadas durante o processo de aquisição. A IBM venceu o processo de licitação competitiva. A IBM é uma empresa eminentemente qualificada. Essa combinação de ERP de nível 1 e integrador de sistemas de nível 1 é uma estratégia estabelecida para reduzir os riscos.

  3. Orçamento racional, que, segundo informações, está em torno de C$300M, com um preço muito atraente de ROI do projeto. Esperava-se que a mudança para centralizar a folha de pagamento reduzisse as necessidades de pessoal e de tecnologia da informação.

  4. Regras de negócios bem compreendidas para a produção da folha de pagamento no Canadá. É verdade que o regime de folha de pagamento é complexo, mas é altamente codificado. Há vários aplicativos que foram usados em regimes de folha de pagamento descentralizados anteriores que encapsulavam essas regras.

É difícil argumentar contra as decisões tomadas. É fácil em retrospectiva.

O que deu errado?

É difícil interpretar os detalhes da implementação a partir dos relatórios da mídia. Todos nós sabemos que grandes projetos de TI são arriscados no governo. Talvez eu esteja lendo as entrelinhas, mas aqui estão alguns padrões observados em outros governos:

  1. Grande nem sempre é melhor, como Eu indiquei em um artigo anterior entrada no blog sobre serviços compartilhados do governo, big não é sinônimo de melhor.

  2. A culpa não contribui para um ambiente de sucessoConforme apontado pelo analista do setor Michael Krigsmann: "Há uma série de projetos de TI fracassados em que todos apontam o dedo para os outros e não há ninguém que assuma a responsabilidade.”
  3. Aumento do compromisso é uma dinâmica organizacional típica em que as organizações "quando confrontados com resultados cada vez mais negativos, em vez de alterar seu curso.”

  4. Foco na entrega pontual em grandes projetos geralmente resulta na aceitação de baixa qualidade. Esse é um problema clássico identificado no "triângulo do gerenciamento de projetos" - rápido, bom e barato. Os relatórios sugerem que os bônus dos funcionários públicos estavam vinculados ao cumprimento de prazos. Isso cria incentivos perversos aceitar a baixa qualidade em favor da condução do projeto com base no plano original do projeto.
  5. Personalização do PeopleSoft para atender às necessidades das regras de negócios, acrescentam riscos. ERP legado Os sistemas de software de prateleira, projetados para o setor privado, geralmente exigem uma personalização significativa do código para atender às complexas regras comerciais do governo. Muitos governos acham que o esforço para personalizar sistemas prontos para uso por meio de programação é um fardo tão grande quanto o desenvolvimento do zero.

  6. Treinamento nunca é concluídoA tecnologia de gerenciamento de dados, especialmente para sistemas ERP, é um fator crítico para o sucesso. Ainda não está claro se houve um falta de treinamento ou não. Não parece provável que qualquer falta de treinamento seja responsável por nomes de funcionários desaparecem aleatoriamente do sistema.

  7. Gerenciamento de riscos não se trata de evitar riscos, conforme apontado em um entrada anterior do blogEm um cenário de risco, a seleção de fornecedores estabelecidos não anula a responsabilidade dos clientes de mitigar o risco.

Qual é a solução para o problema?

A pressão política e o intenso escrutínio da mídia não são uma receita para o sucesso. Os projetos de alto risco geralmente sofrem com a redução da consideração de ideias inovadoras e com a dependência da decisão dos gerentes seniores em vez daqueles que podem ser mais qualificados. As soluções típicas para os problemas de TI não parecem ser realistas:

  1. Colocar mais pessoas no projeto é provável que gere ainda mais problemas, conforme articulado na década de 1960 no "Mês do Homem Mítico.”

  2. Reverter para o sistema anteriorA nova configuração do novo sistema pode não ser realista, dadas as demissões de funcionários públicos que operavam o sistema descentralizado anterior.

  3. Reapresentação de propostas para um novo integrador de sistemas ou um software diferente parece ser tarde demais.

Aqui estão algumas ideias úteis:

  1. Auditar a governança, os processos e a documentação do projeto para determinar se o projeto pode ser aprimorado por meio de metodologias ágeis ou pontos de revisão e fazer alterações.

  2. Ajustar o escopo e o tempo das entregas para que o projeto não seja apresentado como um "big bang" em que 100% de todos os problemas precisam ser resolvidos até 31 de outubro. As classes de tipos de pagamento devem ser entregues em iterações, começando com as mais afetadas.

  3. Criar uma estratégia de mitigação de riscos em que o gerenciamento se concentra nas áreas de maior preocupação de probabilidade x impacto.

  4. Comunique-se além da imprensa aos funcionários e cidadãos, que são as partes interessadas mais importantes. A mídia está definindo a narrativa, e ela pode ser totalmente enganosa.

Tópicos

Contato