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

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

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

Catatan

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