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 3 ile Logo GO 3'ün sunduğu arayüzler aynı değildir: REST Servis Tiger 3'te desteklenir, GO 3 ise desteklenmeyenler arasında sayılır. Mikro'da servisin dinlediği port V16 ile V17 arasında değişir. Nebim V3'te geliştirici dokümanı herkese açık olmadığı için arayüz kurulumda netleşir.

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.

Tipik bir durum: Entegrasyon, ürünün güncel sürümündeki arayüze göre yazılır. Canlıdaki kurulum ise bir sürüm geridedir ve o arayüz orada yoktur. Bu fark canlıya geçişte ortaya çıkar; ek geliştirme ve gecikme demektir.

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

Birçok üründe resmi arayüzün kullanımı ayrı bir lisansa ya da başvuruya bağlıdır. Logo Objects run-time lisansı gerektirir. Mikro Desktop API için API Key başvurusu yapılır. DİA'da API anahtarı üreticiden talep edilir. ETA'da Transfer ve Veri Aktarma ayrı modüllerdir ve lisansınızda olmayabilir. Arayüzün türü de üründen ürüne değişir: COM nesnesi, REST servisi, web servisi ya da dosya aktarımı.

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. Bu süreç günler de sürebilir, haftalar da; lisans bayi üzerinden alınmışsa talep önce bayiye, oradan üreticiye gider.

Örnek senaryo: Bir gıda firmasında Logo Tiger entegrasyonuna başlanır, ancak Logo Objects run-time lisansının olmadığı sonradan fark edilir. Önce lisans temini, sonra kurulum, ardından yetkilendirme gerekir. Bu bekleme proje takvimine yazılmamışsa ciddi gecikme 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.

Örnek senaryo: 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 çoğu 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: Mikro'da büyük sürüm geçişinde servisin dinlediği port değişir: V16'da 8084, V17'de 8094. Portu koda sabit yazmış bir entegrasyon, yükseltmenin ertesi günü bağlantı kuramaz. Çözüm: değişmeye açık değerleri yapılandırmada tutmak, sürüm notlarını izlemek ve yükseltmeden önce test etmek.

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?

Ürün, sürüm ve kapsam bilinmeden verilen süre tahmindir. Yalnızca stok ve fiyat okuyan bir entegrasyon ile sipariş, fatura, cari ve iade akışını kapsayan çift yönlü bir entegrasyon aynı iş değildir. Süreyi en çok şunlar etkiler: arayüz erişiminin ve lisansın açılma süresi, test ortamının olup olmaması, iş süreçlerinin yazılı tanımlanmış olması ve eşleme tablolarının hazır olması. Keşif görüşmesinden sonra yazılı bir takvim veriyoruz ve takvim sözleşmeye giriyor.

Hangi ERP sistemleri ile entegrasyon yapıyorsunuz?

Logo, Netsis, Mikro, Zirve, ETA, Wolvox, Nebim, Luca, DİA, Paraşüt, SAP Business One ve Dynamics 365 Business Central için entegrasyon geliştiriyoruz. Hiçbirinin bayisi ya da çözüm ortağı değiliz; bağımsız bir yazılım firmasıyız. Yöntem, ürünün sunduğu arayüze göre belirlenir: bazı ürünlerde belgelenmiş bir API vardır, bazılarında iş dosya aktarımı üzerinden yürür. Okuma için veritabanı sorgusu kullanılabilir; yazmayı ise doğrudan veritabanına yapmıyoruz, ürünün resmi arayüzünü kullanıyoruz. Keşif görüşmesinde ürününüzü, sürümünüzü ve arayüz durumunu birlikte netleştiriyoruz.

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 geçiş 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.

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. Kendi ekibinizle yaparsanız bu bilgiyi öğrenmenin de bir maliyeti olur: zaman ve deneme yanılma. Bir de şu var: işiniz ERP entegrasyonu değil, kendi ürününüzü satmak. Ekibinizin zamanını nereye harcayacağınız, fiyat kadar önemli bir karardır.

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, Mersin merkezli bağımsız bir yazılım firmasıdır. ERP entegrasyonunu sabit fiyatla ve sözleşmede yazılı koşullarla geliştiriyoruz; teslim sonrası 15 gün hata düzeltme ücretsizdir.

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ı atlamayın.