Combinar sistemas contábeis de uma filial remota e sua integração com a estrutura matriz é uma tarefa bastante difícil, mesmo dentro da Rússia. E quando o cliente está no exterior, todo o projeto pode complicar a falta de conhecimento nas leis tributárias locais e o conflito de mentalidade. Meu nome é Stanislav Gotz, sou o chefe do departamento de desenvolvimento de sistemas ERP da Lamoda e, neste post, vou falar sobre essa experiência - sobre a implementação de um sistema ERP em nossa filial alemã.
Nossa subsidiária alemã compra mercadorias e as vende para uma entidade legal russa. O sistema Tsenit usado nele permitia manter registros apenas no nível dos dados financeiros: quem, quem e quanto dinheiro devia, quando a compra ou venda ocorreu, etc. Era impossível realizar a contabilidade de mercadorias e tarefas logísticas usando as ferramentas Tsenit; para resolver esses problemas, eram necessárias ferramentas adicionais, que afetavam negativamente a velocidade e a confiabilidade de todo o sistema. Os dados, como resultado, foram espalhados por vários bancos de dados.
Além disso, a entidade legal alemã deve enviar relatórios, pagar impostos e passar nas auditorias - e com os sistemas contábeis existentes não foi fácil resolver esses problemas.
Para entender por que essa ou aquela transação financeira foi feita no Tsenit e responder a perguntas simples das autoridades fiscais ou auditores, tive que cavar manualmente grandes quantidades de dados no Excel e entrar em contato com o departamento de logística.
Em algum momento, foi decidido combinar contabilidade e finanças com logística em um único circuito dentro da estrutura de um sistema ERP de uma única filial. Como o principal software foi escolhido, o Microsoft Dynamics 365 - antigo Dynamics AX, ou ainda mais fácil - Axapta. Quase não há clientes russos usando a solução em nuvem deste sistema (para ser mais preciso, nos tornamos o segundo), mas era mais adequado para nossos propósitos.
Momento, Orçamento e Crença em um Futuro Brilhante
Tínhamos prazos rígidos: o lançamento de um sistema desse tipo no meio de um ano fiscal exigia a transferência de todo o conjunto de dados históricos, o que seria uma tarefa impossível, porque no sistema antigo, a contabilidade de mercadorias estava praticamente ausente e mantida em planilhas. Porém, no início do período coberto pelo relatório, basta transferir apenas saldos. Portanto, era necessário lançar 1 de janeiro de 2019 ou adiá-lo por mais um ano. Os processos associados à logística de comércio e armazém não são particularmente complexos e parecia-nos que não haveria problemas com prazos.
Além dos prazos, havia também um problema de orçamento: implantar e manter sua própria infraestrutura de TI na Alemanha e comprar licenças de software corporativo é muito caro por usuário.
Como não mais de 20 pessoas participam dos processos de negócios alemães, optamos pela solução em nuvem Dynamics 365. Para pequenas filiais remotas, o esquema SaaS é ideal, permitindo que você obtenha todos os ambientes de software e desenvolvimento necessários para iniciar a implementação imediatamente após a assinatura do contrato com o provedor.
A política de licenciamento do Microsoft Dynamics 365 é extremamente simples e pressupõe um preço fixo para uma licença de usuário por mês, enquanto o número de usuários pode ser aumentado ou diminuído. Esse foi outro argumento para a escolha desse produto de software específico.
Armadilhas
O principal problema estava fora do plano técnico: não conhecíamos todos os requisitos da legislação europeia para manter registros nesses sistemas. O Microsoft Dynamics 365 cobre um grande número de processos de negócios; são lançados os chamados pacotes de localização que permitem personalizar de forma flexível a solução para as especificidades da legislação de um país específico. Se a equipe de desenvolvimento estudou a versão em russo por um longo tempo, nunca encontramos uma versão para a Alemanha. Configurar essa solução por sua própria equipe seria uma tarefa difícil.
A administração alemã temia que o lado russo não pudesse lidar com a tarefa devido à falta de experiência e conhecimento em impostos e contabilidade locais. Como resultado, escolhemos o meio termo e atraímos consultoria externa. Deveria fechar as lacunas associadas aos requisitos legais europeus, fornecer uma auditoria da migração do sistema financeiro anterior, analisar as descrições dos processos de negócios, otimizá-los e ajustar a solução futura com o uso máximo da funcionalidade padrão. Se necessário, eles estavam planejados para serem concluídos, mergulhando gradualmente a equipe russa no desenvolvimento.
Início da implementação e transferência de dados
Por padrão, temos direitos para três ambientes: BUILD - para montar código criado por diferentes desenvolvedores em um aplicativo, SAT (Standard Acceptance Testing) - para realizar testes de aceitação do usuário e PROD - para operação. Além disso, as máquinas virtuais dev-box são implantadas para todos os desenvolvedores no Azure. Toda a infraestrutura é gerenciada e monitorada por meio de um único portal - serviços de ciclo de vida , e um recurso do processo de customização é que qualquer melhoria entra no ambiente PROD somente através do SAT.
Devido ao fato de o Microsoft Dynamics 365 ter sido escolhido como o novo sistema, a transferência de dados foi relativamente fácil de implementar usando os pacotes de dados disponíveis na caixa. O Dynamics 365 tem um relacionamento próximo com os produtos da Microsoft, incluindo o Excel: para o usuário, parecia uma planilha conectada aos serviços do Dynamics 365 via
ODATA . Usando a extensão do Excel, os usuários publicaram dados diretamente no sistema. O lado alemão preparou os modelos, observando as colunas necessárias neles. Os usuários preencheram esses modelos e os consultores controlaram o processo de importação.
Entre outras coisas, do antigo sistema contábil, os consultores transferiam informações sobre fornecedores e clientes, além de saldos nas contas contábeis. A transferência direta de todos os dados sobre mercadorias exigiria tempo e esforço consideráveis, e tentamos resolver esse problema de maneira mais eficiente. Foi implementada a integração do novo sistema contábil da filial alemã ao principal sistema russo, no qual estão localizados os dados mestre de mercadorias. No final do ano, não tínhamos balanços físicos na Alemanha e, como resultado, era necessário transferir do sistema antigo apenas as informações básicas necessárias para a distribuição futura das mercadorias. Assim, foi possível dispensar a transferência de todos os dados históricos sobre mercadorias, o que economizou tempo.
Meia terceirização: conectando a equipe russa
Tendo iniciado a implementação em junho de 2018, esperávamos resolver todos os problemas antes do feriado de Ano Novo, mas, além dos problemas de linguagem natural em tais projetos, surgiram dificuldades de comunicação. Os consultores alemães há muito respondem às perguntas. Um funcionário não pode trabalhar sem interrupção por mais de 6 horas seguidas. Depois de terminar o trabalho, ele deve ter no mínimo 11 horas de tempo livre do trabalho. E quando um especialista lida com outro cliente, ele não pode ser questionado sobre nada. Essa abordagem formal afetou o momento. Em algum momento, o contratado propôs, no ano novo, lançar apenas a contabilidade financeira, que já funcionava no sistema antigo. Isso não nos convinha. Desde 2013, implementamos independentemente o Axapta em Lamoda e, em 2016, transferimos completamente toda a contabilidade da 1C para ela. Os processos na Rússia são muito mais complexos, então sabíamos que o projeto poderia ser concluído no prazo.
Decidimos atrair a equipe russa, retirando de nossos colegas da Alemanha toda a personalização e desenvolvimento da funcionalidade do sistema. De fato, deixamos para o contratado externo apenas consultoria, definição de tarefas e design funcional. Eles nos disseram o que precisava ser feito, fizemos e depois testaram e aceitaram os resultados. A velocidade da implementação aumentou, mas logo essa organização do fluxo de trabalho exigiu revisão: o consultor financeiro alemão saiu de férias por três semanas. Para o projeto, esse prazo se tornou crítico, as principais tarefas para nós foram relacionadas precisamente a finanças, impostos e afins. Eu também tive que assumir essa parte. Como resultado, nossos especialistas descobriram que a legislação tributária européia não era muito pior do que a externa.
Além disso, constantemente havia algumas tarefas fora do padrão. Graças à imersão profunda da principal equipe russa em desenvolvimento, eles foram capazes de resolvê-los de forma relativamente rápida. Além disso, as soluções foram desenvolvidas inicialmente levando em consideração o conhecimento de todos os sistemas e processos utilizados em nossa empresa.
Uma dessas tarefas é a integração de um novo ambiente de nuvem com o sistema ERP russo existente. Ele já implementava funcionalidades relacionadas ao trabalho dos compradores e não queríamos duplicar o código para não complicar seu suporte. Como resultado, os pedidos de compra de mercadorias de fornecedores estrangeiros são criados no ERP russo e depois transferidos para a nuvem alemã.
No processo de implementação, a equipe russa dominou uma abordagem completamente nova de desenvolvimento para nós e novas ferramentas. Costumávamos usar nosso próprio IDE para Axapta, mas aqui mudamos para o Visual Studio e o Azure DevOps. Durante a implementação do projeto, as versões de software mudaram e nossos especialistas conheciam todas as delícias do desenvolvimento paralelo de ambientes em nuvem - em termos técnicos, foi muito interessante.
SureStep vs Agile: problemas de inicialização
Colegas da Alemanha trabalharam de acordo com a metodologia Microsoft SureStep. Esta é uma abordagem inflexível que está mais próxima da "cachoeira" clássica. Envolve em todas as etapas a documentação de tudo, a preparação de projetos funcionais e técnicos, testes rigorosos com o lançamento de protocolos, o registro de processos em algum sistema de modelagem, etc. Com a solicitação dessa documentação, os colegas entraram em contato conosco um mês antes do lançamento. O novo sistema ERP naquela época já estava mais ou menos funcionando. Assumindo o lançamento em seis meses, escolhemos métodos de desenvolvimento mais flexíveis: stand-ups diários, discussão de tarefas e lançamentos semanais. Para a documentação, usamos itens de trabalho no Azure DevOps, eles também refletiram o progresso do projeto e confirmaram os resultados do teste.
Como o sistema está nublado, a decisão final sobre o seu lançamento em produção foi tomada pela Microsoft, com todos os contatos realizados por nossos contratados. Eles, por sua vez, não estavam prontos para enviar um aplicativo sem toda a documentação necessária do ponto de vista da metodologia SureStep. Como resultado, o lançamento oportuno do projeto estava em risco.
Decidimos entrar em contato com o fornecedor por conta própria e recebemos a aprovação para entrar na produção, após o que, calma e sistematicamente, melhoramos a funcionalidade do sistema por conta própria. Os especialistas alemães nos ajudaram a transferir as configurações do ambiente de teste para o supermercado. Depois disso, eles criaram contabilidade e corrigiram as deficiências, se tivéssemos algum comentário.
Teste de batalha
Graças ao envolvimento oportuno de nossa própria equipe, conseguimos cumprir os prazos e lançar o sistema em 1 de janeiro de 2019, conforme planejado originalmente.
O novo sistema contábil combinou a parte financeira e a logística, já passamos por ele relatórios trimestrais na Alemanha. Antes disso, conseguimos realizar o chamado fechamento do mês sem perda significativa em termos. Ao lançar essa classe de sistemas, os atrasos são inevitáveis, mas em janeiro estávamos três dias atrasados e em fevereiro - apenas um. Enquanto coletamos dados do sistema manualmente, agora a equipe de desenvolvimento russa está envolvida na automação dos relatórios. Os problemas estão principalmente relacionados ao fator humano: é difícil para os funcionários executarem novos procedimentos para eles, e certamente haverá alguma rugosidade.
Agora, temos uma imagem transparente das mercadorias no nível do número do depósito individual (SKU) e dados sobre saldos em armazéns europeus intermediários. Não foi possível encerrar uma série de tarefas até o fim: há dificuldades com a integração com um banco alemão e vários problemas menores para a resolução oportuna da qual os recursos da equipe interna não eram suficientes - assumiu-se inicialmente que o contratado fecharia essa frente. Basicamente, tudo se resume à falta de um nível adequado de automação e a algum aumento na quantidade de trabalho manual para os usuários finais. Agora, estamos gradualmente fechando as lacunas com as forças de nossa equipe e com a ajuda de um novo parceiro com uma filial na Rússia.
O bônus que nossos desenvolvedores trabalharam no projeto também foi o fato de que, imediatamente no estágio de implementação, foram feitas melhorias para melhorar a funcionalidade do sistema.
A equipe russa desenvolveu uma determinação automática de impostos em pedidos de compra e venda. Por padrão, o sistema exige que o contador defina manualmente o esquema de impostos ao processar a fatura e lançar transações. Nesse caso, é necessário levar em consideração o país de remessa, o país de registro do fornecedor, que coleta as mercadorias (destinatário ou fornecedor), que envia as mercadorias para a Federação Russa (entidade legal alemã ou russa), se as mercadorias são retiradas diretamente do fornecedor para a Rússia ou se a carga é consolidada na Europa. O contador não possui todas essas sutilezas para cada entrega. Automatizamos completamente o processo no sistema para que o provedor de logística responsável introduza os parâmetros iniciais necessários. Além disso, o sistema com base nas próprias configurações criadas determina o esquema de impostos e os lançamentos contábeis necessários. Todos os dados são automaticamente consolidados nos relatórios estatísticos necessários para a Alemanha e a declaração de impostos. Assim, as responsabilidades são melhor distribuídas entre os especialistas, a velocidade e a confiabilidade do trabalho aumentam.
Sumário
Inicialmente, esperávamos que a maior parte do trabalho fosse do contratado e, como resultado, todos os principais blocos foram criados pelo nosso próprio desenvolvimento. Normalmente, o lançamento do ERP leva de 1 ano, mas conseguimos iniciar 6 meses após o início do projeto, dos quais o desenvolvimento ativo durou apenas 3 meses.
Como resultado, tivemos uma experiência única, que decidimos compartilhar. A cooperação com empreiteiros estrangeiros que conhecem as condições locais faz sentido prático, mas você não deve esperar milagres deles. Se você
possui uma equipe forte , terceirize apenas consultoria e configuração de tarefas, além de testes.
Este não é o fim da nossa história. Um novo desafio está associado à introdução na Rússia de um sistema nacional unificado para marcação de mercadorias. Os legisladores adiaram sua data de lançamento para 2020, mas a partir de julho queremos marcar cada par de sapatos com um código de barras exclusivo antes de passar pela alfândega. Além disso, sempre há tarefas relacionadas à otimização do desempenho. Bem, existem muitas outras idéias e planos. Em sua implementação, agora confiaremos mais em nossas próprias forças, pelas quais teremos que "engordar" um pouco.