.jpg)
Duplicate purchase sering terjadi ketika request barang berasal dari banyak divisi tanpa histori pembelian yang jelas. Pelajari cara merapikan proses request dan approval agar pembelian lebih terkontrol.
Request pembelian sebenarnya sudah masuk minggu lalu. Namun karena dikirim lewat chat berbeda dan diproses oleh PIC yang berbeda, tim procurement baru sadar bahwa barang yang sama sudah pernah dibeli oleh divisi lain beberapa hari sebelumnya.
Kasus seperti ini cukup sering terjadi di perusahaan yang memiliki banyak request operasional setiap hari. Mulai dari ATK, laptop, spare part, kebutuhan project, sampai langganan software, semuanya bisa terduplikasi ketika proses request tidak terpusat dan histori pembelian sulit dicek dengan cepat.
Kenapa Duplicate Purchase Sering Terjadi?
Masalahnya biasanya bukan karena tim procurement tidak teliti. Yang lebih sering terjadi adalah informasi pembelian tersebar di banyak tempat.
Contohnya:
- Request masuk lewat email, chat, atau spreadsheet berbeda
- Nama barang ditulis tidak konsisten
- Tidak ada histori pembelian yang mudah dicari
- Approval dilakukan lewat chat tanpa dokumentasi jelas
- Tiap divisi membuat request sendiri-sendiri
- Status request masih manual dan sulit dipantau
Akibatnya, tim procurement hanya fokus memproses request yang masuk tanpa visibility apakah barang tersebut:
- Sudah pernah dibeli
- Masih tersedia
- Sedang dalam proses pembelian
- Sudah pernah diajukan divisi lain
Bedakan Request Baru, Repeat Purchase, dan Duplicate Request
Sebelum merapikan proses procurement, penting untuk membedakan beberapa kondisi berikut:
|
Status Request |
Penjelasan |
|
New Request |
Barang memang belum pernah dibeli sebelumnya |
|
Repeat Purchase |
Barang yang sama dibeli kembali karena stok habis atau kebutuhan rutin |
|
Duplicate Request |
Barang yang sama diajukan lebih dari satu kali tanpa kebutuhan tambahan yang jelas |
|
Pending Approval |
Request masih menunggu persetujuan |
|
In Procurement Process |
Barang sedang dalam proses pembelian |
Masalah duplicate purchase sering muncul karena tim tidak bisa membedakan antara repeat purchase yang memang diperlukan dan duplicate request yang sebenarnya bisa dicegah.
Data Minimal yang Perlu Dicek Sebelum Membeli Barang
Sebelum request diproses menjadi purchase order, tim procurement sebaiknya mengecek beberapa data berikut:
- Nama barang dan spesifikasi
- Divisi pengaju
- Tanggal request
- Jumlah barang
- Status approval
- Histori pembelian sebelumnya
- Status pengadaan yang sedang berjalan
- Vendor yang pernah digunakan
- PIC request
- Estimasi stok atau kebutuhan existing
Jangan hanya melihat nama barang. Banyak duplicate purchase terjadi karena spesifikasi ditulis berbeda padahal kebutuhan barangnya sama.
Contoh:
- “Monitor 24 inch”
- “Monitor Full HD”
- “Monitor Dell 24”
Padahal yang dimaksud adalah produk yang sama.
Contoh Kasus Duplicate Purchase antar Divisi
Berikut contoh sederhana yang sering terjadi di operasional sehari-hari:
|
Tanggal |
Divisi |
Barang |
Status |
|
3 Mei |
Marketing |
Printer Epson L3250 |
Approved |
|
5 Mei |
Finance |
Printer Epson L3250 |
Approved |
|
6 Mei |
Procurement |
Purchase Order dibuat |
Diproses |
Karena request masuk dari divisi berbeda dan histori pembelian tidak terlihat dalam satu dashboard, procurement mengira kedua request tersebut adalah kebutuhan terpisah.
Padahal setelah dicek, printer pertama sebenarnya masih cukup digunakan bersama untuk sementara waktu.
Akibatnya:
- Budget pembelian membengkak
- Approval menjadi tidak efektif
- Barang menumpuk
- Finance sulit mengontrol pengeluaran operasional
Cara Merapikan Proses Request Pembelian antar Divisi
Beberapa langkah berikut biasanya cukup membantu mengurangi duplicate purchase:
1. Gunakan format request yang sama
Semua divisi perlu menggunakan format request yang konsisten agar data mudah dicek.
Minimal isi request mencakup:
- Nama barang
- Spesifikasi
- Jumlah
- Tujuan penggunaan
- Deadline kebutuhan
- PIC pengaju
- Lokasi penggunaan
2. Buat request masuk ke satu alur yang sama
Jangan biarkan sebagian request masuk lewat chat, sebagian lewat email, dan sebagian lewat spreadsheet.
Ketika seluruh request masuk ke workflow yang sama, procurement lebih mudah:
- Mengecek histori
- Melihat request serupa
- Memantau approval
- Menghindari request ganda
Jika request pembelian mulai sulit dipantau karena datang dari banyak channel berbeda, perusahaan bisa mempertimbangkan sistem seperti BYON agar request form, approval, dan histori pembelian lebih mudah dilihat dalam satu alur kerja.
3. Cek histori pembelian sebelum approval final
Sebelum purchase order dibuat, biasakan melakukan pengecekan cepat:
- Apakah barang pernah dibeli sebelumnya?
- Apakah masih ada stok existing?
- Apakah ada request serupa minggu ini?
- Apakah barang sedang dalam proses procurement?
Langkah sederhana ini sering mengurangi pembelian yang sebenarnya belum perlu dilakukan.
Bagaimana Purchase History dan Workflow Approval Membantu?
Ketika request dan approval sudah masuk ke satu sistem, procurement tidak perlu lagi membuka banyak chat atau file untuk mengecek histori.
Fitur seperti purchase history membantu tim melihat:
- Barang yang pernah dibeli
- Frekuensi pembelian
- Vendor sebelumnya
- Nominal pembelian
- Divisi pengaju
- Status pengadaan terakhir
Sementara approval workflow membantu memastikan:
- Request tidak diproses dua kali
- Approval terdokumentasi
- Status request terlihat jelas
- PIC terkait mengetahui progres pembelian
Kombinasi dua hal ini membuat proses procurement lebih mudah dikontrol, terutama ketika jumlah request mulai meningkat setiap minggu.
Untuk perusahaan yang ingin membuat proses request dan procurement lebih konsisten antar divisi, BYON dapat membantu menghubungkan request form, workflow approval, purchase history, dan monitoring status dalam satu sistem yang lebih mudah dilacak.
Duplicate Purchase Biasanya Berawal dari Visibility yang Kurang
Dalam banyak kasus, duplicate purchase bukan terjadi karena tim sengaja melakukan kesalahan. Masalah utamanya adalah informasi pembelian tidak terlihat secara utuh saat request diproses.
Ketika histori pembelian, status request, dan approval bisa dilihat dalam satu alur yang jelas, perusahaan lebih mudah mengontrol pengeluaran, mengurangi pembelian yang tidak perlu, dan menjaga proses procurement tetap rapi meskipun request datang dari banyak divisi.