AI untuk Kos Sebenar Melayan Pelanggan (Cost-to-Serve)

Pada hujung tahun, ramai pasukan logistik dan perolehan sedang “tutup buku”: semak bajet, buat rundingan kontrak, dan bersedia untuk lonjakan permintaan musim cuti sekolah serta sambutan awal tahun. Tapi ada satu isu yang selalu muncul semula—margin mengecil walaupun jualan nampak sihat.

Most companies get this wrong: mereka urus “spend” (perbelanjaan) ikut laporan statik, ikut kategori, dan ikut vendor. Masalahnya, kos dalam rantaian bekalan hari ini bergerak macam ombak—tarif, kadar pengangkutan, ketepatan pembekal, perubahan corak pesanan, dan kekangan gudang semuanya saling mempengaruhi. Bila kita hanya tengok “berapa dibelanjakan”, kita terlepas perkara yang lebih penting: berapa kos sebenar untuk melayan pelanggan tertentu, di lokasi tertentu, dengan tahap servis tertentu. Itulah cost-to-serve.

Dalam siri “AI dalam Logistik dan Rantaian Bekalan”, saya suka mengambil pendekatan yang praktikal: bukan sekadar teori AI, tapi bagaimana AI membantu pasukan buat keputusan yang cepat, berasas data, dan boleh diaudit. Artikel RSS ini menekan satu mesej yang saya setuju 100%: spend bukan isu back-office—ia tuil strategi. Bezanya hari ini, tuil itu boleh digerakkan dengan lebih tepat menggunakan AI.

Spend yang “kelihatan terkawal” selalunya menipu

Jawapan terus: spend boleh nampak terkawal di dashboard, tetapi cost-to-serve mungkin sedang bocor di belakang tabir.

Ramai organisasi memantau kos melalui laporan bulanan atau suku tahunan: kos pengangkutan, kos pembelian bahan, kos gudang, kos tenaga kerja. Itu berguna, tapi ia tidak menyambungkan kos kepada tingkah laku permintaan dan servis.

Tiga punca besar spend nampak cantik, margin tetap bocor

1. Data berpecah: perolehan di satu sistem, pengangkutan di TMS, gudang di WMS, kewangan di ERP. Bila berpecah, kos sebenar tak pernah “berjumpa” dalam satu cerita.
2. Laporan statik: laporan hanya cerita apa yang sudah berlaku. Bila kos drift (contoh: prestasi pembekal merosot, lead time naik), tindakan selalunya lambat.
3. Kos yang “berantai”: satu perubahan kecil boleh mengalir ke banyak tempat. Contoh mudah: pembekal lewat → perlu expedite shipping → gudang kerja lebih masa → lebih banyak split shipment → kos last mile naik.

Kalau anda pernah rasa “kita dah negotiate harga vendor”, tetapi kos operasi tetap naik—itu simptom klasik.

Ayat yang patut jadi pegangan: Kalau anda tak boleh nampak cost-to-serve mengikut pelanggan/SKU/lokasi secara hampir masa nyata, anda sedang mengurus spend secara separuh buta.

Rethink: Total Cost-to-Serve sebagai “satu sumber kebenaran”

Jawapan terus: total cost-to-serve yang moden mesti menyatukan perolehan, logistik, pergudangan, kewangan, dan prestasi pembekal dalam satu model.

Dalam konteks Malaysia dan rantau ini, cabarannya sering berkait dengan:

• rangkaian pembekal yang campuran (tempatan + import)
• variasi kos pengangkutan antara Semenanjung–Sabah–Sarawak
• permintaan e-dagang yang menolak penghantaran lebih cepat dan pulangan lebih tinggi

Apa yang patut masuk dalam model cost-to-serve

Bukan setakat “freight + warehousing”. Model yang berguna biasanya merangkumi:

• Kos perolehan: harga unit, diskaun volum, MOQ, kos kualiti (reject/return)
• Kos pengangkutan: line-haul, surcaj bahan api, tol, caj puncak, demurrage/detention (jika berkaitan)
• Kos gudang: putaway, picking, packing, kitting, cross-dock, ruang (m²) dan pusing ganti
• Kos servis: split order, urgent order, penghantaran hari sama/next day
• Kos risiko: penalti SLA, stockout, obsolescence, insurans, kerosakan

Di sini AI mula relevan: bila komponennya banyak dan saling bergantung, manusia akan sukar buat analisis yang konsisten setiap minggu, apatah lagi setiap hari.

Lapisan “tingkah laku hidup”: AI untuk kesan drift sebelum jadi parah

Jawapan terus: AI berguna bukan kerana ia ‘bijak’, tetapi kerana ia boleh mengesan perubahan corak kos dan punca akar lebih awal daripada kitaran laporan biasa.

Artikel RSS menyentuh idea penting: bukan sekadar data bersambung, tetapi lapisan tingkah laku yang sentiasa memerhati drift dan interdependensi.

Drift yang biasa, tapi mahal

Saya bagi contoh yang kerap berlaku:

• Vendor performance drift: kadar on-time-in-full (OTIF) jatuh sedikit demi sedikit. Tiada siapa panik sebab “masih ok”. Tiga bulan kemudian, expedite menjadi rutin.
• Drift mix pesanan: pelanggan mula membuat pesanan kecil tetapi kerap. Kos picking dan last mile per unit naik, tapi jualan nampak meningkat.
• Drift lokasi permintaan: pertumbuhan di kawasan yang jauh dari DC utama. Kos zon penghantaran melonjak.

Apa yang AI buat secara praktikal

Dengan data yang cukup, AI/ML boleh:

• mengesan anomaly pada kos per order, kos per kg, kos per line item
• membuat ramalan kos (bukan ramalan permintaan sahaja), contohnya kos pengangkutan minggu depan mengikut lane
• memetakan punca kemungkinan (contoh: “kenaikan kos picking 12% berkorelasi dengan peningkatan split shipment dan pesanan < 3 item”)

Ini bukan magik. Ini disiplin data + pemodelan yang konsisten. Dan bila ia berjalan, pasukan tak lagi bergantung pada “rasa-rasanya”.

Dari maklumat ke tindakan: playbook berasaskan AI untuk orkestrasi

Jawapan terus: nilai sebenar datang bila insight terus memicu tindakan—alternate sourcing, renegotiation, rerouting, atau rescheduling—bukan sekadar notifikasi.

Banyak organisasi berhenti di dashboard. Saya cakap terus: dashboard tanpa tindakan ialah hiasan. Dalam rantaian bekalan yang volatile, anda perlukan orkestrasi.

Contoh playbook yang berbaloi untuk cost-to-serve

1. Alternate sourcing automatik (dengan syarat)
   • Jika kos landed item naik melebihi ambang (contoh 6%) dan vendor B memenuhi kriteria kualiti, AI cadangkan peralihan volum.
2. Renegotiation trigger
   • Jika surcaj atau aksesori caj vendor logistik mula “mengembang” melebihi kadar sejarah, sistem flag untuk semak invois dan jadual semula kontrak.
3. Rerouting & mode shift
   • Jika lane tertentu menunjukkan risiko lewat tinggi, AI cadangkan laluan alternatif atau peralihan mod (contoh: dari ekspres ke ekonomi untuk order bukan kritikal).
4. Rescheduling gudang
   • Jika ramalan volum dan cut-off time menunjukkan bottleneck, sistem cadangkan slotting semula, wave picking, atau tambah shift sementara.

Yang penting: playbook ini mesti boleh diaudit. Pengurus perlu nampak “kenapa cadangan ini keluar” dan “apa impaknya pada kos dan SLA”.

Cara mula: pelan 30-60-90 hari untuk AI spend & cost-to-serve

Jawapan terus: mulakan dengan satu use case yang ada data jelas dan impak P&L, kemudian skala secara berperingkat.

Kalau anda cuba buat semuanya serentak, projek akan jadi berat dan lambat. Ini pendekatan yang saya tengok paling menjadi.

30 hari: satukan definisi dan data minimum

• Tetapkan definisi cost-to-serve untuk organisasi (unit analisis: per pelanggan, per SKU, per order, atau per lane?)
• Senaraikan 10–20 medan data wajib dari ERP/TMS/WMS
• Pilih satu segmen untuk pilot (contoh: 20 pelanggan terbesar atau 50 SKU tertinggi volum)

60 hari: bina model kos & papan pemuka tindakan

• Bina model total cost-to-serve dan semak dengan Finance (ini penting)
• Wujudkan 5–8 metrik “pemandu kos” (contoh: split shipment rate, expedite rate, OTIF supplier)
• Sediakan alert untuk drift (ambang + trend)

90 hari: hidupkan playbook dan ukur hasil

• Pilih 2 playbook yang paling mudah dieksekusi (contoh: audit caj logistik + pengurangan split shipment)
• Ukur hasil dalam angka yang semua faham:
  • penjimatan RM per bulan
  • penurunan kos per order
  • peningkatan OTIF
  • pengurangan expedite shipment

Prinsip yang saya pegang: AI yang bagus ialah AI yang membantu anda buat keputusan lebih awal—bukan yang menghasilkan laporan paling cantik.

Soalan lazim (yang biasanya muncul dalam mesyuarat)

“Adakah kami perlukan AI kalau data kami masih berselerak?”

Anda masih boleh mula, tapi fokus pada penyatuan data minimum dahulu. AI tanpa asas data akan jadi projek ‘cuba-cuba’.

“Use case mana paling cepat nampak hasil?”

Biasanya:

• pengesanan drift caj pengangkutan dan audit invois
• pengurangan split shipment melalui cadangan konsolidasi
• ramalan kos lane + perancangan kapasiti gudang

“Macam mana nak elak AI jadi alat yang orang tak percaya?”

Pastikan setiap cadangan ada:

• input data yang jelas
• logik/penjelasan ringkas
• impak kewangan yang boleh disemak
• pilihan ‘approve/override’ dengan sebab

Apa yang patut anda buat minggu ini

Spend management yang lama—laporan statik, sistem berpecah, tindakan lambat—memang akan kalah dalam rantaian bekalan yang volatile. Cara yang lebih masuk akal ialah urusan cost-to-serve secara berterusan, dengan AI sebagai enjin pengesan drift dan pencetus playbook tindakan.

Jika anda sedang merancang bajet 2026, saya cadangkan satu keputusan tegas: berhenti menilai kos secara silo, mula ukur cost-to-serve sebagai KPI rentas fungsi. Dari situ, AI dalam logistik dan rantaian bekalan bukan lagi “projek teknologi”, tapi alat harian untuk lindungi margin.

Anda nak organisasi anda berada di pihak yang bertindak awal, atau pihak yang hanya sedar selepas margin sudah terhakis?