Modüler ERP mimarisi: tek blok sistemden parçalı yapıya geçiş

Bir ERP projesi başladığında genelde tek bir soru sorulur: "Hangi paket, hangi vendor?" Oysa 2026'nın ikinci yarısında analist firmaların gündeminde farklı bir soru var: sistem tek parça mı kurulacak, yoksa parça parça mı birleştirilecek? Gartner'ın "composable ERP" olarak adlandırdığı bu yaklaşım, klasik "tek paket her şeyi yapar" mantığının yerine, işlevleri ayrı ayrı seçip birbirine API üzerinden bağlamayı öneriyor. Türkçe karşılığıyla modüler ERP mimarisi, büyük vendorların ürün yol haritalarında giderek daha çok yer tutuyor; ama her işletme için aynı anlama gelmiyor.

Modüler ERP mimarisi nedir

Klasik ERP kurulumunda finans, stok, satış, üretim gibi modüller aynı vendor'ın tek bir paketi içinde, birbirine sıkı sıkıya bağlı olarak gelir. Bir modülü değiştirmek ya da güncellemek, çoğu zaman sistemin geri kalanını da etkiler; yeni bir entegrasyon eklemek haftalar sürebilir.

Modüler ERP mimarisinde ise sistem, birbirinden bağımsız çalışabilen ve standart arayüzler (API) üzerinden konuşan parçalardan oluşur. Bir işletme örneğin finans çekirdeğini bir vendor'dan, depo yönetimini başka bir vendor'dan, pazaryeri entegrasyonunu üçüncü bir araçtan alıp aynı veri katmanında birleştirebilir. Amaç, tek bir dev sistemin her şeyi yapmasını beklemek yerine, ihtiyaç değiştikçe parçaları tek tek değiştirebilmek.

Paketlenmiş iş yetkinlikleri: modülerliğin yapı taşı

Gartner bu parçalara "packaged business capabilities" (PBC) adını veriyor — Türkçesiyle paketlenmiş iş yetkinlikleri. Sipariş yönetimi, fiyatlandırma, stok takibi, müşteri hizmetleri gibi her biri kendi başına çalışabilen, stabil bir API üzerinden dışarıya açılan ve ayrı ayrı devreye alınabilen yazılım bileşenleri olarak tanımlanıyor. Bir PBC'yi değiştirmek, teoride aylar değil günler sürüyor; çünkü geri kalan sistemi bozma riski, klasik yapıya göre daha düşük.

Bu, tamamen yeni bir kavram değil — mikroservis mimarisinin kurumsal yazılım tarafına uyarlanmış hali gibi düşünülebilir. Asıl fark, bunun artık büyük ERP vendorlarının resmi ürün stratejisi haline gelmiş olması. Daha önce bu tarz parçalı entegrasyonlar genelde özel geliştirme ya da orta katman (middleware) yazılımlarla, iş ortağının kendi çözümüyle sağlanırdı; şimdi vendorların kendisi bu parçalı yapıyı standart bir ürün özelliği olarak sunmaya başlıyor. Bu fark küçük görünse de, sonucu değiştiriyor: özel geliştirme genelde tek bir işletmeye özgü ve bakımı o işletmenin sorumluluğunda kalırken, vendor'ın sunduğu standart PBC güncellemesi, destek ve sürüm yükseltmesi ürünün kendi yaşam döngüsüne dahil oluyor.

Neden şimdi öne çıkıyor: yapay zeka ve hız baskısı

Gartner'ın Şubat 2026'da yayımladığı bir araştırmaya göre, bulut ERP harcamalarının yapay zeka destekli çözümlere ayrılan payı 2024'te yüzde 14 iken, 2027'ye kadar yüzde 62'ye çıkması bekleniyor. Aynı araştırma, finans fonksiyonuna gömülü yapay zeka asistanlarının 2028'e kadar finansal kapanış (ay/yıl sonu muhasebe kapanışı) sürecini yaklaşık yüzde 30 hızlandırabileceğini öngörüyor.

Bu hızlı değişim, tek blok sistemler için bir sorun yaratıyor: yapay zeka özelliği eklemek, tek parça bir sistemde vendor'ın kendi güncelleme takvimine bağlı kalmak demek. Modüler yapıda ise bir işletme, örneğin sadece talep tahmini yapan bir yapay zeka bileşenini mevcut ERP'nin üzerine ekleyebilir — çekirdek sistemi değiştirmeden. Analistlerin modülerliği öne çıkarmasının asıl gerekçesi bu: değişim hızının, tek bir vendor'ın güncelleme temposundan daha hızlı olması.

Türkiye'de somut bir örnek: pazaryeri ve e-ihracat entegrasyonu

Modülerliğin soyut kalmaması için somut bir örnek Türkiye'den: e-ihracat. Ticaret Bakanlığı, 5 Aralık 2025 tarihli Resmî Gazete'de yayımlanan kararla mikro ihracat (ETGB) limitini 300 kg / 15.000 Euro'dan 600 kg / 30.000 Euro'ya çıkardı. Bu değişiklik, Trendyol, Hepsiburada, N11 gibi yerli pazaryerleri ile Amazon, Etsy gibi uluslararası platformlar üzerinden satış yapan işletmeler için ihracat hacmini büyütme fırsatı yarattı.

Ama bu fırsatı yakalamak ERP tarafında hıza bağlı: her pazaryerinin kendi API'si, kendi sipariş formatı, kendi kargo/gümrük entegrasyonu var. Tek blok bir ERP'de yeni bir pazaryeri eklemek, vendor'ın yerel iş ortağından özel geliştirme talep etmek anlamına gelebilir — haftalar, bazen aylar sürer. Modüler yapıda ise pazaryeri entegrasyonu, çekirdek ERP'nin dışında ayrı bir bileşen olarak eklenir; yeni bir platform açıldığında sadece o bileşen güncellenir, finans ve stok çekirdeği yerinde kalır. İhracat yapan işletmeler için ERP ihtiyaçlarını bu açıdan değerlendirmek, satış kanalı sayısı arttıkça giderek daha kritik hale geliyor.

Büyük vendorların yönü

Büyük ERP vendorları — SAP, Oracle, Microsoft, Odoo gibi — ürün yol haritalarında API-first yaklaşımı ve modüler genişletilebilirliği öne çıkarıyor; her birinin bu yaklaşımı hangi ölçüde ve hangi modüllerde uyguladığı vendor'dan vendor'a farklılaşıyor ve zamanla değişiyor. Spesifik bir modülün modüler mimariye ne kadar uyduğu güncel bilgisi için doğrudan vendor'ın resmi ürün sayfasından ya da iş ortağından teyit alınmalı. SAP S/4HANA Cloud, Oracle NetSuite ve Odoo Enterprise gibi platformların bağımsız incelemelerinde bu yönelim ayrı ayrı ele alınıyor.

Riskler ve dikkat edilmesi gerekenler

Modüler mimari her işletme için otomatik avantaj değil. Birkaç risk kalemi öne çıkıyor:

• Entegrasyon karmaşıklığı: Beş farklı vendor'dan alınan beş bileşeni birbirine bağlamak, kendi başına bir mühendislik işi. Bu işi üstlenecek bir iç ekip ya da güvenilir bir entegrasyon ortağı yoksa, modülerlik avantaj değil yük haline gelir.
• Çoklu vendor bağımlılığı: Tek vendor yerine beş vendor'la ilişki yönetmek demek, beş ayrı sözleşme, beş ayrı destek hattı, beş ayrı fiyat artışı takvimi demek.
• Veri tutarlılığı: Farklı bileşenler arasında veri senkronize kalmazsa (örneğin stok bir sistemde güncel, diğerinde eski), operasyonel hata riski artar.
• Toplam maliyet: Her bileşen ayrı lisanslandığında, toplam maliyet tek paket bir ERP'den daha yüksek çıkabilir; ERP TCO hesaplamasında bu kalemlerin ayrı ayrı görünür olması gerekir.

Tek blok ile modüler ERP karşılaştırması

İşletmeler için pratik uygulama: ne zaman anlamlı

Modüler mimari, özellikle çok kanallı satış yapan, sık pazaryeri/entegrasyon değişikliği yaşayan ya da yapay zeka destekli yeni araçları hızlı denemek isteyen işletmeler için gerçek bir avantaj sunuyor. Buna karşılık, tek bir üretim hattı ya da istikrarlı, az değişen bir sürece sahip işletme için klasik tek paket bir ERP hâlâ daha az operasyonel yük anlamına gelebilir — entegrasyon karmaşıklığını yönetecek ek bir ekip gerektirmeden.

Uygulamada birçok işletme zaten tam anlamıyla ne saf tek blok ne de tam modüler bir yapıda çalışıyor; ara bir noktada duruyorlar. Çekirdek finans ve muhasebe tek bir ERP'de tutulurken, pazaryeri entegrasyonu, kargo takibi ya da CRM gibi hızlı değişen alanlar ayrı, API bağlantılı araçlarla yönetiliyor. Bu melez (hybrid) yaklaşım, modülerliğin tüm faydasını almadan, tüm yönetim yükünü de üstlenmeden bir orta yol sunuyor — özellikle mevcut bir ERP'yi baştan değiştirmeden aşamalı ilerlemek isteyen işletmeler için gerçekçi bir başlangıç noktası.

Karar, "hangisi daha modern" sorusundan çok, "işletmenin değişim hızı ile ERP'nin değişim hızı ne kadar örtüşmeli" sorusuna bağlı. Bulut/SaaS ERP karşılaştırmamızda bu tercihin kurulum modeliyle ilişkisini ayrıca ele aldık; yapay zeka ajanlarının ERP'deki gerçek karşılığını ise ayrı bir yazıda saha örnekleriyle inceledik.

Kendi işletme profiline göre modüler mi tek paket mi daha uygun olduğunu netleştirmek isteyen kurumlar için uygun ERP bul aracı bir başlangıç noktası olabilir; daha detaylı bir değerlendirme için bağımsız bir keşif görüşmesi talep edilebilir.

Kaynaklar

• Gartner Predicts Embedded AI in Cloud ERP Applications will Drive a 30% Faster Financial Close by 2028
• Advanced ERPs could cut financial close times by 30%, Gartner says — CFO Dive
• 5 Aralık 2025 tarih ve 10664 sayılı Resmî Gazete — mikro ihracat (ETGB) limit artışı kararı
• What are packaged business capabilities (PBCs)? — Talon.One