Agile ERP: A myth no more

(PDF-382 KB)

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).

Quadro 1

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.

Would you like to learn more about McKinsey Digital?

Visit our Enterprise Architecture page

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.

Harnessing agile

See the collection

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.

Como uma empresa de logística utilizou práticas ágeis para transformar o ERP

Uma das maiores transportadoras e empresas de logística da Europa embarcou num projeto plurianual de transformação de uma importante tecnologia. A meta do programa era substituir o antigo sistema de planejamento de recursos corporativos (ERP) com as mais recentes tecnologias e acrescentar novas funcionalidades. Após alguns anos, porém, o programa enfrentava sérios desafios e sequer possuía um caso de negócio. As responsabilidades pelos negócios não eram claras e não havia uma gestão robusta dos fornecedores e programas. Além disso, o escopo era amplo e complexo demais para que uma transformação eficaz ocorresse com uma abordagem sequencial “em cascata” [tipo waterfall].

Para colocar o programa de volta nos eixos, a empresa focou em três iniciativas: (1) redefinir o escopo do programa em torno dos elementos mais valiosos; (2) desenhar e implementar uma metodologia ágil de entrega do ERP; e (3) instituir um rigoroso escritório de gestão do programa (PMO).

Para tornar realidade a entrega ágil, desenhou-se um novo modelo operacional ágil para o equivalente a mais de 300 funcionários em tempo integral (FTEs) mediante alinhamento de vários stakeholders – incluindo clientes internos de negócios e TI, o fornecedor de ERP, o parceiro de integração de sistemas da empresa, o parceiro de desenvolvimento onshore/offshore e o parceiro de infraestrutura. Os FTEs e o programa foram então adaptados em ritmo acelerado para a entrega ágil.

Para tanto, os FTEs foram reorganizados em seis domínios funcionais, que consistiam em 11 equipes ágeis multifuncionais focadas em tarefas como desenvolvimento e integração do catálogo de produtos. Havia seis domínios transversais com cerca de 15 equipes focadas em áreas como migração de dados e intercâmbio eletrônico de dados (EDI). Em seguida, foi desenhada uma abordagem ágil detalhada levando em conta as especificidades do ERP, e a nova organização foi preparada e treinada nessa nova abordagem. O PMO ágil conduziu o programa, apoiou as cerimônias ágeis do projeto como um todo, resolveu problemas complexos, facilitou a eliminação rápida de quaisquer impedimentos e implementou uma nova ferramenta de gestão e monitoramento de backlogs [tarefas a cumprir].

A aplicação da metodologia ágil nessa implementação do ERP resultou em vários benefícios significativos:

Maior transparência. As equipes do projeto colocaram suas macrofuncionalidades (“épicos”) em uma ferramenta de gestão das frentes de trabalho que vinculou cada uma ao incremento ou sprint em que ela seria entregue. O progresso foi medido ao final de cada sprint (segundo o número de histórias de usuários e pontos de histórias entregues) e na conclusão do projeto (segundo o número de épicos entregues e analisados). Graças a essa transparência, as equipes puderam avaliar e assumir responsabilidade por seu progresso, o que lhes permitiu corrigir rapidamente o curso utilizando retrospectivas ágeis como ferramenta. As equipes também puderam encaminhar prontamente quaisquer impedimentos para seus gerentes. Por sua vez, os gerentes desfrutaram um nível sem precedentes de transparência; eles agora podiam ver a duração, o custo e as causas dos atrasos a cada semana e tomar medidas rápidas. Além disso, por estarem cientes do status exato do projeto a cada momento, os responsáveis por produtos e a liderança puderam tomar decisões bem informadas sobre o que priorizar com base no valor.
Forte coordenação entre equipes. Visando promover a coordenação e a comunicação entre as equipes, o processo começou com um planejamento incremental com todas as equipes – funcionais e transversais – reunidas em uma sala. Então, no início de cada sprint, cada equipe deu sua contribuição para as demais no quesito “dependências”. As equipes funcionais e transversais mantiveram reuniões [huddles] quinzenais. A partir delas, os problemas foram encaminhados para a “sala de guerra” semanal, onde todas as equipes se reuniam para discutir dependências e desempenho.
Solução de problemas rápida e direcionada. O PMO, formado por um total de 12 a 15 pessoas, além de realizar atividades clássicas, atuou como uma equipe SWAT para resolver problemas complexos à medida que iam surgindo. Quase metade do trabalho do PMO envolveu a identificação e resolução de problemas – como a construção de cenários para avaliar o impacto de um atraso na entrega de uma importante interface; a elaboração de um documento complexo para o CEO sobre a redefinição do escopo; aumento da capacidade analítica para planejar 3.000 casos de teste; e reorganização do modelo operacional completo à medida que as necessidades evoluíam (por exemplo, a fusão de equipes funcionais após redefinição do escopo e a construção de uma fábrica de testes eficiente baseada em princípios lean.)
Organização ágil. As 11 equipes ágeis foram capacitadas para entregarem uma solução de ponta a ponta, incluindo representação comercial. Seus sprints de três semanas incluíram desenvolvimento, testes de soluções e uma demonstração para os usuários finais ao término de cada um. Além disso, ao final de cada incremento (ou período de três sprints), foram realizados testes abrangentes, de ponta a ponta, da aceitação dos usuários e da solução para garantir a qualidade e a integridade da funcionalidade entregue. As equipes cumpriram todas as cerimônias do scrum e começaram a obter benefícios em apenas algumas semanas.
Um manual ágil detalhado. A abordagem ágil – customizada para a empresa e o ERP – foi documentada detalhadamente em um manual, que permaneceu um documento de consulta ao longo de todo o programa. O manual incluía itens variados (por exemplo, como traduzir os requisitos tradicionais do ERP em épicos e histórias de usuários para criar um backlog do produto), além de documentação do projeto adaptada à metodologia ágil (por exemplo, especificações técnicas simplificadas – visto que os desenvolvedores trabalhavam diretamente com os responsáveis por produtos e analistas) e uma nova terminologia, como a definição de “pronto e concluído” [ready and done].

Como resultado, o programa conseguiu atingir e até superar as metas de desempenho. A entrega foi 20% mais rápida do que se estimara, pois houve muito menos retrabalho graças às melhorias iterativas obtidas trabalhando-se com os usuários finais na inspeção e adaptação de cada iteração. A rapidez da entrega também decorreu do melhor gerenciamento dos atrasos do projeto – que, graças à adoção de prazos intermediários e da existência de um escopo incremental, deixaram de afetar o cronograma geral. Além disso, menos bugs foram encontrados graças à realização de testes mais frequentes e também aos testes integrados de ponta a ponta da aceitação dos usuários, os quais permitiram lançamentos ágeis – ao contrário do que ocorrera com dois lançamentos em cascata anteriores. O escopo final foi três a dez vezes maior do que em lançamentos anteriores de duração semelhante, devido ao melhor alinhamento entre as equipes funcionais. A aceitação da nova solução pelos usuários também foi muito maior, pois estiveram envolvidos ao longo de toda a implementação. Por fim, o estado de ânimo da equipe ágil melhorou significativamente, conforme medido ao longo das retrospectivas ágeis, o que contribuiu para o sucesso da entrega.

Desde o início do projeto, mais de cem pessoas foram treinadas em mentalidade ágil e em formas de trabalho ágeis, resultando em um novo modelo operacional para a empresa, que reflete os benefícios alcançados pela abordagem ágil – refutando categoricamente o mito de que a metodologia ágil não se aplica ao ERP.

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

Quadro 2

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.

Explore a career with us

Search Openings

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