Bulut ERP vs On-Premise ERP: Maliyet, KVKK, Ölçekleme ve Geçiş

Kısa cevap: Bulut ERP'de yazılım, sağlayıcının altyapısında çalışır; abonelik ödersiniz, güncelleme ve altyapı işletimi sağlayıcıya aittir. On-premise ERP'de yazılım kendi sunucunuzda çalışır; lisans ve donanıma yatırım yapar, işletim sorumluluğunu kendiniz taşırsınız. Bulut; hızlı başlangıç, düşük başlangıç yatırımı ve öngörülebilir gider isteyen kurumlara; on-premise ise veri konumu üzerinde tam kontrol, derin özelleştirme ve mevcut BT ekibiyle işletme isteyen kurumlara daha uygundur. Karar, beş yıllık toplam sahip olma maliyeti (TCO) ve KVKK yükümlülükleri birlikte modellenmeden verilmemelidir.

Tanımlar: neyi karşılaştırıyoruz?

Bulut ERP derken kastedilen çoğunlukla SaaS modelidir: yazılım, ABD standart enstitüsü NIST'in bulut tanımındaki "hizmet olarak yazılım" sınıfına uygun biçimde sağlayıcının altyapısında çok kiracılı çalışır ve tarayıcıdan kullanılır (NIST SP 800-145, 2011). Bunun yanında tek kiracılı "barındırılan/private cloud" ara modeli de vardır — büyük üreticiler ikisini de sunar; örneğin SAP, S/4HANA'yı hem public hem private cloud sürümüyle listeler (sap.com, 2026). On-premise ERP ise lisansını satın aldığınız yazılımın kendi veri merkezinizde veya kiraladığınız sunucuda, sizin kontrolünüzde çalıştırılmasıdır. Türkiye pazarındaki yerli üreticilerin çoğu iki modeli birden sunar; hangi ürünün hangi modelde sunulduğunu Türkiye ERP karşılaştırmasında tablo hâlinde bulabilirsiniz.

Kriter bazlı karşılaştırma tablosu

Tablo, model düzeyinde kategorik bir karşılaştırmadır; belirli bir ürünün taahhüdü değildir. Ürün bazlı doğrulanmış bilgiler için Türkiye ERP karşılaştırmasına bakın.

Toplam sahip olma maliyeti: iki modelin TCO bileşenleri

İki modeli liste fiyatıyla kıyaslamak en yaygın hatadır; çünkü kalemler farklı yerlerde birikir. Bulutta TCO ≈ abonelik (kullanıcı × ay) + uyarlama/danışmanlık + veri göçü + entegrasyonlar + eğitim + yedekli internet hattı. On-premise'ta TCO ≈ lisans + sunucu/sanallaştırma/yedekleme altyapısı + uyarlama + veri göçü + entegrasyonlar + eğitim + yıllık bakım + BT personelinin bu işe ayrılan mesaisi + 4-5 yılda bir donanım yenileme. İki listeyi aynı 5 yıllık zaman çizgisine döktüğünüzde sonuç kuruma göre değişir: kullanıcı sayısı küçük ve BT kadrosu dar olan işletmelerde bulut toplamı çoğunlukla daha düşük çıkar; kullanıcı sayısı büyüdükçe abonelik kalemi bileşik büyür ve mevcut veri merkezi yatırımı olan kurumlarda on-premise avantaja geçebilir. Bağımsız araştırmalar bütçe riskinin asıl kaynağının model seçimi değil kapsam yönetimi olduğunu gösteriyor: Panorama Consulting'in ERP araştırmasında kuruluşların dörtte birinden fazlası projesinin bütçeyi aştığını bildiriyor ve bütçeyi aşanlarda en sık neden öngörülmeyen ek teknoloji ihtiyacı — rapor bunu geç fark edilen uyum boşluklarına, kapsam genişlemesine ve özel geliştirmelere bağlıyor (Panorama Consulting, The 2026 ERP Report). Yani hangi modeli seçerseniz seçin, veri göçü ve entegrasyona ayrı bütçe ve kabul kriteri yazmak zorundasınız.

Güvenlik ve KVKK: sorumluluk kimde?

Güvenlikte doğru soru "bulut mu güvenli, on-premise mi" değil, "hangi katmanı kim yönetiyor" sorusudur. Bulutta fiziksel güvenlik, altyapı yamaları ve platform izleme sağlayıcının işidir; kullanıcı yetkilendirme, parola politikası ve erişim logları yine sizin işinizdir — ihlallerin önemli bölümü bu katmanda yaşanır. On-premise'ta ise işletim sistemi yamasından yedekleme testine, sızma testinden felaket kurtarmaya bütün katmanlar kurumun sorumluluğundadır; bu, güçlü BT ekibi olan kurumlar için kontrol, olmayanlar için risk demektir. KVKK boyutunda kritik değişken veri merkezinin konumudur: 6698 sayılı Kanun kişisel verilerin yurt dışına aktarılmasını 9. maddedeki şartlara bağlar (KVKK, kvkk.gov.tr); bulut sözleşmesinde verinin barındırıldığı ülke, alt işleyenler ve silme/iade prosedürü açıkça yazılmalıdır. Erişim yetkisi tasarımı ve denetim izleri her iki modelde de şartname konusudur — bu tarafın çerçevesi için iç kontrol ve KVKK uyum sayfamıza bakabilirsiniz.

Ölçekleme ve performans

Bulutta ölçekleme ticari bir işlemdir: kullanıcı eklemek aboneliği artırmaktır, kapasite sağlayıcının havuzundan gelir. Hızlı büyüyen, şube açan, dönemsel yük dalgalanması yaşayan işletmeler için bu ciddi bir esnekliktir. On-premise'ta ölçekleme bir mühendislik işlemidir: sunucu, disk, lisans ve kurulum ister; planlıdır ama öngörülebilir performans ve veri yerelliği sunar — üretim sahasındaki terminallerin milisaniyelere duyarlı olduğu senaryolarda yerel kurulum hâlâ tercih nedenidir. Sanallaştırma ve yedekleme altyapınız güçlüyse on-premise ölçekleme maliyeti düşer; bu altyapının bileşenlerini sunucu sanallaştırma ve yedekleme çözümü sayfasında ayrıntılı anlattık.

Kesinti riski ve iş sürekliliği

Bulut ERP'nin görünür riski internet bağımlılığıdır; yedekli hat olmadan kritik operasyon buluta taşınmamalıdır. Görünmeyen tarafta ise sağlayıcı SLA'sı vardır: taahhüt edilen erişilebilirlik oranı, planlı bakım pencereleri ve ihlal hâlinde tazminat şartları sözleşmede ölçülebilir yazılmalıdır. On-premise tarafta kesinti riski daha az konuşulur ama daha somuttur: tekil sunucu arızası, elektrik/soğutma sorunu, fidye yazılımı. Bu risklerin cevabı yedeklilik (replikasyon, yedek merkez) ve düzenli test edilen bir felaket kurtarma planıdır — ki bu da TCO'ya eklenmesi gereken gerçek bir maliyettir. Özet: kesintisiz sistem yoktur; sorumluluğu sözleşmeyle sağlayıcıya devretmek ile planla kendi üzerinize almak arasında seçim vardır.

Geçiş senaryoları: hangi yol, ne zaman?

• İlk ERP'sini seçen KOBİ: Kuruluş altyapısı yoksa bulut, makul varsayılandır; düşük başlangıç maliyeti ve hızlı devreye alma öne çıkar. Sözleşmeye veri dışa aktarım formatı ve süresi mutlaka yazılmalıdır.
• On-premise'tan buluta geçen kurum: Aynı üreticinin bulut sürümüne geçiş görece yönetilebilirdir; ürün de değişiyorsa bu tam bir ERP projesidir — veri göçü, entegrasyonların yeniden kurulumu ve paralel çalışma dönemi planlanmalıdır.
• Takvim baskısıyla geçen kurum: Sektörün en büyük örneği yaşanıyor: SAP, ECC'nin de içinde olduğu Business Suite 7 için standart bakımı 2027 sonunda bitiriyor (SAP resmî duyurusu, 2020); ECC'den S/4HANA Cloud'a tam geçişin ortalama 18-36 ay sürdüğü ve uzman iş gücünde daralma yaşandığı raporlanıyor (SAVIC Technologies, Mayıs 2026). Ders üründen bağımsız: dağıtım modeli kararınızı üreticinin yol haritası takvimiyle birlikte verin.
• Regülasyon hassasiyeti yüksek kurum: Veri konumu şartı varsa Türkiye'de veri merkezi sunan bulut, private cloud veya on-premise kısa listeye girer; yurt dışı SaaS için hukuki değerlendirme şarttır.

Üçüncü seçenek: özel geliştirme

Bulut-paket ve on-premise-paket ikilemi, sorunun yarısını sorar: "yazılım nerede çalışacak?" Asıl soru şudur: "yazılım kimin süreçlerine göre yazıldı?" Süreçleri standarda yakın kurumlar için paket + uygun dağıtım modeli doğru cevaptır. Süreçleri kendine özgü kurumlar içinse üçüncü bir yol vardır: kuruma özel geliştirilen ERP. Bu modelde dağıtım ikilemi ortadan kalkar — yazılım isterseniz kendi sunucunuzda, isterseniz bulutta çalışır, çünkü kaynak kodu ve mimari karar sizindir. Kullanıcı başına abonelik ödenmez, üreticinin sürüm takvimine ve bakım-sonu kararlarına bağımlılık oluşmaz; e-belge entegrasyonu sürece göre tasarlanır. Dürüst dezavantajları da yazalım: başlangıç süresi paketten uzundur, analiz disiplini ister ve tek geliştirici ekibe bağımlılık riski, kaynak kod + dokümantasyon teslimi sözleşmeye yazılarak yönetilmelidir. Kapsam ve şartname çerçevesi için ERP çözüm sayfamız ile seçim rehberimizdeki kriter setini birlikte kullanabilirsiniz.

Hangi durumda hangisi?

• Dar BT kadrosu, hızlı başlangıç, öngörülebilir gider: Bulut ERP; SLA ve veri iade hükümleri sözleşmede ölçülebilir olmalı.
• Mevcut veri merkezi, güçlü BT ekibi, veri konumu şartı: On-premise veya Türkiye lokasyonlu private cloud.
• Dönemsel yük, şubeleşme, hızlı büyüme: Bulut; ölçeklemenin ticari işleme dönüşmesi belirleyici avantaj.
• Derin özelleştirme ihtiyacı, sahaya duyarlı performans: On-premise; özelleştirmelerin sürüm yükseltme maliyeti bütçeye eklenmeli.
• Paket akışlara sığmayan süreçler, lisans/lock-in yorgunluğu: Özel geliştirme; dağıtım modelini kurum kendisi seçer, kaynak kodu kurumda kalır.