Nosso armazém, do tamanho de dois quadrados vermelhos e altura de 5 andares, fica aberto o ano todo e nunca dorme - 24/7 364 dias por ano (o único dia de folga é 1º de janeiro). Armazenamos e atendemos mais de 8.000.000 de mercadorias, todos os dias mais de 300 operadoras mudam. Eles trabalham com mercadorias provenientes de todo o mundo e coletam pedidos de usuários de quatro países: Rússia, Ucrânia, Bielorrússia e Cazaquistão. Nessa escala, os negócios exigem automação impecável.
Por dentro, eu, Pasha Finkelstein - líder da equipe de desenvolvimento e automação do armazém - vou lhe dizer o que uma solução de código aberto pode crescer se você anexar uma boa equipe de desenvolvimento e uma tarefa de negócios muito específica a ela.
Lógica básica
Três processos principais de qualquer armazém: aceitação de mercadorias, armazenamento e expedição. O ciclo simplificado de nosso armazém é semelhante a: identificação primária, controle de qualidade, colocação, seleção e reserva de um pedido, pesquisa, classificação, embalagem, transferência para um serviço de entrega. Quando o cliente devolve o produto, o ciclo se repete. Cada entidade física que participa desses processos tem sua própria representação informacional, por exemplo: caminhão, produto, célula do armário, parcela, material de embalagem, contêiner, etc. Todos os movimentos significativos e mudanças no status das mercadorias são convertidos em sistemas contábeis e absolutamente todas as ações com as mercadorias dentro do armazém são registradas.
O WMS (Sistema de Gerenciamento de Armazém) controla o ciclo de vida de cada produto no depósito, desde o momento em que o caminhão com as mercadorias do fornecedor chega ao depósito até as mercadorias serem enviadas ao cliente.
As especificidades da automação de moda
Nossa empresa trabalha no campo da moda e estilo de vida, que apresenta certas tarefas no armazém: o produto pode ser frágil (óculos, relógios), tamanho fora do padrão (botas de inverno ou joias), premium (em embalagens especiais) - ou possuir outras características específicas que o armazém deve levar em consideração. Portanto, é impossível abandonar completamente o uso de trabalho manual nas áreas de armazenamento.
Todos os outros processos são automatizados - aceitação de mercadorias, transferência para a área de embarque, classificação, embalagem e preparação para embarque. Cada um desses processos requer equipamentos especiais e um processo operacional. A mágica acontece quando todos esses processos "se unem" e começam a trabalhar juntos - graças aos nossos sistemas.
Qualquer supervisão na automação do armazém - seja uma interface que contribua para erros do operador, um processo não ideal etc. - Isso é um atraso no envio, o tempo de inatividade de todo o complexo, enormes perdas. Além disso, a cada erro, criamos uma experiência negativa do cliente. Portanto, é importante para nós que o armazém funcione como um relógio.
Código aberto e o caminho para o próprio desenvolvimento
Na fase de abertura, usamos um armazém externo. Com o crescimento dos volumes, começamos a entender que precisamos de controle total sobre os processos operacionais e uma alta taxa de alteração desses processos, por isso decidimos avançar em direção ao nosso próprio armazém e desenvolvimento.
A principal questão que nos confrontou foi a elaboração dos processos operacionais em todos os detalhes. Até onde e como os funcionários vão, quantas verificações eles fazem, etc. E já nesses processos, era necessário implantar o WMS, que gerencia atividades operacionais e automatiza operações rotineiras.
Para começar, eles adotaram uma solução de código aberto em Java e decidiram montar sua própria equipe de desenvolvimento, principalmente porque já existe uma base adequada. Aumentamos a funcionalidade e, em seguida, assumimos o núcleo do sistema: nos livramos do legado e de um cliente gordo, realizamos refatoração, desenvolvemos novos serviços para dar suporte aos processos operacionais.
Estágios de automação
As principais mudanças foram realizadas pelas “ondas”, juntamente com a reestruturação dos próprios processos.
Até o momento, ele passou por nove estágios de modernização, e não pretendemos nos deter nisso.
- No primeiro e no segundo estágio, automatizamos os processos de remessa de pedidos - adicionamos transportadores, lógica para classificação de mercadorias, classificação automatizada de pedidos por paletes.
- No terceiro e quarto estágio, focamos nos processos de aceitação: aprendemos a separar os fluxos de entrada de mercadorias por diferentes tipos e zonas de armazenamento.
- A quinta fase adicionou elevadores automatizados entre os andares - foi assim que o trabalho começou na área de armazenamento.
- A sexta fase foi a mais crítica quando fechamos as zonas de aceitação e expedição, percorrendo toda a automação.
- Na sétima e oitava fases, fizemos alterações nos processos na zona de aceitação e adicionamos novas zonas, elevadores e transportadores: escalamos a automação existente.
- Na nona fase, eles adicionaram um novo edifício ao armazém e o integraram ao sistema de automação existente.
Implementação
Nossas principais tecnologias: Java, Postgres, Wildfly, Redis, ActiveMQ.
O WMS é escrito em Java 8. Mas não faz muito tempo, consertamos o último módulo, que impedia a transição para o Java 11, será atualizado em um futuro próximo.
Um rack de servidor instalado diretamente no armazém é reservado para o WMS. Isso nos dá muito mais confiança de que o WMS funcionará mesmo que a eletricidade e / ou a Internet estejam desligadas. A única coisa que sofrerá é que as mensagens para o sistema contábil chegarão com um atraso. O WildFly é usado como servidor de aplicativos, embora ainda não seja a versão mais recente. A migração para o último também está nos planos. Tudo já foi escrito para a mudança, mas ainda não conseguimos realizar testes funcionais e de carga e, antes do ano novo, a carga é relativamente alta. Um ActiveMQ comprovado também é usado.
Os dados que armazenamos no PostgreSQL. A principal essência do nosso sistema é obviamente um produto. Às vezes, os funcionários do armazém criam soluções alternativas para simplificar seu trabalho, por exemplo, digitalizam o mesmo código de barras 50 vezes, e o produto em si é simplesmente jogado manualmente sem digitalizar, sem entrar em detalhes, como jeans ou camisetas, então inserimos etiquetas identificando uma unidade específica bens, apoiando-o na infraestrutura. As informações sobre essas unidades são armazenadas em um banco de dados PostgreSQL de 2 terabytes.
A maior parte do local não é ocupada nem por mercadorias, mas por uma auditoria das ações dos trabalhadores do armazém. Sendo um sistema crítico para os negócios, o armazém deve saber por que algo apareceu no sistema ou desapareceu - não podemos permitir alterações não rastreadas. No momento, estamos pensando em levar essa parte do banco de dados para uma entidade separada no MongoDB.
As estações de trabalho da equipe do armazém são thin clients da web. Em algum momento do início da automação, tudo isso funcionava de acordo com o princípio de um cliente espesso, que criava certas dificuldades, em particular, com grandes lançamentos, que incluíam alterações na interface: cerca de 150 estações de trabalho precisavam ser atualizadas manualmente. Isso e o fato de não podermos liberar sem que o tempo de inatividade tenha estabelecido limites para nós - poderíamos implantar não mais que duas vezes por semana, no início da manhã, quando o turno da noite termina, o que não pode ser chamado de um cronograma conveniente. Agora, transferimos o WMS para a Web e, no final do ano, abandonaremos completamente os clientes gordos, o que simplificará bastante as alterações na interface do usuário. A web e o cluster adicionados em um dos estágios removem as restrições de frequência e hora dos lançamentos - agora os usuários aprenderão sobre lançamentos apenas se algo der errado.
Há também um interessante "exótico" em nosso armazém. Por exemplo, o Haskell mencionado no
Technoradar , no qual está escrito o back-end para visualizar um classificador de itens (esta é uma máquina que pode compor produtos de um pacote juntos e entregá-los ao operador de montagem). Há um problema puramente computacional, que é convenientemente resolvido em um estilo funcional. Naturalmente, ninguém vai usar o Haskell para projetos de larga escala.
Outro elemento do armazém que mencionamos no
artigo sobre o Technoradar é uma máquina de
estado auto-escrita que “monitora” a sequência correta de ações com cada produto. Como todo o sistema, ele se desenvolveu iterativamente, começando com um conjunto simples de restrições. Agora é uma coisa muito conveniente, profundamente integrada ao nosso sistema. Esperamos colocá-lo em
código aberto em um futuro próximo - talvez seja útil não apenas para nós.
Equipamento de automação
Que automação sem equipamento! Todo o armazém está preso em toda uma rede de transportadores.
O classificador de itens mencionado acima funciona no estágio de remessa, permitindo a disposição de dezenas de milhares de unidades de mercadorias coletadas do estoque para pedidos específicos. Ao mesmo tempo, o classificador salvou nossos operadores da necessidade de viajar com um carrinho pelo armazém para coletar as mercadorias necessárias. Os pedidos são divididos, cada operador coleta mercadorias apenas do seu andar (economizando tempo em movimento) e o classificador garante que mercadorias de diferentes andares recebam os pedidos certos automaticamente. A alteração do processo operacional em 4 vezes acelerou a montagem do pedido e reduziu significativamente o número de erros.
Todo o equipamento automatizado é fornecido pelo nosso parceiro. Para o gerenciamento de unidades específicas, eles têm seu próprio sistema, localizado no rack do servidor ao lado do nosso WMS. Entre os sistemas, a integração é configurada em um protocolo de alto nível - nós nos comunicamos via SOAP. De nossos processos operacionais no WMS, recorremos ao sistema deles quando, por exemplo, precisamos mover um contêiner com mercadorias do ponto A ao ponto B. Ou seja, do ponto de vista do nosso sistema, toda essa automação parece bastante simples, apesar de sua real complexidade interna.
Obviamente, essa aparente simplicidade não funcionou imediatamente. Nos primeiros estágios da automação, tivemos uma "moagem mútua" de tecnologias. Uma vez que o transportador literalmente queimou nossas mercadorias - a velocidade da correia transportadora era muito alta, "mastigava" as mercadorias e queimava, o que impedia a montagem de outros pedidos. Talvez a história mais difícil tenha acontecido no início da automação, quando lançamos a primeira fase. Ontem, o armazém era totalmente manual e, hoje, depois de mudar o interruptor, deveria se tornar automático. Mas nada funcionou: devido a um erro na integração do sistema, as mensagens uns dos outros foram interpretadas incorretamente, o que resultou em vários dias de inatividade do armazém e milhões de perdas para nós.
Agora, o parceiro está presente em nosso armazém, planeja providenciar equipamentos conosco quando se trata de uma nova rodada de automação, ajudando a testar novos blocos.
Equipe e scrumban
O desenvolvimento de todo esse sistema agora está envolvido em uma equipe de 12 pessoas. Em um dos últimos estágios do pico da modernização, quando processos automatizados separadamente foram combinados em algo inteiro, até 20 desenvolvedores participaram (esse estágio exigiu 132 homens-mês e incluiu mais de 1.500 confirmações). Mas, quando as transformações em larga escala terminam, algumas pessoas decidiram aprender Go ou Python e mudaram para outras equipes de desenvolvimento.
Na equipe, temos gerentes de projeto "clássicos" que combinam as funções de um produto e um projeto de TI (em média, uma PM para 5-6 pessoas). Suas tarefas incluem comunicação com nosso principal cliente - um armazém representado por seu diretor e pelo departamento de desenvolvimento de processos operacionais. De nossa parte, estamos mais preocupados com a modernização técnica - escolhendo a pilha certa, as atualizações etc. - E os funcionários do armazém estão pensando em otimizar os processos.
Às vezes, dedicamos tempo à pesquisa e desenvolvimento no campo. No sentido literal, chegamos ao armazém, nos comunicamos com turnos seniores, com operadores comuns e esclarecemos quais problemas eles têm, o que é conveniente e inconveniente para se trabalhar. Em outras palavras, realizamos pesquisas de experiência do usuário.
Graças a essa abordagem, por exemplo, transformamos a interface do local de trabalho de um funcionário que realiza a aceitação de mercadorias. Inicialmente, era uma interface complexa da empresa com muitos campos, botões e abreviações, em vez de explicações textuais. Mas tentamos otimizar o processo, bem como o design, tornando-o mais semelhante à página principal de pesquisa do Google - não tão bonita, mas muito funcional. Quanto mais simples a interface e menos opções o operador tiver, onde clicar e o que verificar, menos erros (e o tempo necessário para corrigi-los).
E o conhecimento acumulado sobre a otimização dos detalhes agora nos ultrapassa nos momentos mais inesperados: quando nossa equipe estava na instituição e em um momento quase todos os participantes observavam a sequência de ações do caixa. Após cerca de 40 segundos, um colega expressou a ideia geral: "Não é o ideal, você pode simplificá-la".
Embora a relação entre os papéis na equipe seja bastante clássica, escolhemos um scrumban para a metodologia de desenvolvimento.
Experimentamos muito com metodologias, enquanto os dados de "entrada" não eram padrão. Por exemplo, tivemos lançamentos bastante raros. A restrição acima mencionada de dois lançamentos por semana atuou por parte dos processos, mas na verdade implementamos com muito menos frequência - em média, uma vez a cada duas semanas. Além disso, tínhamos um hardware de automação de armazém, que está sendo desenvolvido por uma empresa externa para a cascata limpa, onde todas as alterações são agendadas com dois anos de antecedência com toda a documentação necessária. No entanto, nós mesmos não pudemos seguir o exemplo deles: precisávamos fazer algumas alterações no sistema regularmente e forçar o cliente a escrever uma tarefa detalhada para cada um deles era inútil.
Então scrumban é um compromisso que fez todos felizes. Usamos um processo iterativo, mas o sprint é a versão para nós. Uma vez por mês, nos reunimos com o cliente e planejamos o lançamento: discutimos o que e em que semana lançamos. Dentro do sprint, o kanban é implementado - com uma lista de tarefas, progresso, etc. É verdade que esse processo está mudando gradualmente - por exemplo, não temos um quadro kanban. Apenas quando um desenvolvedor termina sua tarefa, ele recebe o próximo da piscina, de acordo com os planos para o próximo lançamento e as competências do desenvolvedor.
Nós gostamos dessa abordagem. Ele fornece a flexibilidade necessária nas iterações e fornece ao cliente comercial a previsibilidade das datas pelas quais determinadas confirmações serão implementadas. E não é tão importante para nós como essa metodologia é chamada. O principal é que tudo funciona.
Não é como todo mundo - usando inventário e monitoramento como exemplo
Desenvolvendo processos operacionais, partimos das necessidades de nossa indústria, portanto, temos algumas características individuais.
Um bom exemplo é um inventário. De acordo com a lei, ela deve ser realizada no armazém uma vez por ano, mas nossos requisitos de negócios determinam um monitoramento mais detalhado do estoque. Em primeiro lugar, queremos refletir informações relevantes sobre a disponibilidade de produtos no site e, em segundo lugar, nossos parceiros B2B, as marcas de moda exigem as mesmas informações relevantes. Portanto, um inventário é realizado diariamente, 364 dias por ano, prateleira após prateleira em todo o complexo de cinco andares de vários edifícios. E esse processo é totalmente suportado pelo nosso WMS - seria difícil implementar essa solução.
Agora, o inventário está no processo da próxima atualização para aumentar a eficiência desse processo.
Outro exemplo de nosso próprio desenvolvimento é o monitoramento. É implementado através de um cliente da Web e permite exibir e acompanhar métricas muito interessantes. Além disso, uma representação visual dessas métricas é importante para nós. De fato, o monitoramento é um armazém representado em um cronograma simples, onde vemos claramente em que lugares tudo funciona bem e onde os problemas são observados (até um operador específico). Mais importante, com essa visão, podemos entender por que esses problemas surgem.
Trabalhadores de armazém de KPI e Redis
A introdução de novas tecnologias, atualizações, refatoração - tudo é ótimo. Mas nosso WMS funciona em negócios reais, então aqui temos que resolver não apenas esses problemas. Parte do nosso trabalho é a proteção contra "hackers" internos - funcionários de armazém engenhosos que inventam novas maneiras de executar KPI ignorando a tarefa.
Por exemplo, não muito tempo atrás, fomos forçados a adicionar Redis à pilha para impedir que os usuários efetuem login no sistema em várias estações de trabalho ao mesmo tempo e implementem um tempo limite de sessão. O fato é que os funcionários do armazém perceberam que trabalhar com o mesmo login e receber um bônus por exceder o KPI é muito mais lucrativo do que aumentar sua própria produtividade.
Como a solução do problema de negócios exigia alterações em vários locais do sistema, do ponto de vista técnico, era um desafio muito interessante.
As surpresas da equipe do armazém não terminaram por aí. Quase imediatamente após o lançamento da sessão, o PostgreSQL começou a falhar. Pesquisamos os motivos da degradação inesperada da base por vários dias, até descobrirmos que o problema, novamente, era engenhoso. Uma garota costumava fumar. Quando ela saiu do local de trabalho, ela foi eliminada da sessão e, para entrar novamente, era necessário encontrar o turno sênior e escanear seu crachá. Reduzindo suas andanças pelo armazém, ela simplesmente rasgou o código de barras de um dos carrinhos e fixou o botão do scanner com fita adesiva, configurando-o para escanear constantemente esse código de barras. E isso poderia passar despercebido por um longo tempo se o código de barras não fosse do carrinho, que continha 800 unidades de mercadorias. A cada varredura, uma enorme consulta SQL era gerada para validar as mercadorias, que "matavam" o banco de dados com esses "DDoS internos". Eu tive que cuidar das restrições no número de digitalizações por unidade de tempo e no número de mercadorias no carrinho.
Já existem muitas dessas histórias e somos constantemente confrontados com novas. Além disso, o sistema deve se adaptar a novas condições sempre. Em tais situações, não se pode limitar-se apenas a métodos administrativos - o que aconteceu uma vez pode muito bem ser repetido.
Para onde vamos a seguir?
Parece que a otimização do processo e a automação do armazém são impossíveis de serem concluídas. Ela dura 5 anos na empresa e, como eu disse acima, mesmo após o estágio 9, não vamos parar. A empresa continua a se expandir tanto no B2C quanto no B2B, então, no futuro próximo, estamos planejando outro grande projeto - a abertura de outro armazém, isso exigirá uma reescrita em larga escala do sistema existente ou a criação de um semelhante do zero em um novo local. E esse é um novo desafio interessante na junção de negócios, instalações físicas, processos operacionais e soluções técnicas.