Templat data Purchase to Pay - Requisition Anda
Templat data Purchase to Pay - Requisition Anda
- Atribut yang disarankan untuk analisis menyeluruh
- Aktivitas proses utama yang perlu dilacak
- Panduan praktis untuk mengekstrak data
Atribut Purchase to Pay - Requisition
| Nama | Deskripsi | ||
|---|---|---|---|
|
ID Permintaan Pembelian
PurchaseRequisitionId
|
Pengenal unik untuk setiap permintaan pembelian, yang berfungsi sebagai ID kasus utama dalam proses. | ||
|
Deskripsi
ID Permintaan Pembelian menjadi kunci utama yang menghubungkan semua aktivitas terkait satu permintaan barang atau jasa. Setiap permintaan mendapat ID unik saat dibuat, dan ID ini tetap sama sepanjang siklusnya. Dengan ID tersebut, Anda dapat melacak permintaan dari awal pembuatan dan pengajuan, melalui setiap langkah persetujuan atau penolakan, hingga proses pengadaan dan penutupan. Dalam process mining, setiap entri log peristiwa dikaitkan dengan ID ini, sehingga seluruh perjalanan setiap kasus dapat direkonstruksi.
Mengapa ini penting
ID Kasus utama ini menghubungkan semua langkah proses, sehingga Anda dapat menganalisis seluruh siklus permintaan pembelian dari awal hingga akhir.
Sumber data
Kolom kunci utama ini terdapat di modul Requisitions Coupa dan ekspor data terkait.
Contoh
PR-102934PR-102935PR-102936
|
|||
|
Nama Aktivitas
ActivityName
|
Nama aktivitas bisnis atau peristiwa tertentu yang terjadi pada waktu tertentu dalam proses permintaan pembelian. | ||
|
Deskripsi
Atribut ini mencatat setiap langkah dalam siklus permintaan pembelian. Contohnya mencakup 'Permintaan Pembelian Dibuat', 'Langkah Persetujuan Disetujui', dan 'Permintaan Pembelian Masuk ke Proses Pengadaan'. Setiap aktivitas menandai pencapaian atau tindakan tertentu pada permintaan pembelian. Menganalisis urutan dan frekuensi aktivitas ini merupakan dasar process mining. Analisis tersebut membantu memvisualisasikan peta proses, menemukan jalur yang umum, dan mendeteksi penyimpangan dari prosedur standar.
Mengapa ini penting
Atribut ini menentukan langkah-langkah dalam peta proses, sehingga alur permintaan pembelian dapat divisualisasikan dan dianalisis.
Sumber data
Biasanya, data ini berasal dari log peristiwa, catatan perubahan status, atau jejak audit di sistem Coupa. Anda mungkin perlu memetakan kolom status atau kode tindakan.
Contoh
Permintaan pembelian dibuatPermintaan pembelian diajukanTahap persetujuan disetujuiPermintaan Pembelian DitolakPesanan Pembelian Dibuat
|
|||
|
Waktu Peristiwa
EventTime
|
Tanggal dan waktu tepat saat aktivitas terjadi. | ||
|
Deskripsi
Waktu Peristiwa, atau stempel waktu, mencatat saat tepat suatu aktivitas pada permintaan pembelian direkam. Data ini penting untuk mengurutkan peristiwa secara kronologis dan menyusun alur proses. Semua analisis berbasis waktu mengandalkan data ini, termasuk penghitungan waktu siklus, penemuan hambatan dengan mengukur durasi antaraktivitas, dan pemahaman kinerja proses dari waktu ke waktu. Stempel waktu yang akurat dan terperinci diperlukan agar analisis proses bermakna.
Mengapa ini penting
Stempel waktu ini penting untuk mengurutkan peristiwa dengan benar dan menghitung semua metrik durasi, seperti waktu siklus dan hambatan.
Sumber data
Informasi ini tercatat dalam jejak audit atau riwayat setiap permintaan pembelian di Coupa, biasanya pada kolom 'created_at' atau 'updated_at' untuk setiap tindakan.
Contoh
2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
|
|||
|
Pembaruan Data Terakhir
LastDataUpdate
|
Stempel waktu yang menunjukkan kapan terakhir kali data diperbarui dari sistem sumber. | ||
|
Deskripsi
Atribut ini mencatat tanggal dan waktu ekstraksi data terbaru dari Coupa. Informasi ini menunjukkan seberapa baru data yang dianalisis. Dengan mengetahui kapan data diperbarui, pengguna dapat memahami apakah wawasan yang diperoleh mencerminkan kondisi operasional saat ini atau kondisi sebelumnya. Hal ini sangat penting untuk dasbor yang memantau operasional yang sedang berlangsung.
Mengapa ini penting
Memberi tahu pengguna seberapa baru data yang digunakan, sehingga mereka memahami rentang waktu analisis dan dapat mengambil keputusan berdasarkan informasi terkini.
Sumber data
Stempel waktu ini dibuat dan ditambahkan oleh pipeline data atau alat ETL setelah proses ekstraksi data berhasil.
Contoh
2024-05-21T02:00:00Z
|
|||
|
Sistem Sumber
SourceSystem
|
Menunjukkan sistem sumber tempat data diekstrak. | ||
|
Deskripsi
Atribut ini menunjukkan sistem pencatatan asal data proses. Untuk analisis ini, nilainya selalu 'Coupa'. Sebaiknya sertakan kolom ini, terutama jika data berasal dari beberapa sistem. Kolom ini memberikan konteks penting tentang asal-usul data dan membantu mengelola tata kelola serta aturan kualitas data.
Mengapa ini penting
Menjelaskan asal-usul data dengan jelas. Informasi ini penting untuk tata kelola data dan saat menggabungkan data dari beberapa sistem perusahaan.
Sumber data
Biasanya, nilai tetap ini ditambahkan saat proses ekstraksi dan transformasi data untuk menandai asal set data.
Contoh
Coupa
|
|||
|
Departemen
Department
|
Departemen bisnis atau pusat biaya yang dibebankan untuk permintaan pembelian. | ||
|
Deskripsi
Atribut Departemen menghubungkan setiap permintaan pembelian dengan unit organisasi atau pusat biaya tertentu. Atribut ini penting untuk analisis perbandingan. Anda dapat memfilter dan mengelompokkan dasbor serta KPI berdasarkan departemen, lalu membandingkan waktu siklus persetujuan, tingkat penolakan, dan kepatuhan di berbagai bagian organisasi. Dengan begitu, masalah atau praktik baik di departemen tertentu lebih mudah ditemukan.
Mengapa ini penting
Memungkinkan perbandingan KPI proses, seperti waktu siklus dan tingkat penolakan, antarunit bisnis untuk menemukan area yang perlu diperbaiki.
Sumber data
Kolom standar pada objek Requisition di Coupa ini biasanya dikaitkan dengan profil pengguna pemohon atau dicantumkan pada item baris permintaan.
Contoh
PemasaranOperasional TIFasilitasRiset dan Pengembangan
|
|||
|
Jumlah Total
TotalAmount
|
Nilai total uang dari permintaan pembelian. | ||
|
Deskripsi
Atribut ini menunjukkan total biaya semua barang dan jasa yang diminta. Nilai ini penting dalam analisis proses karena sering memengaruhi kompleksitas alur persetujuan. Permintaan bernilai tinggi biasanya memerlukan lebih banyak langkah persetujuan. Menganalisis metrik proses berdasarkan rentang nilai, misalnya <$1.000 atau $1.000-$10.000, dapat menunjukkan bagaimana proses menangani permintaan dengan nilai finansial yang berbeda.
Mengapa ini penting
Membantu menganalisis perbedaan proses untuk permintaan dengan nilai yang berbeda, karena jumlah yang lebih besar sering memicu alur persetujuan yang lebih rumit.
Sumber data
Kolom standar pada header objek Requisition di Coupa ini biasanya bernama 'total' atau 'total_amount'.
Contoh
500.0012550.7599.99
|
|||
|
Pemberi Persetujuan
Approver
|
Pengguna atau kelompok yang bertanggung jawab atas aktivitas persetujuan. | ||
|
Deskripsi
Atribut ini menunjukkan orang atau kelompok persetujuan yang ditugaskan pada suatu langkah. Atribut ini terisi untuk aktivitas seperti 'Langkah Persetujuan Dimulai', 'Langkah Persetujuan Disetujui', dan 'Langkah Persetujuan Ditolak'. Analisis berdasarkan pemberi persetujuan penting untuk menyusun dasbor 'Kinerja dan Beban Kerja Pemberi Persetujuan'. Analisis ini membantu mengukur waktu persetujuan setiap orang, menemukan hambatan yang disebabkan pemberi persetujuan tertentu, dan menilai pembagian beban kerja.
Mengapa ini penting
Penting untuk menganalisis kinerja pemberi persetujuan, menyeimbangkan beban kerja, dan menemukan hambatan yang terkait dengan orang atau kelompok persetujuan tertentu.
Sumber data
Informasi ini terdapat dalam detail rantai persetujuan yang terkait dengan setiap permintaan pembelian di Coupa. Anda mungkin perlu menggabungkannya dengan data User.
Contoh
David MillerPemberi Persetujuan Keuangan L2Susan Chen
|
|||
|
Pemohon
Requester
|
Karyawan yang membuat dan mengajukan permintaan pembelian. | ||
|
Deskripsi
Atribut ini menunjukkan orang yang mengajukan permintaan. Dengan menganalisis data berdasarkan pemohon, Anda dapat menemukan pola pada pengguna tertentu, seperti permintaan yang sering diubah atau ditolak. Pola tersebut mungkin menunjukkan perlunya pelatihan tambahan. Atribut ini juga digunakan untuk menganalisis volume permintaan dan perilaku proses berdasarkan pengguna atau kelompok pengguna.
Mengapa ini penting
Memungkinkan analisis perilaku proses berdasarkan pengguna, sehingga Anda dapat mengetahui kebutuhan pelatihan dan memahami cara setiap orang menjalani proses.
Sumber data
Tersedia sebagai kolom standar pada objek Requisition di Coupa. Kolom ini biasanya ditautkan ke objek User dan bernama 'requester' atau 'created_by'.
Contoh
Alice JohnsonBob SmithCharlie Brown
|
|||
|
Status Permintaan Pembelian
RequisitionStatus
|
Status permintaan pembelian saat ini atau status akhirnya. | ||
|
Deskripsi
Atribut ini menunjukkan kondisi keseluruhan permintaan pembelian saat data diekstrak atau hasil akhirnya. Status yang umum mencakup 'Menunggu Persetujuan', 'Disetujui', 'Ditolak', 'Ditarik', dan 'Ditutup'. Status ini menjadi dimensi penting untuk pemfilteran dan analisis. Gunakan untuk menghitung tingkat persetujuan dan penolakan, memantau beban kerja permintaan yang masih terbuka, serta memahami hasil akhir permintaan.
Mengapa ini penting
Penting untuk memahami hasil permintaan pembelian, menghitung tingkat persetujuan dan penolakan, serta memantau kondisi permintaan yang masih diproses.
Sumber data
Kolom standar pada objek Purchase Requisition di Coupa ini biasanya bernama 'status' atau 'state'.
Contoh
Menunggu PersetujuanDisetujuiDitolakDitarikDitutup
|
|||
|
Alasan Penolakan
RejectionReason
|
Alasan yang diberikan pemberi persetujuan saat menolak permintaan pembelian atau langkah persetujuan. | ||
|
Deskripsi
Saat menolak permintaan pembelian, pemberi persetujuan biasanya menjelaskan alasannya. Atribut ini menyimpan penjelasan tersebut. Analisis alasan penolakan memberikan masukan langsung tentang penyebab permintaan gagal. Informasi ini berguna untuk mencari akar masalah, seperti kode yang salah, anggaran yang tidak mencukupi, atau alasan pengajuan yang kurang kuat. Masalah tersebut kemudian dapat ditangani melalui pelatihan atau perbaikan proses.
Mengapa ini penting
Memberikan gambaran langsung tentang akar penyebab kegagalan proses, sehingga Anda dapat menemukan kebutuhan pelatihan pengguna atau memperjelas proses.
Sumber data
Informasi ini biasanya dicatat di kolom komentar atau catatan yang terkait dengan perubahan status menjadi 'Ditolak' dalam riwayat persetujuan permintaan pembelian.
Contoh
Pusat biaya tidak tepatMelebihi anggaran untuk kuartal iniPermintaan duplikatAlasan pengajuan tidak memadai
|
|||
|
Durasi Langkah Persetujuan
ApprovalStepDuration
|
Waktu yang dihabiskan permintaan pembelian untuk menunggu pada satu langkah persetujuan. | ||
|
Deskripsi
Metrik terhitung ini mengukur durasi antara aktivitas 'Langkah Persetujuan Dimulai' dan aktivitas terkait, yaitu 'Langkah Persetujuan Disetujui' atau 'Langkah Persetujuan Ditolak'. Metrik ini mengukur waktu tunggu pada setiap tahap dalam rantai persetujuan. Informasi ini penting untuk dasbor 'Hambatan pada Langkah Persetujuan Kritis', karena menunjukkan pemberi persetujuan atau tahap yang paling banyak menyebabkan keterlambatan dalam proses.
Mengapa ini penting
Menemukan hambatan pada setiap tahap persetujuan dengan mengukur waktu tunggu per tahap, bukan hanya total waktu proses.
Sumber data
Dihitung di alat process mining dengan mencari selisih waktu antara 'Approval Step Started' dan peristiwa persetujuan akhir berikutnya (Approved/Rejected).
Contoh
1,2 hari4 jam3,8 hari
|
|||
|
ID Pesanan Pembelian
PurchaseOrderId
|
Pengenal pesanan pembelian yang dibuat dari permintaan pembelian yang disetujui. | ||
|
Deskripsi
Setelah permintaan pembelian disetujui sepenuhnya dan masuk ke proses pengadaan, pesanan pembelian biasanya dibuat. Atribut ini menyimpan ID PO yang dihasilkan. ID tersebut menghubungkan proses Permintaan Pembelian di tahap awal dengan proses Pesanan Pembelian berikutnya. Dengan atribut ini, Anda dapat menghitung KPI 'Waktu dari Persetujuan Permintaan Pembelian hingga Pembuatan PO' dan menganalisis seluruh siklus Purchase-to-Pay dari awal hingga akhir.
Mengapa ini penting
Menghubungkan permintaan pembelian dengan pesanan pembelian berikutnya, sehingga waktu peralihan dapat dianalisis dan proses P2P dapat ditinjau secara menyeluruh.
Sumber data
Kolom standar pada objek Requisition di Coupa ini akan terisi setelah PO dibuat.
Contoh
PO-45000123PO-45000124PO-45000125
|
|||
|
Jalur Alur Persetujuan
ApprovalWorkflowPath
|
Pengenal rantai persetujuan atau templat alur kerja tertentu yang diterapkan pada permintaan pembelian. | ||
|
Deskripsi
Atribut ini menunjukkan urutan pemberi persetujuan yang seharusnya dilalui oleh permintaan pembelian. Urutan ini ditentukan oleh aturan bisnis, biasanya berdasarkan faktor seperti jumlah, departemen, dan jenis permintaan. Atribut ini menjadi dasar dasbor 'Kepatuhan Kebijakan Permintaan Pembelian'. Dengan membandingkan urutan pemberi persetujuan yang sebenarnya dengan jalur alur kerja yang ditetapkan, Anda dapat mendeteksi penyimpangan, mengukur tingkat kepatuhan, dan menemukan pengecualian yang tidak dikelola.
Mengapa ini penting
Memungkinkan analisis kepatuhan dengan membandingkan langkah persetujuan yang diharapkan dengan yang sebenarnya, sehingga penyimpangan proses dapat ditemukan.
Sumber data
Periksa dokumentasi Coupa. Nilai ini mungkin berasal dari nama rantai persetujuan atau aturan alur kerja yang dipicu untuk permintaan pembelian.
Contoh
Persetujuan Standar <$5kPersetujuan Perangkat Keras TI >$10kTinjauan CFO untuk Belanja Modal
|
|||
|
Jenis Permintaan Pembelian
RequisitionType
|
Kategori atau jenis permintaan pembelian, seperti 'Belanja Modal', 'Belanja Operasional', atau 'Perangkat Lunak'. | ||
|
Deskripsi
Jenis Permintaan Pembelian mengelompokkan permintaan berdasarkan tujuan bisnis atau sifat pembeliannya. Atribut ini berguna untuk analisis kepatuhan dan untuk memahami alur berbagai jenis permintaan dalam proses. Contohnya, permintaan belanja modal mungkin mengikuti jalur persetujuan yang lebih ketat dan panjang daripada permintaan operasional biasa. Analisis proses berdasarkan jenis permintaan pembelian dapat mengungkap peluang untuk menyempurnakan proses.
Mengapa ini penting
Memungkinkan analisis dikelompokkan berdasarkan tujuan bisnis permintaan, karena tiap jenis dapat memiliki alur proses dan kebijakan yang berbeda.
Sumber data
Kemungkinan besar, kolom klasifikasi ini merupakan kolom khusus atau standar pada objek Requisition di Coupa.
Contoh
Belanja ModalBelanja OperasionalPerangkat Keras TIJasa Profesional
|
|||
|
Jumlah tahap persetujuan
ApprovalStepCount
|
Jumlah seluruh tahap persetujuan yang dilalui sebuah permintaan pembelian. | ||
|
Deskripsi
Atribut terhitung ini menghitung jumlah aktivitas 'Approval Step Approved' yang berbeda untuk setiap permintaan pembelian. Angka ini membantu mengukur kerumitan alur kerja persetujuan tiap kasus. Nilai ini menjadi dasar KPI 'Rata-rata jumlah tahap persetujuan' dan membantu menemukan permintaan pembelian dengan jalur persetujuan yang terlalu panjang atau rumit, yang mungkin perlu disederhanakan.
Mengapa ini penting
Mengukur kerumitan alur kerja persetujuan untuk setiap permintaan pembelian dan membantu menemukan jalur yang terlalu rumit dan perlu disederhanakan.
Sumber data
Metrik ini dihitung di alat process mining dengan menghitung kemunculan 'Approval Step Approved' untuk setiap ID kasus.
Contoh
253
|
|||
|
Kategori Barang atau Jasa
Commodity
|
Kategori umum barang atau jasa yang diminta. | ||
|
Deskripsi
Atribut Kategori Barang atau Jasa memberikan klasifikasi standar untuk item dalam permintaan pembelian, seperti 'Perlengkapan Kantor', 'Perangkat Keras Komputer', atau 'Jasa Pemasaran'. Atribut ini memungkinkan analisis pola pembelian dan variasi proses berdasarkan barang atau jasa yang dibeli. Kategori tertentu mungkin memerlukan persetujuan khusus atau strategi pengadaan tersendiri. Dengan menganalisis proses berdasarkan kategori, Anda dapat menyempurnakan pengadaan untuk berbagai jenis belanja.
Mengapa ini penting
Membantu menganalisis kategori belanja dan memahami apakah perilaku proses, seperti waktu persetujuan, berbeda menurut jenis barang atau jasa yang dibeli.
Sumber data
Kolom standar di Coupa ini biasanya tersedia pada tingkat item baris permintaan pembelian. Anda mungkin perlu menggabungkannya ke tingkat header.
Contoh
Perlengkapan KantorPerangkat Keras KomputerJasa PemasaranPerjalanan
|
|||
|
Mata Uang
Currency
|
Kode mata uang untuk jumlah total permintaan pembelian. | ||
|
Deskripsi
Atribut ini menunjukkan mata uang, misalnya USD, EUR, atau GBP, yang digunakan untuk menyatakan Jumlah Total permintaan pembelian. Informasi ini penting untuk analisis keuangan, terutama bagi organisasi multinasional yang menggunakan beberapa mata uang. Dengan begitu, nilai uang dapat ditafsirkan dengan benar serta dikonversi dan dijumlahkan secara tepat dalam laporan keuangan dan dasbor.
Mengapa ini penting
Memberikan konteks yang diperlukan untuk atribut 'Jumlah Total' agar analisis keuangan tetap akurat saat menggunakan beberapa mata uang.
Sumber data
Kolom standar pada objek Requisition di Coupa ini biasanya bernama 'currency_code' atau nama serupa.
Contoh
USDEURGBP
|
|||
|
Nama Pemasok
SupplierName
|
Nama pemasok atau vendor yang dipilih untuk permintaan pembelian. | ||
|
Deskripsi
Atribut ini menunjukkan pemasok yang dituju untuk barang atau jasa yang diminta. Pemohon dapat menentukan pemasok, atau pemasok dapat ditambahkan kemudian selama proses pengadaan. Analisis metrik proses berdasarkan pemasok dapat membantu menilai kinerja pemasok dan mengetahui apakah interaksi dengan pemasok tertentu memperpanjang waktu siklus atau menimbulkan kendala proses lainnya. Informasi ini juga memberi konteks penting untuk strategi pengadaan dan pengelolaan hubungan dengan pemasok.
Mengapa ini penting
Memungkinkan analisis kinerja proses berdasarkan pemasok yang dipilih, sehingga dapat menjadi bahan untuk strategi pengadaan dan pengelolaan pemasok.
Sumber data
Informasi ini tersedia pada objek Requisition Line di Coupa, biasanya di kolom 'supplier' atau 'vendor'.
Contoh
StaplesDell TechnologiesAccentureCDW
|
|||
|
Pernah Diubah
IsAmended
|
Penanda boolean bernilai true jika permintaan pembelian diubah satu kali atau lebih setelah pertama kali diajukan. | ||
|
Deskripsi
Atribut terhitung ini berupa penanda sederhana (True/False) yang menunjukkan apakah aktivitas 'Permintaan Pembelian Diubah' terjadi pada suatu kasus. Penanda ini memudahkan analisis dan pemfilteran, sehingga pengguna dapat dengan mudah memisahkan permintaan yang perlu diubah. Gunakan atribut ini untuk menghitung KPI Tingkat Perubahan Permintaan Pembelian dan mengisi dasbor 'Volume Perubahan Permintaan Pembelian'. Dengan begitu, Anda dapat menemukan penyebab pekerjaan ulang dan meningkatkan kualitas sejak pengajuan pertama.
Mengapa ini penting
Memudahkan penghitungan KPI tingkat perubahan dan pemisahan kasus yang memerlukan pekerjaan ulang dari kasus yang tidak memerlukannya.
Sumber data
Atribut ini dihitung di alat process mining dengan memeriksa apakah aktivitas 'Permintaan Pembelian Diubah' tercatat di log peristiwa untuk setiap kasus.
Contoh
truefalse
|
|||
|
Tingkat Urgensi
UrgencyLevel
|
Klasifikasi tingkat urgensi permintaan pembelian, seperti 'Tinggi', 'Sedang', atau 'Rendah'. | ||
|
Deskripsi
Tingkat Urgensi, yang biasanya dipetakan ke kolom prioritas, memungkinkan pemohon menandai permintaan yang perlu diproses lebih cepat. Atribut ini penting untuk dasbor 'Waktu Pemrosesan Permintaan Mendesak'. Dengan membandingkan waktu siklus permintaan berurgensi tinggi dengan permintaan biasa, organisasi dapat menilai efektivitas penentuan prioritas dan memastikan kebutuhan bisnis yang mendesak terpenuhi tepat waktu.
Mengapa ini penting
Memungkinkan analisis untuk mengetahui apakah permintaan mendesak diproses lebih cepat daripada permintaan biasa, sekaligus menilai efektivitas kebijakan penentuan prioritas.
Sumber data
Kolom ini mungkin merupakan kolom standar atau khusus pada objek Requisition di Coupa. Periksa dokumentasi atau konfigurasi sistem Coupa.
Contoh
TinggiSedangRendah
|
|||
Aktivitas Purchase to Pay - Requisition
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Permintaan pembelian diajukan
|
Pemohon secara resmi mengajukan permintaan yang telah dilengkapi ke alur persetujuan. Peristiwa ini diketahui saat status permintaan berubah dari 'draft' menjadi 'pending_approval' dalam log audit atau tabel riwayat sistem. | ||
|
Mengapa ini penting
Pengajuan memulai proses persetujuan, sehingga menjadi tonggak penting untuk mengukur KPI 'Average Requisition Approval Cycle Time'. Keterlambatan sebelum tahap ini berkaitan dengan pengguna, sedangkan keterlambatan setelahnya berkaitan dengan proses.
Sumber data
Peristiwa ini diketahui dari perubahan status pada tabel 'requisition_headers', khususnya saat kolom 'status' berubah menjadi 'pending_approval'. Stempel waktu perubahan dapat ditemukan di jejak audit terkait.
Pengumpulan data
Temukan stempel waktu saat status permintaan pertama kali berubah menjadi 'pending_approval'.
Jenis peristiwa
inferred
|
|||
|
Permintaan pembelian dibuat
|
Pengguna memulai permintaan pembelian baru dan menyimpannya sebagai draf. Ini adalah titik awal setiap kasus permintaan dan biasanya diketahui dari stempel waktu pembuatan catatan permintaan. | ||
|
Mengapa ini penting
Aktivitas ini menandai awal siklus permintaan pembelian. Analisis waktu antara pembuatan dan pengajuan dapat mengungkap keterlambatan akibat ketidakpastian pengguna atau kerumitan sistem.
Sumber data
Peristiwa ini diambil dari stempel waktu 'created-at' pada tabel 'requisition_headers' untuk Purchase Requisition ID tertentu.
Pengumpulan data
Gunakan stempel waktu pembuatan catatan header permintaan.
Jenis peristiwa
inferred
|
|||
|
Permintaan Pembelian Disetujui
|
Permintaan pembelian berhasil melewati semua langkah yang diwajibkan dalam alur persetujuan. Status keseluruhan pada header permintaan berubah menjadi 'approved'. | ||
|
Mengapa ini penting
Ini adalah pencapaian penting yang menandai berakhirnya siklus persetujuan. Waktu hingga aktivitas ini menjadi KPI utama dan memicu tindakan pengadaan berikutnya.
Sumber data
Disimpulkan dari perubahan status pada tabel 'requisition_headers' saat kolom 'status' diperbarui menjadi 'approved'. Waktunya tercatat di jejak audit terkait.
Pengumpulan data
Temukan waktu saat status keseluruhan permintaan pembelian berubah menjadi 'approved'.
Jenis peristiwa
inferred
|
|||
|
Permintaan Pembelian Ditolak
|
Permintaan pembelian ditolak secara definitif selama proses persetujuan dan tidak akan diubah menjadi pesanan pembelian. Hal ini disimpulkan dari perubahan status keseluruhan pada header permintaan menjadi 'rejected'. | ||
|
Mengapa ini penting
Aktivitas ini menandai kegagalan akhir dalam proses. Menganalisis peristiwa ini penting untuk menurunkan 'Tingkat Penolakan Permintaan Pembelian' dan menemukan penyebab utama, seperti pelanggaran kebijakan atau masalah anggaran.
Sumber data
Disimpulkan dari perubahan status pada tabel 'requisition_headers' saat kolom 'status' diperbarui menjadi 'rejected'. Waktunya tercatat di jejak audit terkait.
Pengumpulan data
Temukan waktu saat status keseluruhan permintaan pembelian berubah menjadi 'rejected'.
Jenis peristiwa
inferred
|
|||
|
Permintaan Pembelian Ditutup
|
Permintaan pembelian ditutup secara resmi, yang berarti tidak ada tindakan lanjutan. Penutupan dapat terjadi setelah PO dibuat dan dipenuhi, atau jika permintaan dibatalkan setelah disetujui tetapi sebelum pesanan dibuat. | ||
|
Mengapa ini penting
Aktivitas ini menandai akhir siklus permintaan pembelian. Dengan begitu, setiap kasus memiliki penutup yang jelas dan tidak terus muncul sebagai 'aktif' dalam analisis proses.
Sumber data
Disimpulkan dari perubahan status pada tabel 'requisition_headers' saat kolom 'status' diperbarui menjadi 'closed'. Waktunya tercatat di jejak audit terkait.
Pengumpulan data
Temukan waktu saat status keseluruhan permintaan pembelian berubah menjadi 'closed'.
Jenis peristiwa
inferred
|
|||
|
Pesanan Pembelian Dibuat
|
Pesanan pembelian (PO) berhasil dibuat berdasarkan informasi dari permintaan pembelian yang disetujui. Peristiwa ini disimpulkan saat catatan PO dibuat dengan merujuk ke ID permintaan pembelian asal. | ||
|
Mengapa ini penting
Ini adalah hasil utama yang diharapkan dari proses permintaan pembelian dan menandai peralihan ke tahap Purchase-to-Pay berikutnya. Menganalisis waktu dari 'Permintaan Pembelian Disetujui' hingga peristiwa ini dapat menunjukkan keterlambatan pelaksanaan.
Sumber data
Disimpulkan dari pembuatan catatan di tabel 'purchase_orders' yang merujuk kembali ke ID 'requisition_headers' atau 'requisition_lines' asal.
Pengumpulan data
Gunakan stempel waktu 'created-at' pada catatan PO yang ditautkan ke ID permintaan pembelian.
Jenis peristiwa
inferred
|
|||
|
Langkah Persetujuan Ditolak
|
Pemberi persetujuan menolak permintaan pembelian pada tahapnya dalam alur kerja. Biasanya, permintaan dikembalikan kepada pemohon untuk diperbaiki. Coupa mencatat tindakan ini secara eksplisit. | ||
|
Mengapa ini penting
Penolakan pada tahap mana pun menimbulkan pekerjaan ulang dan memperpanjang waktu siklus. Menganalisis kapan dan mengapa penolakan terjadi penting untuk perbaikan proses dan pelatihan pengguna.
Sumber data
Diambil dari tindakan 'reject' yang tercatat secara eksplisit di tabel 'approvals' atau jejak auditnya, lalu dikaitkan dengan permintaan pembelian dan pemberi persetujuan terkait.
Pengumpulan data
Filter peristiwa 'reject' dalam riwayat persetujuan permintaan pembelian.
Jenis peristiwa
explicit
|
|||
|
Permintaan Pembelian Ditarik
|
Pemohon awal membatalkan permintaan pembelian sebelum persetujuan akhir diberikan. Pengguna melakukan tindakan ini secara eksplisit, sehingga proses untuk permintaan tersebut berakhir. | ||
|
Mengapa ini penting
Penarikan dapat menandakan perubahan kebutuhan bisnis, permintaan duplikat, atau pengguna yang menghindari proses. Dengan melacaknya, Anda dapat memahami perubahan kebutuhan dan potensi masalah kepatuhan proses.
Sumber data
Disimpulkan dari perubahan status pada tabel 'requisition_headers' menjadi 'withdrawn' atau status serupa, berdasarkan tindakan pengguna yang tercatat secara eksplisit di jejak audit.
Pengumpulan data
Temukan waktu saat status permintaan pembelian berubah menjadi 'withdrawn'.
Jenis peristiwa
inferred
|
|||
|
Permintaan pembelian diubah
|
Setelah permintaan diajukan, pemohon atau pengguna lain yang berwenang mengeditnya. Coupa mencatat perubahan ini sebagai versi baru atau entri audit, dan sering kali mengatur ulang sebagian atau seluruh alur persetujuan. | ||
|
Mengapa ini penting
Melacak perubahan penting untuk memahami pekerjaan ulang dan inefisiensi proses. Banyaknya perubahan dapat menunjukkan persyaratan awal yang kurang jelas atau kebijakan pembelian yang rumit, sehingga memengaruhi KPI 'Requisition Amendment Rate'.
Sumber data
Perubahan ini diambil dari tabel jejak audit yang terkait dengan tabel 'requisition_headers'. Tabel tersebut mencatat perubahan versi atau tindakan 'edit' tertentu.
Pengumpulan data
Cari peristiwa 'edit' atau 'update' yang tercatat secara jelas dalam log riwayat permintaan setelah pengajuan.
Jenis peristiwa
explicit
|
|||
|
Permintaan Pembelian Masuk ke Proses Pengadaan
|
Permintaan pembelian yang disetujui dikirim ke proses pengadaan, seperti RFQ atau lelang, alih-alih langsung diubah menjadi pesanan pembelian. Peristiwa ini disimpulkan saat permintaan pembelian ditautkan ke objek proses pengadaan. | ||
|
Mengapa ini penting
Aktivitas ini menunjukkan jalur alternatif yang penting dalam proses pengadaan. Jalur ini membedakan pembelian sederhana dari proses pengadaan strategis yang lebih kompleks, sehingga analisis waktu siklus dapat dilakukan dengan lebih terperinci.
Sumber data
Disimpulkan dengan mendeteksi perubahan status menjadi 'sourcing' atau tautan yang dibuat antara tabel 'requisition_lines' dan tabel peristiwa pengadaan.
Pengumpulan data
Periksa apakah status berubah menjadi 'sourcing' atau tautan ke ID peristiwa pengadaan dibuat.
Jenis peristiwa
inferred
|
|||
|
Tahap persetujuan dimulai
|
Tugas persetujuan diberikan kepada pemberi persetujuan atau kelompok tertentu, dan permintaan kini menunggu tindakan mereka. Peristiwa ini diketahui saat catatan persetujuan yang terkait dengan permintaan dibuat dengan status 'pending'. | ||
|
Mengapa ini penting
Tahap ini menandai awal waktu tunggu untuk persetujuan tertentu. Mengukur durasi antara tahap ini dan 'Approval Step Approved/Rejected' membantu menemukan hambatan pada rantai persetujuan.
Sumber data
Peristiwa ini diketahui dari stempel waktu pembuatan catatan pada tabel 'approvals' yang terkait dengan permintaan, dengan status tindakan pemberi persetujuan 'pending' atau status setara.
Pengumpulan data
Gunakan stempel waktu pembuatan catatan persetujuan yang masih menunggu tindakan dari pemberi persetujuan dalam rantai persetujuan.
Jenis peristiwa
inferred
|
|||
|
Tahap persetujuan disetujui
|
Pemberi persetujuan dalam alur kerja menyetujui permintaan pembelian. Sistem mencatat tindakan ini secara eksplisit, lengkap dengan waktu dan informasi pengguna. | ||
|
Mengapa ini penting
Aktivitas ini memberikan gambaran terperinci tentang alur persetujuan. Dengan menggabungkan langkah-langkah ini, Anda dapat menghitung 'Rata-rata Waktu Tunggu per Langkah Persetujuan' dan menganalisis kinerja pemberi persetujuan.
Sumber data
Diambil dari tindakan 'approve' yang tercatat secara eksplisit di tabel 'approvals' atau jejak auditnya, lalu dikaitkan dengan permintaan pembelian dan pemberi persetujuan terkait.
Pengumpulan data
Filter peristiwa 'approve' dalam riwayat persetujuan permintaan pembelian.
Jenis peristiwa
explicit
|
|||
Panduan ekstraksi
Siap memulai?
Mulai optimalkan proses Purchase to Pay - Requisition di Coupa hari ini dengan templat ini. Temukan wawasan penting dan tingkatkan efisiensi pengadaan Anda.
Optimalkan permintaan pembelian P2P di Coupa, kurangi waktu proses mulai hari ini
Temukan inefisiensi dan kurangi waktu proses permintaan pembelian P2P hingga 30%.
Tidak perlu kartu kredit. Mulai optimalkan proses dalam hitungan menit.