ERP entegrasyonu, kurumsal kaynak planlama yazılımının e-ticaret sitesi, pazaryeri, CRM, üretim takip ve muhasebe gibi diğer sistemlerle veriyi karşılıklı ve otomatik alışverişe açacak biçimde bağlanmasıdır. Hedef, tek bir raporu dışa aktarmak değil; stok, sipariş, cari ve ürün verisinin ikinci, üçüncü bir yere elle girilmesi zorunluluğunu tamamen ortadan kaldırmaktır.
- ERP entegrasyonu, aynı verinin birden fazla sisteme elle girilmesini bitiren kalıcı veri bağıdır; "Excel'e aktar" bir entegrasyon değildir.
- Bağlantı dört yöntemle kurulur: doğrudan API/web servis, ara katman (middleware), dosya aktarımı ve bağ kurmayan manuel portal. Gelir İdaresi'nin e-belge yöntemleri bu yöntemlerin resmî bir örneğidir.
- Projelerin çoğu teknik nedenle değil, "hangi sistem ana kaynak" kararı verilmediği için batar.
- TÜİK'e göre 10-49 çalışanlı girişimlerin yalnızca %10,8'inde bilişim uzmanı var; entegrasyonun bakım yükü baştan planlanmalıdır.
- Yapay zeka katmanı entegrasyondan sonra gelir; tek kaynaklı ve temiz veri olmadan talep tahmini de belge okuma da çalışmaz.
Türkiye'de ERP artık azınlığın işi değil. TÜİK'in 2025 Girişimlerde Bilişim Teknolojileri Kullanım Araştırması, en az 10 çalışanı olan girişimlerin %28,3'ünün kurumsal kaynak planlama yazılımı kullandığını gösteriyor. Oran 10-49 çalışanlı işletmelerde %23,6, 50-249 çalışanlılarda %46,0 ve 250 ve üzeri çalışanı olanlarda %76,5. Yani sorun çoğu işletmede "ERP yok" değil; ERP var ama yalnız çalışıyor.
ERP entegrasyonu nedir, "Excel'e aktarma"dan farkı nedir?
ERP entegrasyonu, iki sistem arasında kurulan ve insan müdahalesi olmadan çalışan kalıcı bir veri bağıdır. Excel dışa aktarma ise anlık bir fotoğraftır: dosya indirildiği saniyede eskimeye başlar, kimin ne zaman aktardığı kayda geçmez ve bir hata olduğunda kimse fark etmez. Entegrasyonun üç ölçütü tekrarlanabilirlik, iz kaydı ve hata yönetimidir.
Pratikte fark şurada görünür. Elle aktarımda iki kişi ayda onlarca saatini kopyalamaya verir ve hata payı insanın dikkatine bağlı kalır. Entegrasyonda aktarım dakikalar içinde kendi kendine olur, başarısız her kayıt bir hata kuyruğuna düşer ve biri onu görür. Tekrar eden adımların kurallarla yazılıma devredilmesinin genel mantığını iş akışı otomasyonu rehberimizde anlatmıştık; ERP entegrasyonu bu mantığın kurumsal veri katmanındaki karşılığıdır.
Sistemler birbirine hangi yöntemlerle bağlanır?
Sistemler birbirine dört yöntemle bağlanır: doğrudan API bağlantısı, araya bir katman koyan middleware, belirli aralıkla dosya alışverişi ve hiçbir bağ kurmayan manuel portal. Seçim teknik bir zevk meselesi değildir; işletmenin bilişim kapasitesine, bağlanacak sistem sayısına ve verinin ne kadar taze olması gerektiğine göre belirlenir.
Bu yöntemlerin en somut örneği Türkiye'nin kendi mevzuatında duruyor. Gelir İdaresi Başkanlığı'nın e-belge uygulaması, e-faturaya üç kullanım yöntemiyle bağlanılmasına izin verir: doğrudan entegrasyon, özel entegratör ve portal. Bu üçlü sırasıyla doğrudan API, ara katman ve manuel portal mimarisinin resmî karşılığıdır; e-fatura hangi yol seçilirse seçilsin UBL-TR standardında üretilir.
| Yöntem | Nasıl çalışır | Ne zaman doğru | Dikkat edilecek nokta |
|---|---|---|---|
| Doğrudan API / web servis | İki sistem birbiriyle doğrudan konuşur | 1-2 sistem var, kendi bilişim ekibi var | Her yeni sistem yeni bir bağlantı demektir |
| Ara katman (middleware) | Tüm sistemler ortadaki katmana bağlanır | 3 ve üzeri sistem, çok kanallı satış | Katmanın kendisi bakım ister |
| Dosya aktarımı (EDI/CSV) | Belirli aralıkla dosya alışverişi yapılır | Toplu ve gecikmeye toleranslı veri | Anlık stok için uygun değildir |
| Manuel portal | İnsan iki ekrana da ayrı ayrı girer | Düşük hacim, geçici çözüm | Entegrasyon sayılmaz |
Küçük ölçekli, birkaç adımlık bağlantılar için n8n, Make ve Zapier gibi araçlar yeterli olabilir; bunları otomasyon aracı karşılaştırmamızda yan yana koymuştuk. Ancak ERP entegrasyonu farklı bir ligdir: işlem bütünlüğü, başarısız isteği tekrar deneme, sıra garantisi ve dönem sonu mutabakatı gerektirir. Bu yazının konusu o kurumsal mimaridir.
Gerçek zamanlı senkron mu, zamanlanmış aktarım mı seçilmeli?
Senkron biçimi, verinin bayatlama maliyetine göre seçilir. Stok gibi yanlış olduğunda anında para kaybettiren veriler gerçek zamanlı veya birkaç dakikalık aralıkla akmalıdır. Ürün açıklaması, fiyat listesi ve cari bakiye gibi daha yavaş değişen veriler için gecelik toplu aktarım hem yeterli hem de belirgin biçimde ucuzdur.
Her şeyi gerçek zamanlı kurmak yaygın ve pahalı bir hatadır. Gerçek zamanlı bağlantı, sürekli ayakta duran bir altyapı, izleme ve arıza nöbeti demektir. Konya'daki 60 kişilik bir makine imalatçısında stok ve sipariş akışını 5 dakikada bir, ürün ve fiyat akışını gecede bir çalıştırmak; her şeyi anlık kurmaya göre hem daha az arızalanır hem daha az tutar.
Entegrasyon projeleri en çok nerede kırılır?
Entegrasyon projeleri neredeyse hiç "veri taşınamadı" diye kırılmaz; verinin iki tarafta aynı şeyi ifade etmemesi yüzünden kırılır. Aşağıdaki dört kırılma noktası, çok kanallı satış yapan işletmelerin tamamında şu ya da bu ölçüde çıkar ve dördünün de çözümü teknik değil tanımsaldır.
| Kırılma noktası | Belirti | Kök neden |
|---|---|---|
| Stok tutarsızlığı | Pazaryerinde olmayan ürün satılıyor | Rezerve stok ile fiili stok ayrımı yok |
| Mükerrer sipariş | Aynı sipariş ERP'ye iki kez düşüyor | Tekilleştirme anahtarı tanımlanmamış |
| SKU eşleşme kaosu | Aynı ürünün üç sistemde üç ayrı kodu var | Ürün ana verisi sahipsiz |
| İade akışı | İade edilen mal stoğa geri dönmüyor | Ters akış hiç kapsama alınmamış |
İade akışı özellikle sinsidir. Projelerin büyük kısmı sipariş yönünü kurar, ters yönü "sonra bakarız" diye bırakır ve birkaç ay içinde stok farkı büyür. TÜİK'in verisi bu riskin neden yaygınlaştığını gösteriyor: web sitesi ya da mobil uygulama üzerinden satış yapan girişimlerin %80,4'ü başka girişimlerin de satış yaptığı çevrimiçi pazaryerlerini kullanıyor, %51,6'sı kendi sitesini. Oysa bu oranlar 2020 yılında sırasıyla %69,7 ve %70,3'tü. İşletmeler giderek daha çok, kurallarını kendilerinin koymadığı platformlara bağlanıyor.
"Hangi sistem ana kaynak?" kararı neden projeyi belirler?
Ana kaynak kararı, her veri türü için "doğrusu hangi sistemdedir" sorusunun tek ve yazılı cevabıdır. Stok için ERP mi depo yönetimi mi, müşteri için CRM mi ERP mi, ürün açıklaması için pazaryeri paneli mi ürün yönetimi mi? Bu cevap verilmeden kurulan her bağlantı, er ya da geç iki sistemin birbirinin üzerine yazmasıyla sonuçlanır.
Karar verilmediğinde ortaya çıkan tablo tanıdıktır: gece çalışan aktarım, gündüz elle yapılmış bir düzeltmeyi siler; kimse neyin doğru olduğunu bilemez; ekip entegrasyona güvenmeyi bırakır ve yeniden Excel'e döner. Üretim yapan işletmelerde bu sınır özellikle ERP ile saha arasında belirsizleşir. İş emri gerçekleşmelerinin ve duruşların doğru adresi genelde üretim yürütme katmanıdır; bu sınırı MES ve üretim takip sistemi yazımızda ayrıntılı ele aldık.
Pratik kural şudur: her veri türü için tek bir sahip sistem ve tek bir sahip kişi yazılır. Sahipsiz veri, entegrasyonun en pahalı kalemidir.
Bir entegrasyon projesi nasıl kapsanır ve ne kadar sürer?
Kapsam, bağlanacak sistem sayısıyla değil; taşınacak veri türü ve akış yönü sayısıyla ölçülür. "ERP'yi pazaryerine bağlayalım" bir kapsam değildir, bir niyet beyanıdır. "Ürün, stok, sipariş ve iade olmak üzere dört veri türünü, ikisi çift yönlü olacak biçimde bağlayalım" ise bir kapsamdır: sayılabilir, test edilebilir ve fiyatlanabilir.
Süre beklentisini gerçekçi tutmak gerekir. Panorama Consulting Group'un 2026 ERP Raporu, Ocak 2025 - Ocak 2026 arasında 170 kuruluştan toplanan yanıtlarda medyan proje süresini 9 ay olarak veriyor; kuruluşların dörtte birinden fazlası bütçeyi, yaklaşık dörtte biri de takvimi aşmış. Bütçe aşımının en sık nedeni beklenmedik ek teknoloji ihtiyacı, takvim aşımının en sık nedeni ise organizasyonel sorunlar olarak kaydedilmiş.
Bu 9 aylık süre, tek bir entegrasyonun değil komple bir ERP kurulumunun medyanıdır ve örneklemin medyan cirosu 200,5 milyon dolardır; yani Konya ölçeğindeki bir KOBİ'den çok daha büyük kuruluşlar. Dört veri türüyle sınırlanmış bir entegrasyon kapsamı bunun çok altında kalır. Buna karşın aşım nedenlerinin ikisi de ölçekten bağımsızdır: küçük projelerde de en sık gecikme sebebi kod değil, karar verilememesidir.
Bakım yükü de baştan hesaplanmalıdır. TÜİK'in 2026 araştırmasına göre girişimlerin yalnızca %15,2'si bilişim teknolojileri uzmanı istihdam ediyor; oran 10-49 çalışanlı işletmelerde %10,8'e düşüyor. Entegrasyonu kuran taraf işi teslim ettikten sonra bağlantıyı kimin izleyeceği sözleşmede yazmıyorsa, proje ilk pazaryeri API değişikliğinde durur.
Entegrasyonun üzerine yapay zeka katmanı ne zaman eklenir?
Yapay zeka katmanı, veri tek kaynaktan ve düzenli akmaya başladıktan sonra eklenir. Sebebi basittir: model geçmiş veriden öğrenir ve aynı ürün için üç sistemde üç farklı stok gösteren bir işletmenin geçmiş kaydı güvenilir sayılmaz. Entegrasyon bu anlamda yapay zekanın ön koşuludur, alternatifi değildir.
Sıra geldiğinde üç uygulama hızlı karşılık verir. Talep tahmini, temizlenmiş satış geçmişinden hareketle fazla ve eksik stok maliyetini düşürür; bunun KOBİ ölçeğinde nasıl kurulduğunu stok ve talep tahmini rehberimizde adım adım anlattık. Belge okuma, tedarikçi faturasını ve irsaliyeyi okuyup ERP'ye kalem kalem yazar; fatura işleme ve OCR yazımız bu akışı ele alıyor. Anomali yakalama ise entegrasyonun kendisini denetler: gece aktarımında beklenenin çok dışında bir stok hareketi olduğunda, sabah kimse fark etmeden uyarı üretir.
Panorama'nın raporunda bunu destekleyen bir bulgu daha var: "silolardan kurtulma" faydasını gerçekleştirdiğini söyleyen kuruluşların oranı bir yıl içinde %55,2'den %77,4'e çıkmış. Fayda, entegrasyon oturduktan sonra geliyor.
Konya'daki bir işletme nereden başlamalı?
Başlangıç noktası yazılım seçimi değil, envanter çıkarmaktır. İlk hafta üç soruyu yazılı cevaplayın: hangi veri hangi sistemlerde tutuluyor, hangi veri bugün elle kaç kez giriliyor ve her veri türünün ana kaynağı hangi sistem olacak. Bu üç cevap, teklif almadan önce elinizde olmalıdır.
Ardından tek bir akışla başlayın. En çok acıtan, genelde stok veya siparişte olan tek bir akışı uçtan uca kurun; iki hafta boyunca gölge modda elle süreçle birlikte çalıştırın ve sayıların tuttuğunu görün. Sonra ikinci akışa geçin. Aynı anda altı akış açan projeler, hata çıktığında hangi bağlantının suçlu olduğunu bulamadığı için uzar.
Üçüncü adım sözleşmeye bakar. Bağlantının kim tarafından izleneceği, bir pazaryeri API değişikliğinde müdahale süresinin ne olduğu ve hata kuyruğuna düşen kayıtları kimin temizleyeceği yazılı olsun. Mevcut sistemlerinizin haritasını çıkarıp gerçekçi bir kapsam ve süre görmek isterseniz, TecnoNest olarak entegrasyon keşfi ve kapsam çıkarma görüşmesi yapıyoruz: hangi akışın önce kurulacağını ve neyin ertelenebileceğini birlikte netleştiriyoruz.