Tantangan process mining: cara menjaga proyek tetap berjalan
Daftar periksa praktis untuk mengenali dan mencegah kegagalan proyek.
Tantangan process mining biasanya muncul sebelum proyek benar-benar terhambat: data sulit dipercaya, cakupan terus melebar, atau tidak ada yang menindaklanjuti temuan. Gunakan daftar periksa ini untuk mengenali gejala, memahami penyebab, dan menentukan tindakan pencegahan.
Tantangan process mining apa yang dapat menghambat proyek?
Proyek paling sering terhambat oleh masalah data, metode, penanggung jawab organisasi, atau perangkat. Periksa setiap area untuk menemukan gejalanya, kemungkinan penyebab, dan tindakan praktis.
Transformasi itu sulit. Upaya yang dilakukan dengan niat baik pun sering kehilangan momentum atau gagal sebelum benar-benar dimulai. Tidak ada yang berniat gagal, tetapi penelitian menunjukkan bahwa 70 persen perusahaan mengalaminya.
Data: quality, access, scope, and history
Gejala: Kasus tidak muncul dalam analisis, urutan aktivitas terlihat keliru, atau langkah yang sama muncul dengan beberapa nama.
Penyebab: ID kasus mungkin tidak cocok di berbagai sistem. Stempel waktu mungkin menggunakan zona waktu atau tingkat detail yang berbeda. Nama aktivitas mungkin bervariasi, sedangkan peristiwa yang hilang dapat membuat kasus tampak tidak lengkap. Akses data juga dapat tertunda karena penanggung jawab tidak jelas, persyaratan privasi, atau kolom sumber yang tidak tersedia.
Pencegahan: Mulailah dengan satu proses. Pastikan ID kasus konsisten, nama aktivitas bermakna, stempel waktu dapat digunakan, dan jumlah kasus lengkap cukup untuk mewakili pekerjaan. Pastikan persyaratan akses dan privasi bersama pemilik data sejak awal. Catat celah yang ada dan tentukan apakah celah tersebut memengaruhi pertanyaan yang perlu dijawab.
Jangan berasumsi sistem tertentu akan selalu menyediakan data yang rapi. Periksa ekstrak yang Anda miliki, apa pun sumbernya. Dataset terarah dengan kasus lengkap biasanya lebih berguna daripada ekstrak luas dengan kolom yang hilang.
Untuk memeriksa satu per satu masalah umum pada event log, periksa log Anda terhadap empat masalah umum.
Metode: tidak ada pertanyaan, analisis hanya sekali, atau tidak ada kondisi awal
Gejala: Tim Anda memiliki dashboard, tetapi tidak sepakat tentang hal yang perlu diperbaiki, atau mengulang analisis tanpa mengetahui apakah ada perubahan.
Penyebab: Proyek dimulai dari alat atau dataset, bukan dari keputusan yang perlu diambil tim. Tanpa kondisi awal, Anda tidak dapat membandingkan proses sebelum dan sesudah intervensi. Analisis satu kali juga semakin kurang berguna saat proses berubah.
Pencegahan: Rumuskan pertanyaan dengan istilah operasional. Misalnya, cari tahu di bagian mana langkah tertentu dalam proses mengalami keterlambatan atau varian mana yang paling sering dikerjakan ulang. Pilih KPI yang mencerminkan masalah, catat kondisi awal, dan sepakati kapan hasilnya akan ditinjau kembali. Jadikan process mining bagian dari siklus perbaikan berulang, bukan laporan yang disimpan begitu saja.
Organisasi: tidak ada penanggung jawab, mandat, atau tindak lanjut
Gejala: Para pemangku kepentingan menganggap hasilnya menarik, tetapi tidak ada yang memutuskan tindakan selanjutnya. Pemilik proses tidak dilibatkan atau dukungan mereda setelah presentasi pertama.
Penyebab: Orang yang memahami pekerjaan mungkin tidak dilibatkan, atau tidak ada yang memiliki wewenang dan waktu untuk bertindak. Jika proyek tidak terkait dengan prioritas bisnis, proyek bisa terasa seperti pekerjaan tambahan, bukan cara untuk mengatasi masalah yang sedang dihadapi.
Pencegahan: Tetapkan pemilik proses dan sponsor eksekutif sebelum analisis dimulai. Libatkan orang yang menjalankan dan mengelola pekerjaan. Sepakati keputusan yang perlu didukung oleh analisis, tetapkan sasaran yang realistis, dan jadwalkan peninjauan.
Alat: penyiapan, kecocokan, dan kerumitan
Gejala: Tim Anda menghabiskan lebih banyak waktu untuk menyiapkan koneksi atau mempelajari alat daripada menjawab pertanyaan tentang proses. Setiap perubahan membutuhkan bantuan spesialis.
Penyebab: Alat tersebut mungkin tidak cocok dengan format data, keterampilan tim, atau cakupan proyek Anda. Penyiapan yang rumit dapat menunda analisis pertama. Lisensi yang tidak sesuai dengan tujuan penggunaan juga dapat membatasi keterlibatan.
Cara mencegahnya: Uji alur kerja dengan satu file ekspor sebelum menerapkannya secara luas. Pastikan alat tersebut dapat digunakan dengan data yang tersedia dan orang yang bertanggung jawab atas analisis mampu menggunakannya. Pahami apa yang diukur, dimodelkan, atau disimulasikan oleh alat tersebut. Jangan berharap alat itu menjalankan perubahan proses untuk Anda.
Masalah terbesar yang saya lihat adalah proyek dimulai dengan cakupan terlalu luas dan akhirnya sangat rumit. Mulailah dari yang kecil lalu kembangkan: satu proses, satu keputusan, satu tolok ukur.
Apa yang dilakukan ProcessMind untuk mengatasi pola kegagalan umum?
ProcessMind menggabungkan impor data, process mining, model proses, dasbor, simulasi, dan publikasi dalam satu platform. Ini dapat mengurangi perpindahan pekerjaan antara analisis dan dokumentasi yang terpisah, sementara keputusan tentang proses tetap berada di tangan tim Anda.
| Pola kegagalan | Yang biasanya terjadi | Cara ProcessMind menangani hal ini |
|---|---|---|
| Persiapan data menunda analisis pertama | Tim menghabiskan waktu mencari cara menyusun dan memetakan data ekspor sebelum dapat menelusuri proses. | Anda dapat mengimpor file CSV/XLSX dan menggunakan rekomendasi data AI untuk membantu menyiapkan data. Tinjau rekomendasi tersebut dengan membandingkannya dengan sumber data dan pertanyaan analisis Anda. |
| Analisis dan dokumentasi proses tidak selaras | Data peristiwa menunjukkan apa yang terjadi, sementara diagram terpisah menggambarkan apa yang diharapkan terjadi. | Anda dapat menambang proses dan menyimpan modelnya dalam satu catatan proses, sehingga analisis dan dokumentasi proses tetap terhubung. |
| Tim tidak memiliki gambaran bersama tentang kesehatan proses | Temuan tersimpan dalam laporan terpisah, sehingga kinerja proses sulit ditinjau secara konsisten. | Dasbor mencakup Kesehatan Proses, tempat tim dapat meninjau ukuran proses bersama-sama. |
| Tim tidak dapat memeriksa kemungkinan perubahan sebelum mengambil keputusan | Perubahan yang diusulkan dibahas tanpa cara terstruktur untuk menelaah dampak yang mungkin terjadi. | Simulasi membantu Anda menelaah skenario sebelum memutuskan perubahan. Simulasi tidak menjalankan perubahan tersebut. |
| Kepemilikan proses dan revisi tidak jelas | Dokumen beredar tanpa riwayat publikasi yang jelas atau penanggung jawab yang terlihat. | Publikasi dan riwayat versi membantu tim mengelola konten proses dan melacak revisi. |
Anda tetap memerlukan pertanyaan yang jelas, kumpulan data yang sesuai, dan orang yang dapat memvalidasi temuan. Platform ini mendukung pekerjaan tersebut, tetapi tidak menggantikan penanggung jawab proses atau menentukan perubahan yang perlu dilakukan organisasi Anda. Lihat dukungan ProcessMind untuk analisis process mining.
Bagaimana mengenali proyek yang mulai bermasalah?
Dalam tinjauan proyek, hubungkan setiap gejala dengan penyebab, tindakan perbaikan, dan penanggung jawab yang jelas. Gunakan daftar ini untuk mengenali risiko sebelum menjadi kebiasaan dalam proyek.
Analisis pertama terus tertunda
Kemungkinan penyebab: Akses, kepemilikan, atau persyaratan penyiapan data belum diselesaikan.
Tindakan: Pastikan siapa pemilik data, kolom apa yang diperlukan, dan bagaimana cara mengaksesnya. Uji dengan file ekspor kecil.
Proyek terus menambah proses dan pertanyaan
Kemungkinan penyebab: Cakupan proyek tidak dikaitkan dengan satu keputusan.
Tindakan: Kembali ke pertanyaan awal. Tunda pembahasan proses lain sampai analisis pertama selesai.
Peta proses tidak sesuai dengan pemahaman tim
Kemungkinan penyebab: Ada peristiwa yang hilang, nama aktivitas berbeda-beda, atau batas proses belum jelas.
Tindakan: Tinjau contoh kasus bersama pakar proses dan perbaiki definisi peristiwa.
Tidak ada yang bisa memastikan apakah proses membaik
Kemungkinan penyebab: Tim belum memiliki tolok ukur atau KPI yang disepakati.
Tindakan: Catat KPI saat ini, lalu tentukan kapan dan bagaimana Anda akan mengukurnya kembali.
Temuan dipaparkan, tetapi tidak ada perubahan yang dilakukan
Kemungkinan penyebab: Tidak ada yang bertanggung jawab atas keputusan atau langkah berikutnya.
Tindakan: Tunjuk penanggung jawab, sepakati tindakan, dan tetapkan tanggal peninjauan.
Orang-orang meragukan analisis atau enggan menggunakannya
Kemungkinan penyebab: Proyek dirancang tanpa melibatkan orang yang menjalankan pekerjaan.
Tindakan: Libatkan mereka untuk memvalidasi proses dan menentukan pertanyaan yang akan dijawab.
Setiap pembaruan membutuhkan bantuan spesialis
Kemungkinan penyebab: Alur kerja terlalu rumit atau pengetahuan hanya dimiliki satu orang.
Tindakan: Dokumentasikan langkah-langkahnya dan tingkatkan kemampuan orang yang akan memelihara analisis.
Jika gejala yang sama muncul dalam beberapa tinjauan, catat sebagai risiko proyek. Tuliskan penyebab, tindakan, dan penanggung jawabnya agar Anda dapat melihat apakah proyek mengalami kemajuan atau hanya mengulang pembahasan yang sama.
Masalah terkait proses apa yang perlu diperiksa?
Tantangan terkait proses sering muncul karena batas proses tidak jelas, definisi tidak konsisten, atau ada kesenjangan antara proses yang didokumentasikan dan pekerjaan yang tercatat dalam data peristiwa.
Model proses terlalu terperinci untuk dipahami
Gejala: Tim Anda berdebat tentang langkah mana yang perlu dimasukkan dalam analisis, atau model terlalu rumit untuk membantu mengambil keputusan.
Penyebab: Proses nyata memiliki variasi, pengecualian, dan serah terima. Memetakan setiap detail sebelum mengajukan pertanyaan yang terarah hanya menambah kerumitan. Model juga dapat menyesatkan jika dianggap sebagai gambaran lengkap untuk setiap kasus.
Cara mencegahnya: Tetapkan batas proses dan fokus pada tahapan penting untuk menjawab pertanyaan Anda. Gunakan process mining untuk melihat variasi kasus, lalu telusuri variasi yang relevan dengan masalah. Minta orang yang menjalankan pekerjaan untuk memvalidasi data peristiwa.
Tim berbeda pendapat tentang nama aktivitas atau penyelesaian kasus
Gejala: Tim yang berbeda menggunakan nama berbeda untuk aktivitas yang sama atau tidak sepakat tentang kapan suatu kasus selesai.
Penyebab: Definisi proses berubah-ubah di berbagai departemen, sistem, atau dokumentasi. Akibatnya, perbandingan menjadi sulit dan sumber keterlambatan bisa tersembunyi.
Cara mencegahnya: Sepakati definisi kasus dan arti aktivitas utama sebelum membandingkan hasil. Catat asumsi dan transformasi data agar analisis dapat ditinjau dan diulang.
Peta proses dan analisis dikelola secara terpisah
Gejala: Tim Anda memiliki peta proses, tetapi belum memiliki cara yang konsisten untuk menggunakannya bersama analisis.
Penyebab: Dokumentasi dan data peristiwa dikelola secara terpisah. Diagram mungkin menggambarkan proses yang seharusnya terjadi, sementara log peristiwa menunjukkan apa yang benar-benar terjadi.
Cara mencegahnya: Gunakan model sebagai acuan, lalu bandingkan dengan proses yang teramati. Telusuri penyimpangan yang relevan dengan pertanyaan bisnis, bukan berusaha menghilangkan semua variasi.
Masalah organisasi apa yang dapat menghambat pekerjaan?
Tantangan organisasi sering muncul ketika proyek tidak memiliki tujuan bisnis yang jelas, pemahaman bersama, atau rencana setelah uji coba.
Pemangku kepentingan mempertanyakan manfaat proyek
Gejala: Orang-orang menolak perubahan berdasarkan temuan atau mempertanyakan relevansi analisis.
Penyebab: Proyek mungkin tidak terkait dengan prioritas bisnis saat ini. Orang-orang juga bisa meragukan temuan jika tidak memahami cara analisis dilakukan atau tidak dilibatkan dalam menentukan pertanyaan.
Cara mencegahnya: Jelaskan tujuan, cakupan, dan batas analisis. Libatkan pemilik proses dan tim lini depan sejak awal, lalu kaitkan pekerjaan dengan sasaran operasional yang spesifik. Bagikan bukti dan asumsi, bukan hanya kesimpulan.
Proyek bergantung pada satu analis atau tim pusat yang kecil
Gejala: Pekerjaan melambat saat analis tertentu tidak tersedia, atau tim lain tidak mampu memelihara analisis.
Penyebab: Pengetahuan tentang data, definisi, dan langkah analisis belum dibagikan.
Cara mencegahnya: Dokumentasikan proses, definisi data, dan keputusan. Latih orang yang akan menggunakan temuan, lalu tetapkan cara yang jelas untuk mengajukan perubahan atau meninjau hasil. Center of Excellence dapat mengoordinasikan pekerjaan lintas tim, tetapi tidak menggantikan pemilik proses.
Uji coba berakhir tanpa keputusan tentang langkah selanjutnya
Gejala: Uji coba selesai, tetapi belum ada rencana untuk melanjutkan, menyesuaikan, atau menghentikannya.
Penyebab: Tim menganggap uji coba sebagai hasil akhir, bukan sebagai pengujian pendekatan yang dapat diulang.
Cara mencegahnya: Sebelum uji coba, tentukan bukti yang diperlukan untuk melangkah ke tahap berikutnya. Tinjau hasil bersama sponsor dan pemilik proses. Perluas cakupan hanya jika data, metode, dan penanggung jawab mendukungnya.
Apa dampak jika tantangan process mining diabaikan?
Mengabaikan pola kegagalan dapat menghabiskan waktu tanpa memberi tim Anda dasar yang dapat diandalkan untuk bertindak. Dampaknya bergantung pada proses, data, dan konteks operasional Anda.
| Tantangan yang belum teratasi | Dampak yang mungkin terjadi seiring waktu |
|---|---|
| Kualitas data buruk | Analis menghabiskan waktu untuk memeriksa dan memperbaiki data ekspor. Tim bisa bertindak berdasarkan hasil yang tidak mencerminkan proses sebenarnya. |
| Cakupan terus meluas | Analisis pertama yang berguna tertunda, dan pemangku kepentingan mungkin kehilangan kepercayaan sebelum tim menjawab pertanyaan awal. |
| Tidak ada tolok ukur | Anda tidak dapat mengetahui apakah perubahan memperbaiki proses. Akibatnya, tim mungkin mengulang pekerjaan atau terlalu cepat menghentikan tindakan yang sebenarnya bermanfaat. |
| Tidak ada penanggung jawab | Temuan tidak ditindaklanjuti, sementara keterlambatan, pengerjaan ulang, atau pengecualian yang sama terus terjadi. |
| Alat tidak sesuai kebutuhan | Penyiapan dan dukungan spesialis menyita waktu yang seharusnya dapat digunakan untuk analisis dan perbaikan. |
| Tidak ada rencana untuk mengulang analisis | Dampak perubahan proses tidak terukur, dan temuan awal makin tidak relevan seiring perubahan cara kerja. |
Perkirakan dampaknya dengan data Anda sendiri: waktu untuk menyiapkan data ekspor, biaya pengerjaan ulang, jeda antara ditemukannya masalah dan tindakan yang diambil, serta upaya untuk mengulang analisis. Jangan memperkirakan penghematan sebelum memiliki tolok ukur dan cara untuk mengukur perubahan.
Apa yang perlu diperiksa sebelum analisis pertama?
Gunakan daftar periksa ini sebelum analisis dan tinjau kembali setiap kali proyek dievaluasi. Daftar ini juga dapat menjadi titik awal untuk menyusun rencana proyek.
- Pilih satu proses dan tentukan batasannya. Tetapkan titik awal dan akhir kasus. Jangan masukkan proses lain ke dalam cakupan sebelum pertanyaan pertama terjawab.
- Tuliskan pertanyaan analisis. Jelaskan keputusan yang perlu diambil tim, bukan sekadar meminta pencarian peluang secara umum.
- Tentukan pemilik proses dan sponsor. Pastikan siapa yang dapat memvalidasi proses, menentukan langkah berikutnya, dan mendukung pekerjaan ini.
- Pastikan akses data dan persyaratan privasi. Tentukan pemilik data, kolom yang diperlukan, dan batasan sebelum menyusun analisis.
- Periksa kualitas data. Validasi pengenal kasus, stempel waktu, nama aktivitas, dan kelengkapan kasus.
- Catat data dasar. Pilih KPI yang sesuai dengan pertanyaan, lalu dokumentasikan nilainya saat ini sebelum melakukan perubahan.
- Sepakati ukuran keberhasilan. Tetapkan target yang dapat diukur dan tanggal tinjauan. Penggunaan dasbor saja tidak menunjukkan hasil proses.
- Libatkan orang yang menjalankan pekerjaan. Minta mereka memeriksa apakah data peristiwa dan interpretasi proses sudah masuk akal.
- Pastikan analisis dapat diulang. Dokumentasikan definisi data, asumsi, dan langkah-langkahnya agar tim dapat menjalankannya lagi.
- Tinjau dan tindak lanjuti. Tunjuk pemilik untuk setiap tindakan yang disepakati, lalu bandingkan proses dengan data dasar pada tinjauan berikutnya.
- Perluas berdasarkan bukti. Perluas cakupan hanya setelah proses pertama memiliki data yang andal, analisis yang berguna, dan penanggung jawab yang jelas.
Untuk bantuan menyiapkan log peristiwa, baca cara membuat log peristiwa untuk process mining. Jika Anda masih menentukan proses pertama, mulailah dengan satu proses yang cakupannya jelas.
Seperti apa proyek pertama dengan cakupan yang jelas?
Proyek dengan cakupan yang jelas dimulai dari satu proses, satu keputusan, dan tolok ukur yang dapat diukur kembali oleh tim.
Bayangkan sebuah tim yang menyelidiki keterlambatan dalam satu proses persetujuan. Tim tersebut menetapkan batas proses dan mencari tahu di bagian mana kasus paling lama menunggu persetujuan. Pemilik proses dan pemilik data memastikan pengenal kasus, nama aktivitas, stempel waktu, dan persyaratan akses.
Tim mencatat KPI awal, lalu meninjau analisis pertama bersama orang-orang yang mengelola dan menjalankan pekerjaan. Tim menemukan titik spesifik untuk ditelusuri, menyepakati tindakan, dan menunjuk penanggung jawab. Pada tinjauan berikutnya, tim menjalankan analisis yang sama dan membandingkan hasilnya dengan tolok ukur awal.
Hasil awal yang berguna adalah cara yang dapat diulang untuk melihat apa yang terjadi, menentukan hal yang perlu ditelusuri, dan memeriksa apakah perubahan membawa dampak. Setelah pendekatan itu berhasil untuk satu proses, tim dapat memutuskan apakah pendekatan tersebut siap diterapkan di proses lain.
Cegah kegagalan dengan menguji pendekatannya
Uji pendekatan dengan satu proses yang cakupannya terbatas, satu file ekspor, dan satu tolok ukur sebelum memperluas proyek.
Where to Go From Here
Proyek Anda berisiko terhenti karena data, cakupan, atau penanggung jawabnya belum jelas.
