Fénix a cair ou Fénix a nascer?
Notícias sobre o sistema central de processamento de salários do Governo do Canadá que utiliza o ERP PeopleSoft, cada vez mais ironicamente designado por "Sistema de pagamento Phoenix", é desencorajador. O CBC refere que 228 000 casos no final de julho. Durante o mês, foram acrescentados milhares de novos casos, o que resultou numa redução líquida de 18.000. Os o governo tinha-se comprometido, em junho do ano passado, a resolver os problemas até ao final de outubro. O meu twitter mostra uma grande frustração entre os funcionários públicos. Muitos perguntam-se porque é que o problema não pode ser resolvido.
Esta implementação do ERP tornou-se altamente politizada. As comunicações do governo são vagas. A imprensa política desconhece a tecnologia e não tem a capacidade de fazer as perguntas correctas. O público não sabe qual é o problema ou quais são os problemas.
Penso que é mais do que tempo de o governo explicar o problema ou problemas tecnológicos subjacentes. Caso contrário, estaremos a dar azo a especulações intermináveis. A falta de transparência leva-nos a supor que não houve qualquer competência na gestão do projeto Phoenix por parte do Governo do Canadá. Conheci muitos funcionários públicos canadianos na área das tecnologias da informação que possuem excelentes capacidades de gestão de projectos e conhecimentos tecnológicos. Projectos de ERP e complicados com taxas de sucesso desanimadoras na administração pública. Existem padrões que surgiram de outros fracassos de ERP governamentais: entrega tardia, orçamento excessivo, poucos benefícios previstos - alguns projectos abandonados. É uma ilusão pensar que supervisão ministerial fará renascer magicamente a fénix das cinzas.
Por isso, vou especular sobre o que poderá ser o problema com base em padrões em circunstâncias semelhantes, abrangendo estes aspectos:
- Incentivos
- Qualidade
- Gestão de Projectos
- As melhores práticas
- Formação
- Tecnologia ERP
- Substituição
- Escalabilidade
Concluirei com uma reflexão sobre a razão pela qual alguém se deve preocupar com isto.
1. Quando os incentivos conspiram para o fracasso da tecnologia governamental
A equipa de projeto do Governo recebia bónus pela conclusão de etapas. Trata-se de um incentivo tóxico para a produção. Por um lado, incentiva os funcionários públicos a manipularem os resultados e, por outro, cria um mecanismo de pressão para que os fornecedores os aprovem. Cria um ambiente em que os a definição de sucesso pode ser comprometida. Esta situação pode levar as equipas de implementação a entregarem um âmbito e uma qualidade que elas definem como bem sucedidos, mas que os utilizadores não definem.
Os fornecedores podem aproveitar o mandato de entrega atempada para entregar com menor qualidade ou menor âmbito. Os fornecedores de grande dimensão sabem como tirar partido dos contratos. Têm departamentos jurídicos para analisar os pormenores dos contratos. A minha experiência diz-me que existem sempre lacunas entre os requisitos dos pedidos de propostas e as necessidades do governo. Talvez o âmbito das funções que têm estado a gerar problemas não tenha sido bem articulado. Pode haver um fosso significativo entre o objetivo contratual legal estabelecido para o fornecedor e a necessidade real.
Suspeito que os incentivos dados à equipa de implementação do governo implicam que a administração compreendeu que o projeto era arriscado. Parece-me que a abordagem de aquisição consistiu em criar uma negação de fracasso através da aquisição exclusiva da PeopleSoft, o principal pacote ERP de RH, e garantir que apenas as grandes empresas de integração de sistemas pudessem satisfazer as qualificações do fornecedor. É uma forma de pensar do tipo "nunca ninguém foi despedido por ter comprado...".
2. A Fénix é atormentada por insectos?
Não se sabe ao certo como é que 89 000 casos foram tratados em junho. A minha impressão é que estes foram tratados através de soluções alternativas no sistema e de transacções financeiras fora do sistema. Existem erros no sistema que estão a gerar problemas? Em caso afirmativo, são as regras comerciais incorrectas ou determinadas funções do sistema? A adição de 71 000 novos casos num mês implica que quaisquer erros de regras ou de validação que estejam em falta não foram corrigidos.
Muitas empresas de integração de sistemas culpam os clientes por comunicações incompletas durante a recolha de requisitos. Neste caso, isso parece inconcebível. As regras salariais do Governo do Canadá não são um mistério. As regras são complicadas mas bem compreendidas. Muitas pessoas empregadas pelo governo conhecem estas regras - tal como muitas no sector privado. Por exemplo, muitos departamentos e agências governamentais utilizaram o software FreeBalance para a elaboração de orçamentos salariais e para o controlo de qualidade do sistema de folhas de pagamento antigo.
3. Os projectos sob tensão tornam-se tragédias gregas
Há uma resposta típica da gestão a projectos sob pressão - mais supervisão. A supervisão da gestão introduz mais reuniões e mais relatórios. Perturba o fluxo do projeto. Aumenta a probabilidade de fracasso, como numa tragédia grega, ao tentar evitar o fracasso. É inevitável que Édipo mate o seu pai e que o seu projeto ERP não seja entregue a tempo.
A gestão de projectos sob stress resulta muitas vezes em seguir a opinião do elemento da equipa com menos qualificações funcionais e técnicas: a pessoa com mais experiência. A voz do pessoal com conhecimentos técnicos e funcionais é frequentemente abafada pela supervisão, pela papelada e pelos comités.
A tragédia das comissões é que elas respondem a mais comissões. As decisões são tomadas cada vez mais por quem não tem conhecimentos nem contexto.
A resposta típica dos comités é: adicionar mais pessoas, trabalhar mais horas. As pessoas são acrescentadas demasiado tarde no projeto. Este pessoal nunca chega a trabalhar, interrompendo constantemente a produtividade. Entretanto, trabalhar mais horas agrava os problemas de qualidade, introduz novos bugs, prejudica o projeto.
4. Quando as "melhores práticas" são as piores
Os contratos públicos baseiam-se frequentemente na noção de prazos previsíveis alinhados com o ciclo orçamental. Os contratos governamentais típicos para software empresarial têm marcos definidos com base em projectos anteriores que utilizaram tecnologias diferentes. Os pagamentos são efectuados de acordo com estes marcos definidos. Qualquer projeto em que as etapas não estejam rigorosamente definidas é considerado arriscado. Isto significa que as metodologias ágeis são evitadas pela maioria dos governos em aquisições complexas de TI. As lacunas entre os requisitos e as necessidades reais passam por ordens de alteração. As ordens de alteração custam dinheiro. Os custos adicionais são evitados. Isto resulta em custos muito mais elevados a longo prazo devido ao desalinhamento com as necessidades.
A previsibilidade está também associada à documentação e à supervisão. As empresas de integração de sistemas gastam uma quantidade significativa de tempo a redigir análises de lacunas, especificações, casos de teste e planos de aceitação, sendo o sucesso frequentemente medido pelo número de árvores destruídas e pelo número de reuniões em que se participou. Isto compromete o sucesso do projeto. Não se trata de dizer que a documentação deve ser evitada. O que acontece é que a documentação como cerimónia inibe frequentemente o sucesso. Por exemplo, o processo de documentação utiliza frequentemente o sistema antigo como âncora e não a substituição. Assim, as equipas gastam mais tempo a determinar e documentar como o novo software irá funcionar como o software que está a ser substituído. A melhor abordagem é identificar os problemas que o software antigo resolveu e determinar se o software de substituição resolve esses problemas. Muitas vezes, verifica-se que o novo software tem formas mais elegantes de resolver os problemas.
Os governos especificam frequentemente a composição da equipa do projeto de integração de sistemas. Isto inclui o número de anos de experiência com o produto escolhido, ou no domínio dos RH. A equipa pode não ter conhecimento da folha de pagamentos do Governo do Canadá, ou dos governos em geral. Além disso, os governos especificam frequentemente o número de pessoas que a empresa de integração deve fornecer. Estas equipas de projeto podem tornar-se pesadas, exigindo o funcionamento em silos com reuniões frequentes entre grupos. Mais raramente é melhor na implementação de software.
5. O enigma da formação
Os porta-vozes do governo indicaram que a falta de formação foi uma das causas causas profundas do problema. O governo assumiu a formação do integrador de sistemas, a IBM. Esta abordagem não é despropositada quando os funcionários públicos têm mais experiência prática com o processamento de salários. No entanto, muitos projectos sofrem quando esta tática é utilizada para reduzir custos. Os custos de formação podem parecer terrivelmente caros numa proposta de grande dimensão. É uma rubrica orçamental que pode sobressair como um polegar dorido - fácil de cortar para reduzir os custos.
É necessária uma formação suficiente para obter a máxima utilidade de qualquer software empresarial. O pessoal do integrador de sistemas conhece frequentemente muito melhor o novo produto, e a formação do pessoal do governo pode ser inferior. Os esquemas de "formação de formadores" podem resultar em cegos a guiar cegos. Além disso, a formação em software empresarial também pressupõe um mínimo de conhecimento do domínio que pode não existir (mesmo que os clientes insistam que esse conhecimento existe). É muitas vezes difícil para os funcionários públicos abstraírem a formação genérica de um contexto empresarial para lições para o governo.
A falta de formação é a causa principal? Como é que a falta de formação resulta em cálculos inválidos, incluindo o facto de alguns funcionários públicos não receberem qualquer pagamento? Deve haver uma validação da entrada de dados e relatórios de exceção que indiquem que as pessoas não estão a ser pagas. Os relatórios orçamentais devem também mostrar qualquer diferença entre o salário previsto e o efetivo. Aparentemente, a falta de formação contribui para centenas de milhares de casos, mas não é a causa principal.
6. Quando a tecnologia herdada é substituída pelo ERP herdado
Existe um mal-entendido comum sobre o projeto Phoenix. A maioria dos observadores acredita que o sistema foi "desenvolvido" pela IBM. O Governo do Canadá contratou exclusivamente a PeopleSoft. Trata-se de uma declaração oficial do Conselho do Tesouro. A IBM tornou-se a empresa de integração de sistemas após um processo competitivo. O problema é que o governo está a tentar eliminar a dívida técnica causada por software antigo através da aquisição de ERP antigo. Isso significa que cair em "falência técnica" foi adiado. Mas o relógio do dia do juízo final das TI está a contar.
De pouco serve substituir sistemas antigos por aquilo que a Grupo Gartner chamadas "ERP antigo", que exige mais personalização do que as aplicações empresariais mais modernas. Os governos exigem frequentemente mais personalizações devido a regulamentos legislativos únicos. Estas personalizações introduzem novo código. Quanto mais alterações no código, maior a possibilidade de problemas de qualidade. Mais bugs. Perda de integridade dos dados.
O problema de qualidade dos sistemas ERP altamente personalizados agrava-se com o tempo. As alterações à legislação introduzem mais personalização. A personalização dificulta as actualizações do produto porque o código órfão tem de ser examinado em pormenor para ver o que precisa de ser alterado. Se as personalizações são a causa principal, o os problemas só vão piorar.
7. Mito da substituição e da carteira
A melhoria da integração e a redução dos custos totais são propostas de valor típicas de muitos projectos ERP de grande escala. Ainda, muitos projectos governamentais concebidos para substituir vários sistemas por um único sistema resultam em custos excessivos significativos. Nestas circunstâncias, poderá haver problemas de gestão da mudança. A minha sensação é que os decisores de TI muitas vezes não compreendem a razão pela qual os diferentes sistemas foram adicionados em primeiro lugar. Pode haver uma funcionalidade necessária significativa nesses sistemas que aumenta a pegada de personalização.
Faz sentido que as funções informáticas centralizadas obtenham economias de escala mais positivas do que muitos sistemas individuais. É razoável esperar que a formação e a manutenção de uma única solução integrada sejam inferiores às de várias soluções que funcionam de formas diferentes com tecnologias diferentes. Na prática, nem sempre é esse o caso. Em primeiro lugar, os sistemas ERP tendem a ser mais complexos. De acordo com a nossa experiência, podem ser necessárias mais pessoas para operar e manter um grande sistema ERP do que um conjunto de aplicações personalizadas e COTS. Em segundo lugar, muitas soluções ERP não são unificadas. Este facto resulta de muitas aquisições feitas pelos fornecedores de ERP, pelo que existem muitas tecnologias e bases de código nestas soluções. Os fornecedores de ERP implementam versões monolíticas de módulos que utilizam a mesma tecnologia e a mesma base de código. Este facto exige estratégias de gestão e integração de metadados quando é utilizado o mesmo software, porque a definição de algo num módulo difere de outros. O custo total a longo prazo pode ser mais elevado com um único ERP antigo do que com uma carteira de aplicações.
Há também algo fundamentalmente diferente nos sistemas ERP para todo o governo. Há retornos negativos que ocorrem em muitas organizações governamentais quando departamentos e agências mais pequenos se debatem com processos normalizados altamente complexos concebidos para departamentos muito maiores. Também pode introduzir mais carga de trabalho para departamentos e agências com processos legitimamente únicos. Por exemplo, uma entidade governamental que lida com questões de segurança nacional tem critérios de contratação muito complexos.
8. Quando o escalonamento não é escalonado
Os grandes sistemas de processamento de salários têm problemas de escalonamento. Isto deve-se ao facto de qualquer execução do cálculo das folhas de pagamento exigir a aplicação de milhares de regras. Em abril de 2016, havia mais de 258 000 funcionários públicos federais no Governo do Canadá. Este número não inclui o número de funcionários públicos reformados que estão a receber pensões. Por conseguinte, é importante assegurar o dimensionamento do sistema para as actividades de pico de processamento dos salários. O PeopleSoft é construído com base numa tecnologia proprietária. O escalonamento do PeopleSoft provavelmente requer algum método proprietário de balanceamento de carga para processos em lote. Este método pode não ser elegante em comparação com algumas das técnicas atualmente disponíveis. No entanto, deve ser dimensionado, a menos que, como em algumas implementações de Serviços Partilhados no Canadá, os recursos informáticos disponibilizados sejam insuficientes.
Porque é que isto é importante?
O Phoenix é um dos muitos grandes projectos de TI do Governo do Canadá que não corresponderam às expectativas, juntamente com o projeto único de gestão de conteúdos web, o Projeto de correio eletrónico dos Serviços Partilhados do Canadá, e outros Isto é dinheiro público que foi desperdiçado. Aparentemente, estas implementações custarão ao governo mais do que se o status quo fosse mantido. Este não é um bom presságio para futuros grandes projectos de TI no Governo do Canadá.
Alguns observadores pensam que os funcionários públicos têm demasiados direitos. Uma pessoa respondeu-me no twitter que devia haver muito menos empregados no Canadá. O seu ponto de vista parecia ser que os funcionários públicos que perdiam as suas casas, que não podiam pagar os medicamentos ou a educação, estavam a pedi-las. Parece haver uma falta de empatia fora da Região da Capital Nacional. Esta noção de burocratas improdutivos e sem nome é um mito. É verdade que os funcionários públicos canadianos têm bons planos de pensões, mas muitos ganham menos do que os seus homólogos do sector privado.
A minha observação é que os funcionários públicos passaram por ondas de redução de efectivos, de redução de direitos, de serviços partilhados e de externalização, de tal modo que seria difícil distinguir a qualidade e a eficiência do trabalho entre os sectores público e privado. É certo que há burocratas oficiosos no governo, mas também há muitos no sector privado. Empresas como a Blackberry e a Blockbuster cometeram erros cruciais.
Na administração pública, o rácio de pessoal orientado para uma missão é muito mais elevado do que no sector privado. A maior parte dos funcionários públicos que conheci estão lá para fazer uma diferença positiva. Este é um facto raramente referido. Deveria ser.