M.Video-Eldorado Group mempresentasikan strategi Hacking Retail pada awal tahun 2021. Selama 5 tahun ke depan, kami berencana untuk menggandakan total omset menjadi 1 triliun rubel dan melipatgandakan ragamnya, termasuk melalui pengembangan pasar kami sendiri. Sistem TI "monolitik" tidak dapat memberikan pertumbuhan ini dalam waktu singkat, dan perkembangan non-standar memperlambat seluruh proses. Layanan mikro datang untuk menyelamatkan. Kami akan memberi tahu Anda bagaimana kami "memotong" sepotong SAP ERP, dan apa yang dihasilkan darinya.
Beberapa tahun yang lalu kami menyelesaikan proses penggabungan back office M.Video dan Eldorado. Akibatnya, infrastruktur TI terpadu dari jaringan ritel mulai mewakili struktur tiga lapis: pada tingkat pertama, back office bersatu, sistem akuntansi utamanya adalah SAP ERP "monolitik".
Di atasnya adalah platform layanan mikro yang terus berkembang yang menyediakan data kunci ke semua sistem depan (harga, promosi, produk, saldo, informasi pelanggan, dll.) dan menyediakan integrasi sistem depan dengan sistem belakang. Di lantai atas, skema ini dimahkotai dengan dua kantor depan terpisah untuk masing-masing merek.
Secara umum, bundel ini memenuhi kebutuhan bisnis saat ini. Tetapi mereka terus tumbuh, jadi kami terus mencari suboptimal, penghapusan yang dapat meningkatkan kinerja proses bisnis dan mempersiapkan mereka untuk peningkatan beban kerja.
Persiapkan dengan serius. M.Video-Eldorado memiliki rencana besar untuk memperluas jangkauan barang dan meluncurkan proyek baru. Pertumbuhan yang diharapkan dalam volume pasokan harus dua sampai lima kali. Dan bukan suatu hari nanti, tetapi dalam satu atau dua tahun ke depan.
Lama menunggu
Salah satu hambatan yang perlu dihilangkan sesegera mungkin adalah algoritma untuk menghitung kalender logistik. Mari kita jelaskan sedikit lebih detail. Ada konsep aksesibilitas logistik. Ini menentukan pada saat apa barang dapat dikirim dari titik A ke titik B. Parameter aksesibilitas logistik digunakan oleh semua kantor depan, diakses oleh aplikasi bisnis, dll. - ini adalah salah satu parameter utama suatu produk sebagai unit logistik.
Kalender berisi informasi lengkap tentang kemungkinan pemindahan barang antara pemasok, gudang pusat dan regional dan toko di kedua jaringan. Jika pengiriman dijadwalkan hari ini, kalender hari ini digunakan. Tapi besok itu akan kehilangan relevansinya dan akan perlu untuk menerapkan "besok".
Untuk meningkatkan stabilitas kerja proses logistik, perhitungan dilakukan setiap hari selama tiga hari sebelumnya. Solusi ini telah lama disampaikan sebagai "penopang" di SAP ERP karena kecepatan implementasinya. Prosesnya memakan waktu 9-11 jam! Pengujian di bawah beban yang lebih tinggi menunjukkan bahwa sistem tidak dapat mengatasi perhitungan bahkan dalam 24 jam. Untuk mencapai produktivitas yang lebih tinggi secara kualitatif dengan peningkatan volume yang signifikan, penting untuk mengeluarkan layanan ini dari monolit ...
Situasi saat ini
Algoritma untuk menghitung kalender logistik, yang merupakan bagian dari SAP ERP, adalah paket prosedur PL / SQL yang disediakan oleh SAP dalam bentuk solusi kotak yang disesuaikan. Perhitungan masing-masing dari tiga kalender di dalamnya dilakukan "dari awal", dengan mempertimbangkan semua kondisi untuk setiap rantai pasokan. Dengan demikian, sebagian besar perhitungan pada setiap tahap hanya saling menduplikasi. Ini adalah logika operasi produk, dan kami tidak memiliki sumber daya untuk sepenuhnya menghilangkan utang teknis.
Selain itu, algoritme meninggalkan rantai pasokan "sampah" duplikat di kalender yang telah selesai. Hal ini menyebabkan peningkatan ukuran database. Alih-alih 10 juta catatan yang diperlukan, database dapat berisi 20-30 juta dan membutuhkan pembersihan manual.
Alat asli tidak mencapai kondisi optimal dalam satu hari. Itu diperkenalkan sejak lama, dan selama seluruh periode operasi, banyak perbaikan dilakukan untuk itu, diprakarsai oleh pelanggan bisnis. Aliran perubahan bertahap selama bertahun-tahun menyebabkan munculnya berbagai ketidakakuratan, beberapa di antaranya tidak sepenuhnya tercermin dalam spesifikasi.
Pada saat yang sama, ini tentang alat bisnis yang penting, yang pada kinerjanya bergantung pada aktivitas ratusan toko di jaringan ritel. Oleh karena itu, pendekatan pengembangan produk harus sangat hati-hati tetapi cepat.
Menggerogoti sepotong "monolit"
Menyadari bahwa potensi pertumbuhan produktivitas SAP ERP di area ini (omong-omong, tidak khas untuk layanan ERP) telah habis, kami beralih ke layanan mikro. M.Video-Eldorado telah mengembangkan arah ini selama beberapa tahun.
Kami memiliki platform layanan mikro kami sendiri yang menjalankan lebih dari seratus layanan mikro. Itu perlu untuk membuat sejumlah layanan berdasarkan algoritma yang sama dengan modul asli dari sistem ERP. Kami ingin mempertahankan logika umum perhitungan, tetapi menghindari mengulangi proses yang sama.
Pekerjaan itu dilakukan dalam tiga arah utama. Pertama, perlu untuk mengoptimalkan algoritma SAP dengan menghilangkan perhitungan yang tidak perlu darinya. Kedua, perlu untuk menghilangkan munculnya rantai pasokan duplikat, yang mengarah ke akumulasi catatan yang tidak perlu dalam database. Ketiga, perlu untuk menghilangkan ketidakakuratan dalam hasil algoritma asli, yang memperumit optimalisasi proses bisnis.
Ingatlah bahwa SAP ERP adalah salah satu sistem belakang utama perusahaan, yang menerima data dari semua sistem depan. Terlepas dari kenyataan bahwa perhitungan kalender harus ditransfer ke layanan mikro, langkah pengadaan individu itu sendiri, pergerakan barang masih dibuat dalam sistem akuntansi pusat.
Untuk menghasilkan kalender logistik, SAP ERP menyediakan lebih dari 20 tabel dengan pengaturan yang diterima dari pengguna bisnis. Berdasarkan data inilah platform layanan mikro melakukan perhitungan. ERP sendiri juga menggunakannya untuk perhitungan internal saat membuat lengan pengiriman kedua dan ketiga. Oleh karena itu, tidak mungkin untuk hanya merobek seluruh proses dari monolit dan mentransfernya.
Diagram proses:
1 dan 3 - Proses melalui SAP PI menerima data dengan pengaturan untuk menghitung kalender dari SAP ERP;
2 dan 4 - Merekam data yang diterima dari ERP ke dalam database;
5 - Proses mengambil salah satu versi data yang disimpan dalam databasenya (secara default - versi terbaru). Kemudian menghitung kalender berdasarkan data ini dan menyimpannya dalam tabel pementasan. Selama operasi, proses meminta informasi tentang objek.
6 - Data ditransfer dari tabel staging ke tabel produktif dalam format yang sama di mana proses menerimanya dari SAP ERP.
7 - Menghapus data lama dengan pengaturan kalender dari database.
Alat, waktu, sumber daya
Karena kami telah membuat layanan mikro selama beberapa tahun, kami tidak memiliki keraguan khusus tentang pilihan alat pengembangan. Kombinasi Java 11 dan Spring Boot
2 yang dikuasai dengan baik mulai beraksi . Tidak ada keajaiban dalam kode, hanya hal-hal standar untuk Java - koleksi, antarmuka, dll.
Kami awalnya membangun algoritme baru sehingga semua operasi dengan tabel sepenuhnya dilakukan di RAM, dan tidak menggunakan kueri SQL di dalam database.
Pada bagian dari tim operasi SAP ERP, persiapan dilakukan untuk mentransfer data master ke platform layanan mikro untuk menghitung kalender. Butuh waktu sekitar 40 jam.
Ke depan, mereka hanya perlu mendukung proyek tersebut. Pekerjaan utama, tentu saja, jatuh di pundak para insinyur platform itu sendiri. Logika algoritma pada dasarnya diciptakan kembali. Dari ERP, hanya data master dan prinsip bisnis dasar untuk menghitung kalender yang diambil. Ini memakan waktu 150 jam lagi.
Secara umum, pelaksanaan proyek memakan waktu sekitar enam bulan. Kami menghabiskan dua bulan sendirian di berbagai autotests berdasarkan pendekatan yang berbeda. Uji coba instrumen baru berlanjut selama sekitar satu bulan. Selama periode ini, kami secara bersamaan menghitung dua jenis kalender - lama dan baru, mempelajari dan membandingkan hasilnya, sangat penting untuk memastikan bahwa layanan tidak memburuk dan perhitungannya benar. Hanya setelah itu diputuskan untuk mentransfer alat baru ke lingkungan produksi.
hasil
Apa yang kita dapatkan pada akhirnya? Kalender sekarang dihitung hanya sekali. Kemudian turunannya untuk masing-masing dari tiga hari diperoleh sebagai hasil dari sedikit perhitungan tambahan yang terkait dengan perubahan tanggal. Volume database secara otomatis dipertahankan dalam keadaan optimal karena tidak adanya add-on "kruk", beban pada sistem ERP berkurang.
Tetapi hasil utama yang dapat kami capai adalah pengurangan waktu pembuatan kalender dari 9-11 jam menjadi ... 10 menit! Ada banyak pekerjaan di depan, beberapa peningkatan beban pada infrastruktur TI di masa depan masih akan membutuhkan perbaikan, tetapi kami memenangkan bagian dari hutang teknis ini.