Hackathon sobre Ciência de Dados no SIBUR: como foi

Oi

Desde o início do ano, realizamos cerca de 10 hackathons e oficinas em todo o país. Em maio, em conjunto com a comunidade de IA, organizamos um hackathon na direção da "Digitalização da produção". Ainda não fizemos um hackathon sobre ciência de dados na produção e hoje decidimos falar em detalhes sobre como era.



O objetivo era simples. Era necessário digitalizar nossos negócios em todas as suas etapas (do fornecimento de matérias-primas à produção e vendas diretas). Obviamente, tarefas de natureza aplicada deveriam ter sido resolvidas, por exemplo:

• eliminação do tempo de inatividade do equipamento, violações e falhas tecnológicas;
• aumentar a produtividade e, ao mesmo tempo, a qualidade do produto;
• redução de custos de logística e compras;
• lançamento acelerado e lançamento de novos produtos.

Qual é o principal valor dessas tarefas? É isso mesmo, o mais próximo possível de casos de negócios reais, e não de abstrair projetos. A primeira tarefa já está descrita em detalhes em Habré por um dos participantes (obrigado, cointegrou David!). E a segunda tarefa colocada no hackathon foi a necessidade de otimizar o processo de combinar reparos programados de vagões ferroviários do parque logístico. Isso foi retirado diretamente do nosso backlog atual, ligeiramente adaptado para os participantes, a fim de torná-lo mais compreensível.

Então, a descrição do problema.

O que tinha que ser feito

Os especialistas em logística possuem um calendário especial, que contém informações sobre o envio de carros para manutenção programada. Como existem mais de dois vagões (muito mais que dois), você precisa de uma solução que simplifique o trabalho do funcionário, facilite o trabalho, seja mais intuitivo e também o ajude a tomar decisões mais rapidamente com base na análise preliminar de dados.

Portanto, a própria decisão deve incluir dois componentes:

1. Algoritmo especial baseado em análise de dados.
2. Interface amigável que permite visualizar de forma clara e clara os dados recebidos e os resultados do algoritmo. Sobre o que exatamente implementar (web, aplicativo móvel ou mesmo com a ajuda de um bot) - a critério dos participantes.

Dados de entrada

Fornecemos aos participantes um conjunto de dados sobre o envio de 18.000 carros para reparo com dados de todas as distâncias, horários, etc. (informações por vários anos). Além disso, eles tiveram a oportunidade de conversar ao vivo com o processo de negócios ou esclarecer com ele todos os detalhes necessários, além de coletar desejos.

Parece que, bem, eu criei um calendário de reparos de carros e tudo mais, o que mais pode ser otimizado aqui? E o mais importante - como e com o que medir a eficácia da solução?


Critérios para otimizar reparos agendados

Aqui vale a pena começar com o fato de que o reparo do carro não é apenas o reparo do carro. Cada um dos nossos carros pode ter 4 tipos de reparos.

• Capital.
• Depot.
• Aviso planejado.
• Aspiração e hidroteste.

Cada um desses quatro tipos de reparo tem seu próprio custo de reparo (materiais de reparo + pagamento pelo trabalho de reparo), bem como o custo de preparação para o reparo. Além disso, também há o custo da entrega do carro ao depósito. E, como o carro é montado propositadamente para reparos, fica vazio, o que significa que excluímos o possível lucro da viagem aqui.

Os caras começaram, é claro, com hipóteses.

Hipóteses

Hipótese nº 1. Se você combinar vários reparos em um dia, poderá economizar no trabalho preparatório.

A hipótese encontrou uma frase da forma "Sim, então vamos fazer todo o resto a cada reparo, para não levantar duas vezes, no mesmo dia".

Isso parece legal. Em alguns lugares, é até lógico. Mas não é tão simples.

O reparo (qualquer um dos quatro) não tem apenas custo, mas também descarte. Em geral, como em um carro. Você passou na inspeção em janeiro e a arrastou o maior tempo possível até a próxima inspeção, para que cada rublo gasto na primeira inspeção seja gasto com eficiência. Se você faz o MOT com muita frequência sem desenvolver um recurso, perde dinheiro.

Sim, o exemplo de um carro não coincide exatamente com o nosso; no entanto, as situações são diferentes e, às vezes, vale a pena passar pelo MOT com antecedência (ou até 2-3 vezes por ano), digamos, antes de uma importante viagem longa. Mas, no caso de um grande número de carros, um início tão falso de reparos pode causar perdas bastante sérias.

Hipótese nº 2. Em seguida, você pode simplesmente combinar esses reparos para que o descarte de cada um deles seja o mais completo possível.

Já está melhor. Surgem perguntas:

De que estação é mais rentável enviar um carro para reparo?
O caminho de cada estação para o depósito que conhecemos. Mas o caminho entre as próprias estações não é. Talvez o carro domine o transporte de um pouco mais de carga e vá ao depósito de uma estação mais distante, mas ganhando dinheiro em uma viagem?

Hipótese nº 3. Levamos em consideração a distância entre as estações e o lucro com a entrega do produto - otimizamos os pontos logísticos de expedição para reparo.

Que a hipótese não era apenas uma afirmação infundada, é melhor expressá-la em indicadores financeiros.

Ou seja, aqui, para resolver o problema, idealmente, é necessário construir um modelo que possa vincular ao máximo esses indicadores entre si. Ao mesmo tempo, foi possível alterar os parâmetros de entrada (o número de carros enviados para reparo, datas de reparo, estar nas estações etc.) e mostrar uma economia real de custos.

E, novamente, a principal coisa. Este é um programa com o qual as pessoas trabalharão. Portanto, você precisa criar uma interface para as pessoas, e não um monte de moldes e placas de filtro. Cada um dos funcionários que trabalhará com essa interface deve entender rapidamente o que está acontecendo, de onde vem esse carro e para quais carros foi pensado para combinar.
Como ponto de partida, mostramos aos participantes alguns de nossos rascunhos. Este não era um guia de ação, mas apenas um exemplo.





Esboços de design de rascunho

Os participantes aceitaram todos os esboços e desejos e deixaram para pensar.

Alguns dias se passaram no formato de esclarecimentos constantes - as equipes vieram até nós, mostraram rascunhos, esclareceram alguma coisa, obtiveram respostas e deixaram para concluir a decisão.

De fato, do lado do organizador, parece muito legal - as pessoas são criativas em movimento, ajustando-se às novas notas introdutórias refinadas, encontrando algumas desvantagens em sua própria solução em algumas horas e eliminando-as ali mesmo. Além disso, no formato de trabalho em equipe completo - enquanto se desenha o design de todas essas coisas, os cientistas de dados já estão terminando de escrever os primeiros scripts.

Agora estamos tentando fazer nossa divisão digital funcionar nas tarefas diárias da empresa na mesma atmosfera, porque é muito emocionante.

Assista à demonstração e final

Tudo era simples e familiar aqui. Cada equipe tem 5 minutos para falar e os organizadores têm 5 minutos para responder. Obviamente, a estrutura não era muito rígida e, às vezes, fomos além desse tempo.

Para tudo sobre esse ritmo, passamos 3 horas.



Eles avaliaram as soluções de maneira abrangente - abordagens para resolver o problema em geral, visualização, aplicabilidade das propostas na realidade. Aqui, a abordagem da comunidade de IA ajudou, pela qual os resultados intermediários do processo também foram registrados.

Vencedores

O prêmio principal (300.000 rublos) foi para a equipe Hack.zamAI.

Os caras criaram uma solução abrangente, não apenas otimizando o desempenho financeiro, mas também escrevendo um monte de pães adicionais por lá, exibindo um processo de negócios pronto no produto.

Ao mesmo tempo, ainda parece decente e amigável.







Aqui você pode ver uma demonstração de sua solução.



(vídeo no GoogleDrive)

Claro, este não é o nosso último hackathon.

Queremos agradecer a todos que participaram disso. E não deixe de publicar o anúncio do próximo.

Dmitry Arkhipov, arquiteto, Digitalização de processos, SIBUR