Templat data Purchase to Pay - Requisition Anda
Templat data Purchase to Pay - Requisition Anda
Ini template data umum kami untuk process mining Purchase to Pay - Permintaan pembelian. Gunakan template khusus sistem untuk mendapatkan panduan yang lebih terarah.
Pilih sistem tertentu- Kolom data standar untuk analisis yang konsisten di berbagai sistem.
- Daftar aktivitas penting yang perlu dilacak agar proses terlihat jelas.
- Dasar yang fleksibel dan dapat disesuaikan dengan alur kerja Purchase to Pay, Requisition di organisasi Anda.
Atribut Purchase to Pay - Requisition
| Nama | Deskripsi | ||
|---|---|---|---|
| ID permintaan pembelian PurchaseRequisitionId | Pengenal unik untuk setiap permintaan pembelian. ID ini menjadi pengenal utama kasus dalam proses. | ||
| Deskripsi ID permintaan pembelian adalah kunci unik yang diberikan kepada setiap dokumen permintaan saat dibuat. ID ini menjadi acuan utama untuk semua aktivitas, perubahan, dan persetujuan yang terkait dengan satu permintaan, dari awal hingga selesai. Dalam process mining, ID ini penting untuk menghubungkan data kasus. Sistem menggunakannya untuk menyusun kembali perjalanan setiap permintaan dari awal hingga akhir, dengan mengaitkan berbagai peristiwa seperti 'Permintaan dibuat', 'Tahap persetujuan disetujui', dan 'Pesanan pembelian dibuat' menjadi satu alur proses yang utuh. Tanpa pengenal kasus yang konsisten dan unik, analisis variasi proses, waktu siklus, dan hasil tidak dapat dilakukan. Mengapa ini penting Kunci ini penting untuk melacak seluruh siklus permintaan dan menghubungkan semua peristiwa terkait ke dalam satu instans proses. Sumber data Biasanya terdapat di data header transaksi permintaan pembelian atau tabel dokumen. Contoh PR-100567REQ00043218000123987 | |||
| Nama aktivitas ActivityName | Nama aktivitas bisnis atau peristiwa tertentu yang terjadi pada waktu tertentu dalam proses permintaan. | ||
| Deskripsi Nama aktivitas menjelaskan satu langkah atau perubahan status dalam siklus permintaan pembelian. Nama ini memberi label yang mudah dipahami untuk peristiwa seperti 'Permintaan diajukan', 'Tahap persetujuan dimulai', atau 'Permintaan ditolak', yang menjadi bagian dasar peta proses. Atribut ini penting untuk menemukan dan menganalisis proses. Dengan menyusun aktivitas secara berurutan, alat process mining dapat menampilkan alur proses yang sebenarnya, menemukan penyimpangan dari prosedur standar, serta menunjukkan hambatan atau siklus pengerjaan ulang. Nama aktivitas yang konsisten dan jelas membantu menghasilkan model proses yang mudah dipahami dan ditindaklanjuti. Mengapa ini penting Atribut ini menentukan tiap langkah proses, yang diperlukan untuk menampilkan peta proses dan menganalisis alurnya. Sumber data Sering kali diambil dari log peristiwa, tabel perubahan status, atau kode transaksi yang terkait dengan dokumen permintaan. Contoh Permintaan pembelian dibuatTahap persetujuan disetujuiPesanan pembelian dibuat | |||
| Waktu peristiwa EventTime | Tanggal dan waktu tepat saat aktivitas terjadi. Informasi ini menjadi stempel waktu utama untuk mengurutkan peristiwa. | ||
| Deskripsi Waktu peristiwa, yang sering disebut stempel waktu, mencatat saat tepat suatu aktivitas berlangsung. Data ini penting untuk mengurutkan peristiwa dengan benar dan melakukan semua analisis proses berbasis waktu, termasuk menghitung waktu siklus, menemukan hambatan, dan memantau kinerja. Dalam process mining, stempel waktu digunakan untuk mengurutkan aktivitas dalam setiap kasus dan mengukur durasi antar langkah. Analisis durasi membantu menemukan keterlambatan, memahami penyebab waktu siklus yang panjang, dan menilai apakah perjanjian tingkat layanan terpenuhi. Data stempel waktu yang akurat dan lengkap diperlukan untuk analisis kinerja yang bermakna. Mengapa ini penting Stempel waktu ini penting untuk mengurutkan peristiwa, menghitung waktu siklus, serta menganalisis kinerja dan hambatan proses. Sumber data Biasanya tercatat dalam jejak audit sistem, log peristiwa, atau sebagai tanggal pembuatan maupun perubahan pada catatan transaksi. Contoh 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:45Z | |||
| Pembaruan data terakhir LastDataUpdate | Stempel waktu yang menunjukkan kapan data untuk catatan ini terakhir diperbarui atau diekstrak dari sistem sumber. | ||
| Deskripsi Stempel waktu pembaruan data terakhir menunjukkan seberapa baru data yang dianalisis. Informasi ini mencatat kapan data terakhir diekstrak dari sistem sumber dan dimuat ke lingkungan process mining. Atribut ini penting untuk pemantauan operasional dan memastikan analisis menggunakan informasi terkini. Atribut ini membantu pengguna memahami jeda antara peristiwa di lapangan dan pencatatannya dalam model proses. Dashboard dan KPI untuk memantau operasional yang sedang berjalan mengandalkan informasi ini agar dapat memberikan wawasan yang tepat waktu dan relevan. Mengapa ini penting Informasi ini menunjukkan seberapa baru data yang tersedia, sehingga analisis tetap relevan dan terkini. Sumber data Biasanya ditambahkan oleh alat integrasi data atau ETL (Extract, Transform, Load) saat data dimuat. Contoh 2024-05-20T02:00:00Z2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Sistem sumber SourceSystem | Menunjukkan sistem informasi tempat data diambil, seperti ERP atau platform pengadaan. | ||
| Deskripsi Atribut sistem sumber menunjukkan asal data proses. Di organisasi yang menggunakan beberapa sistem, seperti ERP pusat dan alat e-procurement khusus, kolom ini membantu membedakan data dari tiap sumber. Informasi ini berguna untuk memvalidasi data, mencari penyebab masalah, dan memahami variasi proses yang mungkin bergantung pada sistem. Misalnya, permintaan dari satu sistem mungkin mengikuti jalur persetujuan yang berbeda atau memiliki waktu siklus lebih singkat dibandingkan permintaan dari sistem lain. Analisis berdasarkan sistem sumber dapat mengungkap masalah integrasi atau peluang untuk menggabungkan sistem. Mengapa ini penting Informasi ini memberi konteks tentang asal data, yang penting untuk validasi data dan analisis perbedaan proses di berbagai sistem. Sumber data Biasanya berupa nilai tetap yang ditambahkan saat data diekstrak, atau tersedia di kolom metadata teknis. Contoh SAP S/4HANAOracle FusionCoupa | |||
| Departemen Department | Departemen bisnis, pusat biaya, atau unit organisasi yang menanggung biaya permintaan. | ||
| Deskripsi Atribut departemen menunjukkan unit organisasi yang bertanggung jawab atas pembelian, seperti 'Pemasaran', 'TI', atau 'Keuangan'. Informasi ini penting untuk keuangan dan organisasi, termasuk penyusunan anggaran dan alokasi biaya. Dalam process mining, analisis data berdasarkan departemen merupakan teknik yang umum digunakan. Analisis ini memungkinkan perbandingan kinerja antarunit bisnis, sehingga Anda dapat mengetahui departemen yang paling efisien dan yang mungkin membutuhkan dukungan. Analisis ini juga dapat mengungkap perbedaan waktu siklus, tingkat persetujuan, atau kepatuhan yang berkaitan dengan kebiasaan pembelian atau proses internal departemen tertentu. Mengapa ini penting Atribut ini memungkinkan perbandingan kinerja dan analisis biaya antarunit bisnis, serta menunjukkan pola proses yang khas di tiap departemen. Sumber data Biasanya tersedia di data header atau baris item permintaan pembelian, dan terhubung dengan struktur organisasi perusahaan. Contoh PemasaranTeknologi informasiKeuanganOperasional | |||
| ID pesanan pembelian PurchaseOrderId | Pengenal pesanan pembelian yang dibuat dari permintaan yang telah disetujui. | ||
| Deskripsi ID pesanan pembelian adalah nomor unik dokumen PO yang dibuat dari permintaan pembelian yang telah disetujui. Kolom ini menghubungkan proses permintaan dengan proses pengadaan dan pembayaran berikutnya. Atribut ini penting untuk menganalisis efisiensi konversi permintaan menjadi PO. Atribut ini memastikan permintaan berhasil menghasilkan pesanan pembelian dan memungkinkan pengukuran waktu yang dibutuhkan untuk konversi tersebut. Dengan menganalisis permintaan yang memiliki PO terkait, perusahaan dapat menilai efektivitas tahap sebelum pengadaan dan menemukan permintaan yang telah disetujui tetapi tidak pernah dipenuhi. Mengapa ini penting Atribut ini menghubungkan permintaan dengan proses pengadaan berikutnya, sehingga tingkat dan waktu konversi permintaan menjadi PO dapat dianalisis. Sumber data Biasanya terdapat di data dokumen permintaan setelah PO dibuat, terkadang di tabel dokumen terkait atau alur dokumen. Contoh PO-4500012345ORD7890016000054321 | |||
| Jenis permintaan RequisitionType | Kategori atau jenis permintaan, misalnya permintaan barang, jasa, atau belanja modal. | ||
| Deskripsi Jenis permintaan mengelompokkan permintaan pembelian berdasarkan sifat atau tujuannya. Contohnya, permintaan bahan standar, jasa, belanja modal, atau barang dari katalog tertentu. Klasifikasi ini sering menentukan alur persetujuan dan perlakuan akuntansi. Analisis berdasarkan jenis permintaan membantu Anda memahami apakah tiap jenis permintaan mengikuti jalur yang berbeda atau memiliki tingkat efisiensi yang berbeda. Misalnya, permintaan belanja modal mungkin memiliki waktu siklus lebih panjang karena memerlukan lapisan persetujuan tambahan, sedangkan permintaan barang standar dari katalog mungkin sangat otomatis. Analisis ini membantu merancang dan mengoptimalkan variasi proses untuk tiap jenis permintaan. Mengapa ini penting Atribut ini memungkinkan analisis jalur proses yang berbeda, karena jenis permintaan sering menentukan alur persetujuan dan tingkat kerumitannya. Sumber data Informasi ini biasanya disimpan sebagai jenis dokumen atau kode kategori di data header permintaan. Contoh Belanja modalBelanja operasionalPermintaan jasaPermintaan material | |||
| Mata uang Currency | Kode mata uang, seperti USD atau EUR, untuk total nilai permintaan. | ||
| Deskripsi Atribut mata uang menunjukkan satuan uang untuk nilai permintaan. Di organisasi multinasional, permintaan dapat dibuat dalam berbagai mata uang, bergantung pada lokasi pemohon atau pemasok. Kolom ini penting untuk pelaporan dan analisis keuangan yang akurat. Informasi ini memastikan nilai uang ditafsirkan dengan benar dan dapat dikonversi saat data dari berbagai wilayah digabungkan. Setiap analisis nilai permintaan perlu memperhitungkan mata uang agar satuan uang yang berbeda tidak dibandingkan secara langsung. Mengapa ini penting Informasi ini memberi konteks yang diperlukan untuk data keuangan, sehingga nilai permintaan dari berbagai wilayah dapat ditafsirkan dan digabungkan dengan akurat. Sumber data Biasanya terdapat di data header transaksi permintaan pembelian, bersama kolom nilai. Contoh USDEURGBP | |||
| Nama pemohon RequesterName | Nama karyawan atau pengguna yang membuat dan mengajukan permintaan pembelian. | ||
| Deskripsi Nama pemohon menunjukkan orang yang memulai permintaan pembelian. Biasanya, orang ini adalah pengguna bisnis yang membutuhkan barang atau jasa. Analisis proses berdasarkan pemohon dapat membantu menemukan pola pada individu atau kelompok tertentu. Misalnya, analisis dapat menunjukkan pemohon yang sering mengajukan permintaan tidak lengkap atau tidak sesuai ketentuan sehingga perlu dikerjakan ulang. Informasi ini dapat digunakan untuk memberikan pelatihan yang sesuai atau menyederhanakan proses permintaan bagi kelompok pengguna tertentu, sehingga efisiensi dan kepatuhan meningkat. Mengapa ini penting Atribut ini membantu menemukan pola perilaku pengguna, sehingga pelatihan dan perbaikan proses dapat diarahkan kepada individu atau tim yang tepat. Sumber data Terdapat di data header permintaan pembelian dan sering kali terhubung dengan data induk karyawan. Contoh John SmithJane DoeMaria Garcia | |||
| Nilai permintaan RequisitionAmount | Total nilai uang dalam permintaan pembelian. | ||
| Deskripsi Nilai permintaan menunjukkan total nilai keuangan semua barang dan jasa yang diminta dalam permintaan pembelian. Ini adalah metrik keuangan penting dalam proses pengadaan. Dalam analisis proses, atribut ini penting untuk pemfilteran dan analisis berdasarkan nilai. Anda dapat mengelompokkan permintaan bernilai tinggi dan rendah, yang sering memiliki alur persetujuan dan tingkat risiko berbeda. Analisis waktu siklus atau tingkat penolakan berdasarkan nilai permintaan dapat menunjukkan bahwa permintaan bernilai tinggi membutuhkan waktu lebih lama untuk disetujui atau lebih sering ditolak. Temuan ini dapat menjadi titik awal perbaikan proses. Mengapa ini penting Atribut ini memungkinkan analisis berdasarkan nilai, membantu Anda memprioritaskan permintaan bernilai tinggi dan memahami dampak nilai keuangan terhadap proses. Sumber data Biasanya terdapat di data header transaksi permintaan pembelian atau tabel dokumen. Contoh 500.0012500.7599.95 | |||
| Status permintaan RequisitionStatus | Status permintaan pembelian saat ini atau status akhirnya dalam siklus proses. | ||
| Deskripsi Status permintaan menunjukkan kondisi permintaan pada waktu tertentu atau hasil akhirnya. Status yang umum meliputi 'Sedang diproses', 'Menunggu persetujuan', 'Disetujui', 'Ditolak', dan 'Ditutup'. Atribut ini penting untuk analisis hasil dan pemantauan operasional. Analis dapat memfilter permintaan berdasarkan status akhirnya untuk menghitung metrik seperti tingkat penolakan atau tingkat konversi ke PO. Dalam operasional, tim dapat melihat beban kerja saat ini, misalnya jumlah permintaan yang menunggu persetujuan, lalu menentukan prioritas dan mengelola sumber daya dengan lebih baik. Mengapa ini penting Atribut ini memperjelas hasil permintaan, sehingga Anda dapat menghitung metrik penting seperti tingkat penolakan dan mengelola beban kerja operasional. Sumber data Biasanya terdapat di kolom status header dokumen permintaan pembelian. Contoh DisetujuiDitolakMenunggu persetujuanDitarik | |||
| Alasan penolakan RejectionReason | Alasan yang diberikan pemberi persetujuan saat menolak permintaan atau tahap persetujuan. | ||
| Deskripsi Alasan penolakan adalah kolom teks atau kode yang menjelaskan mengapa permintaan ditolak. Pemberi persetujuan mengisi informasi ini sebagai masukan bagi pemohon, yang mungkin perlu mengubah dan mengajukan ulang permintaan. Atribut ini sangat berguna untuk mencari akar penyebab kegagalan proses. Dengan mengelompokkan dan menganalisis alasan penolakan, organisasi dapat menemukan masalah umum seperti 'Kode GL salah', 'Anggaran terlampaui', atau 'Pemasok tidak memenuhi ketentuan'. Temuan ini dapat mendorong perbaikan yang terarah, seperti pelatihan pemohon yang lebih baik, komunikasi kebijakan yang lebih jelas, atau penyempurnaan sistem untuk mencegah kesalahan umum. Mengapa ini penting Atribut ini menunjukkan secara langsung alasan permintaan gagal, sehingga Anda dapat mencari akar penyebab, mengurangi pekerjaan ulang, dan meningkatkan tingkat persetujuan pada pengajuan pertama. Sumber data Biasanya dicatat di kolom komentar atau catatan yang terkait dengan aktivitas 'Ditolak' atau perubahan status. Contoh Anggaran terlampauiPusat biaya salahPermintaan duplikatPelanggaran kebijakan | |||
| Nama pemberi persetujuan ApproverName | Nama pengguna atau kelompok yang bertanggung jawab atas aktivitas persetujuan atau penolakan. | ||
| Deskripsi Nama pemberi persetujuan menunjukkan individu, peran, atau kelompok yang melakukan tahap persetujuan atau penolakan dalam alur kerja. Pihak ini berbeda dari pemohon atau pengguna umum yang mungkin melakukan aktivitas lain. Atribut ini penting untuk menganalisis proses persetujuan. Anda dapat mengukur kinerja pemberi persetujuan, misalnya waktu rata-rata yang dibutuhkan untuk mengambil keputusan. Atribut ini juga dapat menunjukkan pembagian beban kerja dan apakah pemberi persetujuan tertentu menjadi hambatan dalam proses. Analisis ini mendukung alokasi sumber daya dan pengelolaan kinerja yang lebih baik dalam rangkaian persetujuan. Mengapa ini penting Atribut ini memungkinkan analisis alur persetujuan secara terperinci, termasuk beban kerja dan kinerja pemberi persetujuan serta hambatan dalam proses. Sumber data Tercatat dalam log peristiwa atau log audit untuk aktivitas terkait persetujuan. Data ini mungkin perlu digabungkan dengan data induk karyawan. Contoh Alice JohnsonBob WilliamsKelompok persetujuan keuangan | |||
| Nama pengguna UserName | Nama pengguna yang melakukan aktivitas tertentu, seperti membuat, mengedit, atau menyetujui. | ||
| Deskripsi Nama pengguna menunjukkan orang yang bertanggung jawab atas setiap aktivitas dalam log proses. Atribut umum ini dapat mencatat pemohon, editor, pemberi persetujuan, atau siapa pun yang berinteraksi dengan permintaan pembelian. Atribut ini penting untuk menganalisis sumber daya dan otomatisasi. Anda dapat menggunakannya untuk memahami prinsip empat mata, yaitu serah terima pekerjaan antar pengguna, serta menghitung tingkat otomatisasi dengan mengenali aktivitas yang dilakukan oleh pengguna sistem atau batch. Analisis aktivitas berdasarkan pengguna juga membantu Anda memahami interaksi berbagai peran dalam proses. Mengapa ini penting Atribut ini penting untuk memahami serah terima antar pengguna, menganalisis otomatisasi, dan mengaitkan setiap langkah proses dengan pelakunya. Sumber data Biasanya tersedia di jejak audit atau data log peristiwa untuk setiap transaksi, dan sering disimpan sebagai User ID. Contoh asmithjdoeBATCH_USER | |||
| Tanggal dibutuhkan RequiredByDate | Tanggal saat pemohon membutuhkan barang atau jasa. | ||
| Deskripsi Pemohon menetapkan Tanggal dibutuhkan sebagai tenggat pemenuhan. Tanggal ini menjadi target untuk seluruh proses pengadaan, mulai dari persetujuan permintaan hingga barang atau jasa diterima. Atribut ini membantu Anda menganalisis ketepatan waktu proses dan kesesuaiannya dengan kebutuhan bisnis. Bandingkan Tanggal dibutuhkan dengan tanggal pembuatan Purchase Order atau tanggal pengiriman aktual untuk mengukur kemampuan organisasi memenuhi tingkat layanan internal. Atribut ini juga membantu menjawab pertanyaan penting, seperti apakah proses pengadaan cukup cepat untuk memenuhi tenggat bisnis. Mengapa ini penting Atribut ini menjadi acuan untuk mengukur kinerja proses terhadap tenggat bisnis dan menilai kemampuan memenuhi kebutuhan tepat waktu. Sumber data Biasanya diisi oleh pengguna saat membuat permintaan pembelian dan disimpan di bagian header atau detail baris permintaan. Contoh 2024-06-302024-07-152024-08-01 | |||
| Tingkat urgensi UrgencyLevel | Klasifikasi yang menunjukkan prioritas atau tingkat urgensi permintaan, seperti 'Tinggi', 'Sedang', atau 'Rendah'. | ||
| Deskripsi Tingkat urgensi, yang terkadang disebut prioritas, adalah kolom yang digunakan pemohon untuk menunjukkan seberapa cepat barang atau jasa dibutuhkan. Klasifikasi ini dapat memengaruhi cara tim pengadaan dan pemberi persetujuan mengarahkan serta memprioritaskan permintaan. Analisis kinerja proses berdasarkan tingkat urgensi membantu menilai apakah proses tanggap terhadap kebutuhan bisnis. Misalnya, Anda dapat memeriksa apakah permintaan berurgensi 'Tinggi' benar-benar diproses lebih cepat daripada permintaan berurgensi 'Rendah'. Jika tidak, mungkin ada hambatan atau mekanisme penentuan prioritas yang tidak berjalan dan perlu diperbaiki. Mengapa ini penting Atribut ini membantu menilai apakah proses memprioritaskan permintaan mendesak dengan baik dan apakah tingkat urgensi yang dicantumkan sesuai dengan kecepatan pemrosesan. Sumber data Biasanya berupa kolom opsional atau wajib pada formulir pembuatan permintaan, dan disimpan di header permintaan. Contoh TinggiSedangRendahMendesak | |||
Aktivitas Purchase to Pay - Requisition
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Permintaan disetujui | Permintaan berhasil melewati semua tahap yang diwajibkan dalam alur persetujuan. Setelah itu, permintaan dapat diproses untuk pengadaan atau diubah menjadi pesanan pembelian. | ||
| Mengapa ini penting Ini adalah pencapaian penting yang menandai keberhasilan. Waktu yang dibutuhkan hingga tahap ini menjadi ukuran utama efisiensi proses permintaan. Sumber data Disimpulkan dari perubahan status keseluruhan pada header permintaan menjadi 'Approved' atau status akhir persetujuan serupa dalam log alur kerja. Pengumpulan data Catat stempel waktu saat status keseluruhan permintaan pertama kali berubah menjadi 'Approved' atau status setara. Jenis peristiwa inferred | |||
| Permintaan ditolak | Permintaan ditolak secara definitif selama proses persetujuan dan tidak akan diubah menjadi pesanan pembelian. Ini menandai hasil akhir yang tidak berhasil. | ||
| Mengapa ini penting Ini adalah pencapaian penting yang menandai kegagalan. Analisis alasan penolakan akhir dapat membantu memperbaiki proses awal dan pelatihan pemohon. Sumber data Disimpulkan dari perubahan status keseluruhan pada header permintaan menjadi 'Rejected', 'Denied', atau status akhir penolakan serupa. Pengumpulan data Catat stempel waktu saat status keseluruhan permintaan pertama kali berubah menjadi 'Rejected', 'Denied', atau status setara. Jenis peristiwa inferred | |||
| Permintaan ditutup | Permintaan ditutup secara administratif, yang berarti tidak ada tindakan lanjutan. Biasanya, ini terjadi setelah semua baris permintaan diubah menjadi pesanan pembelian atau dibatalkan. | ||
| Mengapa ini penting Ini adalah peristiwa akhir proses yang menandai selesainya siklus permintaan. Dengan begitu, permintaan lama tidak terus terbuka tanpa batas waktu. Sumber data Disimpulkan dari pembaruan status akhir pada header permintaan atau saat semua baris terkait ditandai telah dipesan sepenuhnya atau ditutup. Pengumpulan data Catat stempel waktu saat status akhir permintaan diubah menjadi 'Closed' atau 'Completed'. Jenis peristiwa inferred | |||
| Permintaan pembelian diajukan | Pemohon secara resmi mengajukan permintaan yang sudah lengkap ke alur kerja persetujuan. Tindakan ini mengubah status permintaan dari draf menjadi aktif dan menunggu peninjauan serta persetujuan. | ||
| Mengapa ini penting Peristiwa ini memulai proses persetujuan resmi. Waktu antara pengajuan dan persetujuan akhir merupakan bagian penting dari keseluruhan durasi siklus. Sumber data Biasanya, peristiwa ini dicatat melalui perubahan status, log tindakan pengguna, atau log mesin alur kerja yang menunjukkan dimulainya proses persetujuan. Pengumpulan data Catat stempel waktu saat status permintaan berubah dari draf menjadi status yang menunjukkan bahwa permintaan menunggu persetujuan. Jenis peristiwa explicit | |||
| Permintaan pembelian dibuat | Pengguna memulai permintaan barang atau jasa dengan membuat dokumen permintaan pembelian baru. Peristiwa ini menandai awal siklus permintaan, yang biasanya dimulai dengan status draf atau belum lengkap sebelum diajukan secara resmi. | ||
| Mengapa ini penting Ini adalah peristiwa awal utama dalam proses. Menganalisis waktu dari pembuatan hingga pengajuan dapat mengungkap keterlambatan dalam menyiapkan permintaan atau keraguan pengguna. Sumber data Biasanya, peristiwa ini dicatat dari stempel waktu pembuatan pada catatan atau tabel utama header permintaan pembelian. Pengumpulan data Temukan stempel waktu awal pembuatan catatan header permintaan pembelian. Jenis peristiwa explicit | |||
| Permintaan pembelian diubah | Pengguna mengubah permintaan setelah diajukan, biasanya untuk memperbaiki informasi atau menanggapi penolakan. Perubahan ini umumnya mencakup detail seperti jumlah, harga, atau item, dan dapat mengharuskan proses persetujuan dimulai kembali. | ||
| Mengapa ini penting Melacak perubahan penting untuk menemukan rangkaian pekerjaan ulang, inefisiensi proses, dan kebutuhan awal yang kurang jelas. Tingkat perubahan yang tinggi dapat memperpanjang durasi siklus secara signifikan. Sumber data Data dapat diperoleh dari jejak audit sistem, log perubahan, atau dengan menemukan pembuatan versi baru dokumen permintaan pembelian. Pengumpulan data Temukan peristiwa dalam log perubahan atau audit yang menunjukkan pengeditan kolom penting pada permintaan pembelian setelah pengajuan awal. Jenis peristiwa explicit | |||
| Pesanan pembelian dibuat | Dokumen pesanan pembelian resmi dibuat berdasarkan informasi dari satu atau beberapa baris permintaan yang telah disetujui. Peristiwa ini menandai peralihan dari proses permintaan internal ke proses pengadaan eksternal. | ||
| Mengapa ini penting Ini adalah hasil utama yang menandai keberhasilan proses permintaan. Waktu dari persetujuan akhir hingga pembuatan PO mengukur efisiensi departemen pembelian. Sumber data Peristiwa ini disimpulkan untuk permintaan dengan mencari dokumen pesanan pembelian terkait yang mencantumkan ID permintaan tersebut. Pengumpulan data Temukan stempel waktu pembuatan pesanan pembelian yang mencantumkan ID permintaan tersebut. Jenis peristiwa inferred | |||
| Permintaan ditarik | Pemohon atau pengguna yang berwenang membatalkan permintaan sebelum mendapat persetujuan akhir atau diubah menjadi pesanan. Tindakan ini mengakhiri proses untuk permintaan tersebut. | ||
| Mengapa ini penting Ini adalah peristiwa akhir yang menghentikan proses tanpa hasil yang jelas, baik berhasil maupun gagal. Tingginya angka penarikan dapat menunjukkan perubahan kebutuhan bisnis atau permintaan yang diajukan terlalu dini. Sumber data Biasanya tercatat sebagai tindakan langsung pengguna yang mengubah status menjadi 'Withdrawn' atau 'Cancelled', atau menetapkan tanda penghapusan. Pengumpulan data Catat stempel waktu saat status permintaan berubah menjadi 'Withdrawn' atau 'Cancelled', atau saat tanda penghapusan ditetapkan. Jenis peristiwa explicit | |||
| Persetujuan diatur ulang | Seluruh alur persetujuan permintaan diatur ulang sehingga proses harus dimulai dari awal. Hal ini biasanya terjadi setelah permintaan yang sedang diproses mengalami perubahan besar. | ||
| Mengapa ini penting Pengaturan ulang persetujuan sering memperpanjang waktu siklus. Frekuensi dan pemicunya dapat menunjukkan masalah kebijakan atau proses perubahan permintaan. Sumber data Disimpulkan dari status persetujuan yang dihapus atau dikembalikan ke tahap awal, setelah sebelumnya ditetapkan kepada pemberi persetujuan di tahap berikutnya. Pengumpulan data Temukan kapan status alur persetujuan kembali ke kondisi awal setelah proses berlanjut ke tahap berikutnya. Jenis peristiwa inferred | |||
| Sumber pasokan ditetapkan | Pembeli atau spesialis pengadaan menetapkan vendor, kontrak, atau kesepakatan harga tertentu pada baris permintaan yang telah disetujui. Langkah ini dilakukan sebelum pesanan pembelian dibuat. | ||
| Mengapa ini penting Aktivitas ini mengukur efisiensi tim pengadaan taktis. Keterlambatan dapat menjadi hambatan antara persetujuan permintaan dan pembuatan pesanan. Sumber data Dicatat dengan mengamati perubahan pada kolom vendor atau sumber di baris permintaan setelah permintaan disetujui. Pengumpulan data Temukan stempel waktu saat ID vendor atau kontrak pertama kali diisi pada baris permintaan yang telah disetujui. Jenis peristiwa explicit | |||
| Tahap persetujuan dimulai | Permintaan pembelian ditugaskan kepada pemberi persetujuan tertentu atau kelompok pemberi persetujuan sebagai bagian dari alur kerja bertahap. Aktivitas ini menandai dimulainya waktu tunggu untuk tindakan persetujuan tertentu. | ||
| Mengapa ini penting Peristiwa ini memungkinkan analisis hambatan yang lebih terperinci dalam rangkaian persetujuan, sehingga pemberi persetujuan atau tahap tertentu yang menyebabkan keterlambatan dapat ditemukan. Sumber data Peristiwa ini disimpulkan dari log mesin alur kerja saat tugas persetujuan baru dibuat dan ditugaskan kepada pengguna atau peran. Pengumpulan data Catat stempel waktu saat tugas persetujuan dibuat atau saat status permintaan menunjukkan bahwa permintaan menunggu pemberi persetujuan tertentu. Jenis peristiwa inferred | |||
| Tahap persetujuan disetujui | Pemberi persetujuan memberikan persetujuan atas permintaan pada tahap yang menjadi tanggung jawabnya dalam alur kerja. Tindakan ini memindahkan permintaan ke tahap berikutnya atau mendekatkannya ke persetujuan akhir. | ||
| Mengapa ini penting Analisis durasi dari awal hingga akhir tahap persetujuan menunjukkan kinerja tiap pemberi persetujuan dan pembagian beban kerja. Sumber data Dicatat saat pengguna melakukan tindakan tertentu, berdasarkan log riwayat persetujuan atau data transaksi alur kerja. Pengumpulan data Ambil data peristiwa persetujuan dari riwayat persetujuan atau log alur kerja, termasuk nama pemberi persetujuan dan stempel waktunya. Jenis peristiwa explicit | |||
| Tahap persetujuan ditolak | Pemberi persetujuan menolak permintaan pada tahap yang menjadi tanggung jawabnya. Biasanya, permintaan dikembalikan kepada pemohon untuk diperbaiki. Tindakan ini menghentikan alur persetujuan. | ||
| Mengapa ini penting Aktivitas ini sering menyebabkan pekerjaan harus diulang. Dengan melacak penolakan, Anda dapat menemukan alasan umum, kebutuhan pelatihan, dan tahap persetujuan yang bermasalah. Sumber data Dicatat saat pengguna melakukan tindakan tertentu, berdasarkan log riwayat persetujuan atau data transaksi alur kerja. Pengumpulan data Ambil data peristiwa penolakan dari riwayat persetujuan atau log alur kerja, termasuk nama pemberi persetujuan dan stempel waktunya. Jenis peristiwa explicit | |||
Panduan ekstraksi
Metode ekstraksi berbeda-beda untuk setiap sistem. Untuk petunjuk lengkap,
baca panduan ETL kami atau pilih proses dan sistem tertentu.
Siap memulai?
Pilih panduan ekstraksi khusus sistem untuk menyesuaikan pengumpulan data, atau gunakan templat umum ini sebagai kerangka fleksibel untuk memulai analisis proses Purchase to Pay, Requisition.
Tingkatkan proses P2P Requisition dan wujudkan efisiensi sekarang
Temukan hambatan, tingkatkan kepatuhan, dan hemat biaya di seluruh proses P2P Anda.
Tidak perlu kartu kredit. Penyiapan hanya perlu beberapa menit.