ERP seçimi için senaryo tabanlı değerlendirme kontrol listesi
ERP adaylarını gerçek iş akışlarıyla karşılaştırmak için senaryo şablonu, kanıt kontrol listesi, örnek puanlama ve pilot kabul ölçütleri.
ERP seçiminde çok sayıda ekran görmek, işletmenizin işlerini tamamlayabildiğinizi göstermez. Bunun yerine birkaç kritik işi aynı koşullarda farklı çözümlerde deneyin. Bu rehber, operasyon, finans ve yazılım ekipleri için kuruluşa göre uyarlanabilen bir karar şablonu sunar.
Önce üç kritik iş akışını yazın
Birbirini izleyen adımları ve istisnaları içeren üç senaryo seçin. Örneğin tekliften siparişe, satın alma talebinden teslim almaya ve stok hareketinden yönetim raporuna uzanan akışlar kullanılabilir. İşletmenizde bu süreçler yoksa örneği aynen uygulamayın. Gerçek darboğazınızı temsil eden akışları süreç sahipleriyle belirleyin.
Her senaryo için başlangıç durumu, kullanıcı rolü, girdiler, adımlar, beklenen çıktı ve başarısızlık koşulu yazın. “Raporlama var mı?” yerine “Yetkili operasyon kullanıcısı belirli tarih aralığındaki bekleyen işleri dışa aktarabiliyor mu?” gibi gözlenebilir bir soru sorun. Demo için gerçek müşteri kayıtları yerine yapay veya uygun şekilde anonimleştirilmiş örnekler hazırlayın.
Mevcut alışkanlıkların tamamını yeni yazılımda tekrar oluşturmak zorunda değilsiniz. Önce standart akışın ihtiyacı karşılayıp karşılamadığını, ardından kalan farkları değerlendirin. Özelleştirme kararında geliştirme kadar bakım ve güncelleme etkisini de inceleyin. Microsoft: Standart uyumu ve fark analizi
Gösterimden önce kabul koşullarını paylaşın
Adaylara aynı senaryo dosyasını gönderin. Hazır olanı, yapılandırma gerektireni, ek geliştirme gerektireni ve yalnızca yol haritasında olanı ayrı işaretlemelerini isteyin. “Yapabiliriz” ifadesini bugün çalışan özellik gibi puanlamayın. Henüz doğrulanmayan özellikleri “test edilmedi” olarak kaydedin; sözlü iddiayı kanıt sütununa yazmayın.
Dar ekranda tablonun devamı için yatay kaydırın.
| Kontrol alanı | Demoda istediğiniz kanıt | Kabul sorusu |
|---|---|---|
| Uçtan uca süreç | Aynı örnek kaydın bütün adımları | İşlem tekrar veri girmeden tamamlandı mı? |
| İstisna yönetimi | İptal, iade veya hatalı giriş denemesi | Kayıt tutarlı biçimde düzeltilebildi mi? |
| Yetki sınırı | İki farklı rolle aynı işlem | Yetkisiz rol gerçekten engellendi mi? |
| Veri taşıma | Örnek içe aktarma ve karşılaştırma | Eksik, hatalı veya çift kayıt görüldü mü? |
| Entegrasyon | Test ortamında başarı ve hata akışı | Kesintide yeniden deneme ve sorumluluk açık mı? |
| Çıkış ve bakım | Dışa aktarım örneği, destek koşulları | Ayrılma ve bakım maliyeti anlaşılır mı? |
Her kayda kanıtın tarihi, sürüm ve gerekli ek modülü ekleyin. Bir süreçteki olumlu sonucu bütün sisteme genellemeyin. Kullanıcı kabul, süreç ve entegrasyon testleri farklı soruları yanıtlar; ihtiyacınıza göre birlikte planlanmalıdır. Microsoft: Uygulama projelerindeki test türleri
Puanlamayı kararın tek sahibi yapmayın
Önce vazgeçilmez koşulları belirleyin. Örneğin belirli bir iş için gerekli yetki sınırı veya kullanılabilir veri dışa aktarımı zorunluysa, diğer alanlardaki yüksek puan bunların eksikliğini kapatmamalıdır. Bu koşulları geçemeyen aday için eksik işin kapsamını, sorumlusunu ve yeniden test tarihini isteyin.
Kalan adaylarda 0–5 arasında örnek bir ölçek kullanılabilir: 0 ihtiyacı karşılamıyor, 1 ciddi engel var, 3 kısmi karşılıyor, 5 senaryo bütün kabul koşullarıyla doğrulandı. Ara puanların gerekçesini yazın. Test edilmemiş alanlara tahmin puanı vermeyin; toplam karşılaştırmayı tamamlanana kadar erteleyin. Ağırlıkları değerlendirmeden önce belirlemek, beğenilen ürüne göre ölçüt değiştirme riskini azaltır.
Varsayımsal örnek: daha yüksek puan hemen seçim değildir
Tamamen varsayımsal iki aday için süreç uyumuna yüzde 40, veri ve entegrasyona yüzde 25, kullanıcı deneyimine yüzde 20, işletim ve desteğe yüzde 15 ağırlık verilsin. A adayının sırasıyla 4, 3, 4, 3 puanı varsa toplamı 3,60/5; B adayının 3, 4, 4, 4 puanı varsa toplamı 3,60/5 olur. Hesap, her puanın ilgili ağırlıkla çarpılıp sonuçların toplanmasıdır.
Eşit puan eşit çözüm anlamına gelmez. A, günlük kritik iş akışında daha güçlü; B, veri aktarımı ve işletimde daha güçlü olabilir. Ekip şimdi gerçek darboğazı, kapatılacak eksiklerin maliyetini ve pilot sonuçlarını karşılaştırır. Her iki aday da zorunlu kabul koşullarını ayrıca geçmelidir. Bu puanlar gerçek ürün karşılaştırması, sektör standardı veya Kürklü Digital ürününe ait sonuç değildir.
Satın alma öncesinde küçük bir pilot kapısı koyun
Pilotu sınırlandırın: bir süreç, belli kullanıcılar, yapay test verisi ve yazılı kabul koşulları. Süreç sahibi sonucu kendisi doğrulasın. Geçiş planında eski sistemden hangi verinin taşınacağını, sayımların nasıl karşılaştırılacağını, hata durumunda kimin karar vereceğini ve geri dönüş koşullarını yazın. Canlıya geçiş öncesinde veri taşıma, entegrasyon, kullanıcı kabulü ve destek hazırlığını ayrı ayrı doğrulamak gerekir. Microsoft: Canlıya geçiş kontrol listesi
Son değerlendirmede lisans bedelinin yanında kurulum, veri temizleme, eğitim, entegrasyon, bakım ve sistemden ayrılma giderlerini aynı kapsamda isteyin. Belirsiz kalemleri sıfır kabul etmeyin; teklif netleşene kadar “belirsiz” olarak tutun. Böylece en etkileyici demoyu değil, kanıtlanmış ihtiyaç uyumunu değerlendirmiş olursunuz.