ERP ve CRM seçiminde önce hedef iş süreçleri ve sahipleri tanımlanmalı; gereksinimler kritik, farklılaştırıcı ve tercihe bağlı olarak sınıflandırılmalıdır. Ürünün demosu yerine gerçek süreç senaryoları, veri migrasyonu, entegrasyon, rol ve yetki modeli, raporlama, performans, kullanılabilirlik, test, destek, sürüm yol haritası ve çıkış kabiliyeti sınanmalıdır. “Her ihtiyacı özelleştirme” yaklaşımı teknik borç üretirken, “ürüne olduğu gibi uyun” yaklaşımı da kritik kontrol ve iş gereklerini gözden kaçırabilir.
ERP ve CRM seçimi hedef süreç ve karar modelinden başlamalıdır
ERP; finans, satın alma, envanter, üretim, insan kaynakları veya proje süreçlerini ortak kayıt ve kontrol yapısında birleştirir. CRM ise müşteri, satış, pazarlama ve hizmet etkileşimlerini yönetir. Ancak ürün adları iş sonucunu garanti etmez. Kurum önce hangi süreçlerin değişeceğini, hangi verinin ortaklaşacağını, hangi kontrollerin zorunlu olduğunu ve hangi KPI’ların iyileşeceğini belirlemelidir.
| Alan | ERP için temel soru | CRM için temel soru |
|---|---|---|
| İş sonucu | Kapanış, maliyet, stok veya tedarik nasıl iyileşecek? | Dönüşüm, satış süresi, hizmet ve müşteri görünümü nasıl iyileşecek? |
| Kayıt otoritesi | Finansal ve operasyonel kaydın sahibi hangi sistem? | Müşteri kimliği, iletişim ve izinlerin sahibi hangi sistem? |
| Kontrol | Görev ayrılığı, onay ve muhasebe kuralları nasıl uygulanacak? | Erişim, müşteri segmenti, teklif ve iletişim izinleri nasıl yönetilecek? |
| Ölçüm | Süreç ve finansal doğruluk hangi KPI’larla izlenecek? | Pipeline, aktivite ve müşteri sonucu nasıl ölçülecek? |
Gereksinim listesi mevcut ekranların kopyası olmamalıdır
Eski sistemdeki her alan, rapor ve istisnayı yeni ürüne taşımak dönüşümü engeller. Gereksinimler kullanıcı görevi, iş kuralı, veri, kontrol, performans ve kanıt şeklinde yazılmalıdır. “Rapor olmalı” yerine hangi kararın, hangi veriyle, hangi sıklıkta ve hangi güven düzeyinde alınacağı tanımlanmalıdır.
Mevzuat ve kritik kontrol
Olmadan canlıya geçilemeyecek finansal, güvenlik veya operasyon şartları.
Farklılaştırıcı kabiliyet
Müşteri, gelir, verimlilik veya risk avantajı üreten özellikler.
Ürünle uyarlanabilir süreç
Kurumsal alışkanlık yerine iyi uygulamaya yaklaşabilecek alanlar.
Konfor veya kozmetik istek
Maliyet ve karmaşıklık yaratmadan ertelenebilecek istekler.
Her kritik gereksinim için test edilebilir kabul kriteri ve sorumlu iş sahibi bulunmalıdır. Tedarikçi cevabı “destekleniyor” ifadesiyle değil; standart özellik, yapılandırma, eklenti, özel geliştirme veya üçüncü taraf bağımlılığı olarak sınıflandırılmalıdır.
Demo, gerçek uçtan uca süreç senaryolarıyla yapılmalıdır
Genel ürün demosu tedarikçinin güçlü olduğu ekranları gösterir. Kurum kendi senaryosunu, rollerini, örnek verisini, istisnalarını ve kontrol noktalarını kullanmalıdır. ERP için satın alma–teslim–fatura–ödeme veya sipariş–üretim–sevkiyat–muhasebe; CRM için lead–fırsat–teklif–sözleşme–hizmet gibi uçtan uca akışlar sınanabilir.
- Süreçte kaç ekran, rol ve manuel adım var?
- İstisna ve geri alma nasıl yönetiliyor?
- Onay ve görev ayrılığı standart mı, özel mi?
- Mobil ve erişilebilir kullanım yeterli mi?
- Toplu işlem ve yüksek hacim nasıl davranıyor?
- Audit izi ve değişiklik geçmişi görünür mü?
- Rapor ile kaynak kayıt arasında izlenebilirlik var mı?
Veri migrasyonu seçim kararının merkezinde olmalıdır
ERP ve CRM projelerinde veri migrasyonu çoğu zaman geç faza bırakılır. Oysa kaynak sistem sayısı, veri kalitesi, tekilleştirme, tarihsel veri, açık işlemler, kişisel veri, arşiv ve mutabakat gereksinimleri ürün ve süre kararını doğrudan etkiler. Hangi verinin taşınacağı, arşivleneceği veya bırakılacağı iş ve mevzuat gerekleriyle belirlenmelidir.
| Karar | Sorulacak soru | Kabul kanıtı |
|---|---|---|
| Kapsam | Hangi ana, işlem ve tarihsel veri taşınacak? | Onaylı veri kapsam matrisi |
| Kalite | Eksik, mükerrer ve hatalı kayıtlar nasıl temizlenecek? | Kalite kuralı ve hata raporu |
| Eşleme | Eski kod ve kimlikler yeni modele nasıl dönüşecek? | Mapping ve dönüşüm sözleşmesi |
| Mutabakat | Taşıma sonrası sayı ve bakiye nasıl doğrulanacak? | Kaynak–hedef karşılaştırma raporu |
| Geri dönüş | Cutover başarısız olursa veri nasıl korunacak? | Rollback ve yeniden çalışma planı |
En az birkaç deneme migrasyonu, sistem entegrasyon testi ve kullanıcı kabul testi gerçekçi veriyle yapılmalıdır. Microsoft’un Dynamics uygulama rehberi de veri migrasyonu, entegrasyon, performans, güvenlik ve kullanılabilirlik testlerinin erken planlanmasını önerir.
Entegrasyon envanteri ve kayıt otoritesi açık olmalıdır
ERP ve CRM tek başına çalışmaz. Kimlik, e-posta, ödeme, e-ticaret, veri ambarı, doküman, çağrı merkezi, banka, kamu servisi ve özel uygulamalarla ilişkilidir. Her veri alanı için kaynak otoritesi, senkronizasyon yönü, gecikme, hata kuyruğu, yeniden çalışma ve izleme tanımlanmalıdır.
| Entegrasyon sorusu | Neden önemli? |
|---|---|
| API ve olay modeli açık mı? | Kapalı ve toplu dosya bağımlılığını azaltır. |
| Hız ve kota sınırı nedir? | Hacim ve dönem sonu performansını belirler. |
| Hata ve tekrar mekanizması var mı? | Kayıp veya çift kayıt riskini azaltır. |
| Versiyon değişiklikleri nasıl duyurulur? | Entegrasyon kırılmasını önler. |
| Log ve correlation ID var mı? | Uçtan uca kök neden analizini destekler. |
Yetki modeli iş rolü ve görev ayrılığıyla sınanmalıdır
SSO ve MFA bulunması yeterli değildir. Yetkiler rol, organizasyon, veri alanı, işlem türü ve onay limitine göre çalışmalıdır. Ayrıcalıklı hesaplar, servis hesapları, denetim logları, veri şifreleme, veri lokasyonu, yedek, olay bildirimi ve alt tedarikçi politikaları incelenmelidir.
- Rol ve görev ayrılığı çatışmaları otomatik tespit ediliyor mu?
- Yetki talepleri onaylı ve süreli mi?
- Maskeleme ve hassas alan koruması var mı?
- Admin işlemleri ayrı loglanıyor mu?
- Veri dışa aktarma ve toplu indirme kontrol ediliyor mu?
- Tedarikçi destek erişimi nasıl açılıp kapatılıyor?
- Olay, yama ve güvenlik açığı bildirim süreleri sözleşmede mi?
Ürün tedarikçisi ile uygulama ortağı ayrı değerlendirilmelidir
Ürünün güçlü olması, uygulama ortağının iş analizi, mimari, veri migrasyonu, test ve değişim yönetimi kapasitesini garanti etmez. Referanslar benzer sektör, ölçek, modül, entegrasyon ve migrasyon karmaşıklığına göre incelenmelidir. Anahtar uzmanların özgeçmişi, projedeki fiilî rolü ve değişim koşulu sözleşmede yer almalıdır.
| Alan | Ürün tedarikçisi | Uygulama ortağı |
|---|---|---|
| Yol haritası | Ürün sürümü, destek ve yaşam döngüsü | Uygulama sürüm ve değişiklik yönetimi |
| Güvenlik | Ürün geliştirme ve bulut hizmeti | Proje erişimi ve yapılandırma kalitesi |
| Uzmanlık | Platform ve sektör kabiliyeti | Süreç, migrasyon, entegrasyon ve test |
| Sorumluluk | Ürün hatası ve hizmet seviyesi | Tasarım, kurulum ve teslimat kusuru |
Canlıya geçiş çok katmanlı kabul kapısına bağlanmalıdır
Test stratejisi fonksiyon, entegrasyon, migrasyon, güvenlik, performans, kullanılabilirlik, raporlama, görev ayrılığı ve iş sürekliliğini kapsamalıdır. Kullanıcı kabul testi yalnız ekran tıklama değil, gerçek rol ve iş sonucu doğrulamasıdır.
- Gereksinimleri test senaryosu ve kabul kriterine bağlayın.
- Gerçekçi veriyle konferans odası pilotu veya proof of concept yapın.
- En az bir tam uçtan uca deneme migrasyonu yürütün.
- Sistem entegrasyon, performans ve güvenlik testlerini tamamlayın.
- İş kullanıcılarıyla UAT ve görev ayrılığı doğrulaması yapın.
- Cutover, rollback, destek ve hypercare planını test edin.
- Açık kritik bulgular için go/no-go kararı alın.
Başarı lisans seçimiyle değil süreç, veri ve benimsemeyle ölçülmelidir
TCO; lisans, danışmanlık, veri, entegrasyon, özel geliştirme, test, eğitim, iç ekip, destek, kapasite, ek modül, yükseltme ve çıkış maliyetini içermelidir. Sözleşme; teslimat kabulü, anahtar ekip, değişiklik talebi, veri ihracı, fiyat artışı, hizmet seviyesi ve geçiş desteğini açıklaştırmalıdır.
| KPI | ERP örneği | CRM örneği |
|---|---|---|
| Süreç sonucu | Kapanış süresi, sipariş doğruluğu | Satış döngüsü, ilk çözüm oranı |
| Veri güveni | Mutabakat ve ana veri kalite ihlali | Mükerrer müşteri ve izin doğruluğu |
| Benimseme | Standart süreç kullanımı | Güncel pipeline ve aktivite kalitesi |
| Değişim | Yeni kuralı yayına alma süresi | Yeni kampanya veya süreç süresi |
| TCO | İşlem ve kullanıcı başına maliyet | Aktif kullanıcı ve sonuç başına maliyet |
Kaynaklar ve gözden geçirme notu
Bu rehberde değişebilir veya teknik iddialar için öncelikle resmî kurum, ürün geliştiricisi ve birincil araştırma kaynakları kullanılmıştır. Bağlantılar 27 Temmuz 2026 tarihinde gözden geçirilmiştir.
- 01GOV.UK — Technology Code of Practice
Teknoloji satın alma ve uygulama kararlarında kullanıcı ihtiyacı, açık standart, güvenlik ve sürdürülebilirlik ölçütlerini açıklar.
- 02CISA — Software Acquisition Guide
Yazılım satın alma yaşam döngüsünde güvenlik, tedarikçi ve ürün şeffaflığına ilişkin soru ve kontrolleri tanımlar.
- 03NIST SP 1326 — Supplier Due Diligence
Tedarikçi ve ürün durum tespiti için makul araştırma ve risk faktörlerini açıklar.
- 04Microsoft Dynamics 365 Implementation Guide — Testing Strategy
Fonksiyon, performans, güvenlik, kullanılabilirlik, entegrasyon ve veri migrasyonu testlerinin planlanmasını açıklar.
- 05Microsoft Dynamics 365 — Go-Live Checklist
UAT, performans, entegrasyon, veri migrasyonu, destek ve canlıya geçiş hazırlığını kapsayan kontrol yaklaşımını sunar.