ARIS SANDO HAMZAH

Pada 6 Mei 2026, saya memulai perjalanan mengikuti bootcamp Data Science and Machine Learning di Purwadhika. Hampir enam bulan kemudian, pada 22 Oktober 2026, perjalanan pembelajaran ini mencapai tahap sidang final project.

Data Science dan Machine Learning

Saya mengambil kelas Online Livestream After Hour, yang dilaksanakan secara daring pada malam hari. Pilihan ini memungkinkan saya tetap bekerja sebagai data analis sekaligus memperdalam kemampuan di bidang data science dan machine learning.

Menjalaninya tentu memiliki tantangan tersendiri. Setelah menyelesaikan pekerjaan pada siang hari, saya harus kembali menyiapkan energi dan konsentrasi untuk mengikuti kelas, mengerjakan latihan, serta menyelesaikan proyek. Ada malam ketika tubuh sudah lelah, sementara materi yang dipelajari masih membutuhkan perhatian penuh.

Capek dan lelah menjadi bagian yang wajar dalam proses ini. Namun, saya berusaha menjaga semangat dan konsisten hadir hingga akhir. Bagi saya, bootcamp ini sekaligus menjadi latihan mengatur waktu, menjaga komitmen, dan membangun kebiasaan belajar di tengah tanggung jawab pekerjaan.

Pembelajaran terbagi menjadi tiga modul utama: Programming Fundamental, Data Analysis, dan Machine Learning. Setiap modul dilengkapi evaluasi serta capstone project untuk menerapkan materi pada suatu permasalahan.

Modul 1 — Programming Fundamental: Membangun Dasar Logika Pemrograman

Pembelajaran dimulai pada 6 Mei 2026 dengan materi Introduction to Data Science, Computer & Programming. Pada sesi awal ini, mentor menjelaskan pengertian data science, ruang lingkup pekerjaannya, serta perannya dalam membantu organisasi memahami data dan mengambil keputusan.

Dari pengenalan tersebut, kami mulai masuk ke dasar pemrograman menggunakan Python. Materinya mencakup variabel, tipe data, input pengguna, dan conditional statements. Melalui percabangan seperti if, elif, dan else, saya belajar menerjemahkan suatu kondisi menjadi aturan yang dapat dijalankan oleh program.

Berikutnya, kami mempelajari looping statements atau perulangan. Konsep ini membantu menjalankan pekerjaan berulang secara otomatis. Sebagai contoh, for loop dapat digunakan untuk memeriksa setiap elemen data tanpa harus menuliskan instruksi yang sama berkali-kali. Ketika dikombinasikan dengan percabangan, program dapat memeriksa kondisi sekaligus menjalankan tindakan yang sesuai.

Kami juga mempelajari collection data types, seperti list, tuple, dictionary, dan set. Pada tahap ini, saya mulai memahami cara menyimpan sekumpulan data serta melakukan proses menambahkan, menampilkan, mengubah, dan menghapus data.

Materi selanjutnya adalah Python functions. Dengan fungsi, suatu proses dapat disusun menjadi bagian kode yang bisa digunakan kembali. Saya cukup memanggil fungsi tersebut ketika dibutuhkan, sehingga kode menjadi lebih terstruktur dan lebih mudah diperbaiki.

Capstone Project 1: Kalkulator Panen Udang

Setelah mengikuti pembelajaran dan evaluasi, saya membuat capstone project pertama berupa Kalkulator Panen Udang sederhana.

Saya memilih topik yang dekat dengan latar belakang dan pekerjaan saya di bidang akuakultur. Melalui proyek ini, konsep dasar Python mulai terasa lebih konkret karena digunakan untuk mengelola data panen dan membantu perhitungan usaha budidaya.

Proyek tersebut menjadi langkah awal saya dalam menghubungkan logika pemrograman dengan kebutuhan operasional yang saya pahami.

Baca selengkapnya: Aplikasi Python Sederhana: Kalkulator Panen Udang.

Modul 2 — Data Analysis: Mengolah Data hingga Menjadi Informasi

Modul kedua dimulai pada 20 Mei 2026 dengan pengenalan SQL. Pada tahap ini, pembelajaran berkembang dari membuat program menjadi mengambil, mengelola, dan menganalisis data.

SQL merupakan bahasa untuk berinteraksi dengan basis data relasional. Kami mempelajari penggunaannya melalui MySQL yang diinstal secara lokal, mulai dari membuat tabel, mengatur kolom, menambahkan dan memperbarui data, hingga menampilkan data sesuai kebutuhan.

Kami juga belajar melakukan agregasi, seperti menghitung jumlah observasi, menjumlahkan nilai, dan mencari rata-rata. Dengan JOIN, data dari beberapa tabel dapat dihubungkan berdasarkan kolom yang sesuai untuk membentuk dataset analisis.

Selain MySQL, kami diperkenalkan dengan Google BigQuery. Pengalaman ini membantu saya memahami pengolahan data di lingkungan cloud serta integrasinya dengan layanan lain, seperti Google Colab dan Looker Studio.

Python untuk Analisis Data

Setelah SQL, pembelajaran berlanjut ke Python for Data Analysis. Jika pada modul pertama Python digunakan untuk membangun dasar pemrograman, pada tahap ini penggunaannya lebih terarah pada pengolahan dan analisis data melalui notebook.

Kami menggunakan berbagai lingkungan kerja, seperti Jupyter Notebook, Google Colab, dan Visual Studio Code. Jupyter menjadi salah satu lingkungan yang sering saya gunakan karena memudahkan saya menjalankan kode secara bertahap sekaligus memeriksa hasilnya.

Kami mempelajari pandas untuk mengelola data berbentuk tabel, NumPy untuk operasi numerik, serta Matplotlib untuk visualisasi. Dari sini, saya mulai membangun alur kerja yang lebih terstruktur: membaca data, memeriksa isinya, membersihkan data, lalu mengolahnya untuk menjawab pertanyaan analisis.

Statistik sebagai Dasar Pengambilan Keputusan

Analisis data kemudian diperkuat melalui pembelajaran statistik. Kami membahas proses pengumpulan data, sampling, serta pemeriksaan kualitas data, termasuk missing value, ketidakkonsistenan kategori, outlier, dan anomali.

Saya semakin memahami bahwa kualitas analisis sangat dipengaruhi oleh kualitas data dan ketepatan metode yang digunakan. Angka yang terlihat menarik belum tentu cukup untuk mendukung suatu kesimpulan.

Dalam statistik deskriptif, kami belajar merangkum karakteristik data melalui ukuran pemusatan, penyebaran, dan visualisasi. Kami juga mempelajari kapan sebaiknya menggunakan bar chart, line chart, boxplot, atau grafik lainnya agar informasi mudah dipahami oleh audiens.

Pada statistik inferensial, kami mempelajari pengujian hipotesis serta asumsi yang perlu diperhatikan, seperti distribusi dan homogenitas varians. Beberapa metode yang dipelajari meliputi uji t, ANOVA, ANCOVA, Kruskal–Wallis, dan Chi-square.

Pembelajaran ini membantu saya membedakan antara perbedaan yang terlihat secara deskriptif dan perbedaan yang didukung oleh pengujian statistik. Saya juga belajar bahwa kesimpulan harus disesuaikan dengan desain penelitian dan karakteristik data yang tersedia.

Visualisasi, Dashboard, dan Storytelling

Setelah mempelajari statistik, kami memperdalam visualisasi menggunakan Python. Kami belajar mengatur jenis grafik, warna, label, serta tata letak agar hasil analisis lebih jelas dan nyaman dibaca.

Materi kemudian berlanjut ke storytelling with data dan presentasi. Pada tahap ini, tantangannya adalah menyusun penjelasan yang membantu audiens memahami masalah, temuan, dan implikasinya.

Kami juga mempelajari pembuatan dashboard menggunakan Looker Studio dan Tableau. Dashboard menjadi sarana untuk menyajikan indikator dan hasil analisis agar lebih mudah dipantau serta dieksplorasi.

ETL: Menyiapkan Data sebelum Dianalisis

Materi penutup modul kedua adalah ETL, yaitu Extract, Transform, dan Load.

Kami belajar mengambil data dari sumbernya, membersihkan dan mengubahnya sesuai kebutuhan, lalu memuat hasilnya ke penyimpanan tujuan. Dalam praktik pembelajaran, Google Colab digunakan untuk membantu pengolahan data, sedangkan BigQuery menjadi tempat penyimpanan hasil pengolahan yang kemudian dapat digunakan untuk analisis dan dashboard.

Prinsip garbage in, garbage out menjadi pengingat penting. Jika data yang masuk tidak diperiksa dengan baik, hasil analisis juga berisiko menyesatkan.

Saya mulai melihat bahwa pekerjaan data analis mencakup proses yang panjang sebelum grafik dan kesimpulan dihasilkan. Menyiapkan data yang konsisten, relevan, dan dapat dipercaya merupakan bagian penting dari pekerjaan tersebut.

Capstone Project 2: Revenue Leakage & Billing Control Tower Analysis

Setelah mengikuti evaluasi modul kedua, saya mengerjakan Revenue Leakage & Billing Control Tower Analysis.

Proyek ini menggunakan kasus fiktif dengan data simulasi sebagai latihan membangun alur analisis dari pemahaman masalah bisnis, proses ETL, hingga penyajian dashboard.

Melalui proyek ini, saya berlatih menghubungkan pengolahan data dengan kebutuhan pemantauan tagihan, tunggakan, dan potensi kebocoran pendapatan. Pengalaman tersebut memperlihatkan bagaimana keterampilan analisis dapat diterapkan pada konteks bisnis di luar bidang pekerjaan saya sehari-hari.

Baca selengkapnya: Dari ETL hingga Dashboard: Proses Analisis Revenue Leakage & Billing Control Tower.

Modul 3 — Machine Learning: Menghubungkan Prediksi dengan Kebutuhan Bisnis

Pembelajaran machine learning dimulai pada 13 Juli 2026. Kami diperkenalkan pada konsep dasar, jenis permasalahan yang dapat ditangani, serta alasan penggunaan machine learning.

Salah satu pelajaran yang paling saya ingat adalah pentingnya memilih pendekatan berdasarkan kebutuhan. Tidak semua masalah memerlukan machine learning. Dalam beberapa situasi, analisis deskriptif, pengujian statistik, atau aturan bisnis yang sederhana sudah dapat memberikan jawaban yang memadai.

Pemahaman ini membantu saya lebih berhati-hati dalam menentukan metode. Tujuan analisis dan kebutuhan pengguna perlu dipahami sebelum memilih algoritma.

Memahami Supervised dan Unsupervised Learning

Kami mempelajari dua kelompok utama machine learning, yaitu supervised learning dan unsupervised learning.

Pada supervised learning, model belajar dari data yang memiliki target. Target tersebut dapat berupa nilai numerik untuk regresi atau kategori untuk klasifikasi. Klasifikasi juga dapat melibatkan dua kelas maupun lebih dari dua kelas.

Sementara itu, unsupervised learning digunakan untuk mengeksplorasi pola atau struktur dalam data tanpa target berlabel.

Pada supervised learning, kami mempelajari berbagai algoritma, seperti Linear Regression, Logistic Regression, dan Random Forest. Setiap algoritma memiliki karakteristik dan keterbatasan yang perlu dipertimbangkan sesuai data serta tujuan penggunaannya.

Data Preparation dan Feature Engineering

Tahap berikutnya adalah data preparation dan feature engineering. Kami memeriksa kualitas data, melakukan Exploratory Data Analysis atau EDA, serta mengeksplorasi hubungan antarvariabel melalui boxplot, scatter plot, dan heatmap korelasi.

Kami juga belajar membuat fitur baru yang relevan dengan permasalahan. Proses ini menuntut pemahaman konteks, karena sebuah fitur perlu memiliki makna yang masuk akal bagi tujuan analisis.

Dalam pemodelan, kami mempelajari penggunaan pipeline untuk menyatukan preprocessing dan algoritma. Prosesnya dapat mencakup imputasi missing value, encoding fitur kategorikal, serta scaling pada fitur numerik sesuai kebutuhan model.

Hal penting dalam alur ini adalah memisahkan data latih dan data uji sebelum mempelajari parameter preprocessing. Dengan demikian, informasi dari data uji tidak ikut digunakan untuk melatih model dan menimbulkan data leakage.

Evaluasi Model dan Hyperparameter Tuning

Kami kemudian mempelajari generalization, overfitting, dan underfitting. Model perlu dievaluasi untuk mengetahui kemampuannya mempelajari pola yang dapat digunakan pada data baru.

Performa pada data latih perlu dibandingkan dengan hasil validasi. Pemilihan model dan hyperparameter tuning dilakukan menggunakan data latih serta proses validasi, sedangkan data uji digunakan untuk menilai performa akhir setelah keputusan pemodelan ditetapkan.

Melalui proses ini, saya memahami bahwa pemilihan model memerlukan evaluasi yang terukur. Model yang lebih kompleks belum tentu memberikan hasil yang lebih sesuai dengan kebutuhan.

Machine Learning for Business

Materi Machine Learning for Business memperluas cara saya menilai suatu model. Evaluasi mencakup dampak operasional dan biaya dari keputusan yang dihasilkan.

Setiap kesalahan prediksi dapat memiliki konsekuensi yang berbeda. Karena itu, pemilihan metrik perlu mempertimbangkan tujuan bisnis, biaya kesalahan, serta kapasitas tim yang akan menggunakan hasil prediksi.

Kami juga membandingkan skenario penggunaan model dengan skenario tanpa model. Dari sini, saya belajar menerjemahkan performa teknis menjadi pertimbangan bisnis yang lebih konkret, termasuk potensi penghematan biaya dan pemanfaatan sumber daya.

End-to-End Machine Learning dan Deployment

Pada bagian akhir, kami mempelajari alur machine learning secara menyeluruh dan menerapkan model melalui Streamlit.

Tahap ini memperlihatkan bagaimana hasil pemodelan dapat disajikan melalui aplikasi yang lebih mudah digunakan. Pengguna dapat memasukkan data dan melihat hasil prediksi tanpa harus menjalankan kode secara langsung.

Bagi saya, deployment menjadi penghubung antara pekerjaan analisis dan penggunaan model dalam suatu alur kerja.

Capstone Project 3: Bank Marketing Campaign

Setelah mengikuti evaluasi modul ketiga, termasuk ujian Perceptual Logic, saya mengerjakan capstone project Bank Marketing Campaign.

Proyek ini berfokus pada prediksi nasabah yang berpotensi membuka deposito untuk membantu penyusunan prioritas campaign. Saya menerapkan tahapan pembelajaran mulai dari memahami masalah bisnis, menyiapkan data, membangun dan mengevaluasi model, hingga menyajikannya melalui aplikasi.

Proyek ini juga melatih saya mempertimbangkan dampak false positive dan false negative terhadap biaya campaign serta peluang nasabah potensial yang terlewat.

Baca selengkapnya: Prediksi Nasabah Potensial Deposito dengan Machine Learning.

Perjalanan Bootcamp

Final Project — Olist Seller Churn bersama Tim Alpha

Setelah menyelesaikan tiga modul beserta evaluasinya, kami mengikuti proses seleksi untuk masuk ke tahap final project. Peserta kemudian dibagi menjadi tiga tim: Alpha, Beta, dan Gamma.

Saya bergabung dalam Tim Alpha bersama Rifdah Octavi Azzahra dan Dzakwan Taufiq Nur Muhammad. Kami mengangkat topik Seller Churn pada marketplace Olist untuk membantu mengidentifikasi seller berisiko dan mendukung penentuan prioritas campaign retensi.

Keberlanjutan aktivitas seller merupakan bagian penting dalam bisnis marketplace. Berkurangnya seller aktif dapat memengaruhi variasi produk, volume transaksi, dan potensi pendapatan platform. Konteks tersebut menjadi dasar bagi kami dalam merumuskan tujuan proyek.

Selama pengerjaan, kami berkoordinasi dua kali dalam seminggu dan menjalani empat sesi konsultasi bersama mentor, masing-masing satu kali setiap minggu. Diskusi tersebut menjadi kesempatan untuk meninjau perkembangan, mengevaluasi pendekatan, dan memperbaiki bagian yang masih perlu diperkuat.

Final project menjadi tempat kami menggabungkan pembelajaran dari ketiga modul: memahami permasalahan bisnis, mengolah data, melakukan analisis, membangun model, serta menyampaikan hasil dan rekomendasi.

Pengerjaan secara tim juga memberikan pengalaman dalam membagi tanggung jawab, menyelaraskan pemahaman, dan menjelaskan alasan di balik setiap keputusan analisis.

Pada 22 Oktober 2026, kami mengikuti sidang final project sebagai tahapan akhir dari rangkaian pembelajaran bootcamp ini.

Baca selengkapnya: Dari Data Menjadi Solusi Bisnis: Proyek Olist Seller Churn.

Sebagai seorang magister perikanan yang bekerja sebagai data analis, mendalami data science memberikan tantangan tersendiri. Saya perlu memperkuat kemampuan pemrograman, statistik, dan pemodelan, sekaligus membiasakan diri dengan cara kerja serta perangkat yang baru.

Namun, latar belakang perikanan juga memberikan bekal yang berharga. Pengalaman di bidang akuakultur membantu saya memahami konteks data, kebutuhan operasional, dan pertanyaan yang relevan bagi pengguna hasil analisis.

Selama bootcamp, saya semakin memahami pentingnya domain knowledge atau pengetahuan bidang. Kemampuan teknis perlu berjalan bersama pemahaman terhadap proses bisnis agar analisis dan model yang dibuat dapat digunakan secara tepat.

Perjalanan dari kelas pertama pada 6 Mei hingga sidang final project pada 22 Oktober 2026 menjadi pengalaman belajar yang berarti bagi saya. Ada materi yang harus dipelajari berulang kali, kode yang perlu diperbaiki, serta waktu istirahat yang harus diatur kembali agar pekerjaan dan pembelajaran tetap berjalan.

Menyelesaikan bootcamp ini memberi saya fondasi untuk terus berkembang. Saya ingin membawa pembelajaran tersebut ke pekerjaan sehari-hari dan mengembangkan penerapan data science dalam akuakultur—mulai dari meningkatkan kualitas data, mengevaluasi performa budidaya, hingga membangun alat bantu keputusan yang sesuai dengan kebutuhan di lapangan.

Setelah mengikuti tiga rangkaian modul pembelajaran beserta evaluasinya, perjalanan belajar kami berlanjut ke tahap final project. Pada tahap ini, kami diseleksi dan dibagi menjadi tiga tim, yaitu Alpha, Beta, dan Gamma.

Saya bergabung dalam Tim Alpha bersama Rifdah Octavi Azzahra dan Dzakwan Taufiq Nur Muhammad. Kami mengerjakan proyek analisis data Olist dengan fokus pada prediksi seller churn, yaitu mengidentifikasi seller yang berpotensi berhenti bertransaksi agar dapat diprioritaskan dalam program retensi.

Final project ini menjadi kesempatan untuk menghubungkan materi yang telah dipelajari dengan satu proses kerja yang lengkap: memahami masalah bisnis, mengolah data, membangun model, membuat dashboard dan aplikasi, hingga mempertanggungjawabkan hasil analisis di hadapan penguji.

Membangun ritme kerja bersama tim

Selama penyusunan proyek, kami melakukan koordinasi dua kali dalam seminggu. Pertemuan ini menjadi ruang untuk membahas perkembangan pekerjaan, menyelaraskan analisis, dan menyelesaikan kendala yang muncul.

Kami juga menjalani empat sesi konsultasi rutin bersama mentor, dengan frekuensi satu kali setiap minggu. Konsultasi membantu kami meninjau pendekatan yang digunakan dan mengarahkan pekerjaan menuju tujuan proyek.

Koordinasi menjadi penting karena hasil pekerjaan kami saling terhubung. Definisi churn yang digunakan dalam notebook harus konsisten dengan dashboard. Fitur yang digunakan saat melatih model juga harus sama dengan masukan pada aplikasi prediksi. Seluruh hasil tersebut kemudian perlu dijelaskan dengan runtut dalam presentasi.

Alur Proses Final Project

Mengapa memilih seller churn?

Olist merupakan platform marketplace yang menghubungkan seller dan pelanggan di Brasil. Keberlanjutan aktivitas seller penting karena seller yang berhenti bertransaksi dapat mengurangi pilihan produk, volume transaksi, dan potensi pendapatan platform.

Dari konteks tersebut, kami mengangkat pertanyaan: bagaimana data historis dapat membantu mengidentifikasi seller berisiko churn dan mendukung prioritas campaign retensi?

Dalam proyek ini, churn ditetapkan menggunakan aturan aktivitas transaksi dan periode observasi. Seller yang belum memiliki histori memadai dipisahkan sebagai not eligible. Penetapan aturan ini penting agar seller baru tidak langsung dianggap churn hanya karena belum banyak bertransaksi.

Kami juga memperhatikan pemisahan antara data historis sebelum tanggal cutoff dan periode yang digunakan untuk menentukan label. Informasi yang digunakan untuk memprediksi harus sudah tersedia pada saat prediksi dilakukan.

Memulai analisis melalui Google Colab

Kami menggunakan notebook Google Colab untuk mengolah dan menganalisis data. Data sumber mencakup informasi pesanan, item, seller, customer, pembayaran, produk, dan geolocation.

Tantangan awalnya adalah perbedaan tingkat rincian antartabel. Satu pesanan dapat memiliki beberapa item dan beberapa record pembayaran. Apabila seluruh tabel langsung digabungkan, jumlah baris dapat berlipat dan menyebabkan nilai transaksi terhitung berulang.

Karena itu, kami melakukan agregasi sebelum penggabungan. Informasi transaksi diringkas sesuai kebutuhan hingga terbentuk dataset dengan satu baris untuk satu seller.

Proses pengolahan juga mencakup penyesuaian tipe tanggal, pemeriksaan missing value, penanganan duplikasi lokasi, penyeragaman kategori, serta validasi koordinat geografis.

Tahap ini membutuhkan perhatian karena kesalahan pada penggabungan atau perhitungan fitur akan terbawa ke analisis berikutnya, meskipun model berhasil dijalankan.

Mengubah transaksi menjadi karakteristik seller

Catatan transaksi kemudian kami olah menjadi fitur yang menggambarkan aktivitas dan karakteristik seller. Beberapa contohnya adalah:

• Jumlah order historis.

• Hari sejak order terakhir.

• Rata-rata jeda antarorder.

• Jumlah hari aktif bertransaksi.

• Jumlah produk dan kategori produk yang terjual.

• Total harga produk.

• Jarak geografis antara seller dan customer.

Fitur tersebut membantu model mengenali perbedaan pola aktivitas seller. Misalnya, jumlah order menunjukkan volume aktivitas, sedangkan rata-rata jeda antarorder membantu menggambarkan keteraturan transaksi.

Melalui exploratory data analysis atau EDA, kami memeriksa distribusi fitur, nilai ekstrem, hubungan antarfitur, serta perbedaan pola antara seller churn dan tidak churn. Hasil eksplorasi digunakan untuk memahami data dan mendukung pemilihan fitur, dengan tetap membedakan hubungan statistik dari hubungan sebab akibat.

Dataset pemodelan yang dilaporkan dalam proyek mencakup 2.692 seller eligible dengan 14 fitur numerik terpilih.

Menyiapkan data sebelum pemodelan

Sebelum melatih model, data dibagi menjadi data latih dan data uji dengan proporsi 80:20. Data latih digunakan untuk pembelajaran dan pemilihan konfigurasi model, sedangkan data uji digunakan untuk evaluasi akhir.

Preprocessing dilakukan melalui pipeline yang mencakup pengisian nilai kosong menggunakan median dan scaling menggunakan RobustScaler.

Pengisian median membantu menyediakan masukan numerik ketika sebagian fitur tidak tersedia. Sementara itu, RobustScaler menyetarakan skala fitur berdasarkan median dan rentang antarkuartil. Pendekatan ini relevan untuk data transaksi yang dapat memiliki rentang lebar dan nilai ekstrem.

Statistik preprocessing dipelajari dari data latih, kemudian diterapkan pada data validasi, data uji, dan masukan aplikasi. Dengan cara ini, proses prediksi menggunakan transformasi yang konsisten.

Membandingkan model dan memilih Logistic Regression

Kami membandingkan 13 model, termasuk Logistic Regression, KNN, Decision Tree, Random Forest, beberapa algoritma boosting, serta metode ensemble seperti voting dan stacking.

Evaluasi menggunakan F2-score dengan perhatian pada recall kelas churn. Recall menunjukkan seberapa banyak seller churn yang berhasil terdeteksi. F2-score menggabungkan precision dan recall dengan penekanan lebih besar pada recall, sesuai tujuan mengurangi seller churn yang terlewat.

Pada perbandingan awal, Random Forest menghasilkan rata-rata skor validasi tertinggi. Namun, pemilihan model juga mempertimbangkan selisih skor pelatihan dan validasi serta kemudahan interpretasi.

Kami memilih Logistic Regression untuk dikembangkan lebih lanjut. Model ini menghitung probabilitas churn dari kombinasi fitur seller, lalu mengubahnya menjadi keputusan kelas berdasarkan threshold.

Koefisiennya membantu menjelaskan arah hubungan fitur terhadap prediksi. Dengan fitur lain tetap, koefisien positif meningkatkan log-odds churn, sedangkan koefisien negatif menurunkannya. Interpretasi ini tetap merupakan hubungan prediktif dan tidak langsung menunjukkan penyebab churn.

Selanjutnya, kami melakukan hyperparameter tuning menggunakan GridSearchCV lima fold dengan F2-score sebagai metrik pemilihan. Presentasi proyek mencatat nilai C terpilih sebesar 0,001. Parameter C mengatur kekuatan regularisasi: semakin kecil nilainya, semakin kuat pembatasan terhadap besar koefisien.

Membawa hasil analisis ke dashboard dan aplikasi

Kami menyusun dashboard menggunakan Looker Studio dengan dua halaman utama. Seller Performance digunakan untuk memantau performa seller dan penjualan, sedangkan Seller Churn digunakan untuk memantau status aktivitas dan tingkat churn.

Dashboard Olist

Kami juga mengembangkan aplikasi machine learning menggunakan Streamlit. Aplikasi menyediakan dua cara penggunaan: input manual untuk satu seller dan unggahan CSV untuk prediksi beberapa seller sekaligus.

Hasil prediksi menampilkan status beserta probabilitas churn. Probabilitas memberikan informasi tambahan mengenai tingkat risiko menurut model, sehingga pengguna dapat mempertimbangkannya ketika menyusun prioritas tindak lanjut.

Dashboard dan aplikasi memiliki fungsi yang saling melengkapi. Dashboard membantu membaca kondisi secara agregat, sedangkan aplikasi membantu menghasilkan prediksi pada data seller yang dimasukkan.

Proses Kerja Aplikasi Machine Learning Seller Churn

Menyusun presentasi dan menghadapi sidang

Setelah analisis, dashboard, dan aplikasi disusun, kami merangkainya menjadi presentasi. Pada tahap ini, kami perlu menyampaikan hubungan antara masalah bisnis, keputusan pengolahan data, pemodelan, dan rekomendasi dalam waktu yang terbatas.

Puncak final project berlangsung pada 22 Oktober 2026, ketika Tim Alpha menjalani sidang di hadapan dua orang penguji.

Kami memperoleh waktu 20 menit untuk mempresentasikan proyek. Setelah itu, sesi tanya jawab dan pengujian berlangsung selama kurang lebih satu jam sepuluh menit.

Sidang menjadi tahap untuk mempertanggungjawabkan proses yang telah kami kerjakan. Hasil proyek perlu disertai penjelasan mengenai alasan pemilihan metode, cara membaca evaluasi, dan batas penggunaan model.

Pembelajaran dari final project

Melalui proyek ini, saya belajar melihat pekerjaan data sebagai rangkaian keputusan yang saling berkaitan. Definisi target memengaruhi penyusunan dataset. Penggabungan tabel memengaruhi ketepatan fitur. Evaluasi model memengaruhi bagaimana hasilnya layak digunakan.

Saya juga semakin memahami pentingnya membedakan skor prediksi dengan dampak bisnis. Model yang mampu mengenali seller churn belum otomatis membuktikan bahwa campaign akan berhasil mempertahankan seller. Efektivitas intervensi tetap perlu diuji dan diukur.

Perjalanan bersama Tim Alpha memberi pengalaman bekerja dari data sumber hingga hasil yang dapat dikomunikasikan dan digunakan. Terima kasih kepada kedua rekan tim, mentor, dan para penguji yang telah menjadi bagian dari proses pembelajaran ini.

https://github.com/ashamzah/JCDSAH-026_Alpha/tree/main

Belum bisa menambah penghasilan? Setidaknya, kita bisa mulai memahami ke mana uang kita pergi.

Pernah merasa baru menerima gaji, tetapi beberapa hari kemudian saldo sudah jauh berkurang? Lalu muncul pertanyaan, “Uangnya habis untuk apa saja, ya?” 😅

Pengeluaran besar biasanya mudah diingat. Justru pengeluaran kecil seperti jajan, transportasi, atau hiburan sering lewat begitu saja. Ketika terus berulang, jumlahnya bisa cukup terasa di akhir bulan.

Household Finance Apps

Karena itu, saya mengembangkan aplikasi sederhana untuk pencatatan keuangan rumah tangga menggunakan AppSheet. Tujuannya adalah memudahkan pencatatan pemasukan dan pengeluaran melalui smartphone, lalu mengolah catatan tersebut menjadi informasi yang bisa dievaluasi.

1. Input Data: Mencatat Transaksi melalui Smartphone

Pencatatan dimulai dari form input di aplikasi. Setiap transaksi dicatat dengan beberapa informasi berikut:

Setelah informasi diisi, pengguna menekan tombol Save untuk menyimpan catatan. Tombol Cancel digunakan untuk membatalkan pengisian.

Dengan form ini, pencatatan memiliki struktur yang sama untuk setiap transaksi. Kita bisa mengetahui kapan transaksi terjadi, siapa yang terkait, serta jenis, kategori, dan nominalnya.

Kebiasaan yang ingin dibangun sederhana: setelah melakukan transaksi, luangkan sebentar untuk mencatatnya. Jadi, saat akhir bulan, kita punya riwayat yang bisa diperiksa kembali.

2. Kalender: Mencari dan Mengedit Data Historis

Mencatat transaksi saja belum cukup. Kadang kita perlu melihat kembali pengeluaran pada tanggal tertentu atau memperbaiki catatan yang keliru.

Fitur Kalender membantu pengguna menelusuri transaksi berdasarkan tanggal. Tampilan aplikasi menyediakan pilihan Day, Week, dan Month, sehingga riwayat bisa dilihat dalam rentang harian, mingguan, maupun bulanan.

Misalnya, ketika ingin memeriksa transaksi minggu lalu, pengguna dapat membuka periode tersebut dan memilih catatan yang ingin ditinjau. Jika ada kesalahan pada tanggal, kategori, atau nominal, catatan dapat dibuka kembali untuk diedit.

Fitur ini memudahkan penelusuran data historis tanpa harus mengingat seluruh transaksi yang pernah dilakukan.

3. Grafik: Melihat Tren Pengeluaran

Daftar transaksi memberikan detail, sementara grafik membantu kita melihat pola dari waktu ke waktu.

Melalui fitur Grafik, pengguna dapat meninjau tren pengeluaran: kapan nominal meningkat, kapan menurun, dan tanggal mana yang perlu diperiksa lebih lanjut.

Jika terlihat lonjakan, langkah berikutnya adalah membuka catatan pada periode tersebut untuk memahami penyebabnya. Bisa jadi ada kebutuhan rutin, pembayaran tertentu, atau pengeluaran yang memang perlu dievaluasi.

Grafik menjadi titik awal untuk bertanya dan menelusuri data, sehingga evaluasi keuangan memiliki dasar yang lebih jelas.

Dari Catatan Harian ke Dashboard

Data yang diinput melalui aplikasi tersimpan di Google Sheets sebagai riwayat transaksi. Selain dilihat melalui grafik di AppSheet, data tersebut juga digunakan dalam dashboard Looker Studio untuk analisis lebih lanjut.

Alurnya sederhana: mencatat melalui smartphone, menyimpan riwayat di spreadsheet, kemudian meninjau data melalui grafik dan dashboard.

Sebagai data analis, proyek ini menjadi salah satu cara saya menerapkan proses pengumpulan, penyimpanan, dan visualisasi data pada kebutuhan sehari-hari.

Penghasilan tambahan mungkin belum bisa langsung bertambah. Namun, memahami pola pengeluaran bisa dimulai dari transaksi yang kita catat hari ini.

Kalau kamu, sudah rutin mencatat pemasukan dan pengeluaran, atau masih mengandalkan ingatan? 🙂

Beberapa waktu terakhir saya kembali mencoba mengembangkan project machine learning, kali ini menggunakan studi kasus Bank Marketing Campaign.

Permasalahan yang ingin diselesaikan cukup sederhana: bagaimana cara membantu tim telemarketing menentukan nasabah yang lebih berpotensi membuka deposito?

Dalam campaign konvensional, bank dapat menghubungi banyak nasabah tanpa mengetahui siapa yang memiliki peluang konversi lebih tinggi. Strategi tersebut memang dapat menjangkau lebih banyak nasabah, tetapi juga membutuhkan biaya, waktu, dan kapasitas tim yang cukup besar.

Karena itu, saya mencoba membangun model klasifikasi yang dapat mempelajari data campaign sebelumnya dan memberikan prediksi terhadap potensi nasabah dalam membuka deposito.

Model ini tidak dibuat untuk menggantikan keputusan bisnis, tetapi digunakan sebagai alat bantu dalam menyusun prioritas target campaign.

Data tidak menggantikan keputusan; data membantu kita membuat keputusan yang lebih tepat.

📌 Business Understanding

Sebelum membangun model, hal pertama yang perlu dipahami adalah dampak dari setiap kesalahan prediksi.

Dalam project ini, target True berarti nasabah membuka deposito, sedangkan False berarti nasabah tidak membuka deposito.

Terdapat dua kesalahan prediksi yang perlu diperhatikan:

1. False Positive
   Model memprediksi nasabah akan membuka deposito, tetapi aktualnya tidak. Dampaknya adalah biaya dan sumber daya campaign digunakan untuk nasabah yang tidak melakukan konversi.
2. False Negative
   Model memprediksi nasabah tidak akan membuka deposito, tetapi aktualnya nasabah tersebut membuka deposito. Dampaknya adalah nasabah potensial tidak menjadi target campaign sehingga peluang bisnis dapat terlewat.

Berdasarkan kebutuhan tersebut, saya memilih Recall sebagai metrik utama.

Recall menunjukkan seberapa banyak nasabah yang aktualnya membuka deposito berhasil ditemukan oleh model. Semakin tinggi Recall, semakin sedikit nasabah potensial yang terlewat.

Namun, Recall yang tinggi juga dapat meningkatkan False Positive. Oleh karena itu, hasil model tetap perlu diterjemahkan ke dalam konteks biaya dan kapasitas campaign.

📊 Data Understanding dan EDA

Dataset yang digunakan memiliki informasi karakteristik nasabah dan riwayat campaign, seperti:

• usia;
• pekerjaan;
• saldo;
• kepemilikan housing loan;
• kepemilikan personal loan;
• metode kontak;
• bulan campaign;
• jumlah kontak selama campaign;
• jarak waktu dari campaign sebelumnya; dan
• hasil campaign sebelumnya.

Setelah menghapus data duplikat, terdapat 7.805 observasi yang digunakan dalam proses analisis.

Pada tahap Exploratory Data Analysis, saya memeriksa distribusi setiap variabel, komposisi target, missing value, data duplikat, outlier, serta hubungan awal antara karakteristik nasabah dan keputusan membuka deposito.

Tahap ini penting karena model yang baik tidak hanya bergantung pada algoritma, tetapi juga pada pemahaman terhadap kualitas dan karakteristik data.

[Sisipkan gambar distribusi target]

🧹 Data Preprocessing

Setiap fitur memiliki karakteristik yang berbeda sehingga metode preprocessing tidak bisa disamaratakan.

Beberapa metode yang digunakan dalam project ini antara lain:

SimpleImputer

SimpleImputer digunakan untuk menangani missing value.

• Mean digunakan pada fitur yang relatif stabil.
• Median digunakan pada fitur dengan distribusi miring atau memiliki outlier.
• Most frequent digunakan pada fitur kategorikal atau diskrit.

Tujuannya agar missing value dapat ditangani tanpa menghapus terlalu banyak data.

Scaling

Beberapa metode scaling digunakan sesuai karakteristik fitur:

• MinMaxScaler mengubah data ke rentang yang lebih terkontrol.
• StandardScaler menyetarakan skala berdasarkan mean dan standard deviation.
• RobustScaler menggunakan median dan IQR sehingga lebih tahan terhadap outlier.

Scaling membantu memastikan perbedaan satuan antarfitur tidak memberikan pengaruh yang tidak proporsional selama proses modeling.

Encoding

Data kategorikal perlu diubah menjadi format numerik agar dapat diproses oleh model.

Metode yang digunakan meliputi:

• OneHotEncoder untuk kategori nominal;
• BinaryEncoder untuk fitur dengan kategori yang relatif banyak; dan
• OrdinalEncoder untuk kategori yang memiliki urutan tertentu.

Seluruh proses preprocessing ditempatkan di dalam pipeline.

Pipeline memastikan preprocessing dan model dijalankan sebagai satu rangkaian proses. Struktur ini juga membantu mencegah data leakage karena transformer hanya mempelajari informasi dari data training pada setiap proses validasi.

🔄 Pembagian Data dan Validasi

Data dibagi menjadi training set dan test set dengan proporsi 80:20.

Pembagian dilakukan menggunakan metode stratified agar proporsi kelas deposito dan tidak deposito tetap relatif sama pada kedua kelompok data.

Saya juga menggunakan random_state=42 agar proses pengacakan dapat direproduksi. Angka 42 bukan berarti mengambil 42 data, tetapi hanya berfungsi sebagai seed dalam proses pengacakan.

Pada data training, evaluasi dilakukan menggunakan 5-fold Stratified Cross-Validation.

Data training dibagi menjadi lima bagian. Empat bagian digunakan untuk melatih model dan satu bagian digunakan untuk validasi. Proses tersebut diulang hingga setiap bagian pernah menjadi data validasi.

Pendekatan ini memberikan evaluasi yang lebih stabil dibandingkan hanya menggunakan satu kali pembagian data.

🤖 Model Benchmarking

Beberapa algoritma klasifikasi dibandingkan terlebih dahulu, yaitu:

• K-Nearest Neighbors;
• Logistic Regression;
• Decision Tree;
• XGBoost;
• AdaBoost; dan
• CatBoost.

Perbandingan dilakukan menggunakan Recall cross-validation.

Dari proses benchmarking, XGBoost memberikan performa yang paling sesuai untuk tujuan project. XGBoost mampu menangkap hubungan non-linear, interaksi antarfitur, serta memiliki mekanisme regularisasi untuk membantu mengurangi overfitting.

[Sisipkan gambar model benchmarking]

⚙️ Hyperparameter Tuning dengan GridSearchCV

Setelah algoritma dipilih, saya melakukan hyperparameter tuning menggunakan GridSearchCV.

GridSearchCV mencoba seluruh kombinasi parameter yang telah ditentukan, kemudian mengevaluasi setiap kombinasi menggunakan cross-validation.

Parameter yang diuji meliputi:

• n_estimators;
• max_depth;
• learning_rate; dan
• scale_pos_weight.

Kombinasi parameter terbaik yang diperoleh adalah:

• n_estimators = 100;
• max_depth = 3;
• learning_rate = 0.01; dan
• scale_pos_weight = 1.5.

Nilai scale_pos_weight membantu meningkatkan perhatian model terhadap kelas positif. Hal ini sesuai dengan tujuan project yang berfokus pada kemampuan menemukan nasabah potensial.

📈 Hasil Evaluasi Model

Model final menghasilkan performa sebagai berikut:

• Recall cross-validation: 91,09%;
• Recall test: 91,42%;
• ROC-AUC test: 75,05%;
• True Negative: 258;
• False Positive: 557;
• False Negative: 64; dan
• True Positive: 682.

Recall test sebesar 91,42% berarti model berhasil menemukan sekitar 91 dari setiap 100 nasabah yang aktualnya membuka deposito.

Nilai Recall cross-validation dan test juga relatif berdekatan. Hal ini menunjukkan performa model cukup konsisten dan tidak memperlihatkan indikasi overfitting yang berarti.

Meskipun demikian, model menghasilkan False Positive yang cukup tinggi. Kondisi ini merupakan trade-off dari optimasi Recall karena model dibuat lebih sensitif dalam menangkap kelas deposito.

[Sisipkan gambar confusion matrix]

ROC-AUC sebesar 75,05% menunjukkan model memiliki kemampuan yang cukup baik dalam membedakan nasabah deposito dan tidak deposito pada berbagai threshold.

[Sisipkan gambar ROC curve]

💰 Business Loss Analysis

Evaluasi model tidak berhenti pada metrik statistik.

Saya membandingkan tiga skenario campaign menggunakan asumsi biaya:

• biaya False Negative sebesar $10; dan
• biaya False Positive sebesar $5.

Hasil perbandingannya adalah:

1. Tidak ada nasabah yang dihubungi
   Business Loss: $7.460
2. Seluruh nasabah dihubungi
   Business Loss: $4.075
3. Menggunakan model
   Business Loss: $3.425

Berdasarkan asumsi tersebut, penggunaan model menghasilkan Business Loss paling rendah.

Model dapat menghemat $650 dibandingkan strategi menghubungi seluruh nasabah. Namun, model masih merekomendasikan sekitar 79,37% nasabah test untuk dihubungi karena optimasi difokuskan pada Recall.

Hasil ini menunjukkan bahwa model membantu menyaring target campaign, tetapi threshold prediksi masih dapat disesuaikan kembali berdasarkan biaya, kapasitas telemarketing, dan tujuan bisnis.

🔍 Feature Importance

Feature importance digunakan untuk melihat kontribusi relatif setiap fitur terhadap keputusan model.

Namun, feature importance perlu diinterpretasikan dengan hati-hati. Nilai yang tinggi tidak menunjukkan arah pengaruh dan tidak membuktikan hubungan sebab-akibat.

Analisis lanjutan seperti SHAP dapat digunakan apabila dibutuhkan penjelasan yang lebih detail mengenai bagaimana nilai suatu fitur meningkatkan atau menurunkan probabilitas prediksi.

[Sisipkan gambar feature importance]

🖥️ Model Deployment dengan Streamlit

Model final disimpan sebagai full pipeline dalam file best_model.sav.

Full pipeline berarti file tersebut sudah memuat preprocessing dan model XGBoost. Dengan demikian, aplikasi tidak perlu melakukan preprocessing ulang secara manual.

Model kemudian diterapkan ke aplikasi Streamlit dengan dua menu utama:

🎯 Prediksi Customer

Menu ini digunakan untuk:

• memprediksi satu customer;
• melakukan prediksi data CSV;
• menampilkan hasil klasifikasi;
• menampilkan probabilitas deposito; dan
• menentukan tingkat prioritas campaign.

📊 Riwayat & Analisis

Menu ini digunakan untuk:

• menyimpan riwayat prediksi selama sesi aktif;
• menampilkan KPI historis;
• membandingkan probabilitas antarcustomer;
• menampilkan komposisi hasil prediksi;
• menyusun ranking prioritas campaign;
• menghapus data tertentu; dan
• mengunduh riwayat dalam format CSV.

[Sisipkan gambar aplikasi Streamlit]

Deployment menjadi tahap penting karena model yang hanya tersimpan di notebook akan sulit digunakan oleh pengguna nonteknis.

Melalui Streamlit, proses prediksi dapat dilakukan melalui antarmuka sederhana tanpa perlu menjalankan kode Python secara langsung.

💡 Catatan Pembelajaran

Dari project ini saya kembali belajar bahwa pemilihan model tidak cukup hanya berdasarkan skor tertinggi.

Metrik evaluasi harus disesuaikan dengan tujuan bisnis. Recall yang tinggi memang membantu menemukan lebih banyak nasabah potensial, tetapi juga dapat meningkatkan jumlah nasabah yang tetap harus dihubungi.

Karena itu, hasil model perlu dievaluasi bersama dengan Business Loss, kapasitas campaign, dan threshold yang digunakan.

Model sebaiknya diposisikan sebagai alat prioritas, bukan keputusan otomatis.

Setelah deployment, performa model juga tetap perlu dimonitor karena karakteristik nasabah dan pola campaign dapat berubah dari waktu ke waktu.

Beberapa waktu terakhir saya mengerjakan project Revenue Leakage & Billing Control Tower Analysis.

Project ini menggunakan kasus fiktif dengan data dummy/simulasi untuk kebutuhan pembelajaran dan portfolio. Walaupun datanya bukan data riil perusahaan, struktur kasusnya dibuat menyerupai permasalahan yang cukup sering muncul dalam proses bisnis, yaitu bagaimana data dapat digunakan untuk membantu mendeteksi potensi revenue leakage, risiko tunggakan, kualitas data collection, anomali utilitas, hingga logical error pada sistem billing.

Dalam project ini, tujuan utamanya bukan hanya membuat dashboard yang menarik secara visual. Lebih dari itu, saya ingin membangun alur analisis yang utuh: mulai dari memahami masalah bisnis, menyiapkan data, melakukan proses ETL, menganalisis data, sampai menghasilkan dashboard yang bisa membantu proses monitoring dan pengambilan keputusan.

Bagi saya, project ini menjadi latihan yang cukup menarik karena proses analisis data ternyata tidak dimulai dari membuat grafik, tetapi dimulai dari memahami konteks masalah dan memastikan data yang digunakan memang layak untuk dianalisis.

1. Memahami Konteks Masalah

Tahap pertama dalam project ini adalah memahami masalah bisnis yang ingin dianalisis.

Dalam konteks estate atau township management, salah satu tantangan utama adalah pengelolaan billing secara berkala. Setiap unit memiliki tagihan yang perlu dibayar, seperti iuran pengelolaan lingkungan atau tagihan utilitas. Jika proses billing dan collection tidak berjalan dengan baik, maka perusahaan dapat mengalami keterlambatan penerimaan kas atau bahkan potensi kebocoran pendapatan.

Beberapa masalah utama yang ingin dianalisis dalam project ini antara lain:

• Invoice yang masih berstatus unpaid atau overdue
• Tunggakan yang sudah berumur lama
• Unit vacant yang tetap membebani biaya kawasan
• Nomor kontak pemilik yang tidak lengkap
• Metode pembayaran yang tidak konsisten
• Pemakaian air yang terlihat tidak wajar
• Anomali sistem seperti invoice paid sebelum tanggal handover

Dari sini, saya menyusun pertanyaan analisis utama:

1. Township mana yang memiliki risiko tunggakan tertinggi?
2. Berapa nilai outstanding berdasarkan umur tunggakan?
3. Apakah unit vacant lebih berisiko menunggak dibanding occupied?
4. Apakah missing contact menghambat proses collection?
5. Apakah terdapat data payment method yang tidak konsisten?
6. Apakah terdapat outlier pada pemakaian air?
7. Apakah terdapat logical error pada sistem billing?

Pertanyaan-pertanyaan ini kemudian menjadi dasar dalam menentukan proses pengolahan data, analisis, dan visualisasi dashboard.

2. Persiapan Data

Setelah memahami masalah, tahap berikutnya adalah memahami data yang tersedia.

Data yang digunakan dalam project ini terdiri dari beberapa tabel utama:

1. Data Cluster

Data ini berisi informasi terkait township dan cluster. Di dalamnya terdapat informasi seperti nama township, kategori cluster, dan identitas cluster.

Tabel ini penting karena digunakan untuk melihat perbandingan risiko antar area atau township.

2. Data Unit

Data unit berisi informasi properti individual, seperti unit ID, owner, contact number, vacant status, dan handover date.

Data ini penting untuk analisis vacant property risk, missing contact, dan validasi paid before handover.

3. Data Billing

Data billing berisi informasi invoice, billing date, water usage, total amount, payment status, payment method, dan payment date.

Tabel ini menjadi sumber utama untuk menganalisis tunggakan, aging schedule, payment method, water usage outlier, dan ERP logical error.

Secara sederhana, ketiga tabel tersebut belum bisa langsung memberikan insight jika berdiri sendiri. Karena itu, data perlu digabungkan terlebih dahulu agar membentuk satu dataset analitik yang utuh.

3. Proses ETL

Tahap paling penting sebelum analisis adalah ETL, yaitu Extract, Transform, dan Load.

ETL adalah proses mengambil data dari sumber, membersihkan dan membentuk data, lalu menyimpannya kembali dalam format yang siap digunakan untuk analisis maupun dashboard.

Proses ETL

Extract: Mengambil Data dari Sumber

Pada tahap Extract, data diambil dari beberapa tabel utama yang sudah disebutkan sebelumnya, yaitu data cluster, data unit, dan data billing.

Tujuan dari tahap ini adalah memastikan semua data yang dibutuhkan untuk menjawab pertanyaan bisnis sudah tersedia.

Contohnya, jika ingin menganalisis tunggakan berdasarkan township, maka data billing harus bisa terhubung dengan data unit dan data cluster. Jika ingin menganalisis paid before handover, maka payment date dari data billing harus bisa dibandingkan dengan handover date dari data unit.

Dengan kata lain, tahap Extract memastikan bahwa semua potongan puzzle data sudah tersedia.

Transform: Membersihkan dan Membentuk Data

Setelah data berhasil diambil, tahap berikutnya adalah Transform.

Menurut saya, tahap ini adalah bagian paling penting dalam project analisis data. Karena data mentah biasanya belum siap langsung digunakan. Ada banyak hal yang perlu dicek, dibersihkan, dan dibentuk ulang.

Beberapa proses transformasi yang saya lakukan antara lain:

1. Join Data

Data cluster, unit, dan billing digabungkan menjadi satu dataset utama.

Penggabungan ini dilakukan menggunakan key seperti cluster_id dan unit_id.

Dengan hasil join ini, setiap invoice tidak hanya memiliki informasi billing, tetapi juga informasi unit, township, status vacant, dan informasi pemilik.

2. Formatting Tanggal

Kolom tanggal seperti handover_date, billing_date, dan payment_date perlu dipastikan memiliki format date/datetime yang benar.

Ini penting karena beberapa analisis sangat bergantung pada tanggal, seperti aging schedule dan paid before handover anomaly.

Jika format tanggal tidak benar, maka hasil analisis bisa salah.

3. Handling Missing Value

Missing value dicek terutama pada kolom penting seperti contact number dan payment method.

Missing contact penting untuk analisis collection data quality, sedangkan payment method penting untuk proses rekonsiliasi channel pembayaran.

4. Payment Method Cleansing

Salah satu temuan data quality adalah metode pembayaran yang ditulis dengan beberapa variasi.

Contohnya:

• bca va
• VA BCA
• BCA Virtual Account

Ketiganya sebenarnya merujuk pada channel pembayaran yang sama, yaitu BCA Virtual Account. Jika tidak dibersihkan, maka analisis payment channel akan terpecah dan kurang akurat.

Karena itu, kategori payment method distandarisasi menjadi label yang lebih konsisten.

Hasilnya, kategori payment method yang sebelumnya lebih banyak dapat diringkas menjadi kategori standar yang lebih mudah dianalisis.

5. Membuat Status Tunggakan

Dalam project ini, invoice yang dianggap sebagai tunggakan adalah invoice dengan status:

• Unpaid
• Overdue

Dari kolom payment status, saya membuat flag atau status baru untuk membedakan invoice yang termasuk tunggakan dan tidak tunggakan.

Kolom ini kemudian digunakan untuk menghitung rasio tunggakan, outstanding amount, dan analisis collection risk.

6. Membuat Aging Bucket

Aging bucket digunakan untuk mengelompokkan tunggakan berdasarkan umur tagihan.

Contoh bucket yang digunakan:

• 0–1 bulan
• 2–3 bulan
• 4–6 bulan
• Lebih dari 6 bulan

Aging bucket ini sangat penting karena semakin lama tagihan tertunda, semakin tinggi risiko recovery-nya.

Dalam project ini, bucket lebih dari 6 bulan menjadi salah satu fokus utama karena memiliki outstanding amount terbesar.

7. Flagging Missing Contact

Untuk mendukung analisis collection data quality, saya membuat flag untuk membedakan unit dengan contact available dan missing contact.

Missing contact bukan berarti selalu menjadi penyebab tunggakan, tetapi tetap penting secara operasional karena tim collection akan lebih sulit melakukan follow-up kepada pemilik unit.

8. Deteksi Water Usage Outlier

Pada bagian utility billing, saya mendeteksi outlier pada pemakaian air.

Outlier ini dihitung menggunakan pendekatan IQR atau Interquartile Range. Nilai yang berada jauh di luar batas normal akan ditandai sebagai extreme outlier.

Tujuan dari analisis ini adalah untuk mendeteksi potensi salah input meteran, error pencatatan, atau potensi salah tagih utilitas.

9. Flagging Paid Before Handover

Salah satu analisis yang cukup penting adalah mendeteksi invoice yang berstatus Paid, tetapi payment date-nya lebih awal dari handover date.

Secara alur bisnis, kondisi ini terlihat tidak wajar. Karena itu, transaksi seperti ini ditandai sebagai anomali paid before handover.

Anomali ini bisa mengindikasikan beberapa kemungkinan, seperti bug sistem, salah mapping tanggal, backdated transaction, atau masalah migrasi data.

Load: Menyimpan Data Bersih

Setelah proses cleaning dan transformasi selesai, data final disimpan sebagai clean table.

Clean table ini kemudian digunakan sebagai sumber utama untuk dashboard.

Bagi saya, tahap Load ini penting karena dashboard sebaiknya tidak langsung membaca data mentah yang masih belum rapi. Dengan adanya clean table, dashboard menjadi lebih stabil, lebih cepat dibaca, dan lebih mudah dikembangkan.

Secara sederhana, output dari proses ETL ini adalah satu dataset analitik yang sudah siap digunakan untuk menjawab pertanyaan bisnis.

4. Analisis Data

Setelah data bersih tersedia, tahap berikutnya adalah analisis data.

Proses & Hasil Analisis Data

Dalam project ini, saya membagi analisis ke beberapa area utama.

Revenue Leakage Analysis

Analisis pertama adalah revenue leakage.

Revenue leakage dalam project ini didefinisikan sebagai potensi pendapatan yang belum tertagih karena invoice masih berstatus unpaid atau overdue.

Dari analisis ini, saya melihat rasio tunggakan antar township. Menariknya, rasio tunggakan antar township terlihat relatif mirip, yaitu berada di kisaran 28,5% sampai 29,9%.

Hal ini menunjukkan bahwa masalah collection tidak hanya terjadi di satu township tertentu, tetapi cenderung bersifat sistemik.

Artinya, strategi collection tidak cukup hanya difokuskan berdasarkan township dengan rasio tertinggi. Perlu dilihat juga dari sisi aging dan nilai outstanding.

Aging Schedule Analysis

Setelah melihat revenue leakage secara umum, analisis dilanjutkan ke aging schedule.

Aging schedule digunakan untuk melihat umur tunggakan.

Dari hasil analisis, outstanding terbesar berada pada kategori tunggakan lebih dari 6 bulan, dengan nilai sekitar Rp82,51 miliar.

Temuan ini penting karena tagihan yang sudah lama tertunda biasanya memiliki risiko recovery yang lebih tinggi.

Dari sisi prioritas, collection sebaiknya difokuskan pada aging lebih dari 6 bulan, terutama pada township yang menyumbang porsi terbesar dari total revenue tertunda.

Dalam project ini, tiga township utama menyumbang sekitar 82,7% dari total revenue tertunda lebih dari 6 bulan.

Vacant Property Risk Analysis

Analisis berikutnya adalah vacant property risk.

Unit vacant adalah unit yang kosong atau tidak dihuni. Walaupun unit tersebut tidak dihuni, kawasan tetap membutuhkan biaya operasional seperti keamanan, kebersihan, fasilitas umum, dan maintenance.

Dari hasil analisis, unit vacant memiliki rasio tunggakan yang jauh lebih tinggi dibanding occupied.

Rasio tunggakan unit vacant mencapai 59,7%, hampir tiga kali lebih tinggi dibanding occupied.

Untuk memperkuat insight ini, saya menggunakan Chi-Square Test. Hasilnya menunjukkan bahwa terdapat hubungan signifikan antara occupancy status dan status tunggakan.

Artinya, vacant status dapat digunakan sebagai salah satu indikator risiko dalam strategi collection.

Collection Data Quality Analysis

Setelah menganalisis vacant risk, saya masuk ke collection data quality.

Fokusnya adalah melihat apakah missing contact berhubungan dengan status tunggakan.

Dari hasil analisis, missing contact tidak terbukti signifikan secara statistik sebagai penyebab tunggakan. Proporsi tunggakan antara unit dengan contact available dan missing contact relatif mirip, sekitar 30%.

Namun, secara operasional, missing contact tetap menjadi masalah.

Mengapa?

Karena jika nomor kontak pemilik tidak tersedia, maka tim collection akan lebih sulit melakukan follow-up. Jadi, missing contact mungkin bukan penyebab utama tunggakan, tetapi tetap dapat menghambat proses collection.

Ini menjadi contoh bahwa hasil statistik dan konteks bisnis perlu dibaca bersama-sama.

Payment Method Cleansing

Bagian berikutnya adalah payment method cleansing.

Sebelum cleaning, beberapa metode pembayaran tercatat dalam format yang berbeda-beda, padahal merujuk ke channel yang sama.

Contohnya variasi BCA Virtual Account, Cash, Tokopedia, dan Credit Card.

Setelah proses cleaning, kategori payment method menjadi lebih ringkas dan konsisten.

Hal ini penting karena payment method yang tidak standar dapat mengganggu analisis channel pembayaran dan proses rekonsiliasi finance.

Namun, masih terdapat payment method yang kosong atau None. Ini perlu menjadi perhatian karena dapat mengindikasikan masih adanya gap dalam pencatatan channel pembayaran.

Water Usage Outlier Analysis

Selanjutnya adalah analisis water usage outlier.

Tujuannya adalah mendeteksi pemakaian air yang tidak wajar.

Outlier pemakaian air perlu divalidasi karena bisa menimbulkan salah tagih utilitas. Meskipun secara persentase jumlah extreme outlier relatif rendah, yaitu kurang dari 1%, tetap perlu dilakukan validasi.

Dalam project ini, outlier tertinggi ditemukan pada kategori tertentu dengan nilai sekitar 0,65%.

Insight penting dari analisis ini adalah bahwa water usage outlier lebih tepat diperlakukan sebagai risiko akurasi billing, bukan sebagai penyebab utama tunggakan.

ERP Logical Error Analysis

Salah satu bagian paling menarik dalam project ini adalah analisis ERP logical error.

Saya mendeteksi invoice dengan status Paid, tetapi payment date lebih awal daripada handover date.

Secara alur bisnis, kondisi ini tidak normal. Pembayaran seharusnya terjadi setelah unit aktif atau setelah invoice terbentuk sesuai alur billing.

Dari hasil analisis, ditemukan 6.291 invoice anomali paid before handover dengan nilai sekitar Rp8,35 miliar.

Selain itu, sekitar 82,9% invoice anomali terkonsentrasi pada tiga township utama.

Temuan ini menunjukkan bahwa audit sistem bisa dilakukan lebih terarah, tidak harus langsung menyisir semua area secara merata.

Rekomendasi utamanya adalah menambahkan validation rule pada sistem agar payment date tidak boleh lebih awal dari handover date.

5. Dashboard Looker Studio

Setelah semua analisis dilakukan, hasilnya divisualisasikan ke dalam dashboard Looker Studio.

Dashboard ini dibuat sebagai bentuk billing control tower, yaitu tampilan monitoring yang membantu melihat kondisi billing dan collection secara lebih terpusat.

Tampilan Dashboard

Beberapa halaman dashboard yang dibuat antara lain:

1. Executive Overview

Halaman ini berisi ringkasan KPI utama, seperti total billing, outstanding amount, paid, unpaid, overdue, dan indikator risiko utama lainnya.

2. Collection & Aging

Halaman ini digunakan untuk memantau aging tunggakan dan menentukan prioritas collection berdasarkan umur tagihan serta nilai outstanding.

3. Vacant Property Risk

Halaman ini digunakan untuk memantau risiko tunggakan pada unit vacant dan membandingkannya dengan unit occupied.

4. Water & Utility

Halaman ini digunakan untuk memantau pemakaian air dan mendeteksi outlier yang berpotensi menyebabkan salah tagih utilitas.

5. Data Quality Monitoring

Halaman ini digunakan untuk memantau missing contact, payment method cleansing, dan ERP logical error.

Dengan dashboard ini, insight yang sebelumnya hanya ada di notebook dapat digunakan secara lebih praktis untuk monitoring.

6. Kesimpulan

Dari project ini, ada beberapa insight utama yang saya dapatkan.

Key Visual

Pertama, risiko revenue terbesar tidak hanya berasal dari rasio tunggakan, tetapi terutama dari aging tunggakan yang sudah lebih dari 6 bulan.

Kedua, unit vacant memiliki risiko tunggakan yang jauh lebih tinggi dibanding occupied, sehingga perlu menjadi segment khusus dalam strategi collection.

Ketiga, missing contact tidak terbukti signifikan sebagai penyebab tunggakan, tetapi tetap menjadi hambatan operasional dalam proses follow-up.

Keempat, outlier pemakaian air relatif rendah, tetapi tetap perlu divalidasi untuk mencegah salah tagih utilitas.

Kelima, ERP logical error berupa paid before handover perlu menjadi prioritas audit karena melibatkan nilai transaksi yang cukup besar.

7. Rekomendasi

Berdasarkan hasil analisis, beberapa rekomendasi yang dapat dilakukan antara lain:

1. Menerapkan risk-based collection berdasarkan aging, nilai outstanding, vacant status, dan contact availability.
2. Memprioritaskan collection pada aging lebih dari 6 bulan.
3. Membuat segment khusus untuk unit vacant yang memiliki status unpaid atau overdue.
4. Melakukan cleansing contact number secara berkala.
5. Menstandarisasi payment method untuk mendukung rekonsiliasi finance.
6. Memvalidasi water usage outlier sebelum invoice diterbitkan.
7. Menambahkan validation rule pada ERP agar payment date tidak lebih awal dari handover date.
8. Menggunakan dashboard sebagai alat monitoring billing control secara berkala.

Penutup

Dari project ini saya belajar bahwa proses analisis data tidak hanya berhenti di membuat grafik atau dashboard.

Bagian paling penting justru ada pada bagaimana kita memahami konteks bisnis, membersihkan data, membuat fitur yang relevan, menganalisis pola, dan menerjemahkan hasilnya menjadi rekomendasi yang bisa ditindaklanjuti.

Dashboard yang bagus bukan hanya yang terlihat menarik, tetapi yang mampu membantu menjawab pertanyaan bisnis dengan lebih jelas.

Karena pada akhirnya, data analysis bukan hanya tentang angka, tetapi tentang bagaimana angka tersebut bisa membantu proses pengambilan keputusan.

Link Terkait

• Github : File Analisis
• Dashboard : Looker Studio

Catatan

Project ini menggunakan kasus fiktif dan data dummy/simulasi untuk kebutuhan pembelajaran dan portfolio.

Belajar Python akan terasa lebih menarik jika langsung diterapkan pada studi kasus nyata. Salah satu contoh sederhana yang saya buat adalah Aplikasi Python: Kalkulator Panen Udang.

Aplikasi ini dibuat sebagai latihan dasar Python dengan pendekatan studi kasus panen udang. Walaupun masih berbasis terminal atau command line, aplikasi ini sudah mencakup beberapa konsep penting dalam pemrograman, seperti penggunaan dictionary, function, perulangan, percabangan, input user, serta proses CRUD sederhana.

Aplikasi Python Sederhana: Kalkulator Panen Udang

Latar Belakang

Dalam kegiatan budidaya udang, data panen menjadi salah satu informasi penting untuk mengevaluasi hasil produksi. Beberapa data yang umum dicatat antara lain umur panen atau DOC, size udang, biomass panen, harga jual, biaya produksi, hingga keuntungan atau kerugian.

Dari kebutuhan sederhana tersebut, saya mencoba membuat aplikasi kalkulator panen menggunakan Python. Tujuannya bukan untuk membuat sistem yang kompleks, tetapi sebagai latihan bagaimana Python dapat digunakan untuk membantu perhitungan sederhana berbasis data.

Fitur Aplikasi

Aplikasi Kalkulator Panen Udang ini memiliki beberapa fitur utama, yaitu:

• Menampilkan seluruh data panen
• Menampilkan data panen tertentu
• Menambahkan data panen baru
• Mengubah data panen
• Menghapus data panen
• Menghitung total biomass
• Menghitung total income
• Menghitung biaya produksi
• Menghitung profit/loss
• Menghitung ROI

Konsep Python yang Digunakan

Dari project sederhana ini, ada beberapa konsep dasar Python yang bisa dipelajari, antara lain:

• Dictionary untuk menyimpan data panen
• Function untuk memecah program menjadi beberapa bagian
• While loop untuk membuat menu berjalan terus sampai user memilih keluar
• If else untuk menjalankan pilihan menu
• Input user untuk memasukkan data secara interaktif
• CRUD sederhana untuk tambah, tampilkan, ubah, dan hapus data

Contoh Struktur Data

Data panen disimpan dalam bentuk dictionary. Setiap panen memiliki beberapa informasi seperti DOC, Size, Biomass, dan Harga.

dataPanen = {
    "Panen1": {"DOC": 60, "Size": 93, "Biomass": 200, "Harga": 72500},
    "Panen2": {"DOC": 70, "Size": 77, "Biomass": 200, "Harga": 90000},
    "Panen3": {"DOC": 80, "Size": 68, "Biomass": 200, "Harga": 100000},
    "Panen4": {"DOC": 90, "Size": 61, "Biomass": 200, "Harga": 110000}
}

Dengan struktur seperti ini, data lebih mudah diakses dan diproses menggunakan fungsi Python.

Contoh Menu Aplikasi

Aplikasi ini menggunakan menu utama agar user dapat memilih fitur yang ingin dijalankan.

============== APLIKASI PANEN UDANG ==============

1. Report Data Panen
2. Menambah Data Panen
3. Mengubah Data Panen
4. Menghapus Data Panen
5. Menghitung Keuntungan Panen
6. Exit Program

Menu tersebut dibuat agar aplikasi lebih mudah digunakan. User cukup memilih angka sesuai menu yang ingin dijalankan.

Perhitungan Keuntungan

Salah satu bagian penting dari aplikasi ini adalah perhitungan keuntungan panen. Beberapa komponen yang dihitung antara lain:

• Total biomass
• Total pakan berdasarkan nilai FCR
• Total biaya pakan
• Biaya listrik
• Biaya gaji karyawan
• Biaya bahan kimia
• Biaya lainnya
• Total income
• Total cost
• Profit atau loss
• ROI

Rumus sederhana yang digunakan:

profitLoss = totalIncome - totalCost
roi = (profitLoss / totalCost) * 100

Dari rumus tersebut, aplikasi dapat memberikan informasi apakah panen berada dalam kondisi untung, rugi, atau impas.

Kenapa Project Ini Menarik?

Menurut saya, project ini menarik karena menghubungkan pembelajaran Python dengan studi kasus yang dekat dengan dunia aquaculture. Belajar coding tidak harus selalu menggunakan contoh yang terlalu umum. Justru dengan studi kasus yang dekat dengan pekerjaan atau kebutuhan sehari-hari, proses belajar menjadi lebih mudah dipahami.

Project ini juga menunjukkan bahwa aplikasi sederhana bisa menjadi langkah awal untuk pengembangan yang lebih kompleks. Ke depan, konsep seperti ini bisa dikembangkan menjadi aplikasi berbasis web menggunakan Streamlit, ditambahkan grafik, export data ke Excel, atau bahkan dikombinasikan dengan analisis data.

Pengembangan Selanjutnya

Beberapa ide pengembangan yang bisa dilakukan dari aplikasi ini antara lain:

• Menyimpan data panen ke file Excel atau CSV
• Membuat tampilan web menggunakan Streamlit
• Menambahkan grafik biomass dan profit
• Menambahkan simulasi harga jual
• Menambahkan analisis BEP
• Menambahkan database sederhana
• Membuat dashboard interaktif

Repository GitHub

Script lengkap aplikasi ini dapat dilihat melalui repository GitHub berikut:

https://github.com/ashamzah/Kalkulator-Panen-Udang

Penutup

Project Kalkulator Panen Udang ini merupakan contoh sederhana bagaimana Python dapat digunakan untuk membantu perhitungan berbasis data. Meskipun aplikasinya masih sederhana, konsep yang dipelajari cukup penting sebagai dasar untuk membuat aplikasi yang lebih besar.

Bagi saya, belajar Python paling efektif adalah dengan membuat project kecil yang dekat dengan kebutuhan nyata. Dari project seperti ini, kita tidak hanya belajar syntax, tetapi juga belajar bagaimana menyusun logika program untuk menyelesaikan masalah.

Semoga artikel ini bermanfaat bagi teman-teman yang sedang belajar Python, khususnya yang tertarik dengan data, aquaculture, dan aplikasi sederhana berbasis studi kasus nyata.

Tag: Python, Belajar Python, Aplikasi Python, Kalkulator Panen Udang, Budidaya Udang, Aquaculture, Data Analysis, Python Pemula