Atualizar um sistema integrado de gestão dos recursos da empresa (ERP) é uma das maiores e mais caras decisões que os líderes de TI podem tomar. A atualização chega a custar US$ 500 milhões, pode durar vários anos e determinará elementos importantes do modelo operacional da empresa para a próxima década.
Mais insights da McKinsey em português
Confira nossa coleção de artigos em português e assine nossa newsletter mensal em português.
Antes tomar tal decisão, um CIO fará bem em buscar entender como as empresas de tecnologia lidam com mudanças na estrutura de seus sistemas. Essas empresas valorizam velocidade, flexibilidade e escala para criar valor para seus negócios. Isso significa que tomam decisões de tecnologia que maximizam a liberdade e a independência dos desenvolvedores, reduzindo as dependências e complexidades do sistema. Conforme descrevemos em nosso artigo “The platform play”, as empresas nativas digitais conseguem oferecer essa independência porque organizam sua tecnologia em torno de produtos e plataformas modulares que funcionam como um serviço.1 Essa abordagem permite que as equipes tomem as melhores decisões para o produto ou plataforma que gerenciam.
Compare essa abordagem com o que acontece em muitas empresas estabelecidas, que operam sob sistemas corporativos em que dependências complexas tornam praticamente impossível tomar decisões de modo independente.
Considere o caso de uma grande empresa farmacêutica que utilizava um único sistema ERP para distribuição e armazenamento, embora a distribuição fosse uma poderosa vantagem competitiva e precisava ser flexível e responsiva. Por sua vez, a gestão de armazéns era apenas uma commodity básica. Esses dois domínios de negócios estavam rigidamente acoplados no sistema ERP, o que significava que mudanças necessárias na distribuição acabavam limitadas pelas dependências do sistema com a gestão de armazéns. Esta realidade foi um fator significativo da sua elevada dívida técnica acumulada.
As coisas não precisam ser assim. Se concentrar os esforços para atualizar o ERP nos módulos que constituem o sistema, não no sistema como um todo, e se souber o que é importante para gerar valor comercial, o CIO poderá reduzir as dependências, gastar menos, obter mais, reduzir os riscos e fazer tudo isso com mais rapidez.
Do pensamento centrado no ERP para uma moderna organização em plataforma
A primeira lição a aprender com empresas nativas digitais é que elas primeiro definem a estratégia e só depois desenham a arquitetura de sua plataforma. Com uma estratégia clara (por exemplo, aumentar o número de novos clientes e reduzir a rotatividade de clientes), elas seguem uma lógica inexorável para identificar “produtos”, como jornadas do cliente (comprar o produto, encontrar uma loja, obter informações sobre um produto), que podem fazer avançar a estratégia.
Com isso estabelecido, elas então identificam as plataformas (como autenticação de usuários e comparação de produtos) necessárias para entregar esses produtos. Para cada uma dessas plataformas, as empresas nativas digitais formam uma equipe que fica responsável por resultados e desempenho, e decide em última análise se a plataforma utilizará funcionalidades já existentes no sistema ERP.
Essa abordagem que engloba produtos e plataformas deixa claros dois princípios: primeiro, o sistema ERP deve ser tratado como um somatório de funcionalidades, não uma pilha monolítica; e, segundo, são os produtos que determinam a decisão sobre quais partes do sistema ERP utilizar, não vice versa.
É um passo importante buscar um modelo operacional que englobe produtos e plataformas e requer uma mudança de mentalidade na maioria das organizações de TI. Tradicionalmente, as empresas sempre buscaram adquirir soluções de ERP, confiando no fornecedor e no integrador do sistema para realizar as customizações necessárias. Embora isso ainda seja bom o suficiente em áreas onde predominam processos padrão, não basta para áreas onde as empresas precisam de algo mais adaptado a suas necessidades. A maioria dos fornecedores de sistemas ERP entende isso – e eles próprios começaram a insistir em mais modularidade e um núcleo mais enxuto. Por sua vez, os sistemas legados de TI tendem a buscar resolver o problema construindo em cima do sistema ERP existente, o que faz com que a implantação de qualquer alteração seja altamente complexa.
A implicação dessa mudança é que TI precisará “colocar a mão na massa” para gerenciar seus sistemas ERP. E isso significa desenvolver habilidades avançadas de engenharia, gerenciar ativamente as complexidades e dependências do sistema, e trabalhar em estreita colaboração com a empresa para garantir que as mudanças gerem valor comercial.
Determine quais partes do sistema ERP agregam valor
Havendo clareza acerca da estratégia e foco em um modelo operacional que englobe produtos e plataformas, a próxima etapa crucial é determinar quais elementos do sistema ERP contribuem diretamente para a estratégia da empresa. Realizada em alto nível, essa análise de valor divide as funções e capacidades do sistema ERP em dois continentes:
- Em um continente estão os elementos diferenciadores que agregam valor ao negócio. Para um varejista que deseja oferecer entregas mais rápidas, por exemplo, isso significaria priorizar o preenchimento de pedidos e a logística. Em muitos casos, essas funcionalidades são entregues por meio de microsserviços e são totalmente independentes do sistema ERP.
- No outro continente estão as funções commoditizadas, aquelas que não são essenciais para garantir vantagem competitiva. Em muitos casos, essas funções incluem assessoria jurídica ou de gestão de imóveis. Ao oferecer estabilidade, rastreamento e a funcionalidade de gerir capacidades, o ERP possui vantagens suficientes. Se os padrões do setor forem aplicados, a empresa geralmente se beneficiará das inovações dos fornecedores e criará valor sem se desviar desses padrões. Quaisquer customizações criadas por TI precisam contribuir com valor suficiente para compensar o trabalho de mantê-las.
O resultado desse exercício de classificação é um mapa das capacidades, mostrando as funcionalidades diferenciadoras e não diferenciadoras de ERP e o modo como estão organizadas (Quadro 1). A maioria das classificações pode ser feita no nível mais alto possível, mas há algumas áreas que precisam ser desmembradas ainda mais. Por exemplo, como mostra o Quadro 1, embora a maior parte da gestão do sortimento seja considerada uma função commoditizada, é na previsão da demanda que essa empresa quer se diferenciar dos concorrentes.
Um mapa das capacidades bem concebido também ajudará a determinar, com base no valor para a empresa, quais módulos precisam ser atualizados.
Esta perspectiva constitui um poderoso contrapeso para a norma prevalecente pela qual são os fornecedores, não a empresa, que definem os limites das funcionalidades e modernizações necessárias. É uma situação que tende a estar refletida no fato de que, em muitas empresas estabelecidas, até mesmo os stakeholders que nada têm a ver com TI costumam se referir ao “projeto de atualização do fornecedor X de ERP”, não ao projeto de modernização de “finanças” ou da “cadeia de suprimentos”.
Procure reduzir os custos e os riscos das atualizações para as partes de menor valor do sistema
Para o primeiro continente – elementos diferenciadores de ERP – os CIOs devem insistir em atualizações imediatas. Mas para o segundo – elementos não diferenciadores de ERP – eles devem sequenciar as atualizações cuidadosamente a fim de gerenciar melhor os custos e os riscos. Com isso, a atualização deixa de ser um único projeto plurianual e se torna uma série de projetos menores de software, cada um com duração de alguns meses. Essa redução do escopo diminui os riscos (projeto pequeno = riscos pequenos) e adia gastos, liberando recursos que poderão ser melhor utilizados em programas de transformação que agreguem valor rapidamente.
Verificamos que TI pode capturar essas vantagens adotando três medidas para reduzir a complexidade da configuração monolítica do ERP (Quadro 2).
1. Desacoplar conexões desnecessárias
A substituição do sistema principal pode ser uma tarefa desalentadora devido à variedade de conexões com outros aplicativos. Algumas dessas conexões permitem a execução de funções padrão (por exemplo, contas a pagar), seguem todas as diretrizes de arquitetura do fornecedor e são fáceis de manter. Elas fazem o trabalho para o qual foram projetadas e não devem ser mexidas. Contudo, muitas vezes há várias outras conexões entre partes do sistema que surgiram como soluções alternativas, improvisadas ou específicas, e foram adotadas por uma ampla variedade de razões – por exemplo, um desenvolvedor que decidiu que seria mais fácil acessar diretamente um banco de dados criando algo customizado do que utilizando uma interface modular. A quantidade e diversidade dessas conexões tornam qualquer esforço de modernização altamente complexo e demorado.
Para reduzir essa complexidade, o primeiro passo é criar uma nova camada entre o sistema principal e os aplicativos aos quais ele se conecta. Isso costuma ser chamado de “fachada” [façade]. Todas as novas conexões irão para essa camada de fachada por meio de APIs que acessam dados do sistema ERP. Dessa forma, múltiplas conexões podem ser desacopladas do sistema principal. Isso oferece a grande vantagem de permitir que se façam alterações no sistema (como implementar facetas de arquitetura modular) sem afetar todos os aplicativos conectados. Uma fachada pode ser construída em menos de um ano. Não precisa ser 100% perfeita; basta que seja funcional.
Entretanto, os desenvolvedores não utilizarão nem mesmo uma boa fachada a menos que haja uma governança eficaz que obrigue a sua adoção. Uma maneira de fazer isso é facilitando as coisas, por exemplo, permitindo que as equipes de produto acessem as funcionalidades principais sem terem que passar por longos mecanismos de aprovação e esperar que alguém da equipe principal crie uma interface específica. Além desses incentivos, também podem ser necessárias algumas sanções – como penalidades para quem não seguir os novos protocolos.
2. Eliminar customizações
A maioria dos sistemas principais foi customizada até a morte, desde funções complexas de relatórios até protocolos de acesso personalizados. Cada customização precisa ser migrada – e, muitas vezes, retificada de alguma forma – para o novo ambiente, o que pode ser arriscado devido à complexidade correspondente. Para resolverem esse problema, as empresas precisam construir uma plataforma digital (geralmente na nuvem) que possa ser acessada por meio de microsserviços. O número e a função dessas plataformas digitais podem variar; algumas empresas, por exemplo, criarão uma plataforma para funções voltadas para o cliente, outra para a cadeia de suprimentos e ainda outra para o próprio sistema ERP. A plataforma se torna assim o local para o qual as funções customizadas podem ser movidas e onde o novo código é desenvolvido.
É importante determinar quais customizações são mais importantes. Esse processo inevitavelmente revelará que muitas delas deixaram de ser necessárias e podem ser removidas, simplificando assim a atualização.
3. Encolher o sistema principal
Depois que as customizações forem removidas do sistema principal, é necessário começar a encolher o próprio núcleo até sua funcionalidade mais necessária.
Este é, em essência, um processo de desagregação que remove as muitas conexões intricadas que tantas vezes são incorporadas aos grandes sistemas. Dessa forma, desenvolvedores e engenheiros podem substituir ou melhorar uma funcionalidade específica sem afetar as demais partes do sistema. O processo geralmente também inclui limpar a base de código, tornando-o mais fácil de entender e, portanto, de corrigir ou substituir.
Conforme observamos, esse processo de desagregação não precisa atingir as áreas funcionais, como contabilidade ou controladoria, que executam operações padrão dentro do sistema ERP. Apenas as funções que, sem nenhuma razão funcional, costumam fazer parte de um núcleo fortemente acoplado (como gestão de armazéns, previsão da demanda ou transporte) são candidatas a residirem fora do sistema principal de ERP.
Atualizações do ERP são eventos massivos, complexos e necessários, especialmente quando a pressão sobre os negócios aumenta e os provedores de nuvem e de ERP lançam novos softwares e serviços. Contudo, se adotarem uma abordagem que englobe produtos e plataformas, as empresas poderão priorizar as atualizações que criam valor e reduzir o risco daquelas que não criam. Dessa forma, poderão gerenciar melhor os custos e melhorar os resultados.