Bir müşteri web sitesinden sipariş verdiğinde iş aslında “sipariş alındı” ekranında bitmez. Ürün kodunun ERP’de karşılığı bulunmalı, doğru fiyat ve cari bilgiler kullanılmalı, stok hareketi oluşmalı, gerekiyorsa sipariş üretim veya sevkiyat sürecine aktarılmalı. ERP’de yapılan değişikliklerin de gerektiği ölçüde web sitesine geri dönmesi gerekir.
Web sitesi, ERP ve özel yazılım entegrasyonunun asıl konusu budur: Verinin bir sistemden diğerine gönderilmesi değil, farklı sistemlerde aynı iş sürecinin tutarlı biçimde devam etmesi.
Örneğin işletme Netsis kullanıyor, ürünlerini kendi web sitesi veya e-ticaret sistemi üzerinden satıyor ve standart yazılımların karşılamadığı operasyonları yönetmek için özel bir yazılıma sahipse üç ayrı veri dünyası oluşabilir. Entegrasyon doğru kurulmadığında aynı stok üç yerde farklı görünebilir, müşteri kayıtları çoğalabilir veya web siparişi ERP’ye eksik aktarılabilir.
Bu nedenle geliştirmeye başlamadan önce “Hangi sistemi hangisine bağlayacağız?” sorusundan daha temel bir sorunun cevabı verilmelidir:
Hangi verinin asıl sahibi hangi sistem?
Entegrasyon veri sahipliğiyle başlar
Bir ürünün stok miktarını ERP yönetiyorsa web sitesi bu bilginin ikinci kaynağı olmamalıdır. Web sitesi stoğu gösterir; stok bilgisinin kaynağı ERP olur. Ürün açıklamaları ve görseller web yönetim panelinden yönetiliyorsa ERP’nin de bu alanları değiştirmeye çalışması gereksizdir.
Aynı karar müşteri, fiyat, iskonto, sipariş, ödeme, fatura ve sevkiyat verileri için ayrı ayrı verilmelidir.
Basit bir yapı şöyle kurgulanabilir:
| Veri | Ana sistem | Veri akışı |
|---|---|---|
| Stok miktarı | ERP | ERP → Web |
| Ürün fiyatı | ERP veya özel fiyat sistemi | ERP → Web |
| Ürün görselleri | Web yönetim paneli | Web içinde yönetilir |
| Web siparişi | Web / e-ticaret | Web → ERP |
| Cari kart | ERP | İhtiyaca göre çift yönlü |
| Sipariş durumu | ERP | ERP → Web |
| Ödeme bilgisi | Web / ödeme altyapısı | Web → ERP |
| Sevkiyat bilgisi | ERP veya lojistik sistemi | ERP → Web |
Bu tablo her işletmede aynı çıkmaz. Bayiye özel fiyat kullanan bir şirket ile doğrudan tüketiciye satış yapan işletmenin veri modeli doğal olarak farklıdır.
Netsis tarafında da entegrasyon yapılacak verinin hangi modül ve yapıda bulunduğunu bilmek gerekir. Piasoft'un Netsis tabloları ve açıklamaları rehberi, stoktan faturaya, cari işlemlerden entegrasyon kayıtlarına kadar Netsis veritabanındaki tabloları modül bazında incelemek için kullanılabilir.
Veri aktarım yöntemi iş sürecine göre seçilir
Her entegrasyon gerçek zamanlı çalışmak zorunda değildir. Hatta bütün verileri anlık aktarmaya çalışmak gereksiz yük ve karmaşıklık yaratabilir.
Sipariş gibi operasyonu doğrudan etkileyen bir işlem mümkün olduğunca hızlı aktarılmak istenir. Buna karşılık binlerce ürünün belirli raporlama verileri birkaç dakikada veya belirlenmiş zamanlarda senkronize edilebilir.
Teknik tarafta API, web servisleri, ara entegrasyon uygulamaları ve zamanlanmış görevler gibi farklı yöntemler kullanılabilir. Hangi yöntemin uygun olduğu mevcut ERP sürümüne, erişilebilen servislerin yeteneklerine, veri hacmine, aktarım sıklığına ve iş kurallarına bağlıdır.
Doğrudan ERP veritabanına erişim de bazı projelerde gündeme gelir. Okuma amaçlı sorgular ile ERP'ye işlem yazmak ise aynı risk düzeyinde değildir. Özellikle sipariş, fatura, stok veya muhasebe hareketi oluştururken ERP'nin kendi iş kurallarını atlayan doğrudan veritabanı işlemleri veri bütünlüğü sorunlarına yol açabilir. Kullanılabilecek resmi servis veya uygulama katmanı varsa öncelikle bunun değerlendirilmesi gerekir.
Entegrasyon tasarımında teknik olarak “veriye ulaşabiliyor olmak”, o veriye istenen şekilde müdahale etmenin doğru olduğu anlamına gelmez.
Alan eşleştirmesi küçük görünür, sorunların önemli kısmı burada çıkar
İki sistem aynı üründen söz ediyor olabilir ama ürünü aynı biçimde tanımayabilir.
ERP'de STK-001 koduyla bulunan ürün web sisteminde farklı bir dahili ID ile tutulabilir. ERP fiyatı KDV hariç saklarken web sitesi KDV dahil gösterebilir. Bir sistemde müşteri vergi numarası temel eşleştirme alanıyken diğerinde e-posta adresi esas alınmış olabilir.
Entegrasyon başlamadan önce alan eşleştirme tablosu hazırlanması bu nedenle faydalıdır:
ERP stok kodu → Web ürün kodu
ERP cari kodu → Web müşteri ID
ERP fiyat tipi → Web satış fiyatı
ERP sipariş numarası → Web ERP referansı
Burada yalnızca alan isimleri belirlenmez. Veri tipi, zorunluluk durumu, karakter sınırı, para birimi, vergi hesaplama biçimi ve boş değerlerin nasıl ele alınacağı da tanımlanır.
Aksi halde teknik bağlantı başarıyla çalışırken operasyon yanlış veri üretmeye başlayabilir. En tehlikeli entegrasyon hataları da zaten bağlantının tamamen kesildiği durumlar değildir. Sistem çalışıyor görünürken yanlış kayıt üretmesidir.
Çift yönlü entegrasyonda çakışma kuralları gerekir
Web sitesi ERP'den stok alıyor, ERP de web sitesinden sipariş alıyorsa iki yönlü bir trafik vardır. Özel yazılım da sürece girdiğinde hangi sistemin hangi kaydı değiştirebileceği açıkça tanımlanmalıdır.
Bir müşteri adresini web sitesinden değiştirdi. Aynı cari kartın adresi ERP'de de değiştirildi. Hangisi geçerli?
ERP'deki ürün satışa kapatıldı fakat web tarafındaki güncelleme henüz gerçekleşmedi. Ürün siparişe açık kalacak mı?
Web siparişi ERP'ye aktarıldı ancak ERP'de aynı sipariş daha önce oluşturulmuşsa ne yapılacak?
Bu sorular kod yazılırken geliştiricinin vereceği kararlar olmamalıdır. İş kuralları proje başında belirlenmelidir.
Özellikle tekrar gönderilen işlemler için aynı siparişin iki kez oluşmasını engelleyen kontroller gerekir. Sipariş numarası, işlem kimliği veya entegrasyona özel benzersiz bir referans kullanılabilir. Böylece bağlantı kesilip yeniden kurulduğunda sistem aynı işlemi ikinci kez kaydetmek yerine daha önce işlenip işlenmediğini kontrol eder.
“Aktarılamadı” tek başına yeterli bir hata yönetimi değildir
ERP entegrasyonunda hata kaçınılmazdır. Ağ bağlantısı kesilebilir, ERP servisi cevap vermeyebilir, stok kodu bulunamayabilir, zorunlu cari alanı boş gelebilir veya karşı sistem beklenmeyen bir değer döndürebilir.
Sağlıklı bir entegrasyon bu durumları önceden hesaba katar.
Bir web siparişinin ERP'ye aktarılamadığını düşünelim. Sipariş kaybolmamalı ve kullanıcıdan yeniden sipariş vermesi istenmemelidir. İşlem hata durumuna alınabilir, hata nedeni kaydedilebilir ve uygun hatalarda belirli kurallarla yeniden denenebilir. İnsan müdahalesi gerekiyorsa bilgi işlem veya ilgili operasyon ekibi hangi kaydın neden beklediğini görebilmelidir.
Burada log tutmak tek başına yeterli değildir. Logun cevap verebildiği sorular önemlidir:
Hangi kayıt gönderildi? Ne zaman gönderildi? Hangi sistem gönderdi? Karşı sistem ne cevap verdi? İşlem başarılı mıydı? Başarısızsa neden? Tekrar denendi mi?
Bu bilgiler yoksa birkaç ay sonra ortaya çıkan “Bu sipariş neden ERP'ye düşmedi?” sorusu veritabanları ve sunucu kayıtları arasında yapılan pahalı bir dedektiflik çalışmasına dönüşür. Yazılım dünyasının insanlığa bıraktığı daha az romantik gizemlerden biri.
Güvenlik entegrasyon katmanında ayrıca ele alınmalı
Web sitesinin internete açık olması, ERP'nin de internete doğrudan açılması gerektiği anlamına gelmez.
Entegrasyon mimarisi hazırlanırken hangi sistemin hangi ağa erişeceği, API veya servis kimlik bilgilerinin nerede tutulacağı, hangi kullanıcının hangi işlemleri yapabileceği ve bağlantının nasıl korunacağı belirlenmelidir.
Entegrasyon hesabına gereğinden fazla yetki vermemek temel kurallardan biridir. Sadece stok okuyacak bir servis hesabının muhasebe kayıtlarını değiştirebilmesi için bir neden yoktur.
Aynı yaklaşım özel yazılıma da uygulanır. Yönetim panelinde fiyat değiştirebilen kullanıcı ile yalnızca sipariş görüntüleyen kullanıcının yetkileri ayrılmalıdır. Kritik işlemlerde kullanıcı ve işlem kayıtlarının tutulması, sonradan yapılacak kontrolleri de kolaylaştırır.
Kişisel ve ticari verilerin gereksiz yere sistemler arasında çoğaltılmaması gerekir. Entegrasyon “veritabanındaki her şeyi karşı tarafa gönderelim” yaklaşımıyla değil, iş sürecinin gerçekten ihtiyaç duyduğu alanlarla kurulmalıdır.
Özel yazılım entegrasyonda ne işe yarar?
ERP ile web sitesi arasında doğrudan bağlantı her zaman yeterli olmaz. İşletmenin kendi kuralları araya girdiğinde özel yazılım bir entegrasyon ve süreç katmanı olarak çalışabilir.
Örneğin web sitesinden gelen sipariş doğrudan ERP'ye gönderilmeden önce bayi koşulları kontrol edilebilir, ürün kodları eşleştirilebilir, sipariş farklı depolara ayrılabilir veya işletmeye özgü onay sürecinden geçirilebilir.
Başka bir projede özel yazılım ERP'den aldığı stok ve fiyatları birden fazla satış kanalına dağıtabilir. Kanallardan gelen siparişleri ortak biçime dönüştürüp ERP'ye aktarabilir. Yönetim ekranından da başarılı, bekleyen ve hatalı işlemler takip edilebilir.
Piasoft, özel web yazılım çözümlerinde ERP, CRM, stok ve benzeri kurumsal sistemlerle çalışabilecek yapıların proje ihtiyacına göre planlandığını belirtiyor. Süreç ihtiyaç analizi, teknik planlama, geliştirme, test ve yayın sonrası desteği kapsayacak şekilde ele alınıyor.
Canlıya geçmeden önce gerçek operasyon test edilmeli
“API çalışıyor” entegrasyon testinin tamamlandığı anlamına gelmez.
Test ortamında normal bir sipariş kadar sorun çıkarabilecek kayıtlar da denenmelidir: ERP'de bulunmayan ürün, sıfır stok, iptal edilen sipariş, aynı siparişin ikinci kez gönderilmesi, bağlantının işlem sırasında kesilmesi, geçersiz müşteri bilgisi, farklı KDV veya iskonto koşulları, ERP servisinin geç cevap vermesi gibi.
Test planının işletmenin gerçek operasyonuna göre hazırlanması gerekir. Üretim yapan bir şirkette kritik senaryolar ile sadece stoktan satış yapan bir e-ticaret işletmesinin kritik senaryoları aynı değildir.
Canlıya geçişten sonra da ilk işlemler yakından izlenmelidir. Hangi kayıtların ne kadar sürede aktarıldığı, bekleyen işlemler ve tekrarlanan hatalar görülebilmelidir. Piasoft'un bakım ve destek hizmetlerinde de teknik taleplerin kayıt altına alınması, önceliklendirilmesi ve yapılan işlemlerin takip edilebilir olması sürecin parçası olarak tanımlanıyor.
İyi entegrasyon görünmez çalışır, gerektiğinde ayrıntısını gösterir
Web sitesi, Netsis veya başka bir ERP ve işletmeye özel yazılım birlikte çalışacaksa proje kapsamını “ERP'den web sitesine veri aktarımı” şeklinde tanımlamak eksik kalır.
Asıl tasarlanması gereken veri yaşam döngüsüdür.
Hangi sistem ana kaynak olacak? Hangi kayıt ne zaman aktarılacak? Alanlar nasıl eşleşecek? Aynı işlem ikinci kez gelirse ne olacak? Bağlantı kesilirse veri nerede bekleyecek? Hata kimin ekranına düşecek? Bir kaydın geçmişi nasıl izlenecek? Hangi servis hangi verilere erişebilecek?
Bu sorular netleştiğinde entegrasyon, birbirine kabloyla bağlanmış üç yazılım olmaktan çıkar ve yönetilebilir bir iş sürecine dönüşür.
Piasoft; web sitesi, özel yazılım ve ERP tarafındaki ihtiyaçları birlikte değerlendirerek veri modeli, entegrasyon akışları, yetkilendirme, hata yönetimi, test ve yayın sonrası bakım süreçlerini uçtan uca planlayabilir. Özellikle Netsis kullanılan yapılarda mevcut ERP verisinin ve işletmenin gerçek iş akışının geliştirmeden önce analiz edilmesi, kurulacak entegrasyonun sınırlarını doğru belirlemek için başlangıç noktasıdır.