Gudang kami, ukuran dua Kotak Merah dan ketinggian 5 lantai, buka sepanjang tahun dan tidak pernah tidur - 24/7 364 hari setahun (satu-satunya hari libur adalah 1 Januari). Kami telah menyimpan dan melayani lebih dari 8.000.000 barang, setiap hari lebih dari 300 operator berubah. Mereka bekerja dengan barang-barang yang datang dari seluruh dunia dan mengumpulkan pesanan untuk pengguna dari empat negara: Rusia, Ukraina, Belarus dan Kazakhstan. Pada skala seperti itu, bisnis membutuhkan otomatisasi yang sempurna.
Di bawah potongan, saya, Pasha Finkelstein - pemimpin tim pengembangan dan otomasi gudang - akan memberi tahu Anda apa solusi sumber terbuka yang dapat tumbuh jika Anda memasang tim pengembangan yang baik dan tugas bisnis yang sangat spesifik untuk itu.
Logika dasar
Tiga proses utama dari setiap gudang: penerimaan barang, penyimpanan dan pengirimannya. Siklus yang disederhanakan dari gudang kami terlihat seperti ini: identifikasi utama, kontrol kualitas, penempatan, pemilihan dan pemesanan untuk pemesanan, pencarian, penyortiran, pengemasan, transfer ke layanan pengiriman. Ketika pelanggan mengembalikan produk, siklus berulang. Setiap entitas fisik yang berpartisipasi dalam proses ini memiliki perwakilan informasi sendiri, misalnya: truk, produk, sel kabinet, parsel, bahan kemasan, wadah, dll. Semua pergerakan signifikan dan perubahan status barang diterjemahkan ke dalam sistem akuntansi dan benar-benar setiap tindakan dengan barang di dalam gudang dicatat.
WMS (Warehouse Management System) mengendalikan siklus hidup setiap produk di gudang, sejak saat truk dengan barang-barang dari pemasok tiba di gudang hingga barang-barang dikirim ke pelanggan.
Spesifikasi otomatisasi mode
Perusahaan kami bekerja di bidang mode dan gaya hidup, yang memiliki tugas-tugas tertentu di gudang: produk dapat rapuh (kacamata, jam tangan), ukuran non-standar (sepatu bot musim dingin atau perhiasan), premium (dalam kemasan khusus) - atau memiliki karakteristik spesifik lain yang gudang harus memperhitungkan. Oleh karena itu, tidak mungkin untuk sepenuhnya mengabaikan penggunaan tenaga kerja manual di area penyimpanan.
Semua proses lainnya dilakukan secara otomatis - penerimaan barang, transfer ke area pengiriman, penyortiran, pengemasan dan persiapan pengiriman. Setiap proses ini membutuhkan peralatan khusus dan proses operasional. Keajaiban terjadi ketika semua proses ini "bersatu" dan mulai bekerja bersama - berkat sistem kami.
Segala pengawasan dalam otomatisasi gudang - baik itu antarmuka yang berkontribusi terhadap kesalahan operator, proses yang tidak optimal, dll. - Ini adalah keterlambatan pengiriman, waktu henti seluruh kompleks, kerugian besar. Selain itu, dengan setiap kesalahan, kami menciptakan pengalaman pelanggan yang negatif. Karena itu, penting bagi kami bahwa gudang berfungsi seperti jam.
Sumber terbuka dan jalur menuju pengembangan sendiri
Pada tahap pembukaan, kami menggunakan gudang eksternal. Dengan pertumbuhan volume, kami mulai memahami bahwa kami membutuhkan kontrol penuh atas proses operasional dan tingkat perubahan proses yang tinggi, sehingga kami memutuskan untuk bergerak ke gudang dan pengembangan kami sendiri.
Pertanyaan utama yang kami hadapi adalah uraian proses operasional dalam semua detail. Ke mana dan bagaimana karyawan pergi, berapa banyak pemindaian yang mereka lakukan, dll. Dan sudah pada proses ini, perlu untuk menyebarkan WMS, yang mengelola kegiatan operasional dan mengotomatisasi operasi rutin.
Untuk memulai, mereka mengambil solusi open source di Jawa dan kemudian memutuskan untuk membentuk tim pengembangan mereka sendiri, terutama karena sudah ada yayasan yang cocok. Kami meningkatkan fungsionalitas, kemudian mengambil inti dari sistem: menyingkirkan warisan dan klien yang gemuk, melakukan refactoring, mengembangkan layanan baru untuk mendukung proses operasi.
Tahap otomatisasi
Perubahan utama dilakukan oleh "gelombang", bersama dengan restrukturisasi proses itu sendiri.
Sampai saat ini, ia telah melalui sembilan tahap modernisasi, dan kami tidak berencana untuk memikirkan ini.
- Pada tahap pertama dan kedua, kami mengotomatiskan proses pengiriman pesanan - kami menambahkan konveyor, logika untuk menyortir barang, penyortiran otomatis pesanan dengan palet.
- Pada tahap ketiga dan keempat, kami fokus pada proses penerimaan: kami belajar bagaimana memisahkan arus barang yang masuk dengan berbagai jenis dan zona penyimpanan.
- Fase kelima menambahkan elevator otomatis di antara lantai - ini adalah bagaimana pekerjaan dimulai di area penyimpanan.
- Fase keenam adalah yang paling penting ketika kami menutup zona penerimaan dan pengiriman, melewati semua otomatisasi.
- Dalam fase ketujuh dan kedelapan, kami membuat perubahan pada proses di zona penerimaan dan menambahkan zona, elevator, dan konveyor baru: kami meningkatkan otomatisasi yang ada.
- Pada fase kesembilan, mereka menambahkan bangunan baru ke gudang dan mengintegrasikannya dengan sistem otomasi yang ada.
Implementasi
Teknologi inti kami: Java, Postgres, Wildfly, Redis, ActiveMQ.
WMS ditulis dalam Java 8. Tetapi belum lama ini, kami memperbaiki modul terakhir, yang mencegah transisi ke Java 11, akan diperbarui dalam waktu dekat.
Rak server yang dipasang langsung di gudang dicadangkan untuk WMS. Ini memberi kami lebih percaya diri bahwa WMS akan berfungsi bahkan jika listrik dan / atau Internet dimatikan. Satu-satunya hal yang akan menderita adalah bahwa pesan ke sistem akuntansi akan datang dengan penundaan. WildFly digunakan sebagai server aplikasi, meskipun belum versi terbaru. Migrasi ke yang terakhir juga dalam rencana. Semuanya sudah ditulis untuk dipindah, tetapi belum berhasil melakukan pengujian fungsional dan beban, dan sebelum tahun baru, bebannya relatif tinggi. ActiveMQ yang terbukti juga digunakan.
Data yang kami simpan di PostgreSQL. Esensi utama dalam sistem kami jelas merupakan produk. Kadang-kadang karyawan gudang menemukan solusi untuk menyederhanakan pekerjaan mereka, misalnya, mereka memindai barcode yang sama 50 kali, dan produk itu sendiri dilemparkan secara manual tanpa memindai, tanpa merinci, ini jins atau kaus, jadi kami memasukkan label yang mengidentifikasi unit tertentu barang, mendukungnya di infrastruktur. Informasi tentang unit-unit ini disimpan dalam database PostgreSQL 2-terabyte.
Sebagian besar tempat di sana diduduki bahkan bukan oleh barang-barang, tetapi oleh audit atas tindakan para pekerja gudang. Sebagai sistem yang kritis terhadap bisnis, gudang harus tahu mengapa sesuatu muncul di sistem atau menghilang - kami tidak dapat mengizinkan perubahan yang tidak terlacak. Saat ini kami sedang berpikir tentang mengambil bagian dari basis data ini ke entitas yang terpisah di MongoDB.
Workstation staf gudang adalah klien web tipis. Di suatu tempat di awal otomatisasi, semua ini bekerja sesuai dengan prinsip klien yang tebal, yang menciptakan kesulitan tertentu, khususnya, dengan rilis besar, yang termasuk perubahan dalam antarmuka: sekitar 150 workstation harus diperbarui secara manual. Ini dan fakta bahwa kami tidak dapat merilis tanpa downtime menetapkan batas bagi kami - kami dapat menggunakan tidak lebih dari dua kali seminggu, di pagi hari, ketika shift malam berakhir, yang tidak bisa disebut jadwal yang nyaman. Sekarang kami telah mentransfer WMS ke web dan pada akhir tahun ini kami akan sepenuhnya meninggalkan klien yang gemuk, yang akan sangat menyederhanakan perubahan antarmuka pengguna kami. Web dan pengelompokan ditambahkan pada salah satu tahap menghapus batasan pada frekuensi dan waktu rilis - sekarang pengguna akan belajar tentang rilis hanya jika ada kesalahan.
Ada juga "eksotis" yang menarik di gudang kami. Misalnya, Haskell disebutkan dalam
Technoradar , di mana backend untuk memvisualisasikan item sorter ditulis (ini adalah mesin yang dapat menyusun barang dari satu paket bersama-sama dan memberikannya kepada operator perakitan). Ada masalah komputasi murni, yang mudah diselesaikan dalam gaya fungsional. Tentu, tidak ada yang akan menggunakan Haskell untuk proyek skala besar.
Elemen lain dari gudang yang kami sebutkan dalam
artikel tentang Technoradar adalah mesin
negara yang ditulis sendiri yang "memantau" urutan tindakan yang benar dengan setiap produk. Seperti halnya keseluruhan sistem, dikembangkan secara iteratif, dimulai dengan serangkaian kendala sederhana. Sekarang ini adalah hal yang sangat nyaman, terintegrasi ke dalam sistem kami. Kami berharap dapat menempatkannya dalam
open source dalam waktu dekat - mungkin akan bermanfaat tidak hanya bagi kami.
Peralatan otomasi
Otomatisasi apa tanpa peralatan! Seluruh gudang terjerat dalam seluruh jaringan konveyor.
Penyortir barang yang disebutkan di atas bekerja pada tahap pengiriman, memungkinkan Anda untuk meletakkan puluhan ribu unit barang yang dikumpulkan dari stok untuk pesanan tertentu. Pada suatu waktu, tukang sortir menyelamatkan operator kami dari kebutuhan bepergian dengan troli di sekitar gudang untuk mengumpulkan barang-barang yang diperlukan. Pesanan dibagi, masing-masing operator mengumpulkan barang hanya dari lantainya (menghemat waktu untuk bergerak), dan penyortir memastikan bahwa barang dari lantai berbeda masuk ke pesanan yang tepat secara otomatis. Mengubah proses operasional sebanyak 4 kali mempercepat perakitan pesanan dan secara signifikan mengurangi jumlah kesalahan.
Semua peralatan otomatis disediakan oleh mitra kami. Untuk manajemen unit tertentu mereka memiliki sistem mereka sendiri, yang terletak di rak server di sebelah WMS kami. Di antara sistem, integrasi dikonfigurasikan pada protokol tingkat tinggi - kami berkomunikasi melalui SOAP. Dari proses operasional kami di dalam WMS, kami beralih ke sistem mereka ketika, misalnya, kita perlu memindahkan wadah berisi barang dari titik A ke titik B. Yaitu, dari sudut pandang sistem kami, semua otomatisasi ini terlihat cukup sederhana, meskipun kompleksitas internal sebenarnya.
Tentu saja, kesederhanaan yang tampak ini tidak segera berhasil. Pada tahap pertama otomatisasi, kami memiliki teknologi yang saling menguntungkan. Setelah konveyor benar-benar membakar barang-barang kami - kecepatan sabuk konveyor terlalu tinggi, konveyor “mengunyah” barang-barang kami dan membakar, yang menghalangi perakitan pesanan lainnya. Mungkin kisah tersulit terjadi pada awal otomatisasi, ketika kami meluncurkan fase pertama. Kemarin, gudang itu sepenuhnya manual, dan hari ini, setelah beralih, harus menjadi otomatis. Tetapi tidak ada yang berhasil: karena kesalahan dalam integrasi sistem, pesan masing-masing ditafsirkan secara salah, yang mengakibatkan beberapa hari downtime gudang dan jutaan kerugian bagi kami.
Sekarang mitra hadir di gudang kami, berencana untuk mengatur peralatan dengan kami ketika datang ke babak otomatisasi baru, membantu untuk menguji blok baru.
Tim dan scrumban
Pengembangan seluruh sistem ini sekarang terlibat dalam tim yang terdiri dari 12 orang. Pada salah satu tahap terakhir dalam puncak modernisasi, ketika proses otomatisasi terpisah digabungkan menjadi sesuatu yang utuh, hingga 20 pengembang saja yang berpartisipasi (tahap itu membutuhkan 132 orang-bulan dan mencakup lebih dari 1.500 komitmen). Tetapi ketika transformasi skala besar berakhir, beberapa orang memutuskan untuk belajar Go atau Python dan beralih ke tim pengembangan lainnya.
Dalam tim, kami memiliki manajer proyek "klasik" yang menggabungkan fungsi produk dan proyek dari TI (rata-rata, satu PM untuk 5-6 orang). Tugasnya meliputi komunikasi dengan pelanggan utama kami - gudang yang diwakili oleh direkturnya dan departemen pengembangan proses operasional. Untuk bagian kami, kami lebih peduli tentang modernisasi teknis - memilih tumpukan yang tepat, pembaruan, dll. - Dan orang-orang dari gudang berpikir untuk mengoptimalkan proses.
Terkadang kita sendiri mencurahkan waktu untuk R&D di lapangan. Dalam arti harfiah, kami datang ke gudang, berkomunikasi dengan shift senior, dengan operator biasa, dan mengklarifikasi masalah apa yang mereka miliki, apa yang nyaman dan tidak nyaman untuk diajak bekerja sama. Dengan kata lain, kami melakukan penelitian pengalaman pengguna.
Berkat pendekatan ini, misalnya, kami telah mengubah antarmuka tempat kerja karyawan yang melakukan penerimaan barang. Awalnya, itu adalah antarmuka perusahaan yang kompleks dengan banyak bidang, tombol, dan singkatan alih-alih penjelasan tekstual. Tetapi kami mencoba untuk mengoptimalkan proses, serta desain, membuatnya lebih mirip dengan halaman pencarian Google utama - tidak begitu indah, tetapi sangat fungsional. Semakin sederhana antarmuka dan semakin sedikit opsi yang dimiliki operator, di mana untuk mengklik dan apa yang harus dipindai, semakin sedikit kesalahan (dan waktu yang diperlukan untuk memperbaikinya).
Dan akumulasi pengetahuan tentang pengoptimalan perincian kini menyusul kami di saat-saat yang paling tidak terduga: begitu tim kami berada di institusi dan pada satu saat hampir semua peserta melihat urutan tindakan kasir. Setelah sekitar 40 detik, seorang kolega menyuarakan gagasan umum: "Tidak terlalu optimal, Anda dapat menyederhanakannya."
Meskipun hubungan antara peran dalam tim cukup klasik, kami memilih scrumban untuk metodologi pengembangan.
Kami banyak bereksperimen dengan metodologi, sedangkan data "input" tidak standar. Sebagai contoh, kami memiliki rilis yang agak jarang. Pembatasan dua rilis per minggu yang disebutkan di atas bertindak pada bagian dari proses, tetapi pada kenyataannya kami menggunakan jauh lebih jarang - rata-rata sekali setiap dua minggu. Selain itu, kami memiliki perangkat keras otomatisasi gudang, yang sedang dikembangkan oleh perusahaan eksternal untuk air terjun bersih, di mana semua perubahan dijadwalkan dua tahun sebelumnya dengan semua dokumentasi yang diperlukan. Namun, kami sendiri tidak dapat mengikuti contoh mereka: kami perlu melakukan beberapa perubahan pada sistem secara teratur, dan memaksa pelanggan untuk menulis tugas terperinci karena masing-masing tidak ada gunanya.
Jadi scrumban adalah kompromi yang membuat semua orang bahagia. Kami menggunakan proses berulang, tetapi sprint adalah rilis untuk kami. Sekali sebulan kami bertemu dengan pelanggan dan melakukan perencanaan rilis: kami mendiskusikan apa dan minggu apa kami mulai. Di dalam sprint, kanban diimplementasikan - dengan tumpukan tugas, kemajuan, dll. Benar, proses ini secara bertahap berubah - misalnya, kami tidak memiliki papan kanban. Tepat ketika satu pengembang menyelesaikan tugasnya, ia diberi yang berikutnya dari kumpulan sesuai dengan rencana untuk rilis berikutnya dan kompetensi pengembang.
Kami menyukai pendekatan ini. Ini memberikan fleksibilitas yang diperlukan dalam iterasi, dan memberikan pelanggan bisnis prediksi tanggal dimana komitmen tertentu akan dilaksanakan. Dan tidak begitu penting bagi kita apa yang disebut metodologi ini. Yang utama adalah semuanya bekerja.
Tidak seperti orang lain - menggunakan inventaris dan pemantauan sebagai contoh
Mengembangkan proses operasional, kami mulai dari kebutuhan industri kami, oleh karena itu, kami memiliki beberapa fitur individual.
Contoh yang baik adalah inventaris. Menurut undang-undang, itu harus dilakukan di gudang setahun sekali, tetapi persyaratan bisnis kami menentukan pemantauan stok yang lebih dekat. Pertama, kami ingin mencerminkan informasi yang relevan tentang ketersediaan barang di situs web, dan kedua, mitra B2B kami, merek fesyen memerlukan informasi relevan yang sama. Oleh karena itu, inventarisasi dilakukan setiap hari, 364 hari setahun, rak demi rak di seluruh kompleks 5 lantai beberapa bangunan. Dan proses ini didukung penuh oleh WMS kami - akan sulit untuk mengimplementasikan solusi semacam itu.
Sekarang inventaris sedang dalam proses pembaruan berikutnya untuk meningkatkan efisiensi proses ini.
Contoh lain dari pengembangan kami sendiri adalah pemantauan. Ini diterapkan melalui klien web dan memungkinkan Anda untuk menampilkan dan melacak metrik yang sangat menarik. Selain itu, representasi visual dari metrik ini penting bagi kami. Sebenarnya, pemantauan adalah gudang yang digambarkan dalam jadwal yang sederhana, di mana kita dengan jelas melihat di mana semuanya berjalan dengan baik dan di mana masalah diamati (hingga operator tertentu). Yang terpenting, dengan pandangan ini, kita bisa mengerti mengapa masalah ini muncul.
Pekerja Gudang dan Redis KPI
Pengenalan teknologi baru, pembaruan, refactoring - semuanya hebat. Tapi WMS kami bekerja di bisnis nyata, jadi di sini kami harus menyelesaikan tidak hanya masalah ini. Bagian dari pekerjaan kami adalah perlindungan dari "peretas" internal - karyawan gudang yang memiliki akal yang menemukan cara baru untuk melakukan KPI tanpa melewati tugas.
Sebagai contoh, belum lama ini, kami terpaksa menambahkan Redis ke stack untuk mencegah pengguna masuk ke sistem dari beberapa workstation pada waktu yang bersamaan dan mengimplementasikan timeout sesi. Faktanya adalah pekerja gudang menyadari bahwa bekerja di bawah login yang sama dan menerima bonus untuk melebihi KPI jauh lebih menguntungkan daripada meningkatkan produktivitas mereka sendiri.
Karena menyelesaikan masalah bisnis memerlukan perubahan di berbagai tempat sistem, dari sudut pandang teknis, itu adalah tantangan yang sangat menarik.
Kejutan dari staf gudang tidak berakhir di sana. Hampir segera setelah rilis sesi, PostgreSQL mulai macet. Kami mencari alasan degradasi pangkalan yang tak terduga selama beberapa hari, sampai kami menemukan bahwa masalahnya, sekali lagi, adalah akal. Seorang gadis sering pergi merokok. Ketika dia meninggalkan tempat kerja, dia tersingkir dari sesi, dan untuk masuk lagi, perlu menemukan shift senior dan memindai lencananya. Mengurangi pengembaraannya di sekitar gudang, dia hanya merobek kode batang dari salah satu kereta dan memperbaiki tombol pemindai dengan selotip, mengaturnya untuk terus memindai kode batang ini. Dan ini bisa tidak diketahui untuk waktu yang lama jika barcode tidak berasal dari kereta, yang berisi 800 unit barang. Dengan setiap pemindaian, permintaan SQL besar dihasilkan untuk memvalidasi barang, yang "membunuh" database dengan "DDoS internal". Saya harus mengurus pembatasan jumlah pemindaian per unit waktu dan jumlah barang dalam kereta.
Sudah ada banyak cerita seperti itu, dan kami terus dihadapkan dengan yang baru. Selain itu, sistem harus beradaptasi dengan kondisi baru setiap saat. Dalam situasi seperti itu, seseorang tidak dapat membatasi diri hanya untuk metode administrasi - apa yang terjadi sekali dapat diulangi dengan baik.
Kemana kita akan pergi selanjutnya?
Optimalisasi proses dan otomatisasi gudang, tampaknya, tidak mungkin untuk diselesaikan. Itu berlangsung selama 5 tahun di perusahaan, dan, seperti yang saya katakan di atas, bahkan setelah tahap 9 kita tidak akan berhenti. Perusahaan terus berkembang di B2C dan B2B, jadi dalam waktu dekat kami merencanakan proyek besar lainnya - membuka gudang lain, ini akan membutuhkan penulisan ulang skala besar dari sistem yang ada, atau pembuatan yang serupa dari awal di tempat baru. Dan ini adalah tantangan baru yang menarik di persimpangan bisnis, fasilitas fisik, proses operasional dan solusi teknis.