Bisnis Punya Banyak Data, tapi Sedikit Insight: Mengapa Data Hygiene Menjadi Fondasi AI dan Dashboard

Sebuah bisnis dapat memiliki POS.

Marketplace.

QRIS.

Website analytics.

CRM.

Accounting software.

Inventory system.

Spreadsheet finance.

WhatsApp order.

Dan tetap tidak tahu dengan pasti berapa pelanggan aktifnya.

Ini bukan masalah kekurangan data.

Ini adalah masalah data hygiene.

Satu customer memiliki tiga nama.

Satu produk memiliki lima SKU.

Order yang sudah refund masih dihitung sebagai revenue.

Transaksi yang sama masuk dua kali.

Marketplace mencatat tanggal order, finance menggunakan tanggal settlement.

Tim marketing mengatakan conversion naik.

Finance mengatakan revenue turun.

Dashboard terlihat rapi.

Sumber datanya belum tentu demikian.

Banyak data tidak sama dengan data yang baik

Bisnis modern menghasilkan data di hampir setiap aktivitas.

Masalah muncul ketika setiap sistem menggunakan definisi berbeda.

POS mengenali pelanggan dari nomor telepon.

CRM dari email.

Marketplace dari marketplace ID.

Accounting hanya mengenal invoice.

Akhirnya satu orang terlihat seperti empat customer.

Hal yang sama terjadi pada produk.

“Latte Regular”.

“Latte Reg”.

“LAT-R”.

“Coffee Milk R”.

Bagi manusia di toko, semua mungkin jelas.

Bagi sistem, mereka berbeda.

Ketika data seperti ini masuk ke dashboard, teknologi hanya memvisualisasikan inkonsistensi.

Ketika masuk ke AI, masalahnya bisa menjadi lebih besar karena AI akan menggunakan data tersebut sebagai dasar analisis atau tindakan.

NIST menempatkan kualitas data sebagai bagian dari AI risk

NIST AI Risk Management Framework menekankan perlunya memahami bagaimana data dikumpulkan dan dipilih, termasuk availability, representativeness, dan suitability.[1]

Panduan pengukuran NIST juga secara eksplisit mencatat bahwa sistem AI memiliki ketergantungan pada data dan metode yang secara langsung berkaitan dengan data quality dan representativeness.[2]

Ini berarti kualitas data bukan persoalan “housekeeping IT”.

Ia merupakan bagian dari risk management.

Jika input salah, keputusan yang terlihat canggih tetap dapat salah.

Dashboard memiliki masalah yang sama

Masalah kualitas data bahkan muncul jauh sebelum AI.

Bayangkan revenue dashboard menghitung dua transaksi identik.

Atau refund tidak dikurangkan.

Atau cancelled order tetap dianggap penjualan.

Atau satu transaksi marketplace masuk dari API dan spreadsheet sekaligus.

Jumlah chart bisa bertambah.

Akurasi tidak.

Google Analytics, misalnya, menggunakan transaction ID unik untuk menghindari duplicate purchase dan membantu merekonsiliasi refund.[3]

Ini bukan aturan universal untuk semua sistem.

Tetapi prinsipnya sangat kuat:

setiap transaksi membutuhkan identitas yang dapat dilacak.

Data hygiene dimulai dari ID

Sebuah organisasi sebaiknya memiliki minimum unique identifiers.

Transaction ID untuk setiap order.

Customer ID bila business model membutuhkan customer-level analysis.

Product atau SKU ID.

Supplier ID.

Invoice ID.

ID harus konsisten antar-sistem.

Nama boleh berubah.

Deskripsi boleh diperbaiki.

ID idealnya tidak.

Tanpa itu, reconciliation menjadi bergantung pada nama dan tebakan.

Jangan pakai data pribadi sebagai transaction ID

Hal ini juga penting dari sisi privacy.

Google Analytics secara eksplisit menyarankan transaction ID tidak berisi informasi yang dapat mengidentifikasi customer secara individual.[3]

Praktiknya masuk akal lebih luas.

Jangan menjadikan:

nama lengkap;

NIK;

nomor telepon;

email;

sebagai ID transaksi jika tidak perlu.

Gunakan identifier teknis yang tidak membawa lebih banyak data pribadi daripada yang dibutuhkan.

Definisikan status transaksi

Banyak dashboard gagal bukan karena transaksi hilang, tetapi karena statusnya tidak jelas.

Apakah order:

created?

paid?

processing?

shipped?

completed?

cancelled?

refunded?

partial refund?

Revenue sebaiknya tidak dihitung hanya karena order pernah dibuat.

Setiap bisnis harus menentukan revenue recognition logic sesuai kebutuhan akuntansi dan operasionalnya.

Untuk dashboard operasional, yang penting adalah definisi konsisten.

Apa yang disebut “sales”?

Apa yang disebut “order”?

Apa yang disebut “completed transaction”?

Refund bukan detail kecil

Refund dapat mengubah revenue, product performance, customer behaviour, bahkan marketing attribution.

Jika sistem penjualan mencatat Rp100 juta tetapi refund Rp10 juta tidak masuk ke dashboard, keputusan dibuat berdasarkan revenue yang terlalu tinggi.

Karena itu refund harus memiliki link ke transaction ID asal.

Bukan sekadar entry negatif tanpa konteks.

Master product data sering menjadi sumber kekacauan

Satu produk dapat ditulis berbeda di marketplace, POS dan inventory.

Solusinya adalah master product table.

Minimal berisi:

product ID;

nama resmi;

kategori;

variant;

unit;

status aktif/nonaktif.

Channel dapat menggunakan nama display berbeda.

Tetapi semuanya dipetakan ke product ID yang sama.

Ini terdengar administratif.

Justru dari sinilah product-mix analysis menjadi mungkin.

Customer master lebih rumit

Customer identity jauh lebih sensitif.

Tidak semua bisnis membutuhkan customer master lengkap.

Toko dengan banyak anonymous walk-in mungkin tidak perlu memaksa setiap pembeli mendaftar.

Tetapi bisnis dengan loyalty, CRM, subscription, B2B, atau repeat purchase membutuhkan metode untuk menghubungkan aktivitas pelanggan secara konsisten.

Di sini prinsip data minimization menjadi penting.

Kumpulkan hanya data yang relevan terhadap tujuan.

UU PDP juga menuntut akurasi

Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi tidak hanya bicara keamanan.

Pasal 29 mengharuskan Pengendali Data Pribadi memastikan akurasi, kelengkapan, dan konsistensi data pribadi serta melakukan verifikasi.[4]

Prinsip pemrosesan juga mencakup data yang akurat, lengkap, tidak menyesatkan, mutakhir, serta dapat dipertanggungjawabkan.[4]

Artinya, customer-data hygiene bukan hanya masalah analytics.

Dalam konteks data pribadi, ia juga memiliki dimensi legal dan governance.

Data ownership perlu jelas

Salah satu pertanyaan terpenting sering tidak memiliki jawaban:

Siapa pemilik data customer?

Marketing?

Sales?

IT?

Operations?

Finance?

Jawaban yang lebih sehat adalah memisahkan antara ownership bisnis dan stewardship operasional.

Business owner menentukan definisi dan penggunaan.

Data steward memastikan kualitas.

IT mengelola sistem dan akses.

Security mengelola protection.

Legal/privacy memastikan penggunaan sah.

Tanpa role jelas, semua orang dapat mengubah data dan tidak ada yang bertanggung jawab atas kualitasnya.

Satu metric harus punya satu definisi

Ambil contoh “active customer”.

Marketing mendefinisikan customer yang membuka aplikasi.

Sales: customer yang membeli.

Finance: customer yang memiliki invoice.

Customer success: customer yang masih dalam kontrak.

Semua definisi bisa benar dalam konteks masing-masing.

Masalah muncul ketika dashboard hanya menampilkan “active customers” tanpa menjelaskan definisinya.

Setiap metric penting membutuhkan:

nama;

definisi;

formula;

data source;

owner;

refresh cadence.

Ini adalah metric dictionary.

Tanpanya, meeting berubah menjadi debat definisi.

Lineage menjawab: angka ini datang dari mana?

Data lineage adalah kemampuan menelusuri perjalanan data.

Misalnya:

POS → transaction database → data warehouse → transformation → dashboard.

Ketika revenue dashboard berubah tiba-tiba, tim dapat mencari titik masalah.

Apakah source berubah?

Mapping gagal?

Timezone berubah?

Refund tidak terbawa?

Tanpa lineage, orang hanya melihat angka akhir.

NIST juga mendorong dokumentasi data provenance—sumber, origin, transformasi, dependency, dan metadata—dalam praktik AI governance.[5]

Timezone terdengar sepele sampai revenue pindah hari

Bisnis Indonesia perlu memperhatikan timezone.

Marketplace mungkin menyimpan UTC.

POS menggunakan WIB.

Cloud database mengikuti default server.

Order pukul 00.30 WIB bisa dianggap transaksi hari sebelumnya jika conversion tidak konsisten.

Bagi dashboard harian, perbedaan kecil ini dapat mengubah:

daily sales;

campaign attribution;

delivery SLA;

peak-hour analysis.

Tetapkan satu canonical timestamp dan aturan konversi.

Missing data harus dianggap sebagai informasi

Field kosong tidak selalu berarti nol.

Stock kosong dapat berarti inventory habis.

Atau data belum diinput.

Customer age kosong bukan berarti customer berusia nol tahun.

Saat AI atau dashboard melihat missing value, interpretasinya harus jelas.

Gunakan status seperti:

unknown;

not applicable;

not collected;

pending.

Lebih baik daripada mengisi data palsu hanya agar tabel terlihat lengkap.

AI tidak membersihkan definisi bisnis secara ajaib

AI dapat membantu mendeteksi duplicate.

Membantu matching.

Mendeteksi anomaly.

Mengklasifikasi.

Tetapi AI tidak tahu secara otomatis bahwa:

“Produk A Reg” dan “Produk A Regular” memang produk yang sama.

Itu membutuhkan business rule.

AI juga tidak tahu apakah customer dari dua email berbeda adalah satu orang yang sama tanpa evidence yang cukup.

Automation dapat membantu.

Governance tetap membutuhkan manusia.

Jangan mulai dari data lake

Beberapa bisnis melihat masalah data lalu langsung berpikir tentang teknologi besar.

Data warehouse.

Lakehouse.

AI platform.

Master-data-management suite.

Semua bisa berguna.

Tetapi untuk banyak UMKM atau perusahaan menengah, langkah awal jauh lebih sederhana:

satu chart of accounts yang konsisten;

satu SKU master;

satu transaction ID;

satu customer identifier bila dibutuhkan;

satu channel taxonomy;

satu refund logic.

Fondasinya adalah definisi.

Bukan platform.

Audit lima jenis error

Bisnis dapat mulai dengan audit sederhana.

Duplicate

Apakah order/customer/product tercatat lebih dari sekali?

Missing

Apakah field penting sering kosong?

Inconsistent

Apakah category/channel/status menggunakan banyak format?

Invalid

Apakah tanggal, nominal, atau kode berada di luar rule?

Stale

Apakah data sudah terlalu lama untuk dipakai?

Dari sini buat data-quality score sederhana.

Tidak perlu sempurna.

Yang penting masalah terlihat.

Dashboard sebaiknya menunjukkan kualitas datanya sendiri

Ini sering dilupakan.

Dashboard dapat memiliki indicator seperti:

last refresh;

data completeness;

unmatched transactions;

failed imports;

unknown products;

reconciliation difference.

Jadi pengguna tidak hanya melihat revenue.

Mereka tahu seberapa dapat dipercaya revenue tersebut.

AI membutuhkan source hierarchy

Ketika perusahaan menggunakan AI internal, tentukan sumber mana yang authoritative.

Contoh:

Harga produk → ERP.

Status order → OMS.

Invoice → accounting.

Customer consent → CRM/privacy system.

Policy internal → document repository resmi.

Jika AI menemukan dua angka berbeda, source hierarchy membantu menentukan mana yang diutamakan.

Tanpa itu, AI hanya menerima konflik.

Data hygiene bukan proyek sekali selesai

Produk berubah.

Channel baru masuk.

Karyawan baru menggunakan spreadsheet baru.

Supplier berganti.

Integration diperbarui.

Karena itu, data hygiene harus memiliki cadence.

Mingguan untuk reconciliation.

Bulanan untuk master data.

Quarterly untuk access review.

Periodik untuk metric definition dan data retention.

NIST sendiri memandang AI risk management sebagai proses berkelanjutan sepanjang lifecycle.[1]

Prinsip yang sama berlaku pada data.

Delapan fondasi minimum

Sebelum bisnis membangun AI atau dashboard besar, pastikan ada:

1. unique transaction ID;

1. master product/SKU;

1. definisi customer yang jelas;

1. standard transaction status;

1. refund/cancellation logic;

1. channel taxonomy;

1. metric dictionary;

1. data owner dan access rule.

Jika delapan ini belum rapi, proyek analytics sebaiknya memperbaiki fondasi terlebih dahulu.

Dashboard bukan tempat memperbaiki data

Ini prinsip yang paling penting.

Dashboard adalah output layer.

Jika sistem upstream berantakan, dashboard hanya membuat kekacauan terlihat lebih cantik.

AI lebih jauh lagi.

Ia dapat mengubah data buruk menjadi rekomendasi yang terdengar meyakinkan.

Karena itu, pertanyaan perusahaan seharusnya bukan:

“AI apa yang perlu kita beli?”

atau:

“Dashboard apa yang paling keren?”

Tetapi:

“Apakah data yang kita berikan cukup konsisten, dapat ditelusuri, dan dipercaya untuk menjadi dasar keputusan?”

Bisnis tidak kekurangan data.

Yang langka adalah data yang cukup rapi untuk dipercaya.

Dan di era AI, kualitas itu menjadi semakin berharga.