ERP Entegrasyon Projesi Nasıl Planlanır? 8 Adımlık Kontrol Listesi

1. Hangi Ürün, Hangi Sürüm? İlk Tespit Burada Başlar

ERP entegrasyonu dendiğinde ilk soru şu olmalı: "Hangi ERP yazılımının hangi versiyonu kullanılıyor?" Logo Tiger 5.0 ile Logo Go'nun API yapısı farklı. Mikro 17 ile Mikro 20 arasında yetkilendirme mekanizması değişmiş. Nebim V3 ile Fusion'ın REST endpoint'leri bambaşka.

Atlanırsa ne olur?

Kod yazılır, test ortamında çalışır (çünkü genelde test için güncel sürüm kurulur), canlıya geçildiğinde patlarsınız. Üretici firma eski sürümünde desteklenmeyen bir özelliği kullanmaya çalışmış olursunuz.

Sık karşılaşılan bir durum: Eta v15 kullanan bir firmada, entegrasyon için yazılan kod v16'nın JSON API'sini baz alır. Canlıya geçildiğinde fark edilir ki v15'te sadece XML destekleniyor. İki haftalık ekstra geliştirme ve maliyet demek olur.

Yapılması gereken:

• ERP yazılımının tam adı, sürüm numarası, build/patch seviyesi
• Şirket içi mi (on-premise) yoksa bulut mu?
• Hangi modüller aktif? (Bazen entegre edilecek modül satın alınmamış bile olabiliyor)
• Son güncelleme ne zaman yapılmış, düzenli güncelleme politikası var mı?

Bu bilgileri topladıktan sonra ERP üreticisinin API dokümantasyonunu sürüme özel indirin. Genel dokümantasyon yetmez.

2. Kullanılacak Arayüz ve Lisans Yetkisi Teyidi

Çoğu ERP'de API erişimi ayrı bir lisans kalemi veya ek ücretli modüldür. Bazılarında kullanıcı başına, bazılarında sabit API call limiti vardır. Kimi sistemlerde sadece REST, kimi sistemlerde sadece SOAP, kimi sistemlerde her ikisi de mevcuttur ama yetkilendirme şekilleri farklıdır.

Takvimin ilk maddesi kod yazmak değil, erişimin açılmasıdır

Bu cümle altın değerindedir. Projeye başlarken ilk iş API erişim talebini ERP sağlayıcısına iletmektir. Onay süreci iki gün sürebileceği gibi, bayi üzerinden lisans alınmışsa, bayinin üreticiden talepte bulunması, sonra sizin onay almanız üç hafta sürebilir.

Sık karşılaşılan bir durum: Bir gıda firmasında Logo Tiger entegrasyonuna başlanır, ancak entegrasyon modülünün lisansta olmadığı sonradan fark edilir. Önce satış süreci başlar, sonra kurulum, ardından yetkilendirme. Proje takvimine bu üç haftalık bekleme eklenmemişse, ciddi gecikmeler yaşanır.

Yapılması gereken:

• API/Web Servis modülü lisansı var mı?
• Varsa hangi yöntemlerle erişim sağlanıyor? (REST, SOAP, ODBC, Webhook?)
• Authentication tipi nedir? (OAuth 2.0, Basic Auth, API Key, Windows Auth?)
• Test ve canlı ortam için iki ayrı erişim gerekiyor mu?
• IP kısıtlaması var mı?

Erişim bilgileri alındıktan sonra basit bir "bağlantı testi" yapın: tek bir GET isteği atıp 200 OK dönüşü alın. Bu onay gelmeden tek satır iş kodu yazmayın.

3. Salt Okuma Pilotu ile Risksiz Başlangıç

Entegrasyon planlama aşamasında en akıllıca hareket, ilk adımı sadece okuma ile atmaktır. Hiçbir veri yazmadan, değiştirmeden önce sistemi dinlemek, anlamak, API'nin gerçek davranışını gözlemlemek gerekir.

Salt okuma pilotu şu demektir: ERP'den stok kodlarını çek, fiyat listesini çek, cari hesap bakiyelerini çek ama geri hiçbir şey yazma. E-ticarete veya WMS'e aktarılacak veriyi önce manuel olarak kontrol et, hangi alanların dolu geldiğini, hangilerinin boş döndüğünü gör.

Atlanırsa ne olur?

Doğrudan yazma işlemleri ile başlarsanız yanlış alana yanlış veri yazabilir, silemeyeceğiniz kayıtlar oluşturabilir, muhasebe dönemini kapatılmış faturaya müdahale edebilirsiniz.

Örnek hata senaryosu: Bir tekstil firmasında sipariş entegrasyonunda doğrudan "sipariş oluştur" endpoint'i kullanılmaya başlanır. İlk testte fark edilmez ki kargo tutarı yanlış alana yazılıyor, ERP bunu ürün fiyatına ekliyor. Sistem iki gün böyle çalışırsa, onlarca sipariş yanlış fiyatla muhasebeleşir. Düzeltme için manuel müdahale gerekir.

Yapılması gereken:

• İlk hafta sadece GET istekleri
• Gelen veriyi JSON veya XML olarak logla, manuel incele
• Alan adlarını, veri tiplerini, zorunlu/opsiyonel alanları çıkar
• Boş dönen, null gelen, beklenmedik formatta gelen alanları belirle
• Dökümantasyonda yazanla gerçekte gelen arasındaki farkları not et

Bu aşama sıkıcı gelebilir ama yazma işlemlerine geçmeden önce haritayı çıkarmış olursunuz.

4. Kod/Birim/Ambar Eşleme Tablosunun Kurulması

ERP'deki stok kodu "ÜRN-001" iken e-ticarette "urun-kirmizi-paket" olabilir. ERP'de ambar adı "MERSİN DEPO" iken WMS'te "MRS-ANA" olabilir. KDV oranı ERP'de sayı (18) iken, e-ticarette string ("%18") olabilir.

Eşleme tablosu olmadan entegrasyon çalışmaz. Bu tablo manuel oluşturulur, süreç içinde güncellenir ve her iki sistemde de aynı varlığa işaret eden farklı kimlik/kodu eşleştirir.

Atlanırsa ne olur?

Sistemler konuşur ama yanlış anlar. Sipariş "Ankara Deposu"na düşer ama ERP'de "İstanbul Şubesi" olarak kaydedilir. Ürün kodu eşleşmez, entegrasyon "ürün bulunamadı" hatası verir, sipariş askıda kalır.

Sık karşılaşılan bir durum: Bir e-ticaret firması Logo entegrasyonunda müşteri kodu eşlemesi yapmaz, her siparişte yeni cari hesap açılır. Birkaç ay sonra fark edilir ki aynı müşterinin çok sayıda farklı cari kodu var. Muhasebe departmanı kaosa girer.

Yapılması gereken:

• Stok kodları (SKU) eşleme tablosu: ERP_StokKodu ↔ Platform_SKU
• Cari kodları eşleme: ERP_CariKodu ↔ Platform_MüşteriID
• Ambar/depo eşleme: ERP_AmbarKodu ↔ Platform_DepoID
• Birimler: ERP'de "AD" iken platformda "Adet" yazıyorsa eşleştir
• Vergi oranları, ödeme tipleri, kargo firmaları

Bu tablo sistem entegrasyonu kodunun dışında, ayrı bir veritabanı tablosunda veya config dosyasında tutulmalı. Değiştiğinde kod değiştirmeden güncellenebilmeli.

5. Hangi Olay Hangi Kaydı Üretir? Yazılı Tanım Şart

Proje kontrol listesi içinde en çok atlanılan, sonra en çok kavgaya yol açan kısım budur: "Hangi olay tetiklendiğinde hangi kayıt nereye, hangi alanlarla, hangi durumda yazılacak?" sorusunun yazılı, maddeler halinde, örnekli cevabı.

Örneğin:

• E-ticarette sipariş "ödeme onaylandı" durumuna geçtiğinde → ERP'de fatura mı kesilecek, proforma mı, irsaliye mi?
• Sipariş iptal edilirse → ERP'de kayıt silinecek mi, iptal faturası mı kesilecek, sadece durum mu güncellenecek?
• Stok miktarı ERP'de değiştiğinde → hangi ambarlar senkronize edilecek? Tümü mü, sadece e-ticaret deposu mu?
• Fiyat değişikliği gerçek zamanlı mı, saatlik mi, günlük toplu mu aktarılacak?

Atlanırsa ne olur?

Geliştirici varsayımla çalışır. "Herhalde sipariş onaylanınca fatura keseriz" der, kesmeye başlar. Muhasebe departmanı "biz önce irsaliye kesip teslimattan sonra fatura kesiyoruz" der. Sistem yanlış çalışmaya başlar.

Örnek hata senaryosu: E-ticaret siparişleri "hazırlanıyor" durumuna geçtiğinde ERP'ye irsaliye olarak kaydedilirse, ama bazen sipariş iptal edilirse ve kimse ERP'deki irsaliyeyi iptal etmezse, ay sonunda stok sayımında hayalet irsaliyeler çıkar.

Yapılması gereken:

Bir "Entegrasyon Senaryo Dokümanı" oluşturun. Her satır şu formatta olsun:

Olay: E-ticaret siparişi ödeme onayı aldı
Koşul: Ödeme tipi "Havale/EFT" değilse
Aksiyon: ERP'de FATURA kesimi başlat
Alanlar: CariKodu (müşteri eşlemeden), StokKodu (ürün eşlemeden), Miktar, BirimFiyat, KDV, İskonto
Durum: Fatura kesilince e-ticarete "fatura_no" ve "fatura_tarihi" geri dön

Bu doküman hem geliştirme için referans, hem test için senaryo listesi, hem de ileride "neden böyle yaptık" sorusunun cevabıdır.

6. Hata Kaydı ve Yeniden Deneme Kurgusu: Sessiz Başarısızlık En Sinsi Sorundur

ERP entegrasyonu dendiğinde herkes başarı senaryosunu düşünür. Ama gerçek dünyada işler ters gider: API geçici çöker, timeout olur, ERP sunucusu yeniden başlatılır, network geçici kesilir, rate limit aşılır.

Bu geçici hataların 90%'ı yeniden denendiğinde başarılı olur. Ama yeniden deneme mekanizması yoksa, hata loglanmıyorsa sistem sessizce başarısız olur. Sipariş e-ticarette "tamamlandı" görünür, ERP'ye hiç geçmez. Kimse fark etmez, ay sonu stok tutmaz, kaos başlar.

Atlanırsa ne olur?

Siparişler e-ticaret panelinde "hazırlanıyor" ama ERP'de yok. Kargo çıkamaz, müşteri şikayet eder. Manuel müdahale edilir. Sonra bir daha, bir daha… Entegrasyonun anlamı kalmaz.

Tipik bir senaryo: Bir hafta sonu ERP sunucusu güncelleme için kapatılır, onlarca sipariş havada kalır. Pazartesi sabah fark edilir, manuel tek tek girilir. Çözüm: "entegrasyon kuyruk" mekanizması kurulur: başarısız işlemler kuyruğa düşer, 5-10-30-60 dakika aralıklarla yeniden denenir, 4. denemede de olmazsa mail ile uyarı gider.

Yapılması gereken:

• Her API isteği için try-catch ve loglama
• Geçici hatalar (timeout, 502, 503, network error) için retry logic (üstel geri çekilme ile: 1-2-5-10 dakika)
• Kalıcı hatalar (401 yetki hatası, 404 kayıt bulunamadı) için yeniden deneme yapma ama admin'e bildir
• Başarısız işlemler için bir kuyruk tablosu: hangi işlem, kaç kez denendi, son hata mesajı
• Kuyruk tablosundan günde bir özet rapor: "dün 12 işlem 3 denemede başarılı, 2 işlem hala bekliyor"

Sessiz başarısızlık yerine gürültülü başarısızlık tercih edin. Sistem hata verdiğinde herkes duysun.

7. Test Ortamında Doğrulama: Canlı Veriye Dokunmadan Önce

Kod yazıldı, eşlemeler kuruldu, hata yakalama eklendi. Şimdi sıra test ortamında doğrulamada. İdeal senaryo: ERP'nin test instance'ı var, e-ticaret/WMS'in staging ortamı var, ikisi arasında entegrasyon test edilir.

Gerçek dünyada ERP'nin genelde test ortamı yoktur (özellikle küçük-orta ölçekli firmalarda lisans maliyeti nedeniyle). O zaman en azından salt okuma testleri canlı, yazma testleri geliştirme ortamında mock API ile yapılmalıdır.

Test senaryoları:

1. Mutlu senaryo: Normal sipariş → ERP'ye fatura kesimi → stok düşümü → e-ticarete fatura no dönüşü
2. İptal senaryosu: Sipariş iptal → ERP'de ilgili kayıt iptal/durum güncelleme
3. Kısmi teslimat: 10 adet sipariş, 7 adet sevk edildi → ERP'de irsaliye 7 adet, kalan 3 bekliyor
4. Stok sıfırlanma: ERP'de ürün stok = 0 → e-ticaret "stokta yok" işaretle
5. Hata senaryoları: API timeout, yetki hatası, kayıt bulunamadı → yeniden deneme kuyrukta bekliyor mu?
6. Eşleşmeyen kod: E-ticarette yeni ürün eklendi ama eşleme tablosunda yok → hata loglanıyor mu, admin'e bildirim gidiyor mu?

Her senaryo test edilmeli, sonuç dokümente edilmeli: "✅ Başarılı", "⚠️ Kısmi sorun (manuel müdahale ile çözüldü)", "❌ Başarısız (geliştirme gerekli)".

Atlanırsa ne olur?

Canlıya geçilir, ilk sipariş gelir, sistem patlar. Ya da daha kötüsü: ilk 10 sipariş tesadüfen doğru çalışır (çünkü basit senaryolardır), 11. sipariş farklı bir durumda (iade, kısmi ödeme, hediye paketi) gelir, sistem sessizce başarısız olur.

Test ortamı yoksa bile sandbox veri ile (gerçek müşteri değil, test müşterisi; gerçek stok değil, kukla stok kodu) lokal/staging ortamda tüm senaryoları koşturun.

8. Devreye Alma ve İzleme: Entegrasyon Bitmiş Bir İş Değildir

Test tamamlandı, onay alındı, canlıya geçiliyor. İlk hafta yakın izleme şarttır. Saatlik log kontrolü, günlük başarı/başarısızlık raporu, müşteri şikayetlerine anında müdahale.

Ama asıl kritik nokta şu: ERP entegrasyonu bitmiş bir iş değil, sürümle yaşayan bakım kalemidir.

Neden?

• ERP yazılımı güncellenir, yeni sürümde API değişir
• E-ticaret platformu güncellenir, webhook yapısı değişir
• İş süreçleri değişir: önce irsaliye kesiyordunuz, şimdi proforma kesmeye başladınız
• Yeni ödeme yöntemi eklendi, yeni kargo firması eklendi → eşleme tablosu güncellenmeli
• Yeni ambar açıldı → entegrasyon yeni depoyu tanımalı

Yapılması gereken:

İlk 1 hafta: Günlük monitoring, log kontrolleri, hata raporları
İlk 1 ay: Haftalık durum raporu, kullanıcı geri bildirimleri toplama
Devam eden: Aylık sağlık kontrolü (log analizi, kuyrukta bekleyen işlem var mı, hata oranı artıyor mu)
Sürüm takibi: ERP ve platform güncellemeleri takip edilmeli, yeni sürüm çıkmadan önce API değişiklik notları okunmalı, gerekirse entegrasyon kodu güncellenmeli

Örnek senaryo: Logo Tiger'da bir sürüm güncellemesi sonrası OAuth token süresi 24 saatten 12 saate düşürülür. Bunu takip etmeyen entegrasyon kodları günde bir kez token yeniler, 12. saatten sonra 401 hatası almaya başlar. Çözüm: sürüm notlarının takip edilmesi, güncelleme öncesi test edilip kod uyarlanmasıdır.

Atlanırsa ne olur?

Entegrasyon altı ay sorunsuz çalışır, sonra ERP güncellemesi gelir, sistem çöker. "Entegrasyon bitmişti, kod dokunulmadı" denilir ama o kod artık çalışmayan bir API'ye bağlanıyordur.

O yüzden proje kontrol listesi kapalı devre değil, açık döngüdür: "8. İzleme" adımı yeni bir güncelleme gerektiğinde "1. Sürüm tespiti" adımına geri döner.

Sık Sorulan Sorular

ERP entegrasyon projesi ne kadar sürer?

Basit bir okuma entegrasyonu (sadece stok/fiyat senkronizasyonu) 2-3 haftada tamamlanabilir. Karmaşık bir çift yönlü entegrasyon (sipariş, fatura, cari hesap, stok hareketi, iade süreci) 6-10 hafta sürebilir. Süreyi etkileyen faktörler: ERP sağlayıcısından API erişim onayının gelme süresi (bazen 2 gün, bazen 3 hafta), test ortamının olup olmaması, iş süreçlerinin net tanımlanmış olup olmaması, eşleme tablolarının hazır olup olmaması. D'Cloud Software olarak proje keşif görüşmesinde size detaylı bir zaman planı sunuyoruz, her adım için gerçekçi tarih veriyoruz.

Hangi ERP sistemleri ile entegrasyon yapıyorsunuz?

Logo (Tiger, Go, J3), Mikro (Bulut, 17, 20), Netsis, Nebim, Eta, SAP Business One, Uyumsoft gibi yaygın ERP'lerle projeler tamamladık. Az bilinen veya sektöre özel ERP'lerle de çalışabiliyoruz, kritik nokta o ERP'nin REST/SOAP API veya ODBC erişimi sunuyor olması. API dokümantasyonu yoksa ya da çok kısıtlıysa (örneğin bazı eski versiyonlarda) veritabanı seviyesinde entegrasyon da yapıyoruz ama bu daha riskli ve bakımı zor olduğu için tercih etmiyoruz. Keşif görüşmesinde ERP sürümünüzü ve API erişim durumunuzu kontrol edip net bir yanıt veriyoruz.

ERP entegrasyonu yapılırken işlerimiz aksıyor mu?

Hayır. Entegrasyon paralel ortamda, mevcut iş akışınıza dokunmadan geliştirilir. Salt okuma pilotu zaten risk içermez. Yazma işlemleri test ortamında doğrulanır. Canlıya geçiş planlandığı gün (genellikle hafta sonu veya düşük yoğunluklu saatlerde) kısa bir전환 süreci yaşanır ama normal işleyişiniz devam eder. Devreye alma sırasında geçici bir sorun olursa hemen eski sürüme dönüş (rollback) planımız hazır olur. İlk 15 gün içinde tespit edilen hatalar ücretsiz düzeltilir (garanti koşulumuz). İşlerinizin aksamadan entegrasyonu tamamlamak bizim standart uygulamamız.

Entegrasyon maliyeti ne kadardır?

Maliyet projenin kapsamına göre değişir. Tek yönlü (sadece ERP'den okuma), çift yönlü (yazma-okuma), kaç tablo/modül entegre edilecek, hata yakalama ve kuyruk mekanizması gerekli mi, mevcut ERP API'si hazır mı yoksa API modülü lisansı alınacak mı gibi faktörler belirleyici. Keşif görüşmesinde ihtiyaçlarınızı detaylı dinler, size sabit fiyat teklif veririz, sözleşmede yazılı bu fiyat değişmez. "Geliştirme sırasında ek ücret" durumu yaşanmaz. Görüşme talebinizi WhatsApp veya iletişim formu üzerinden iletebilirsiniz, 24 saat içinde dönüş yapıyoruz.

Entegrasyonu kendin yapsam daha ucuz olmaz mı?

Eğer yazılımcı ekibiniz varsa ve ERP API konusunda deneyimlilerse teknik olarak mümkün. Ama yukarıda saydığımız 8 adımın her biri deneyim gerektirir: hangi hatanın geçici hangisinin kalıcı olduğunu bilmek, eşleme tablolarını doğru kurmak, sessiz başarısızlıkları yakalamak, sürüm güncellemelerini takip etmek. Biz bu işi onlarca projede yaptık, her ERP'nin hangi sürümünde hangi tuzak olduğunu biliyoruz. Kendi ekibinizle yaparsanız öğrenme maliyeti (zaman + deneme-yanılma) genelde bizim teklif ettiği fiyattan daha pahalıya mal olur. Bir de şu var: işiniz ERP entegrasyonu değil, kendi ürününüzü satmak. Ekibinizi buna harcamak yerine bize yaptırıp siz işinize odaklanırsanız ROI daha yüksek olur.

Entegrasyon sonrası destek veriyor musunuz?

Evet. İlk 15 gün içinde tespit edilen hatalar ücretsiz düzeltilir, bu garanti sözleşmede yazılıdır. Sonrasında aylık veya yıllık bakım anlaşması yapabilirsiniz: log izleme, sürüm güncellemeleri takibi, küçük iyileştirmeler, yeni alan ekleme gibi işler için. Bakım anlaşması zorunlu değil ama öneriyoruz çünkü ERP entegrasyonu canlı bir sistemdir, sürekli evrim geçirir. Bakım anlaşmanız yoksa bile sorun yaşadığınızda bize ulaşabilir, proje bazlı destek alabilirsiniz. Mersin merkezliyiz ama 3 kıtada uzaktan destek veriyoruz, fiziksel olarak yanınızda olmamız gerekmiyor.

Sonuç: Entegrasyon Kod Değil, Süreçtir

ERP entegrasyon projesi planlamak, satır satır kod yazmaktan çok daha geniş bir iştir. Hangi sürüm, hangi yetki, hangi olay hangi kaydı üretecek, hata olunca ne olacak, sürüm güncellenince kim takip edecek — bunların hepsi kod kadar kritiktir.

Yukarıdaki 8 adımlık kontrol listesi size bir harita verir. Her adımı atlarsanız ne olacağını gördünüz: API erişimi geç gelir ve proje gecikir, eşleme tablosu yoksa yanlış kayıt yazılır, hata yakalama yoksa sessiz başarısızlık yaşanır, test edilmezse canlıda patlar, izleme yapılmazsa sürüm güncellemesinde çöker.

Entegrasyon bitmiş bir iş değil, yaşayan bir bakım kalemidir. Logo yeni sürüm çıkarır, sizin kod güncellenmezse çalışmaz. İş süreciniz değişir, entegrasyon uyarlanmazsa yanlış çalışır. Sürekli izleme, düzenli kontrol, proaktif güncelleme gerekir.

D'Cloud Software olarak Mersin'den 3 kıtaya ERP entegrasyon projeleri yönetiyoruz. Size de aynı titizlikle, sabit fiyat ve sözleşmede yazılı garantilerle hizmet veriyoruz.

ERP entegrasyon projesi planlıyorsanız, yukarıdaki kontrol listesini yazdırın, yanınızda bulundurun. Hangi adımı atladığınızı görmek için her maddeyi işaretleyin. Eksik olan adımlar varsa onları tamamlamadan koda başlamayın.

Bizimle ücretsiz online keşif görüşmesi yapmak isterseniz iletişim formundan veya WhatsApp üzerinden ulaşabilirsiniz. Hangi ERP kullanıyorsunuz, hangi platformla entegre etmek istiyorsunuz, iş süreciniz nasıl — bunları dinler, size özel çözüm önerisi ve net fiyat teklifi sunarız. Keşif görüşmesi ücretsizdir, zorlama satış yapmayız.

Entegrasyonunuz sorunsuz, sessiz başarısızlığın olmadığı, sürüm güncellemelerinde çökmeden yaşayan bir sistem olsun. Kod yazmadan önce plan yapın. Plan yaparken bu 8 adımı atlayın.

Doğuhan Bulut
D'Cloud Software