Hackathon pada Ilmu Data dalam SIBUR: bagaimana itu

Hai

Sejak awal tahun, kami telah mengadakan sekitar 10 hackathon dan lokakarya di seluruh negeri. Pada bulan Mei, bersama dengan komunitas AI, kami mengorganisir hackathon ke arah “Digitalisasi produksi”. Kami belum melakukan hackathon tentang ilmu data dalam produksi, dan hari ini kami memutuskan untuk berbicara secara rinci tentang bagaimana itu.



Tujuannya sederhana. Penting untuk mendigitalkan bisnis kami di semua tahapannya (dari pasokan bahan baku hingga produksi dan penjualan langsung). Tentu saja, tugas-tugas yang bersifat terapan seharusnya diselesaikan, misalnya:

• penghapusan downtime peralatan, pelanggaran dan kegagalan teknologi;
• meningkatkan produktivitas dan, pada saat yang sama, kualitas produk;
• pengurangan biaya logistik dan pengadaan;
• peluncuran dan peluncuran produk baru yang dipercepat.

Apa nilai utama dari tugas-tugas tersebut? Itu benar, sedekat mungkin dengan kasus bisnis nyata, dan bukan dengan proyek abstrak. Tugas pertama sudah dijelaskan secara rinci tentang Habré oleh salah satu peserta (terima kasih, David terkointegrasi !). Dan tugas kedua yang diajukan ke hackathon adalah kebutuhan untuk mengoptimalkan proses menggabungkan perbaikan terjadwal mobil kereta api dari taman logistik. Ini diambil langsung dari simpanan kami saat ini, sedikit disesuaikan untuk para peserta, agar lebih dimengerti.

Jadi, uraian masalahnya.

Apa yang harus dilakukan

Spesialis logistik memiliki kalender khusus, yang berisi informasi tentang pengiriman mobil untuk pemeliharaan terjadwal. Karena ada lebih dari dua gerbong (lebih dari dua), Anda memerlukan solusi yang akan menyederhanakan pekerjaan karyawan, membuat pekerjaannya lebih mudah, lebih intuitif, dan juga akan membantunya membuat keputusan lebih cepat berdasarkan analisis data awal.

Karena itu, keputusan itu sendiri harus mencakup dua komponen:

1. Algoritma khusus berdasarkan analisis data.
2. Antarmuka yang ramah pengguna yang memungkinkan Anda untuk memvisualisasikan data yang diterima dan hasil algoritme dengan jelas dan jelas. Tentang apa yang harus diterapkan (web, aplikasi seluler, atau bahkan dengan bantuan bot) - atas kebijakan peserta.

Masukkan data

Kami memberikan data kepada peserta tentang pengiriman 18.000 mobil untuk diperbaiki dengan data tentang semua jarak, waktu, dll. (Informasi selama beberapa tahun). Plus, mereka memiliki kesempatan untuk mengobrol langsung dengan ouner proses bisnis dan mengklarifikasi dengan dia semua rincian yang diperlukan, serta mengumpulkan keinginan.

Tampaknya, yah, saya membuat kalender perbaikan mobil dan segalanya, apa lagi yang bisa dioptimalkan di sini? Dan yang paling penting - bagaimana dan dengan apa mengukur keefektifan solusi?


Kriteria untuk mengoptimalkan perbaikan terjadwal

Di sini perlu dimulai dengan fakta bahwa perbaikan mobil bukan hanya perbaikan mobil. Setiap mobil kami dapat memiliki 4 jenis perbaikan.

• Modal.
• Depot.
• Peringatan yang direncanakan.
• Vacuum cleaner dan hydrotesting.

Masing-masing dari keempat jenis perbaikan ini memiliki biaya perbaikan sendiri (bahan perbaikan + pembayaran untuk pekerjaan perbaikan), serta biaya persiapan untuk perbaikan. Selain itu, ada juga biaya pengiriman mobil ke depot. Dan karena mobil mengendarai dengan sengaja untuk perbaikan, itu menjadi kosong, yang berarti bahwa kami mengecualikan kemungkinan untung untuk perjalanan di sini.

Orang-orang mulai, tentu saja, dengan hipotesis.

Hipotesis

Hipotesis No. 1. Jika Anda menggabungkan beberapa perbaikan dalam satu hari, Anda dapat menghemat pekerjaan persiapan.

Hipotesis itu menemukan kalimat dalam bentuk, "Ya, kalau begitu mari kita lakukan semua yang lain di setiap perbaikan, agar tidak bangun dua kali, pada hari yang sama."

Kedengarannya keren. Di tempat-tempat itu bahkan logis. Tapi tidak sesederhana itu.

Perbaikan (salah satu dari empat) tidak hanya memiliki biaya, tetapi juga pembuangan. Secara umum, seperti dengan mobil. Anda lulus inspeksi pada bulan Januari, dan Anda menyeretnya selama mungkin hingga inspeksi berikutnya, sehingga setiap rubel yang dihabiskan untuk inspeksi pertama dihabiskan secara efisien. Jika Anda melakukan MOT terlalu sering tanpa mengembangkan sumber daya, Anda kehilangan uang.

Ya, contoh dengan mobil tidak persis sama dengan mobil kami; namun, situasinya berbeda, dan kadang-kadang ada baiknya melewati MOT terlebih dahulu (atau bahkan 2-3 kali setahun), katakanlah, sebelum perjalanan panjang yang penting. Tetapi dalam kasus sejumlah besar mobil, awal perbaikan yang salah dapat menyebabkan kerugian yang cukup serius.

Hipotesis No. 2. Kemudian Anda bisa menggabungkan perbaikan ini sehingga pembuangan masing-masing selengkap mungkin.

Sudah lebih baik. Muncul pertanyaan:

Dari stasiun mana lebih menguntungkan mengirim mobil untuk diperbaiki?
Jalur dari setiap stasiun ke depo yang kita tahu. Tetapi jalur antara stasiun itu sendiri tidak. Mungkin mobil akan menguasai untuk mengangkut lebih sedikit kargo dan pergi ke stasiun dari stasiun yang lebih jauh, tetapi menghasilkan uang dalam perjalanan?

Hipotesis No. 3. Kami memperhitungkan jarak antara stasiun dan keuntungan dari pengiriman produk - kami mengoptimalkan titik logistik pengiriman untuk diperbaiki.

Bahwa hipotesis itu bukan hanya pernyataan yang tidak berdasar, lebih baik diungkapkan dalam indikator keuangan.

Artinya, di sini, untuk menyelesaikan masalah, idealnya, perlu untuk membangun model yang dapat secara maksimal menghubungkan indikator-indikator ini satu sama lain. Pada saat yang sama, memungkinkan untuk mengubah parameter input (jumlah mobil yang dikirim untuk perbaikan, tanggal perbaikan, berada di stasiun, dll) dan menunjukkan penghematan biaya nyata.

Dan lagi, yang utama. Ini adalah program yang akan digunakan orang. Karena itu, Anda perlu membuat antarmuka untuk orang, dan bukan tumpukan cetakan dan pelat filter. Masing-masing karyawan yang akan bekerja dengan antarmuka ini harus dengan cepat memahami apa yang sedang terjadi, dari mana mobil ini berasal, dan mobil mana yang dianggap untuk digabungkan.
Sebagai titik awal, kami menunjukkan kepada peserta beberapa draft kami. Ini bukan panduan untuk bertindak, tetapi hanya sebuah contoh.





Sketsa Desain Draf

Para peserta menerima semua sketsa dan keinginan dan pergi untuk berpikir.

Beberapa hari berlalu dalam format klarifikasi konstan - tim datang kepada kami, menunjukkan draf kasar, mengklarifikasi sesuatu, mendapat jawaban, pergi untuk menyelesaikan keputusan lebih lanjut.

Bahkan, dari sisi penyelenggara terlihat sangat keren - orang-orang kreatif saat bepergian, menyesuaikan diri dengan catatan pengantar yang baru, menemukan beberapa kelemahan dalam solusi mereka sendiri dalam beberapa jam dan menghilangkannya di sana. Selain itu, dalam format kerja tim penuh - sementara orang menggambar desain dari semua ini, data-ilmuwan sudah selesai menulis skrip pertama.

Kami sekarang mencoba untuk membuat divisi digital kami bekerja pada tugas-tugas harian perusahaan dalam suasana yang sama, karena itu sangat menarik.

Tonton demo dan final

Semuanya sederhana dan akrab di sini. Setiap tim memiliki 5 menit untuk berbicara, dan panitia memiliki 5 menit untuk menjawab. Tentu saja, kerangka kerjanya tidak terlalu ketat, dan kadang-kadang kami melampaui waktu itu.

Untuk semuanya tentang segala sesuatu dalam ritme seperti itu, kami menghabiskan 3 jam.



Mereka mengevaluasi solusi secara komprehensif - pendekatan untuk memecahkan masalah secara umum, visualisasi, penerapan proposal dalam kenyataan. Di sini pendekatan AI-komunitas membantu, dimana hasil antara dari proses juga dicatat.

Pemenang

Hadiah utama (300.000 rubel) diberikan kepada tim Hack.zamAI.

Orang-orang menciptakan solusi yang komprehensif, tidak hanya mengoptimalkan kinerja keuangan, tetapi juga menulis banyak roti tambahan di sana, menampilkan proses bisnis yang sudah jadi dalam produk.

Pada saat yang sama, masih terlihat sopan dan ramah.







Di sini Anda dapat melihat demonstrasi solusi mereka.



(video di GoogleDrive)

Tentu saja, ini bukan hackathon terakhir kami.

Kami ingin mengucapkan terima kasih kepada semua orang yang berpartisipasi dalam ini. Dan pastikan untuk memposting pengumuman selanjutnya.

Dmitry Arkhipov, arsitek, Digitalisasi Proses, SIBUR