Masalah dan Solusi Umum

Paling sering disebabkan oleh tabrakan kunci komposit - jika dua catatan berbagi pengenal unik yang sama, satu menimpa yang lain.

Dapat juga terjadi jika kriteria filter dalam pemetaan data mengecualikan catatan yang Anda harapkan untuk dilihat.

Pesanan yang dipenuhi atau dihapus di antara laporan berjalan akan hilang dari penyegaran berikutnya tetapi mungkin masih muncul dalam pengecualian yang dihasilkan dari data hari sebelumnya.

Pesanan yang baru dibuat tidak akan muncul hingga penyegaran data berikutnya.

Sistem akan memfilter ke master produk secara otomatis. Hanya produk yang ada di file master produk Anda yang akan dimasukkan dalam perkiraan. Namun, jika sebagian besar file input Anda berada di luar cakupan (misalnya, 50% + baris), ini menunjukkan ekspor sumber perlu diperketat.

Periksa tingkat cakupan produk Anda secara teratur. Setelah setiap pemuatan data, verifikasi berapa persentase produk dalam penjualan Anda dan file input perkiraan yang cocok dengan master produk. Jika cakupan turun di bawah 80%, selidiki apakah cakupan ekspor sumber telah berubah atau master produk perlu diperbarui.

Out-of-scope produk dalam input rencana dapat menyebabkan total meningkat. Jika file EDI atau SIOP Anda menyertakan produk dari pabrik lain, sinyal perkiraan agregat akan lebih tinggi dari yang seharusnya. Pastikan file input paket disaring ke lingkup produk yang sama dengan master produk Anda sebelum memuat.

Periksa stempel waktu pada pengecualian — jika usianya lebih dari satu hari, rekomendasinya mungkin basi.

Jika rekomendasi jelas salah (misalnya, mengabaikan urutan besar yang terlihat di bagan), berikan umpan balik menggunakan jempol ke bawah dan laporkan pengecualian spesifik kepada tim dukungan Anda.

Tanggal dampak menunjukkan kapan masalah inventaris dimulai (misalnya, ketika stockout dimulai atau kelebihan melebihi ambang batas).

Tanggal “Act By” harus memperhitungkan lead time sehingga Anda punya waktu untuk bertindak sebelum masalah terwujud. Jika Act By sama dengan tanggal dampak, lead time mungkin tidak dimasukkan — laporkan ini ke tim dukungan Anda.

Terlalu banyak volume/inactive produk rendah dalam lingkup. Produk dengan permintaan yang jarang dan intermiten sulit bagi model apa pun untuk mengalahkan rata-rata sederhana. Gunakan aturan pra-pemrosesan untuk cakupan perkiraan untuk produk dengan riwayat permintaan yang berarti (misalnya, setidaknya 6 bulan permintaan bukan nol).

Pelatihan tentang sejarah basi atau terkontaminasi. Jika riwayat pesanan Anda sudah bertahun-tahun, pola permintaan lama mungkin tidak mencerminkan kenyataan saat ini. Pertimbangkan aturan pra-pemrosesan untuk membatasi riwayat pelatihan hingga 3-5 tahun terakhir, atau untuk mengganti periode anomali (misalnya, COVID) dengan nilai yang dinormalisasi.

Permintaan melonjak dari pesanan satu kali. Satu pesanan massal besar dapat membuat tren kenaikan palsu dalam data pelatihan. Gunakan aturan pra-pemrosesan untuk membatasi nilai permintaan bulanan anomali pada kelipatan rata-rata trailing (misalnya, 5x).

Aturan konsensus diterapkan ke arah yang salah. Agen LLM dapat salah menafsirkan bahasa aturan. “Penurunan sebesar 27%" dapat diterapkan sebagai peningkatan. Selalu validasi output konsensus terhadap baseline dengan membandingkan produk dan bulan tertentu. Gunakan bahasa perkalian eksplisit (“kalikan dengan 0,725") daripada bahasa terarah (“turun 27,5% “).

Model ini dilatih pada periode pertumbuhan. Jika beberapa tahun terakhir menunjukkan pertumbuhan yang tidak berlanjut, model memperkirakan tren yang tidak ada lagi.

Aturan konsensus menumpuk penyesuaian ke atas. Beberapa aturan yang masing-masing meningkatkan perkiraan (bias stok, peningkatan tren, peningkatan musiman) dapat bertambah. Tinjau aturan mana yang aktif dan periksa apakah semuanya berlaku untuk produk yang sama.

Deleted/discontinued produk masih dalam lingkup. Produk dengan permintaan trailing-off yang masih diperkirakan akan menunjukkan perkiraan berlebihan yang sistematis.

Sinyal perkiraan eksternal tidak dimasukkan. Jika Anda memiliki input rencana (misalnya, perkiraan pelanggan EDI, rencana produksi SIOP) dimuat tetapi aturan konsensus Anda tidak menerapkannya, perkiraan default ke garis dasar statistik - yang mungkin tidak menangkap sinyal permintaan yang dilihat oleh perencana Anda. Verifikasi bahwa aturan konsensus benar-benar memodifikasi output dengan membandingkan ekspor dengan ConsensusForecast ekspor Forecast (baseline). Jika mereka identik, aturannya tidak menembak.

Kombinasi produk × situs yang jarang menarik agregat ke bawah. Jika Anda memperkirakan pada granularitas produk × situs tetapi banyak kombinasi memiliki permintaan nol atau mendekati nol, model menghasilkan perkiraan kecil bukan nol untuk kombinasi tidak aktif. Ini tidak bertambah banyak secara individual tetapi secara kolektif menyeret perkiraan total di bawah aktual. Gunakan aturan pra-pemrosesan untuk mengecualikan kombinasi dengan riwayat permintaan yang tidak mencukupi, atau gunakan pengisian nol bersyarat dalam input paket Anda untuk secara eksplisit memberi sinyal “tidak ada permintaan yang diharapkan” untuk kombinasi yang tidak aktif.

Model ini belum menangkap tren pertumbuhan baru-baru ini. Model statistik menimbang data historis. Jika bisnis Anda telah tumbuh secara signifikan dalam beberapa bulan terakhir tetapi model ini memiliki sejarah volume yang lebih rendah selama bertahun-tahun, itu akan tertinggal tren. Ini biasanya meningkat seiring waktu karena model mengumpulkan data yang lebih baru. Untuk sementara, pertimbangkan aturan konsensus yang menggunakan rata-rata trailing dari aktual baru-baru ini sebagai dasar untuk minggu perkiraan luar.

Year-over-year ketidakcocokan musiman. Jika pola permintaan tahun ini berbeda dari tahun-tahun sebelumnya (misalnya, jalan musiman sebelumnya, peluncuran produk baru), model mungkin kurang diperkirakan selama periode divergen. Periksa apakah under-bias terkonsentrasi pada minggu atau bulan tertentu yang berbeda dari pola tahun sebelumnya.

Sinyal eksternal hanya membantu jangka pendek. Jika Anda memiliki aturan konsensus yang menggabungkan perkiraan pelanggan (EDI) untuk beberapa minggu pertama, akurasi akan terasa lebih baik dalam jangka pendek dan menurun ketika aturan berhenti berlaku. Ini diharapkan — pertimbangkan untuk memperpanjang aturan untuk mencakup lebih banyak minggu dengan pendekatan campuran (misalnya, 50/50 campuran sinyal eksternal dan garis dasar untuk minggu jangka menengah).

Garis dasar kembali ke rata-rata jangka panjang pada cakrawala yang lebih panjang. Model statistik menjadi kurang percaya diri pada cakrawala yang lebih panjang dan cenderung ke arah rata-rata historis. Jika permintaan baru-baru ini berada di atas rata-rata historis, minggu-minggu luar akan tampak kurang bias. Ini adalah perilaku model, bukan masalah konfigurasi.

Volatilitas permintaan membuat cakrawala yang lebih panjang secara inheren lebih sulit. Jika permintaan Anda memiliki variabilitas minggu-ke-minggu yang tinggi (koefisien variasi> 0,5), bahkan model yang sempurna akan menunjukkan kesalahan tinggi pada cakrawala yang lebih panjang. Evaluasi akurasi fokus pada 3-4 minggu pertama, yang merupakan jendela perencanaan yang dapat ditindaklanjuti untuk sebagian besar operasi.

Sinyal eksternal mungkin tidak mencakup cukup produk. EDI atau perkiraan pelanggan biasanya hanya mencakup sebagian dari katalog produk Anda (seringkali 30-50%). Produk tanpa sinyal eksternal masih menggunakan baseline. Periksa tingkat pertanggungan Anda — jika di bawah 50%, dampak pada akurasi agregat akan terbatas.

Sinyal eksternal mungkin tidak cukup akurat untuk membantu. Ukur akurasi perkiraan eksternal secara independen sebelum menggunakannya dalam aturan. Jika WAPE-nya lebih buruk dari baseline, menggabungkannya akan lebih menyakitkan daripada membantu. Pertimbangkan untuk membatasi aturan ke situs atau produk tertentu di mana sinyal eksternal terbukti lebih baik (misalnya, WAPE berbobot volume di bawah 50%).

Sinyal eksternal tidak melaporkan nol. Banyak sistem EDI hanya mengirim catatan untuk produk dengan pesanan aktif — mereka menghilangkan produk dengan permintaan nol daripada secara eksplisit melaporkan nol. Jika aturan konsensus Anda mengatakan “ketika EDI = 0, atur perkiraan ke 0,” itu tidak akan pernah menyala karena tidak ada catatan nol. Anda perlu menghasilkan catatan nol sintetis dalam pra-pemrosesan untuk kombinasi produk × situs yang tidak memiliki sinyal eksternal DAN tidak ada riwayat penjualan terbaru.

Akurasi sinyal eksternal bervariasi menurut cakrawala. Prakiraan pelanggan biasanya paling akurat untuk minggu depan segera (pada dasarnya pesanan yang dikonfirmasi) dan menurun dengan cepat. Aturan yang menggunakan sinyal eksternal secara langsung untuk semua minggu dapat merusak akurasi pada cakrawala yang lebih panjang. Pertimbangkan pendekatan berjenjang: penggantian langsung untuk minggu 1-3, dicampur selama minggu 4-6, baseline hanya untuk minggu 7+.

Aturan tersebut mungkin telah diganti dengan aturan prioritas yang lebih tinggi. Aturan diterapkan dalam urutan prioritas. Aturan selanjutnya dapat membatalkan yang sebelumnya. Periksa aturan pemesanan.

Kondisi aturan mungkin tidak cocok dengan produk apa pun. Jika aturan mereferensikan atribut produk (misalnya, product_group_id) yang tidak ada dalam metadata item, itu akan diam-diam tidak cocok dengan apa pun.

Bahasa aturan disalahartikan. Agen LLM menghasilkan kode dari bahasa alami. Ungkapan yang ambigu dapat menghasilkan hasil yang tidak terduga. Jadilah sespesifik dan literal mungkin. Gunakan nama bidang yang tepat, pengganda eksplisit, dan kondisi yang jelas.

Ketidakcocokan dimensi dalam bergabung. Mesin konsensus menggabungkan input rencana ke baseline pada kolom dimensi (ID produk, ID situs, tanggal). Jika nama kolom berbeda antara baseline dan input paket (misalnya, baseline menggunakan item_id sementara EDI menggunakan product_id), join tidak menghasilkan kecocokan dan semua aturan jatuh ke default baseline. Verifikasi bahwa pemetaan dimensi dalam konfigurasi aliran data Anda memetakan dengan benar di antara kedua skema.

Ketidakcocokan format tanggal. Garis dasar dapat menyimpan tanggal sebagai 2026-03-02 sementara input paket menyimpannya sebagai 2026-03-02. T00:00:00.000Z Jika bergabung membutuhkan kecocokan yang tepat, tanggal yang sadar zona waktu dan naif zona waktu tidak akan cocok. Periksa apakah kolom tanggal dikonversi ke format yang sama sebelum bergabung.

Input rencana tidak dimuat. Verifikasi bahwa file input paket Anda (EDI, SIOP, dll.) berhasil dicerna. Periksa jumlah catatan dalam sistem — jika mereka menunjukkan nol baris untuk input rencana, file mungkin gagal dimuat.

Consensus forecast_id cocok dengan baseline forecast_id. Jika kedua ekspor berbagi forecast_id yang sama, mesin konsensus menghasilkan salinan langsung dari baseline tanpa diproses. Ini menunjukkan masalah tingkat sistem — hubungi tim dukungan Anda dengan forecast_id dan demand_plan_run_id.

Kondisi site/product filter dapat merujuk kolom yang salah. Jika aturan Anda mengatakan “berlaku untuk situs di [daftar]” tetapi kode yang dihasilkan memeriksa kolom yang tidak ada atau memiliki nilai yang berbeda, filter dapat secara diam-diam melewati semua baris. Verifikasi dengan memeriksa beberapa produk tertentu yang TIDAK boleh terpengaruh oleh aturan.

Urutan prioritas aturan dapat dibalik. Aturan diterapkan sebagai rantai di mana aturan selanjutnya mengesampingkan yang sebelumnya. Jika aturan luas (misalnya, “gunakan garis dasar untuk semuanya”) diterapkan setelah aturan tertentu (misalnya, “gunakan EDI untuk 50 situs ini”), aturan luas akan membatalkan yang spesifik. Pastikan deskripsi aturan Anda dengan jelas menyatakan urutan prioritas.

Tambahkan aturan pembulatan sebagai langkah konsensus akhir. Aturan “bulat ke bilangan bulat terdekat” sederhana yang diterapkan setelah semua aturan konsensus lainnya akan membersihkan nilai pecahan. Nilai di bawah 0,5 akan bulat ke nol, yang sesuai untuk kombinasi permintaan yang sangat rendah.

Pertimbangkan pembulatan ke jumlah operasional. Jika produk Anda dikirimkan dalam ukuran kemasan standar (misalnya, kotak 12, palet 48), pembulatan ke ukuran paket valid terdekat dapat meningkatkan kegunaan dan akurasi perkiraan. Ini membutuhkan data ukuran paket di master produk Anda. Bagikan MOQ atau data ukuran paket Anda dengan tim dukungan Anda untuk menjelajahi opsi ini.

Periksa granularitasnya. Suatu produk mungkin memiliki 52 minggu permintaan pada tingkat produk tetapi hanya 3 minggu pada setiap produk individu × kombinasi situs. Ambang batas riwayat minimum yang diterapkan pada tingkat produk×situs akan mengecualikan sebagian besar kombinasi. Pertimbangkan untuk menerapkan ambang batas pada tingkat produk sebagai gantinya, atau menurunkan ambang batas secara signifikan.

Uji sebelum menerapkan. Sebelum mengaktifkan aturan pra-pemrosesan, hitung berapa banyak kombinasi produk × situs yang melewati filter vs. total Anda saat ini. Jika lebih dari 20% dikecualikan, aturannya kemungkinan terlalu agresif. Mulailah dengan ambang batas yang lunak dan kencangkan secara bertahap.