ERP karşılaştırması marka listesiyle değil, kriterle yapılır.

Kısa cevap: ERP karşılaştırması, ürün broşürlerini yan yana koymak değildir. Önce kurumunuzun süreç envanteri ve zorunlulukları (GİB e-belge, TDHP, KVKK) çıkarılır; sonra adaylar aynı kriter setiyle puanlanır; en sonunda kısa listedeki 2–3 aday gerçek verinizle bir kanıtlama (PoC) turundan geçirilir. Bu sayfa, beş ayrıntılı karşılaştırma rehberimizin — Türkiye ERP markaları, bulut vs on-premise, KOBİ ERP karşılaştırması, fiyatlandırma modelleri ve e-fatura özel entegratör karşılaştırması — üzerine kurulduğu ortak seçim çerçevesini anlatır.

ERP karşılaştırması nedir, neden "en iyi ERP" listesi işe yaramaz?

ERP (kurumsal kaynak planlama) yazılımı; finans-muhasebe, satın alma, stok, üretim, satış ve insan kaynakları süreçlerini tek veri tabanında birleştiren omurga sistemdir. Bu omurga her kurumda farklı yüke biner: bir perakende zincirinin önceliği mağaza-POS bütünleşmesiyken, bir üretici için kritik olan ürün ağaçları ve planlamadır; bir kamu iştirakinde ise mevzuat raporlaması öne çıkar. Aynı ürün birinde "en iyi", diğerinde yanlış tercihtir. Bu yüzden bu sitede sıralama yayınlamayız; her rehberde aynı yöntemi uygularız: kriterleri tanımla, doğrulanabilir bilgiyle doldur, senaryoya göre yorumla. Bağımsız araştırmalar da seçimin marka değil süreç işi olduğunu doğruluyor: Panorama Consulting'in küresel ERP araştırmasına göre kuruluşların dörtte birinden fazlası projesinin bütçeyi aştığını bildiriyor ve bütçeyi aşanlarda en sık görülen neden, öngörülmeyen ek teknoloji ihtiyacı — rapor bunu projenin geç aşamasında fark edilen uyum boşluklarına, kapsam genişlemesine ve özel geliştirmelere bağlıyor (Panorama Consulting, The 2026 ERP Report duyurusu). Yani risk, ürün logosunda değil; seçim isabetinde ve kapsam disiplininde birikiyor.

Seçim kriterleri çerçevesi: 8 başlık

Karşılaştırma rehberlerimizde adayları şu sekiz kriterle ele alıyoruz. Kendi kısa listenizi de aynı çerçeveyle puanlayabilirsiniz:

1. Süreç uyumu (fit-gap): Ürünün standart akışları sizin süreçlerinizin ne kadarını özelleştirmesiz karşılıyor? Boşluk (gap) sayısı arttıkça uyarlama maliyeti ve sürüm yükseltme riski büyür.
2. Mevzuat ve yerelleştirme: GİB e-Fatura, e-Arşiv, e-İrsaliye ve e-Defter uyumu yerleşik mi, entegratörle mi sağlanıyor? TDHP/VUK raporları standart mı? Mevzuat güncellemesi kimin taahhüdünde?
3. Toplam sahip olma maliyeti (TCO): Liste fiyatı değil; lisans/abonelik + uyarlama + veri göçü + entegrasyon + eğitim + yıllık bakım + altyapının 3–5 yıllık toplamı karşılaştırılır.
4. Dağıtım modeli: Bulut (SaaS), kurum içi (on-premise) veya hibrit. Bu tek başına o kadar belirleyici ki ayrı bir rehber ayırdık: Bulut ERP vs On-Premise ERP.
5. Entegrasyon ve API: Banka, e-ticaret, MES/saha sistemleri ve raporlama araçlarıyla bağlantı standart API/servisle mi kuruluyor? Kapalı sistemler her entegrasyonu ayrı projeye çevirir.
6. Veri sahipliği ve kilitlenme (lock-in): Verinizi açık formatta (SQL/CSV/XML) dışa aktarabiliyor musunuz? Özelleştirmelerin dokümantasyonu ve alternatif uygulayıcı imkânı var mı?
7. Üretici yol haritası: Teklif edilen sürümün destek takvimi net mi? SAP'nin ECC/Business Suite 7 için standart bakımı 2027 sonunda bitirme kararı (SAP, 2020 resmî duyurusu), yol haritasının başlı başına bir satın alma kriteri olduğunu gösterdi.
8. Uygulayıcı ekosistemi: Ürünü sizin ölçeğinizde ve sektörünüzde uyarlamış iş ortağı sayısı; yerel destek gücü ve referansların doğrulanabilirliği.

Kriter ağırlıklandırma: örnek puanlama tablosu

Aynı sekiz kriter her kurumda aynı ağırlığı taşımaz; çerçeveyi işe yarar kılan, ağırlıkları kurumunuza göre dağıtmaktır. Aşağıdaki tablo temsili bir örnektir — üç farklı kurum profili için makul ağırlık dağılımlarını gösterir; kendi tablonuzu satın alma komitesiyle birlikte doldurmanız gerekir:

Mantık şu: ilk ERP'sini alan bir KOBİ için bütçe disiplini ve e-belge uyumu hayati olduğundan TCO ile mevzuat öne çıkar; ürün değiştiren orta ölçekli bir işletme, eski sistemden veri ve entegrasyon taşıyacağı için fit-gap ve API tarafına ağırlık verir; çok şirketli bir yapıda ise üreticinin on yıllık yol haritası ve uygulayıcı ekosistemi, tekil fiyat farklarından daha belirleyicidir. Her aday 1-5 arası puanlanıp ağırlıkla çarpıldığında, sonuç tablosu yönetim kuruluna sunulabilir bir karar belgesine dönüşür.

Sık yapılan 7 hata

• Demoya göre karar: Satış demosu en iyi senaryoyu gösterir; kendi verinizle, kendi istisnalarınızla PoC istemek esastır.
• Liste fiyatıyla kıyas: Uyarlama, veri göçü ve entegrasyon çoğu projede lisansın kendisinden pahalıdır; TCO yerine lisans karşılaştırmak yanıltır.
• Veri göçünü sona bırakmak: Hesap planı, cari ve stok verisinin temizliği projenin kritik yoludur; sözleşmede ayrı kalem ve kabul kriteri olmalıdır.
• Mevzuatı "nasılsa vardır" saymak: e-belge uyumunun yerleşik mi entegratörlü mü olduğu, maliyeti ve güncelleme sorumluluğunu değiştirir.
• Aşırı özelleştirme: Standart akışa uydurulabilecek süreci koda boğmak, her sürüm yükseltmeyi projeye çevirir. (Tersi de hatadır: kritik farklılaşma noktanızı pakete kurban etmek.)
• Çıkış planını sormamak: Sözleşmede veri dışa aktarım formatı ve süresi yazmıyorsa, pazarlık gücünüzü imza gününde bırakırsınız.
• İç sahiplik atamamak: Tam zamanlı bir iç proje sahibi olmayan ERP projesi, tedarikçinin öncelik listesine emanet kalır.

Şartname yaklaşımı: karşılaştırmayı satın almaya çevirmek

Kriter çerçevesi ancak şartnameye dönüşürse işe yarar. Önerdiğimiz akış dört adımdır. Birinci adım, gereksinim envanteri: süreç listesi çıkarılır, her satır "zorunlu / önemli / olsa iyi" diye etiketlenir; zorunlular arasına GİB e-belge, TDHP raporları ve KVKK gereklilikleri yazılır. İkinci adım, ağırlıklı puanlama: sekiz kriter kurumunuza göre ağırlıklandırılır (ör. mevzuat %25, TCO %20) ve adaylar aynı tabloda puanlanır — böylece karar, kişisel izlenimden bağımsız savunulabilir hâle gelir. Üçüncü adım, kanıtlama (PoC): kısa listedeki adaylardan, sizin verinizle uçtan uca bir akışı (ör. siparişten faturaya) göstermesi istenir. Dördüncü adım, sözleşme: veri dışa aktarım garantisi, mevzuat güncelleme taahhüdü, SLA ve değişiklik yönetimi prosedürü şart koşulur. Modül kapsamı tarafında neyin "standart" sayılması gerektiğini görmek için ERP ve mali-muhasebe çözüm sayfamızdaki şartname maddeleri iyi bir başlangıç listesidir.

Kapsamı belirlerken modülleri de gerçekçi sıralamak gerekir: ilk fazda genellikle finans-muhasebe ve stok-envanter yönetimi canlıya alınır; İK-bordro ve ileri planlama ikinci faza bırakılır. KVKK ve erişim yetkisi tarafını ise projenin sonuna değil başına koymak gerekir — iç kontrol ve KVKK uyum gereksinimleri, yetki matrisi tasarımını doğrudan etkiler.

Karşılaştırma süreci için gerçekçi bir takvim

Kriter çerçevesi ve şartname yaklaşımı, bir zaman planına oturmadan kağıt üzerinde kalır. Orta ölçekli bir kurum için makul bir seçim süreci — projenin kendisi değil, yalnız seçim — tipik olarak şöyle akar: gereksinim envanteri ve ağırlıklandırma için 2-4 hafta; uzun listeden (5-8 aday) kısa listeye (2-3 aday) inmek için doküman/demo turuyla 3-4 hafta; kısa liste adaylarıyla kendi verinizle PoC için 3-6 hafta; teklif, referans doğrulama ve sözleşme müzakeresi için 3-4 hafta. Toplamda çeyrek ile yarım yıl arası bir süreçtir ve bunu sıkıştırmanın bedeli, genellikle canlıya geçişten sonra ödenir. Süreç boyunca iki disiplin kritik: her adaya aynı senaryo setini göstertmek (yoksa demolar karşılaştırılamaz) ve her görüşmenin çıktısını puan tablosuna işlemek (yoksa karar, son görüşmenin izlenimine teslim olur). Referans doğrulamada üreticinin verdiği listeyle yetinmeyin; benzer ölçekte ve sektörde en az bir kullanıcıyla, tedarikçi odada değilken görüşün ve özellikle veri göçü ile destek deneyimini sorun.

Hazır paket mi, özel geliştirme mi?

Karşılaştırmanın dürüst bir cevabı da şudur: bazı kurumlar için doğru seçenek hazır paketlerden hiçbiri değildir. Süreçleriniz sektör standardına yakınsa hazır ERP hızlı ve ekonomiktir; süreçleriniz rekabet avantajınızın kendisiyse — sıra dışı bir üretim akışı, kendine özgü bir bayi/iade düzeni — paketi kendinize benzetmek için ödediğiniz özelleştirme bedeli, zamanla özel geliştirmenin maliyetine yaklaşır ama kaynak kodu yine size ait olmaz. Özel geliştirmede başlangıç süresi daha uzundur ve disiplinli bir analiz ister; karşılığında kaynak kodu, veri modeli ve yol haritası kurumda kalır, kullanıcı başına lisans ödenmez. Bu üç yolun (bulut paket, kurum içi paket, özel geliştirme) sistematik kıyasını bulut vs on-premise rehberinde bulabilirsiniz.