SAP Procurement: Proses, Integrasi, dan Cara Memperluas

SAP procurement jadi tulang punggung banyak perusahaan dalam mengelola pengadaan barang dan jasa.

Tapi begitu muncul kebutuhan approval atau alur kerja yang spesifik, tim IT sering harus memilih antara mengubah core-nya atau membiarkan kebutuhan itu tidak terpenuhi.

Risiko ini membuat perusahaan mulai mengevaluasi ulang cara memperluas sistem pengadaan SAP mereka tersebut tanpa menyentuh core-nya.

Artikel ini mengupas cara kerja SAP procurement secara menyeluruh, mulai dari alur proses hingga cara memperluas kapabilitasnya dengan aman. 

Apa Itu SAP Procurement?

SAP procurement adalah modul atau sistem perangkat lunak dari SAP yang digunakan perusahaan untuk mengelola proses pengadaan barang dan jasa secara terintegrasi.

Cakupannya mulai dari pembelian hingga pembayaran, atau yang biasa disebut alur Procure-to-Pay.

Biasanya, sistem ini berjalan lewat SAP MM (Materials Management) sebagai komponen operasional, atau lewat platform cloud seperti SAP Ariba untuk kebutuhan sourcing yang lebih strategis.

Proses pengadaan di software bisnis ini tidak berdiri sendiri, melainkan terhubung dengan beberapa modul dan produk lain di dalam ekosistem SAP.

Beberapa komponen yang biasanya jadi bagian dari SAP procurement meliputi:

• SAP Ariba: menangani strategic sourcing dan spend management.
• SAP Fieldglass: mengelola pengadaan tenaga kerja kontingen dan jasa.
• SAP Business Network: menghubungkan buyer dan supplier untuk mengeksekusi transaksi.
• SAP S/4HANA (modul MM): menjalankan proses pembelian barang dan jasa melalui komponen Materials Management, sebagai bagian dari alur procure-to-pay.

Modul-modul SAP tersebut saling terhubung erat satu sama lain. Perubahan pada satu modul, seperti menambah field custom di SAP Ariba, bisa berdampak ke proses di S/4HANA atau Business Network. 

Oleh karena itu, perusahaan cenderung berhati-hati saat mempertimbangkan modifikasi langsung ke dalam core SAP.

Alur Proses SAP Procurement (Procure-to-Pay)

Alur SAP procurement dikenal sebagai proses Procure-to-Pay (P2P), yaitu rangkaian langkah dari permintaan barang hingga pembayaran ke vendor.

Prosesnya diawali dari pembuatan dokumen internal permintaan pembelian, lalu berlanjut ke pencarian vendor, hingga akhirnya diverifikasi dan dibayarkan.

Agar lebih jelas, berikut tahapan pengadaan melalui SAP secara berurutan.

1. Purchase Requisition (PR)

Purchase Requisition adalah dokumen internal yang dibuat departemen atau sistem untuk meminta pembelian barang atau jasa tertentu.

Dokumen ini belum punya konsekuensi hukum atau finansial, jadi sifatnya masih permintaan awal.

PR bisa dibuat manual lewat transaksi ME51N, atau otomatis lewat Material Requirements Planning (MRP) saat stok sudah di bawah batas minimum.

Setelah dibuat, PR akan melalui proses approval sebelum lanjut ke tahap berikutnya.

2. Request for Quotation (RFQ) dan Penentuan Sumber

Setelah PR disetujui, tim purchasing mencari sumber pengadaan dengan mengirim RFQ (transaksi ME41) ke beberapa vendor.

Vendor kemudian mengirim penawaran harga sebagai respons. Tim purchasing membandingkan penawaran tersebut untuk menentukan vendor mana yang paling sesuai, baik dari sisi harga maupun ketersediaan.

3. Purchase Order (PO)

Setelah vendor terpilih, sistem membuat Purchase Order (transaksi ME21N) sebagai dokumen resmi yang mengikat secara hukum.

PO ini mencantumkan detail material, jumlah, harga, serta tanggal pengiriman yang disepakati.

PO bisa dibuat langsung dari referensi PR maupun RFQ, sehingga datanya tetap konsisten sepanjang alur.

4. Goods Receipt (GR)

Goods Receipt mencatat penerimaan barang atau jasa ke dalam sistem lewat transaksi MIGO.

Pada tahap ini, jumlah barang yang diterima dicocokkan dengan yang tertera di PO.

Kalau ada selisih, sistem akan mencatatnya sebagai diskrepansi yang perlu ditindaklanjuti sebelum proses lanjut ke verifikasi invoice.

5. Invoice Verification

Invoice vendor diverifikasi lewat transaksi MIRO untuk memastikan kecocokan antara PO, goods receipt, dan invoice yang diterima. Proses ini biasa disebut three-way matching.

Verifikasi ini penting untuk mencegah pembayaran atas barang yang belum diterima, sekaligus jadi kontrol internal dalam audit finansial.

6. Payment Processing

Setelah invoice terverifikasi, sistem memproses pembayaran ke vendor lewat transaksi F110 untuk payment run otomatis, atau F-53 untuk pembayaran manual.

Tahap ini menutup siklus P2P secara penuh, dari permintaan awal sampai dana benar-benar keluar ke vendor.

Tantangan Kustomisasi Core SAP Procurement

Alur procurement standar yang sudah dibahas sebelumnya berjalan baik untuk kebutuhan umum.

Namun, begitu muncul kasus di luar standar, seperti approval bertingkat khusus atau integrasi dengan sistem lokal, banyak perusahaan langsung mengarah ke satu opsi: modifikasi core system.

Padahal, opsi ini menyimpan risiko yang sering baru terasa belakangan.

Risiko Memodifikasi Core System Secara Langsung

Modifikasi langsung ke core memang terasa cepat di awal, karena tim IT bisa menambah custom code atau field baru sesuai kebutuhan.

Namun ada beberapa konsekuensi yang biasanya menyusul:

• Testing berulang: setiap custom code harus diuji ulang tiap kali SAP merilis patch atau update, menambah beban kerja tim IT.
• Biaya naik: semakin banyak modifikasi yang menumpuk, semakin besar juga biaya maintenance dan dukungan teknis jangka panjang.
• Upgrade tertunda: perusahaan jadi ragu melakukan upgrade karena harus memastikan semua custom code tetap kompatibel dengan versi baru.
• Risiko error meningkat: custom code yang saling bertumpuk membuat sistem lebih rentan terhadap bug saat live kembali dijalankan.

Keempat risiko ini saling berkaitan, dan biasanya baru terasa dampaknya saat perusahaan butuh upgrade atau menambah modul baru.

Prinsip Clean Core: Kenapa SAP Sendiri Menyarankan Tidak Mengubah Core

Menariknya, SAP sendiri secara resmi tidak merekomendasikan pendekatan modifikasi langsung ke core system.

SAP menjelaskan bahwa sistem ERP tradisional yang sering dikustomisasi berat memang memberi fleksibilitas jangka pendek, tapi lambat laun menciptakan lapisan custom code yang sulit dirawat, mahal untuk di-upgrade, dan rentan error.

Kompleksitas ini dikenal sebagai technical debt.

Sebagai gantinya, SAP mendorong satu prinsip yang disebut clean core. Intinya ada dua:

• Core tetap standar: sistem ERP dijaga sedekat mungkin dengan kondisi bawaan dari vendor, tanpa modifikasi berat.
• Ekstensi dibangun terpisah: kebutuhan kustomisasi ditangani lewat ekstensi cloud dan inovasi yang dibangun di luar sistem inti, dikenal sebagai side-by-side extensibility.

Pendekatan ini biasanya dijalankan lewat SAP Business Technology Platform (BTP), yang

berfungsi sebagai lapisan tempat perusahaan membangun logic tambahan tanpa menyentuh core SAP itu sendiri.

Kalau SAP sendiri merekomendasikan core tetap bersih, pertanyaan yang lebih relevan bagi perusahaan bukan lagi “boleh tidak memperluas SAP procurement?”, melainkan “lewat jalur apa perluasan itu sebaiknya dilakukan?”.

Cara Memperluas Kapabilitas SAP Procurement Tanpa Mengubah Core

Prinsip clean core menegaskan bahwa SAP tetap jadi system of record, sementara kebutuhan spesifik dibangun di lapisan terpisah.

Namun secara praktik, bagaimana penerapannya? Berikut langkah-langkah yang bisa diikuti perusahaan.

1. Pisahkan Kebutuhan Standar dan Kebutuhan Spesifik

Langkah pertama adalah memetakan proses procurement mana yang masih sesuai dengan alur standar SAP, dan mana yang butuh penyesuaian.

Approval flow yang mengikuti struktur organisasi internal, vendor onboarding lokal, atau dashboard turunan biasanya masuk kategori kedua.

Pemetaan ini penting supaya tim tidak asal memodifikasi core hanya karena satu proses terasa kurang pas.

2. Tentukan Titik Integrasi lewat API

Setelah kebutuhan spesifik teridentifikasi, langkah berikutnya adalah menentukan data dan proses apa saja yang perlu dipertukarkan antara SAP dan sistem ekstensi.

Ini termasuk menentukan API mana yang dipakai untuk menarik data purchase order, vendor, atau status approval dari SAP, dan bagaimana data itu dikembalikan setelah diproses di luar core.

3. Bangun Ekstensi di Luar Core System

Kebutuhan spesifik tadi kemudian dibangun secara terpisah, tanpa menyentuh kode atau konfigurasi inti SAP.

Ini bisa berupa custom workflow, form vendor, atau dashboard yang dijalankan di platform ekstensi.

Karena dibangun terpisah, perubahan atau iterasi di lapisan ini tidak memengaruhi stabilitas proses standar di SAP.

4. Hubungkan Kembali lewat Integrasi, Bukan Modifikasi

Setelah ekstensi selesai dibangun, sistem ini dihubungkan kembali ke SAP lewat API, bukan lewat perubahan langsung ke core.

Data tetap mengalir dua arah, misalnya status approval dari sistem ekstensi otomatis ter-update di SAP, tapi core system tetap dalam kondisi standar dan siap di-upgrade kapan saja.

5. Uji dan Kelola Secara Terpisah dari Core

Karena berjalan di luar core, testing dan maintenance ekstensi ini bisa dilakukan tanpa mengganggu jadwal upgrade SAP.

Perusahaan bisa melakukan iterasi lebih cepat pada bagian yang sering berubah, seperti approval flow atau dashboard, tanpa harus menunggu siklus release SAP secara keseluruhan.

Mekari Officeless sebagai Pelengkap dan Lapisan Integrasi SAP Procurement Anda

Lima langkah di atas butuh satu hal yang sama, yaitu platform yang bisa membangun ekstensi dan menghubungkannya ke SAP tanpa menyentuh core system.

Di sinilah Mekari Officeless berperan. Mekari Officeless menawarkan platform pengembangan software enterprise yang dirancang untuk membangun workflow, integrasi, dan pelaporan custom yang terhubung langsung dengan sistem SAP procurement yang sudah berjalan.

Beberapa kapabilitas yang relevan untuk kebutuhan ini:

• Custom workflow builder: membangun approval flow atau alur kerja procurement spesifik sesuai struktur organisasi, tanpa mengubah konfigurasi inti SAP.
• Integration & connections: menghubungkan sistem ekstensi ke SAP lewat API, sehingga data purchase order, vendor, dan status approval tetap sinkron dua arah.
• Insight & report builder: menyusun dashboard dan laporan turunan dari data procurement, disesuaikan dengan kebutuhan internal tanpa membebani core.
• Environment & release management: menguji dan merilis perubahan pada lapisan ekstensi secara terpisah dari jadwal upgrade SAP, sehingga iterasi bisa berjalan lebih cepat.

Lebih dari itu, Mekari Officeless juga merupakan bagian dari ekosistem software terpadu Mekari yang terhubung dengan seluruh produk Mekari lainnya, memungkinkan otomasi proses bisnis yang berulang, konektivitas lintas fungsi tanpa hambatan, dan konsolidasi data operasional menjadi laporan cerdas.

Sederhanakan perluasan SAP procurement Anda tanpa risiko mengubah core bersama Mekari Officeless.