Hackathon sobre Data Science en SIBUR: cómo fue

Hola

Desde principios de año, hemos realizado alrededor de 10 hackatones y talleres en todo el país. En mayo, junto con la comunidad de IA, organizamos un hackathon en la dirección de "Digitalización de la producción". Todavía no hemos hecho un hackathon sobre ciencia de datos en producción, y hoy decidimos hablar en detalle sobre cómo fue.



El objetivo era simple. Era necesario digitalizar nuestro negocio en todas sus etapas (desde el suministro de materias primas hasta la producción y ventas directas). Por supuesto, las tareas de naturaleza aplicada deberían haberse resuelto, por ejemplo:

• eliminación del tiempo de inactividad del equipo, violaciones tecnológicas y fallas;
• aumentar la productividad y, al mismo tiempo, la calidad del producto;
• reducción en logística y costos de adquisición;
• Lanzamiento acelerado y lanzamiento de nuevos productos.

¿Cuál es el valor principal de tales tareas? Así es, lo más cerca posible de casos comerciales reales y no de proyectos abstractos. La primera tarea ya está descrita en detalle en Habré por uno de los participantes (¡gracias, David cointegrado !). Y la segunda tarea del hackathon fue la necesidad de optimizar el proceso de combinar las reparaciones programadas de vagones de ferrocarril del parque logístico. Esto fue tomado directamente de nuestra cartera de pedidos actual, ligeramente adaptada para los participantes, para que sea más comprensible.

Entonces, la descripción del problema.

Lo que tenia que hacer

Los especialistas en logística tienen un calendario especial, que contiene información sobre el envío de automóviles para el mantenimiento programado. Dado que hay más de dos vagones (mucho más de dos), necesita una solución que simplifique el trabajo del empleado, haciendo que su trabajo sea más fácil, más intuitivo y también lo ayudará a tomar decisiones más rápido en función del análisis preliminar de datos.

Por lo tanto, la decisión en sí misma debe incluir dos componentes:

1. Algoritmo especial basado en análisis de datos.
2. Interfaz fácil de usar que le permite visualizar clara y claramente los datos recibidos y los resultados del algoritmo. Sobre qué implementar exactamente (web, aplicación móvil o incluso con la ayuda de un bot), a discreción de los participantes.

Datos de entrada

Proporcionamos a los participantes un conjunto de datos sobre el envío de 18,000 automóviles para reparación con datos de todas las distancias, tiempos, etc. (información de varios años). Además, tuvieron la oportunidad de conversar en vivo con el proceso de negocios y aclarar con él todos los detalles necesarios, así como también reunir deseos.

Parece que, bueno, hice un calendario de reparación de automóviles y todo lo demás se puede optimizar aquí. Y lo más importante: ¿cómo y con qué medir la efectividad de la solución?


Criterios para optimizar reparaciones programadas

Aquí vale la pena comenzar con el hecho de que la reparación de automóviles no es solo reparación de automóviles. Cada uno de nuestros autos puede tener 4 tipos de reparaciones.

• Capital
• Depósito
• Advertencia planificada
• Aspiradoras e hidrotestas.

Cada uno de estos cuatro tipos de reparación tiene su propio costo de reparación (materiales de reparación + pago por el trabajo de reparación), así como el costo de preparación para la reparación. Además, también existe el costo de la entrega del automóvil al depósito. Y dado que el automóvil viaja a propósito para reparaciones, se vacía, lo que significa que excluimos posibles ganancias para el viaje aquí.

Los muchachos comenzaron, por supuesto, con hipótesis.

Hipótesis

Hipótesis No. 1. Si combina varias reparaciones en un día, puede ahorrar en el trabajo preparatorio.

La hipótesis encontró una oración de la forma "Sí, entonces hagamos todo lo demás en cada reparación, para no levantarnos dos veces, el mismo día".

Eso suena bien En algunos lugares es incluso lógico. Pero no tan simple.

La reparación (cualquiera de los cuatro) no solo ha costado, sino también la eliminación. En general, como con un automóvil. Pasó la inspección en enero y la arrastró el mayor tiempo posible hasta la próxima inspección, de modo que cada rublo gastado en la primera inspección se gasta de manera eficiente. Si haces MOT con demasiada frecuencia sin desarrollar un recurso, pierdes dinero.

Sí, el ejemplo con un automóvil no coincide exactamente con el nuestro; sin embargo, las situaciones son diferentes y, a veces, vale la pena pasar por MOT con anticipación (o incluso 2-3 veces al año), por ejemplo, antes de un viaje largo importante. Pero en el caso de una gran cantidad de automóviles, un inicio tan falso de reparaciones puede causar pérdidas bastante graves.

Hipótesis No. 2. Luego, simplemente puede combinar estas reparaciones para que la eliminación de cada una de ellas sea lo más completa posible.

Ya mejor. Surgen preguntas:

¿Desde qué estación es más rentable enviar un automóvil para su reparación?
El camino desde cada estación hasta el depósito que conocemos. Pero el camino entre las estaciones en sí no lo es. Tal vez el auto dominará para transportar un poco más de carga e ir al depósito desde una estación más lejana, pero ¿ganar dinero en un viaje?

Hipótesis No. 3. Tenemos en cuenta la distancia entre las estaciones y el beneficio de la entrega del producto: optimizamos los puntos logísticos de envío para la reparación.

Que la hipótesis no era solo una declaración infundada, es mejor expresarla en indicadores financieros.

Es decir, aquí, para resolver el problema, idealmente, es necesario construir un modelo que pueda vincular al máximo estos indicadores entre ellos. Al mismo tiempo, hizo posible cambiar los parámetros de entrada (la cantidad de vagones enviados para reparaciones, fechas de reparación, estar en estaciones, etc.) y mostrar un ahorro real de costos.

Y de nuevo, lo principal. Este es un programa con el que las personas trabajarán. Por lo tanto, debe crear una interfaz para las personas, y no un montón de moldes y placas de filtro. Cada uno de los empleados que trabajará con esta interfaz debe comprender rápidamente lo que está sucediendo, de dónde viene este automóvil y para qué estos automóviles pensaron combinarlos.
Como punto de partida, mostramos a los participantes algunos de nuestros borradores. Esto no fue una guía de acción, sino solo un ejemplo.





Bocetos de diseño borrador

Los participantes aceptaron todos los bocetos y deseos y se fueron a pensar.

Pasaron un par de días en forma de aclaraciones constantes: los equipos se acercaron a nosotros, nos mostraron borradores, aclararon algo, obtuvieron respuestas y se fueron para terminar la decisión.

De hecho, desde el punto de vista del organizador, se ve muy bien: las personas son creativas sobre la marcha, se ajustan a las nuevas notas introductorias actualizadas, encuentran algunas desventajas en su propia solución en un par de horas y las eliminan allí mismo. Además, en el formato de trabajo en equipo completo, mientras uno dibuja el diseño de todo esto, los científicos de datos ya están terminando de escribir los primeros guiones.

Ahora estamos tratando de hacer que nuestra división digital trabaje en las tareas diarias de la empresa en la misma atmósfera, porque es muy emocionante.

Ver demo y final

Aquí todo era simple y familiar. Cada equipo tiene 5 minutos para hablar, y los organizadores tienen 5 minutos para responder. Por supuesto, el marco no era realmente ajustado, y a veces fuimos más allá de ese tiempo.

Para todo sobre todo en ese ritmo, pasamos 3 horas.



Evaluaron las soluciones de manera integral: enfoques para resolver el problema en general, visualización, aplicabilidad de propuestas en la realidad. Aquí ayudó el enfoque de AI-comunidad, mediante el cual también se registraron los resultados intermedios del proceso.

Ganadores

El premio principal (300,000 rublos) fue para el equipo Hack.zamAI.

Los chicos crearon una solución integral, no solo optimizando el rendimiento financiero, sino también escribiendo un montón de bollos adicionales allí, mostrando un proceso comercial listo para usar en el producto.

Al mismo tiempo, todavía se ve decente y amigable.







Aquí puede ver una demostración de su solución.



(video en GoogleDrive)

Por supuesto, este no es nuestro último hackathon.

Queremos agradecer a todos los que participaron en esto. Y asegúrese de publicar el anuncio de la próxima.

Dmitry Arkhipov, arquitecto, Digitalización de Procesos, SIBUR