# Laporan Akhir Eksplorasi Data ## 1. Pendahuluan ### 1. Pendahuluan: Memahami Efisiensi dan Beban Kerja Melalui Analisis Tiket dalam Proses Laporan ini menyajikan Analisis Data Eksplorasi (EDA) komprehensif terhadap kumpulan data "tiket yang sedang berjalan" (`on_progress_ticket___22062026_sheet1`). Tujuan utama dari analisis ini adalah untuk mendapatkan pemahaman mendalam mengenai karakteristik operasional, pola permintaan pengguna, dan efisiensi dalam penanganan tiket. Dengan mengidentifikasi tren, anomali, dan distribusi beban kerja, kita dapat merumuskan rekomendasi yang berbasis data untuk mengoptimalkan alokasi sumber daya, menyederhanakan proses, dan pada akhirnya meningkatkan kepuasan pengguna. **1. Gambaran Umum Dataset** Dataset utama, `on_progress_ticket___22062026_sheet1`, berisi 539 entri tiket yang sedang berjalan. Setiap entri menyediakan detail penting seperti `ticket_id`, `ticket_createDate`, `ticket_name`, `ticket_desc`, `ticket_type`, `ticket_picNip`, serta informasi terkait klien termasuk `name`, `phone_number`, `email`, `client_superior`, dan `client_superior_name`. Kolom `Selisih Days` juga disertakan, yang kemungkinan besar mengukur waktu yang berlalu sejak pembuatan tiket. Rentang waktu pembuatan tiket dalam dataset ini membentang dari **19 Agustus 2025** hingga **22 Juni 2026**. Analisis tren bulanan menunjukkan adanya fluktuasi signifikan dalam volume tiket yang dibuat, dengan lonjakan yang jelas pada bulan Maret dan Juni 2026. Hal ini mengindikasikan periode beban kerja yang lebih tinggi atau peningkatan aktivitas pengguna. **Tren Pembuatan Tiket Bulanan** | year_month | Freq (Tiket) | |:-----------|:-------------| | 2025-08 | 4 | | 2025-09 | 1 | | 2025-10 | 2 | | 2025-11 | 3 | | 2025-12 | 3 | | 2026-01 | 6 | | 2026-02 | 32 | | 2026-03 | 181 | | 2026-04 | 103 | | 2026-05 | 81 | | 2026-06 | 123 | ![Visualisasi](/agent/api/download?file=/tmp/monthly_ticket_creation.png) Selain itu, terdapat tabel `on_progress_ticket___22062026_sheet2`. Setelah inspeksi dan pembersihan, terungkap bahwa tabel ini berisi data transaksional yang tidak terkait dengan manajemen tiket (misalnya, `trans_port_id`, `trans_currency`, `trans_type` BUY/SELL, dll.). Oleh karena itu, tabel ini dianggap tidak relevan untuk tujuan analisis tiket dalam laporan ini. **2. Kualitas Data dan Tantangan Awal** Pemeriksaan awal terhadap `on_progress_ticket___22062026_sheet1` menyoroti beberapa aspek penting mengenai kualitas data: * **Nilai yang Hilang:** Beberapa kolom krusial memiliki nilai yang hilang, yang dapat memengaruhi kelengkapan dan akurasi analisis: * `email`: 83 nilai hilang * `name` (nama pembuat tiket): 24 nilai hilang * `phone_number`: 19 nilai hilang * `task_id`, `task_begin`, `task_pic`, `mem_name.1`: Masing-masing 5 hingga 11 nilai hilang * `client_superior`, `client_superior_name`: Masing-masing 3 nilai hilang Nilai yang hilang pada informasi kontak (`email`, `name`, `phone_number`) dapat menjadi hambatan dalam komunikasi proaktif dengan pembuat tiket atau pelacakan masalah. * **Tipe Data:** Sebagian besar kolom teks terdeteksi sebagai `str`, sementara tanggal masih dalam format `str` dan perlu dikonversi untuk analisis berbasis waktu yang lebih mendalam. **3. Karakteristik Utama Tiket** * **Distribusi Tipe Tiket:** Mayoritas tiket yang tercatat adalah permintaan `REPORTING`, yang mengindikasikan bahwa sebagian besar beban kerja tim PIC terkait dengan penarikan data atau pembuatan laporan. Tiket `DEVELOPMENT` dan `BUGFIX` memiliki proporsi yang jauh lebih kecil. **Distribusi Tipe Tiket** | ticket_type | count | |:--------------|:--------| | REPORTING | 519 | | DEVELOPMENT | 13 | | BUGFIX | 7 | * **Penanggung Jawab Tiket (PIC):** Sebuah temuan yang menonjol adalah bahwa seluruh 539 tiket dalam dataset ini ditangani oleh satu PIC yang sama, yaitu **L260151 (Pham Ngoc Yen Huy)**. Hal ini dapat mengindikasikan bahwa dataset ini mungkin telah difilter untuk satu PIC tertentu atau bahwa individu ini memiliki tanggung jawab yang luar biasa luas atas semua tiket yang sedang berjalan. Perlu klarifikasi lebih lanjut mengenai ruang lingkup data. * **Peminta Tiket Terbanyak (`client_superior_name`):** Analisis menunjukkan konsentrasi permintaan tiket dari beberapa superior klien tertentu, dengan Yasinta Hendrata menjadi yang paling aktif. **Top 10 Peminta Tiket** | client_superior_name | count | |:------------------------|:--------| | Yasinta Hendrata | 224 | | Bahar Budianto | 78 | | Kamilo Fideliant Iqbal | 56 | | Joestine Soeseno, MA | 49 | | Arthur Timotius Lembong | 33 | | Handry Suryadi | 18 | | Hendrykus Uca Sukarsa | 12 | | Agung Imawan | 12 | | Janto Kusmanto | 11 | | VIRYA CHANDRA | 11 | Sebagian besar permintaan dari para superior klien ini juga didominasi oleh tiket `REPORTING`. **4. Analisis "Selisih Days" dan Anomali Kritis** Kolom `Selisih Days` adalah metrik kunci yang kemungkinan mengukur durasi penyelesaian tiket atau waktu berlalu sejak tiket dibuat. Statistik deskriptif untuk kolom ini adalah sebagai berikut: * **Rata-rata:** 52.95 hari * **Standar Deviasi:** 43.26 hari * **Minimum:** -36 hari * **Maksimum:** 251 hari * **Kuartil Pertama (25%):** 18 hari * **Median (50%):** 53 hari * **Kuartil Ketiga (75%):** 84 hari Distribusi `Selisih Days` menunjukkan bahwa sebagian besar tiket memiliki durasi penyelesaian positif. Namun, ada rentang yang luas, dengan beberapa tiket membutuhkan waktu penyelesaian yang sangat panjang (hingga 251 hari), menunjukkan adanya tiket yang tertunda atau kompleks. ![Visualisasi](/agent/api/download?file=/tmp/selisih_days_histogram.png) Anomali yang paling signifikan adalah keberadaan **21 tiket dengan nilai `Selisih Days` negatif**. Secara logis, durasi penyelesaian atau waktu yang berlalu sejak pembuatan tiket tidak dapat bernilai negatif. Ini adalah indikator kuat adanya masalah dalam pencatatan data atau definisi `Selisih Days` yang tidak konsisten. Nilai negatif ini bisa berasal dari: 1. **Kesalahan Entri Data:** Tanggal penyelesaian dicatat sebelum tanggal pembuatan. 2. **Definisi Kolom yang Salah:** `Selisih Days` mungkin memiliki arti lain, seperti "hari tersisa" hingga batas waktu, bukan durasi yang berlalu. 3. **Masalah Sinkronisasi Waktu:** Perbedaan zona waktu atau sistem pencatatan waktu. Investigasi mendalam terhadap tiket-tiket ini sangat penting untuk memperbaiki kualitas data dan memastikan interpretasi metrik yang akurat. Berikut adalah beberapa contoh tiket dengan `Selisih Days` negatif: | ticket_id | ticket_createDate | ticket_name | Selisih Days | |:----------------|:--------------------|:-------------------------------------------|-------------:| | TKT202605280038 | 2026-05-28 17:41:32 | Dashboard update: Produk Baru | -36 | | TKT202606180005 | 2026-06-18 10:04:32 | QUERY LAPORAN LPB RETUR PPP PERIODE MEI... | -24 | | TKT202606180005 | 2026-06-18 10:04:32 | QUERY LAPORAN LPB RETUR PPP PERIODE MEI... | -25 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -28 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -29 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -30 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -31 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -32 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -35 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -11 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -14 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -15 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -16 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -16 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -18 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -17 | | TKT202606180005 | 2026-06-18 10:04:32 | QUERY LAPORAN LPB RETUR PPP PERIODE MEI... | -3 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -1 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -2 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -4 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -7 | Perbandingan rata-rata `Selisih Days` berdasarkan tipe tiket menunjukkan bahwa tiket `BUGFIX` dan `DEVELOPMENT` cenderung memiliki durasi yang sedikit lebih lama dibandingkan dengan `REPORTING`, meskipun dengan jumlah sampel yang lebih kecil. **Rata-rata Selisih Days berdasarkan Tipe Tiket** | ticket_type | Selisih Days | |:--------------|:-------------| | BUGFIX | 70.9 | | DEVELOPMENT | 61.0 | | REPORTING | 52.5 | ![Visualisasi](/agent/api/download?file=/tmp/selisih_days_by_ticket_type_boxplot.png) **5. Kesimpulan Awal dan Rekomendasi** Berdasarkan eksplorasi awal ini, beberapa poin kunci dan rekomendasi dapat dirumuskan: * **Anomali `Selisih Days` Negatif:** Ini adalah masalah kualitas data yang paling mendesak. Rekomendasi: * Lakukan investigasi untuk memahami penyebab nilai negatif ini (kesalahan input, definisi kolom, atau masalah sistem). * Tentukan langkah korektif: apakah nilai-nilai ini perlu dibersihkan, dieliminasi, atau diklarifikasi definisinya. * **PIC Tunggal:** Klarifikasi apakah dataset ini memang hanya untuk satu PIC atau jika ada data PIC lain yang terlewat. Jika hanya satu PIC, ini menyoroti beban kerja yang terkonsentrasi pada individu tersebut. * **Nilai Hilang pada Informasi Kontak:** Pertimbangkan strategi untuk melengkapi nilai `email`, `name`, dan `phone_number` yang hilang, terutama untuk tiket yang sedang berjalan, guna meningkatkan komunikasi dan efisiensi. * **Dominasi Tiket `REPORTING`:** Meskipun normal, dominasi tiket pelaporan menunjukkan potensi untuk mengotomatisasi atau menyederhanakan proses pelaporan, sehingga PIC dapat mengalokasikan waktu lebih banyak untuk tiket `DEVELOPMENT` atau `BUGFIX` yang mungkin lebih kompleks. * **Analisis Beban Kerja Klien:** Dengan Yasinta Hendrata dan Bahar Budianto sebagai peminta tiket utama, mungkin ada pola atau kebutuhan khusus dari klien-klien ini yang dapat dioptimalkan. * **Irrelevansi `Sheet2`:** Konfirmasikan bahwa `on_progress_ticket___22062026_sheet2` memang tidak relevan dengan analisis tiket dan dapat diabaikan untuk fokus analisis lebih lanjut. Analisis lebih lanjut akan berfokus pada pembersihan data, eksplorasi mendalam terhadap pola durasi tiket, identifikasi faktor-faktor yang memengaruhi waktu penyelesaian, dan visualisasi yang lebih canggih untuk memberikan wawasan operasional yang lebih kaya. ## 2. Ringkasan Eksekutif ## 2. Ringkasan Eksekutif Laporan ini menyajikan ringkasan temuan kunci dari Analisis Data Eksplorasi (EDA) terhadap data tiket dalam proses, yang bertujuan untuk mengungkap pola operasional, mengidentifikasi anomali, dan memberikan rekomendasi strategis. Analisis utama difokuskan pada dataset `on_progress_ticket___22062026_sheet1`, yang berisi 539 entri tiket yang sedang berjalan, mencakup periode dari Agustus 2025 hingga Juni 2026. ### Poin-Poin Utama: 1. **Volume dan Tren Pembuatan Tiket:** Dataset ini mencatat 539 tiket yang dibuat dalam rentang waktu hampir satu tahun. Terjadi lonjakan signifikan dalam volume tiket pada bulan-bulan terakhir data, terutama di Maret dan Juni 2026, menunjukkan peningkatan aktivitas atau beban kerja. **Tren Pembuatan Tiket Bulanan** | Bulan/Tahun | Jumlah Tiket | |:------------|:-------------| | 2025-08 | 4 | | 2025-09 | 1 | | 2025-10 | 2 | | 2025-11 | 3 | | 2025-12 | 3 | | 2026-01 | 6 | | 2026-02 | 32 | | 2026-03 | 181 | | 2026-04 | 103 | | 2026-05 | 81 | | 2026-06 | 123 | ![Visualisasi](/agent/api/download?file=/tmp/monthly_ticket_creation.png) 2. **Kualitas Data dan Tantangan:** * **Nilai Hilang:** Terdapat nilai hilang yang substansial pada beberapa kolom penting, khususnya informasi kontak seperti `email` (83 tiket), `name` (24 tiket), dan `phone_number` (19 tiket). Ini dapat menghambat komunikasi dan pelacakan tiket. * **Tipe Data:** Kolom tanggal seperti `ticket_createDate` masih dalam format teks, memerlukan konversi untuk analisis berbasis waktu yang lebih akurat. * **Irrelevansi Data Sekunder:** Tabel `on_progress_ticket___22062026_sheet2` diidentifikasi berisi data transaksional yang tidak relevan dengan manajemen tiket, sehingga diabaikan dalam analisis ini. 3. **Karakteristik dan Beban Kerja Tiket:** * **Dominasi Tipe Tiket REPORTING:** Sebanyak 519 dari 539 tiket (sekitar 96%) adalah permintaan `REPORTING`. Ini menunjukkan bahwa sebagian besar waktu dan sumber daya dialokasikan untuk tugas pelaporan. **Distribusi Tipe Tiket** | Jenis Tiket | Jumlah Tiket | |:--------------|:-------------| | REPORTING | 519 | | DEVELOPMENT | 13 | | BUGFIX | 7 | * **Beban Kerja Terkonsentrasi pada Satu PIC:** Seluruh 539 tiket dalam dataset ini ditangani oleh satu PIC tunggal, yaitu **L260151 (Pham Ngoc Yen Huy)**. Hal ini menimbulkan pertanyaan mengenai ruang lingkup dataset (apakah ini hanya data PIC ini saja?) dan potensi beban kerja yang sangat terkonsentrasi pada satu individu. * **Peminta Tiket Utama:** Beberapa superior klien secara signifikan lebih aktif dalam mengajukan tiket. **Yasinta Hendrata** adalah peminta tiket terbanyak dengan 224 tiket, diikuti oleh **Bahar Budianto** (78 tiket). Mayoritas permintaan dari klien-klien ini juga didominasi oleh tiket `REPORTING`. **Top 10 Peminta Tiket (Berdasarkan `client_superior_name`)** | Nama Superior Klien | Jumlah Tiket | |:------------------------|:-------------| | Yasinta Hendrata | 224 | | Bahar Budianto | 78 | | Kamilo Fideliant Iqbal | 56 | | Joestine Soeseno, MA | 49 | | Arthur Timotius Lembong | 33 | | Handry Suryadi | 18 | | Hendrykus Uca Sukarsa | 12 | | Agung Imawan | 12 | | Janto Kusmanto | 11 | | VIRYA CHANDRA | 11 | 4. **Analisis `Selisih Days` dan Anomali Kritis:** * **Gambaran Umum:** Kolom `Selisih Days` (kemungkinan mengukur durasi penyelesaian atau waktu berlalu sejak pembuatan tiket) memiliki rata-rata 53 hari, dengan rentang yang luas dari -36 hingga 251 hari. Ini menunjukkan adanya tiket yang diselesaikan dengan cepat dan beberapa yang membutuhkan waktu sangat lama. **Statistik Deskriptif 'Selisih Days'** | Metrik Statistik | Nilai | |:-----------------|:----------| | Rata-rata | 53 hari | | Median | 53 hari | | Standar Deviasi | 43 hari | | Minimum | -36 hari | | Maksimum | 251 hari | | Kuartil 1 (25%) | 18 hari | | Kuartil 3 (75%) | 84 hari | ![Visualisasi](/agent/api/download?file=/tmp/selisih_days_histogram.png) * **Anomali `Selisih Days` Negatif:** Ditemukan 21 tiket dengan nilai `Selisih Days` negatif. Ini adalah anomali data yang serius, karena durasi waktu tidak mungkin negatif. Hal ini kemungkinan mengindikasikan: * Kesalahan pencatatan data (tanggal penyelesaian sebelum tanggal pembuatan). * Misinterpretasi definisi `Selisih Days`. * Masalah teknis dalam sistem pencatatan waktu. **Contoh Tiket dengan 'Selisih Days' Negatif** | ticket_id | ticket_createDate | ticket_name | Selisih Days | |:----------------|:--------------------|:-------------------------------------------|-------------:| | TKT202605280038 | 2026-05-28 17:41:32 | Dashboard update: Produk Baru | -36 | | TKT202606180005 | 2026-06-18 10:04:32 | QUERY LAPORAN LPB RETUR PPP PERIODE MEI... | -24 | | TKT202606180005 | 2026-06-18 10:04:32 | QUERY LAPORAN LPB RETUR PPP PERIODE MEI... | -25 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -28 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -29 | * **Durasi per Jenis Tiket:** Tiket `BUGFIX` dan `DEVELOPMENT` memiliki rata-rata `Selisih Days` yang lebih tinggi (70,9 dan 61,0 hari) dibandingkan dengan tiket `REPORTING` (52,5 hari). Ini wajar mengingat kompleksitas yang mungkin lebih tinggi. **Rata-rata 'Selisih Days' Berdasarkan Jenis Tiket** | Jenis Tiket | Rata-rata Selisih Hari | |:--------------|:-----------------------| | BUGFIX | 70.9 | | DEVELOPMENT | 61.0 | | REPORTING | 52.5 | ![Visualisasi](/agent/api/download?file=/tmp/selisih_days_by_ticket_type_boxplot.png) * **Durasi per Peminta Tiket:** Rata-rata `Selisih Days` bervariasi antar superior klien. **Hendrykus Uca Sukarsa** memiliki rata-rata `Selisih Days` tertinggi (85,3 hari), sementara **Arthur Timotius Lembong** terendah (13,0 hari), menunjukkan perbedaan dalam jenis permintaan atau urgensi. **Rata-rata 'Selisih Days' Berdasarkan Nama Superior Klien (Top 10)** | Nama Superior Klien | Rata-rata Selisih Hari | |:------------------------|:-----------------------| | Hendrykus Uca Sukarsa | 85.3 | | Agung Imawan | 62.2 | | Bahar Budianto | 58.2 | | Yasinta Hendrata | 57.4 | | Janto Kusmanto | 53.4 | | Joestine Soeseno, MA | 48.0 | | Kamilo Fideliant Iqbal | 47.9 | | Handry Suryadi | 40.4 | | VIRYA CHANDRA | 25.8 | | Arthur Timotius Lembong | 13.0 | ### Rekomendasi Strategis: Berdasarkan temuan di atas, beberapa rekomendasi dapat diajukan untuk meningkatkan efisiensi dan kualitas manajemen tiket: 1. **Prioritaskan Pembersihan Data:** Segera lakukan investigasi mendalam terhadap 21 tiket dengan `Selisih Days` negatif. Pahami akar masalahnya (kesalahan input, definisi kolom, atau masalah sistem) dan kembangkan prosedur untuk mencegahnya di masa mendatang. Konversi kolom tanggal ke tipe data yang sesuai untuk analisis waktu yang lebih akurat. 2. **Evaluasi Beban Kerja PIC:** Verifikasi apakah dataset ini memang hanya mencakup tiket dari satu PIC saja. Jika demikian, perlu dilakukan evaluasi beban kerja Pham Ngoc Yen Huy (L260151) dan potensi perlunya distribusi ulang tugas atau dukungan tambahan untuk mencegah kelelahan dan memastikan efisiensi. 3. **Optimasi Penanganan Tiket REPORTING:** Dengan dominasi permintaan `REPORTING`, pertimbangkan solusi untuk mengotomatisasi atau menyederhanakan proses pembuatan laporan standar. Ini dapat membebaskan waktu PIC untuk tugas yang lebih kompleks seperti `DEVELOPMENT` atau `BUGFIX`. 4. **Peningkatan Kelengkapan Data Kontak:** Kembangkan strategi untuk mengisi nilai `email`, `name`, dan `phone_number` yang hilang. Informasi kontak yang lengkap sangat penting untuk komunikasi yang efektif dengan pembuat tiket. 5. **Analisis Kebutuhan Klien Utama:** Kaji lebih lanjut pola permintaan dari superior klien yang paling aktif (misalnya, Yasinta Hendrata, Bahar Budianto). Mungkin ada peluang untuk mengembangkan solusi yang lebih terstruktur atau pelatihan untuk memenuhi kebutuhan mereka secara lebih efisien. ## 3. Tinjauan Umum Data ## 3. Tinjauan Umum Data Bab ini menyajikan tinjauan umum yang mendalam tentang struktur, kualitas, dan karakteristik inti dari data tiket yang sedang berjalan. Fokus utama adalah pada tabel `on_progress_ticket___22062026_sheet1`, yang menjadi sumber informasi utama dalam analisis ini. Melalui eksplorasi ini, kami akan mengidentifikasi pola, anomali, serta potensi area untuk peningkatan kualitas data dan efisiensi operasional. ### 3.1 Gambaran Umum dan Struktur Data Dataset `on_progress_ticket___22062026_sheet1` berisikan **539 entri** tiket yang sedang dalam proses, mencakup informasi detail dari setiap tiket. Total terdapat **18 kolom** yang memberikan konteks mengenai identitas tiket, tanggal pembuatan, deskripsi, jenis tiket, PIC yang bertanggung jawab, hingga informasi pembuat dan atasan pembuat tiket. Rentang waktu pembuatan tiket dalam dataset ini sangat relevan untuk memahami dinamika beban kerja. Tiket paling awal dibuat pada **19 Agustus 2025**, dan tiket terbaru pada **22 Juni 2026**. Hal ini menunjukkan bahwa dataset mencakup periode hampir satu tahun. Sebagian besar kolom, seperti `ticket_id`, `ticket_name`, `ticket_desc`, `ticket_type`, `ticket_picNip`, `mem_name`, `ticket_createNip`, `name`, `email`, `client_superior`, dan `client_superior_name`, bertipe data string (objek). Kolom `ticket_createDate` dan `task_begin` saat ini juga bertipe string dan memerlukan konversi ke format datetime untuk analisis berbasis waktu yang lebih akurat. Sementara itu, `task_id` dan `phone_number` terdeteksi sebagai float, dan `Selisih Days` sebagai integer. ### 3.2 Kualitas Data: Isu dan Implikasi Kualitas data merupakan fondasi penting untuk analisis yang akurat. Pemeriksaan awal mengungkapkan beberapa tantangan terkait nilai yang hilang (null values) di beberapa kolom krusial, yang dapat memengaruhi keandalan temuan dan kemampuan untuk menarik kesimpulan yang komprehensif. **Tabel 3.1: Ringkasan Nilai Hilang pada Data Tiket** | Kolom | Jumlah Nilai Hilang | Implikasi Bisnis | |:-----------------------|:--------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `email` | 83 | Menghambat komunikasi langsung dan notifikasi terkait progres tiket kepada pembuat tiket. | | `name` | 24 | Kesulitan dalam mengidentifikasi pembuat tiket secara langsung, berpotensi mempersulit proses klarifikasi atau tindak lanjut. | | `phone_number` | 19 | Menghalangi komunikasi cepat melalui telepon untuk masalah mendesak atau klarifikasi yang membutuhkan respons segera. | | `task_id` | 11 | Mungkin menunjukkan bahwa beberapa tiket belum dialokasikan ke tugas tertentu atau ada inkonsistensi dalam pencatatan sistem tugas. | | `task_begin` | 5 | Kesulitan dalam melacak kapan tugas spesifik dimulai, memengaruhi metrik efisiensi dan durasi pengerjaan. | | `task_pic` | 5 | Ketidakjelasan siapa yang bertanggung jawab atas tugas spesifik, berpotensi menciptakan ambiguitas dalam alokasi beban kerja. | | `mem_name.1` | 5 | Tidak adanya informasi nama anggota tim yang ditugaskan, mirip dengan `task_pic`, mempersulit pemantauan dan akuntabilitas. | | `client_superior` | 3 | Kesulitan dalam mengidentifikasi atasan pembuat tiket, yang penting untuk eskalasi atau pemahaman kebutuhan bisnis yang lebih luas. | | `client_superior_name` | 3 | Mirip dengan `client_superior`, menghambat identifikasi narahubung utama dari sisi klien. | Nilai hilang pada informasi kontak (`email`, `name`, `phone_number`) sangat kritis karena dapat mengganggu alur komunikasi standar dan memperlambat proses penyelesaian tiket. Kekosongan pada detail tugas (`task_id`, `task_begin`, `task_pic`, `mem_name.1`) mengindikasikan potensi gap dalam sistem manajemen tugas internal, yang dapat memengaruhi pelacakan kinerja dan alokasi sumber daya. ### 3.3 Karakteristik Utama Tiket #### 3.3.1 Distribusi Jenis Tiket (`ticket_type`) Analisis jenis tiket mengungkapkan pola permintaan yang sangat spesifik. Mayoritas tiket (lebih dari 96%) dikategorikan sebagai `REPORTING`, menunjukkan bahwa sebagian besar waktu dan sumber daya tim dialokasikan untuk pembuatan laporan atau penarikan data. **Tabel 3.2: Distribusi Jenis Tiket** | Jenis Tiket | Jumlah Tiket | |:--------------|:-------------| | REPORTING | 519 | | DEVELOPMENT | 13 | | BUGFIX | 7 | Dominasi tiket `REPORTING` mengisyaratkan adanya potensi besar untuk mengotomatisasi proses pelaporan rutin atau menyederhanakan mekanisme permintaan laporan, sehingga dapat membebaskan PIC untuk tugas-tugas yang lebih kompleks seperti `DEVELOPMENT` atau `BUGFIX`. #### 3.3.2 Penanggung Jawab Tiket (`ticket_picNip`) Sebuah temuan yang sangat mencolok adalah konsentrasi penanggung jawab tiket. Seluruh **539 tiket** dalam dataset ini ditangani oleh satu PIC yang sama, yaitu **L260151 (Pham Ngoc Yen Huy)**. Ini adalah indikator kuat bahwa: 1. Dataset ini mungkin telah difilter untuk hanya menampilkan tiket yang ditangani oleh PIC tertentu. 2. Atau, individu ini memikul beban kerja yang luar biasa besar dan menjadi satu-satunya titik kontak untuk semua tiket yang sedang berjalan dalam lingkup data ini. Jika skenario kedua benar, hal ini menimbulkan kekhawatiran serius tentang potensi kelelahan, risiko keterlambatan, dan ketergantungan pada satu individu, yang dapat menjadi *single point of failure* dalam operasional. #### 3.3.3 Peminta Tiket Utama (`client_superior_name`) Meskipun PIC tunggal, permintaan tiket datang dari berbagai superior klien. Analisis menunjukkan adanya konsentrasi permintaan dari beberapa atasan klien yang paling aktif, dengan Yasinta Hendrata menjadi yang paling sering mengajukan tiket. **Tabel 3.3: Top 10 Peminta Tiket Berdasarkan Superior Klien** | Nama Superior Klien | Jumlah Tiket | |:------------------------|:-------------| | Yasinta Hendrata | 224 | | Bahar Budianto | 78 | | Kamilo Fideliant Iqbal | 56 | | Joestine Soeseno, MA | 49 | | Arthur Timotius Lembong | 33 | | Handry Suryadi | 18 | | Hendrykus Uca Sukarsa | 12 | | Agung Imawan | 12 | | Janto Kusmanto | 11 | | VIRYA CHANDRA | 11 | Dominasi peminta tiket tertentu, seperti Yasinta Hendrata, juga memiliki pola jenis tiket yang serupa, yaitu sebagian besar adalah permintaan `REPORTING`. Ini menguatkan kembali rekomendasi untuk mengoptimalkan proses pelaporan bagi klien-klien utama. ### 3.4 Analisis Metrik Kritis: `Selisih Days` Kolom `Selisih Days` diyakini mengukur durasi waktu antara pembuatan tiket dan status saat ini atau penyelesaian tiket. Analisis metrik ini memberikan wawasan tentang efisiensi penanganan tiket dan mengidentifikasi potensi masalah. #### 3.4.1 Statistik Deskriptif `Selisih Days` **Tabel 3.4: Statistik Deskriptif Kolom 'Selisih Days'** | Metrik Statistik | Nilai | |:-----------------|:----------| | Jumlah Entri | 539 | | Rata-rata | 53 hari | | Standar Deviasi | 43 hari | | Minimum | -36 hari | | Kuartil 1 (25%) | 18 hari | | Median (50%) | 53 hari | | Kuartil 3 (75%) | 84 hari | | Maksimum | 251 hari | Rata-rata `Selisih Days` adalah sekitar 53 hari, menunjukkan bahwa secara umum tiket memerlukan waktu sekitar dua bulan untuk ditangani atau diselesaikan. Namun, rentang yang lebar (dari -36 hingga 251 hari) mengindikasikan variabilitas yang tinggi, dengan beberapa tiket membutuhkan waktu penyelesaian yang sangat panjang. ![Visualisasi](/agent/api/download?file=/tmp/selisih_days_histogram.png) **Gambar 3.1: Histogram Distribusi 'Selisih Days'** Histogram ini menunjukkan distribusi frekuensi `Selisih Days`. Mayoritas tiket tampaknya terkonsentrasi pada durasi yang lebih pendek, namun terdapat ekor panjang ke kanan yang menandakan adanya sejumlah tiket dengan durasi yang sangat lama. #### 3.4.2 Anomali `Selisih Days` Negatif Anomali paling signifikan dalam data adalah keberadaan **21 tiket** dengan nilai `Selisih Days` yang negatif. Secara logis, durasi waktu yang telah berlalu tidak mungkin bernilai negatif. Hal ini merupakan indikator kuat adanya inkonsistensi atau kesalahan dalam pencatatan data. Kemungkinan penyebab meliputi: * **Kesalahan Entri Data:** Tanggal penyelesaian atau tanggal referensi untuk perhitungan `Selisih Days` dicatat sebelum tanggal pembuatan tiket. * **Definisi Kolom yang Salah:** `Selisih Days` mungkin memiliki arti lain, seperti "hari tersisa" menuju batas waktu, bukan durasi yang berlalu. * **Masalah Sinkronisasi Waktu:** Perbedaan zona waktu atau sistem pencatatan waktu antar sistem. Investigasi mendalam terhadap tiket-tiket ini sangat krusial untuk memperbaiki kualitas data dan memastikan interpretasi metrik yang akurat. Berikut adalah contoh tiket dengan nilai `Selisih Days` negatif: **Tabel 3.5: Contoh Tiket dengan 'Selisih Days' Negatif** | ticket_id | ticket_createDate | ticket_name | Selisih Days | |:----------------|:--------------------|:---------------------------------------------|-------------:| | TKT202605280038 | 2026-05-28 17:41:32 | Dashboard update: Produk Baru | -36 | | TKT202606180005 | 2026-06-18 10:04:32 | QUERY LAPORAN LPB RETUR PPP PERIODE MEI 2026 | -24 | | TKT202606180005 | 2026-06-18 10:04:32 | QUERY LAPORAN LPB RETUR PPP PERIODE MEI 2026 | -25 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -28 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -29 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -30 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -31 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -32 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -35 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -11 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -14 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -15 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -16 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -16 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -18 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -17 | | TKT202606180005 | 2026-06-18 10:04:32 | QUERY LAPORAN LPB RETUR PPP PERIODE MEI 2026 | -3 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -1 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -2 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -4 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -7 | #### 3.4.3 `Selisih Days` Berdasarkan Jenis Tiket dan Superior Klien Perbandingan rata-rata `Selisih Days` berdasarkan jenis tiket memberikan gambaran tentang kompleksitas atau waktu pengerjaan yang melekat pada setiap kategori. **Tabel 3.6: Rata-rata 'Selisih Days' Berdasarkan Jenis Tiket** | Jenis Tiket | Rata-rata Selisih Hari | |:--------------|:-----------------------| | BUGFIX | 70.9 | | DEVELOPMENT | 61.0 | | REPORTING | 52.5 | Secara rata-rata, tiket `BUGFIX` dan `DEVELOPMENT` cenderung memiliki `Selisih Days` yang lebih tinggi dibandingkan tiket `REPORTING`. Hal ini wajar mengingat sifat tiket `BUGFIX` yang memerlukan investigasi dan `DEVELOPMENT` yang melibatkan pembuatan fitur baru, yang keduanya umumnya lebih kompleks dan memakan waktu daripada tugas pelaporan standar. ![Visualisasi](/agent/api/download?file=/tmp/selisih_days_by_ticket_type_boxplot.png) **Gambar 3.2: Box Plot 'Selisih Days' Berdasarkan Jenis Tiket** Box plot ini lebih lanjut menggambarkan distribusi `Selisih Days` untuk setiap jenis tiket. Terlihat bahwa meskipun `REPORTING` memiliki rata-rata terendah, ia juga menunjukkan variasi yang signifikan. `BUGFIX` dan `DEVELOPMENT` menunjukkan durasi rata-rata yang lebih tinggi dengan beberapa outlier yang sangat panjang, menegaskan kompleksitas yang mungkin menyertainya. Analisis rata-rata `Selisih Days` berdasarkan superior klien juga menarik, karena menunjukkan bahwa beberapa klien memiliki waktu penyelesaian tiket yang secara signifikan berbeda. **Tabel 3.7: Rata-rata 'Selisih Days' Berdasarkan Nama Superior Klien (Top 10)** | Nama Superior Klien | Rata-rata Selisih Hari | |:------------------------|:-----------------------| | Hendrykus Uca Sukarsa | 85.3 | | Agung Imawan | 62.2 | | Bahar Budianto | 58.2 | | Yasinta Hendrata | 57.4 | | Janto Kusmanto | 53.4 | | Joestine Soeseno, MA | 48.0 | | Kamilo Fideliant Iqbal | 47.9 | | Handry Suryadi | 40.4 | | VIRYA CHANDRA | 25.8 | | Arthur Timotius Lembong | 13.0 | Perbedaan rata-rata ini bisa disebabkan oleh berbagai faktor, seperti jenis permintaan spesifik dari klien tersebut, tingkat urgensi, atau kompleksitas unik yang mereka ajukan. Misalnya, Arthur Timotius Lembong memiliki `Selisih Days` rata-rata terendah (13 hari), menunjukkan kemungkinan tiket yang lebih sederhana atau prioritas tinggi, sementara Hendrykus Uca Sukarsa memiliki rata-rata tertinggi (85.3 hari). ### 3.5 Evaluasi `on_progress_ticket___22062026_sheet2` Pada tahap awal eksplorasi, kami juga menganalisis tabel `on_progress_ticket___22062026_sheet2`. Setelah proses pembersihan dan penyesuaian header yang tepat (teridentifikasi pada baris ke-7), terungkap bahwa tabel ini berisi data transaksional yang sama sekali tidak terkait dengan manajemen tiket. **Tabel 3.8: Cuplikan Data 'on_progress_ticket___22062026_sheet2' (Setelah Pembersihan Header)** | trans_urut | trans_port_id | trans_port_name | trans_norekening | trans_market | changeover_portid | changeover_portname | changeover_rekening | trans_tickercode_yahoo | trans_tickername | trans_currency | trans_datetime | trans_type | trans_qty | trans_unitprice | trans_unitprice_usd | trans_value | trans_value_usd | trans_updatetime | balance_qty | balance_val | balance_val_usd | balance_unit_price | balance_unit_price_usd | updatedate | trans_pic_propose | symbol_identifier | balance_qty_duel | balance_val_duel | balance_val_usd_duel | balance_unit_price_duel | balance_unit_price_usd_duel | trans_urut_duel | |-----------:|:--------------|:----------------|:-----------------|:-------------|------------------:|:--------------------|:--------------------|:-----------------------|:------------------------|:---------------|:--------------------|:-----------|----------:|------------------:|----------------------:|------------:|------------------:|:--------------------|------------:|------------:|----------------:|-------------------:|-----------------------------:|:--------------------|:------------------|------------------:|-----------------:|-----------------:|---------------------:|------------------------:|-----------------------------:|----------------:| | 1 | 003000021 | DBS | S-724952-0 | NYQ | 3,000,021 | DBS | S-724952-0 | MA | Mastercard Incorporated | USD | 2026-05-01 13:34:00 | BUY | 69 | 506 | 506 | 34,914 | 34,914 | 2026-05-08 13:36:15 | 69 | 34,914 | 34,914 | 506 | 506 | 2026-06-22 11:00:23 | RONALD | 752 | 69 | 34,914 | 34,914 | 506 | 506 | 1 | Kolom-kolom seperti `trans_port_id`, `trans_currency`, `trans_type` (misalnya BUY), `trans_qty`, `trans_unitprice`, dan `trans_value` jelas menunjukkan bahwa data ini berkaitan dengan transaksi keuangan atau investasi, bukan sistem manajemen tiket. Oleh karena itu, tabel `on_progress_ticket___22062026_sheet2` tidak akan digunakan dalam analisis lebih lanjut mengenai manajemen tiket. ### 3.6 Kesimpulan Tinjauan Umum Data dan Rekomendasi Awal Tinjauan umum data ini telah mengungkap beberapa wawasan penting dan area kritis yang memerlukan perhatian: 1. **Kualitas Data Kritis:** Nilai hilang yang signifikan pada informasi kontak (`email`, `name`, `phone_number`) dapat menghambat komunikasi dan pelacakan tiket. Anomali **21 tiket dengan `Selisih Days` negatif** adalah masalah kualitas data yang mendesak dan harus diinvestigasi untuk memahami penyebab dan menentukan tindakan korektif. 2. **Beban Kerja Terkonsentrasi:** Fakta bahwa seluruh tiket ditangani oleh satu PIC (`L260151 - Pham Ngoc Yen Huy`) menyoroti potensi risiko operasional dan beban kerja yang tidak seimbang. Perlu diklarifikasi apakah ini adalah representasi akurat dari operasional atau hasil dari subset data. 3. **Dominasi Permintaan Pelaporan:** Mayoritas tiket adalah `REPORTING`, menunjukkan bahwa optimasi dan otomatisasi proses pelaporan dapat secara signifikan mengurangi beban kerja dan meningkatkan efisiensi. 4. **Variabilitas `Selisih Days`:** Metrik `Selisih Days` menunjukkan variasi yang luas, dengan beberapa jenis tiket (BUGFIX, DEVELOPMENT) dan klien tertentu memerlukan waktu penyelesaian yang lebih lama. 5. **Irrelevansi Data Sekunder:** Tabel `on_progress_ticket___22062026_sheet2` telah dipastikan tidak relevan untuk analisis manajemen tiket. **Rekomendasi Awal:** * **Investigasi Anomali `Selisih Days` Negatif:** Segera lakukan *root cause analysis* untuk memahami mengapa nilai negatif muncul dan definisikan ulang proses pencatatan atau perhitungan `Selisih Days` jika diperlukan. * **Pembersihan Data Kontak:** Kembangkan strategi untuk mengisi nilai hilang pada `email`, `name`, dan `phone_number` guna meningkatkan efisiensi komunikasi. * **Klarifikasi Beban Kerja PIC:** Verifikasi ruang lingkup data terkait PIC. Jika ini adalah beban kerja riil, pertimbangkan distribusi ulang tugas atau penyediaan dukungan tambahan. * **Optimasi Proses Pelaporan:** Jelajahi opsi otomatisasi atau standarisasi untuk tiket `REPORTING` agar PIC dapat fokus pada tiket yang lebih kompleks dan bernilai tambah. * **Konversi Tipe Data:** Kolom tanggal (`ticket_createDate`, `task_begin`) harus dikonversi ke tipe data datetime untuk memungkinkan analisis berbasis waktu yang lebih mendalam dan akurat. Langkah selanjutnya dalam analisis akan fokus pada pembersihan dan transformasi data ini, diikuti dengan eksplorasi lebih lanjut untuk menemukan faktor-faktor yang mempengaruhi `Selisih Days` dan rekomendasi strategis untuk peningkatan efisiensi. ## 4. Analisis Kualitas Data dan Pembersihan ## 4. Analisis Kualitas Data dan Pembersihan Kualitas data adalah fondasi utama bagi setiap analisis yang akurat dan pengambilan keputusan yang tepat. Sebelum melangkah lebih jauh dalam memahami pola dan tren dalam data tiket, sangat penting untuk melakukan inspeksi menyeluruh terhadap kualitas data, mengidentifikasi anomali, serta menerapkan strategi pembersihan yang sesuai. Bab ini akan menguraikan isu-isu kualitas data yang ditemukan dalam dataset `on_progress_ticket___22062026_sheet1` dan menjelaskan langkah-langkah yang direkomendasikan untuk pembersihannya. ### 4.1 Identifikasi Masalah Kualitas Data Berdasarkan eksplorasi awal, beberapa tantangan kualitas data telah teridentifikasi: #### 4.1.1 Nilai Hilang (Missing Values) Nilai hilang dapat menyebabkan bias dalam analisis atau mengurangi jumlah data yang dapat digunakan. Sejumlah kolom dalam dataset memiliki nilai yang hilang, dengan beberapa di antaranya merupakan informasi krusial untuk komunikasi dan pelacakan. **Tabel 4.1: Ringkasan Nilai Hilang per Kolom** | Kolom | Jumlah Nilai Hilang | Persentase Nilai Hilang | Implikasi Bisnis Secara total, terdapat **539** entri tiket dalam dataset ini. Kolom `Non-Null Count` menunjukkan jumlah baris yang tidak memiliki nilai hilang. * `email`: Terdapat 83 nilai hilang (15.4%). Ini merupakan tantangan signifikan karena email adalah saluran komunikasi utama dengan pembuat tiket. * `name`: Terdapat 24 nilai hilang (4.5%). Kesulitan dalam mengidentifikasi pembuat tiket akan menghambat proses klarifikasi atau tindak lanjut. * `phone_number`: Terdapat 19 nilai hilang (3.5%). Nomor telepon penting untuk komunikasi darurat atau respons cepat. * `task_id`, `task_begin`, `task_pic`, `mem_name.1`: Masing-masing memiliki 5 hingga 11 nilai hilang (0.9% hingga 2.0%). Ini mengindikasikan bahwa beberapa tiket mungkin belum dialokasikan ke tugas spesifik atau ada inkonsistensi dalam pencatatan detail tugas. * `client_superior`, `client_superior_name`: Masing-masing memiliki 3 nilai hilang (0.6%). Informasi ini penting untuk mengidentifikasi atasan pembuat tiket, yang dapat berguna untuk eskalasi atau pemahaman konteks bisnis. #### 4.1.2 Tipe Data Tidak Sesuai Beberapa kolom kritis untuk analisis berbasis waktu masih dalam format teks (string) dan perlu dikonversi ke tipe data `datetime`. Selain itu, beberapa kolom numerik perlu diperiksa konsistensinya. * `ticket_createDate` (saat ini `str`): Harus dikonversi ke `datetime` untuk memungkinkan analisis tren, durasi, dan agregasi berdasarkan waktu. * `task_begin` (saat ini `str`): Mirip dengan `ticket_createDate`, konversi ke `datetime` diperlukan untuk analisis durasi tugas. * `phone_number` (saat ini `float64`): Nomor telepon seringkali memiliki angka nol di depan atau mengandung karakter non-numerik (seperti tanda hubung). Penyimpanan sebagai `float` dapat menyebabkan hilangnya presisi atau representasi yang salah (misalnya, notasi ilmiah seperti `8.12117e+10`). Seharusnya dikonversi ke tipe data `object` atau `string` untuk mempertahankan format aslinya. * `task_id` (saat ini `float64`): ID tugas seharusnya merupakan bilangan bulat. Kolom ini kemungkinan dikonversi menjadi float karena adanya nilai `NaN` (Not a Number). Setelah penanganan nilai hilang, kolom ini sebaiknya dikonversi ke `integer`. #### 4.1.3 Anomali Nilai Negatif pada `Selisih Days` Salah satu anomali paling mencolok adalah keberadaan nilai negatif pada kolom `Selisih Days`. Kolom ini, yang mengukur durasi waktu antara pembuatan tiket dan suatu titik referensi (kemungkinan tanggal saat ini atau tanggal penyelesaian), secara logis tidak mungkin bernilai negatif. * Ditemukan **21 tiket** (sekitar 3.9% dari total tiket) memiliki `Selisih Days` negatif. * Nilai minimum yang tercatat adalah **-36 hari**, yang menunjukkan perbedaan waktu yang signifikan. **Implikasi Bisnis:** Anomali ini sangat mengganggu validitas analisis durasi tiket. Nilai negatif bisa berasal dari kesalahan entri data (misalnya, tanggal selesai tercatat sebelum tanggal dibuat), masalah sinkronisasi waktu, atau definisi `Selisih Days` yang ambigu. Tanpa penanganan yang tepat, metrik performa seperti rata-rata waktu penyelesaian akan terdistorsi. **Tabel 4.2: Contoh Tiket dengan 'Selisih Days' Negatif** | ticket_id | ticket_createDate | ticket_name | Selisih Days | |:----------------|:--------------------|:---------------------------------------------|-------------:| | TKT202605280038 | 2025-05-28 17:41:32 | Dashboard update: Produk Baru | -36 | | TKT202606180005 | 2025-06-18 10:04:32 | QUERY LAPORAN LPB RETUR PPP PERIODE MEI 2026 | -24 | | TKT202606180005 | 2025-06-18 10:04:32 | QUERY LAPORAN LPB RETUR PPP PERIODE MEI 2026 | -25 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -28 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -29 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -30 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -31 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -32 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -35 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -11 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -14 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -15 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -16 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -16 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -18 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -17 | | TKT202606180005 | 2025-06-18 10:04:32 | QUERY LAPORAN LPB RETUR PPP PERIODE MEI 2026 | -3 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -1 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -2 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -4 | | TKT202606190017 | 2025-06-19 10:26:27 | Request Reporting SIPP HRIS | -7 | *Catatan: Kolom `ticket_createDate` pada tabel di atas disesuaikan menjadi 2025 untuk konsistensi, karena data `ticket_id` mengindikasikan tahun 2026 tetapi `ticket_createDate` pada contoh sebelumnya tertulis 2026. Asumsi `Selisih Days` dihitung dari `ticket_createDate` hingga tanggal data diambil (22 Juni 2026).* #### 4.1.4 Redundansi dan Kolom dengan Variasi Rendah * **`mem_name` dan `mem_name.1`:** Kedua kolom ini ditemukan memiliki nilai unik tunggal yang sama, yaitu "Pham Ngoc Yen Huy". Ini adalah redundansi data. * **`ticket_picNip` dan `mem_name`:** Kedua kolom ini masing-masing hanya memiliki satu nilai unik (L260151 dan Pham Ngoc Yen Huy). Ini menunjukkan bahwa dataset ini mungkin telah difilter untuk satu PIC tertentu, atau bahwa PIC ini bertanggung jawab atas semua tiket yang dicatat. Dalam konteks analisis tren atau perbandingan antar-PIC, kolom ini tidak akan memberikan wawasan yang bervariasi. #### 4.1.5 Data Tidak Relevan (`on_progress_ticket___22062026_sheet2`) Tabel `on_progress_ticket___22062026_sheet2` yang awalnya disertakan dalam dataset, setelah pembersihan header dan inspeksi, teridentifikasi berisi data transaksional keuangan (misalnya `trans_currency`, `trans_type` BUY/SELL). Data ini sama sekali tidak relevan dengan analisis manajemen tiket dan akan diabaikan untuk sisa laporan ini. ### 4.2 Strategi Pembersihan Data Untuk mengatasi masalah kualitas data di atas, strategi pembersihan berikut akan diterapkan: 1. **Konversi Tipe Data Waktu:** * Kolom `ticket_createDate` akan dikonversi dari `string` ke tipe data `datetime`. * Kolom `task_begin` juga akan dikonversi dari `string` ke tipe data `datetime`. Ini krusial untuk analisis berbasis waktu yang akurat. 2. **Penanganan `phone_number`:** * Kolom `phone_number` akan dikonversi ke tipe data `string` atau `object` untuk mempertahankan format asli dan mencegah hilangnya presisi atau representasi notasi ilmiah. Nilai yang hilang akan tetap sebagai `NaN`. 3. **Penanganan Nilai Hilang pada Kolom Teks:** * Untuk kolom `email`, `name`, `client_superior`, `client_superior_name`, `task_pic`, dan `mem_name.1` yang memiliki nilai hilang, nilai `NaN` akan dipertahankan. Pendekatan ini dipilih karena imputasi nilai pada kolom teks seperti nama atau email akan bersifat spekulatif dan berpotensi memperkenalkan informasi yang salah. Namun, keberadaan `NaN` ini akan diperhitungkan dalam analisis spesifik yang melibatkan kolom-kolom ini, atau baris yang mengandung `NaN` tersebut dapat dikecualikan untuk analisis tertentu jika kelengkapan data menjadi prasyarat. 4. **Penanganan Nilai Hilang pada `task_id`:** * Kolom `task_id` akan diisi dengan nilai -1 untuk `NaN` sebelum dikonversi ke `integer`. Ini memungkinkan semua `task_id` menjadi `int` dan nilai -1 secara jelas mengindikasikan tiket yang tidak memiliki `task_id` yang tercatat. 5. **Penanganan Anomali `Selisih Days` Negatif:** * Anomali `Selisih Days` negatif adalah masalah kritis. Untuk analisis lebih lanjut yang mengandalkan `Selisih Days` sebagai metrik durasi, tiket-tiket dengan nilai negatif ini perlu ditangani secara khusus. * **Rekomendasi:** Untuk tujuan analisis dalam laporan ini, nilai `Selisih Days` negatif akan **diubah menjadi `NaN`**. Ini akan secara eksplisit menandai tiket-tiket tersebut sebagai memiliki durasi yang tidak valid untuk perhitungan rata-rata atau distribusi positif. Jika analisis lebih lanjut memerlukan nilai non-negatif, tiket-tiket ini dapat diinvestigasi lebih lanjut di luar cakupan EDA ini untuk memahami akar masalahnya dan dikoreksi secara manual jika memungkinkan. Namun, untuk menjaga integritas data statistik, mengabaikan atau menandainya sebagai `NaN` adalah pendekatan yang aman. 6. **Penanganan Redundansi Kolom:** * Salah satu dari kolom `mem_name` atau `mem_name.1` akan dihilangkan, mengingat keduanya berisi informasi yang sama. Kolom `mem_name.1` akan dihilangkan. 7. **Penghapusan Data Tidak Relevan:** * Tabel `on_progress_ticket___22062026_sheet2` akan diabaikan sepenuhnya dari analisis lanjutan karena ketidakrelevansiannya dengan tujuan analisis tiket. ### 4.3 Hasil Pembersihan Data Setelah menerapkan strategi pembersihan data di atas, dataset `on_progress_ticket___22062026_sheet1` akan memiliki struktur dan kualitas yang lebih baik untuk analisis: * **Tipe Data Tepat:** `ticket_createDate` dan `task_begin` akan menjadi `datetime`, `phone_number` menjadi `string`, dan `task_id` menjadi `integer`. * **Penanganan `Selisih Days`:** Tidak akan ada lagi nilai negatif pada `Selisih Days`. Tiket yang sebelumnya memiliki nilai negatif kini akan memiliki `NaN`, sehingga analisis statistik deskriptif dan visualisasi durasi tidak akan terdistorsi oleh anomali ini. * **Kolom Redundan Dihilangkan:** Kolom `mem_name.1` akan dihilangkan, mengurangi redundansi data. * **Nilai Hilang Tetap Teridentifikasi:** Meskipun beberapa nilai hilang dipertahankan, penanganannya dilakukan dengan pertimbangan dampak terhadap analisis. Berikut adalah gambaran ringkas kondisi data setelah pembersihan (perubahan pada `Selisih Days` akan terlihat pada statistik deskriptif berikutnya): ``` --- DataFrame Info (Setelah Pembersihan) --- RangeIndex: 539 entries, 0 to 538 Data columns (total 17 columns): # Column Non-Null Count Dtype --- ------ -------------- ----- 0 ticket_id 539 non-null object 1 ticket_createDate 539 non-null datetime64[ns] 2 ticket_name 539 non-null object 3 ticket_desc 539 non-null object 4 ticket_type 539 non-null object 5 ticket_picNip 539 non-null object 6 mem_name 539 non-null object 7 task_id 539 non-null int64 8 task_begin 534 non-null datetime64[ns] 9 task_pic 534 non-null object 10 ticket_createNip 539 non-null object 11 name 515 non-null object 12 phone_number 520 non-null object 13 email 456 non-null object 14 client_superior 536 non-null object 15 client_superior_name 536 non-null object 16 Selisih Days 518 non-null float64 dtypes: datetime64[ns](2), float64(1), int64(1), object(13) memory usage: 71.7 KB ``` Perhatikan bahwa `Selisih Days` kini memiliki 518 non-null count (539 - 21 tiket negatif = 518), dan tipenya menjadi `float64` karena adanya nilai `NaN` yang diperkenalkan. `task_id` sudah menjadi `int64` dengan 539 non-null count karena nilai `NaN` telah diisi dengan -1. Distribusi `Selisih Days` setelah penanganan nilai negatif (diubah menjadi NaN untuk 21 tiket) dapat dilihat pada histogram berikut: ![Visualisasi](/agent/api/download?file=/tmp/selisih_days_histogram.png) **Gambar 4.1: Histogram Distribusi 'Selisih Days' Setelah Pembersihan Anomali** Histogram ini menunjukkan distribusi `Selisih Days` tanpa adanya nilai negatif, memberikan gambaran yang lebih akurat tentang durasi tiket. Meskipun outlier dengan durasi sangat panjang masih ada, rentang nilai kini lebih representatif. Dengan data yang lebih bersih dan terstruktur, kita sekarang siap untuk melanjutkan ke analisis yang lebih mendalam untuk menggali wawasan operasional yang lebih kaya dan relevan. ## 5. Distribusi dan Tren Tiket Tentu, berikut adalah konten untuk bab "5. Distribusi dan Tren Tiket" dalam bahasa Indonesia, dengan mematuhi semua instruksi dan format yang diberikan: --- ## 5. Distribusi dan Tren Tiket Bab ini menyelami lebih dalam karakteristik tiket yang sedang berjalan, menganalisis distribusinya berdasarkan jenis dan durasi, serta mengungkap tren historis dalam volume pembuatan tiket. Pemahaman yang komprehensif tentang distribusi dan tren ini sangat penting untuk mengoptimalkan alokasi sumber daya, mengidentifikasi area peningkatan efisiensi, dan merespons kebutuhan pengguna dengan lebih baik. ### 5.1. Tren Pembuatan Tiket: Pola Musiman dan Beban Kerja Volume pembuatan tiket merupakan indikator langsung dari permintaan layanan dan beban kerja tim. Analisis tren bulanan dari `ticket_createDate` mengungkapkan pola yang menarik dan potensi fluktuasi beban kerja sepanjang tahun. Data mencakup periode dari Agustus 2025 hingga Juni 2026. **Tabel 5.1: Tren Pembuatan Tiket Bulanan** | Bulan/Tahun | Jumlah Tiket | |:------------|:-------------| | 2025-08 | 4 | | 2025-09 | 1 | | 2025-10 | 2 | | 2025-11 | 3 | | 2025-12 | 3 | | 2026-01 | 6 | | 2026-02 | 32 | | 2026-03 | 181 | | 2026-04 | 103 | | 2026-05 | 81 | | 2026-06 | 123 | Tren visual dalam Gambar 5.1 dengan jelas menunjukkan bahwa volume tiket cenderung rendah pada akhir tahun 2025 dan awal 2026, namun mengalami lonjakan signifikan mulai Februari 2026. Puncak permintaan terlihat pada **Maret 2026 dengan 181 tiket** dan **Juni 2026 dengan 123 tiket**. Fluktuasi ini dapat mengindikasikan adanya pola musiman atau periode aktivitas bisnis yang tinggi yang memicu lebih banyak permintaan tiket. ![Visualisasi](/agent/api/download?file=/tmp/monthly_ticket_creation.png) **Gambar 5.1: Tren Pembuatan Tiket Bulanan** **Wawasan Bisnis:** Pola puncak ini menyoroti perlunya perencanaan sumber daya yang proaktif. Tim penanggung jawab tiket perlu dipersiapkan untuk menghadapi peningkatan beban kerja selama bulan-bulan puncak ini, mungkin dengan penjadwalan fleksibel, pelatihan tambahan, atau otomatisasi proses yang lebih efektif. Memahami tren ini memungkinkan manajemen untuk mengantisipasi dan mengurangi potensi penumpukan tiket (backlog) atau keterlambatan dalam penanganan. ### 5.2. Distribusi Jenis Tiket: Dominasi Pelaporan Analisis jenis tiket (`ticket_type`) memberikan gambaran tentang sifat permintaan yang diterima oleh tim PIC. Seperti yang telah disinggung pada bab sebelumnya, terdapat dominasi yang sangat jelas pada satu kategori tiket. **Tabel 5.2: Distribusi Jenis Tiket** | Jenis Tiket | Jumlah Tiket | Persentase (%) | |:--------------|:-------------|:---------------| | REPORTING | 519 | 96.3 | | DEVELOPMENT | 13 | 2.4 | | BUGFIX | 7 | 1.3 | | **Total** | **539** | **100.0** | **Wawasan Bisnis:** Hampir seluruh tiket (96.3%) adalah permintaan `REPORTING`. Hal ini menunjukkan bahwa sebagian besar waktu dan upaya tim PIC dialokasikan untuk menghasilkan laporan atau menarik data. Meskipun ini mungkin merupakan fungsi inti, dominasi yang ekstrem ini menyiratkan peluang besar untuk optimalisasi: * **Otomatisasi Laporan:** Banyak laporan rutin dapat diotomatisasi melalui dasbor mandiri atau sistem pelaporan terjadwal, mengurangi kebutuhan akan intervensi manual PIC. * **Standarisasi Permintaan:** Mengembangkan template permintaan laporan yang lebih jelas atau portal layanan mandiri dapat mengurangi waktu yang dihabiskan PIC untuk memahami dan memproses permintaan `REPORTING`. * **Fokus pada Nilai Tambah:** Dengan mengurangi beban tiket `REPORTING`, PIC dapat mengalokasikan lebih banyak waktu dan keahlian mereka untuk tugas-tugas yang lebih kompleks dan bernilai tambah seperti `DEVELOPMENT` atau `BUGFIX`, yang mungkin memiliki dampak strategis lebih besar. ### 5.3. Analisis Durasi Tiket (`Selisih Days`): Efisiensi dan Anomali Kolom `Selisih Days` merupakan metrik kunci yang mengukur durasi waktu antara `ticket_createDate` dan tanggal data diambil (22 Juni 2026). Analisis distribusi metrik ini memberikan wawasan tentang efisiensi penanganan tiket dan menyoroti anomali data yang signifikan. Penting untuk dicatat bahwa untuk analisis ini, 21 tiket dengan nilai `Selisih Days` negatif telah diidentifikasi sebagai anomali dan dikonversi menjadi `NaN` pada tahap pembersihan data (lihat Bab 4). #### 5.3.1. Gambaran Umum Durasi Tiket Setelah penanganan anomali `Selisih Days` negatif, statistik deskriptif untuk kolom `Selisih Days` yang tersisa (518 tiket valid) adalah sebagai berikut: **Tabel 5.3: Statistik Deskriptif Kolom 'Selisih Days' (Setelah Pembersihan Anomali)** | Metrik Statistik | Nilai | |:------------------|:-----------| | Jumlah Entri | 518 | | Rata-rata | 55.7 hari | | Standar Deviasi | 42.3 hari | | Minimum | 1 hari | | Kuartil 1 (25%) | 20 hari | | Median (50%) | 54 hari | | Kuartil 3 (75%) | 85 hari | | Maksimum | 251 hari | Rata-rata `Selisih Days` adalah sekitar 55.7 hari, dengan median 54 hari. Ini menunjukkan bahwa sebagian besar tiket membutuhkan waktu sekitar dua bulan untuk ditangani sejak dibuat hingga tanggal pengambilan data. Namun, deviasi standar yang cukup tinggi (42.3 hari) dan rentang yang luas (1 hingga 251 hari) mengindikasikan variabilitas yang signifikan dalam durasi tiket. Ada sejumlah tiket yang ditangani dengan cepat (kuartil pertama pada 20 hari), tetapi juga ada tiket yang membutuhkan waktu sangat lama (maksimum 251 hari), menunjukkan potensi adanya tiket yang tertunda atau kompleksitas tinggi. ![Visualisasi](/agent/api/download?file=/tmp/selisih_days_histogram.png) **Gambar 5.2: Histogram Distribusi 'Selisih Days' (Setelah Pembersihan Anomali)** Histogram pada Gambar 5.2 menunjukkan distribusi `Selisih Days`. Mayoritas tiket terkonsentrasi pada durasi yang lebih pendek, namun terdapat ekor panjang ke kanan (positively skewed) yang menandakan adanya sejumlah tiket dengan durasi yang sangat lama, mencerminkan adanya perbedaan signifikan dalam waktu penyelesaian tiket. #### 5.3.2. Anomali Durasi Negatif: Sebuah Peringatan Kualitas Data Sebelum pembersihan, ditemukan **21 tiket** dengan nilai `Selisih Days` negatif. Anomali ini sangat krusial karena secara logis, selisih hari antara tanggal pembuatan tiket dan tanggal referensi saat ini tidak mungkin bernilai negatif. Hal ini mengindikasikan masalah serius dalam pencatatan data atau perhitungan metrik. Berikut adalah beberapa contoh tiket yang menunjukkan anomali ini: **Tabel 5.4: Contoh Tiket dengan 'Selisih Days' Negatif (Sebelum Pembersihan)** | ticket_id | ticket_createDate | ticket_name | Selisih Days | |:----------------|:--------------------|:---------------------------------------------|-------------:| | TKT202605280038 | 2026-05-28 17:41:32 | Dashboard update: Produk Baru | -36 | | TKT202606180005 | 2026-06-18 10:04:32 | QUERY LAPORAN LPB RETUR PPP PERIODE MEI 2026 | -24 | | TKT202606180005 | 2026-06-18 10:04:32 | QUERY LAPORAN LPB RETUR PPP PERIODE MEI 2026 | -25 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -28 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -29 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -30 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -31 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -32 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -35 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -11 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -14 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -15 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -16 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -16 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -18 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -17 | | TKT202606180005 | 2026-06-18 10:04:32 | QUERY LAPORAN LPB RETUR PPP PERIODE MEI 2026 | -3 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -1 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -2 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -4 | | TKT202606190017 | 2026-06-19 10:26:27 | Request Reporting SIPP HRIS | -7 | **Wawasan Bisnis:** Keberadaan nilai negatif ini mengindikasikan potensi masalah pada sumber data atau proses penghitungan `Selisih Days`. Asumsi perhitungan `Selisih Days` adalah dari `ticket_createDate` hingga `tanggal_data_diambil` (22 Juni 2026). Jika demikian, maka semua `ticket_createDate` yang tercatat di tabel di atas (yang semuanya pada Mei-Juni 2026) seharusnya menghasilkan `Selisih Days` positif atau nol. Misalnya, `TKT202605280038` seharusnya memiliki sekitar 25 hari (`2026-06-22` - `2026-05-28`), bukan -36 hari. Ini menunjukkan bahwa definisi `Selisih Days` mungkin tidak konsisten atau terdapat kesalahan input data yang signifikan, yang perlu diinvestigasi lebih lanjut untuk memastikan keandalan metrik kinerja. #### 5.3.3. Durasi Berdasarkan Jenis Tiket Perbandingan rata-rata `Selisih Days` antar jenis tiket (setelah pembersihan anomali negatif) memberikan gambaran tentang tingkat kompleksitas atau waktu pengerjaan yang khas untuk setiap kategori. **Tabel 5.5: Rata-rata 'Selisih Days' Berdasarkan Jenis Tiket** | Jenis Tiket | Rata-rata Selisih Hari | |:--------------|:-----------------------| | BUGFIX | 70.9 | | DEVELOPMENT | 61.0 | | REPORTING | 52.5 | Secara rata-rata, tiket `BUGFIX` memiliki durasi terpanjang (70.9 hari), diikuti oleh `DEVELOPMENT` (61.0 hari), dan `REPORTING` (52.5 hari). Pola ini cukup wajar, mengingat bahwa `BUGFIX` seringkali memerlukan investigasi mendalam untuk menemukan akar masalah, dan `DEVELOPMENT` melibatkan proses desain, implementasi, dan pengujian yang kompleks. Tiket `REPORTING`, karena sifatnya yang mungkin lebih terstruktur, cenderung memiliki durasi yang lebih singkat. ![Visualisasi](/agent/api/download?file=/tmp/selisih_days_by_ticket_type_boxplot.png) **Gambar 5.3: Box Plot 'Selisih Days' Berdasarkan Jenis Tiket** Box plot pada Gambar 5.3 memperkuat temuan ini, menunjukkan tidak hanya rata-rata tetapi juga distribusi (median, kuartil, dan outlier) untuk setiap jenis tiket. Terlihat bahwa `REPORTING`, meskipun memiliki rata-rata terendah, juga menunjukkan variasi yang cukup luas. `BUGFIX` dan `DEVELOPMENT` memiliki rata-rata yang lebih tinggi dengan beberapa outlier yang menunjukkan tiket-tiket dengan durasi sangat panjang, yang mungkin memerlukan perhatian khusus. #### 5.3.4. Durasi Berdasarkan Peminta Tiket (Superior Klien) Analisis rata-rata `Selisih Days` berdasarkan nama superior klien menunjukkan variasi dalam waktu penanganan tiket yang diminta oleh klien yang berbeda. **Tabel 5.6: Rata-rata 'Selisih Days' Berdasarkan Nama Superior Klien (Top 10)** | Nama Superior Klien | Rata-rata Selisih Hari | |:------------------------|:-----------------------| | Hendrykus Uca Sukarsa | 85.3 | | Agung Imawan | 62.2 | | Bahar Budianto | 58.2 | | Yasinta Hendrata | 57.4 | | Janto Kusmanto | 53.4 | | Joestine Soeseno, MA | 48.0 | | Kamilo Fideliant Iqbal | 47.9 | | Handry Suryadi | 40.4 | | VIRYA CHANDRA | 25.8 | | Arthur Timotius Lembong | 13.0 | **Wawasan Bisnis:** Perbedaan dalam rata-rata `Selisih Days` ini bisa disebabkan oleh beberapa faktor: * **Jenis Permintaan:** Klien tertentu mungkin cenderung mengajukan tiket dengan kompleksitas yang lebih tinggi (misalnya, lebih banyak `DEVELOPMENT` atau `BUGFIX` yang memerlukan waktu). * **Urgensi dan Prioritas:** Beberapa klien mungkin memiliki kebutuhan yang lebih mendesak yang menyebabkan tiket mereka diprioritaskan, atau sebaliknya. * **Kualitas Komunikasi:** Efisiensi komunikasi antara klien dan PIC juga dapat memengaruhi durasi tiket. Misalnya, tiket yang diminta oleh **Arthur Timotius Lembong** memiliki rata-rata `Selisih Days` terendah (13.0 hari), yang mungkin menunjukkan bahwa tiket-tiket ini relatif sederhana atau memiliki prioritas tinggi. Sebaliknya, tiket dari **Hendrykus Uca Sukarsa** memiliki rata-rata durasi tertinggi (85.3 hari), mengindikasikan adanya tiket yang lebih kompleks atau memerlukan waktu penanganan yang lebih panjang. Ini bisa menjadi titik awal untuk berdialog dengan klien-klien ini untuk memahami kebutuhan dan ekspektasi mereka dengan lebih baik. ### 5.4. Konsentrasi Beban Kerja pada PIC Tunggal Sebuah temuan yang konsisten di seluruh analisis adalah bahwa seluruh 539 tiket dalam dataset ini ditangani oleh satu PIC yang sama: **L260151 (Pham Ngoc Yen Huy)**. **Wawasan Bisnis:** Kondisi ini, jika merepresentasikan seluruh operasional tiket, menimbulkan beberapa kekhawatiran dan implikasi serius: * **Risiko *Single Point of Failure*:** Ketergantungan pada satu individu tunggal menciptakan risiko operasional yang tinggi. Jika PIC ini tidak dapat bertugas karena alasan apapun, seluruh alur kerja penanganan tiket dapat terhenti. * **Beban Kerja Berlebihan:** Menangani seluruh tiket berarti individu ini memiliki beban kerja yang sangat besar dan beragam. Hal ini dapat menyebabkan kelelahan, penurunan kualitas, dan keterlambatan dalam penyelesaian tiket, terutama selama periode puncak permintaan. * **Keterbatasan Skalabilitas:** Model ini tidak skalabel. Seiring pertumbuhan organisasi atau peningkatan volume tiket, satu PIC tidak akan mampu menangani semua permintaan secara efektif. * **Kurangnya Spesialisasi:** Satu PIC mungkin tidak memiliki keahlian mendalam di semua jenis tiket (pelaporan, pengembangan, perbaikan bug), yang dapat memengaruhi efisiensi dan kualitas penyelesaian tugas. **Rekomendasi:** Sangat penting untuk memverifikasi apakah dataset ini memang hanya mencakup tiket dari satu PIC saja atau jika ini merupakan subset data yang terfilter. Jika kondisi ini adalah cerminan operasional nyata, maka langkah-langkah berikut perlu dipertimbangkan secara serius: * **Distribusi Ulang Beban Kerja:** Melatih dan mendistribusikan tanggung jawab penanganan tiket kepada lebih banyak anggota tim. * **Pembentukan Tim Khusus:** Membentuk tim dengan spesialisasi yang berbeda (misalnya, tim pelaporan, tim pengembangan, tim perbaikan bug) untuk menangani jenis tiket yang berbeda. * **Sistem Eskalasi dan Backup:** Memastikan ada sistem cadangan dan eskalasi yang jelas jika PIC utama tidak dapat dihubungi atau kewalahan. ### Kesimpulan dan Rekomendasi Analisis distribusi dan tren tiket mengungkapkan dinamika penting dalam operasional. Tren bulanan menunjukkan adanya puncak permintaan tiket yang memerlukan perencanaan sumber daya yang lebih baik. Dominasi tiket `REPORTING` menyoroti peluang besar untuk efisiensi melalui otomatisasi dan standarisasi. Anomali `Selisih Days` negatif adalah peringatan serius tentang kualitas data yang harus segera diperbaiki pada tingkat sistem pencatatan. Terakhir, konsentrasi beban kerja pada satu PIC tunggal merupakan risiko operasional yang signifikan yang memerlukan evaluasi strategis untuk distribusi beban kerja dan skalabilitas. **Rekomendasi Tambahan:** 1. **Optimasi Respons Periode Puncak:** Manfaatkan pola tren bulanan untuk merencanakan alokasi sumber daya secara proaktif, mungkin dengan menunda proyek non-kritis atau menyiapkan tim cadangan selama bulan-bulan puncak (Maret dan Juni). 2. **Kaji Ulang Proses `REPORTING`:** Lakukan studi lebih lanjut untuk mengidentifikasi laporan mana yang dapat diotomatisasi sepenuhnya, laporan mana yang dapat dipermudah dengan template, dan mana yang benar-benar memerlukan intervensi manual PIC. 3. **Investigasi Anomali `Selisih Days`:** Prioritaskan perbaikan sistem yang menghasilkan `Selisih Days` negatif. Hal ini bisa berarti meninjau ulang definisi metrik, proses entri data, atau sinkronisasi waktu antar sistem. Akurasi metrik ini sangat penting untuk evaluasi kinerja yang valid. 4. **Tinjau Beban Kerja PIC Pham Ngoc Yen Huy:** Lakukan audit menyeluruh terhadap beban kerja PIC L260151 (Pham Ngoc Yen Huy). Pertimbangkan untuk mengimplementasikan rotasi tugas, pelatihan silang, atau merekrut staf tambahan untuk mengurangi ketergantungan pada satu individu dan meningkatkan ketahanan operasional. --- ## 6. Analisis Performa dan Penanggung Jawab Tiket ## 6. Analisis Performa dan Penanggung Jawab Tiket Bab ini akan mengulas performa penanganan tiket berdasarkan metrik `Selisih Days` dan menganalisis peran serta beban kerja penanggung jawab tiket (PIC), serta bagaimana pola permintaan dari superior klien memengaruhi dinamika ini. Pemahaman mendalam tentang aspek-aspek ini krusial untuk mengidentifikasi area efisiensi, merancang strategi alokasi sumber daya yang lebih baik, dan memastikan kualitas layanan yang optimal. ### 6.1. Durasi Penanganan Tiket Berdasarkan Jenis Durasi `Selisih Days` mencerminkan waktu yang dibutuhkan sejak tiket dibuat hingga tanggal pengambilan data (22 Juni 2026). Analisis ini memberikan gambaran tentang kompleksitas atau waktu pengerjaan yang khas untuk setiap kategori tiket. Perlu diingat bahwa 21 tiket dengan nilai `Selisih Days` negatif telah ditandai sebagai `NaN` pada proses pembersihan data (lihat Bab 4) untuk memastikan akurasi perhitungan. **Tabel 6.1: Rata-rata Selisih Days Berdasarkan Jenis Tiket** | Jenis Tiket | Rata-rata Selisih Hari | |:--------------|:-----------------------| | BUGFIX | 70.9 | | DEVELOPMENT | 61.0 | | REPORTING | 52.5 | Dari tabel di atas, terlihat jelas bahwa tiket `BUGFIX` dan `DEVELOPMENT` memiliki rata-rata `Selisih Days` yang lebih tinggi dibandingkan dengan tiket `REPORTING`. * **Tiket `BUGFIX`** membutuhkan rata-rata **70.9 hari**, menunjukkan bahwa perbaikan *bug* seringkali memerlukan investigasi, replikasi masalah, pengembangan solusi, dan pengujian yang intensif. * **Tiket `DEVELOPMENT`** membutuhkan rata-rata **61.0 hari**, yang juga wajar mengingat proses pengembangan fitur baru melibatkan berbagai tahapan mulai dari perencanaan, desain, coding, hingga pengujian. * **Tiket `REPORTING`** memiliki rata-rata `Selisih Days` terendah, yaitu **52.5 hari**. Hal ini konsisten dengan sifatnya yang cenderung lebih terstruktur dan berulang, seringkali melibatkan penarikan data atau pembuatan laporan standar. **Wawasan Bisnis:** Perbedaan durasi ini mengindikasikan bahwa tiket `BUGFIX` dan `DEVELOPMENT` secara intrinsik lebih kompleks dan memakan waktu. Meskipun tiket `REPORTING` mendominasi volume (96.3% dari total tiket, lihat Bab 5), durasi per tiketnya relatif lebih pendek. Ini memperkuat rekomendasi untuk mengotomatisasi atau menyederhanakan proses `REPORTING` agar PIC dapat mengalokasikan lebih banyak waktu dan perhatian pada tiket yang lebih kompleks dan kritis seperti `BUGFIX` dan `DEVELOPMENT`. Mengoptimalkan `REPORTING` akan membantu mengurangi *backlog* dan meningkatkan waktu respons untuk jenis tiket lainnya. Distribusi `Selisih Days` untuk setiap jenis tiket dapat dilihat lebih detail pada box plot berikut: ![Visualisasi](/agent/api/download?file=/tmp/selisih_days_by_ticket_type_boxplot.png) **Gambar 6.1: Box Plot Distribusi 'Selisih Days' Berdasarkan Jenis Tiket** Box plot ini menunjukkan variabilitas durasi dalam setiap jenis tiket. Meskipun `REPORTING` memiliki median dan rata-rata yang lebih rendah, terdapat juga outlier dengan durasi yang sangat panjang. Ini bisa menunjukkan bahwa tidak semua tiket `REPORTING` sederhana; beberapa mungkin melibatkan laporan yang sangat kompleks atau kustom yang memerlukan waktu signifikan. Tiket `BUGFIX` dan `DEVELOPMENT` juga menunjukkan variasi yang cukup besar, dengan beberapa tiket membutuhkan waktu penyelesaian yang ekstrem, menyoroti tantangan dalam memperkirakan dan mengelola proyek-proyek ini. ### 6.2. Beban Kerja dan Performa Penanggung Jawab Tiket (PIC) Salah satu temuan paling menonjol dari analisis awal adalah konsentrasi beban kerja pada satu PIC tunggal. Seluruh 539 tiket yang tercatat dalam dataset ini ditangani oleh **L260151 (Pham Ngoc Yen Huy)**. **Tabel 6.2: Rata-rata Selisih Days oleh PIC** | PIC (NIP) | Rata-rata Selisih Hari | |:--------------|:-----------------------| | L260151 | 52.95 | *Catatan: Nilai ini sedikit berbeda dari rata-rata 55.7 hari di atas karena Tabel 6.2 ini diambil dari data *sebelum* penanganan anomali `Selisih Days` negatif (yaitu, masih mengandung nilai negatif), sedangkan analisis di atas menggunakan data *setelah* penanganan anomali.* Meskipun tabel di atas menunjukkan rata-rata `Selisih Days` untuk PIC tersebut, ini tidak dapat digunakan untuk perbandingan performa antar-PIC karena tidak ada PIC lain dalam dataset. Temuan ini lebih mengindikasikan struktur organisasi atau pembagian tugas yang ekstrem. **Implikasi Bisnis dari Konsentrasi PIC Tunggal:** 1. **Risiko *Single Point of Failure*:** Organisasi sangat bergantung pada satu individu. Jika PIC ini tidak dapat bertugas (sakit, cuti, resign), seluruh operasional penanganan tiket dapat terhenti atau sangat terganggu, mengakibatkan penumpukan tiket dan penurunan kepuasan pengguna. 2. **Beban Kerja Berlebihan dan *Burnout*:** Menangani ratusan tiket dari berbagai jenis dan kompleksitas dapat menyebabkan beban kerja yang sangat tinggi, stres, dan kelelahan (burnout). Hal ini berpotensi menurunkan kualitas pekerjaan dan memperlambat waktu penyelesaian. 3. **Keterbatasan Skalabilitas:** Model ini tidak akan mampu menopang pertumbuhan volume tiket di masa depan. Peningkatan permintaan akan langsung membebani satu individu secara eksponensial. 4. **Kurangnya Spesialisasi dan *Knowledge Sharing*:** Meskipun PIC mungkin sangat kompeten, sulit bagi satu orang untuk menjadi ahli di semua bidang (`REPORTING`, `DEVELOPMENT`, `BUGFIX`). Selain itu, kurangnya tim berarti minimnya *knowledge sharing* dan pengembangan keahlian bersama. **Rekomendasi:** Sangat penting untuk melakukan validasi lebih lanjut apakah dataset ini benar-benar mencerminkan kondisi operasional secara keseluruhan atau hanya merupakan subset yang difilter untuk satu PIC. Jika ini adalah gambaran utuh, maka tindakan strategis berikut sangat diperlukan: * **Diversifikasi Tanggung Jawab:** Segera identifikasi dan latih anggota tim lain untuk berbagi tanggung jawab penanganan tiket. Ini bisa dilakukan melalui program pelatihan silang (cross-training). * **Struktur Tim:** Pertimbangkan untuk membentuk tim dengan spesialisasi yang berbeda untuk menangani jenis tiket yang berbeda, seperti tim khusus untuk `REPORTING`, `DEVELOPMENT`, dan `BUGFIX`. * **Sistem Eskalasi dan Cadangan:** Bangun sistem eskalasi yang jelas dan pastikan ada PIC cadangan untuk setiap jenis tiket. * **Implementasi Sistem Manajemen Beban Kerja:** Gunakan alat atau proses untuk memantau dan mendistribusikan beban kerja secara adil di antara tim untuk mencegah kelelahan. ### 6.3. Performa Tiket Berdasarkan Peminta (Client Superior) Permintaan tiket tidak merata di antara semua superior klien. Beberapa superior menjadi sumber utama tiket, dan hal ini juga berkorelasi dengan rata-rata `Selisih Days` yang berbeda. **Tabel 6.3: Rata-rata Selisih Days Berdasarkan Nama Superior Klien (Top 10)** | Nama Superior Klien | Rata-rata Selisih Hari | |:------------------------|:-----------------------| | Hendrykus Uca Sukarsa | 85.3 | | Agung Imawan | 62.2 | | Bahar Budianto | 58.2 | | Yasinta Hendrata | 57.4 | | Janto Kusmanto | 53.4 | | Joestine Soeseno, MA | 48.0 | | Kamilo Fideliant Iqbal | 47.9 | | Handry Suryadi | 40.4 | | VIRYA CHANDRA | 25.8 | | Arthur Timotius Lembong | 13.0 | Variasi rata-rata `Selisih Days` ini dapat disebabkan oleh beberapa faktor: * **Jenis Permintaan yang Diajukan:** Superior klien tertentu mungkin cenderung mengajukan tiket dengan kompleksitas yang lebih tinggi. Misalnya, jika Hendrykus Uca Sukarsa sering mengajukan tiket `BUGFIX` atau `DEVELOPMENT` yang kompleks, wajar jika rata-rata `Selisih Days`-nya lebih tinggi. * **Prioritas atau Urgensi:** Beberapa permintaan mungkin memiliki prioritas lebih rendah atau sebaliknya, seringkali datang dari klien yang tiketnya diprioritaskan. * **Kualitas Komunikasi dan Informasi:** Kelengkapan dan kejelasan informasi yang diberikan oleh peminta tiket dapat memengaruhi kecepatan PIC dalam memulai dan menyelesaikan tugas. Untuk memahami lebih lanjut, mari kita lihat distribusi jenis tiket dari 5 superior klien teratas: **Tabel 6.4: Distribusi Jenis Tiket untuk Top 5 Klien** **Klien: Yasinta Hendrata** (224 tiket) | Jenis Tiket | Jumlah Tiket | Persentase (%) | |:--------------|:-------------|:---------------| | REPORTING | 220 | 98.2 | | DEVELOPMENT | 2 | 0.9 | | BUGFIX | 2 | 0.9 | **Klien: Bahar Budianto** (78 tiket) | Jenis Tiket | Jumlah Tiket | Persentase (%) | |:--------------|:-------------|:---------------| | REPORTING | 77 | 98.7 | | BUGFIX | 1 | 1.3 | **Klien: Kamilo Fideliant Iqbal** (56 tiket) | Jenis Tiket | Jumlah Tiket | Persentase (%) | |:--------------|:-------------|:---------------| | REPORTING | 49 | 87.5 | | DEVELOPMENT | 7 | 12.5 | **Klien: Joestine Soeseno, MA** (49 tiket) | Jenis Tiket | Jumlah Tiket | Persentase (%) | |:--------------|:-------------|:---------------| | REPORTING | 48 | 98.0 | | DEVELOPMENT | 1 | 2.0 | **Klien: Arthur Timotius Lembong** (33 tiket) | Jenis Tiket | Jumlah Tiket | Persentase (%) | |:--------------|:-------------|:---------------| | REPORTING | 33 | 100.0 | **Wawasan Bisnis:** * Mayoritas superior klien teratas sangat dominan dalam mengajukan tiket `REPORTING`. Ini mengindikasikan bahwa sebagian besar permintaan mereka adalah untuk laporan atau data. * **Arthur Timotius Lembong** memiliki rata-rata `Selisih Days` terendah (13.0 hari) dan semua tiketnya adalah `REPORTING`. Ini mungkin menunjukkan bahwa permintaan laporannya sangat standar atau sederhana, sehingga dapat diproses dengan cepat. * **Kamilo Fideliant Iqbal** memiliki proporsi tiket `DEVELOPMENT` yang relatif lebih tinggi (12.5%) dibandingkan klien lain, yang mungkin menjelaskan `Selisih Days` rata-ratanya yang sedikit lebih tinggi daripada Arthur, namun masih di bawah rata-rata umum. * Klien seperti **Hendrykus Uca Sukarsa** yang memiliki rata-rata `Selisih Days` tertinggi, perlu diinvestigasi lebih lanjut jenis tiket spesifik apa yang mereka ajukan, karena datanya tidak tersedia di tabel ini. **Rekomendasi:** * **Segmentasi Klien:** Pertimbangkan untuk mengelompokkan klien berdasarkan jenis dan kompleksitas permintaan mereka. Ini dapat membantu dalam menyesuaikan ekspektasi dan strategi penanganan. * **Edukasi dan Layanan Mandiri:** Untuk klien dengan dominasi tiket `REPORTING` yang tinggi, berikan edukasi tentang fitur laporan yang sudah tersedia atau kembangkan portal layanan mandiri agar mereka bisa mendapatkan data yang dibutuhkan tanpa harus mengajukan tiket manual. * **Dialog Proaktif:** Lakukan dialog dengan superior klien yang memiliki rata-rata `Selisih Days` sangat tinggi atau sangat rendah untuk memahami faktor-faktor penyebabnya. Ini dapat mengungkap peluang untuk efisiensi atau kebutuhan dukungan yang belum terpenuhi. ### 6.4. Dampak Anomali Data pada Analisis Performa Anomali `Selisih Days` negatif yang ditemukan pada 21 tiket adalah contoh kritis bagaimana kualitas data dapat secara langsung memengaruhi keakuratan analisis performa. Jika nilai-nilai negatif ini tidak ditangani, mereka akan mendistorsi perhitungan rata-rata, median, dan metrik lainnya, memberikan gambaran yang salah tentang efisiensi penanganan tiket. **Dampak pada Performa:** * Jika `Selisih Days` diartikan sebagai waktu penyelesaian, nilai negatif akan menyiratkan bahwa tiket diselesaikan bahkan sebelum dibuat, yang mustahil. * Nilai negatif akan secara artifisial menurunkan rata-rata `Selisih Days` keseluruhan, membuat performa terlihat lebih baik dari yang sebenarnya. * Kehadiran anomali ini mengurangi kepercayaan terhadap data dan metrik performa yang dihitung. **Rekomendasi:** * **Perbaikan Akar Masalah:** Prioritaskan investigasi dan perbaikan akar masalah yang menyebabkan munculnya `Selisih Days` negatif pada sistem pencatatan. Ini mungkin melibatkan peninjauan alur kerja, validasi input data, atau sinkronisasi sistem. * **Standardisasi Definisi Metrik:** Pastikan definisi yang jelas dan konsisten untuk `Selisih Days` dan metrik performa lainnya di seluruh organisasi. Secara keseluruhan, analisis performa menunjukkan adanya ruang besar untuk optimasi, terutama dalam mengelola volume tiket `REPORTING`, mendiversifikasi beban kerja PIC, dan memahami dinamika permintaan klien untuk meningkatkan efisiensi dan kepuasan secara keseluruhan. ## 7. Analisis Pemohon Tiket ## 7. Analisis Pemohon Tiket Memahami siapa yang mengajukan tiket adalah kunci untuk mengidentifikasi kebutuhan pengguna, mengelola ekspektasi, dan menyelaraskan layanan dengan prioritas bisnis. Bab ini akan menganalisis pola permintaan tiket dari pemohon individual (`name`) dan atasan mereka (`client_superior_name`), menyelidiki bagaimana volume permintaan dan jenis tiket memengaruhi waktu penanganan, serta menyoroti area untuk perbaikan komunikasi dan efisiensi. ### 7.1 Identifikasi Pemohon Tiket Individu Analisis langsung terhadap kolom `name` (nama pembuat tiket) mengungkapkan individu-individu yang paling aktif dalam mengajukan tiket. Informasi ini penting untuk memahami sumber permintaan pada tingkat granular. **Tabel 7.1: Top 10 Pemohon Tiket Individu (`name`)** | Nama Pemohon | Jumlah Tiket | |:--------------------------|:-------------| | LARASSANTI KUSUMOSARI | 33 | | Stephanie Dyah | 32 | | Megie Yolanda Yacobus | 30 | | Devi Elisabeth | 30 | | Togi Marito Silaban | 27 | | Fitri Anita | 25 | | Juni Saputra | 21 | | Handry Suryadi | 19 | | Aicintya Christy | 18 | | M. Rizky Kurniawan | 16 | **Wawasan Bisnis:** Data ini menunjukkan bahwa sejumlah kecil individu bertanggung jawab atas sebagian besar permintaan tiket. LARASSANTI KUSUMOSARI dan Stephanie Dyah adalah pemohon paling aktif. Mengidentifikasi individu-individu ini memungkinkan tim PIC untuk: * Membangun hubungan yang lebih baik dan proaktif. * Memahami kebutuhan spesifik mereka untuk menawarkan solusi yang lebih baik, seperti pelatihan penggunaan sistem atau akses ke laporan *self-service*. * Mendeteksi potensi area di mana mereka mungkin memerlukan dukungan tambahan atau klarifikasi. ### 7.2 Analisis Superior Pemohon Tiket (`client_superior_name`) Meskipun pemohon individu penting, mengelompokkan permintaan berdasarkan atasan klien (`client_superior_name`) memberikan perspektif strategis tentang unit atau departemen mana yang paling sering menggunakan layanan. **Tabel 7.2: Top 10 Superior Klien Pemohon Tiket** | Nama Superior Klien | Jumlah Tiket | |:------------------------|:-------------| | Yasinta Hendrata | 224 | | Bahar Budianto | 78 | | Kamilo Fideliant Iqbal | 56 | | Joestine Soeseno, MA | 49 | | Arthur Timotius Lembong | 33 | | Handry Suryadi | 18 | | Hendrykus Uca Sukarsa | 12 | | Agung Imawan | 12 | | Janto Kusmanto | 11 | | VIRYA CHANDRA | 11 | **Wawasan Bisnis:** Temuan ini dengan jelas menunjukkan konsentrasi permintaan tiket dari beberapa superior klien. Yasinta Hendrata adalah sumber permintaan tiket terbesar, dengan 224 tiket (sekitar 41.5% dari total 539 tiket). Dominasi ini mengindikasikan: * **Ketergantungan Fungsional:** Unit bisnis atau tim di bawah superior ini mungkin sangat bergantung pada layanan atau data yang disediakan melalui sistem tiket. * **Peluang Optimalisasi Khusus:** Ada peluang besar untuk berkolaborasi langsung dengan superior teratas ini untuk memahami kebutuhan inti mereka dan mengembangkan solusi yang lebih efisien, seperti dasbor khusus, otomatisasi laporan, atau *dedicated support*. * **Risiko Bottleneck:** Konsentrasi permintaan yang tinggi dari satu sumber dapat menciptakan *bottleneck* jika tidak dikelola dengan baik. ### 7.3 Dampak Pemohon Terhadap Durasi Tiket (`Selisih Days`) Variasi dalam rata-rata `Selisih Days` antar superior klien dapat menunjukkan perbedaan dalam jenis permintaan, tingkat kompleksitas, atau bahkan prioritas yang diberikan. **Tabel 7.3: Rata-rata Selisih Hari Berdasarkan Nama Superior Klien (Top 10)** | Nama Superior Klien | Rata-rata Selisih Hari | |:------------------------|:-----------------------| | Hendrykus Uca Sukarsa | 85.3 | | Agung Imawan | 62.2 | | Bahar Budianto | 58.2 | | Yasinta Hendrata | 57.4 | | Janto Kusmanto | 53.4 | | Joestine Soeseno, MA | 48.0 | | Kamilo Fideliant Iqbal | 47.9 | | Handry Suryadi | 40.4 | | VIRYA CHANDRA | 25.8 | | Arthur Timotius Lembong | 13.0 | **Wawasan Bisnis:** * **Variasi Durasi:** Rata-rata `Selisih Days` sangat bervariasi, dari 13.0 hari (Arthur Timotius Lembong) hingga 85.3 hari (Hendrykus Uca Sukarsa). Ini menyiratkan bahwa beberapa klien mungkin mengajukan permintaan yang lebih sederhana atau dengan prioritas lebih tinggi, sementara yang lain mengajukan permintaan yang lebih kompleks atau kurang mendesak. * **Penyebab Perbedaan:** Perbedaan ini bisa disebabkan oleh: * **Jenis tiket yang diajukan:** Klien dengan rata-rata `Selisih Days` tinggi mungkin cenderung meminta tiket `BUGFIX` atau `DEVELOPMENT` yang kompleks. * **Kualitas informasi:** Klien yang memberikan detail permintaan yang jelas dan lengkap mungkin mengalami waktu penyelesaian yang lebih cepat. * **Prioritas:** Beberapa permintaan mungkin secara inheren memiliki prioritas yang berbeda, memengaruhi waktu tanggap. ### 7.4 Pola Permintaan Berdasarkan Jenis Tiket dari Superior Klien Teratas Untuk memahami lebih lanjut mengapa rata-rata `Selisih Days` bervariasi, mari kita analisis jenis tiket yang diajukan oleh superior klien teratas. **Klien: Yasinta Hendrata** (224 tiket, rata-rata 57.4 hari) | Jenis Tiket | Jumlah Tiket | Persentase (%) | |:--------------|:-------------|:---------------| | REPORTING | 220 | 98.2 | | DEVELOPMENT | 2 | 0.9 | | BUGFIX | 2 | 0.9 | **Klien: Bahar Budianto** (78 tiket, rata-rata 58.2 hari) | Jenis Tiket | Jumlah Tiket | Persentase (%) | |:--------------|:-------------|:---------------| | REPORTING | 77 | 98.7 | | BUGFIX | 1 | 1.3 | **Klien: Kamilo Fideliant Iqbal** (56 tiket, rata-rata 47.9 hari) | Jenis Tiket | Jumlah Tiket | Persentase (%) | |:--------------|:-------------|:---------------| | REPORTING | 49 | 87.5 | | DEVELOPMENT | 7 | 12.5 | **Klien: Joestine Soeseno, MA** (49 tiket, rata-rata 48.0 hari) | Jenis Tiket | Jumlah Tiket | Persentase (%) | |:--------------|:-------------|:---------------| | REPORTING | 48 | 98.0 | | DEVELOPMENT | 1 | 2.0 | **Klien: Arthur Timotius Lembong** (33 tiket, rata-rata 13.0 hari) | Jenis Tiket | Jumlah Tiket | Persentase (%) | |:--------------|:-------------|:---------------| | REPORTING | 33 | 100.0 | **Wawasan Bisnis:** * **Dominasi `REPORTING` dari Klien Utama:** Seperti yang terlihat dari gambaran umum data, tiket `REPORTING` mendominasi permintaan dari superior klien teratas. Bahkan, Arthur Timotius Lembong, dengan rata-rata `Selisih Days` terendah, mengajukan 100% tiket `REPORTING`. Hal ini memperkuat hipotesis bahwa tiket `REPORTING` cenderung memiliki waktu penyelesaian lebih cepat jika standar. * **Korelasi Jenis Tiket dengan Durasi:** Kamilo Fideliant Iqbal, yang memiliki proporsi tiket `DEVELOPMENT` tertinggi di antara top 5 klien (12.5%), memiliki rata-rata `Selisih Days` 47.9 hari, yang masih relatif baik. Hal ini mungkin menunjukkan bahwa meskipun `DEVELOPMENT` umumnya memakan waktu lebih lama, tim PIC mampu mengelola permintaan ini dengan cukup efisien atau permintaan `DEVELOPMENT` dari klien ini tidak terlalu kompleks. * **Fokus Investasi:** Untuk klien dengan rata-rata `Selisih Days` yang tinggi (misalnya Hendrykus Uca Sukarsa, yang tidak masuk top 5 tetapi disebutkan memiliki rata-rata tertinggi di Tabel 7.3), perlu diinvestigasi lebih lanjut jenis tiket apa yang mereka ajukan. Apakah mereka sering meminta `BUGFIX` atau `DEVELOPMENT` yang memakan waktu lama, atau apakah ada faktor lain yang menyebabkan keterlambatan? ### 7.5 Anomali dan Kualitas Data Terkait Informasi Pemohon Kualitas data yang berkaitan dengan informasi pemohon masih menjadi perhatian. **Tabel 7.4: Ringkasan Nilai Hilang pada Informasi Pemohon** | Kolom | Jumlah Nilai Hilang | Persentase (%) | |:-----------------------|:--------------------|:---------------| | `email` | 83 | 15.4 | | `name` | 24 | 4.5 | | `phone_number` | 19 | 3.5 | | `client_superior` | 3 | 0.6 | | `client_superior_name` | 3 | 0.6 | **Wawasan Bisnis:** * **Hambatan Komunikasi:** Nilai yang hilang pada `email`, `name`, dan `phone_number` merupakan hambatan signifikan untuk komunikasi efektif dengan pemohon tiket. Ini dapat menyebabkan keterlambatan dalam memperoleh klarifikasi, memberikan pembaruan, atau menyelesaikan masalah. * **Manajemen Hubungan Klien:** Ketiadaan `client_superior` atau `client_superior_name` menyulitkan pelacakan permintaan dari perspektif organisasi klien, yang penting untuk manajemen hubungan jangka panjang dan pemahaman kebutuhan bisnis yang lebih luas. ### Rekomendasi Berdasarkan analisis pemohon tiket, beberapa rekomendasi strategis dapat diajukan: 1. **Perbaiki Kelengkapan Data Kontak Pemohon:** * **Proaktif Isi Nilai Hilang:** Lakukan upaya untuk melengkapi `email`, `name`, dan `phone_number` yang hilang, setidaknya untuk tiket-tiket yang aktif atau dari pemohon yang sering. Ini dapat dilakukan melalui klarifikasi langsung atau integrasi dengan sistem informasi karyawan/klien. * **Validasi Input:** Terapkan validasi pada formulir pengajuan tiket untuk memastikan informasi kontak wajib diisi. 2. **Kembangkan Strategi Proaktif untuk Klien Bervolume Tinggi:** * **Sesi Diskusi Reguler:** Jadwalkan pertemuan atau diskusi reguler dengan Yasinta Hendrata, Bahar Budianto, dan superior klien bervolume tinggi lainnya untuk memahami kebutuhan mereka secara mendalam dan mengidentifikasi potensi otomatisasi atau solusi *self-service*. * **Laporan *Self-Service*:** Kembangkan dasbor atau portal di mana klien dapat menarik laporan standar sendiri, mengurangi ketergantungan pada PIC untuk tiket `REPORTING` rutin. Ini akan sangat bermanfaat bagi klien seperti Arthur Timotius Lembong yang 100% tiketnya adalah `REPORTING`. 3. **Investigasi Variasi Durasi Berdasarkan Superior Klien:** * **Analisis Jenis Tiket Detail:** Untuk superior klien dengan rata-rata `Selisih Days` yang sangat tinggi (misalnya Hendrykus Uca Sukarsa), selidiki secara detail jenis tiket spesifik yang mereka ajukan. Apakah ada jenis `BUGFIX` atau `DEVELOPMENT` yang berulang dan sangat kompleks? * **Ulasan Proses:** Tinjau ulang proses penanganan tiket untuk permintaan dari klien-klien ini. Apakah ada *bottleneck* atau area di mana klarifikasi informasi memakan waktu lebih lama? 4. **Edukasi Pemohon:** * Berikan panduan atau pelatihan kepada pemohon tiket (baik individu maupun superior) tentang cara mengajukan tiket yang efektif, termasuk memberikan deskripsi yang jelas, informasi yang lengkap, dan prioritas yang tepat. Hal ini dapat mengurangi waktu klarifikasi dan mempercepat proses penanganan. Dengan menerapkan rekomendasi ini, organisasi dapat tidak hanya meningkatkan efisiensi operasional dalam penanganan tiket tetapi juga membangun hubungan yang lebih kuat dengan pemohon dengan memenuhi kebutuhan mereka secara lebih efektif. ## 8. Kesimpulan ## 8. Kesimpulan Analisis Data Eksplorasi (EDA) terhadap tiket yang sedang berjalan telah memberikan gambaran komprehensif mengenai efisiensi operasional, pola permintaan pengguna, dan beban kerja tim penanganan tiket. Laporan ini menyoroti area-area kunci yang memerlukan perhatian segera dan peluang untuk peningkatan strategis. ### 8.1. Ikhtisar Temuan Kunci 1. **Kualitas Data Kritis Membutuhkan Perhatian:** * **Anomali `Selisih Days` Negatif:** Ditemukan **21 tiket** dengan `Selisih Days` negatif (misalnya, -36 hari), yang secara logis tidak mungkin terjadi. Anomali ini mengindikasikan masalah serius pada proses pencatatan data atau perhitungan metrik, yang secara fundamental memengaruhi akurasi pengukuran kinerja. * **Nilai Hilang pada Informasi Kontak:** Terdapat banyak nilai hilang pada kolom `email` (83), `name` (24), dan `phone_number` (19). Kekosongan ini menjadi hambatan signifikan dalam komunikasi proaktif dan pelacakan tiket yang efisien. * **Tipe Data Tidak Konsisten:** Kolom tanggal (`ticket_createDate`, `task_begin`) awalnya tersimpan sebagai string, yang mengharuskan konversi untuk analisis berbasis waktu yang akurat. 2. **Tren Permintaan Tiket yang Tidak Merata:** * Volume tiket menunjukkan pola musiman yang jelas, dengan lonjakan signifikan pada **Maret 2026 (181 tiket)** dan **Juni 2026 (123 tiket)**. Ini mengindikasikan periode beban kerja puncak yang perlu diantisipasi. ![Visualisasi](/agent/api/download?file=/tmp/monthly_ticket_creation.png) * **Dominasi Tiket `REPORTING`:** Hampir seluruh tiket (96.3%) adalah permintaan `REPORTING`. Ini menunjukkan bahwa sebagian besar sumber daya dialokasikan untuk penarikan data atau pembuatan laporan. 3. **Beban Kerja Terkonsentrasi pada Satu PIC:** * Seluruh **539 tiket** dalam dataset ini ditangani oleh satu PIC tunggal, yaitu **L260151 (Pham Ngoc Yen Huy)**. Kondisi ini menciptakan risiko operasional yang tinggi dan beban kerja yang sangat terkonsentrasi. 4. **Variasi Durasi Penanganan Tiket:** * Setelah pembersihan anomali `Selisih Days` negatif, rata-rata `Selisih Days` untuk penanganan tiket adalah **55.7 hari**, dengan variasi yang luas dari 1 hingga 251 hari. ![Visualisasi](/agent/api/download?file=/tmp/selisih_days_histogram.png) * Tiket `BUGFIX` dan `DEVELOPMENT` memiliki rata-rata `Selisih Days` yang lebih tinggi (70.9 dan 61.0 hari) dibandingkan `REPORTING` (52.5 hari), menunjukkan kompleksitas inheren dari jenis tiket tersebut. ![Visualisasi](/agent/api/download?file=/tmp/selisih_days_by_ticket_type_boxplot.png) 5. **Pola Permintaan dari Klien Utama:** * Beberapa superior klien, khususnya **Yasinta Hendrata (224 tiket)** dan **Bahar Budianto (78 tiket)**, adalah sumber permintaan tiket terbesar. Mayoritas permintaan dari klien-klien ini juga didominasi oleh jenis `REPORTING`. * Rata-rata `Selisih Days` bervariasi signifikan antar superior klien, dari **13.0 hari** (Arthur Timotius Lembong) hingga **85.3 hari** (Hendrykus Uca Sukarsa). ### 8.2. Implikasi Bisnis dan Wawasan * **Risiko Operasional Akibat Ketergantungan Tunggal:** Ketergantungan penuh pada satu PIC untuk semua tiket merupakan *single point of failure* yang serius. Hal ini dapat menghambat skalabilitas, menyebabkan kelelahan karyawan, dan mengancam kontinuitas layanan jika PIC tersebut tidak tersedia. * **Peluang Besar untuk Otomatisasi `REPORTING`:** Dominasi tiket `REPORTING` menunjukkan bahwa sebagian besar waktu PIC dihabiskan untuk tugas yang berulang. Mengotomatisasi atau menyederhanakan proses pelaporan dapat membebaskan PIC untuk fokus pada tugas yang lebih kompleks dan bernilai tambah seperti pengembangan dan perbaikan bug. * **Keandalan Metrik Kinerja yang Terganggu:** Anomali `Selisih Days` negatif menimbulkan keraguan terhadap validitas metrik kinerja durasi tiket. Tanpa data yang akurat, evaluasi performa tim atau efisiensi proses menjadi tidak dapat diandalkan. * **Pentingnya Komunikasi Efektif:** Kurangnya informasi kontak yang lengkap dapat memperlambat proses klarifikasi dan pembaruan status tiket, menurunkan kepuasan pengguna dan efisiensi operasional. * **Manajemen Ekspektasi Klien:** Variasi dalam `Selisih Days` antar klien menunjukkan perlunya manajemen ekspektasi yang disesuaikan dan mungkin segmentasi layanan untuk berbagai jenis permintaan atau klien. ### 8.3. Rekomendasi Strategis Berdasarkan temuan di atas, berikut adalah rekomendasi yang ditujukan untuk meningkatkan efisiensi, kualitas data, dan kepuasan pengguna dalam manajemen tiket: 1. **Prioritaskan Perbaikan Kualitas Data Tiket:** * **Investigasi Anomali `Selisih Days` Negatif:** Segera lakukan *root cause analysis* untuk memahami mengapa nilai `Selisih Days` negatif muncul. Perbaiki sistem pencatatan atau definisi metrik untuk memastikan `Selisih Days` selalu positif dan akurat. Pertimbangkan untuk menghapus atau mengkoreksi data historis yang tidak valid ini jika memungkinkan. * **Lengkapi Informasi Kontak:** Terapkan validasi wajib pada formulir pengajuan tiket untuk `email`, `name`, dan `phone_number`. Lakukan upaya proaktif untuk melengkapi data yang hilang pada tiket yang sedang berjalan, terutama untuk pemohon yang aktif. 2. **Optimasi dan Otomatisasi Proses `REPORTING`:** * **Kembangkan Portal Laporan Mandiri:** Buat dasbor atau portal yang memungkinkan superior klien, terutama yang sering meminta laporan (misalnya Yasinta Hendrata, Bahar Budianto, Arthur Timotius Lembong), untuk mengakses dan menarik laporan standar sendiri. * **Standarisasi dan Otomatisasi Laporan Rutin:** Identifikasi laporan yang paling sering diminta dan pertimbangkan untuk mengotomatisasi pembuatannya atau menjadikannya laporan terjadwal yang dikirimkan secara otomatis. * **Edukasi Pengguna:** Berikan pelatihan kepada pemohon tiket mengenai cara menggunakan alat *self-service* dan bagaimana mengajukan permintaan laporan kustom secara efektif dengan detail yang lengkap. 3. **Diversifikasi Beban Kerja dan Struktur Tim:** * **Verifikasi Lingkup Data PIC:** Konfirmasikan apakah dataset ini benar-benar mencerminkan seluruh beban kerja satu PIC (Pham Ngoc Yen Huy) atau hanya subset data yang difilter. * **Distribusi Ulang Tugas:** Jika beban kerja terkonsentrasi, segera latih dan delegasikan tugas penanganan tiket kepada anggota tim lain untuk mengurangi risiko dan mencegah kelelahan. * **Pertimbangkan Struktur Tim Spesialis:** Bentuk tim yang memiliki spesialisasi berbeda (misalnya, tim `REPORTING`, `DEVELOPMENT`, `BUGFIX`) untuk meningkatkan efisiensi dan keahlian di setiap area. * **Sistem Cadangan dan Eskalasi:** Bangun sistem cadangan yang kuat dan alur eskalasi yang jelas untuk memastikan kelangsungan layanan. 4. **Manajemen Hubungan Klien yang Lebih Terarah:** * **Sesi Klien Proaktif:** Adakan pertemuan rutin dengan superior klien bervolume tinggi (misalnya, Yasinta Hendrata, Bahar Budianto) untuk memahami kebutuhan bisnis mereka secara mendalam dan berkolaborasi dalam solusi yang lebih efisien. * **Analisis Mendalam Klien `Selisih Days` Tinggi/Rendah:** Lakukan investigasi lebih lanjut untuk memahami mengapa beberapa klien memiliki `Selisih Days` rata-rata yang sangat tinggi (misalnya Hendrykus Uca Sukarsa) atau sangat rendah (Arthur Timotius Lembong). Ini dapat mengungkap praktik terbaik atau area masalah yang spesifik. 5. **Penyempurnaan Sistem Manajemen Tiket:** * Tinjau ulang konfigurasi sistem tiket untuk memastikan bahwa semua kolom yang relevan diisi, tipe data konsisten, dan perhitungan metrik seperti `Selisih Days` dilakukan secara akurat dan logis. Dengan mengimplementasikan rekomendasi ini, organisasi dapat beralih dari mode reaktif menjadi proaktif dalam manajemen tiket, meningkatkan efisiensi operasional, memperkuat kualitas data, dan pada akhirnya, memberikan layanan yang lebih baik kepada seluruh pengguna. ## 9. Rekomendasi ## 9. Rekomendasi Analisis Data Eksplorasi (EDA) yang telah dilakukan terhadap data tiket yang sedang berjalan telah mengungkap berbagai wawasan penting mengenai efisiensi operasional, pola permintaan pengguna, dan distribusi beban kerja tim. Berdasarkan temuan-temuan kunci dan anomali yang teridentifikasi, bab ini menyajikan rekomendasi strategis yang ditujukan untuk meningkatkan kualitas data, mengoptimalkan proses, mendiversifikasi beban kerja, serta memperkuat hubungan dengan pemohon tiket. Rekomendasi ini disusun untuk membantu organisasi beralih dari pendekatan reaktif menjadi proaktif dalam manajemen tiket, yang pada akhirnya akan meningkatkan kepuasan pengguna dan efisiensi operasional secara keseluruhan. ### 9.1. Peningkatan Kualitas dan Integritas Data Kualitas data yang baik adalah fondasi untuk setiap analisis yang akurat dan pengambilan keputusan yang tepat. Isu-isu kualitas data yang ditemukan memerlukan perhatian segera. #### 9.1.1. Investigasi dan Koreksi Anomali "Selisih Days" Negatif **Temuan Kritis:** Ditemukan **21 tiket** dengan nilai "Selisih Days" negatif, yang secara logis tidak mungkin terjadi karena durasi waktu tidak bisa kurang dari nol. Anomali ini sangat mengganggu validitas metrik kinerja dan menimbulkan keraguan terhadap keandalan data. **Rekomendasi:** * **Analisis Akar Masalah (Root Cause Analysis):** Segera lakukan investigasi mendalam untuk memahami penyebab munculnya nilai "Selisih Days" negatif. Pertanyaan yang perlu dijawab meliputi: * Apakah ada kesalahan dalam proses entri tanggal (misalnya, tanggal penyelesaian dicatat sebelum tanggal pembuatan)? * Apakah ada masalah pada rumus atau logika perhitungan "Selisih Days" dalam sistem? * Apakah ada inkonsistensi definisi "Selisih Days" atau masalah sinkronisasi waktu antar sistem? * **Tindakan Korektif Sistematis:** Berdasarkan akar masalah, implementasikan perbaikan pada sistem pencatatan atau perhitungan untuk mencegah terulangnya anomali ini di masa mendatang. * **Koreksi Data Historis:** Setelah penyebabnya dipahami, pertimbangkan untuk mengoreksi data historis dari 21 tiket yang terkena dampak. Jika koreksi manual tidak memungkinkan atau terlalu besar, tiket-tiket ini harus ditandai secara jelas atau dikecualikan dari perhitungan metrik kinerja durasi untuk menjaga akurasi. #### 9.1.2. Peningkatan Kelengkapan Informasi Kontak Pemohon **Temuan Kritis:** Terdapat sejumlah besar nilai hilang pada informasi kontak (`email`, `name`, `phone_number`) dan detail atasan klien. **Tabel 9.1: Ringkasan Nilai Hilang pada Informasi Pemohon** | Kolom | Jumlah Nilai Hilang | Persentase (%) | |:-----------------------|:--------------------|:---------------| | `email` | 83 | 15.4% | | `name` | 24 | 4.5% | | `phone_number` | 19 | 3.5% | | `client_superior` | 3 | 0.6% | | `client_superior_name` | 3 | 0.6% | **Rekomendasi:** * **Validasi Wajib Formulir Tiket:** Terapkan validasi pada formulir pengajuan tiket untuk menjadikan kolom `email`, `name`, dan `phone_number` sebagai informasi wajib isi. * **Strategi Pengisian Data Proaktif:** Lakukan upaya untuk melengkapi data yang hilang pada tiket yang sedang berjalan, terutama untuk pemohon yang aktif atau tiket berprioritas tinggi. Ini bisa melibatkan klarifikasi langsung atau integrasi dengan sistem informasi karyawan/klien yang ada. * **Konsistensi Tipe Data:** Pastikan `phone_number` disimpan sebagai tipe data string (`object`) untuk mempertahankan format aslinya (misalnya, angka nol di depan) dan mencegah hilangnya presisi. ### 9.2. Optimalisasi Proses dan Efisiensi Operasional Distribusi tiket dan beban kerja saat ini menunjukkan adanya area signifikan untuk peningkatan efisiensi. #### 9.2.1. Diversifikasi Beban Kerja dan Mitigasi Risiko "Single Point of Failure" **Temuan Kritis:** Seluruh **539 tiket** dalam dataset ini ditangani oleh satu PIC tunggal, yaitu **L260151 (Pham Ngoc Yen Huy)**. Ini adalah risiko operasional yang sangat tinggi dan dapat menyebabkan kelelahan pada individu, keterlambatan penanganan, serta mengancam kelangsungan layanan jika PIC tersebut tidak tersedia. **Rekomendasi:** * **Validasi Lingkup Data:** Pertama, konfirmasi apakah dataset ini memang mencerminkan seluruh beban kerja organisasi atau hanya subset yang difilter untuk satu PIC. Jika ini adalah gambaran keseluruhan, tindakan segera diperlukan. * **Program Pelatihan Silang (Cross-Training):** Latih anggota tim lain untuk berbagi tanggung jawab penanganan tiket. Identifikasi jenis-jenis tiket yang dapat didelegasikan atau dibagi. * **Pembentukan Tim Spesialis:** Pertimbangkan untuk membentuk tim-tim kecil dengan spesialisasi berbeda (misalnya, Tim Pelaporan, Tim Pengembangan, Tim Perbaikan Bug) untuk mendistribusikan beban kerja dan meningkatkan keahlian di setiap area. * **Prosedur Cadangan dan Eskalasi yang Jelas:** Kembangkan dan komunikasikan prosedur yang jelas untuk penanganan tiket jika PIC utama tidak dapat dihubungi atau kewalahan. #### 9.2.2. Optimalisasi Penanganan Tiket "REPORTING" **Temuan Kritis:** Hampir seluruh tiket (96.3%) adalah permintaan `REPORTING`. Meskipun rata-rata durasinya relatif lebih pendek, volume yang sangat tinggi ini menyerap sebagian besar kapasitas PIC. **Tabel 9.2: Distribusi Jenis Tiket** | Jenis Tiket | Jumlah Tiket | Persentase (%) | |:--------------|:-------------|:---------------| | REPORTING | 519 | 96.3% | | DEVELOPMENT | 13 | 2.4% | | BUGFIX | 7 | 1.3% | | **Total** | **539** | **100.0%** | **Rekomendasi:** * **Pengembangan Portal Laporan Mandiri (Self-Service Portal):** Buat platform atau dasbor interaktif di mana pengguna dapat mengakses dan membuat laporan standar mereka sendiri. Ini akan sangat mengurangi jumlah tiket `REPORTING` manual yang masuk. * **Automasi Laporan Rutin:** Identifikasi laporan yang paling sering diminta dan pertimbangkan untuk mengotomatisasi proses pembuatannya atau menjadikannya laporan terjadwal yang dikirimkan secara otomatis kepada penerima. * **Standardisasi Permintaan Laporan:** Kembangkan template atau panduan yang jelas untuk permintaan laporan kustom, memastikan semua informasi yang diperlukan tersedia di awal untuk mempercepat proses PIC. * **Fokus Sumber Daya:** Dengan mengurangi beban tiket `REPORTING` manual, PIC dapat mengalokasikan lebih banyak waktu dan keahlian untuk tiket yang lebih kompleks dan bernilai tambah seperti `DEVELOPMENT` atau `BUGFIX`. #### 9.2.3. Manajemen Beban Kerja Puncak **Temuan Kritis:** Analisis tren bulanan menunjukkan lonjakan signifikan dalam volume pembuatan tiket pada **Maret 2026 (181 tiket)** dan **Juni 2026 (123 tiket)**. **Tabel 9.3: Tren Pembuatan Tiket Bulanan** | Bulan/Tahun | Jumlah Tiket | |:------------|:-------------| | 2025-08 | 4 | | 2025-09 | 1 | | 2025-10 | 2 | | 2025-11 | 3 | | 2025-12 | 3 | | 2026-01 | 6 | | 2026-02 | 32 | | 2026-03 | 181 | | 2026-04 | 103 | | 2026-05 | 81 | | 2026-06 | 123 | ![Visualisasi](/agent/api/download?file=/tmp/monthly_ticket_creation.png) **Gambar 9.1: Tren Pembuatan Tiket Bulanan** **Rekomendasi:** * **Perencanaan Kapasitas Proaktif:** Manfaatkan data historis ini untuk mengantisipasi periode puncak permintaan. Alokasikan sumber daya tambahan, jadwalkan ulang proyek non-kritis, atau siapkan tim cadangan untuk periode tersebut. * **Strategi Pengelolaan Backlog:** Kembangkan rencana darurat untuk mengelola potensi penumpukan tiket selama bulan-bulan puncak, seperti sistem prioritisasi yang lebih ketat atau komunikasi proaktif dengan pemohon mengenai potensi keterlambatan. ### 9.3. Pengelolaan Hubungan dan Kebutuhan Pengguna Memahami kebutuhan dan dinamika pemohon tiket adalah kunci untuk memberikan layanan yang lebih baik. #### 9.3.1. Keterlibatan Proaktif dengan Klien Bervolume Tinggi **Temuan Kritis:** Beberapa superior klien, seperti Yasinta Hendrata (224 tiket) dan Bahar Budianto (78 tiket), adalah sumber permintaan tiket terbesar. **Tabel 9.4: Top 10 Superior Klien Pemohon Tiket** | Nama Superior Klien | Jumlah Tiket | |:------------------------|:-------------| | Yasinta Hendrata | 224 | | Bahar Budianto | 78 | | Kamilo Fideliant Iqbal | 56 | | Joestine Soeseno, MA | 49 | | Arthur Timotius Lembong | 33 | | Handry Suryadi | 18 | | Hendrykus Uca Sukarsa | 12 | | Agung Imawan | 12 | | Janto Kusmanto | 11 | | VIRYA CHANDRA | 11 | **Rekomendasi:** * **Sesi Kolaborasi Strategis:** Adakan pertemuan rutin atau sesi diskusi dengan superior klien bervolume tinggi ini untuk memahami kebutuhan bisnis mereka secara lebih mendalam. Identifikasi apakah ada pola permintaan berulang yang dapat diselesaikan dengan solusi jangka panjang daripada tiket individual. * **Program Edukasi Pengguna:** Berikan pelatihan atau panduan kepada pemohon tiket (baik individu maupun superior) tentang cara mengajukan tiket yang efektif, termasuk pentingnya deskripsi yang jelas, informasi lengkap, dan penentuan prioritas yang tepat. Ini dapat mengurangi waktu klarifikasi dan mempercepat proses. #### 9.3.2. Analisis Mendalam Variasi Durasi Tiket per Klien **Temuan Kritis:** Rata-rata "Selisih Days" bervariasi signifikan antar superior klien, dari 13 hari (Arthur Timotius Lembong) hingga 85 hari (Hendrykus Uca Sukarsa). **Tabel 9.5: Rata-rata Selisih Hari Berdasarkan Nama Superior Klien (Top 10)** | Nama Superior Klien | Rata-rata Selisih Hari | |:------------------------|:-----------------------| | Hendrykus Uca Sukarsa | 85 | | Agung Imawan | 62 | | Bahar Budianto | 58 | | Yasinta Hendrata | 57 | | Janto Kusmanto | 53 | | Joestine Soeseno, MA | 48 | | Kamilo Fideliant Iqbal | 48 | | Handry Suryadi | 40 | | VIRYA CHANDRA | 26 | | Arthur Timotius Lembong | 13 | **Rekomendasi:** * **Segmentasi dan Penyesuaian Layanan:** Gunakan informasi ini untuk mengidentifikasi segmen klien yang mungkin memerlukan pendekatan yang berbeda. Misalnya, klien dengan `Selisih Days` rata-rata rendah (seperti Arthur Timotius Lembong, yang 100% tiketnya `REPORTING`) mungkin memerlukan akses yang lebih mudah ke alat *self-service*, sementara klien dengan `Selisih Days` rata-rata tinggi (seperti Hendrykus Uca Sukarsa) mungkin membutuhkan bantuan dalam mendefinisikan permintaan yang lebih jelas atau prioritisasi yang lebih baik. * **Investigasi Klien Tertentu:** Lakukan investigasi lebih lanjut untuk superior klien dengan `Selisih Days` yang sangat tinggi. Apa jenis tiket yang mereka ajukan? Apakah ada masalah komunikasi atau hambatan lain yang menyebabkan durasi yang panjang? ### 9.4. Pengembangan Sistem dan Kebijakan Untuk mendukung perbaikan yang berkelanjutan, tinjauan terhadap sistem dan kebijakan yang mendasari manajemen tiket adalah esensial. #### 9.4.1. Tinjauan Komprehensif Sistem Manajemen Tiket **Temuan Kritis:** Anomali data dan masalah tipe data menunjukkan adanya potensi kelemahan dalam konfigurasi atau fungsionalitas sistem yang digunakan. **Rekomendasi:** * **Audit Konfigurasi Sistem:** Lakukan audit menyeluruh terhadap konfigurasi sistem manajemen tiket saat ini. Pastikan bahwa semua bidang data yang relevan didefinisikan dengan benar, validasi input diterapkan secara efektif, dan perhitungan metrik (seperti "Selisih Days") dilakukan secara akurat dan logis. * **Integrasi Data:** Jika memungkinkan, jelajahi peluang untuk mengintegrasikan sistem tiket dengan sistem lain (misalnya, sistem HR untuk data karyawan, sistem CRM untuk data klien) untuk secara otomatis mengisi informasi kontak yang saat ini hilang. #### 9.4.2. Penyusunan Metrik Kinerja dan Kebijakan SLA yang Jelas **Temuan Kritis:** Metrik "Selisih Days" saat ini bermasalah, dan tanpa definisi yang jelas, evaluasi kinerja menjadi sulit. **Rekomendasi:** * **Definisi Metrik yang Konsisten:** Tetapkan definisi yang jelas dan konsisten untuk semua metrik kinerja tiket, termasuk "Selisih Days" (misalnya, apakah ini waktu dari pembuatan hingga penyelesaian, atau waktu dari pembuatan hingga status tertentu?). * **Penyusunan Perjanjian Tingkat Layanan (SLA):** Kembangkan SLA yang jelas untuk setiap jenis tiket (REPORTING, DEVELOPMENT, BUGFIX) dan, jika relevan, untuk segmen klien yang berbeda. Ini akan membantu mengelola ekspektasi, memberikan target yang terukur, dan memotivasi tim PIC untuk meningkatkan efisiensi. * **Pelaporan Kinerja Reguler:** Implementasikan sistem pelaporan kinerja tiket secara reguler berdasarkan metrik yang telah diperbaiki, sehingga manajemen dapat memantau progres dan mengidentifikasi area yang membutuhkan perhatian. ### 9.5. Langkah Lanjutan: Pemantauan dan Peningkatan Berkelanjutan Proses peningkatan efisiensi dan kualitas adalah perjalanan berkelanjutan. Organisasi harus berkomitmen untuk: * **Pemantauan Berkelanjutan:** Terus memantau kualitas data dan metrik kinerja tiket setelah implementasi rekomendasi. * **Siklus Umpan Balik:** Bangun mekanisme umpan balik yang kuat dari pengguna dan tim PIC untuk mengidentifikasi masalah baru atau area yang memerlukan perbaikan lebih lanjut. * **Inovasi dan Adaptasi:** Tetap terbuka terhadap teknologi baru dan praktik terbaik dalam manajemen tiket untuk terus meningkatkan layanan. Dengan mengimplementasikan rekomendasi-rekomendasi ini, organisasi dapat secara signifikan meningkatkan efisiensi operasional manajemen tiket, memperbaiki kualitas layanan yang diberikan kepada pengguna, dan membangun fondasi data yang lebih kuat untuk pengambilan keputusan strategis di masa depan.