Hackathon sur la science des données à SIBUR: comment c'était

Salut

Depuis le début de l'année, nous avons organisé une dizaine de hackathons et ateliers à travers le pays. En mai, avec la communauté de l' IA, nous avons organisé un hackathon en direction de la «Numérisation de la production». Nous n'avons pas encore fait de hackathon sur la science des données dans la production, et aujourd'hui nous avons décidé de parler en détail de comment c'était.



Le but était simple. Il fallait numériser notre activité à toutes ses étapes (de l'approvisionnement en matières premières à la production et à la vente directe). Bien sûr, des tâches de nature appliquée auraient dû être résolues, par exemple:

• l'élimination des temps d'arrêt des équipements, des violations technologiques et des pannes;
• augmenter la productivité et, en même temps, la qualité des produits;
• réduction des coûts de logistique et d'approvisionnement;
• lancement accéléré et lancement de nouveaux produits.

Quelle est la valeur principale de ces tâches? C'est vrai, le plus près possible des cas réels, et non des projets abstraits. La première tâche est déjà décrite en détail sur Habré par l'un des participants (merci, David co - intégré !). Et la deuxième tâche du hackathon était la nécessité d'optimiser le processus de combinaison des réparations programmées des wagons du parc logistique. Ceci a été tiré directement de notre carnet de commandes actuel, légèrement adapté aux participants, afin de le rendre plus compréhensible.

Donc, la description du problème.

Que fallait-il faire

Les spécialistes de la logistique ont un calendrier spécial, qui contient des informations sur l'expédition des voitures pour l'entretien programmé. Puisqu'il y a plus de deux wagons (beaucoup plus que deux), vous avez besoin d'une solution qui simplifiera le travail de l'employé, rendra son travail plus facile, plus intuitif et l'aidera également à prendre des décisions plus rapidement sur la base d'une analyse préliminaire des données.

Par conséquent, la décision elle-même doit comprendre deux éléments:

1. Algorithme spécial basé sur l'analyse des données.
2. Interface conviviale qui vous permet de visualiser clairement et clairement les données reçues et les résultats de l'algorithme. Sur quoi exactement mettre en œuvre (web, application mobile, ou même avec l'aide d'un bot) - à la discrétion des participants.

Entrer les données

Nous avons fourni aux participants un ensemble de données sur l'envoi de 18 000 voitures pour réparation avec des données sur toutes les distances, le calendrier, etc. (informations sur plusieurs années). De plus, ils ont eu la possibilité de discuter en direct avec le responsable des processus métier et de clarifier avec lui tous les détails nécessaires, ainsi que de recueillir les souhaits.

Il semblerait que, bien, j'ai inventé un calendrier de réparation automobile et tout, quoi d'autre peut être optimisé ici? Et surtout - comment et comment mesurer l'efficacité de la solution?


Critères d'optimisation des réparations planifiées

Ici, il convient de commencer par le fait que la réparation automobile n'est pas seulement une réparation automobile. Chacune de nos voitures peut avoir 4 types de réparations.

• Capital.
• Dépôt.
• Avertissement prévu.
• Aspirateur et hydrotest.

Chacun de ces quatre types de réparation a lui-même son propre coût de réparation (matériel de réparation + paiement des travaux de réparation), ainsi que le coût de préparation de la réparation. De plus, il y a aussi le coût de livraison de la voiture au dépôt. Et puisque la voiture roule délibérément pour les réparations, elle devient vide, ce qui signifie que nous excluons ici tout profit possible pour le voyage.

Les gars ont commencé, bien sûr, avec des hypothèses.

Hypothèses

Hypothèse n ° 1. Si vous combinez plusieurs réparations en une journée, vous pouvez économiser sur les travaux préparatoires.

L'hypothèse rencontrait une phrase du type "Oui, alors faisons tout le reste à chaque réparation, pour ne pas se lever deux fois, le même jour".

Ça a l'air cool. Par endroits, c'est même logique. Mais pas si simple.

La réparation (l'un des quatre) a non seulement un coût, mais aussi l'élimination. En général, comme avec une voiture. Vous avez réussi l'inspection en janvier et vous la faites glisser le plus longtemps possible jusqu'à la prochaine inspection, de sorte que chaque rouble dépensé pour la première inspection soit dépensé efficacement. Si vous faites du MOT trop souvent sans développer une ressource, vous perdez de l'argent.

Oui, l'exemple avec une voiture ne coïncide pas tout à fait avec le nôtre; néanmoins, les situations sont différentes, et parfois cela vaut la peine de passer par MOT à l'avance (ou même 2-3 fois par an), disons, avant un long voyage important. Mais dans le cas d'un grand nombre de voitures, un tel faux démarrage des réparations peut entraîner des pertes assez importantes.

Hypothèse n ° 2. Ensuite, vous pouvez simplement combiner ces réparations afin que l'élimination de chacune d'entre elles soit aussi complète que possible.

Déjà mieux. Des questions se posent:

De quelle gare est-il plus rentable d'envoyer une voiture en réparation?
Le chemin de chaque station au dépôt que nous connaissons. Mais le chemin entre les stations elles-mêmes ne l'est pas. Peut-être que la voiture maîtrisera pour transporter un peu plus de fret et aller au dépôt depuis une gare plus éloignée, mais gagner de l'argent en voyage?

Hypothèse n ° 3. Nous prenons en compte la distance entre les stations et le profit de la livraison des produits - nous optimisons les points logistiques d'expédition pour la réparation.

Que l'hypothèse n'était pas seulement un énoncé non fondé, il vaut mieux l'exprimer en indicateurs financiers.

Autrement dit, afin de résoudre le problème, idéalement, il est nécessaire de construire un modèle qui puisse relier au maximum ces indicateurs entre eux. Dans le même temps, il a permis de modifier les paramètres d'entrée (nombre de wagons envoyés en réparation, dates de réparation, être en gare, etc.) et de réaliser de réelles économies de coûts.

Et encore une fois, l'essentiel. Il s'agit d'un programme avec lequel les gens travailleront. Par conséquent, vous devez créer une interface pour les personnes, et non pas un tas de moules et de plaques filtrantes. Chacun des employés qui travaillera avec cette interface devrait rapidement comprendre ce qui se passe, d'où vient cette voiture et pour laquelle ces voitures ont pensé à se combiner.
Comme point de départ, nous avons montré aux participants quelques-uns de nos projets. Ce n'était pas un guide pour l'action, mais juste un exemple.





Esquisses de conception

Les participants ont accepté tous les croquis et souhaits et sont partis réfléchir.

Quelques jours se sont écoulés sous la forme d'éclaircissements constants - les équipes sont venues vers nous, ont montré des ébauches, clarifié quelque chose, obtenu des réponses, laissées pour terminer la décision.

En fait, du côté de l'organisateur, cela a l'air très cool - les gens sont créatifs en déplacement, s'adaptant aux nouvelles notes introductives raffinées, trouvant quelques inconvénients dans leur propre solution en quelques heures et les éliminant immédiatement. De plus, sous la forme d'un travail d'équipe à part entière - alors que l'on dessine la conception de tout cela, les data-scientists ont déjà fini d'écrire les premiers scripts.

Nous essayons maintenant de faire fonctionner notre division numérique sur les tâches quotidiennes de l'entreprise dans la même ambiance, car c'est très excitant.

Regardez la démo et la finale

Tout était simple et familier ici. Chaque équipe a 5 minutes pour parler et les organisateurs ont 5 minutes pour répondre. Bien sûr, le cadre n'était pas vraiment serré, et parfois nous dépassions ce délai.

Pour tout sur tout dans un tel rythme, nous avons passé 3 heures.



Ils ont évalué les solutions de manière exhaustive - approches pour résoudre le problème en général, visualisation, applicabilité des propositions dans la réalité. Ici, l'approche AI-communauté a aidé, grâce à laquelle les résultats intermédiaires du processus ont également été enregistrés.

Les gagnants

Le prix principal (300 000 roubles) est allé à l'équipe Hack.zamAI.

Les gars ont créé une solution complète, non seulement pour optimiser les performances financières, mais aussi pour y écrire un tas de petits pains supplémentaires, affichant un processus commercial prêt à l'emploi dans le produit.

En même temps, il a toujours l'air décent et sympathique.







Ici vous pouvez voir une démonstration de leur solution.



(vidéo sur GoogleDrive)

Bien sûr, ce n'est pas notre dernier hackathon.

Nous tenons à remercier tous ceux qui y ont participé. Et n'oubliez pas de publier l'annonce de la prochaine.

Dmitry Arkhipov, architecte, Numérisation des processus, SIBUR