ERP projesinin başarısı, satın alınan ürünün özelliklerinden önce işletmenin neyi değiştirmek istediğini ne kadar açık tanımladığına bağlıdır. Aşağıdaki 12 soru; teklif toplamadan, demo izlemekten veya veri taşımaya başlamadan önce yönetim ekibinin ortak bir çerçeve oluşturmasına yardımcı olur.
1. Bu projeyi neden şimdi yapıyoruz?
“Mevcut program eski” tek başına yeterli bir gerekçe değildir. Büyüme, kontrol kaybı, raporlama gecikmesi, mevzuat, yeni lokasyon, üretim karmaşıklığı veya entegrasyon ihtiyacı gibi iş nedenleri ayrı ayrı yazılmalıdır. Projenin aciliyeti ve beklenen değeri bu gerekçeler üzerinden değerlendirilir.
2. Başarıyı hangi iş sonuçlarıyla ölçeceğiz?
Canlıya geçmek proje çıktısıdır; başarı ölçütü değildir. Aylık kapanış süresinin kısalması, stok doğruluğunun artması, sipariş karşılama oranı, manuel veri girişinin azalması veya yönetim raporunun hazırlanma süresi gibi ölçüler tanımlayın. Başlangıç değerini bilmeden iyileşmeyi ölçemezsiniz.
Her proje hedefini “mevcut değer → hedef değer → ölçüm kaynağı → sorumlu kişi” formatında yazın.
3. Proje kapsamına hangi şirket, lokasyon ve süreçler giriyor?
Tüm süreçleri aynı anda dönüştürmek çoğu işletmede gereksiz risk oluşturur. Şirketler, şubeler, depolar, üretim tesisleri, satış kanalları ve modüller bazında kapsamı açıkça sınırlandırın. Kapsam dışında kalan konuları da yazılı hale getirin; aksi halde proje ilerledikçe beklenti büyür.
4. Bugünkü süreç gerçekten nasıl çalışıyor?
Prosedürde yazan süreç ile sahada uygulanan süreç aynı olmayabilir. Sipariş, satın alma, mal kabul, üretim, sevkiyat, faturalama, tahsilat ve kapanış adımlarını gerçek kullanıcılarla gözlemleyin. Excel dosyalarını, mesajlaşma onaylarını ve kayıt dışı kontrol listelerini de sürecin parçası kabul edin.
5. Hangi ana veriler kritik?
Stok kartı, cari kart, hesap planı, ürün ağacı, reçete, fiyat listesi, proje, masraf merkezi ve personel gibi ana verilerin sahipleri belirlenmelidir. Kod yapısı yalnızca geçmiş alışkanlığa göre değil, operasyon ve raporlama ihtiyacına göre tasarlanmalıdır. Aynı kavram için birden fazla tanım bırakmak yeni sisteme eski sorunu taşır.
6. Veri kalitesinin mevcut durumu nedir?
Aktarılacak kayıtların sayısı kadar doğruluğu, tekrarı, eksik alanları ve güncelliği önemlidir. “Tüm geçmişi taşıyalım” yaklaşımı, kullanılmayan ve hatalı veriyi yeni sisteme doldurabilir. Yasal, operasyonel ve analiz ihtiyacına göre aktif veri, açılış bakiyesi ve arşiv stratejisi ayrı tasarlanmalıdır.
7. Karar ve onay yetkileri nasıl işleyecek?
ERP, mevcut organizasyondaki belirsizliği otomatik olarak çözmez. Kim sipariş açar, kim fiyat değiştirir, kim iskonto onaylar, kim stok düzeltir, kim ödeme talimatı verir? Yetki tasarımı görev ayrılığı, işlem riski ve kullanıcı deneyimi dengesinde kurulmalıdır.
8. Hangi entegrasyonlar gerçekten gerekli?
Banka, e-ticaret, üretim makinesi, saha uygulaması, e-Dönüşüm, kargo, bordro ve raporlama sistemleri için veri yönü, sıklığı ve hata senaryosu yazılmalıdır. Entegrasyon yalnızca “iki sistem konuşsun” değildir; tekrar gönderim, log, mutabakat ve sorumluluk modeli de gerekir.
9. Yönetim hangi raporlarla karar verecek?
Rapor listesini mevcut ekranların kopyası olarak hazırlamayın. Yönetimin düzenli aldığı kararları, bu kararların gerektirdiği KPI’ları ve gerekli detay seviyesini belirleyin. KPI adı, hesaplama formülü, veri kaynağı, dönem, hedef ve sorumlu içeren bir sözlük oluşturun.
10. Proje ekibinin zamanı ve karar yetkisi var mı?
ERP projesi yalnızca bilgi işlem veya muhasebe biriminin ek işi değildir. Süreç sahipleri test, veri temizliği, karar ve eğitim için planlı zaman ayırmalıdır. Proje liderinin kapsam, öncelik ve departmanlar arası anlaşmazlıklarda karar alabilecek sponsor desteği olmalıdır.
11. Test ve kabul nasıl yapılacak?
“Ekran açıldı” kabul kriteri değildir. Gerçek iş senaryolarını uçtan uca tanımlayın: siparişten tahsilata, satın almadan ödemeye, hammaddeden bitmiş ürüne kadar belge, muhasebe, stok ve rapor etkilerini birlikte test edin. Hata önceliği, düzeltme ve yeniden test süreci belirli olmalıdır.
12. Canlıya geçişten sonra sistemi kim yaşatacak?
Kullanıcı eğitimi, ilk dönem destek, ana veri değişiklikleri, yeni rapor talepleri, yetki güncellemeleri ve sürüm yönetimi için işletme içi sahipler belirlenmelidir. Proje ekibi dağıldığında sistemin standardını koruyacak yönetişim yapısı kurulmazsa birkaç ay içinde eski alışkanlıklara dönülebilir.
Sonuç: ERP projesi bir teknoloji satın alma kararı değildir
Başarılı bir ERP projesi; iş hedefi, süreç standardı, doğru veri, karar yetkisi ve kullanıcı sahipliğini ortak bir modelde birleştirir. Bu 12 soruya net yanıt veremediğiniz alanlar, projenin en önemli analiz başlıklarıdır. Ön analiz çalışması, yazılım karşılaştırmasına geçmeden önce bu belirsizlikleri görünür hale getirir.