← Tüm Yazılar
25 Temmuz 2026

AI-Native ERP: Mimari Bir Devrim mi, Yoksa Yeni Bir Pazarlama Etiketi mi?

Kurumsal yazılımın en muhafazakâr köşesinde neler oluyor ve Türkiye bu resmin neresinde duruyor?

Yavuz Selim Kılınç

ERP, kurumsal yazılımın belki de en az heyecan verici, en fazla vazgeçilmez köşesidir. Kırk yıldır aynı temel mantıkla çalışır: formlar veri toplar, iş akışları onayları yönlendirir, toplu (batch) işler mutabakat yapar ve kapatır, raporlama panelleri sonucu özetler. Bu tarif o kadar köklüdür ki, sektörün kendisi bile onu sorgulamayı bırakmıştı — ta ki üretken yapay zekânın, özellikle de “ajan” (agent) olarak adlandırılan otonom yürütme yeteneğinin sahneye çıkmasına kadar.

2026 itibarıyla dünyada kurumsal yazılım dünyasında yeni bir sınıflandırma tartışması yaşanıyor: “AI-native ERP”. Terim o kadar sık ve o kadar gevşek kullanılıyor ki, ne anlama geldiği neredeyse kullanan kişiye göre değişiyor. Bu yazının amacı, kavramı biraz daha disiplinli bir çerçeveye oturtmak; küresel oyuncuların, meydan okuyan girişimlerin, göz ardı edilen risklerin ve son olarak Türkiye’nin bu tabloda nerede durduğunun izini sürmek.

Peki bu tartışma neden tam olarak şimdi patlak verdi, on yıl önce değil? Üç teknik gelişme aynı anda olgunlaştı.

Birincisi, bir yapay zekâ modelini çalıştırmanın maliyeti — yani her soru-cevap veya işlem başına ödenen hesaplama bedeli, teknik adıyla “çıkarım (inference) maliyeti” — son yıllarda sert biçimde düştü. Bunun pratik sonucu şu: bir ERP ajanının tek bir işlemi (örneğin bir faturayı) doğru işleyebilmek için modele arka arkaya birçok kez danışması artık ekonomik olarak sürdürülebilir hale geldi; birkaç yıl önce bu, her işlem başına çok yüksek bir maliyet demekti.

İkincisi, modellerin bir seferde işleyebildiği bilgi miktarı (bağlam penceresi) genişledi ve “araç çağırma” (tool calling) dediğimiz yetenek standartlaştı — yani bir yapay zekâ modeli artık yalnızca metin üretmiyor, ihtiyaç duyduğunda gerçek sistemleri (bir veritabanını, bir API’yi, bir ödeme ağ geçidini) doğrudan çağırıp veri okuyabiliyor ve işlem yaptırabiliyor. Bunu farklı yazılımlar arasında güvenli ve tutarlı şekilde yapabilmesi, Model Context Protocol (MCP) gibi ortak, paylaşılan kuralların olgunlaşmasıyla mümkün oldu.

Üçüncüsü — ve belki en az konuşulanı — kurumsal AI yönetişimi kendi olgunluk eğrisinde ilerledi. Beş yıl önce “yapay zekâya muhasebe kaydı yazdırmak” teknik olarak değil, kurumsal risk iştahı açısından bile düşünülemezdi; bugün görevler ayrılığını koruyan kademeli otonomi modelleri sayesinde bu tartışma en azından masaya oturabiliyor. AI-native ERP’yi mümkün kılan tek bir buluş değil, bu üç eğrinin aynı anda kesişmesi.

Bir Tanım Sorunu: “AI-Native” Ne Zaman Gerçek, Ne Zaman Pazarlama?

Piyasada üç farklı iddia iç içe geçmiş durumda: “AI ERP”, “AI-powered ERP” ve “AI-native ERP”. Finans yazılımları üzerine yayın yapan LiveFlow, öğretici bir ayrım ortaya koyuyor: AI-native bir sistem, yapay zekânın platformun çekirdek mimarisine gömülü olduğu, sonradan eklenen bir özellik güncellemesi olmadığı bir sistemdir. Buna karşılık “AI-powered insights”, “intelligent automation” gibi pazarlama etiketlerinin büyük bölümü aslında büyük bir dil modelinin bir gösterge paneline bağlandığı, temelde değişmemiş bir veritabanını tarif eder — bu, AI ile geliştirilmiş bir sistemdir, AI-native değil.

Bu tartışmanın etrafında tek bir kelime çifti değil, epeyce kalabalık bir terminoloji bulutu dolaşıyor: AI-native’in yanında AI-embedded (gömülü AI), AI-augmented, AI-enhanced, AI-enabled, hatta ERPClaw’ın kendi rakiplerini tarif etmek için kullandığı kasıtlı olarak küçümseyici bir terim olan “AI-decorated” bile var. Bu terimleri kabaca iki eksende düşünmek işe yarıyor.

Birincisi derinlik ekseni: en yüzeyde AI-decorated/AI-added (2015 yazılımına bir sohbet kutusu eklemek), ortada AI-powered/AI-enhanced, daha derinde belirsiz sınırlı bir kategori olarak AI-embedded, en derinde ise mimarinin kendisi olan AI-native.

İkincisi niyet ekseni: bazı terimler ürünün nasıl inşa edildiğini tarif ediyor (AI-native, AI-first), bazıları ise yalnızca işlevsel sonucu tarif ediyor (AI-augmented, AI-embedded). Bu terimlerin hiçbiri bir ISO standardına bağlı değil — aynı ürün bir pazarlama sayfasında “AI-native”, bir teknik dokümanında “AI-embedded” olarak anılabiliyor. Okuyucunun kelimeye değil, altındaki mimari gerçekliğe bakması gerekiyor.

Açık kaynaklı bir ERP girişimi olan ERPClaw, bu ayrımı beş maddelik bir listeye döküyor: bir sistemin gerçekten AI-native sayılabilmesi için kullanıcı arayüzünün (menü yerine sohbet), iş akışının, veri modelinin, otomasyonun ve yönetişimin hepsinin “ajan öncelikli” olması gerektiğini savunuyorlar. Aynı şirket, kendini de dahil ederek beş ERP’yi “gerçekten ajanlar etrafında yeniden inşa edilmiş” diye sıralıyor: ERPClaw, Rillet, Doss, Campfire, DualEntry. Burada bir çekince koymak lazım: bu listeyi öneren şirket, aynı zamanda bu kategoride rakip bir ürün satıyor. Karşımızda hem teknik olarak isabetli bir ayrım hem de ticari bir konumlandırma argümanı aynı anda duruyor — objektif bir hakem kararı değil, tartışmayı zenginleştiren bir bakış açısı olarak okunmalı.

Muhasebe odaklı AI-native girişimi Rillet ise işi daha basit bir soruya indirgiyor: bir ERP’nin gerçekten AI-native olup olmadığını anlamak için “kapanış (close) bugün mü, yoksa üç hafta eski mi?” diye sormak yeterli — yapay zekâ canlı veri üzerinde gerçekten işlem yapabiliyor mu, yoksa yalnızca eski bir anlık görüntüyü mü analiz ediyor? Danışmanlık dünyasından gelen ve bence en zarif olan test ise şu: AI’yi sistemden çıkarırsanız iş modeli çöker mi? Cevap evetse, ortada gerçekten AI-native bir sistem var demektir; sistem sadece verimlilik kaybederek çalışmaya devam ediyorsa, o “AI-adopted” ya da “AI-added” bir sistemdir. AI-native olmak, üstelik, şirketin ne zaman kurulduğuyla ilgili değil — mevcut, bulut-native bir ürün de zamanla yeniden tasarlanarak AI-native hale gelebilir; asıl mesele mimarinin gerçekten yeniden tasarlanıp tasarlanmadığı. Bunun biraz daha ölçülebilir bir versiyonu da var: bir sektör analizine göre, AI-enhanced bir üründe yapay zekâ bileşenleri toplam altyapı bütçesinin yüzde 8–15’ini oluştururken, gerçek bir AI-native üründe bu oran yüzde 40–70’e çıkıyor — çünkü AI artık ürüne sonradan eklenmiş bir maliyet kalemi değil, maliyet yapısının merkezinde duruyor. . Bu “eklenti maliyeti” sorunu soyut değil: Panorama Consulting’in 2026 ERP Raporu’na göre, bütçesini aşan kuruluşların yüzde 54,9’unun (en yaygın neden) gerekçesi, projeye sonradan eklenmesi gereken ek teknoloji ihtiyacı — çoğu zaman, seçilen ERP’nin yerleşik (native) raporlama veya AI yeteneklerinin kurumsal ölçekte yetmemesi yüzünden.

McKinsey’nin yaklaşımı ise daha mimari: ERP’nin zamanla “headless” bir yapıya evrilmesi — kullanıcı etkileşiminin ekran ve formlardan uzaklaşıp AI ajanlarının aracılık ettiği bir modele kayması, ama iş kuralları, veri tutarlılığı ve denetlenebilirliğin korunması. Burada eski bir örneğe atıf yapılıyor: robotik süreç otomasyonu (RPA) da bir zamanlar eski sistemler üzerine bindirilip kenarda hızlı kazanımlar sağlamıştı, ama çekirdekteki yapısal veri ve süreç sorunlarını asla çözemedi. Agentic AI’nin de benzer bir tavana çarpma riski taşıdığı değerlendiriliyor.

“AI-native” bugün itibarıyla endüstri çapında tarafsız bir sertifikasyon değil. Ama okuyucu kendi başına dört soru sorabilir: Yapay zekâ, verilere yalnızca okuma erişimiyle mi, yoksa yazma ve işlem yapma yetkisiyle mi çalışıyor? Sistem sıfırdan mı tasarlandı, yoksa mevcut bir veritabanı şemasının üzerine mi bindirildi? Konuşarak, uçtan uca bir iş süreci gerçekten tamamlanabiliyor mu, yoksa sohbet arayüzü yalnızca bir özet katmanı mı? Ve son olarak: yapay zekâ bugün çekilse, şirketin iş modeli çöker mi, yoksa sadece biraz yavaşlar mı?

Bütün bu tartışmayı kendi cümlelerimle özetlersem: AI-native ERP, yapay zekânın bir özellik değil bir organ olduğu sistemdir — çıkarılırsa sistem ölür, çünkü karar alma, veri yazma ve süreç yürütme yetkisi baştan itibaren o organa devredilmiştir. Bunun dışındaki her şey — ne kadar etkileyici görünürse görünsün — bir eklenti, iyi bir eklenti bile olsa, hâlâ bir eklentidir.

Mimarinin Gerçek Ağırlığı Nerede?

Tartışmanın soyut kaldığı yerde, somut mühendislik gerçeğine bakmakta fayda var. SAP, Oracle ve Microsoft’un yerleşik ERP’leri — hangi mimari felsefeyi izlerse izlesin — hepsi onlarca yıllık bir kod tabanı üzerinde büyümüş ve bugün on binlerce veritabanı tablosuna sahip. Bu, satıcıların kendi teknik dokümantasyonlarından ve danışmanlık camiasının yıllardır kullandığı standart araçlardan (SAP’de SE11/SE16, Oracle’da eTRM gibi) doğrulanabilen bir gerçek. IFS gibi görece daha ufak oyuncularda bile, kendi teknik dokümantasyonunda “binlerce entity modeli”nden bahsediyor — sorun tek bir satıcıya özgü değil, otuz-kırk yıllık bir kod tabanının doğal sonucu.

Her satıcı bu şişkinliğin farkında ve “AI-native” tartışması başlamadan çok önce, kendi yöntemleriyle sadeleştirmeye gitti: SAP, HANA’nın in-memory gücüyle önceden hesaplanmış toplam tabloları kaldırıp bir finansal kaydın dokunduğu tablo sayısını radikal biçimde azalttı; Oracle, Fusion Cloud’da modüller arası “unifed data model (birleşik veri modeli)” ile eşleme tablolarına duyulan ihtiyacı azalttı (EBS’ten Fusion’a geçen kurumların özelleştirmelerinin %30–50’si bu sayede standart işlevsellikle karşılanıyor); Microsoft ise D365’te temel/özet/ara tablo katmanlarını resmi bir mimari olarak korudu. Üçü de aynı sorunu farklı araçlarla çözüm aramış — AI-native mimarinin iddiası, bu sadeleştirmeyi çok daha radikal bir noktaya taşıması.

Tablo sayısının yanına eklenen birkaç pratik gösterge daha var:

Hepsinin ortak paydası şu: asıl soru “kaç tablo var” değil, “bu sistemi değiştirmek ne kadar zor” — AI-native tartışmasında da tam olarak bu soruluyor.

AI-native girişimler kendi tablo sayılarını açıklamıyor — Rillet, Campfire, DualEntry gibi kapalı kaynaklı ürünler şemayı ticari sır sayıyor. Açık kaynaklı ERPClaw ise farklı bir sinyal veriyor: veritabanından bağımsız, SQLite veya PostgreSQL ile çalışabiliyor; “aynı kod, aynı eylemler — veritabanı motoru bir bağlantı dizesi değişikliğiyle değişir” diyor. Bu, karmaşıklığın artık şemada değil, ajanın çağırdığı eylemler katmanında toplandığını ima ediyor. Ama bir tuzağa da dikkat: “az tablo = iyi mimari” basit bir kural değil; aşırı normalize edilmiş şemalar karmaşıklığı yok etmez, başka yere (sorgu mantığına, koda) taşır. “Yeni nesil bir AI-native ERP’de kaç tablo olur” sorusuna bugün kesin bir cevap veremiyoruz; bu, ekosistemin şeffaflaşmasını bekleyen bir alan.

Küresel Devler Neden “AI-Native” Demiyor?

SAP, Oracle ve Microsoft gibi yerleşik ERP devlerinin hiçbiri kendini resmî olarak “AI-native” diye tanımlamıyor — kelime seçimi kendi başına bir sinyal. SAP, Joule’u “bir kurumsal AI asistanı” olarak konumlandırıyor. Oracle, çözümünü “Fusion Applications için AI Ajanları” diye adlandırıyor. Microsoft ise Dynamics 365’i “içinde Copilot olan” bir platform olarak sunuyor.

Bu, tesadüf değil bilinçli bir strateji. Bu devlerin değer önerisi zaten güvenilirlik, derinlik ve yönetişim üzerine kurulu: onlarca yıllık, üretimde defalarca test edilmiş, çok kiracılı, denetim izi bırakan bir altyapı. Bu altyapının üzerine bir AI katmanı eklemek savunulabilir, rasyonel bir mimari tercih — sıfırdan AI’yı eylem katmanı olarak kuran sistemlerden yapısal olarak farklı bir kategoridir. Sorun, bu devlerin kendilerini “AI-native” diye pazarlamaya kalkıştığı noktada değil; sorun, bu farkın kurumsal alıcılar tarafından yeterince anlaşılıp anlaşılmadığında ortaya çıkıyor.

Bir CIO koltuğundan bakınca bu tercih aslında bir risk-iştahı meselesine dönüşüyor: yerleşik satıcı, “biz devrimci değiliz ama seni batırmayız” diyor; meydan okuyan girişim ise “biz daha hızlıyız ama henüz seni her koşulda taşıyabileceğimizi kanıtlamadık” diyor. İkisi de dürüst bir konumlandırma — asıl hata, birini diğerinin diliyle değerlendirmek.

Ama daha sert bir soru sormak gerekiyor: bu üç dev, isterse gerçekten AI-native olabilir mi? Kanaatimce hayır — en azından “sıfırdan yeniden yazma” anlamında değil. Yukarıda tartıştığım on binlerce tablolık şema, otuz-kırk yıllık iş mantığı ve binlerce kurumsal entegrasyon, bir gecede atılıp yeniden inşa edilemeyecek kadar büyük bir sermaye. SAP’nin HANA’yla yaptığı in-memory sadeleştirme ve “clean core” stratejisi, aslında bunun dolaylı bir itirafı: tam yeniden yazım yerine, çekirdeği aşamalı olarak sadeleştirip üzerine “headless” bir ajan katmanı bindirmek. Bu, McKinsey’nin de işaret ettiği yol — ve muhtemelen üç satıcı için de gerçekçi olan tek yol. Sonuç, saf anlamda AI-native değil, ama kurumsal pazarın büyük çoğunluğu için yeterince yakın bir hibrit olabilir.

Meydan Okuyucular: Sıfırdan İnşa Etmenin Bedeli ve Getirisi

Son iki yılda finans ve muhasebe odaklı bir grup girişim — Rillet, Campfire, DualEntry ve birkaç benzeri — sıfırdan, yapay zekâyı bir eylem katmanı olarak tasarlayan sistemler inşa etti. DualEntry, 2025 yılının Ekim ayında Lightspeed Venture Partners ve Khosla Ventures liderliğinde 90 milyon dolarlık bir Seri A turu tamamladı. Rillet ise a16z ve ICONIQ liderliğinde 70 milyon dolarlık bir Seri B turu aldı ve kendini NetSuite veya Intacct’ten göç etmek isteyen, çok varlıklı muhasebe ihtiyacı olan şirketlere konumlandırıyor. Bunların yanında ERPClaw gibi açık kaynaklı bir alternatif de var; kendini “tek açık kaynaklı AI-native ERP” olarak tanımlıyor ve GPL v3 lisansı, birkaç dakikalık kurulum vaadiyle NetSuite, Odoo ve ERPNext’e meydan okuyor.

Bu girişimlerin ortak argümanı basit ve etkileyici: yapay zekâ, 1990’ların veritabanı şemasının üzerine bindirildiğinde o şemanın sınırlarıyla kısıtlı kalır. Sıfırdan inşa edilen bir platform, veriyi baştan makine öğrenmesi için yapılandırabilir — sürekli mutabakat, gerçek zamanlı anomali tespiti ve otonom kapanış iş akışları gibi yetenekler, eskiye AI eklenerek elde edilmesi mimari olarak imkânsız olan şeylerdir.

Madalyonun öbür yüzü de var. Yerleşik ERP’ler, onlarca yıllık, üretimde test edilmiş binlerce entegrasyona sahip: bankacılık, bordro, vergi motorları, satın alma sistemleri. Startup’ların entegrasyon ekosistemi hâlâ olgunlaşma aşamasında. Mimari üstünlük tek başına yeterli bir satış argümanı değil; entegrasyon derinliği ve kurumsal güven de aynı denklemin parçası. Bu, kurumsal bir CIO’nun karşı karşıya kaldığı klasik ikilem: daha temiz bir mimari mi, yoksa daha derin bir ekosistem mi?

Bu ikilemin altında, kanaatimce daha az konuşulan ama daha ciddi bir tanesi yatıyor: muhasebe, doğası gereği olasılıksal değil deterministik bir disiplindir. Aynı girdi her seferinde aynı çıktıyı üretmeli ve bu çıktının nasıl üretildiği bağımsız bir denetçi tarafından adım adım yeniden kurulabilmelidir. Büyük dil modelleri ise olasılıksal çalışır — aynı istemin farklı zamanlarda hafifçe farklı bir sonuç üretmesi, halüsinasyon riski ya da bir ajanın “mantıklı görünen ama yanlış” bir muhasebe kaydı önermesi, klasik ERP dünyasının alışık olmadığı bir risk sınıfıdır. “Ajan bu işlemi otomatik yapsın” cümlesi kulağa çekici gelse de, görevler ayrılığı (segregation of duties) ilkesini kimin uygulayacağı sorusunu beraberinde getiriyor: bir ajan hem faturayı okuyup hem ödemeyi onaylıyorsa, klasik iç kontrol çerçevesi buna nasıl karşılık verecek? Düzenleyiciler ve dış denetçiler için asıl mesele hız değil, açıklanabilirlik — bir kaydın neden o şekilde işlendiğinin insan tarafından okunabilir, savunulabilir bir mantıkla geri izlenebilmesi. Bu, AI-native ERP girişimlerinin bugüne kadar en az konuştuğu, ama kurumsal satışta en sık karşılaşacakları soru olacak.

Kurumsal mühendislik olgunluğu tarafında da benzer bir gerilim var. Carnegie Mellon Üniversitesi Yazılım Mühendisliği Enstitüsü ile Accenture’ın birlikte yayınladığı bir olgunluk modeli, şirketlerin AI benimsemesini beş seviyede sınıflandırıyor: deneysel, uygulanmış, hizalanmış, ölçeklenmiş, geleceğe hazır. Modelin arkasındaki isimlerden biri, sektörün yıllardır taşıdığı bir yanılgıya parmak basıyor: disiplinin otomasyonla kendiliğinden ortadan kalkacağı beklentisi. Oysa kalıcı bir AI başarısı hâlâ eski usul mühendislik disiplinine, yönetişime ve operasyonel titizliğe bağlı — AI’nin kendisi bu disiplini ikame etmiyor. Daha sert bir dille söyleyen başka bir değerlendirme de var: “AI-native dönüşüm” diye pazarlanan pek çok projenin kaputunun altına bakıldığında, elle yazılmış kırılgan betikler, manuel veri çekme adımları ve birinin kendi bilgisayarında çalışan modellerle karşılaşılıyor. Aynı değerlendirme çarpıcı bir gözlem daha ekliyor: kuruluşların önemli bir kısmı kendini “ölçeklenme” aşamasında sanıyor, ama aslında sonsuz bir deneme-yanılma döngüsünde sıkışmış durumda — yani AI başarısızlıklarının çoğu modelin kendisinden değil, veri kalitesinden, yönetişim boşluğundan ve operasyon modelinden kaynaklanıyor. Bu nedenle araştırmada da belirtildiği gibi AI projelerinin %95′ inden somut fayda sağlanamıyor.

Bunun AI-native ERP tartışmasına dönüşü basit ama önemli: bir yazılımın “AI-native” olup olmadığını sormak tek başına yeterli değil — onu satın alan, kuran ya da inşa eden kurumun kendisinin de aynı olgunluk sınavından geçip geçmediğini sormak gerekiyor. En temiz mimariye sahip bir AI-native ERP bile, onu devreye alan kurum hâlâ elle yamalı entegrasyonlarla ve gölge Excel tablolarıyla çalışıyorsa, kâğıt üzerinde kalan bir vaat olmaktan öteye geçmez. Mimari kadar, o mimariyi taşıyan organizasyonun olgunluğu da sınanmalı.

Genel-Amaçlı mı, Sektöre Özel mi Olmalı?

Bu, tartışmanın belki de en az netleşmiş cephesi. Verilere bakıldığında ibre açıkça sektöre özel (vertical) yaklaşıma doğru eğiliyor. Bir sektör analizine göre, Gartner’ın öngörüsü, 2027’ye kadar kurumların kullandığı üretken yapay zekâ modellerinin yarıdan fazlasının belirli bir sektöre veya iş fonksiyonuna özel olacağını öngörüyor — 2023’te bu oran yüzde birin altındaydı. Bir başka sektör analizinde, McKinsey verilerine atfen aktarılan bir rakama göre, sektöre özel çözümler kullanan şirketler genel-amaçlı büyük dil modellerine kıyasla 2,3 kat daha yüksek yatırım getirisi görüyor; bu dağıtımların yüzde 71’i altı ay sonra hâlâ değer üretmeye devam ederken, bu oran yatay çözümlerde yüzde 32’ye düşüyor.

Bu tartışmayı doğrudan ERP’ye taşımadan önce bir ayrım yapmak gerekiyor. Bir ERP’nin çekirdek finansal mantığı — genel muhasebe defteri, çift kayıt, mutabakat, konsolidasyon — doğası gereği sektörden bağımsızdır ve yatay kalabilir; Rillet, Campfire ve DualEntry tam da bu katmanda rekabet ediyor. Sektöre özgü operasyonel katman ise — üretim planlama, inşaat hakediş yönetimi, sağlık uyumluluğu, perakende stok optimizasyonu — vertical bir yaklaşım gerektiriyor; inşaat sektörüne özelleşmiş Graneet gibi girişimler bu ayrımı somutlaştırıyor.

Kanaatimce doğru soru “genel mi, vertical mi” ikilemi değil; “hangi katmanda genel, hangi katmanda vertical olunmalı” sorusudur. Başarılı bir AI-native ERP’nin, yatay bir finansal çekirdek üzerine eklenebilir, sektöre özel modüller inşa etmesi en makul mimari yol gibi görünüyor. Bu, yıllardır ERP ve dijital dönüşüm projelerinde gözlemlediğim bir örüntüyle de örtüşüyor: kurumlar genellikle “bize özel” bir sistem isterler, ama gerçekte istedikleri şey, kendi sektörlerinin diliyle konuşan, sektör dışı işlevlerde ise standart ve güvenilir kalan bir platformdur.

Bulut, Tek Seçenek mi?

Kısa cevap hayır, ama bugün için baskın seçenek evet. İncelenen neredeyse tüm AI-native ERP girişimleri bulut-native olarak inşa ediliyor, çünkü büyük dil modeli çıkarımı ve çok kiracılı ölçeklenebilirlik bulutta çok daha kolay yönetilebiliyor. Panorama Consulting’in 2026 ERP Raporu’na göre (170 kuruluşluk bir örneklemde), ERP projelerinin yüzde 73,5’i bulutta (hosted, managed servis veya SaaS), yalnızca yüzde 26,5’i on-premise olarak yürütülüyor; bulut içinde de dağıtımın yüzde 70,4’ü doğrudan SaaS, yüzde 29,6’sı hosted/managed servis şeklinde.

Buna paralel olarak “egemen yapay zekâ” (sovereign AI) hareketi güçleniyor. Gartner’ın “Predicts 2026: AI Sovereignty” raporuna göre, 2030’a kadar Avrupa ve Orta Doğu’daki işletmelerin yüzde 75’inden fazlasının jeopolitik riski azaltmak amacıyla sanal iş yüklerini kendi topraklarına geri taşıyacağı öngörülüyor — bu oran bugün yüzde beşin altında. Bir örnek olarak aktarılıyor: Fransa ve Almanya’nın, kamu yönetimi için Mistral AI ile SAP arasında bir ortaklıkla, 2026’da devreye girmesi planlanan, tamamen izole olarak (air-gapped) çalışabilen egemen bir AI-native ERP geliştirdiği iddia ediliyor. Bu iddianın kendisi bir varsayımı sarsıyor: “AI-native ERP mutlaka bulutta olur” düşüncesi artık tartışmasız bir gerçek değil

Bunun nedeni açık: veri egemenliği düzenlemeleri, ihracat kontrolüne tabi mühendislik verileri, hastane hasta kayıtları, savunma sanayii gibi alanlarda her komutun ağ sınırını aşması kabul edilebilir bir risk değil. Donanım maliyeti de artık bu tercihin önünde daha küçük bir engel; yeni nesil GPU mimarileri kurumsal düzeyde performansı çok daha erişilebilir bir yatırımla mümkün kılıyor.

Kısaca ayırırsak: tüketici ve orta-ölçek pazarında (Rillet, Campfire’ın hedef kitlesi) bulut fiilen tek seçenek gibi görünürken; kamu, savunma, sağlık ve finans gibi yüksek regülasyonlu alanlarda hibrit veya tam on-premise AI-native mimariler somut olarak gelişiyor ve büyüyor.

Türkiye Tablosu: Umut Verici Ama Henüz Cesur Değil

Bu başlıkta üzerinde çalışılabilecek doğrudan veri, küresel tabloya kıyasla daha sınırlı — bulguları temkinli aktarmak gerekiyor.

Türkiye’nin genel yapay zekâ girişimciliği ekosistemi güçlü bir ivme yakalamış durumda. Türkiye Yapay Zeka İnisiyatifi’nin çeyreklik olarak güncellediği girişim haritasına göre, kayıtlı yapay zekâ girişimi sayısı 2025 başında 379’dan, 2026’nın ilk çeyreğinde 482’ye yükseldi. Yeni eklenen girişimlerin üçte biri “Agentic AI” — otonom karar alıp eylem yapabilen sistemler — kategorisinde konumlanıyor. Bu, ekosistemin “asistanlık” evresinden “otonom iş bitirme” evresine geçtiğinin bir işareti olarak okunabilir.

“AI-native ERP” özelinde ise, Rillet ya da Campfire ölçeğinde, sıfırdan inşa edilmiş, ciddi risk sermayesi çekmiş, iddialı bir Türk girişimine bu araştırmada rastlanmadı. Bunun yerine gözlemlenen tablo şöyle: Türkiye’nin yerleşik ERP oyuncuları — Logo, Netsis, Mikro, Uyumsoft, DİA gibi — kademeli bir “AI-decorated” stratejisi izliyor: mevcut ürünlerine OCR tabanlı fatura okuma, otomatik muhasebe fişi oluşturma, talep tahmini, anomali tespiti gibi yapay zekâ özellikleri ekliyorlar. Hiçbiri kendini “AI-native” olarak konumlandırmıyor; hepsi “yapay zekâ ile entegre” ya da “destekli” dilini tercih ediyor.

Türkiye’ye özgü ilginç bir ikinci model daha var: mevcut ERP’lerin üzerine, onları değiştirmeden bir yapay zekâ ajan katmanı ekleyen küçük girişimler türüyor. Bu girişimler, faturayı okuyup kayda hazır bir özet, tahsilat hatırlatma taslağı veya e-defter ön-kontrol listesi üretiyor — ama kritik bir tasarım tercihiyle: ajanın ERP’ye doğrudan yazma yetkisi yok, kaydı nihai olarak insan geçiriyor. Bu “hazırlayan-rol” (preparer-role) modeli, yukarıda değindiğim görevler ayrılığı endişesine tam da doğru cevabı veren, olgun bir yönetişim refleksi: Türkiye’deki AI-ERP entegrasyonu, “yapay zekâ karar alsın ve yazsın” yerine “yapay zekâ hazırlasın, insan onaylasın” mantığını benimsiyor.

Asıl dikkate değer nokta, bu temkinliliğin kaza sonucu değil, muhtemelen düzenleyici ortamın ve muhasebe kültürünün doğal bir sonucu olması. Türkiye’de mali müşavirlik ve YMM denetiminin güçlü olduğu bir sistemde, “ajan imzayı atsın” fikri zaten kültürel olarak yabancı — dolayısıyla Türk girişimlerinin bugün tesadüfen benimsediği “hazırlayan-rol” yaklaşımı, yarın küresel ölçekte satılabilecek bir ürün felsefesine dönüşebilir. Buna, Türkiye pazarının KOBİ ağırlıklı olması, Logo/Netsis/Mikro üçlüsünün onlarca yıllık pazar hâkimiyeti ve geniş bayi ağı, risk sermayesi hacminin ABD ve Avrupa’ya kıyasla çok daha sınırlı olması gibi yapısal faktörler de ekleniyor — sıfırdan bir ERP inşa etmenin sermaye yoğunluğu, Türkiye’deki tipik erken aşama yatırım büyüklüğüyle bugün için örtüşmüyor. Bunların hepsi makul açıklayıcı faktörler, ama bu bir gözlem ve çıkarımdır, doğrulanmış bir pazar analizi değildir. Yine de sonuç aynı yere çıkıyor: Türkiye’nin bugünkü çekingenliği, doğru konumlandırılırsa yarının farklılaştırıcı özelliği olabilir.

Bir İş Modeli Önerisi ve Üç Gruba Mesaj

Yukarıdaki tabloyu bir araya getirdiğimde, Türkiye için hem bir boşluk hem de somut bir fırsat görüyorum. Önerim: “Yatay çekirdek + dikey ihracat modülü” mimarisiyle kurgulanmış, sıfırdan AI-native, KOBİ ve orta ölçekli ihracatçı işletmelere odaklanan bir ERP girişimi.

İşin temeli, yatay ve sağlam bir finansal çekirdek olmalı: genel muhasebe defteri, e-fatura/e-arşiv/e-defter entegrasyonu, banka mutabakatı ve KDV/vergi uyumu — hepsi AI’nin gerçekten yazma yetkisiyle çalıştığı, ajan öncelikli bir mimaride kurulmalı. Türkiye’nin GİB e-dönüşüm altyapısı burada gerçek bir avantaj sunuyor, çünkü dünyanın pek çok pazarına kıyasla zaten yapılandırılmış XML veri sağlıyor — bu, OCR’nin ötesine geçip doğrudan veri okumaya imkân tanır. Yukarıdaki tartışmanın ışığında, bu çekirdeğin yerleşik devlerin onlarca yıllık tablo şişkinliğinden değil, ihtiyaç kadar normalize edilmiş, ajanın rahatça gezinebileceği bir şemadan başlaması gerekiyor.

Bu çekirdeğin üzerine, genel-amaçlı bir ERP ile herkese hitap etmeye çalışmak yerine, Türkiye’nin güçlü olduğu bir sektörden — tekstil ve hazır giyim, otomotiv yan sanayii veya gıda ihracatı gibi — başlayan sektöre özel bir dikey inşa edilmeli. Bu sektörlerin ortak özelliği yüksek işlem hacmi, döviz kuru riski, çok kademeli tedarikçi ağı ve uluslararası uyumluluk yükü (sürdürülebilirlik raporlaması, CBAM gibi sınır ötesi karbon düzenlemeleri) — tam olarak vertical AI’nin ROI avantajının en görünür olduğu zemin.

Yönetişim tarafında, Türkiye’deki mevcut ajan katmanı girişimlerinin gösterdiği temkinli “hazırlayan-rol” refleksi bir zayıflık değil, bir varlık olarak kullanılmalı: ürün, düşük riskli işlemlerde (tekrarlayan tedarikçi faturaları gibi) otonom yazma yetkisine kademeli olarak geçerken, yüksek riskli işlemlerde (büyük tutarlı ödemeler, yeni tedarikçi kayıtları gibi) insan onayını zorunlu tutmalı — denetlenebilir bir “kademeli otonomi” modeli, hem düzenleyicilerin hem kurumsal alıcıların güvenini kazanmanın en gerçekçi yolu. Buna, büyük ölçekli ihracatçıların ve kamuya yakın kurumların veri egemenliği hassasiyetini gözeten, gerektiğinde on-premise veya özel bulutta çalışabilen bir hibrit dağıtım seçeneği eklenmeli — bu, yalnızca büyük regüle sektörler için değil, “verimiz yurt dışına çıkmasın” hassasiyeti taşıyan pek çok Türk KOBİ’si için de gerçek bir satış argümanı olabilir. Gelir modeli açısından, kullanıcı başına lisans yerine işlem/otomatikleştirilen görev başına fiyatlandırma (a16z’nin “SaaS koltuk satmak yerine tamamlanmış iş satmak” tezine paralel) düşünülebilir — bu hem KOBİ’ler için giriş bariyerini düşürür hem de büyüdükçe gelirin şirketle birlikte büyümesini sağlar.

Bu tabloyu bir politika ve ekosistem perspektifinden değerlendirdiğimde, üç farklı okuyucu grubuna söyleyecek sözüm var. Girişimciler ve yatırımcılar için mesaj yukarıdaki önerinin özeti aslında: mevcut ERP’lerin üzerine ajan katmanı eklemekle yetinmek yerine, bir dikeyde sıfırdan AI-native bir çekirdek inşa etmeye cesaret eden bir girişime ihtiyaç var — “hazırlayan-rol” temkinliliği doğru bir başlangıçtı, ama sonsuza dek orada kalmak geride kalma riski taşıyor. Kurumsal alıcılar — CIO ve CFO’lar — için ise “AI-native” etiketine değil, somut sorulara odaklanmak gerekiyor; bu yazıda dağılmış tüm o soruları toparlayınca ortaya pratik bir kontrol listesi çıkıyor:

Kamu politikası ve ekosistem yapıcıları içinse şunu hatırlatmak isterim: Türkiye’nin GİB e-dönüşüm altyapısı zaten dünya standartlarının önünde, yapılandırılmış veri sunan bir temel — bu, yerli bir AI-native ERP girişiminin küresel rakiplerine karşı gerçek bir başlangıç avantajı olabilir. Bu avantajın bir girişimcilik fırsatına dönüşmesi için, hem TÜBİTAK/KOSGEB gibi destek mekanizmalarının hem de özel sermayenin, çok sayıda küçük ve sığ pilot yerine, tek bir dikeyde derinlemesine, sabırlı ve yeterince büyük ölçekli bir yatırıma razı olması gerekiyor.

ERP dünyası, kırk yıllık sessizliğinin ardından gerçek bir mimari tartışmanın ortasında. AI-native ERP tartışması sonunda teknoloji yarışından çok, güven mimarisi yarışına dönüşecek. Kazanan, en fazla yapay zekâ kullanan değil; yapay zekâyı denetlenebilir, açıklanabilir ve yönetilebilir hâle getiren mimari olacak. Türkiye için de kural aynı — güçlü bir dijital altyapı ve gerçek ihracat problemleri tek başına yeterli değil; asıl fark, bu güveni kuracak sabırlı sermayenin ve iradenin bulunup bulunmayacağında ortaya çıkacak.

#Artificial Intelligence #Enterprise Software #Technology #Software Architecture #Digital Transformation

AI-Native ERP: Mimari Bir Devrim mi, Yoksa Yeni Bir Pazarlama Etiketi mi? | by Yavuz Selim Kılınç | Jul, 2026 | Medium

Bir Cevap Yazın