Migração de um sistema ERP para outro

Muitas vezes, a transição da empresa para um novo sistema ERP não interrompe os custos financeiros da compra e conclusão, mas a necessidade de migrar do sistema antigo. Eles têm centenas ou mesmo milhares de usuários que realizam seus processos de negócios em um programa e, de alguma forma, precisam ser transferidos para outro sem interrupção nos negócios.

Nos últimos anos, seguimos esse caminho várias dezenas de vezes e já desenvolvemos a maneira menos dolorosa de fazer isso.

Dificuldades

O dia em que Bison honrou sua vila com sua presença, tornou-se para você a coisa mais importante na vida. Mas para mim era terça-feira.
- Bayson, lutador de rua

O processo de transição geralmente é complicado pelo fato de muitos funcionários especialmente impressionáveis ​​do cliente estarem em pânico pela primeira vez, pois para eles essa é provavelmente a primeira migração em sua carreira. Para nós, esse é um evento comum, que, em regra, ocorre de acordo com o mesmo cenário.

Quando qualquer pessoa troca um produto por outro, a primeira coisa que ele percebe é que foi tirado dele e ainda não percebe o que recebeu . Portanto, muitas vezes a primeira reação é: "que bobagem você me colocou aqui - faça como foi". Na prática, tivemos uma situação em que um usuário reclamou que não estava confortável com a nova ação, o que foi feito no sistema antigo em cinco transições entre formulários. Mas ele aperfeiçoou tanto o automatismo que, para uma pessoa, era realmente mais rápido fazê-lo do que realizar duas ações novas, mas muito mais simples.

Outra dificuldade é que, durante a transição, os clientes gostam de mudar os processos de negócios para sua visão. Isso deve ser tratado com muito cuidado, pois os processos atuais "como estão" são garantidos para funcionar. Os processos incorporados no produto, como regra, também funcionam, pois são usados ​​por outros clientes. Mas novas invenções podem, em teoria, parecer bonitas, mas, na prática, elas vão se esvair, por causa das quais todo o processo pode ser interrompido.

Cenários

Na prática, existem dois cenários principais para mudar de um sistema para outro:

Momentary

A data da transição para o novo sistema é determinada. Todas as funções são desenvolvidas para descarregar dados do sistema antigo e carregá-los em um novo. No dia X, a migração começa à noite e, de manhã, todos os usuários com todos os processos de negócios começam a trabalhar no novo sistema de uma nova maneira.

Tudo é lindo no papel. Mas, na prática, existem pelo menos quatro categorias de problemas:

1. Treinamento . No momento da transição, como regra, muitos usuários treinados esquecem completamente o que foram ensinados. Eles começam a cutucar tudo e, como resultado, param de trabalhar com as palavras "nada funciona". Esse problema pode ser resolvido com a ajuda da equipe de suporte de primeira linha, que pode ajudar neste momento. Mas haverá tantas solicitações no primeiro dia da transferência que será impossível atendê-las com o número disponível de funcionários. Ou você precisa ter uma maneira de expandir rapidamente o número deles durante a transferência, o que também é bastante difícil de fazer.
2. Melhorias e erros . Como regra, um novo sistema ERP traz novos processos de negócios (caso contrário, por que alterá-lo). É claro que, imediatamente antes da implementação, eles foram afastados de alguma forma, mas no momento de uma verdadeira "verificação de batalha" geralmente surge uma enorme quantidade de nuances, por causa das quais frequentemente os processos não podem ser executados. Consequentemente, novamente o número de tais melhorias com prioridade imediata está crescendo como uma bola de neve, e há uma forte necessidade de recursos para programadores que fisicamente não serão capazes de fechar um número tão grande de solicitações.
3. Dados . Geralmente, os desenvolvedores do sistema antigo não gostam muito de ajudar a enviar dados (para eles, geralmente, é um evento triste de perder um cliente) e, se ajudarem, a qualidade do upload deixa muito a desejar. E inconsistências, como regra, são encontradas nos primeiros dias de operação de um novo sistema. Como resultado, é necessário corrigir a descarga e, de alguma forma, recarregar os dados, levando em consideração as alterações já realizadas durante a operação.
4. Performance . Durante o processo de teste, não é tão fácil reproduzir a carga completamente "real" no sistema. Se a funcionalidade básica do produto já está geralmente testada e mostra parâmetros de desempenho normais, as melhorias "pessoais" do cliente podem, em determinadas circunstâncias, "sentar" o servidor. Isso, por sua vez, também requer recursos do programador para otimização.

Quando todos esses quatro problemas ocorrem no primeiro dia ou semana da transição ao mesmo tempo, as perdas de negócios não podem ser evitadas. Portanto, esse esquema funciona apenas efetivamente em pequenos projetos. Por exemplo, quando o número de usuários é menor que cem e os processos não são críticos.

É claro que você pode gastar mais recursos em treinamento e teste do sistema imediatamente antes da transição e haverá menos problemas. Mas na vida, os funcionários do cliente geralmente se referem a esses processos "sem mangas" e confiam no "talvez". Ou eles estão simplesmente enganados, esperando que um determinado processo possa ganhar dinheiro em um determinado ambiente, mas, de fato, parece que pequenas nuances reduzirão tudo.

Gradual

Com essa abordagem, o sistema é dividido horizontalmente (por processos) ou verticalmente (por usuários) em partes, que são introduzidas uma após a outra. Isso permite espalhar todos os problemas acima com o tempo e resolvê-los à medida que eles recebem menos energia.

Além disso, descreverei o processo de migração de um sistema ERP baseado na plataforma aberta e gratuita da lsFusion para uma cadeia de lojas de varejo, uma vez que nos especializamos neste setor. Mas aplicamos o mesmo princípio a clientes de outras áreas.

Leitura de dados

Normalmente, para empresas que suportam o sistema antigo, a notícia de substituir o programa e perder um cliente é um grande golpe. Alguns caem em um estado inadequado e começam a ameaçar o cliente com uma parada imediata do suporte. Naturalmente, isso nunca funciona e nunca pode reverter a decisão. No entanto, raramente é possível concordar com aqueles que suportam o sistema antigo que eles forneçam tabelas onde todos os dados necessários para a transição estão armazenados.

Primeiro, você precisa determinar em qual DBMS as informações necessárias estão armazenadas e como acessá-las. Nos últimos anos, tivemos que lidar com os seguintes DBMSs com os quais os sistemas antigos funcionavam:

• Acesso Como a plataforma é escrita em Java, foi possível desenterrar uma biblioteca antiga que sabia como se conectar ao mdb (embora apenas para leitura). Funcionou muito peculiarmente porque, apesar dos filtros, lia toda a tabela, mas mesmo assim era o suficiente. Tivemos a sorte de o serviço de TI do cliente conhecer a estrutura do banco de dados muito bem e nos dizer o que e onde está armazenado.
• MS SQL O sistema antigo era o Axapta 2000. Nós configuramos o acesso ao sistema de teste, onde lançamos a GUI e o SQL Profiler. Em seguida, revezamos nos diretórios e analisamos as solicitações que o Axapta gera. Era fácil entender por onde exatamente essas informações são armazenadas.
• Visual Foxpro Tudo era simples, pois houve uma transição de nossos sistemas legados e não foi difícil obter informações. A única dificuldade foi encontrar uma biblioteca Java que possa funcionar não com tabelas DBASE, mas com o formato Visual Foxpro.
• Oracle Transição do programa em caixa supermag. Trabalhamos de acordo com um esquema semelhante ao esquema Axapta: GUI e consultas no SQL Developer para as consultas mais recentes. A estrutura básica e as interfaces eram certamente muito mais simples do que em Axapta, portanto não havia grandes problemas.
• Progresso / OpenEdge . Transição do programa Gestori in a box. Dado que o DBMS, para dizer o mínimo, não é de todo popular, não encontramos nenhum perfilador. No entanto, houve um despejo nos arquivos de texto. Isso tornou possível simplesmente acessar a GUI do servidor de teste e pesquisar nos arquivos de texto para pesquisar dados visíveis na tela. Felizmente, no site oficial deste DBMS, há uma oportunidade de baixar o driver JDBC e fazer consultas ao banco de dados SQL. Então era uma questão de tecnologia.

Graças a essas abordagens, nunca tive que recorrer aos desenvolvedores do sistema antigo, que economizavam significativamente as despesas dos clientes, pois geralmente eles simplesmente distribuíam enormes quantias de dinheiro para cooperação.

Dados mestre

Tudo começa com a importação de dados mestre. Em particular, no comércio varejista, as importações de diretórios de grupos de mercadorias, bens, prestadores de serviços e lojas são as primeiras a serem realizadas. Com uma transição gradual, há duas abordagens para importar dados mestre:

• Importação de dados únicos e entrada dupla no sistema antigo e novo.
• Atualização incremental contínua de dados do sistema antigo para o novo.

Há casos em que a primeira abordagem é usada, mas consome muito tempo e é altamente suscetível ao fator humano, com probabilidade de erros. Portanto, sempre usamos apenas a segunda opção.

Idealmente, o sistema antigo poderia acumular mudanças e, de alguma forma, comunicar que precisa ser reimportado. Mas geralmente ninguém muda ou modifica nada no sistema antigo. Portanto, o único esquema de trabalho que usamos é o seguinte:

1. Há uma solicitação para o diretório do sistema antigo, que lê todos os dados dele.
2. Os dados lidos são comparados com a corrente no novo sistema e as alterações são detectadas.
3. As alterações são gravadas em uma única transação no novo sistema.

O código na plataforma para importar o diretório do produto terá a seguinte aparência:

Isso funcionará da seguinte maneira:

• LER considera o diretório inteiro com o código e o nome na memória
• O IMPORT gravará todos os dados nas propriedades locais (ou seja, tabelas temporárias no banco de dados)
• O primeiro ciclo criará todos os bens que ainda não estão no novo banco de dados (procure pelo código do produto). Apesar do FOR estar escrito lá, ele é compilado em uma consulta no banco de dados, que funcionará apenas com tabelas temporárias.
• O segundo ciclo atualizará os campos para todos os produtos (incluindo os recém-criados). Nesse caso, apenas os valores alterados serão gravados em tabelas temporárias.
• A terceira ação DELETE detecta todos os bens que estão no novo banco de dados, mas não nos dados lidos, e os exclui.
• O APPLY iniciará a transação e gravará todas as alterações no banco de dados com base em tabelas temporárias geradas por comandos anteriores.

De fato, essa ação no momento do lançamento sincroniza completamente o diretório antigo e o novo. Ele não armazena nenhuma informação incremental e, portanto, pode ser reiniciado a qualquer momento, mesmo que a troca anterior tenha sido concluída com erros.

Como todas as ações são compiladas em consultas SQL sem nenhuma iteração, tudo isso é feito com rapidez e segurança. Normalmente, a troca de um diretório de mercadorias de 100 a 200 mil registros levava alguns minutos. Ao mesmo tempo, como o PostgreSQL é versionado, nenhum bloqueio de trabalho do usuário ocorre no momento.
Da mesma forma, os preços dos fornecedores, matrizes de sortimento, programações de pedidos e outras informações necessárias para o trabalho são constantemente sincronizadas. Aqui, no entanto, pode surgir um problema de que a lógica do domínio no sistema antigo não coincide com a nova lógica do domínio. Por exemplo, em nosso sistema, temos um histórico de versões da matriz e o conceito de níveis de produto dentro de uma matriz. Se, no sistema antigo, o sortimento atual de lojas é armazenado como um booleano para a loja e as mercadorias, uma matriz é criada para cada loja com exatamente um nível.

Na maioria das vezes, habilitamos a ação para sincronizar todos os diretórios com o sistema antigo uma vez por hora, enquanto fornecemos ao usuário a oportunidade de iniciar a troca manualmente.

O processo

No varejo, geralmente dividimos o processo de conversão verticalmente entre lojas e simultaneamente horizontalmente dos processos da loja para os processos do escritório.

O primeiro passo é escolher uma loja onde a transferência para o novo sistema começará. Importa saldos atuais e preços de loja do sistema antigo na forma de documentos recebidos com as quantidades e preços correspondentes:


Algumas semanas antes do início da loja, a importação da implementação dos sistemas POS está conectada. Isso é necessário para que haja dados históricos para a formação de pedidos nos primeiros dias de trabalho.

Muitas vezes, o processo de produção própria é transferido um pouco mais tarde que os processos principais. Nesse caso, é implementada a descarga no antigo sistema de documentos sobre movimentação de matérias-primas e importação de produtos acabados.

No dia da transferência, a importação começa à noite e, em seguida, a equipe de suporte ao cliente e nossa primeira linha de suporte são enviadas para a loja. Eles ajudam os usuários a iniciar o novo sistema sem precisar fazer um pré-treinamento. Nesse caso, geralmente por algum tempo, a alteração de documentos no sistema antigo não fecha, pois as pessoas estão enganadas e precisam da capacidade de corrigir erros. Após algumas semanas, os remanescentes são reimportados e, em seguida, a proibição de alterações no sistema antigo já está em vigor.

Depois que todos os problemas descritos acima são identificados e resolvidos na primeira loja, depois de algumas semanas outras 2-3 lojas são transferidas. Novamente uma iteração para identificar e corrigir problemas. E todos os outros são traduzidos muito rapidamente, dependendo dos recursos do serviço de suporte ao cliente do cliente. Todo esse tempo, os dados mestre continuam sendo inseridos no sistema antigo, para que as lojas possam funcionar no sistema antigo.

Em seguida, quando todas as lojas são transferidas, gradualmente ou todas elas desativam imediatamente as importações do sistema antigo, e os usuários começam a inserir dados mestre no novo sistema.

As informações de resumo dos sistemas antigo e novo são obtidas na contabilidade ou no sistema de BI, em que os dois sistemas são carregados ao mesmo tempo. Lá, você pode obter relatórios resumidos para o intervalo, que incluem o tempo nos sistemas antigo e novo.

Conclusão

Apesar da aparente complexidade da transição de um sistema para outro, tendo percorrido esse caminho várias dúzias de vezes, você entende que, com um esquema depurado, na verdade tudo não é tão assustador. Mais problemas surgem com o fato de a maioria dos funcionários do cliente ser bastante conservadora e, na menor oportunidade, exigir que seja "do jeito que foi". E aqui é muito importante que o cliente tenha uma pessoa com autoridade suficiente que possa comparar processos antigos e novos, determinar quais são mais ideais e ser capaz de "quebrar" os funcionários. Ou modifique o processo de acordo com o esquema "como estava", se ocorrer o contrário.