Phoenix Falling ou Phoenix Rising?
Notícias sobre o sistema central de folha de pagamento do governo do Canadá usando o PeopleSoft ERP, cada vez mais ironicamente chamado de "Sistema de pagamento Phoenix", é desanimador. O CBC relata que 228.000 casos permaneceram no final de julho. Milhares de novos casos foram adicionados no mês, resultando em uma redução líquida de 18.000. Os O governo havia se comprometido em junho do ano passado a resolver os problemas até o final de outubro. Meu feed do Twitter mostra uma frustração significativa entre os funcionários públicos. Muitos se perguntam por que o problema não pode ser resolvido.
Essa implementação do ERP se tornou altamente politizada. As comunicações do governo são vagas. A imprensa política não tem conhecimento de tecnologia e não tem a capacidade de fazer as perguntas certas. O público não sabe qual é o problema, ou quais são os problemas.
Acho que está mais do que na hora de o governo explicar o problema ou os problemas tecnológicos subjacentes. Caso contrário, isso leva a uma especulação sem fim. A falta de transparência nos leva a supor que não houve competência alguma no gerenciamento do projeto Phoenix pelo Governo do Canadá. Conheci muitos funcionários públicos canadenses da área de tecnologia da informação que têm excelente habilidade de gerenciamento de projetos e conhecimento de tecnologia. Projetos de ERP e complicados com taxas de sucesso desanimadoras no governo. Existem padrões que surgiram de outros fracassos de ERP do governo: entrega atrasada, orçamento acima do esperado, poucos benefícios previstos e alguns projetos abandonados. É um desejo que supervisão ministerial fará com que a fênix surja magicamente das cinzas.
Portanto, vou especular sobre o que poderia ser o problema com base em padrões em circunstâncias semelhantes, abrangendo esses aspectos:
- Incentivos
- Qualidade
- Gerenciamento de projetos
- As melhores práticas
- Treinamento
- Tecnologia ERP
- Substituição
- Escalabilidade
Para concluir, vou pensar por que alguém deveria se preocupar com isso.
1. Quando os incentivos conspiram para o fracasso da GovTech
A equipe de projeto do governo recebeu bônus pela conclusão de marcos. Esse é um incentivo de resultado tóxico. Por um lado, ele incentiva os funcionários públicos a manipularem os resultados e, por outro, cria um mecanismo de pressão para a aprovação dos fornecedores. Isso cria um ambiente em que o a definição de sucesso pode ser comprometida. Isso pode levar as equipes de implementação a entregar escopo e qualidade que elas definem como bem-sucedidos, mas que os usuários não definem.
Os fornecedores podem aproveitar o mandato de entrega no prazo para entregar com qualidade inferior ou com menos escopo. Os fornecedores muito grandes sabem como aproveitar os contratos. Eles têm departamentos jurídicos para examinar os detalhes do contrato. Minha experiência diz que sempre há lacunas entre os requisitos da Solicitação de Proposta e as necessidades do governo. Talvez o escopo das funções que estão gerando problemas não tenha sido bem articulado. Pode haver uma lacuna significativa entre a meta contratual legal definida para o fornecedor e a necessidade real.
Suspeito que os incentivos dados à equipe de implementação do governo indicam que a gerência entendeu que o projeto era arriscado. Parece-me que a abordagem de aquisição foi criar uma negação de falha por meio da aquisição exclusiva do PeopleSoft, o principal pacote de ERP de RH, e garantir que apenas grandes empresas de integração de sistemas pudessem atender às qualificações do fornecedor. É o modo de pensar "Ninguém nunca foi demitido por comprar...".
2. A Phoenix é atormentada por insetos?
Não está claro como 89.000 casos foram tratados em junho. Minha impressão é que eles foram tratados por soluções alternativas no sistema e por transações financeiras fora do sistema. Existem bugs no sistema que estão gerando problemas? Em caso afirmativo, isso se deve a regras comerciais incorretas ou a determinadas funções do sistema? O acréscimo de 71.000 novos casos em um mês implica que quaisquer erros de regras ou validações que estejam em falta não foram corrigidos.
Muitas empresas de integração de sistemas culpam os clientes pela comunicação incompleta durante a coleta de requisitos. Isso parece inconcebível nesse caso. 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 essas regras, assim como muitas pessoas do setor privado. Por exemplo, muitos departamentos e agências do governo têm usado o software FreeBalance para orçamento de salários e verificação da qualidade do sistema legado de folha de pagamento.
3. Projetos sob estresse tornam-se tragédias gregas
Há uma resposta típica da gerência a projetos sob estresse: mais supervisão. A supervisão da gerência gera mais reuniões e mais relatórios. Ela interrompe o fluxo do projeto. Ela aumenta a probabilidade de fracasso, como em uma tragédia grega, ao tentar evitar o fracasso. É inevitável que Édipo mate seu pai e que seu projeto de ERP não seja entregue no prazo.
O gerenciamento de projetos sob estresse geralmente resulta em seguir o julgamento da pessoa menos qualificada funcional e tecnicamente da equipe: a pessoa mais sênior. A voz da equipe com conhecimento técnico e funcional geralmente é abafada pela supervisão, pela papelada e pelos comitês.
A tragédia dos comitês é que eles se reportam a mais comitês. As decisões são tomadas cada vez mais por aqueles que não têm conhecimento e contexto.
A resposta típica dos comitês é: adicionar mais pessoas, trabalhar mais horas. Mais pessoas são adicionadas muito tarde no projeto. Essa equipe nunca consegue se atualizar, interrompendo constantemente a produtividade. Enquanto isso, trabalhar mais horas aumenta os problemas de qualidade, introduz novos bugs e prejudica o projeto.
4. Quando as "melhores práticas" são as piores
As compras governamentais geralmente são baseadas na noção de cronogramas previsíveis alinhados ao ciclo orçamentário. Os contratos governamentais típicos para software corporativo têm marcos definidos com base em projetos anteriores que usaram tecnologias diferentes. Os pagamentos ocorrem nesses marcos definidos. Qualquer projeto em que os marcos não estejam estritamente definidos é visto como arriscado. Isso significa que as metodologias ágeis são evitadas na aquisição de TI complexa pela maioria dos governos. As lacunas entre os requisitos e as necessidades reais passam por ordens de mudança. Os pedidos de alteração custam dinheiro. Custos extras são evitados. Isso resulta em custos muito mais altos no longo prazo devido ao desalinhamento com as necessidades.
A previsibilidade também está associada à documentação e à supervisão. As empresas de integração de sistemas gastam uma quantidade significativa de tempo redigindo análises de lacunas, especificações, casos de teste e planos de aceitação, sendo que o sucesso é geralmente medido pelo número de árvores destruídas e pelo número de reuniões realizadas. Isso compromete o sucesso do projeto. Isso não significa que a documentação deva ser evitada. O que acontece é que a documentação como cerimônia muitas vezes inibe o sucesso. Por exemplo, o processo de documentação geralmente usa o sistema legado como âncora em vez da substituição. Assim, as equipes gastam mais tempo para determinar e documentar como o novo software funcionará como o software que está sendo substituído. A abordagem mais adequada é identificar os problemas que o software legado resolveu e determinar se o software substituto resolve esses problemas. Em geral, verifica-se que o novo software tem maneiras mais elegantes de resolver os problemas.
O governo geralmente especifica a composição da equipe do projeto de integração do sistema. Isso inclui o número de anos de experiência com o produto escolhido ou no domínio de RH. Isso pode não ter incluído o conhecimento da folha de pagamento do governo do Canadá ou dos governos em geral. Além disso, os governos geralmente especificam o número de pessoas que devem ser fornecidas pela empresa de integração. Essas equipes de projeto podem se tornar pesadas, exigindo a operação em silos com reuniões frequentes de contexto entre os grupos. Mais raramente é melhor na implementação de software.
5. O enigma do treinamento
Os porta-vozes do governo indicaram que a falta de treinamento foi uma das causas da falta de treinamento. causas básicas do problema. O governo assumiu o treinamento do integrador de sistemas, a IBM. Essa não é uma abordagem irracional quando a equipe do governo tem mais experiência prática com a folha de pagamento. Porém, muitos projetos são prejudicados quando essa tática é usada para cortar custos. Os custos de treinamento podem parecer terrivelmente caros em uma proposta grande. É um item de orçamento que pode se destacar como um polegar dolorido - fácil de cortar para reduzir custos.
É necessário treinamento suficiente para obter o máximo de utilidade de qualquer software empresarial. A equipe do integrador de sistemas geralmente conhece muito melhor o novo produto, e o treinamento da equipe do governo pode ser inferior. Os esquemas de "treinar o instrutor" podem resultar em cegos guiando cegos. Além disso, o treinamento em software corporativo também pressupõe um mínimo de conhecimento de 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 o treinamento genérico de um contexto comercial para lições para o governo.
A falta de treinamento é a causa principal? Como a falta de treinamento resulta em cálculos inválidos, incluindo alguns funcionários públicos que não recebem pagamento? Deve haver validação na entrada de dados e relatórios de exceção que indiquem que as pessoas não estão sendo pagas. Os relatórios orçamentários também devem mostrar qualquer diferença entre o pagamento esperado e o real. Parece que a falta de treinamento contribui para centenas de milhares de casos, mas não é a causa principal.
6. Quando a tecnologia legada é substituída pelo ERP legado
Há 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 a PeopleSoft por conta própria. Esse é um pronunciamento 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á tentando eliminar a dívida técnica causada pelo software legado ao adquirir o ERP legado. Isso significa que cair em "falência técnica" foi adiado. Mas o relógio do dia do juízo final da TI está correndo.
Não adianta muito substituir sistemas antigos pelo que a Grupo Gartner chamadas "ERP antigo", que exige mais personalização do que os aplicativos corporativos mais modernos. Os governos geralmente exigem mais personalizações devido a regulamentações legislativas exclusivas. Essas personalizações introduzem novos códigos. 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 aumenta com o tempo. As alterações na legislação introduzem mais personalização. A personalização dificulta as atualizações do produto porque o código órfão precisa ser examinado em detalhes para ver o que precisa ser alterado. Se as personalizações forem a causa principal, a os problemas só vão piorar.
7. Mito da substituição e do portfólio
O aprimoramento da integração e a redução dos custos totais são propostas de valor típicas para muitos projetos de ERP em grande escala. Ainda assim, Muitos projetos governamentais projetados para substituir vários sistemas por um único sistema resultam em custos excedentes significativos. Nessas circunstâncias, pode haver problemas de gerenciamento de mudanças. Minha impressão é que os tomadores de decisão de TI muitas vezes não entendem por que diferentes sistemas foram adicionados em primeiro lugar. Pode haver uma funcionalidade necessária significativa nesses sistemas que aumenta a pegada da personalização.
Faz sentido que as funções centralizadas de TI obtenham economias de escala mais positivas do que muitos sistemas individuais. É razoável esperar que o treinamento e a manutenção de uma única solução integrada sejam menores do que os de várias soluções que operam de maneiras diferentes com tecnologias diferentes. Na prática, isso nem sempre acontece. Em primeiro lugar, os sistemas ERP tendem a ser mais complexos. Nossa experiência mostra que mais pessoas podem ser necessárias para operar e manter um sistema ERP de grande porte do que um conjunto de aplicativos personalizados e COTS. Em segundo lugar, muitas soluções de ERP não são unificadas. Isso se deve a muitas aquisições feitas pelos fornecedores de ERP, de modo que há muitas tecnologias e bases de código existentes nessas soluções. Os fornecedores de ERP implementam versões monolíticas de módulos que usam a mesma tecnologia e base de código. Isso requer gerenciamento de metadados e estratégias de integração quando o mesmo software é usado, pois a definição de algo em um módulo difere de outros. O custo total de longo prazo pode ser mais alto com um único ERP legado do que com um portfólio de aplicativos.
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 órgãos menores lidam com processos padronizados altamente complexos projetados para departamentos muito maiores. Isso também pode aumentar a carga de trabalho dos departamentos e órgãos com processos legitimamente exclusivos. 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 folha de pagamento têm problemas de escalonamento. Isso ocorre porque qualquer execução de folha de pagamento exige a execução de milhares de regras. Havia mais de 258.000 funcionários públicos federais no Governo do Canadá em abril de 2016. Isso não inclui o número de funcionários públicos aposentados que estão recebendo pensões. Portanto, é de certa forma importante garantir o dimensionamento do sistema para as atividades de pico da folha de pagamento. O PeopleSoft foi desenvolvido com tecnologia proprietária. O dimensionamento do PeopleSoft provavelmente requer algum método proprietário de balanceamento de carga para processos em lote. Esse método pode não ser elegante em comparação com algumas das técnicas disponíveis atualmente. No entanto, ele deve ser dimensionado, a menos que, como em algumas implementações de Serviços Compartilhados do Canadá, os recursos de computação fornecidos sejam insuficientes.
Por que isso é importante?
O Phoenix é um dos muitos grandes projetos de TI do governo do Canadá que não atenderam às expectativas, juntamente com o projeto único de gerenciamento de conteúdo da webo Projeto de e-mail dos Serviços Compartilhados do Canadá e outros Isso é dinheiro público que foi desperdiçado. Parece que essas implementações custarão mais ao governo do que se o status quo fosse mantido. Isso não é um bom presságio para futuros grandes projetos de TI no governo do Canadá.
Alguns observadores acham que os funcionários públicos têm direitos demais. Uma pessoa me respondeu pelo twitter que deveria haver muito menos funcionários públicos no Canadá. Seu argumento parecia ser o de que os funcionários públicos que perderam suas casas, que não puderam pagar pelos remédios ou pela educação tiveram o que mereciam. Parece haver uma falta de empatia fora da Região da Capital Nacional. Essa noção de burocratas improdutivos e sem nome é um mito. É verdade que os funcionários públicos canadenses têm bons planos de pensão, mas muitos ganham menos do que os colegas do setor privado.
Minha observação é que os funcionários públicos passaram por ondas de redução de tamanho, redução de direitos, serviços compartilhados e terceirização até o ponto em que seria difícil distinguir a qualidade e a eficiência do trabalho entre os setores público e privado. É claro que há burocratas no governo, mas também há muitos no setor privado. Empresas como a Blackberry e a Blockbuster cometeram erros cruciais.
Há uma proporção muito maior de funcionários voltados para a missão no governo do que no setor privado. A maioria dos funcionários públicos que conheci está lá para fazer uma diferença positiva. Isso é algo raramente relatado. Deveria ser.