ERP entegrasyonu nedir, ERP kurulumundan farkı ne?
ERP entegrasyonu, şirketin ERP’si ile başka bir yazılım arasında verinin kurallı, izlenebilir ve kesintilere dayanıklı biçimde akmasını sağlayan bağlantıdır. Bu yazı şu durumu ele alıyor: ERP muhasebe, stok ve faturayı yürütmeye devam ediyor; yanına bir bayi portalı, saha uygulaması ya da operasyon ekranı ekleniyor ve bu yeni yazılımın ERP ile aynı gerçeği göstermesi gerekiyor.
ERP kurulumu ya da ERP geçişi ise başka bir projedir: ERP’nin kendisini seçmek, uyarlamak ve devreye almak. Bu işi çoğunlukla ERP üreticisi ya da çözüm ortağı yürütür. Entegrasyonda ERP değişmez; ona nasıl bağlanılacağı tasarlanır.
Baştan bir uyarı: hazır bir e-ticaret altyapısı kullanıyorsanız ya da ERP’nizin kendi B2B modülü ihtiyacınızı karşılıyorsa, önce üreticinin hazır bağlantısını değerlendirin; bu çoğu zaman daha hızlı ve ucuz yoldur. Özel entegrasyon ise süreç standart dışıysa, birden fazla sistem bağlanacaksa ya da hazır bağlantının kuralları işinize uymuyorsa anlam kazanır. Portalın kendisinde hangi özelliklerin beklendiğini B2B portal nedir? yazısında ele alıyoruz.
Başlamadan önce: envanter ve sorumlular
Plan bir envanterle başlar. Hangi ERP ve hangi sürüm kullanılıyor; şirket içinde mi çalışıyor, bulutta mı? ERP’ye bugün başka hangi sistemler bağlı: e-Fatura için özel entegratör, banka, depo yazılımı, e-ticaret sitesi? Logo, Mikro ya da SAP gibi aynı ürünü kullanan iki şirketin bile entegrasyon olanakları sürüm, lisans ve yıllar içinde yapılan uyarlamalar nedeniyle farklı olabilir. Ürün adı tek başına yetmez; sizin kurulumunuzda neyin mümkün olduğu doğrulanmalıdır.
İkinci soru insanlarla ilgilidir: ERP tarafında kim yetkili? İç BT ekibi mi, ERP’yi kuran çözüm ortağı mı? Servis kullanıcısını açacak, test ortamını hazırlayacak ve alanların anlamını açıklayacak kişi belli değilse entegrasyon takvimi sizin kontrolünüzde değildir.
ERP sorumlusuna sorulacak sorular
- Hangi ürün ve sürüm kullanılıyor; yakında yükseltme planlanıyor mu?
- ERP web servis ya da API sunuyor mu; bunun için ek lisans veya modül gerekiyor mu?
- Gerçeğe yakın veriyle çalışan ayrı bir test ortamı var mı?
- Fiyat, iskonto ve kampanya kuralları ERP’de mi hesaplanıyor, başka bir yerde mi?
- Bakım saatleri, gece işleri ve ay sonu kapanışı ne zaman?
- Entegrasyon kullanıcısını kim açar; değişiklik taleplerine kim, ne kadar sürede yanıt verir?
Ana kayıt sahipliği: hangi veri nerede doğar?
Planın merkezinde her veri türü için tek bir asıl kaynak belirlemek vardır: fiyat, stok, cari limit ya da sipariş durumu için “doğrusu hangisi?” sorusunun tek cevabı olmalıdır. İki sistemde birden değiştirilebilen bir alan er ya da geç iki farklı değer taşır.
Aşağıdaki tablo, varsayımsal bir bayi portalı için örnek bir plandır; kendi tablonuzu aynı sütunlarla doldurabilirsiniz. Okun başındaki sistem asıl kaynaktır. Sipariş portalda doğar, ERP’ye aktarıldıktan sonra asıl kaydı ERP tutar.
| Veri | Kaynak ve yön | Sıklık, tetikleyici | Hata durumunda |
|---|---|---|---|
| Ürün, birim, KDV oranı | ERP → portal | Değişiklikte ya da saatlik toplu | Portal son bilinen katalogla çalışır; eşlenemeyen kayıt rapora düşer |
| Fiyat ve iskonto | ERP → portal | Değişiklikte; sepet onayında son kontrol | Fiyat teyit edilemezse sipariş “onay bekliyor” olarak alınır |
| Stok | ERP → portal | Kısa aralıklarla | Bilginin güncellenme saati gösterilir |
| Cari, limit, bakiye | ERP → portal | Gece toplu; siparişte anlık limit sorgusu | Limit sorgusu yanıtsız kalırsa sipariş onaya düşer |
| Sipariş | Portal → ERP; durumu ERP → portal | Sipariş verildiğinde | Kuyrukta bekler, yeniden denenir; bayi “aktarılıyor” görür |
| e-Fatura, e-İrsaliye | ERP → portal | Belge oluştuğunda | Portal belge üretmez; belge yoksa “hazırlanıyor” görünür |
| Bayi kullanıcıları ve rolleri | Yalnız portal | — | — |
e-Fatura ve e-İrsaliye ayrı bir dikkat ister: bu yasal belgeler, Gelir İdaresi Başkanlığı’nın tanımladığı yöntemlerden biriyle (doğrudan entegrasyon, özel entegratör ya da GİB portalı) düzenlenir. Kapsamdaki belge türü için GİB’in güncel yöntemleri ve teknik kılavuzları kontrol edilir (kontrol: 11 Ekim 2026). Portalın belge üretmesi gerekmiyorsa: belge numarasını, ETTN’yi ve durumunu ERP’den ya da entegratörden okur, görüntüsünü bayiye sunar.
Anlık mı, periyodik mi?
Her verinin anlık akması gerekmez. Ölçüt şudur: bu veri eskidiğinde hangi karar yanlış verilir? Ürün açıklaması bir gün geç güncellense kimse zarar görmez; hızlı dönen bir üründe stok birkaç saat eskiyse karşılanamayacak sipariş alınır. Her ekranı ERP’ye anlık sorguyla bağlamak da risklidir: ERP yavaşlarsa ya da durursa portal da etkilenir. Çoğu durumda iyi denge, veriyi düzenli aralıklarla portala kopyalamak ve ERP’ye yalnızca kritik anda, örneğin sepet onaylanırken fiyat ve limit için sormaktır.
İki tarafta da değişebilen bir alan için, örneğin teslimat adresi, yazılı bir kural koyun: bayi portaldan değişiklik talep eder, kayıt ERP’de onaylanınca portala döner.
Ana veri temizliği ve eşleme
Entegrasyonda en çok sürpriz verinin kendisinden çıkar: eski ve yeni koduyla iki kez tanımlı ürünler, ERP’de adetle ama bayiye koliyle satılıp birim dönüşümü eksik kalmış kalemler, aynı bayinin şubeleri için açılmış birden fazla cari kart. Bu eşlemeler entegrasyon kodunun içinde gizli kurallar olarak kalmamalı; ayrı bir eşleme tablosunda tutulmalı ve her tablonun bir sahibi olmalıdır.
Entegrasyon yöntemleri: hangisi ne zaman?
Yöntem, ERP’nin sizin kurulumunuzda ne sunduğuna ve verinin niteliğine göre seçilir; bir projede birkaçı birlikte kullanılabilir.
| Yöntem | Ne zaman uygun? | Dikkat edilecekler |
|---|---|---|
| ERP servisleri / API | ERP sürümü web servis sunuyorsa; çoğu durumda ilk tercih | Ek lisans ve istek sınırları olabilir; sürüm yükseltmesinde servisler değişebilir |
| Ara katman ve kuyruk (middleware, iPaaS) | Birden fazla sistem bağlanacaksa ya da ERP yavaş veya kesintiliyse | Ek bileşen ve işletme gideri; izleme sorumlusu belli olmalı |
| Veritabanı görünümü (salt okunur) | Servis yoksa ve veri yalnızca okunacaksa | Tablo yapısı sürüm yükseltmesinde değişebilir; üretici desteği dışında kalabilir |
| Dosya aktarımı, EDI | Toplu ve periyodik veride; karşı taraf yalnızca dosya kabul ediyorsa | Gecikme, dosya formatı üzerinde anlaşma, yarım kalan dosyalar |
| Olay tabanlı (webhook, mesaj) | ERP bir kayıt değiştiğinde bildirim gönderebiliyorsa | Kaçan bildirimler için periyodik mutabakat şart |
ERP veritabanına doğrudan yazmak kısayol gibi görünür, ama ERP’nin stok düşme, cari bakiye ve belge numaralandırma kurallarını atlar. Siparişi ERP’ye her zaman ERP’nin kendi servisi ya da içe aktarma yöntemiyle yazın. ERP eski bir sürümdeyse ve hiçbir servis sunmuyorsa, önce önüne küçük bir servis katmanı koymak gerekebilir; bu iş bir yazılım modernizasyonu çalışmasının ilk adımı olarak da planlanabilir.
Hatalar, izleme ve güvenlik
Entegrasyonun asıl sınavı ERP’nin bakımda olduğu, bağlantının koptuğu ya da bir kaydın reddedildiği gündür. Planda şunlar yanıtlanmalıdır:
- Kuyruk. ERP erişilemezken sipariş kaybolmaz; portalda kaydedilip kuyrukta bekler, bayi de siparişinin alındığını görür.
- Yeniden deneme. Geçici hatalarda aktarım artan aralıklarla, azami deneme sayısı ve toplam süre sınırıyla yeniden denenir. Sınır dolunca kayıt insan incelemesine alınır; durmadan çalışan bir döngü kurulmaz. Kalıcı hatalar, örneğin kapatılmış bir cari, denemeye devam etmez; bir kişinin iş listesine düşer.
- Mükerrer kayıt önleme. Her sipariş portalda benzersiz bir numara alır ve bu numara ERP’de ayrı bir alanda saklanır. Aynı sipariş ikinci kez gelirse yeni kayıt açılmaz.
- İzleme ve uyarı. Kuyrukta bekleyen kayıt sayısı ve en eski kaydın bekleme süresi izlenir; eşik aşılınca adı belli bir kişiye uyarı gider.
- Mutabakat. Portaldaki ve ERP’deki siparişler her gün adet ve tutar olarak karşılaştırılır; fark raporu sahibine gider.
Güvenlik için entegrasyona ayrı bir servis kullanıcısı açılır ve yalnızca gereken işlemlere yetki verilir; bir çalışanın ERP şifresi entegrasyonda kullanılmaz. Şirket içinde çalışan ERP internete açılmaz; bağlantı VPN, IP kısıtı ya da içeriden dışarıya bağlanan bir ara katmanla kurulur. Her istek kayıt altına alınır, ama kayıtlara gereksiz kişisel veri yazılmaz. KVKK açısından hangi kişisel verinin hangi sisteme kopyalandığını entegrasyon belgesine yazın ve ihtiyaç olmayan alanı aktarmayın; şahıs şirketi olan bayilerin cari kartında ad ve T.C. kimlik numarası bulunabilir.
Test, canlıya geçiş ve geri dönüş planı
Örnek kayıtlarla kusursuz çalışan bir akış, gerçek fiyat koşulları ve yıllar içinde birikmiş istisnalarla karşılaşınca bozulabilir. Bu yüzden test, ERP’nin test ortamına alınmış ve kişisel verileri maskelenmiş güncel bir kopyayla yapılır; uç durumlar baştan listelenir: stoku sıfır ürün, limitini aşmış cari, süresi bitmiş kampanya, birden fazla birimle satılan ürün, aktarım sırasında yeniden başlayan ERP, iki kez gönderilen sipariş ve Türkçe karakter (İ, ş, ğ) içeren adresler.
Geçiş penceresi seçerken ay sonu kapanışından, fatura döneminden ve kampanya başlangıçlarından kaçının. Önce ana verinin ilk yüklemesi yapılıp ERP ile karşılaştırılır; ardından küçük bir pilot bayi grubuyla başlanır, telefon ve e-posta kanalı bu sürede açık kalır.
Canlıya geçiş kontrol listesi
- Ana kayıt sahipliği tablosu ve eşleme tabloları onaylandı.
- Uç durumlar test ortamında, gerçeğe yakın veriyle denendi.
- Kuyruk, yeniden deneme ve uyarılar test edildi; uyarıyı alacak kişi belli.
- İlk yükleme yapıldı ve sonuçları ERP ile karşılaştırıldı.
- Geçiş penceresi ERP sorumlusuyla birlikte seçildi.
- Pilot grup ve geçiş boyunca açık kalacak kanallar belirlendi.
- Geri dönüş planı yazıldı: hangi durumda, kimin kararıyla dönülür; o sırada portalda bekleyen siparişler ERP’ye nasıl aktarılır?
Süreyi ne belirler, elle köprüleme ne zaman mantıklı?
ERP entegrasyonunun süresini ürün adı belirlemez. Süreyi en çok etkileyenler: ERP’nin belgelenmiş bir servis sunup sunmadığı, ana verinin temizliği, test ortamının varlığı, akışların sayısı ve ERP tarafındaki sorumlunun ulaşılabilirliği. Bizim sürecimizde entegrasyon envanteri 1–2 haftalık keşifte çıkarılır. Kapsamı birlikte belirlenen ilk sürüm 6–12 haftada canlıya çıkacak şekilde planlanır; entegrasyonun durumu, ilk sürümün bu aralığın neresinde kalacağını en çok etkileyen kalemlerden biridir.
Her ilk sürüm tam entegrasyonu beklemek zorunda değildir. Varsayımsal bayi portalı örneğinde, sipariş hacmi henüz düşükken fiyat ve stok günde birkaç kez ERP’den alınan bir dosyayla güncellenebilir; portala düşen siparişleri operasyon ekibi kendi ekranından ERP’ye aktarabilir. Böylece bayilerin portalı benimseyip benimsemediği entegrasyon bitmeden öğrenilir. Hacim arttığında, stok hızla değiştiğinde ya da kredi limiti riski yüksek olduğunda ise elle köprü bir hata kaynağına dönüşür; o noktada tam entegrasyon sıradaki iştir. Bu kararı MVP kapsamı nasıl belirlenir? yazısında ayrıntılı ele alıyoruz.
ERP’ye bağlı bir portalı nasıl ele aldığımızı B2B portal geliştirme sayfasında anlatıyoruz. Bayi Sipariş Platformu ürün konsepti ise bayiye özel fiyatın, cari hesabın ve sipariş durumunun ekranlarda nasıl görünebileceğini kurgusal X Dağıtım üzerinden gösteriyor.
ERP envanterinizle 30 dakikalık bir görüşmede planın ilk taslağını birlikte çıkarabiliriz.