"Siteden gelen siparişler muhasebeye otomatik düşsün. Basit bir bağlantı, değil mi?"
Bu cümleyle başlayan projelerin çoğu, tahmin edilenin iki-üç katı sürüyor. Sebebi teknik zorluk değil — entegrasyonun aslında bir veri anlaşması olması.
İki sistem birbirine bağlanmıyor; iki farklı dünya görüşü uzlaştırılıyor.
Bağlantıyı kurmak (API'ye istek atmak) genelde işin küçük kısmı. Zaman şurada gidiyor:
Ürün eşleşmesi. Sitedeki ürün kodu ile ERP'deki stok kodu aynı mı? Genelde değil. Sitede "TRK-001", ERP'de "0012345". Eşleştirme tablosu kim tutacak, yeni ürün eklendiğinde ne olacak?
Varyant sorunu. Sitede "Kırmızı / L" tek üründür; ERP'de her varyant ayrı stok kartı olabilir — ya da hiç varyant kavramı yoktur.
Fiyat ve KDV. Sitede KDV dahil gösteriliyor, ERP'de hariç tutuluyor. Yuvarlama farkları kuruş kuruş birikiyor ve mutabakatta patlıyor.
Müşteri kaydı. Site müşterisi e-posta ile tanımlı, ERP'de vergi numarası ile. Aynı kişi iki farklı adresle sipariş verdiğinde tek cari mi açılacak, iki mi?
İskonto ve kampanya. Sitede uygulanan indirim ERP'ye nasıl yansıyacak — satır indirimi mi, genel iskonto mu, yoksa farklı fiyattan mı?
Bu soruların cevabı teknik değil, işletmeye ait. Ve genelde ilk kez bu projede soruluyor.
Mutlu yol (sipariş geldi, ERP'ye düştü) işin en kolayı. Zaman şurada gidiyor:
Her senaryo için bir karar ve bir kod yolu gerekiyor. Toplamı, mutlu yolun birkaç katı.
Deneyimimizde entegrasyon projelerinin %60–70'i hata senaryolarına gidiyor. Teklifte bu kalem yoksa süre tahmini gerçekçi değildir.
Basit görünen ama sonradan pahalıya patlayan soru: veri hangi yöne akıyor?
Çift yönlü entegrasyonlarda "hangisi doğruyu söyler" kuralı yazılı olmalı. Yoksa bir gün stoklar tutmuyor ve kimse neden olduğunu bulamıyor.
Türkiye'de yaygın ERP'lerin (Logo, Netsis, Mikro) entegrasyon imkânları sürümüne göre değişiyor:
Üçüncüsü riskli: doğrudan tabloya yazmak, ERP'nin kendi iş kurallarını atlamak demek. Program içinden yapıldığında tetiklenen kontroller çalışmıyor ve veri sessizce bozulabiliyor.
Projeye başlamadan ERP tedarikçinizden şunu yazılı isteyin: hangi sürüm, hangi entegrasyon yöntemi, ek lisans gerekiyor mu, dokümantasyon var mı?
Bu tek e-posta, sonradan çıkan sürprizlerin çoğunu baştan görünür kılıyor.
Canlı ERP üzerinde test yapılmaz — ama çoğu firmada test ortamı yok.
Kurulmazsa iki seçenek kalıyor: canlıda dikkatli çalışmak (riskli) veya sahte veriyle çalışıp canlıda sürpriz yaşamak.
Test ortamı kurmak projenin başında birkaç günlük iş; kurulmadığında maliyeti bozulan canlı veri oluyor. Bu kalemi kısmayın.
Sistem çalışmaya başladıktan sonra biri şu soruyu soracak: "Dün 42 sipariş geldi, ERP'de 40 tane var. İkisi nerede?"
Bu soruya cevap verebilmek için baştan kurulması gerekenler:
Bu üçü yoksa entegrasyon çalışıyor gibi görünüyor ama kimse emin olamıyor. Ve güvenilmeyen otomasyon, elle kontrol yükü ekliyor — yani çözdüğü sorunu geri getiriyor.
Tek yönlü, orta karmaşıklıkta bir sipariş entegrasyonu için:
| Aşama | Süre |
|---|---|
| Analiz ve veri eşleme kararları | 1–2 hafta |
| Test ortamı ve erişimler | 3–5 gün |
| Geliştirme (mutlu yol) | 1–2 hafta |
| Hata senaryoları ve tekrar deneme | 2–3 hafta |
| Test ve mutabakat | 1–2 hafta |
Toplam 6–10 hafta. "Bir haftada bağlarız" diyen bir teklif, yukarıdaki kalemlerin çoğunu kapsamıyor demektir.
En sık verdiğimiz tavsiye: ilk aşamada tek yön ve tek veri tipi.
Örneğin yalnızca "onaylanmış sipariş → ERP". Stok, iade, cari güncelleme sonraki fazda.
Çalışan küçük bir entegrasyon, yarım kalmış büyük bir entegrasyondan kıyaslanamayacak kadar değerli — hem işe yarıyor hem sonraki fazın gerçek ihtiyacını gösteriyor.
Kapsamın nasıl kayabileceği ayrı bir yazıda: yazılım projesinde kapsam kayması.
Entegrasyon ihtiyacınızı ve gerçek kapsamını birlikte çıkaralım — projenizi anlatın.
Etiketler
Bu konuda destek
Yazıda anlatılan adımları kendi sitenizde uygulamak istiyorsanız ya da nereden başlayacağınızı bilmiyorsanız, kısa bir görüşmeyle durumu birlikte değerlendirelim.
İlk görüşme ve teklif ücretsiz. Kapsamı birlikte çıkarıp size kalem kalem yazılmış bir teklif gönderiyoruz.