CRISP-DM vs MLOps 2026: Veri Bilimi Proje Yönetimi Rehberi

CRISP-DM nedir? 1996’da SPSS, NCR ve DaimlerChrysler tarafından geliştirilen, veri madenciliği projelerini altı fazda (Business Understanding, Data Understanding, Data Preparation, Modeling, Evaluation, Deployment) standartlaştıran sektör-bağımsız bir referans modeldir. Kaggle’ın 2022 State of Data Science raporuna göre veri bilimi takımlarının yaklaşık %43’ü hâlâ CRISP-DM iskeletini kullanır. Ancak 2026 itibarıyla modelin tek başına yetersiz kaldığı bir gerçek: prodüksiyon ML sistemleri için MLOps disiplini gerekiyor. Bu yazıda CRISP-DM’in altı fazını, MLOps olgunluk seviyelerini, iki yaklaşımın karşılaştırmasını ve hibrit bir proje metodolojisini sayısal verilerle ele alıyorum.

“crisp-dm nedir” sorusunun kısa cevabı: yapılandırılmış bir veri madenciliği yaşam döngüsü çerçevesidir. Uzun cevap ise daha incelikli — çünkü 30 yıllık bir standardı 2026’nın gerçek-zamanlı, sürekli yeniden eğitilen ML servisleriyle eşleştirmek doğrudan kopya-yapıştır değil, kritik bir adaptasyon meselesi. Türkiye’de finans, e-ticaret ve telekom sektörlerinde CRISP-DM tabanlı projelerin MLOps boru hattına geçişinde yaşanan başarısızlık oranı (deploy edilemeyen modeller) Algorithmia 2021 State of Enterprise ML raporuna göre %55 civarında. Bu istatistik metodoloji seçimini ciddiye almamızı gerektiriyor.

CRISP-DM’in Altı Fazı ve Ne İşe Yarar

CRISP-DM (Cross-Industry Standard Process for Data Mining), 1996-1999 arasında bir Avrupa Birliği projesi olarak doğdu; 2000’de ilk versiyon yayımlandı. Sektör bağımsız (cross-industry) olması, banka risk skorlamasından üretim hattı anomali tespitine kadar her domainde uygulanabilmesini sağladı. Modelin temel çıktıları: ortak terminoloji, fazlar arası iterasyon, dokümantasyon disiplini ve iş hedefiyle teknik çıktının hizalanması.

Altı faz sıralı değil, iteratiftir. Bir fazdan diğerine ilerleme oklarla gösterilse de geri dönüşler (özellikle Modeling’den Data Preparation’a, Evaluation’dan Business Understanding’e) kuraldır. KDnuggets’ın 2014, 2017 ve 2020 anketlerinde CRISP-DM yöntemler listesinde sürekli birinci sırada kalmıştır — 2020’de katılımcıların %49’u kullandığını belirtmiştir.

Faz	Ana çıktı	Tipik süre payı	Sorumlu rol
1. Business Understanding	Proje hedefi, başarı kriteri, KPI’lar	%5-10	Domain expert + PM
2. Data Understanding	İlk EDA, veri kalite raporu, hipotezler	%10-15	Veri analisti
3. Data Preparation	Temizlenmiş feature tablosu	%50-70	Data engineer + DS
4. Modeling	Aday modeller, hiperparametre sonuçları	%10-15	Data scientist
5. Evaluation	Test seti metrikleri, iş anlamı	%5-10	DS + Business
6. Deployment	Üretim modeli + raporlama	%5-10	ML engineer

Tabloda dikkat çeken oran Data Preparation’ın %50-70 payı. Bu, Anaconda’nın 2022 State of Data Science raporundaki “veri bilimcilerin zamanının yaklaşık %39’unu veri hazırlığa harcadığı” bulgusuyla örtüşür; CRISP-DM bu pratiği 1999’da öngörmüştü. Sağlam bir veri kalitesi kontrol katmanı bu fazın süresini ciddi ölçüde kısaltabilir.

MLOps Nedir: Sürekli Teslimat Disiplini

MLOps (Machine Learning Operations), DevOps prensiplerini ML yaşam döngüsüne uyarlayan ve modeli prodüksiyonda izleme/yeniden eğitme döngüsünü otomatize eden bir mühendislik disiplinidir. Terim ilk defa 2018-2019 civarında Google ve Microsoft mühendisleri tarafından yaygınlaştırıldı; Google Cloud’un yayımladığı “MLOps: Continuous delivery and automation pipelines in machine learning” makalesi (cloud.google.com, 2020-2024 arası güncellenmiştir) referans niteliğinde.

Google’ın olgunluk modeli üç seviye tanımlar: Seviye 0 (manuel süreç), Seviye 1 (ML pipeline otomasyonu), Seviye 2 (CI/CD pipeline otomasyonu). Microsoft Azure ve AWS de benzer 0-2/0-4 dereceli olgunluk eşelleri yayımladı. Google Cloud MLOps referans mimarisi bu seviyeleri detaylı tarif eder.

Olgunluk seviyesi	Karakteristik	Eğitim sıklığı	Drift tespiti	Tipik araç
0 — Manuel	Notebook bazlı, elle deploy	3-12 ay	Yok / manuel	Jupyter + scp
1 — ML pipeline otomasyonu	Otomatik retraining trigger	Haftalık-aylık	Statistical (KS, PSI)	Kubeflow, Vertex AI Pipelines
2 — CI/CD otomasyonu	Kod + model + veri sürümlü	Günlük / event-driven	Otomatik + alert	MLflow + Argo + Evidently

Algorithmia’nın 2021 anketi: yetişkin sermayeli şirketlerin %64’ünün bir modeli prodüksiyona almak için 1 aydan fazla sürdüğü; %38’inin model deployment için zamanının %50’sinden fazlasını harcadığı belirlendi. MLOps tam da bu “son mile” sorununa cevap üretir. Bu nedenle modern veri ekipleri, bir domain-owned data mesh mimarisi üzerine MLOps katmanı kurmayı tercih ediyor.

CRISP-DM vs MLOps: Yapısal Farklar

İki yaklaşım kategorik olarak farklı şeylere cevap verir. CRISP-DM bir proje metodolojisidir: bir ML projesini nasıl başlatıp bitireceğinizi anlatır. MLOps ise bir operasyonel disiplindir: prodüksiyona aldığınız modeli aylar/yıllar boyunca nasıl canlı tutacağınızı tanımlar. CRISP-DM’in 6. fazı “Deployment” tek paragraflık bir bölümdür; MLOps bu paragrafı 200 sayfalık bir mühendislik kitabına dönüştürür.

Boyut	CRISP-DM	MLOps
Doğuş yılı	1996 (v1: 2000)	2018-2019
Odak	Proje yaşam döngüsü	Operasyonel süreklilik
Faz sayısı	6 sıralı faz	Sürekli döngü (CT/CI/CD)
Versiyonlama	Doküman bazlı	Kod + veri + model (Git/DVC/MLflow)
Otomasyon	Minimal	Pipeline-first
Monitoring	Yok	Drift, latency, fairness
Roller	DS + analist + domain	+ ML engineer + SRE + platform
İdeal proje süresi	2-6 ay tek devir	Süresiz, çok devirli
Başarı metriği	Test seti AUC/RMSE	Production SLO + iş KPI

İki yaklaşım birbirinin rakibi değil tamamlayıcısıdır. CRISP-DM’in zayıf noktası Deployment ve Monitoring’in eksikliğidir; MLOps’un zayıf noktası ise ilk fazlardaki iş hizalama disiplininin doğal olarak gelmemesidir. Sahada karşılaştığım veri bilimi takımlarının çoğunda CRISP-DM faz 1-2’yi ihmal edip Modeling’e atladığında, iyi modelin kötü problemi çözdüğü durumlarla karşılaşılıyor. Ömer Önal olarak danışmanlığını verdiğim projelerde fazların ilk %15’ini iş çerçevesine ayırmadan kod yazılmasına izin vermiyorum.

Süreç Akışı: CRISP-DM’in Modern MLOps’a Eşlemesi

CRISP-DM’in altı fazını terk etmek gereksiz; her fazı modern bir araç ve uygulamayla genişletmek mümkün. Aşağıdaki eşleme, 2024-2026 dönemindeki üretim ML mimarilerinde sıklıkla görülen pattern’leri yansıtır.

CRISP-DM fazı	MLOps karşılığı	Tipik araç stack (2026)	Çıktı artifact
Business Understanding	Problem framing + SLO tanımı	Confluence, Jira, OKR docs	Model card v0 (planned metrics)
Data Understanding	Feature discovery + lineage	dbt docs, OpenLineage, Marquez	EDA notebook + data contract
Data Preparation	Feature engineering pipeline + Feature Store	Feast, Tecton, Databricks FS	Versionlu feature table
Modeling	Experiment tracking + AutoML	MLflow, W&B, Vertex AI	Registry’de aday model + run log
Evaluation	Offline + online (shadow, A/B)	Optuna, Evidently, Fiddler	Eval raporu + champion/challenger
Deployment	CI/CD + serving + monitoring	Seldon, KServe, Argo, Prometheus	Live endpoint + dashboard

Bu eşleme, ham veri akışından feature store’a, oradan model registry’e ve canlı endpoint’e kadar bir Spark + Kafka pipeline mimarisi üzerinde inşa edilir. Streaming feature’lar için ise Flink/Kafka stream processing katmanı vazgeçilmezdir.

Veri Hazırlığı ve Feature Store: %70’lik Faz

CRISP-DM’in en uzun fazı Data Preparation, MLOps dünyasında “Feature Engineering Pipeline” ve “Feature Store” kavramlarına evrildi. Feature Store, eğitim ve servis (training-serving skew) farkını gidermek için tek doğruluk kaynağı olarak çalışır. Uber Michelangelo (2017) ve Airbnb Zipline ilk örneklerdi; bugün açık kaynak Feast ve ticari Tecton, Databricks Feature Store standart hâline geldi.

• Avantaj: Online ve offline feature’lar tek tanımdan üretildiği için training-serving skew yaklaşık sıfırlanır.
• Avantaj: Feature reuse: bir takımın yazdığı “user_7d_purchase_count” başka takımca direk tüketilebilir; geliştirme süresi %30-50 düşer (Tecton vaka çalışmaları, 2023).
• Dezavantaj: Self-hosted Feast bile Redis + S3/GCS + offline store (BigQuery/Snowflake) gerektirir; küçük takım için fazla operasyon yükü.
• Ne zaman seç: Aynı feature’ı 3+ model paylaşıyorsa veya saniye altı online tahmin gerekiyorsa.
• Ne zaman seçme: Tek bir batch model çalışıyor ve haftalık tahmin yeterliyse Feature Store ROI’si negatif.

Feature Store altyapısının arkasında genelde bir data lakehouse mimarisi bulunur; offline store olarak Delta/Iceberg tabloları, online store olarak Redis/DynamoDB tercih edilir. Bu eşleştirme dolayısıyla BigQuery vs Snowflake seçimi MLOps olgunluğunu doğrudan etkiler.

Model Registry, Versionlama ve Sürüm Yönetimi

CRISP-DM “Modeling” çıktısı tipik olarak bir .pkl dosyası ve bir notebook’tu. MLOps bunu üç boyutlu sürümlemeye genişletir: kod (Git), veri (DVC/LakeFS/Delta), model artifact (MLflow Registry/SageMaker Registry). Bir deney ancak bu üç boyut sabitlenirse tekrarlanabilir. MLflow Model Registry dokümantasyonu staging→production→archived geçişlerini ve onay akışını tanımlar.

Registry / Tracker	Lisans	Self-host	Notu
MLflow	Apache 2.0	Evet	De facto açık standart, geniş entegrasyon
Weights & Biases	Ticari (free tier)	Enterprise plan	Görselleştirme ve sweep güçlü
Vertex AI Model Registry	GCP managed	Hayır	Vertex Pipelines entegrasyonu sıkı
SageMaker Model Registry	AWS managed	Hayır	SageMaker Pipelines ile uyumlu
Azure ML Registry	Azure managed	Hayır	Component bazlı yeniden kullanım
Neptune.ai	Ticari	Enterprise	Büyük ölçekli deney organizasyonu

Pratik bir öneri: yeni başlayan takımlar için MLflow + DVC + Git üçlüsü 2026’da hâlâ en düşük operasyon yüküyle başlanabilir kombinasyon. Cloud-native bir tercih varsa kurumun mevcut bulut sağlayıcısına bağlı yönetilen registry seçilir. Registry’nin metadata katmanı, çoğu zaman bir data catalog (Atlan/Collibra/Atlas) sistemiyle birleştirildiğinde lineage uçtan uca kapanır.

Monitoring, Drift Detection ve SLO’lar

CRISP-DM “Evaluation” fazı test setinde durur; MLOps ise modeli prodüksiyona aldıktan sonra data drift, concept drift, prediction drift ve performance drift kategorilerinde sürekli izler. ENISA’nın 2023 AI Threat Landscape raporu, model drift’inin AI sistem güvenilirliği üzerinde başlıca işletme riski olduğunu vurguladı. NIST AI Risk Management Framework (AI RMF 1.0, Ocak 2023) da “Measure” ve “Manage” fonksiyonlarında benzer monitoring gereksinimlerini standartlaştırır.

1. Data drift: Giriş feature dağılımının değişmesi. Kolmogorov-Smirnov, Population Stability Index (PSI) sık kullanılır. PSI > 0.25 genelde alarm eşiği.
2. Concept drift: Girdi-çıktı ilişkisinin kayması (ör. müşteri davranışının pandemiyle değişmesi). Ground truth gerekli, gecikmeli ölçülür.
3. Prediction drift: Modelin verdiği tahmin dağılımının değişmesi. Ground truth beklenmeden erken sinyal verir.
4. Performance drift: AUC/F1/RMSE’nin baseline’a göre düşmesi. SLO ihlal eşiği genelde -%5 ile -%10 arası tanımlanır.

Monitoring aracı	Tip	Açık kaynak	Güçlü yön
Evidently AI	Drift + quality reports	Evet (Apache 2.0)	Python-native, hızlı kurulum
Arize AI	End-to-end ML observability	SaaS	Embedding drift, RAG izleme
Fiddler	Explainability + monitoring	SaaS	Fairness ve XAI odağı
WhyLabs	Statistical profiling	SaaS + open whylogs	Düşük overhead, geniş hacim
Prometheus + Grafana	Latency/throughput	Evet	Infra metric’leriyle birleşim

SLO örnekleri: p95 latency < 150 ms, error rate < 0.1%, prediction drift PSI < 0.2, weekly AUC > baseline – 0.03. Google SRE Book SLO bölümü bu disiplinin ML servisleri için de referansıdır. Yüksek hacimli skorlama servisleri için altyapı tarafında PostgreSQL performans optimizasyonu veya OLAP tarafı için Druid/Pinot/Trino federated query mimarileri pratiğe girer.

Hibrit Metodoloji: CRISP-ML(Q) ve Pratik Şablon

2021’de Studer ve ekibi CRISP-ML(Q) adıyla bir arXiv preprint yayımlayarak, CRISP-DM’i ML’e uyarlayan ve kalite güvencesi (Quality assurance) fazları ekleyen genişletilmiş bir model önerdi. CRISP-ML(Q) altı fazı korur ama her faza Q (Quality) görevleri ekler: veri kalite kontrolü, model robustluk testleri, açıklanabilirlik kontrolü, monitoring tasarımı. Bu pratikte CRISP-DM ile MLOps arasındaki köprüdür.

Sahada uyguladığım hibrit şablon: ilk iki haftada CRISP-DM’in Business + Data Understanding fazlarını klasik biçimde yürüt; üçüncü haftadan itibaren tüm artefaktları (notebook, veri, feature, model) Git/DVC/MLflow üçlüsüne çek; Deployment fazını sprint-0’dan itibaren “shadow mode” hedefiyle kur. Bu, klasik bir dbt analytics engineering akışına ML eklendiğinde özellikle iyi çalışır.

• Sprint 0 (1 hafta): Business Understanding + risk haritası + SLO taslağı.
• Sprint 1-2 (2 hafta): Data Understanding + data contract + EDA notebook + baseline metric kararı.
• Sprint 3-5 (3 hafta): Data Preparation pipeline (Airflow/Dagster), Feature Store entegrasyonu.
• Sprint 6-8 (3 hafta): Modeling + experiment tracking, MLflow registry’de en az 3 aday model.
• Sprint 9 (1 hafta): Offline evaluation + bias/fairness kontrolü + model card.
• Sprint 10 (1 hafta): Shadow deployment + Evidently monitoring kurulumu.
• Sprint 11+ (sürekli): Canary → full rollout, retraining tetikleri, post-mortems.

Maliyet, ROI ve Takım Kompozisyonu

MLOps yatırımı altyapı maliyetini doğal olarak yükseltir ama deploy başarı oranını ve modelin yaşam süresini de uzatır. McKinsey’in 2023 “The state of AI” raporu, MLOps pratiklerine yatırım yapan organizasyonların ML projelerinden EBITDA katkısı elde etme olasılığını yaklaşık 3 kat artırdığını gösteriyor.

Senaryo	Yıllık altyapı (USD)	Min. takım	Model deploy/yıl	Tipik MTTR
CRISP-DM saf (Seviye 0)	~5K-15K	1 DS + 1 analist	1-2	Günler/haftalar
MLOps Seviye 1	~30K-80K	2 DS + 1 ML eng	5-10	Saatler
MLOps Seviye 2	~100K-300K	3 DS + 2 ML eng + 1 platform	20-50	Dakikalar
Büyük platform (FAANG benzeri)	$1M+	10+ ML eng + 5 platform	100+	Saniyeler (auto-rollback)

Tablodaki maliyetler yaklaşık değerlerdir; gerçek rakam bulut sağlayıcı kontratına, veri hacmine, online tahmin trafiğine göre değişir. ROI’yi savunmak için en güvenilir çerçeve: modelin etkilediği iş KPI’sının baseline’ı çıkarılır, A/B testiyle uplift ölçülür, yıllık değer tahmini yapılır; bunun yaklaşık %20-30’u altyapı bütçesi olarak ayrılır. Sonuçlar verisel olarak bir vector veritabanı semantik arama projesinde, salt model performansından çok latency p95’in iyileştirilmesinin gelir-başına etkisini ölçen ekipler için belirgin biçimde olumludur.

Yönetişim, KVKK ve Etik AI Boyutu

CRISP-DM’in yazıldığı 1996’da GDPR yoktu, KVKK 2016’da çıktı, AB AI Act 2024 yılında yürürlüğe girdi. Modern bir ML projesi metodolojisi, yönetişim, veri minimizasyonu ve açıklanabilirlik gereksinimlerini ilk fazdan itibaren yansıtmak zorunda. Veri yönetişimi (GDPR/KVKK/katalog) çerçevesi olmadan üretilen bir ML modeli, regülatör denetiminde yeniden tasarlanmak zorunda kalır.

NIST AI RMF (2023) ve ISO/IEC 23894:2023 AI Risk Management standardı, riski “Govern → Map → Measure → Manage” döngüsünde tarif eder. Pratikte her CRISP-DM fazına bir governance kontrolü eklenir: Business Understanding’de risk değerlendirmesi, Data Understanding’de kişisel veri envanteri, Modeling’de fairness testleri, Deployment’ta açıklanabilirlik raporu (örn. SHAP). NIST AI Risk Management Framework resmi sayfası uygulama playbook’larını içerir.

Sıkça Sorulan Sorular (SSS)

Sonuç

CRISP-DM 1996’da ortaya çıkmış olsa da 2026’da hâlâ proje çerçeveleme aşamasında en sağlam metodolojidir; MLOps ise prodüksiyona alma ve sürekli teslimat tarafının operasyonel disiplinidir. Bu ikisi rakip değil katmanlıdır: CRISP-DM “ne yapacağız” sorusunu, MLOps “nasıl ayakta tutacağız” sorusunu yanıtlar. CRISP-ML(Q) bu iki katmanın resmî köprüsüdür; sahadaki uygulanabilir şablon ise altı fazı korumak ve her faza versiyonlama + monitoring + governance görevleri eklemektir.

Karar çerçevesi şu üç soruyla netleşir: (1) Model bir kez mi konuşlandırılacak yoksa sürekli güncellenecek mi? (2) Aynı feature’ı kaç model paylaşacak? (3) Regülatör/audit ne sıklıkla lineage isteyecek? Cevaplar büyüdükçe MLOps olgunluk seviyesi yükselmelidir; tersi durumda fazla mühendislik maliyeti boşa gider. Modeli proje yerine ürün olarak görmek bu kararı kolaylaştırır.

Kurumsal bir veri bilimi takımı için CRISP-DM + MLOps hibridine geçişi planlıyorsanız, mevcut data warehouse, feature pipeline ve deployment skor kartınızı incelemek için iletişim sayfası üzerinden bir görüşme talep edebilirsiniz; yol haritasını birlikte üç oturumda netleştirebiliriz.