Templat data Purchase to Pay - Purchase Order Anda
Templat data Purchase to Pay - Purchase Order Anda
- Atribut data yang disarankan
- Aktivitas proses utama
- Langkah ekstraksi data Coupa
Atribut Purchase to Pay - Purchase Order
| Nama | Deskripsi | ||
|---|---|---|---|
|
Aktivitas
ActivityName
|
Nama peristiwa atau tugas tertentu yang terjadi pada suatu waktu dalam siklus hidup purchase order. | ||
|
Deskripsi
Nama Aktivitas menjelaskan satu langkah dalam proses purchase-to-pay, seperti 'Purchase Order disetujui' atau 'Penerimaan barang dicatat'. Rangkaian aktivitas ini membentuk alur proses untuk setiap purchase order. Atribut ini menjadi dasar process mining karena digunakan untuk menyusun peta proses, menemukan variasi proses, dan menganalisis frekuensi serta urutan peristiwa. Atribut ini membantu menemukan hambatan, siklus pengerjaan ulang, dan penyimpangan dari alur proses standar. Misalnya, analisis terhadap rangkaian aktivitas 'Purchase Order diubah' dapat mengungkap ketidakefisienan dalam akurasi pesanan.
Mengapa ini penting
Atribut ini menentukan langkah-langkah dalam proses, sehingga alur proses dapat divisualisasikan dan hambatan, pengerjaan ulang, serta penyimpangan dapat ditemukan.
Sumber data
Diambil dari log peristiwa, jejak audit, atau catatan perubahan status yang terkait dengan objek Purchase Order di Coupa.
Contoh
Permintaan pembelian disetujuiPurchase Order diajukanPenerimaan barang dicatatFaktur untuk PO diterima
|
|||
|
Purchase Order
PurchaseOrderNumber
|
Pengenal unik untuk purchase order yang berfungsi sebagai ID kasus utama dalam proses. | ||
|
Deskripsi
Nomor Purchase Order adalah ID kasus utama yang menghubungkan semua aktivitas, mulai dari permintaan awal hingga konfirmasi akhir penerimaan barang atau jasa. Setiap Nomor Purchase Order yang unik mewakili satu kasus proses pengadaan. Dalam analisis process mining, atribut ini penting untuk menelusuri perjalanan setiap pembelian dari awal hingga akhir. Analis dapat menggunakannya untuk memvisualisasikan peta proses, menemukan variasi, dan menghitung KPI di tingkat kasus, seperti total waktu siklus pesanan. Semua peristiwa dan data terkait dikelompokkan berdasarkan ID ini untuk membentuk gambaran proses yang utuh.
Mengapa ini penting
Atribut ini penting untuk melacak seluruh siklus hidup setiap pembelian dan menyusun kembali tiap kasus proses agar dapat dianalisis secara terperinci.
Sumber data
Ini adalah kolom kunci utama standar pada objek Purchase Order di Coupa.
Contoh
PO-2023-00123PO-2023-00456PO-2023-00789
|
|||
|
Waktu mulai
EventTime
|
Timestamp tepat yang menunjukkan kapan suatu aktivitas atau peristiwa terjadi. | ||
|
Deskripsi
Waktu Peristiwa mencatat tanggal dan waktu saat aktivitas tertentu dilakukan. Setiap aktivitas dalam proses memiliki timestamp yang menandai waktu terjadinya. Atribut ini penting untuk semua analisis berbasis waktu dalam process mining. Atribut ini digunakan untuk menghitung waktu siklus antaraktivitas, mengukur durasi proses, dan menemukan keterlambatan. Contohnya, selisih waktu antara timestamp 'Draf Purchase Order dibuat' dan 'Purchase Order disetujui' digunakan untuk menghitung KPI Waktu Siklus Persetujuan PO.
Mengapa ini penting
Atribut ini memberikan konteks waktu untuk setiap peristiwa, yang diperlukan untuk menghitung waktu siklus, menganalisis kinerja, dan menemukan hambatan.
Sumber data
Tersedia di log peristiwa atau jejak audit Coupa, biasanya terkait dengan setiap perubahan status atau tindakan pada purchase order.
Contoh
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Timestamp yang menunjukkan kapan terakhir kali data proses ini diperbarui. | ||
|
Deskripsi
Atribut ini mencatat kapan kumpulan data terakhir diperbarui dari sistem sumber. Ini adalah kolom metadata yang berlaku untuk seluruh kumpulan data, bukan untuk setiap peristiwa. Di dashboard analitik, timestamp ini penting agar pengguna tahu seberapa baru data yang mereka lihat. Informasi ini membantu memastikan bahwa wawasan didasarkan pada data terbaru dan memberi gambaran tentang kemutakhiran data. Biasanya, timestamp ini ditampilkan dengan jelas di dashboard.
Mengapa ini penting
Atribut ini memberi tahu pengguna seberapa mutakhir data, sehingga mereka memahami kapan analisis proses dan KPI terakhir diperbarui.
Sumber data
Timestamp ini dibuat dan disimpan oleh pipeline ekstraksi dan pemuatan data (ETL) saat dijalankan.
Contoh
2023-11-01T05:00:00Z
|
|||
|
Sistem sumber
SourceSystem
|
Sistem tempat data proses diambil. | ||
|
Deskripsi
Atribut ini menunjukkan sistem informasi asal tempat data peristiwa dicatat. Untuk proses ini, nilainya selalu 'Coupa'. Di lingkungan perusahaan yang menggunakan beberapa sistem, misalnya Coupa untuk pengadaan dan ERP lain untuk penagihan, atribut ini membantu membedakan sumber data. Atribut ini memperjelas asal-usul data dan dapat digunakan untuk memfilter analisis berdasarkan sistem tertentu.
Mengapa ini penting
Atribut ini memberikan konteks penting tentang asal data, memastikan data dapat ditelusuri, dan mendukung tata kelola data yang tepat, terutama saat menggunakan beberapa sistem.
Sumber data
Nilai statis ini biasanya ditambahkan saat proses ekstraksi dan transformasi data untuk memberi label pada kumpulan data.
Contoh
Coupa
|
|||
|
Departemen
Department
|
Departemen atau pusat biaya yang membebankan biaya pesanan pembelian. | ||
|
Deskripsi
Atribut Departemen menunjukkan unit organisasi yang mengajukan pembelian atau menanggung biayanya. Atribut ini biasanya terkait dengan pemohon atau informasi pusat biaya pada baris pesanan pembelian. Dimensi ini penting untuk mengelompokkan analisis proses dan KPI. Manajer dapat membandingkan efisiensi proses, kepatuhan, dan pola belanja di berbagai bagian organisasi. Contohnya, dashboard 'Analisis Belanja berdasarkan Kategori Pembelian' menggunakan Departemen untuk menunjukkan cara tiap unit bisnis membelanjakan anggarannya.
Mengapa ini penting
Analisis proses dan belanja dapat difilter dan dibandingkan antarunit bisnis untuk melihat perbedaan efisiensi dan kepatuhan.
Sumber data
Tersedia di bagian header atau baris pesanan pembelian di Coupa, dan biasanya terkait dengan pusat biaya atau unit organisasi.
Contoh
PemasaranTeknologi InformasiOperasionalKeuangan
|
|||
|
Kategori Pembelian
PurchaseCategory
|
Klasifikasi barang atau jasa yang dibeli, seperti perangkat keras TI atau jasa profesional. | ||
|
Deskripsi
Kategori Pembelian, yang juga dikenal sebagai Komoditas atau Grup Material, mengelompokkan pembelian sejenis. Data terstruktur ini memungkinkan analisis belanja dan proses pengadaan secara sistematis. Dalam process mining, atribut ini berguna untuk memfilter dan mengelompokkan data. Dashboard 'Analisis Belanja berdasarkan Kategori Pembelian' menggunakannya untuk merinci pola belanja. Atribut ini juga dapat menunjukkan apakah kategori tertentu, seperti jasa yang kompleks, memiliki waktu siklus lebih lama atau tingkat perubahan lebih tinggi daripada kategori lain, seperti perlengkapan kantor standar.
Mengapa ini penting
Memungkinkan analisis belanja dan proses berdasarkan kategori, sehingga Anda dapat mengenali pola pengadaan, bernegosiasi dengan vendor, dan menyesuaikan kontrol proses.
Sumber data
Biasanya terdapat pada tingkat baris pesanan pembelian di Coupa dan sering terkait dengan kode komoditas atau katalog pembelian.
Contoh
Perangkat Keras TIPerlengkapan KantorJasa ProfesionalMateri Pemasaran
|
|||
|
Nama vendor
VendorName
|
Nama pemasok atau vendor tempat barang atau jasa dibeli. | ||
|
Deskripsi
Nama Vendor menunjukkan pihak eksternal yang memasok barang dalam pesanan pembelian. Informasi ini menjadi dasar analisis pengadaan. Analisis kinerja proses berdasarkan vendor penting untuk mengelola hubungan dengan pemasok. Analisis ini membantu mengevaluasi 'Kinerja Waktu Tunggu Pemasok', menemukan keterlambatan dalam 'Keterlambatan Proses Penerimaan Barang', dan menilai kualitas pemasok melalui 'Tingkat Pengembalian Barang'. Atribut ini juga penting untuk menghitung KPI 'Rasio Belanja dari Vendor Nonpilihan'.
Mengapa ini penting
Mendukung analisis kinerja pemasok untuk membantu memilih pemasok, menegosiasikan persyaratan yang lebih baik, serta mengenali vendor berkinerja tinggi maupun rendah.
Sumber data
Kolom standar di bagian header pesanan pembelian Coupa yang terkait dengan Data Induk Pemasok.
Contoh
Global Office SuppliesTech Solutions Inc.Advanced Industrial PartsCreative Marketing Agency
|
|||
|
Pengguna
User
|
ID atau nama pengguna yang melakukan aktivitas, seperti pemberi persetujuan atau pemohon. | ||
|
Deskripsi
Atribut ini menunjukkan orang yang bertanggung jawab menjalankan peristiwa tertentu dalam proses. Orang tersebut bisa jadi penyusun draf pesanan, manajer yang menyetujuinya, atau petugas yang mencatat penerimaan barang. Analisis kinerja berdasarkan pengguna membantu menemukan kebutuhan pelatihan, pengguna berkinerja tinggi, dan pembagian beban kerja. Misalnya, dashboard 'Kinerja Waktu Siklus Persetujuan PO' menggunakan atribut ini untuk menguraikan waktu persetujuan berdasarkan pemberi persetujuan, sehingga terlihat siapa yang mungkin menjadi hambatan dalam proses.
Mengapa ini penting
Atribut ini memungkinkan analisis kinerja proses berdasarkan individu atau peran, sehingga hambatan, kebutuhan pelatihan, dan masalah alokasi sumber daya dapat ditemukan.
Sumber data
Terkait dengan setiap peristiwa dalam jejak audit atau log riwayat Purchase Order di Coupa. Kolom seperti 'Created By', 'Approved By', atau 'Updated By' sering menjadi sumbernya.
Contoh
j.doea.smithm.jones
|
|||
|
Total Nilai Pesanan
TotalOrderAmount
|
Nilai total pesanan pembelian. | ||
|
Deskripsi
Atribut ini menunjukkan total biaya semua barang dan jasa yang tercantum dalam pesanan pembelian, dalam mata uang tertentu. Atribut ini berlaku untuk seluruh pesanan. Data keuangan ini penting untuk analisis belanja dan menentukan prioritas perbaikan proses. Pesanan bernilai tinggi mungkin perlu ditinjau lebih cermat atau melalui jalur persetujuan yang berbeda. Data ini digunakan langsung dalam dashboard 'Analisis Belanja berdasarkan Kategori Pembelian' dan menjadi komponen untuk menghitung KPI 'Rasio Belanja dari Vendor Nonpilihan'.
Mengapa ini penting
Memberikan konteks keuangan untuk setiap pembelian, sehingga Anda dapat menganalisis belanja, memprioritaskan pesanan bernilai tinggi, dan menilai dampak keuangannya.
Sumber data
Tersedia di bagian header pesanan pembelian Coupa, biasanya dengan nama 'Total' atau 'Grand Total'.
Contoh
1500.00250.7512500.50
|
|||
|
Alasan Penolakan
RejectionReason
|
Alasan yang diberikan saat permintaan pembelian atau pesanan pembelian ditolak pada tahap persetujuan. | ||
|
Deskripsi
Saat pemberi persetujuan menolak pesanan pembelian, biasanya mereka menyertakan alasannya. Atribut ini mencatat penjelasan tersebut, misalnya 'Kode anggaran salah' atau 'Melebihi batas belanja'. Analisis alasan penolakan memberi gambaran langsung tentang penyebab utama pengerjaan ulang dan kegagalan proses. Data kualitatif ini dapat digunakan untuk menemukan kesalahan umum dalam proses permintaan, lalu menentukan pelatihan atau perbaikan sistem yang tepat agar penolakan tidak terulang dan tingkat persetujuan pada pengajuan pertama meningkat.
Mengapa ini penting
Memberikan informasi langsung yang dapat ditindaklanjuti tentang alasan pesanan pembelian ditolak, sehingga penyebab utama pengerjaan ulang dan keterlambatan proses dapat diatasi.
Sumber data
Biasanya dicatat di kolom komentar atau catatan yang terkait dengan aktivitas 'Pesanan Pembelian Ditolak' atau 'Permintaan Pembelian Ditolak' dalam alur kerja persetujuan Coupa.
Contoh
Permintaan duplikatAnggaran belum disetujuiVendor yang dipilih salah
|
|||
|
Alasan Perubahan
ChangeReason
|
Alasan perubahan pada pesanan pembelian setelah pertama kali dibuat. | ||
|
Deskripsi
Atribut ini mencatat alasan perubahan pesanan pembelian, misalnya 'Jumlah diperbarui' atau 'Koreksi harga'. Informasi ini sering dicatat dalam jejak audit saat pengguna melakukan aktivitas 'Pesanan Pembelian Diubah'. Memahami alasan perubahan pesanan penting untuk dashboard 'Analisis Perubahan Pesanan Pembelian'. Informasi ini membantu membedakan perubahan yang tidak dapat dihindari, seperti masalah stok vendor, dari perubahan yang bisa dicegah, seperti kesalahan saat memasukkan data awal. Dengan begitu, Anda dapat meningkatkan ketepatan pesanan dan menurunkan KPI 'Tingkat Perubahan Pesanan Pembelian'.
Mengapa ini penting
Menjelaskan penyebab utama perubahan PO, sehingga tindakan perbaikan dapat diarahkan untuk meningkatkan ketepatan pesanan sejak awal dan mengurangi pengerjaan ulang.
Sumber data
Sering ditemukan dalam log audit atau komentar yang terkait dengan peristiwa perubahan Pesanan Pembelian di Coupa.
Contoh
Harga diperbarui oleh vendorTanggal pengiriman disesuaikanKode barang dikoreksi
|
|||
|
Apakah Disetujui pada Pengajuan Pertama
IsFirstPassApproval
|
Penanda hasil perhitungan yang bernilai true jika PO disetujui tanpa perubahan setelah dibuat sebagai draf. | ||
|
Deskripsi
Penanda boolean ini bernilai true jika proses PO dari 'Draf Pesanan Pembelian' hingga 'Pesanan Pembelian Disetujui' tidak mencakup aktivitas 'Pesanan Pembelian Diubah' atau 'Pesanan Pembelian Ditolak'. Atribut ini mengukur langsung KPI 'Tingkat Persetujuan PO pada Pengajuan Pertama'. Tingkat yang tinggi menunjukkan proses awal yang efisien dan akurat. Analisis kasus dengan nilai false dapat membantu menemukan penyebab pengerjaan ulang dan meningkatkan kualitas data pesanan pembelian sejak awal.
Mengapa ini penting
Mengukur langsung efisiensi proses pembuatan dan persetujuan awal, serta menunjukkan jumlah pesanan yang selesai tanpa pengerjaan ulang.
Sumber data
Dihitung saat transformasi data dengan menganalisis urutan peristiwa untuk setiap PurchaseOrderNumber.
Contoh
truefalse
|
|||
|
Apakah Pengerjaan Ulang
IsRework
|
Penanda hasil perhitungan yang menunjukkan apakah pesanan pembelian mengalami perubahan. | ||
|
Deskripsi
Penanda boolean ini bernilai true untuk setiap pesanan pembelian yang memiliki setidaknya satu peristiwa 'Pesanan Pembelian Diubah' dalam riwayatnya. Atribut ini berlaku untuk seluruh kasus dan diturunkan dari log peristiwa. Atribut ini menyederhanakan penghitungan KPI seperti 'Tingkat Perubahan Pesanan Pembelian'. Anda dapat memfilter dan mengelompokkan data dengan mudah untuk membandingkan proses pesanan yang mengalami pengerjaan ulang dengan yang tidak. Dengan begitu, dampak perubahan terhadap waktu siklus dan biaya dapat diukur. Atribut ini merupakan komponen utama dashboard 'Analisis Perubahan Pesanan Pembelian'.
Mengapa ini penting
Memudahkan analisis pengerjaan ulang dengan memfilter dan menggabungkan data semua pesanan pembelian yang pernah diubah.
Sumber data
Dihitung saat transformasi data dengan memeriksa apakah ada aktivitas 'Pesanan Pembelian Diubah' untuk setiap PurchaseOrderNumber.
Contoh
truefalse
|
|||
|
Apakah Pengiriman Tepat Waktu
IsDeliveryOnTime
|
Penanda hasil perhitungan yang menunjukkan apakah barang diterima pada atau sebelum tanggal pengiriman yang diminta. | ||
|
Deskripsi
Atribut boolean ini dihitung dengan membandingkan stempel waktu peristiwa 'Penerimaan Barang Dicatat' dengan 'RequestedDeliveryDate'. Nilainya true jika tanggal penerimaan sama dengan atau lebih awal dari tanggal yang diminta. Penanda ini mendukung KPI 'Ketepatan Pemasok Memenuhi Tanggal Pengiriman' dan dashboard 'Variasi Tanggal Pengiriman dan Pengembalian'. Penanda ini memberikan hasil biner yang jelas dan mudah dirangkum serta divisualisasikan, sehingga masalah kinerja vendor atau proses penerimaan internal dapat segera diketahui.
Mengapa ini penting
Memberikan ukuran kinerja pengiriman yang jelas dalam bentuk biner, sehingga penghitungan KPI ketepatan waktu dan analisis tren menjadi lebih mudah.
Sumber data
Dihitung saat transformasi data dengan membandingkan 'RequestedDeliveryDate' dengan stempel waktu aktivitas 'Penerimaan Barang Dicatat'.
Contoh
truefalse
|
|||
|
Apakah Vendor Pilihan
IsPreferredVendor
|
Penanda boolean yang menunjukkan apakah pembelian dilakukan dari vendor pilihan atau vendor strategis. | ||
|
Deskripsi
Penanda ini menunjukkan apakah vendor pada pesanan pembelian termasuk dalam daftar pemasok strategis yang telah disetujui sebelumnya. Status ini biasanya ditentukan dengan mencocokkan nama atau ID vendor dengan daftar induk vendor pilihan. Atribut ini penting untuk inisiatif pengadaan strategis dan pengelolaan belanja. Atribut ini digunakan untuk menghitung KPI 'Rasio Belanja dari Vendor Nonpilihan', yang membantu organisasi memantau dan mengendalikan pembelian di luar kebijakan serta mengonsolidasikan belanja dengan mitra utama agar dapat memanfaatkan diskon volume dan persyaratan yang lebih baik.
Mengapa ini penting
Membantu memantau kepatuhan terhadap kebijakan pengadaan dan sasaran pengadaan strategis dengan melacak belanja dari pemasok pilihan dan nonpilihan.
Sumber data
Kolom ini sering kali bukan kolom standar di Coupa. Nilainya ditentukan dengan membandingkan Vendor ID pada PO dengan daftar vendor pilihan dari sumber eksternal.
Contoh
truefalse
|
|||
|
Lokasi Penerimaan
ReceivingLocation
|
Lokasi fisik, seperti gudang atau kantor, tempat barang akan dikirim. | ||
|
Deskripsi
Lokasi Penerimaan menunjukkan tujuan pengiriman barang yang dipesan melalui PO. Lokasinya dapat berupa gudang, pabrik, atau alamat kantor tertentu. Atribut ini digunakan untuk menganalisis kinerja logistik dan penerimaan di berbagai lokasi. Dashboard 'Keterlambatan Proses Penerimaan Barang' dapat difilter berdasarkan atribut ini untuk mengetahui apakah lokasi tertentu lebih lambat memproses kiriman masuk. Hasilnya dapat membantu menemukan kendala operasional atau keterbatasan sumber daya di lokasi tersebut.
Mengapa ini penting
Memungkinkan analisis proses penerimaan berdasarkan lokasi dan menunjukkan perbedaan kinerja antar gudang, pabrik, atau kantor.
Sumber data
Informasi ini tercantum dalam alamat 'Ship-To' pada Pesanan Pembelian di Coupa.
Contoh
Gudang A - ChicagoGedung 5 - Kantor LondonPabrik Frankfurt
|
|||
|
Mata Uang
Currency
|
Kode mata uang untuk nilai uang pada pesanan pembelian. | ||
|
Deskripsi
Atribut ini menunjukkan mata uang, seperti USD, EUR, atau GBP, yang digunakan untuk menyatakan Total Nilai Pesanan. Informasi ini penting agar data keuangan organisasi global dapat ditafsirkan dengan benar. Bagi perusahaan multinasional, analisis belanja tanpa memperhitungkan mata uang dapat menyesatkan. Atribut ini memungkinkan konversi mata uang yang tepat dan pelaporan keuangan yang konsisten di dashboard, sehingga nilai dapat dibandingkan secara setara.
Mengapa ini penting
Mendukung analisis dan pelaporan keuangan yang akurat di lingkungan multinasional dengan menyediakan informasi yang diperlukan untuk konversi mata uang.
Sumber data
Kolom standar di bagian header pesanan pembelian Coupa.
Contoh
USDEURGBPJPY
|
|||
|
Nama Pemohon
RequesterName
|
Nama orang yang pertama kali meminta barang atau jasa. | ||
|
Deskripsi
Atribut ini menunjukkan karyawan yang membuat permintaan pembelian hingga menghasilkan pesanan pembelian. Pemohon adalah pengguna bisnis yang membutuhkan barang atau jasa, dan bisa berbeda dari pembeli atau pemberi persetujuan. Analisis perilaku proses berdasarkan pemohon membantu mengenali pola yang terkait dengan pengguna atau departemen tertentu. Dashboard 'Analisis Perubahan Pesanan Pembelian' menggunakan data ini untuk melihat apakah pemohon tertentu lebih sering mengubah pesanan. Hal ini dapat menunjukkan perlunya pelatihan yang lebih baik tentang persyaratan spesifikasi.
Mengapa ini penting
Membantu mengenali asal kebutuhan bisnis suatu pembelian, sehingga perilaku dan ketepatan pengadaan dapat dianalisis berdasarkan pemohon.
Sumber data
Informasi ini biasanya tersimpan di Permintaan Pembelian asal dan diteruskan ke Pesanan Pembelian di Coupa.
Contoh
Alice CooperBob DylanCharlie Parker
|
|||
|
Nomor Permintaan Pembelian
PurchaseRequisitionNumber
|
Pengenal unik untuk permintaan pembelian yang dibuat sebelum pesanan pembelian. | ||
|
Deskripsi
Atribut ini menghubungkan pesanan pembelian dengan permintaan pembelian asalnya. Satu permintaan dapat menghasilkan satu atau beberapa pesanan pembelian. Hubungan ini penting untuk menganalisis waktu siklus 'Permintaan hingga Pesanan'. Dengan menghubungkan peristiwa pembuatan permintaan dengan peristiwa pembuatan dan pengiriman pesanan pembelian, organisasi dapat mengukur efisiensi seluruh proses awal pengadaan, dari permintaan hingga pemenuhan.
Mengapa ini penting
Menghubungkan tahap permintaan dan pemesanan, sehingga waktu siklus permintaan hingga pesanan dan tingkat konversinya dapat dianalisis.
Sumber data
Biasanya berupa kolom referensi pada baris pesanan pembelian di Coupa yang mengarah ke permintaan asal.
Contoh
PR-2023-00098PR-2023-00152PR-2023-00341
|
|||
|
Tanggal Pengiriman yang Diminta
RequestedDeliveryDate
|
Tanggal yang diminta pemohon untuk pengiriman barang atau jasa. | ||
|
Deskripsi
Atribut ini menunjukkan tanggal target pengiriman yang ditentukan pengguna bisnis saat mengajukan permintaan. Tanggal tersebut mencerminkan harapan bisnis mengenai kapan pesanan harus dipenuhi. Tanggal ini menjadi tolok ukur penting untuk mengukur kinerja pemasok dan tim internal. Tanggal ini digunakan langsung untuk menghitung KPI 'Ketepatan Pemasok Memenuhi Tanggal Pengiriman' dengan membandingkannya dengan tanggal aktual 'Penerimaan Barang Dicatat'. Dashboard 'Variasi Tanggal Pengiriman dan Pengembalian' menampilkan selisih antara tanggal yang diminta dan tanggal pengiriman aktual, sehingga Anda dapat mengelola ekspektasi dan meningkatkan perkiraan.
Mengapa ini penting
Menjadi tolok ukur utama untuk mengukur ketepatan waktu pengiriman vendor dan efisiensi proses penerimaan internal.
Sumber data
Kolom standar pada baris pesanan pembelian di Coupa.
Contoh
2023-11-152023-12-012024-01-10
|
|||
Aktivitas Purchase to Pay - Purchase Order
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Penerimaan barang dicatat
|
Peristiwa ini merupakan konfirmasi resmi bahwa barang telah diterima, diperiksa, dan disetujui. Catatan inventaris diperbarui dan kewajiban pemasok untuk pengiriman ini dinyatakan terpenuhi. | ||
|
Mengapa ini penting
Tonggak penting ini menandai berakhirnya waktu tunggu pemasok dan digunakan untuk mengukur ketepatan tanggal pengiriman. Keterlambatan pencatatan penerimaan dapat mengaburkan kondisi inventaris yang sebenarnya.
Sumber data
Transaksi utama ini dicatat pada objek Receipt di Coupa. Peristiwa diambil dari timestamp saat status penerimaan berubah menjadi 'Posted' atau 'Received'.
Pengumpulan data
Dicatat saat transaksi penerimaan barang diselesaikan di sistem.
Jenis peristiwa
explicit
|
|||
|
Permintaan pembelian dibuat
|
Aktivitas ini menandai pembuatan permintaan pembelian, yaitu permintaan resmi atas barang atau jasa sebelum purchase order dibuat. Di Coupa, peristiwa ini tercatat secara eksplisit saat pengguna menyimpan dan mengirim dokumen permintaan baru. | ||
|
Mengapa ini penting
Sebagai titik awal proses pengadaan, aktivitas ini penting untuk mengukur seluruh waktu siklus dari permintaan hingga pemesanan dan memahami efisiensi proses di tahap awal.
Sumber data
Peristiwa ini sesuai dengan catatan pembuatan pada objek atau tabel Purchase Requisitions di Coupa. Timestamp-nya dapat ditemukan di kolom 'created_at' atau kolom tanggal pembuatan lain yang dibuat oleh sistem.
Pengumpulan data
Dicatat langsung saat catatan permintaan baru dibuat.
Jenis peristiwa
explicit
|
|||
|
Purchase Order dibatalkan
|
Aktivitas ini menandai pembatalan purchase order sebelum prosesnya selesai. Pembatalan dapat terjadi pada berbagai tahap, misalnya jika permintaan tidak lagi berlaku atau PO dibuat karena kesalahan. | ||
|
Mengapa ini penting
Sebagai salah satu kemungkinan akhir proses, pelacakan pembatalan penting untuk memahami kegagalan proses dan menemukan alasan permintaan pembelian ditinggalkan.
Sumber data
Peristiwa ini disimpulkan dari perubahan status objek Purchase Order menjadi 'Canceled'. Timestamp perubahan status tersebut digunakan sebagai waktu peristiwa.
Pengumpulan data
Diambil dari timestamp perubahan status menjadi 'Canceled'.
Jenis peristiwa
inferred
|
|||
|
Purchase Order dikirim ke pemasok
|
Aktivitas ini menandai saat purchase order yang telah disetujui resmi dikirim kepada pemasok, misalnya melalui email atau Coupa Supplier Portal. Peristiwa ini mengubah PO dari dokumen internal menjadi komitmen eksternal. | ||
|
Mengapa ini penting
Tonggak ini mengakhiri siklus internal dari permintaan hingga pemesanan dan memulai waktu tunggu pemasok. Data ini penting untuk mengukur efisiensi internal sekaligus kinerja pemasok.
Sumber data
Sering kali disimpulkan dari perubahan status PO menjadi 'Ordered' atau 'Sent'. Coupa mungkin juga menyediakan timestamp khusus seperti 'last_exported_at' atau 'sent_to_supplier_at' pada catatan PO.
Pengumpulan data
Diambil dari timestamp perubahan status menjadi 'Ordered' atau dari kolom timestamp pengiriman khusus.
Jenis peristiwa
inferred
|
|||
|
Purchase Order disetujui
|
Tonggak ini menandakan bahwa purchase order telah menyelesaikan alur kerja persetujuan internal dan boleh diterbitkan kepada pemasok. Biasanya, ini adalah tahap persetujuan terakhir dalam proses bertahap. | ||
|
Mengapa ini penting
Tonggak ini penting untuk menghitung waktu siklus persetujuan PO dan menemukan hambatan dalam persetujuan. Ini juga menjadi titik pemeriksaan utama untuk kepatuhan.
Sumber data
Diambil dari log riwayat persetujuan Purchase Order di Coupa. Timestamp tindakan persetujuan terakhir menjadi waktu peristiwa.
Pengumpulan data
Dicatat dalam riwayat persetujuan saat pemberi persetujuan terakhir menyelesaikan tugasnya.
Jenis peristiwa
explicit
|
|||
|
Purchase Order ditutup
|
Ini adalah aktivitas terakhir yang menandakan purchase order telah selesai. PO dianggap ditutup setelah seluruh barang diterima dan seluruh faktur diproses, tanpa transaksi lanjutan yang diharapkan. | ||
|
Mengapa ini penting
Aktivitas ini secara resmi mengakhiri siklus hidup PO. Analisis waktu penutupan dapat mengungkap ketidakefisienan dalam rekonsiliasi akhir dan pencatatan.
Sumber data
Peristiwa ini disimpulkan dari perubahan status objek Purchase Order menjadi 'Closed'. Coupa sering menetapkan status ini secara otomatis berdasarkan aturan bisnis terkait toleransi penerimaan dan penagihan.
Pengumpulan data
Diambil dari timestamp perubahan status menjadi 'Closed'.
Jenis peristiwa
inferred
|
|||
|
Barang dikembalikan
|
Aktivitas ini dicatat saat barang yang sebelumnya diterima dikirim kembali kepada pemasok. Biasanya, hal ini terjadi karena masalah kualitas, kerusakan, atau pengiriman barang yang keliru. | ||
|
Mengapa ini penting
Pelacakan pengembalian penting untuk menghitung Tingkat Pengembalian Barang dan menemukan masalah kualitas pemasok atau akurasi pesanan. Tingkat pengembalian yang tinggi sering menunjukkan kegagalan proses yang merugikan.
Sumber data
Data ini diambil dari transaksi 'Return to Supplier' atau transaksi penerimaan negatif di Coupa. Timestamp transaksi tersebut menjadi waktu peristiwa.
Pengumpulan data
Dicatat saat transaksi pengembalian yang terhubung dengan PO atau penerimaan awal dibuat.
Jenis peristiwa
explicit
|
|||
|
Draf Purchase Order dibuat
|
Peristiwa ini menandai pembuatan awal dokumen Purchase Order di sistem, biasanya dari permintaan yang telah disetujui. Pada tahap ini, PO masih berupa draf internal dan belum diajukan untuk persetujuan atau dikirim ke pemasok. | ||
|
Mengapa ini penting
Aktivitas ini memulai pengukuran KPI Waktu Siklus Persetujuan PO. Ini adalah langkah resmi pertama dalam siklus hidup purchase order.
Sumber data
Peristiwa ini sesuai dengan timestamp pembuatan catatan Purchase Order di Coupa, yang biasanya tersedia di kolom seperti 'created_at'.
Pengumpulan data
Diambil dari timestamp pembuatan catatan PO yang dibuat oleh sistem.
Jenis peristiwa
explicit
|
|||
|
Faktur untuk PO diterima
|
Peristiwa ini menandai penerimaan dan pencatatan faktur pemasok yang merujuk pada purchase order. Ini menjadi awal tahap pemrosesan faktur dan pembayaran dalam siklus P2P. | ||
|
Mengapa ini penting
Meski termasuk dalam proses utang usaha (AP), menghubungkan penerimaan faktur dengan PO memberikan gambaran menyeluruh tentang siklus transaksi dan membantu menganalisis jeda antara pengiriman dan penagihan.
Sumber data
Diambil dari timestamp pembuatan dokumen Invoice di Coupa, saat faktur dicocokkan dengan nomor Purchase Order terkait.
Pengumpulan data
Dicatat saat catatan faktur yang terhubung dengan PO dibuat.
Jenis peristiwa
explicit
|
|||
|
Konfirmasi jasa dicatat
|
Untuk purchase order jasa, aktivitas ini setara dengan penerimaan barang. Aktivitas ini mengonfirmasi bahwa jasa telah diberikan sesuai ketentuan PO. | ||
|
Mengapa ini penting
Pelacakan konfirmasi jasa penting untuk mengelola pengeluaran jasa dan memastikan pembayaran hanya dilakukan untuk pekerjaan yang telah diverifikasi selesai.
Sumber data
Peristiwa ini diambil dari pembuatan atau persetujuan tanda terima jasa atau lembar entri jasa yang terhubung dengan Purchase Order di Coupa.
Pengumpulan data
Dicatat saat lembar entri jasa dibuat dan disetujui.
Jenis peristiwa
explicit
|
|||
|
Pemasok mengonfirmasi pesanan
|
Peristiwa ini menandakan bahwa pemasok telah menerima dan mengonfirmasi purchase order. Konfirmasi ini sering dicatat secara elektronik melalui portal pemasok seperti Coupa Supplier Portal (CSP). | ||
|
Mengapa ini penting
Konfirmasi pemasok memastikan bahwa pesanan sedang diproses. Hal ini meningkatkan akurasi perkiraan pengiriman dan mengurangi ketidakpastian rantai pasok.
Sumber data
Informasi ini biasanya tersedia pada Purchase Order jika pemasok menggunakan Coupa Supplier Portal untuk melakukan tindakan 'Acknowledge'. Timestamp tindakan tersebut digunakan.
Pengumpulan data
Dicatat saat pemasok melakukan tindakan 'Acknowledge' di portal pemasok.
Jenis peristiwa
explicit
|
|||
|
Pemeriksaan kualitas dilakukan
|
Peristiwa ini menandakan bahwa barang yang diterima telah menjalani dan lulus pemeriksaan kualitas. Bergantung pada proses perusahaan, pemeriksaan ini dapat dilakukan setelah penerimaan barang dicatat. | ||
|
Mengapa ini penting
Aktivitas ini penting untuk mengukur efisiensi proses kontrol kualitas. Keterlambatan pada tahap ini dapat menimbulkan hambatan antara penerimaan dan kesiapan barang untuk digunakan.
Sumber data
Data ini mungkin dicatat sebagai perubahan status pada baris barang yang diterima atau melalui objek pemeriksaan terpisah di Coupa. Ketersediaannya bergantung pada penggunaan modul kualitas atau alur kerja khusus.
Pengumpulan data
Disimpulkan dari perubahan status penerimaan atau timestamp pada catatan pemeriksaan terkait.
Jenis peristiwa
inferred
|
|||
|
Penerimaan barang dimulai
|
Aktivitas ini menandai dimulainya proses penerimaan, misalnya saat dokumen penerimaan dibuat di Coupa setelah barang tiba secara fisik. Barang belum resmi dicatat ke inventaris atau dikonfirmasi sebagai barang yang diterima. | ||
|
Mengapa ini penting
Peristiwa ini menjadi titik awal untuk mengukur KPI Waktu Pemrosesan Penerimaan Barang. Data ini membantu membedakan waktu barang menunggu di area bongkar muat dari waktu yang digunakan untuk pemrosesan di sistem.
Sumber data
Peristiwa ini dapat disimpulkan dari timestamp pembuatan dokumen penerimaan dengan status 'Draft' atau 'Pending'. Peristiwa ini terjadi sebelum penerimaan dicatat secara final.
Pengumpulan data
Diambil dari timestamp pembuatan catatan penerimaan yang belum dicatat secara final.
Jenis peristiwa
inferred
|
|||
|
Permintaan pembelian disetujui
|
Permintaan pembelian harus melalui alur kerja persetujuan sebelum dapat diubah menjadi purchase order. Peristiwa ini menandai persetujuan akhir atas permintaan, sehingga siap dipesan. | ||
|
Mengapa ini penting
Pelacakan persetujuan permintaan membantu menemukan hambatan sebelum pemesanan. Keterlambatan pada tahap ini langsung memengaruhi kecepatan penerbitan purchase order.
Sumber data
Biasanya, data ini diambil dari riwayat persetujuan objek permintaan di Coupa. Tindakan persetujuan akhir memiliki timestamp dan pengguna terkait.
Pengumpulan data
Dicatat dalam riwayat persetujuan saat pemberi persetujuan terakhir mengambil tindakan.
Jenis peristiwa
explicit
|
|||
|
Purchase Order diajukan
|
Setelah draf purchase order dibuat, dokumen tersebut secara resmi diajukan ke alur kerja persetujuan. Tindakan pengguna ini mengubah status PO dari draf menjadi menunggu persetujuan. | ||
|
Mengapa ini penting
Peristiwa ini membedakan waktu penyusunan draf dari waktu PO benar-benar menunggu persetujuan. Dengan begitu, perilaku pengguna dan serah terima proses terlihat lebih jelas.
Sumber data
Disimpulkan dari perubahan status pada objek Purchase Order, misalnya dari 'draft' menjadi 'pending approval'. Timestamp perubahan status tersebut digunakan.
Pengumpulan data
Diambil dari timestamp perubahan status menjadi 'pending approval'.
Jenis peristiwa
inferred
|
|||
|
Purchase Order ditolak
|
Aktivitas ini terjadi saat pemberi persetujuan menolak purchase order dalam alur kerja persetujuan. PO biasanya dikembalikan kepada pembuatnya untuk diperbaiki atau dibatalkan. | ||
|
Mengapa ini penting
Analisis penolakan membantu menemukan masalah kualitas data, pelanggaran kebijakan, atau kebutuhan pelatihan. Analisis ini juga menunjukkan siklus pengerjaan ulang yang menyebabkan keterlambatan proses.
Sumber data
Peristiwa ini tercatat secara eksplisit dalam log riwayat persetujuan Purchase Order di Coupa. Log akan menampilkan tindakan 'Reject' beserta timestamp-nya.
Pengumpulan data
Dicatat dalam riwayat persetujuan dengan status 'Reject'.
Jenis peristiwa
explicit
|
|||
|
Purchase Order diubah
|
Peristiwa ini mencakup setiap perubahan pada purchase order setelah draf awal dibuat. Di Coupa, perubahan biasanya dilacak melalui versi dokumen PO. | ||
|
Mengapa ini penting
Pelacakan perubahan penting untuk KPI seperti Tingkat Perubahan Purchase Order dan Tingkat PO yang Tidak Sesuai. Perubahan yang sering terjadi dapat menunjukkan proses yang tidak stabil atau permintaan awal yang kurang akurat.
Sumber data
Peristiwa ini dapat disimpulkan dengan melacak berbagai versi Purchase Order. Setiap nomor versi baru yang lebih tinggi dari versi pertama menandakan perubahan. Tanggal pembuatan versi baru menjadi timestamp peristiwa.
Pengumpulan data
Disimpulkan dari timestamp pembuatan versi PO yang baru.
Jenis peristiwa
inferred
|
|||
Panduan ekstraksi
Siap memulai?
Gunakan templat ini untuk menyiapkan data bagi process mining dan menemukan wawasan yang dapat ditindaklanjuti. Mulai optimalkan proses Purchase to Pay - Purchase Order Anda hari ini.
Optimalkan Purchase Order P2P Anda dan tingkatkan efisiensi hari ini
Kurangi waktu siklus P2P hingga 30% dan lihat hasilnya dalam waktu singkat.
Tidak perlu kartu kredit. Penyiapan hanya perlu beberapa menit.