CRISP-DM: Kerangka Kerja Proyek Data yang Masih Relevan
Blog/Tips & Trik/CRISP-DM: Kerangka Kerja Proyek Data yang Masih Relevan

CRISP-DM: Kerangka Kerja Proyek Data yang Masih Relevan

BimaBima
·7 Juni 2026·8 menit baca

Penulis

Bima

Bima

Founder & Data Professional

Bagikan

TL;DR

CRISP-DM adalah kerangka kerja enam tahap buat ngerjain proyek data: pahami bisnis, pahami data, siapkan data, modeling, evaluasi, dan deployment. Sifatnya melingkar, jadi kamu boleh balik ke tahap sebelumnya kapan pun temuan baru muncul. Kerangka ini tetap dipakai karena masalah terbesar proyek data bukan algoritmanya, tapi salah paham soal pertanyaan bisnis yang mau dijawab.

CRISP-DM adalah kerangka kerja enam tahap buat ngerjain proyek data, dari mahami pertanyaan bisnis sampai hasilnya kepakai di lapangan.

Dibikin tahun 1996. Umurnya udah 30 tahun. Dan masih dipakai.

Kenapa? Karena masalah terbesar proyek data bukan algoritmanya. Masalah terbesarnya: kamu ngerjain tiga minggu, hasilnya bagus, terus manajer bilang "lho, yang aku tanya bukan ini."

CRISP-DM ngasih urutan yang bikin kejadian itu lebih jarang.

Apa itu CRISP-DM?

CRISP-DM (Cross Industry Standard Process for Data Mining) adalah proses standar buat proyek data yang terdiri dari enam tahap berurutan tapi bisa balik-balik. Dia dirancang biar bisa dipakai di industri apa pun, dan gak terikat ke tool tertentu.

Enam tahapnya:

  1. Business Understanding — pertanyaan bisnisnya apa, sukses itu kayak gimana
  2. Data Understanding — datanya ada apa aja, kualitasnya gimana
  3. Data Preparation — bersihin, gabungin, bikin fitur
  4. Modeling — bikin model atau analisisnya
  5. Evaluation — hasilnya jawab pertanyaan bisnisnya gak
  6. Deployment — taruh hasilnya di tempat yang bisa dipakai orang

Panah antar tahapnya dua arah. Kamu boleh, dan bakal, balik ke tahap sebelumnya. Nemu data kotor di tahap 3? Balik ke tahap 2. Model bagus tapi gak jawab pertanyaan? Balik ke tahap 1.

Dokumen aslinya masih bisa kamu baca gratis di dokumentasi IBM SPSS Modeler.

Kenapa tahap 1 dan 2 paling sering dilewatin?

Karena dua tahap itu gak kelihatan kayak "kerja."

Ngobrol sama manajer selama 40 menit buat mastiin pertanyaannya apa itu gak kelihatan produktif. Ngoding kelihatan produktif. Jadi orang loncat langsung ke tahap 3 dan 4.

Hasilnya kelihatan sibuk, tapi jawabannya sering meleset.

Contoh yang sering aku temui. Manajer bilang: "Aku mau tau produk mana yang paling laku." Kedengarannya jelas, kan?

Padahal "paling laku" itu bisa berarti tiga hal berbeda:

  • Paling banyak unit terjual (qty tertinggi)
  • Paling besar omzet (rupiah tertinggi)
  • Paling untung (margin tertinggi)

Tiga definisi itu sering ngasih jawaban yang beda banget. Di toko kelontong, produk qty tertinggi biasanya rokok atau mie instan. Produk margin tertinggi biasanya barang yang jarang laku tapi mahal.

Kalau manajer sebenernya lagi mikirin ruang rak, dia butuh angka margin per meter rak — bukan qty. Salah pilih definisi di menit pertama = tiga minggu terbuang.

Business Understanding itu satu pertanyaan yang harus kamu tanyain: keputusan apa yang bakal kamu ambil setelah lihat angka ini?

Kalau jawabannya "gak ada, cuma pengin tau" — turunin prioritasnya.

Gimana bentuk enam tahap ini di proyek beneran?

Aku pakai contoh proyek dataset toko_berkah: 8.400 transaksi kelontong Bandung selama 12 minggu. Pertanyaan awalnya dari pemilik: "Kenapa omzet Juni turun dibanding Mei?"

Tahap 1: Business Understanding

Pertanyaan awal itu belum bisa dikerjain. Aku tanya balik: turun berapa persen, dan keputusan apa yang mau diambil?

Ternyata omzet turun 12%, dan si pemilik lagi mempertimbangkan mecat satu kasir buat hemat biaya. Nah, itu keputusan yang jelas. Kriteria suksesnya jadi: tau penyebab turunnya, dan tau apakah masalahnya ada di jumlah orang atau di hal lain.

Tahap 2: Data Understanding

Aku cek dulu apa yang ada. Tabelnya punya tanggal, produk, qty, total_belanja, kasir. Yang gak ada: data cuaca, data promo, dan data toko kompetitor.

Ini penting dicatat di awal. Kalau penyebabnya ternyata kompetitor baru buka di seberang, dataku gak akan pernah bisa bilang gitu.

Query pertama yang aku jalanin selalu profil dasar:

SELECT
    DATE_TRUNC('month', tanggal)      AS bulan,
    COUNT(*)                          AS jumlah_transaksi,
    COUNT(DISTINCT tanggal)           AS hari_buka,
    SUM(total_belanja)                AS omzet,
    ROUND(AVG(total_belanja))         AS rata_per_struk
FROM toko_berkah
GROUP BY 1
ORDER BY 1;

Hasilnya bikin arah proyeknya berubah total.

Tahap 3: Data Preparation

Ada 214 baris dengan total_belanja kosong dan 6 baris dengan qty negatif (ternyata itu retur, bukan error). Aku pisahin retur ke tabel sendiri, dan isi nilai kosong pakai qty * harga_satuan.

Tahap ini makan 4 jam dari total 7 jam proyek. Ini normal — dan sering bikin orang kaget.

Tahap 4: Modeling

Gak ada machine learning di sini. "Modeling" buat proyek ini cuma perbandingan agregat per bulan, dipecah per dimensi: per hari, per kategori produk, per kasir.

Modeling gak selalu berarti ML. Kadang cuma GROUP BY yang tepat. Kalau kamu butuh refresher, DATE_TRUNC dan COUNT udah cukup buat 80% analisis kayak gini.

Tahap 5: Evaluation

Temuannya: omzet Juni turun 12%, tapi jumlah transaksi cuma turun 2%. Yang anjlok itu rata-rata belanja per struk — dari Rp 58.400 di Mei jadi Rp 51.145 di Juni.

Terus pas dipecah per kategori: penjualan kategori "kebutuhan bulanan" (beras, minyak, gula) turun 31%, sementara kategori lain stabil.

Juni itu bulan setelah Lebaran. Orang udah borongan di Mei. Ini pola musiman, bukan masalah performa toko.

Kesimpulannya buat si pemilik: mecat kasir gak akan nyelesain apa-apa, karena jumlah orang yang dateng gak turun. Yang turun itu ukuran belanjanya, dan itu bakal balik normal Juli.

Tahap 6: Deployment

Deployment buat proyek kecil bukan berarti bikin API. Bentuknya di sini: satu spreadsheet yang dia buka tiap awal bulan, isinya perbandingan omzet dan rata-rata struk bulan ini vs bulan lalu vs bulan yang sama tahun lalu.

Deployment artinya hasilnya dipakai berulang tanpa kamu. Kalau tiap bulan dia harus telepon kamu buat nanya lagi, proyekmu belum selesai.

Kesalahan umum waktu pakai CRISP-DM

Ngerjain berurutan tanpa balik. Diagramnya melingkar bukan buat gaya-gayaan. Kalau di tahap 3 kamu nemu data yang bikin asumsi tahap 1 salah, balik. Jangan maju terus cuma karena udah kadung.

Bikin dokumen tebal buat proyek kecil. CRISP-DM aslinya punya template dokumentasi yang panjang. Buat analisis sehari, itu overkill. Ambil urutan berpikirnya, buang formalitasnya.

Nganggep Evaluation = ngecek akurasi model. Bukan. Evaluation itu ngecek apakah hasilnya jawab pertanyaan bisnis di tahap 1. Model dengan akurasi 94% yang gak ngebantu keputusan apa pun itu tetap proyek gagal.

Lupa deployment. Analisis yang berhenti di notebook Jupyter dan gak pernah dilihat orang lain itu latihan, bukan proyek.

Gak nyatet apa yang gak ada di data. Batasan data itu bagian dari hasil. Bilang terus terang: "aku gak bisa jawab soal kompetitor, karena datanya gak ada."

FAQ

CRISP-DM itu singkatan dari apa?

CRISP-DM singkatan dari Cross Industry Standard Process for Data Mining. Dibikin tahun 1996 oleh konsorsium yang isinya Daimler, SPSS, dan NCR, terus dirilis sebagai standar terbuka. Namanya panjang dan agak kaku, tapi isinya sederhana: enam tahap buat ngerjain proyek data dari awal sampai hasilnya kepakai.

CRISP-DM masih relevan di era machine learning modern?

Masih, karena yang dia atur itu alur berpikir, bukan tool. Tahap modeling sekarang mungkin pakai library yang beda, tapi urutan pahami bisnis lalu pahami data lalu siapkan data tetap sama. Yang perlu ditambahin buat proyek modern: monitoring model setelah deploy, dan versioning data. CRISP-DM aslinya gak bahas dua hal itu secara detail.

Bedanya CRISP-DM sama KDD atau SEMMA apa?

KDD lebih akademis dan fokus ke penemuan pola. SEMMA dibikin SAS dan lebih terikat ke tool mereka, plus dia mulai dari sampling data langsung tanpa tahap pahami bisnis. CRISP-DM lebih luas karena dia mulai dari pertanyaan bisnis dan berakhir di deployment. Itu sebabnya CRISP-DM lebih sering dipakai di dunia kerja.

Tahap mana yang paling makan waktu?

Data preparation. Di proyek yang aku kerjain, tahap ini biasanya makan 50 sampai 70 persen total waktu. Bersihin nilai kosong, samain format tanggal, gabungin tabel dari sistem yang beda, dan nyocokin definisi metrik antar departemen. Modeling sendiri sering cuma butuh beberapa jam kalau datanya udah rapi.

Apa proyek data kecil juga perlu CRISP-DM?

Perlu, tapi versi ringannya. Buat analisis sehari, kamu gak perlu dokumen formal per tahap. Yang penting urutannya: pastiin dulu pertanyaan bisnisnya apa, cek datanya cukup atau nggak, baru mulai ngoding. Melewatkan dua langkah pertama itu penyebab paling umum analisis selesai tapi gak dipakai siapa-siapa.

Penutup

Yang perlu kamu inget dari CRISP-DM:

  • Mulai dari keputusan yang mau diambil, bukan dari data yang kebetulan ada.
  • Data preparation bakal makan waktu paling banyak. Rencanakan dari awal, jangan kaget.
  • Proyek selesai kalau hasilnya dipakai berulang tanpa kamu — bukan pas notebook-nya jalan.

Proyek toko_berkah tadi nyelametin satu orang dari dipecat, dan analisisnya cuma butuh GROUP BY. Bagian yang bikin beda bukan tekniknya, tapi 40 menit ngobrol di awal.

Mau latihan alur ini di data beneran? Mulai dari glossary EDA, terus baca cara nyusun proyek portfolio data analyst — struktur CRISP-DM bikin portfolio kamu kebaca jauh lebih profesional.

Coba Langsung

Mau praktek langsung? Mulai latihan SQL gratis

Latihan interaktif, langsung di browser.

Buka NgulikSQL →
Bagikan:
Bima
Ditulis oleh

Bima

Founder & Data Professional

Founder Ngulik Data. Passionate about making data analysis accessible for everyone.

Artikel Terkait

Cara Baca Laporan Data dengan Kritis: 7 Pertanyaan Wajib
Tips & Trik
10 Juli 2026•8 menit baca

Cara Baca Laporan Data dengan Kritis: 7 Pertanyaan Wajib

Angka di laporan bisa bener semua tapi tetap nyesatin. Ini 7 pertanyaan yang aku pakai tiap kali dapat laporan dari orang lain.

BimaBima
Produktivitas Data Analyst: Sistem Kerja biar Gak Kebanjiran Request
Tips & Trik
7 Juli 2026•10 menit baca

Produktivitas Data Analyst: Sistem Kerja biar Gak Kebanjiran Request

Sistem 5 langkah buat data analyst yang tiap hari kebanjiran request dadakan — dari intake form, matriks prioritas, sampai cara nolak tanpa bikin stakeholder ngambek.

BimaBima
Bias dalam Analisis Data: 8 Jebakan yang Sering Gak Kerasa
Tips & Trik
4 Juli 2026•8 menit baca

Bias dalam Analisis Data: 8 Jebakan yang Sering Gak Kerasa

Delapan bias analisis data yang paling sering nyelip di kerjaan analyst — dari survivorship bias sampai Simpson's paradox — plus cara ngecek dan ngebenerinnya.

BimaBima
Kembali ke Blog
Ngulik Data logoNgulik Data

Platform edukasi data lengkap untuk professionals Indonesia. Belajar SQL, Data Analysis, dan lebih banyak lagi dengan praktek langsung dan feedback real-time.

Copyright © 2026 - All rights reserved

LINKS
SupportPricingDatasetBlogAffiliates
LEGAL
Terms of servicesPrivacy policy
Ngulik Data
DatasetLeaderboardBlogStore