Skip to main content

Práticas ágeis no planejamento de recursos corporativos não são mais um mito

Transformar o planejamento de recursos corporativos (ERP) nunca é fácil. Uma abordagem ágil pode contribuir para melhorar os resultados.

As soluções de ERP (planejamento de recursos corporativos) são um ativo fundamental para a maioria das grandes empresas, mas as transformações do ERP continuam sendo lentas e complexas. Uma abordagem ágil tem o potencial de simplificar e otimizar drasticamente os projetos de ERP, mas os profissionais de TI sempre acreditaram que ágil é incompatível com ERP. Contudo, nossa experiência ajudando inúmeras organizações a adotarem práticas ágeis em ampla gama de situações tem provado o oposto: que a abordagem ágil pode ser adotada com sucesso nos programas de ERP, com resultados mensuravelmente melhores. Basta apenas adaptar a metodologia às exigências peculiares dessas soluções complexas.

Por que transformar o ERP continua sendo importante

As grandes soluções de ERP despencaram para o último lugar na agenda dos gestores de TI, abrindo espaço para questões mais modernas – digital, big data, machine learning e a nuvem. Mas os benefícios comerciais das soluções de ERP – a saber, a possibilidade de integrar impecavelmente as funções de ponta a ponta e de padronizar os processos de várias regiões e unidades de negócio – tornam tais soluções um ativo fundamental para a maioria das grandes empresas. Além disso, a próxima geração de soluções do ERP (por exemplo, Oracle Cloud e SAP S/4HANA) traz recursos ainda mais promissores, tanto em termos funcionais como tecnológicos. Empresas focadas em programas de transformação digital ou de advanced analytics estão começando a perceber que, para liberar o pleno potencial de seus investimentos, é essencial vincular as novas tecnologias à sua base no ERP.

Os desafios das transformações do ERP

Por mais fundamentais que sejam, três quartos dos projetos de transformação do ERP atrasam ou estouram o orçamento. E dois terços têm retorno negativo do investimento. São cinco os motivos principais (Quadro 1).

We strive to provide individuals with disabilities equal access to our website. If you would like information about this content we will be happy to work with you. Please email us at: McKinsey_Website_Accessibility@mckinsey.com

Primeiro, talvez nem todas as partes compartilhem os mesmos objetivos. Por exemplo, um integrador de sistemas pode ter incentivos para ampliar o escopo e a duração do programa se isso gerar mais receita em uma integração complexa. A empresa, por outro lado, deseja concluir o projeto e capturar seu valor o mais rápido possível.

Segundo, a maioria das organizações não possui experiência em gestão de grandes projetos de TI e de programas envolvendo vários fornecedores. Elas não têm gerentes qualificados em número suficiente, nunca estabeleceram uma governança rigorosa para esses programas e não conseguem compreender o grau de contribuição exigido dos patrocinadores do negócio.

Terceiro, os sistemas de ERP possuem enorme escopo funcional integrado e, portanto, exigem discussões complexas com a empresa sobre modelos operacionais, gestão de dados e direitos de validação. Essas decisões geralmente precisam ser tomadas no meio do programa e exigem interferência do comitê executivo, que terá de se basear em informações que ainda não estão disponíveis. Muitas vezes, é preciso interromper temporariamente o projeto para que tais decisões sejam tomadas, retardando o progresso e até mesmo prejudicando o valor da iniciativa.

Quarto, são as atividades e os produtos finais que tendem a alavancar as transformações do ERP; no entanto, uma transformação deveria ser focada no valor comercial, o qual precisará ser quantificado, documentado e monitorado para que o programa vá adiante.

Por fim, a maioria dos projetos de ERP é empreendida utilizando uma abordagem linear e sequencial do tipo waterfall [em cascata], o que atrasa a realização do valor.

Esses desafios costumam fazer com que as implementações de ERP se arrastem por cinco ou até dez anos. Uma implementação típica envolve longas fases de desenho, especificações e modelação, mas não produz impacto mensurável – enquanto o valor para os acionistas vai diminuindo dia após dia.

Equívocos e verdades sobre a abordagem ágil e o ERP

O mito de que a abordagem ágil não pode ser aplicada a implementações de ERP é baseado em vários equívocos: que uma implementação de ERP é grande e complexa demais para ser gerida e entregue por pequenas equipes ágeis (implicando que é impossível desmembrar os requisitos intrincados e altamente integrados do ERP em histórias verticais de usuários que possam ser desenvolvidas e testadas pelos breves sprints que definem a entrega ágil); que o ERP é um software padronizado e que, portanto, uma abordagem ágil – desenhada tendo em vista requisitos desconhecidos ou em constante mudança – não seria necessária ou aplicável; e que uma solução de ERP não pode ser revelada gradualmente aos usuários finais, pois eles não seriam capazes de perceber valor algum até ela ser totalmente construída e integrada.

Na verdade, as práticas ágeis podem, de várias maneiras, mitigar bastante os riscos e desafios que acometem uma implementação típica de ERP. Por exemplo, fornecedores ágeis e integradores de sistemas ágeis poderão trabalhar juntos como uma só equipe de ponta a ponta focada no mesmo conjunto de indicadores-chave de desempenho (KPIs) e nos mesmos resultados.

Práticas ágeis implicam um ritmo de trabalho mais rápido e maior transparência, tornando mais fácil para os gerentes tomarem decisões críticas no momento certo. Ao contrário do que muitos acreditam, ágil não significa “sem planejamento” – pelo contrário, ágil substitui as fases longas e opacas de um projeto por sprints de duas a três semanas, de tal modo que os gerentes possam monitorar resultados, progressos e desafios.

As práticas ágeis também exigem que os grupos de negócios e de TI se integrem à equipe do projeto, que é estruturalmente voltada para a criação de valor. Esses dois grupos colaboram desde o início do projeto, promovendo a agilidade de ambos.

E a agilidade ajuda a desmembrar o escopo funcional do ERP em um conjunto menor de funcionalidades que equipes pequenas podem entregar por meio de sprints. Essa abordagem iterativa permite que um projeto gere valor comercial rapidamente.

Em resumo, práticas ágeis são exatamente o que é necessário para gerenciar implementações de ERP. Não chega a surpreender, portanto, que os maiores fornecedores de ERP, como a SAP, estejam hoje promovendo uma abordagem mais ágil.

Como adaptar o ágil ao ERP

Algumas práticas ágeis podem ser aplicadas diretamente, sem adaptação, às implementações de ERP. Por exemplo, a formação de pequenas equipes ágeis multifuncionais de ponta a ponta, cujos responsáveis pelo produto provêm da empresa e dos usuários finais; ou as tarefas realizadas em ciclos curtos de duas a três semanas para produzir software funcional (ou configurações, interfaces etc.) de modo incremental; ou adoção de cerimônias de scrum focadas na melhoria contínua, cuja transparência é facilitada pelas próprias cerimônias e por KPIs; ou a utilização de ferramentas e tecnologias (como automação de testes e integração contínua) que otimizam e aceleram o processo de entrega.

Outras práticas ágeis, porém, precisam ser adaptadas. Por exemplo, o escopo do projeto como um todo deve ser definido de antemão, em um nível hierárquico elevado, e incluir critérios claros de sucesso (em oposição à abordagem ágil mais comum, que é a criação de produtos minimamente viáveis). Entretanto, as equipes devem ter autonomia para refinar esse escopo detalhado e definir prioridades à medida que avançam.

Além disso, para assegurar que o desenvolvimento seja consistente e as tarefas possam ser divididas entre equipes pequenas, é preciso trabalhar mais no processo e na arquitetura do negócio do que seria o caso numa implementação ágil típica.

Vínculos fortes precisam unir as equipes ágeis que entregam funcionalidades e as equipes “transversais” – por exemplo, a equipe de migração de dados, a equipe de integração ou a equipe de mudança – que não são equipes funcionais mas dão suporte às equipes funcionais ou de recursos. Todas as equipes devem ser sincronizadas para que trabalhem no mesmo ritmo e possam cruzar juntas a linha de chegada.

Softwares “prontos para produção” não podem ser entregues com a mesma frequência do que os desenvolvidos com práticas ágeis. É necessário haver uma fase de testes e de transição de ponta a ponta para consolidar os incrementos desenvolvidos por cada equipe e testar o funcionamento de interfaces complexas com sistemas legados – e isso geralmente requer mais de um sprint para ser concluído.

Por fim, é preciso haver um escritório de gestão do programa (PMO) que seja forte e ágil para acelerar a resolução de problemas e a tomada de decisões abrangendo mais de uma equipe.

Aplicando o ágil à abordagem clássica

Uma implementação clássica de ERP possui quatro etapas: desenvolvimento de uma estratégia e um roadmap de ERP; montagem do programa; implementação; e implantação. Todas as etapas podem ser adaptadas para a metodologia ágil.

O desenvolvimento de uma estratégia e um roadmap de ERP resulta em uma arquitetura com princípios de alto nível e um caso de negócios para implementar a nova solução. Esta etapa permanece praticamente inalterada na abordagem ágil, mas pode ser acelerada com uma rápida análise fit-gap [análise das falhas de ajuste para avaliar o grau de adesão de cada área funcional ao projeto] em um nível hierárquico elevado, evitando-se modelações infindáveis e trabalhando iterativamente em sprints – evitando assim um caso de negócios excessivamente detalhado. Os responsáveis por produtos ;devem ser convidados a cooperar e ter autonomia para tomar decisões importantes desde o início, enquanto equipes multifuncionais menores são criadas para atingir as metas do programa.

A montagem do programa muda substancialmente em uma abordagem ágil, tornando-se muito mais rápida, principalmente porque as equipes têm maneiras de lidar rapidamente com dificuldades da vida real em vez de se aterem a desenhos teóricos. Esta etapa inclui a seleção rápida de um parceiro que tenha experiência com a solução e com práticas ágeis (em vez de se iniciar um longo processo de solicitação de propostas para encontrar um fornecedor e negociar um contrato com preço fixo); a criação de um road map de alto nível com macrofuncionalidades baseado em uma lista de melhorias identificadas suficientemente detalhada para determinar o tamanho e a forma da organização ágil necessária para levar a cabo o programa; a habilitação de funcionários e o treinamento da organização em formas ágeis de trabalhar; e a criação de um PMO forte que coordenará as frentes de trabalho funcionais e não funcionais.

A implementação da solução é drasticamente diferente em uma abordagem ágil, pois ocorre em ondas sucessivas que capturam valor rapidamente. As equipes funcionais de entrega adotam a maioria das práticas típicas de scrum. Equipes de ponta a ponta, formadas por oito a dez pessoas, tanto dos negócios como da TI da empresa e também do integrador de sistemas, concluem o desenho, desenvolvimento e teste do sistema em sprints de duas a três semanas. Testes de ponta a ponta e testes da aceitação dos usuários são realizados a intervalos regulares – e não apenas no final do desenvolvimento – resultando em código de programação de melhor qualidade e na automação contínua dos testes. Tarefas não funcionais (por exemplo, migração de dados, treinamento e implantação) são menos afetadas pela abordagem ágil, embora continue sendo necessário haver coordenação íntima entre as equipes funcionais e não funcionais. Por exemplo, como os testes funcionais frequentes exigem dados desde o início, a equipe de migração de dados precisa coletá-los para alimentar o ambiente de teste. Os testes não funcionais e a fase de transição entre sistemas [cut-over] permanecem os mesmos que em uma implementação clássica.

Sidebar

Como ilustração, certa empresa em processo de transformação reorganizou seu pessoal em 26 equipes. Destas, 11 eram equipes ágeis multifuncionais de ponta a ponta, responsáveis por entregar funcionalidades; as outras 15 eram equipes transversais que davam suporte às equipes ágeis. Todas as equipes ágeis incluíam as capacidades necessárias para entregar uma solução ponta a ponta, incluindo representação comercial (veja o box, “Como uma empresa de logística utilizou práticas ágeis para transformar o ERP”).

A implantação da solução segue, em linhas gerais, a abordagem clássica. É verdade que as implantações ocorrem com mais frequência, mas as práticas ágeis ajudam a eliminar gargalos. Uma mentalidade de “implantar rapidamente tudo que for desenvolvido” pode reduzir o risco de implantação precoce, analytics pode ajudar a otimizar o processo (por exemplo, o número de “usuários-chave” a serem treinados) e modelos locais podem ser desenhados antecipadamente com a participação de usuários locais . É possível planejar uma fase mais curta de “cuidados intensivos” graças ao foco contínuo na qualidade. E, como lançamentos do produto final são mais frequentes em uma abordagem ágil, há mais oportunidades de industrializar todas as etapas da implantação.

É importante observar que, em uma implementação adaptada para a metodologia ágil, as etapas iniciais são mais aceleradas do que na abordagem tradicional “em cascata”. A maior parte do tempo é despendida nas etapas posteriores, com foco na entrega de funcionalidades.

Benefícios de adaptar práticas ágeis ao ERP

A popularidade da metodologia ágil decorre, em grande parte, de seus resultados. Pesquisas mostram que há 70% de chance de a saúde de organizações ágeis estar no quartil superior (e a saúde organizacional é o melhor indicador de alta performance duradoura). Além disso, essas mesmas empresas são as mais centradas no cliente e têm o menor time-to-market, o maior crescimento das receitas, os menores custos e a força de trabalho mais engajada.

No caso específico do ERP, a implantação ágil – qualquer que seja a tecnologia subjacente – se traduz em uma gama de benefícios tangíveis e intangíveis (Quadro 2):

  • Redução do custo do programa em 10%, graças principalmente à menor necessidade de retrabalho nas fases de testes de ponta a ponta e dos testes da aceitação dos usuários
  • Aumento de 20% do valor do programa, pois os responsáveis por produtos têm visibilidade suficiente do progresso do projeto para focarem os itens de alto valor
  • Capacidade de comprimir três vezes mais carga de trabalho em um determinado período graças ao maior paralelismo das equipes funcionais
  • Adoção mais ampla da solução pelos usuários finais, pois estão envolvidos ao longo de toda a implementação
  • Melhoria no estado de ânimo da equipe, pois é possível acompanhar diariamente o progresso mensurável da implementação da solução
We strive to provide individuals with disabilities equal access to our website. If you would like information about this content we will be happy to work with you. Please email us at: McKinsey_Website_Accessibility@mckinsey.com

Embora os sistemas de ERP sejam muitas vezes considerados um “mal necessário”, eles vieram para ficar e não podem mais ser ignorados à medida que as empresas vão se tornando digitais. A abordagem tradicional (e frequentemente complicada) da transformação do ERP precisa ser drasticamente revista e, sempre que possível, adaptada para incluir maneiras ágeis de trabalhar.

Empresas e integradores de sistemas devem deixar de lado o mito de que a metodologia ágil não pode ser aplicada ao ERP e, em vez disso, industrializar a abordagem ágil para a transformação do ERP.

Além disso, as soluções de ERP devem se tornar mais modulares para que a implantação possa ocorrer em fases – resultando em custos mais baixos e na geração mais rápida de valor.

As transformações do ERP são sempre desafiadoras, mas os desafios podem se tornar muito menos intimidadores com uma abordagem ágil.

Sobre o(s) autor(es)

Didier Casanova é associate partner no escritório de Bruxelas da McKinsey; Swati Lohiya é especialista sênior no escritório de Londres; Jerome Loufrani é associate partner no escritório de Paris, onde Matteo Pacca é sócio sênior; e Peter Peters é sócio no escritório de Dusseldorf.