A segunda parte deixou você com uma lista de uma página: os arquivos críticos, seus responsáveis, o que depende deles e se têm backup. Essa lista diz o que migrar. Esta parte diz o que não deve migrar do jeito que está.

A suposição comum é que a migração é uma etapa técnica: exportar um arquivo, importar no sistema novo e pronto. Tecnicamente isso é verdade, e na prática é o jeito mais rápido de transformar um problema pequeno em um problema caro. Uma planilha é tolerante por natureza: aceita qualquer coisa que você digite em qualquer célula e deixa para você o trabalho de interpretar. Um sistema não é: ele espera que uma data seja uma data, que um número seja um número e que um cliente seja uma única entidade com um registro. Por isso, quando dados sujos migram, a bagunça não desaparece; ela aparece em relatórios que não fecham, notas que não se vinculam ao cliente e saldos que não batem. Aí vem a frase que encerra muitos projetos: o sistema novo não funciona.

Por que a limpeza precisa vir antes da migração, e não depois

Adiar é tentador por um bom motivo: limpar é um trabalho chato que não aparece em nenhuma apresentação, enquanto a tela de um sistema novo aparece. Então se decide migrar agora e limpar depois. Mas, assim que os dados entram, começam a se movimentar: notas são emitidas contra clientes duplicados, pedidos se vinculam a itens duplicados e relatórios são montados com números incompletos. Cada nova transação acrescenta uma camada sobre o erro que torna a correção mais difícil e arriscada, porque editar um registro sobre o qual transações financeiras se movimentaram não tem nada a ver com editar uma célula em um arquivo.

Dados sujos são uma causa recorrente de projetos de sistemas travados em geral, e nós a apresentamos junto com as outras causas em por que projetos de ERP fracassam e como fazer o seu dar certo. A conclusão prática é que a limpeza custa menos enquanto os dados estão em um arquivo estático, e custa mais quando eles já vivem em um sistema em operação.

As cinco falhas presentes em quase toda planilha

Não são erros exóticos; são o resultado natural de uma ferramenta que permite tudo. Você vai encontrar a maioria delas no seu próprio arquivo:

  • Uma mesma parte com vários nomes. O mesmo cliente aparece três vezes: uma com o nome fantasia, outra com o nome do dono e outra como uma abreviação digitada por alguém com pressa. No arquivo, são linhas vizinhas que qualquer leitor entende. Em um sistema, viram três clientes separados, cada um com seu próprio saldo e histórico, então o registro do relacionamento se divide e nenhum dos três mostra o quadro completo. A mesma falha atinge itens e fornecedores.
  • Formatos de data misturados. Uma única coluna com uma data como dia/mês, outra como mês/dia e uma terceira escrita como texto, por exemplo depois do feriado ou fim do mês. Enquanto só pessoas leem, passa; mas qualquer ordenação, cálculo de prazo ou relatório por período baseado nessa coluna vai devolver uma resposta errada com toda a confiança, o que é mais perigoso do que devolver um erro visível.
  • Números armazenados como texto. Um valor digitado com o símbolo da moeda dentro da célula, uma quantidade com a unidade de medida no mesmo campo ou um número que começa com um espaço perdido. Para os olhos parece um número e para a máquina não é, então não soma, não compara e não migra; e normalmente você descobre isso no primeiro relatório financeiro depois da migração.
  • Colunas que ninguém sabe definir. Uma coluna chamada observações, status ou temp, criada anos atrás para um propósito que já acabou, às vezes preenchida e às vezes vazia. Ela costuma viajar porque ninguém tem coragem de apagá-la, então entra no sistema como um campo sem definição e sem responsável, e continua aparecendo nas telas para confundir quem vier depois de você.
  • Células coloridas que carregam significado. A mais perigosa da lista. Amarelo significa vencido, vermelho significa em espera, verde significa recebido. Isso não é formatação, é dado; mas dado guardado na cor e na memória de quem a aplicou. Quando o arquivo é exportado, o texto viaja e a cor se perde, então você perde informações com as quais tocava o negócio todos os dias, sem nenhum aviso.

A regra única: todo significado fora da célula precisa virar um campo

Se você guardar só uma frase desta parte, que seja esta: qualquer significado guardado em uma cor, na posição de uma linha ou na cabeça de alguém precisa virar uma coluna escrita antes de viajar. O teste é simples e implacável: exporte o arquivo para texto simples, sem nenhuma formatação, e pergunte que informação foi perdida. Tudo o que desaparece nesse teste é exatamente o que precisa virar um campo agora.

A conversão em si não é trabalho técnico; é um exercício de definição. Não basta criar uma coluna de status: é preciso fixar os valores permitidos e resolver os que se sobrepõem. Em espera e cancelado são um estado ou dois? Em que momento exato um registro passa a estar vencido? São perguntas sobre como a empresa funciona, não sobre programação, e são a coisa mais valiosa que um dono tira da fase de limpeza, porque respondê-las com clareza uma vez acaba com discussões que antes eram resolvidas de boca a cada vez.

A visão da Origami

Somos uma empresa de tecnologia que desenvolve sistemas para empresas sauditas, e tratamos a fase de limpeza como parte do desenho do sistema, e não como um trabalho administrativo que vem antes dele. O motivo é que cada falha nos dados expõe uma regra de negócio não escrita: um cliente duplicado revela que não existe um identificador acordado para uma parte, e uma célula colorida revela um estado operacional real que ninguém nunca reconheceu formalmente. Essas descobertas são a matéria-prima de um desenho correto, e por isso as analisamos com o cliente em vez de jogá-las em uma ferramenta de importação.

A ordem que recomendamos é unificar primeiro as definições: quem conta como um cliente, o que conta como um item e quais valores são permitidos em cada campo de decisão. Depois disso, a migração vira uma operação limpa que pode ser repetida e revisada. É aí que começam nossos serviços de desenvolvimento de sistemas, e é a mesma lógica que lemos em um caso real que abordamos em de uma loja para um sistema: o que separa operações organizadas de operações improvisadas não é a interface, mas a disciplina de dados por baixo dela.

Uma ordem prática para a limpeza

Limpar cada arquivo por completo é um projeto sem fim. Trabalhe em uma ordem que entregue algo migrável em poucos dias:

  • Comece pelos dados mestres, não pelas transações. Clientes, itens e fornecedores são listas curtas usadas repetidamente, e limpá-las corrige automaticamente os milhares de linhas que vão se vincular a elas depois. Notas e pedidos vêm em seguida.
  • Adote um identificador por entidade. Um código ou número fixo que nunca muda e nunca é reutilizado; depois associe a ele cada nome e abreviação antigos. No caso dos clientes em especial, dados legais exatos do comprador não são um capricho, porque os requisitos de faturamento eletrônico da Autoridade de Zakat, Impostos e Alfândega (ZATCA) especificam o que uma nota fiscal precisa conter; e apresentamos a ligação entre uma movimentação e sua nota em faturamento eletrônico na fábrica e no armazém.
  • Divida toda célula composta. Quantidade em uma coluna e unidade de medida em outra, valor em uma e moeda em outra, nome em uma e celular em outra. A regra é um campo para uma informação.
  • Padronize os formatos antes de qualquer importação. Um único formato de data em todo o arquivo, números sem símbolos dentro da célula e um único formato para números de celular. O trabalho é repetitivo e chato, mas é feito uma vez só.
  • Registre suas decisões de limpeza em uma planilha à parte. O que foi mesclado com o quê, o que foi excluído e o que continua duvidoso. Quando alguém perguntar dois meses depois para onde foi determinado cliente, essa planilha é a resposta; sem ela, a equipe perde a confiança em toda a migração.
  • Não apague o original. Guarde o arquivo anterior à limpeza como uma cópia fechada e somente leitura. Limpar envolve julgamento, e julgamento precisa de uma referência para onde voltar.

E não espere ter dados perfeitos para migrar, porque eles nunca chegam. A limpeza de que você precisa é que os campos críticos estejam corretos, consistentes e definidos, e que o que continuar incompleto seja conhecido e registrado, em vez de ser descoberto mais tarde como surpresa.

Nas próximas partes

Agora os dados estão aptos a migrar, e resta a pergunta que decide se a operação continua durante a transição ou para: o que migra primeiro? A próxima parte trata da ordem de migração, de por que os dados mestres sempre vêm antes das transações e de como funciona a operação em paralelo com uma data de término declarada, e não aberta. Depois tratamos das permissões e de quem vê o quê, em seguida dos relatórios que você montava à mão, e encerramos a série com os primeiros trinta dias depois da migração.

Fontes