Sistem procurement perusahaan tidak seharusnya hanya menjadi aplikasi untuk membuat purchase order. Dalam operasi yang sudah cukup kompleks, kebutuhan purchasing biasanya dimulai jauh sebelum PO dibuat dan belum selesai ketika PO dikirim kepada supplier. Ada purchase request dari user, pengecekan kebutuhan, approval berdasarkan nilai transaksi, budget validation, pemilihan vendor, purchase order, penerimaan barang, update inventory, invoice verification, hingga pembayaran.<\/p>\n\n\n\n
Jika setiap tahapan tersebut dikelola menggunakan aplikasi berbeda tanpa workflow yang jelas, perusahaan sebenarnya sudah memiliki teknologi tetapi belum mempunyai procurement process yang terintegrasi<\/strong>. Request mungkin dibuat melalui form, approval berlangsung melalui email, buyer mencatat PO di ERP, Warehouse menggunakan sistem sendiri, dan Finance baru mengetahui transaksi setelah invoice diterima. Setiap aplikasi bekerja, tetapi manusia masih bertugas menghubungkan keseluruhan proses.<\/p>\n\n\n\n IBM mendefinisikan procurement automation sebagai penggunaan teknologi untuk menyederhanakan dan meningkatkan proses procurement, mulai dari pekerjaan manual seperti data entry hingga workflow procure-to-pay yang lebih terintegrasi. IBM juga menekankan manfaat automation terhadap approval speed, compliance, visibility, dan data-driven decision-making. IBM \u2014 Procurement Automation<\/a><\/p>\n\n\n\n Karena itu pertanyaan yang lebih relevan bagi perusahaan bukan:<\/p>\n\n\n\n \u201cApakah kita sudah mempunyai software purchasing?\u201d<\/strong><\/p>\n\n\n\n melainkan:<\/p>\n\n\n\n \u201cApakah purchase request, approval, inventory, purchasing, receiving, dan Finance sudah bekerja sebagai satu business flow?\u201d<\/strong><\/p>\n\n\n\n Purchasing adalah bagian dari procurement, tetapi keduanya tidak selalu identik. Purchasing lebih dekat dengan kegiatan membeli: membuat PO, berkomunikasi dengan supplier, dan memastikan barang atau jasa diperoleh. Procurement mempunyai ruang lingkup lebih luas karena dimulai dari identifikasi kebutuhan hingga perusahaan memastikan transaksi tersebut memang sesuai policy dan akhirnya dibayar.<\/p>\n\n\n\n SAP menggambarkan procurement cycle dengan tahapan seperti determination of requirements, source determination, purchase-order processing, goods receipt, hingga invoice verification. Requirement bahkan dapat berasal dari user department maupun otomatis dari material planning dan inventory control. SAP \u2014 Procurement in SAP S\/4HANA<\/a><\/p>\n\n\n\n Karena itu sistem procurement perusahaan yang matang tidak hanya menjawab \u201cPO mana yang sudah dibuat?\u201d<\/strong>. Sistem juga harus membantu perusahaan mengetahui mengapa pembelian diperlukan, siapa yang menyetujuinya, apakah kebutuhan sebenarnya dapat dipenuhi dari stock existing, supplier mana yang digunakan, apakah barang sudah diterima, apakah invoice sesuai transaksi, dan berapa total commitment yang sudah dibuat sebelum payment benar-benar terjadi.<\/p>\n\n\n\n Ini yang membedakan procurement application dari sekadar PO generator<\/strong>.<\/p>\n\n\n\n Purchase order biasanya sudah berada cukup jauh di dalam proses. Sebelum PO dibuat, seseorang di dalam perusahaan terlebih dahulu mempunyai kebutuhan.<\/p>\n\n\n\n Contohnya, Operations membutuhkan 20 laptop. Maintenance membutuhkan spare part. Marketing membutuhkan jasa agency. Production membutuhkan raw material. Semua kebutuhan tersebut memiliki karakter berbeda tetapi biasanya dimulai dengan purchase request atau purchase requisition<\/strong>.<\/p>\n\n\n\n Flow dasarnya dapat berbentuk:<\/p>\n\n\n\n Need Identified \u2192 Purchase Request \u2192 Validation \u2192 Approval \u2192 Sourcing\/Vendor \u2192 Purchase Order \u2192 Receiving \u2192 Invoice \u2192 Payment<\/strong><\/p>\n\n\n\n SAP menjelaskan workflow purchase requisition dengan pola yang hampir sama: requester membuat PR, request diarahkan kepada approver berdasarkan business rules, kemudian setelah fully approved supplier ditentukan dan purchase order dapat dibuat. Setelah itu barang dikirim, receipt dicatat, dan proses berlanjut menuju pembayaran. SAP \u2014 Purchase Requisition Workflow<\/a><\/p>\n\n\n\n Jika perusahaan langsung memulai digitalisasi dari PO, sebagian besar friction sebelum PO tetap tidak terlihat. Tim Procurement masih menerima request dari WhatsApp, spreadsheet, email, atau verbal instruction, lalu buyer harus menginterpretasikan apakah request tersebut benar-benar approved.<\/p>\n\n\n\n Sistem procurement yang baik seharusnya membuat business demand muncul di dalam sistem sebelum purchasing action dilakukan<\/strong>.<\/p>\n\n\n\n Salah satu indikator pertama perusahaan membutuhkan sistem procurement yang lebih terintegrasi adalah ketika permintaan pembelian datang dari banyak channel. User mengirim spreadsheet, manager meneruskan email, department lain menggunakan Google Form, sementara request urgent dikirim melalui WhatsApp.<\/p>\n\n\n\n Buyer kemudian bertindak sebagai consolidation layer. Procurement harus memeriksa apakah informasi lengkap, siapa yang sudah menyetujui, apakah budget tersedia, kapan barang dibutuhkan, dan apakah permintaan serupa sudah pernah dibuat.<\/p>\n\n\n\n Pada skala kecil kondisi tersebut masih dapat dikelola. Ketika jumlah request bertambah, masalah utamanya berubah dari data entry<\/strong> menjadi control<\/strong>. Procurement kesulitan menentukan request mana yang benar-benar valid, request mana yang urgent, dan request mana yang sudah terlalu lama menunggu.<\/p>\n\n\n\n IBM menjelaskan bahwa automation pada purchase requisition dapat menyediakan template terstruktur sekaligus mengirim notification langsung kepada pihak yang harus memberikan approval. Setelah requisition disetujui, sistem dapat melanjutkannya menjadi digital purchase order. IBM \u2014 Procurement Automation Workflow<\/a><\/p>\n\n\n\n Dalam konteks yang lebih luas, hal ini berkaitan erat dengan artikel Crocodic tentang Aplikasi Proses Bisnis: Kapan Perusahaan Perlu Mengotomatisasi Workflow Operasional?<\/a>. Purchase request pada dasarnya adalah salah satu contoh workflow lintas-departemen: ada requester, rule, approver, Procurement, system action, dan outcome.<\/p>\n\n\n\n Procurement sangat mudah mengalami bottleneck pada approval.<\/p>\n\n\n\n Purchase request sudah dibuat Senin, tetapi manager baru melihat email Kamis. Request bernilai besar membutuhkan approval tambahan CFO, tetapi requester tidak mengetahui siapa yang sedang memegang proses. Procurement akhirnya menghabiskan waktu untuk mengingatkan approver daripada mengelola supplier dan purchasing strategy.<\/p>\n\n\n\n Masalah seperti ini tidak hanya memperpanjang cycle time. Approval yang berlangsung di luar sistem juga menurunkan auditability. Ketika auditor meminta bukti siapa yang menyetujui pembelian tertentu enam bulan lalu, tim harus mencari conversation atau email yang mungkin sudah tersebar.<\/p>\n\n\n\n Approval system seharusnya dapat menentukan route berdasarkan business rule. Contohnya, request di bawah Rp10 juta cukup disetujui Department Head, sedangkan transaksi di atas Rp100 juta membutuhkan Finance atau Director. Request pada category tertentu dapat memerlukan technical approval, sementara pembelian asset membutuhkan proses yang berbeda dengan operational expense.<\/p>\n\n\n\n SAP secara eksplisit menjelaskan bahwa purchase requisition dapat diarahkan kepada approver berdasarkan business rules dan sistem mengirim notification kepada pihak yang perlu memberikan keputusan. SAP \u2014 PR Approval Workflow<\/a><\/p>\n\n\n\n Dengan demikian, approval berubah dari conversation<\/strong> menjadi state di dalam business process<\/strong>. Perusahaan dapat mengetahui siapa yang menunggu, berapa lama request berada pada satu tahap, dan rule apa yang menentukan approval berikutnya.<\/p>\n\n\n\n Procurement dan inventory sering dianggap dua domain berbeda. Padahal salah satu pertanyaan pertama sebelum melakukan external purchase seharusnya adalah:<\/p>\n\n\n\n \u201cApakah kebutuhan ini sebenarnya sudah dapat dipenuhi dari stock yang tersedia?\u201d<\/strong><\/p>\n\n\n\n Jika sistem procurement tidak terhubung dengan inventory, requester atau buyer mungkin membuat PO untuk barang yang ternyata masih berada di warehouse lain. Sebaliknya, system inventory dapat menunjukkan stok tersedia tetapi quantity tersebut sebenarnya sudah reserved untuk production atau project lain.<\/p>\n\n\n\n SAP bahkan menyediakan proses di mana organisasi dapat memeriksa dan melakukan reservation terhadap item inventory terlebih dahulu sebelum memulai external purchasing. Dokumentasinya menyebut banyak organisasi lebih memilih memenuhi procurement requirement dari inventory existing sebelum membeli dari supplier luar. SAP \u2014 Reserving Inventory During Purchase Requisition<\/a><\/p>\n\n\n\n Integrasi tersebut mengubah decision flow:<\/p>\n\n\n\n Need \u2192 Check Internal Inventory \u2192 Reserve if Available \u2192 Purchase Only the Shortage<\/strong><\/p>\n\n\n\n dibanding:<\/p>\n\n\n\n Need \u2192 Purchase Everything \u2192 Inventory Bertambah.<\/strong><\/p>\n\n\n\n Perubahan kecil ini dapat berdampak langsung terhadap working capital karena Procurement tidak lagi membuat keputusan berdasarkan demand saja tetapi berdasarkan demand dikurangi usable supply existing<\/strong>.<\/p>\n\n\n\n Contoh inefficiency lain adalah ketika purchase request sudah memuat item, quantity, price estimate, cost center, dan supplier recommendation, tetapi setelah approval buyer harus membuka aplikasi lain dan mengetik ulang informasi tersebut untuk membuat PO.<\/p>\n\n\n\n Selain membuang waktu, duplicate entry menciptakan ruang bagi mismatch. Request disetujui untuk 100 unit tetapi PO dibuat 110. Cost center berbeda. Supplier berubah tetapi tidak ada approval ulang.<\/p>\n\n\n\n Automation seharusnya mempertahankan transaction lineage.<\/p>\n\n\n\n Purchase Request PR-001 \u2192 Approved \u2192 Purchase Order PO-001<\/strong><\/p>\n\n\n\n PO bukan transaksi baru yang tidak memiliki hubungan dengan request. Ia merupakan kelanjutan dari demand yang sebelumnya sudah diperiksa dan disetujui.<\/p>\n\n\n\n IBM menjelaskan purchase-order automation sebagai penggunaan software untuk mengelola pembuatan, approval, dan tracking PO secara digital. IBM juga menyebut sistem PO automation biasanya terintegrasi dengan accounting dan inventory management sehingga request, approval, order, receipt, dan invoice dapat terhubung dalam workflow yang lebih kohesif. IBM \u2014 Purchase Order Automation<\/a><\/p>\n\n\n\n Procurement automation yang baik bukan menghilangkan PO. Ia menghilangkan kebutuhan manusia untuk membangun ulang informasi yang sebenarnya sudah dimiliki sistem.<\/strong><\/p>\n\n\n\n Setelah PO dikirim kepada supplier, barang belum tentu datang sesuai pesanan.<\/p>\n\n\n\n PO: 1.000 unit.<\/p>\n\n\n\n Supplier mengirim tahap pertama: 600.<\/p>\n\n\n\n Tahap kedua: 300.<\/p>\n\n\n\n Sebanyak 20 unit rejected.<\/p>\n\n\n\n Masih ada 100 unit outstanding.<\/p>\n\n\n\n Jika Procurement hanya mengetahui PO sedangkan Warehouse mengetahui actual receipt pada sistem berbeda, tidak ada satu tempat yang menggambarkan kondisi transaksi secara lengkap.<\/p>\n\n\n\n SAP procurement workflow mendukung receipt setelah order dibuat, termasuk partial receipt ketika barang datang secara bertahap. SAP \u2014 Purchase Order Process<\/a><\/p>\n\n\n\n Integrasi receiving membuat Procurement dapat mengetahui:<\/p>\n\n\n\nProcurement Bukan Hanya Aktivitas Purchasing<\/strong><\/h2>\n\n\n\n
Procurement Terintegrasi Dimulai dari Purchase Request, Bukan Purchase Order<\/strong><\/h2>\n\n\n\n
1. Purchase Request Masih Datang dari Banyak Channel<\/strong><\/h2>\n\n\n\n
2. Approval Bergantung pada Orang yang Harus Dikejar Manual<\/strong><\/h2>\n\n\n\n
3. Procurement Membeli Barang yang Sebenarnya Masih Tersedia di Inventory<\/strong><\/h2>\n\n\n\n
4. Purchase Order Dibuat Ulang dari Data yang Sudah Disetujui<\/strong><\/h2>\n\n\n\n
5. Receiving dan Purchasing Memiliki Data yang Berbeda<\/strong><\/h2>\n\n\n\n