Web Tasarım Projesinde En Sık Yapılan 10 Entegrasyon Hatası

Bir web projesi ERP, Netsis, e-ticaret altyapısı, ödeme sistemi, CRM veya şirket içindeki başka yazılımlarla veri alışverişi yapacaksa, iş artık yalnızca tasarım ve ekran geliştirme işi değildir. Ürün kodunun hangi sistemden geleceği, stok bilgisinin ne zaman güncelleneceği, siparişin ERP’ye nasıl aktarılacağı ve başarısız işlemlerin nasıl fark edileceği projenin temel mimarisini belirler.

Bu konular tasarım bittikten sonra düşünülürse, çoğu zaman çalışan ekranların arkasında kırılgan bir sistem oluşur. En sık karşılaşılan hatalar da burada başlar.

1. Entegrasyonu projenin sonuna bırakmak

“Önce web sitesini bitirelim, ERP bağlantısını sonra yaparız” yaklaşımı masum görünür. Uygulamada ise veri yapısının yeniden düzenlenmesine, ekranların değiştirilmesine ve daha önce yazılmış kodların tekrar ele alınmasına yol açabilir.

Entegrasyon ihtiyacı proje başlangıcında bilinmelidir.

Örneğin bir e-ticaret sisteminde ürünler Netsis’ten gelecekse daha tasarım ve yazılım aşamasında şu soruların cevabı gerekir:

• Ürün ana kaydı hangi sistemde tutulacak?

• Fiyatı kim belirleyecek?

• Stok hangi depo veya depolardan hesaplanacak?

• Ürün açıklaması ve görseller hangi sistemde yönetilecek?

• Web sitesinde yapılan değişiklikler ERP’ye geri yazılacak mı?

Bu kararlar alınmadan kurulan ürün yapısı, entegrasyon başladığında mevcut ERP modeliyle uyuşmayabilir.

Piasoft’un Netsis tabloları ve açıklamaları içeriği de Netsis tarafında stoktan faturaya kadar verinin farklı tablolar ve modüller içinde nasıl ayrıldığını görmek isteyen ekipler için yararlı bir teknik referans sunuyor.

2. Verinin gerçek sahibini belirlememek

İki sistem aynı bilgiyi değiştirebiliyorsa bir süre sonra hangisinin doğru olduğu tartışması başlar.

Web sitesinde ürün fiyatı 1.500 TL, ERP’de 1.450 TL olabilir. Bir sonraki senkronizasyonda hangi değer korunacak?

Her veri grubu için bir ana kaynak belirlemek gerekir. Örneğin:

Bu tablo her işletmede farklı olabilir. Asıl mesele, kararın geliştirme başlamadan verilmesidir.

Aksi durumda entegrasyon teknik olarak çalışır fakat sistemler birbirlerinin verisini sürekli değiştirmeye başlar.

3. Alan eşleştirmelerini yalnızca isimlere bakarak yapmak

Bir sistemde stok_kodu, diğerinde product_id bulunması bu iki alanın aynı şeyi ifade ettiği anlamına gelmez.

Entegrasyon projelerinde veri modeli açık biçimde çıkarılmalıdır.

Bir ürün aktarımı örneğinde şu alanların ilişkisi ayrı ayrı tanımlanabilir:

ERP stok kodu → Web ürün kodu

ERP barkod → Web barkod

ERP satış fiyatı → Web liste fiyatı

ERP depo bakiyesi → Web satış stoğu

Basit görünür. Fakat iskonto, varyant, birim, döviz, KDV, depo, cari grup veya fiyat listeleri işin içine girdiğinde bire bir alan eşleştirmesi çoğu zaman yeterli olmaz.

Özellikle Netsis gibi kapsamlı ERP sistemlerinde tabloyu bulmak, veri modelini anlamanın yalnızca ilk adımıdır. Kaydın hangi iş sürecinde oluştuğunu ve diğer tablolarla ilişkisini de bilmek gerekir.

4. Her şeyi anlık senkronize etmeye çalışmak

Gerçek zamanlı veri kulağa her zaman daha iyi gelir. Her zaman gerekli değildir.

Siparişin ERP’ye birkaç saniye içinde aktarılması gerekebilir. Ürün açıklamasının ise birkaç dakikada bir güncellenmesi operasyon açısından hiçbir sorun yaratmayabilir.

Her veri için aynı senkronizasyon yöntemini kullanmak yerine ihtiyaca göre karar verilmelidir.

Bazı veriler olay gerçekleştiğinde API üzerinden gönderilebilir. Bazıları belirli aralıklarla toplu şekilde alınabilir. Çok büyük veri kümelerinde yalnızca değişen kayıtların aktarılması tercih edilebilir.

Buradaki karar teknik gösterişe göre değil, işin ihtiyacına göre verilmelidir.

Binlerce stok kaydını gereksiz yere sürekli sorgulayan bir entegrasyon; ERP, veritabanı ve web sistemi üzerinde yük oluşturur. Daha hızlı olması beklenen mimari, tersine sistemi yavaşlatabilir.

5. Başarısız işlemler için senaryo hazırlamamak

Entegrasyonun başarılı çalışması kadar başarısız olduğunda ne yaptığı da önemlidir.

ERP geçici olarak erişilemiyorsa sipariş ne olacak?

Aynı sipariş ikinci kez gönderilirse ERP’de iki sipariş mi oluşacak?

Bir ürünün stok kodu bulunamazsa tüm aktarım mı duracak, yalnızca ilgili kayıt mı bekleyecek?

Bağlantı birkaç dakika kesildiğinde sistem kaldığı yerden devam edebilecek mi?

Bu sorular proje sırasında cevaplanmamışsa sorun genellikle gerçek siparişler sisteme girmeye başladıktan sonra görülür.

Sağlam bir entegrasyonda başarısız işlem kaybolmaz. Kayıt altına alınır, gerektiğinde tekrar denenir ve teknik ekip problemin ne olduğunu görebilir.

Özellikle sipariş, ödeme, fatura ve stok gibi ticari verilerde bu mekanizma tasarımın parçası olmalıdır.

6. Log tutmayı yalnızca geliştiricinin ihtiyacı sanmak

“Veri gitmedi” entegrasyon projelerindeki en pahalı cümlelerden biridir. Çünkü ardından genellikle başka sorular gelir:

Hangi veri?

Ne zaman gönderildi?

ERP kabul etti mi?

Web sistemi cevap aldı mı?

İşlem tekrar denendi mi?

Hangi kullanıcı veya servis işlemi başlattı?

Bunların cevabı kayıt altına alınmıyorsa hata araştırması tahmine dönüşür.

İyi planlanmış bir log yapısı teknik ekibin yanı sıra operasyon ekibinin işini de kolaylaştırır. Siparişin web sisteminden çıktığı, ERP tarafından kabul edildiği veya hangi hata nedeniyle beklediği görülebilir.

Piasoft’un bakım ve destek yaklaşımında işlemlerin kayıt altına alınması ve takip edilebilir olması da sürdürülebilir sistem yönetiminin bir parçası olarak ele alınıyor.

7. API anahtarlarını ve erişim bilgilerini uygulamanın içine gömmek

Entegrasyon kurulunca iki sistem birbirine erişme yetkisi kazanır. Bu yetki gereğinden geniş tutulursa web uygulamasındaki bir güvenlik açığı ERP veya başka şirket sistemlerine kadar uzanabilir.

API anahtarları, kullanıcı bilgileri ve bağlantı parolaları kaynak kodun içinde açık biçimde tutulmamalıdır.

Servis hesaplarına yalnızca ihtiyaç duydukları yetkiler verilmelidir.

Ürün okuyacak bir servis hesabının muhasebe kayıtlarını silme yetkisine ihtiyacı yoktur. Sipariş oluşturacak entegrasyonun tüm ERP veritabanına sınırsız erişmesi de normal kabul edilmemelidir.

Dışarı açık API noktalarında kimlik doğrulama, yetkilendirme, bağlantı güvenliği ve istek sınırları ayrıca ele alınmalıdır.

Güvenlik, proje bittiğinde yapılan son kontrol değildir. Entegrasyon mimarisinin başlangıç kararlarından biridir.

8. Test ortamı olmadan doğrudan gerçek veriye bağlanmak

ERP entegrasyonunda yanlış oluşturulan bir test siparişi bile muhasebe, stok veya sevkiyat süreçlerine kadar ilerleyebilir.

Bu nedenle geliştirme sırasında mümkünse ayrı bir test ortamı kullanılmalıdır.

Gerçek sisteme geçmeden önce en azından normal işlemlerin yanında sorunlu durumlar da denenmelidir:

Eksik stok kodu.

Geçersiz cari hesap.

Bağlantı kesintisi.

Aynı siparişin iki kez gönderilmesi.

ERP’nin geç cevap vermesi.

Çok sayıda kaydın aynı anda aktarılması.

Beklenmeyen karakterler veya boş alanlar.

İptal ve iade işlemleri.

Yalnızca başarılı senaryoyu test etmek, entegrasyonun gerçekten test edildiği anlamına gelmez. Gerçek hayatta sorun çıkaran kayıtlar zaten kusursuz kayıtlardan oluşmaz.

9. Operasyon ekibini teknik tasarımın dışında bırakmak

ERP entegrasyonunun kurallarını yalnızca yazılımcılar belirleyemez.

Bir siparişin Netsis’e teknik olarak aktarılabiliyor olması, muhasebe veya depo açısından doğru aktarıldığı anlamına gelmez.

Hangi cari hesaba yazılacağı, hangi depo kodunun kullanılacağı, ödeme tiplerinin nasıl eşleştirileceği, iptal edilen siparişin ne yapılacağı veya kargo ücretinin faturaya nasıl taşınacağı işletmenin operasyonuna bağlıdır.

Bu nedenle projede bilgi işlem ekibinin yanında süreci gerçekten kullanan kişilerin de bulunması gerekir.

Satış, muhasebe, depo ve e-ticaret ekiplerinden alınmayan bilgiler geliştirme sırasında varsayımlarla doldurulur. Yazılım projelerinde varsayım, sonradan açılan destek kaydının daha kibar adıdır.

10. Entegrasyonu bir kez yapılıp bitecek iş olarak görmek

Web sistemi değişir. ERP güncellenir. Yeni depo açılır. Pazaryeri eklenir. Fiyatlandırma modeli değişir. Şirket farklı bir ödeme veya kargo sağlayıcısına geçer.

Entegrasyonun bunlara uyum sağlayabilecek şekilde kurulması gerekir.

Kodun yalnızca bugünkü senaryoya göre hazırlanması kısa vadede geliştirme süresini azaltabilir. Altı ay sonra yeni bir satış kanalı eklendiğinde aynı yapı ciddi bir engel haline gelebilir.

Bu yüzden entegrasyon mimarisinde veri modeli, servis katmanı, hata yönetimi, yetkilendirme ve izleme mekanizmaları birbirinden ayrılmalıdır. Yeni sistemlerin mevcut yapıyı mümkün olduğunca az etkileyerek eklenebilmesi hedeflenmelidir.

Piasoft, web yazılım ve özel yazılım projelerinde ERP, CRM ve benzeri kurumsal sistemlerle çalışacak yapıları ihtiyaç analizi aşamasından itibaren planlıyor. Projede yalnızca iki sistem arasında veri göndermek yerine; hangi verinin nerede yönetileceği, sistemlerin nasıl haberleşeceği, hata durumlarının nasıl ele alınacağı ve yayın sonrasında entegrasyonun nasıl izleneceği birlikte kurgulanabilir.

Çünkü çalışan bir entegrasyon “veri A sisteminden B sistemine geçti” demek değildir. Siparişin kaybolmadığı, stok bilgisinin nereden geldiğinin belli olduğu, aynı işlemin yanlışlıkla iki kez oluşmadığı, erişimlerin sınırlandırıldığı ve sorun çıktığında ne olduğunun görülebildiği bir yapı kurmaktır.