Modernizar um sistema de armazém com 12 anos sem parar os camiões

O software mais perigoso numa pequena empresa é o software que funciona. Não a ferramenta cheia de erros de que toda a gente se queixa — essa acaba por ser substituída. O perigoso é o sistema de doze anos que ninguém ama mas de que todos dependem, aquele que arranca a partir de uma torre bege a um canto e que gere o armazém desde antes de metade da equipa ter sido contratada. Funciona. Até ao dia em que quase deixa de funcionar, e todos percebem ao mesmo tempo que o negócio inteiro está equilibrado sobre ele.

Esta é a história de um desses sistemas e de como o substituímos. O cliente é um distribuidor regional — alguns milhares de referências, um único armazém, cerca de trinta pessoas entre o pavilhão e o escritório. Anonimizámo-los e arredondámos os números, mas a forma do projeto é exatamente a que aconteceu. Se está sentado sobre um sistema envelhecido que tem medo de tocar, é mais ou menos assim que uma modernização sensata se vê por dentro.

Não há nesta história nenhuma reescrita heroica, nenhum fim de semana em que carregámos num interruptor e tudo estava novo. O ponto essencial — o que a fez resultar — é que nada de dramático aconteceu. Os camiões continuaram a carregar. O armazém mal sentiu o chão a deslocar-se sob os seus pés. É esse o objetivo no trabalho com sistemas legados, e vale a pena perceber porquê.

A situação: um sistema sustido pela memória de uma só pessoa

O armazém funcionava num sistema feito à medida, construído por volta de 2013 por um programador que já há muito tinha seguido o seu caminho. Cumpria o essencial — controlar o stock, imprimir listas de picking, fazer sair as encomendas — e, num dia normal, fazia-o bem. O problema não era propriamente o software. O problema era tudo o que tinha crescido à volta do software para o manter utilizável.

Ao longo de uma década, a equipa tinha construído em silêncio um sistema-sombra feito de remendos: uma folha de cálculo para as contagens de stock que o software errava, uma segunda folha que reconciliava a primeira com a realidade, um grupo de WhatsApp onde o responsável de armazém assinalava artigos que o sistema não sabia representar, e um dossiê impresso de soluções de recurso que os novos colaboradores tinham de decorar. Nada disto estava documentado num único sítio. Vivia na cabeça da responsável de operações, uma mulher serena na casa dos cinquenta, há catorze anos na empresa e que era, na prática, a documentação.

Quando o dono nos ligou pela primeira vez, não foi por causa de uma avaria. Foi porque ela tinha anunciado que queria reformar-se dentro de dois anos, e ele tinha feito as contas e percebido que, no dia em que ela saísse, uma parte significativa de como o armazém realmente funcionava sairia pela porta com ela. Esse é um gatilho de modernização mais comum do que qualquer falha técnica: não o sistema a partir-se, mas a constatação de que as pessoas que o remendam não estarão cá para sempre.

Os sintomas que todos tinham deixado de notar

Quando passámos os nossos dois primeiros dias apenas a observar o armazém a trabalhar, os custos do velho sistema estavam por todo o lado — mas tinham-se tornado tão normais que ninguém os assinalava já como problemas. Confiava-se nos números de stock ao ponto de os dar por errados por uma margem previsível, pelo que toda a encomenda grande recebia uma verificação física manual «por via das dúvidas». O pessoal novo levava semanas a tornar-se útil, porque grande parte do trabalho era saber não escrito. E o sistema corria num sistema operativo tão antigo que já não podia ser atualizado, numa rede que o dono sabia em privado ser um incidente de segurança à espera de acontecer.

• A exatidão do inventário rondava os 80 %, pelo que o pessoal voltava a contar à mão tudo o que fosse importante — horas por dia, em silêncio.
• A lógica da lista de picking não dava conta da disposição atual do armazém, pelo que os preparadores seguiam o percurso indicado pelo dossiê, não pelo ecrã.
• A reconciliação de stock de fim de mês ocupava duas pessoas durante a maior parte de três dias.
• Só uma máquina conseguia executar a parte de administração do software e, se avariasse, ninguém tinha um plano claro.
• Nada se ligava ao canal de encomendas online que a empresa tinha acrescentado em 2019 — essas encomendas eram redigitadas à mão.

O que deliberadamente não fizemos

A jogada óbvia — a que muitos fornecedores teriam proposto — é comprar uma grande plataforma de gestão de armazém pronta a usar, migrar tudo num fim de semana e desligar o velho sistema na segunda-feira de manhã. Vimos esta abordagem correr mal vezes suficientes para não a propormos a um negócio como este. Uma transição de uma só vez pressupõe que se compreende o velho sistema por completo. Com uma década de remendos não documentados, ninguém o compreendia — nem sequer quem o fazia funcionar.

A segunda jogada tentadora é uma reescrita completa à medida, do zero: pegar em tudo o que o velho sistema faz, reconstruí-lo de forma limpa e lançar o novo. Soa responsável e é uma forma clássica de queimar um ano e um orçamento grande enquanto o negócio espera, congelado, por um substituto que continua a escorregar. O problema é que uma reescrita tem de reproduzir cada peculiaridade antes de poder arrancar — incluindo as peculiaridades de que ninguém se lembra serem estruturais até faltarem.

Por isso não fizemos nenhuma das duas. Tratámos o velho sistema não como algo a demolir, mas como algo a rodear e substituir lentamente — uma capacidade de cada vez, com o velho sistema a continuar a funcionar por baixo como rede de segurança durante todo o caminho. Sem brilho. E também a única versão disto que funciona de forma fiável.

A abordagem: estrangular o velho sistema, não o rebentar

Entre os programadores há um nome bem conhecido para este padrão — a abordagem «strangler» (estranguladora), batizada a partir de uma trepadeira que cresce à volta de uma árvore até se conseguir suster sozinha e o original desaparecer em silêncio. Não se substitui o velho sistema num só movimento. Constroem-se novas peças à sua volta, encaminha-se trabalho real para elas uma de cada vez, e deixa-se o velho sistema encolher até que o que resta seja pequeno o suficiente para o desligar sem que ninguém suste a respiração.

Para este armazém, isso significou acordar à partida uma sequência: que capacidade destacaríamos primeiro, qual guardaríamos para o fim e — fundamental — uma regra segundo a qual em cada etapa, se a peça nova se portasse mal, podíamos voltar de imediato ao velho método nesse mesmo dia. A nenhum passo foi permitido ser um ponto sem retorno até ao fim mesmo. É essa única regra que deixou o dono dormir e que fez o pessoal do armazém confiar no projeto em vez de se opor a ele.

1. 1
   Mapear o que o sistema realmente faz

   Três semanas a acompanhar de perto o pavilhão e o escritório para documentar o fluxo de trabalho real — incluindo cada solução de recurso em folha de cálculo e dossiê. Registámos o sistema que existia, não o que a especificação original descrevia.
2. 2
   Limpar os dados antes de os mover

   Fizemos uma contagem física completa do stock e limpámos a base de dados de produtos em função dela. Migrar dados sujos para um sistema novo só dá mais depressa a resposta errada — por isso isto veio antes de qualquer software novo tocar nos dados.
3. 3
   Substituir primeiro a peça mais dolorosa

   Construímos o novo módulo de controlo e contagem de stock, corremo-lo em paralelo com o antigo e só confiámos nele quando os números corresponderam à realidade durante um mês inteiro.
4. 4
   Ligar os canais que o velho sistema ignorava

   A seguir ligámos o canal de encomendas online diretamente aos novos dados de stock, acabando com a redigitação manual que existia em silêncio desde 2019.
5. 5
   Destacar o resto e depois reformar o velho núcleo

   Picking, relatórios e reconciliação mudaram um a um. Quando quase nada de real corria no velho sistema, finalmente desligámo-lo — já um não-acontecimento.

As partes que foram genuinamente difíceis

Seria desonesto apresentar isto como suave. O trabalho técnico foi a parte fácil. As partes difíceis foram humanas e processuais, e são as mesmas partes difíceis de quase todos os projetos de sistemas legados.

A regra não documentada que partiu uma funcionalidade

Duas semanas depois de o novo módulo de stock estar a correr em paralelo, os números desviaram-se numa categoria de produto e não conseguíamos perceber porquê. Após um dia a escavar, a responsável de operações mencionou, quase de passagem, que certos artigos a granel eram contados à palete, não à unidade, e que o velho sistema tinha uma conversão escondida embutida que ninguém tinha documentado numa década. Não constava de nenhuma especificação. Vivia apenas na cabeça dela e no dossiê. Nunca a teríamos encontrado só a partir do código — apenas correndo ambos os sistemas lado a lado e perguntando porque é que discordavam. Esse é todo o argumento a favor do funcionamento em paralelo, numa anedota.

Conquistar o terreno

O pessoal do armazém tinha sobrevivido a mais do que uma «melhoria» bem-intencionada que lhe piorou o dia, pelo que recebeu o projeto com uma desconfiança razoável. Não a combatemos com uma apresentação. Escolhemos o preparador que mais se queixava, sentámo-nos com ele uma manhã e reconstruímos o ecrã de picking em torno da forma como ele realmente percorria o terreno. Assim que ele começou a defender o novo sistema na sala de pausa, o resto seguiu. Em projetos de sistemas legados, o crítico mais duro, uma vez conquistado, torna-se o seu melhor defensor — e isso não se compra com uma circular.

Os resultados, um ano depois

Desconfiamos de números antes-depois reluzentes, porque cada empresa mede de forma diferente e os seus vão variar. Trate-os, pois, como números honestos e arredondados de um projeto, destinados a mostrar a forma do retorno e não uma promessa. O essencial tem menos a ver com qualquer métrica isolada e mais com o que deixou de meter medo.

O número que mais importava ao dono não estava em gráfico nenhum. Foi que, quando a responsável de operações se reformou de facto — uns meses antes do previsto, como se veio a verificar —, o armazém nem sequer vacilou. O conhecimento que antes vivia na cabeça dela vivia agora num sistema em que qualquer pessoa podia ser formada em dias. A razão original de todo o projeto ficou resolvida, em silêncio e por completo.

Se está sentado sobre um sistema como este

A maioria dos donos com um sistema central envelhecido sente duas coisas ao mesmo tempo: é arriscado mantê-lo e é aterrador substituí-lo. Ambas são verdade. O erro é deixar o segundo medo vencer, porque o risco do velho sistema não se mantém estável — cresce em silêncio a cada ano, à medida que as pessoas que o entendem se aproximam da saída e a plataforma em que corre se afasta cada vez mais do suporte.

Não tem de escolher entre «deixá-lo em paz e rezar» e «apostar a empresa numa grande reescrita». O caminho do meio — rodeá-lo, substituí-lo peça a peça, manter o antigo como rede até o novo ter conquistado a confiança — é mais lento e bem menos heroico. É também a versão que não para os camiões. Se há uma coisa a reter de toda esta história, é essa.

Perguntas frequentes