Bir web sitesinin kaç günde tamamlanacağını sayfa sayısından çok, arka planda ne yapacağı belirler. Sadece kurumsal bilgileri, hizmetleri ve iletişim alanlarını gösterecek bir siteyle; Netsis’ten stok çeken, e-ticaret siparişlerini ERP’ye aktaran, müşteri hesaplarını eşleştiren ve farklı sistemlerle veri alışverişi yapan bir web uygulamasının geliştirme süresi aynı değildir.
Bu nedenle sağlıklı bir proje takvimi çıkarmak için önce “Kaç sayfa olacak?” sorusundan değil, “Hangi sistem hangi veriyi üretecek, hangisi kullanacak ve veri ne zaman aktarılacak?” sorusundan başlamak gerekir.
Web sitesi yapım süresi neye göre değişir?
Hazır bir tasarımın uygulanacağı, özel bir iş akışı bulunmayan kurumsal web sitesi nispeten hızlı ilerleyebilir. Özel tasarım, yönetim paneli, üyelik sistemi, bayi ekranları, teklif modülü, ödeme altyapısı veya ERP bağlantıları eklendikçe proje yazılım projesine dönüşür.
Bu aşamada kesin bir gün sayısı vermek, ihtiyaçları görmeden teslim tarihi yazmaktan pek farklı değildir. Takvim üzerinde hoş görünür, gerçek sistemler ise bu tür iyimserliklere pek saygı duymaz.
Süreyi en fazla etkileyen konular şunlardır:
-
Tasarımın hazır olup olmaması
-
Sayfa ve içerik yapısı
-
Yönetim panelinin kapsamı
-
Kullanıcı ve yetki seviyeleri
-
ERP, CRM, Netsis, e-ticaret veya başka sistemlerle entegrasyon
-
Ürün, stok, fiyat, sipariş ve cari bilgilerinin nasıl yönetileceği
-
Kullanılacak sistemlerin API imkânları
-
Eski verilerin taşınıp taşınmayacağı
-
Test ve kullanıcı kabul süreçleri
-
Güvenlik ve yetkilendirme gereksinimleri
Özellikle entegrasyon bulunan projelerde “site bitti mi?” sorusu tek başına yeterli değildir. Arayüz tamamlanmış olabilir ama siparişlerin ERP’ye doğru işlendiği, stokların güncellendiği ve hatalı kayıtların kontrol edilebildiği doğrulanmadan sistem tamamlanmış sayılmaz.
İlk aşama tasarım değil, ihtiyaçların çıkarılmasıdır
Web projesi doğrudan ekran tasarlayarak başlatıldığında kritik iş kuralları çoğu zaman geliştirme sırasında ortaya çıkar. Bu da tasarımın, veri modelinin ve yazılımın tekrar tekrar değiştirilmesine yol açar.
Örneğin Netsis ile e-ticaret sitesi arasında ürün aktarımı yapılacaksa önce birkaç temel konu netleşmelidir:
Ürünün ana kaydı hangi sistemde tutulacak? Ürün adı, stok kodu, fiyat, KDV oranı ve stok miktarı aynı kaynaktan mı gelecek? E-ticaret sitesinde değiştirilen bir fiyat ERP’ye geri yazılacak mı? Bir sipariş geldiğinde Netsis tarafında hangi belge oluşturulacak? İptal edilen sipariş veya iade nasıl işlenecek?
Bunlar teknik ayrıntı gibi görünse de doğrudan işletmenin günlük operasyonunu belirler.
Netsis tarafındaki veri yapısını anlamak da projenin önemli parçalarından biridir. Piasoft’un Netsis tabloları ve açıklamaları rehberi, farklı Netsis modüllerinde kullanılan tabloları ve entegrasyonla ilişkili veri yapılarını incelemek isteyen ekipler için teknik bir başlangıç noktasıdır.
Veri akışı kâğıt üzerinde çözülmeden entegrasyona başlanmamalı
İki sistemi birbirine bağlamak, bir tablodaki alanı diğer tablodaki alana göndermekten ibaret değildir.
Örneğin e-ticaret sistemindeki SKU alanının Netsis’te hangi stok koduna karşılık geldiği belirlenebilir. Fakat işler gerçek veriye geldiğinde aynı ürünün varyantları, farklı depolardaki stokları, farklı fiyat listeleri, kampanyaları ve satış birimleri devreye girer.
Bu yüzden entegrasyon öncesinde bir veri eşleme planı hazırlanır. Hangi alanın nereden geleceği, hedef sistemde nereye yazılacağı ve dönüşüm gerekip gerekmediği belirlenir.
Basit bir ürün akışında bile şu yapı ortaya çıkabilir:
Netsis → Web sitesi: stok kodu, ürün bilgisi, stok miktarı, fiyat ve cari bazlı ticari bilgiler.
Web sitesi → Netsis: sipariş, müşteri bilgisi, teslimat bilgisi, ödeme durumu ve sipariş kalemleri.
Her veri çift yönlü olmak zorunda değildir. Hatta gerekmedikçe çift yönlü senkronizasyon kurmak işleri kolaylaştırmak yerine hata ihtimalini artırabilir. Her veri türü için hangi sistemin “ana kaynak” olduğu açıkça belirlenmelidir.
API varsa proje otomatik olarak kolaylaşmaz
Modern sistemlerde entegrasyon için ilk tercih genellikle uygulamanın sunduğu API veya desteklenen servis katmanıdır. Ancak “API var” bilgisi tek başına entegrasyonun hazır olduğu anlamına gelmez.
API’nin hangi işlemleri desteklediğine bakmak gerekir. Ürün okunabiliyor fakat güncellenemiyor olabilir. Sipariş oluşturulabiliyor ancak belirli özel alanlara erişilemiyor olabilir. İstek sınırları, yetkilendirme yöntemi veya sürüm farklılıkları da tasarımı etkileyebilir.
API bulunmadığında veritabanı, dosya aktarımı, ara servis veya sistemin desteklediği başka yöntemler değerlendirilebilir. Doğrudan veritabanına kayıt yazmak ise özellikle ERP tarafında dikkat gerektirir. Bir işlemin ekranda tek kayıt gibi görünmesi, arka planda yalnızca tek tabloyu etkilediği anlamına gelmez.
Netsis kullanan işletmeler için ERP’nin süreç içindeki yerini ayrıca değerlendirmek gerekir. Netsis ERP hakkında Piasoft’un hazırladığı içerikte CRM, e-ticaret platformları ve üçüncü taraf uygulamalarla entegrasyon konusu da ele alınıyor.
Tasarım ve yazılım paralel ilerleyebilir
İhtiyaçlar netleştikten sonra kullanıcıların göreceği ekranlarla sistemin arka plandaki işleyişi birlikte planlanabilir.
Tasarım tarafında sayfa yapıları, mobil kullanım, ürün veya hizmet sunumu, formlar, kullanıcı panelleri ve yönetim ekranları hazırlanır. Yazılım tarafında ise veri modeli, kullanıcı yetkileri, API bağlantıları, iş kuralları ve entegrasyon servisleri geliştirilir.
Özel web yazılım projelerinde yönetim ekranlarının tasarımı da en az ziyaretçinin gördüğü arayüz kadar önemlidir. Bir siparişin ERP’ye aktarılıp aktarılmadığını kontrol etmek için bilgi işlem ekibinin veritabanına girmek zorunda kaldığı sistem, teknik olarak çalışsa bile operasyon açısından eksiktir.
Piasoft’un kurumsal web tasarım ve özel yazılım çözümleri kapsamında web projeleri; özel paneller, süreç otomasyonları, veri yönetimi ve ERP/CRM bağlantılarıyla birlikte ele alınabiliyor.
Entegrasyonda hata olması istisna değil, tasarım girdisidir
İnternet bağlantısı kesilebilir. ERP servisi yanıt vermeyebilir. Aynı sipariş iki kez gönderilebilir. Bir üründe ERP’nin zorunlu tuttuğu alan boş olabilir. Stok kodu eşleşmeyebilir. Bir sistem çalışırken diğeri bakımda olabilir.
Sağlam entegrasyon, bu ihtimalleri yok saymaz.
Örneğin e-ticaret sitesinden ERP’ye sipariş aktarılırken bağlantı kesilirse sistem siparişi kaybetmemelidir. Tekrar denendiğinde aynı siparişi iki kez oluşturmaması da gerekir. İşlem başarısız olduğunda hangi siparişin, hangi tarihte ve hangi nedenle aktarılamadığı görülebilmelidir.
Burada üç mekanizma özellikle gerekir: kayıt tutma, kontrollü tekrar deneme ve işlem kimliği.
Kayıtlar sayesinde veri hareketinin geçmişi izlenebilir. Tekrar deneme mekanizması geçici kesintiler nedeniyle işlemlerin kaybolmasını engeller. Benzersiz işlem kimlikleri ise aynı kaydın istemeden birden fazla oluşturulmasına karşı koruma sağlar.
Bir entegrasyonun kalitesi çoğu zaman her şey yolundayken değil, bir şey ters gittiğinde belli olur.
Güvenlik entegrasyonun sonuna eklenen bir özellik değildir
ERP bağlantılarında fiyat, cari hesap, sipariş, stok, finans veya müşteri verisi taşınabilir. Bu nedenle entegrasyon servisinin kim tarafından ve hangi yetkilerle kullanılabileceği baştan tanımlanmalıdır.
API anahtarlarının veya kullanıcı bilgilerinin kod içine açık şekilde yazılması doğru bir yaklaşım değildir. Bağlantılar şifreli kanallar üzerinden kurulmalı, erişim yetkileri ihtiyaç kadar sınırlandırılmalı ve kritik işlemler kayıt altına alınmalıdır.
Bir başka sorun da gereğinden fazla erişim vermektir. Sadece stok okuyacak bir servis, mümkünse muhasebe kayıtlarını değiştirebilecek bir kullanıcı hesabıyla çalışmamalıdır.
İnternete açık bir web sistemiyle şirket içindeki ERP arasında bağlantı kuruluyorsa ağ mimarisi de ayrıca ele alınır. ERP veritabanını doğrudan internete açmak yerine kontrollü bir servis katmanı kullanmak, erişilebilen işlem alanını sınırlandırmayı kolaylaştırır.
Test, birkaç örnek sipariş göndermek değildir
Entegrasyon testi gerçek hayattaki istisnaları kapsamadığında canlı kullanımda sorun çıkar.
Normal bir siparişin aktarılması elbette denenir. Ardından problem çıkarabilecek kayıtlar test edilir: aynı siparişin yeniden gönderilmesi, iptal, iade, eksik müşteri bilgisi, sistemde bulunmayan stok kodu, sıfır stok, bağlantı kesintisi, hatalı fiyat, farklı KDV senaryoları veya ERP servisinin yanıt vermemesi gibi.
Hangi senaryoların gerekli olduğu işletmenin çalışma biçimine göre değişir.
Test ortamı ile canlı ortamın ayrılması da özellikle ERP bağlantılarında değerlidir. Geliştirme sırasında yapılan denemelerin gerçek cari, stok veya muhasebe kayıtlarına karışması kimsenin cuma akşamı çözmek isteyeceği türden bir sürpriz değildir.
Canlıya geçişte veri kadar operasyon da planlanır
Teknik ekip entegrasyonu hazırlayabilir ancak sistemin günlük kullanım biçimi işletmeyle birlikte belirlenmelidir.
Aktarılamayan siparişleri kim kontrol edecek? Bir ürün eşleşmediğinde kim müdahale edecek? ERP tarafında fiyat değiştiğinde web sitesine ne kadar sürede yansıyacak? Gece yapılan toplu aktarımlar başarısız olursa sorumlu ekip bunu nasıl görecek?
Bu sorular cevapsız bırakılırsa yazılım çalışır, süreç çalışmaz.
İyi bir yönetim panelinde entegrasyon durumunu izlemek mümkün olmalıdır. Son başarılı aktarım zamanı, bekleyen kayıtlar, hatalı işlemler ve hata açıklamaları gerektiği ölçüde kullanıcıya gösterilebilir. Böylece sorun araştırmak için her seferinde geliştiricinin sunucu kayıtlarına bakması gerekmez.
Peki web sitesi kaç günde yapılır?
En doğru cevap, kapsam çıkarıldıktan sonra verilebilir.
Standart kurumsal site, özel tasarımlı web sitesi, e-ticaret projesi ve ERP bağlantılı özel web yazılımı aynı takvimle değerlendirilemez. Entegrasyon bulunan projelerde süreyi özellikle veri modelinin karmaşıklığı, API imkânları, iş kuralları, test senaryoları ve karşı sistemlerden alınması gereken teknik erişimler belirler.
Bu nedenle Piasoft’ta özel web yazılımı ve entegrasyon projesi planlanırken yalnızca görünen ekranlar değil, sistemlerin birbirleriyle nasıl konuşacağı da kapsamın parçasıdır. ERP, Netsis, e-ticaret veya başka kurumsal sistemler arasında kurulacak yapıda veri kaynakları belirlenir, alan eşleşmeleri hazırlanır, güvenli bağlantı yöntemi seçilir, hata senaryoları tanımlanır ve işlemlerin sonradan izlenebileceği bir altyapı kurulur.
Çünkü çalışan bir entegrasyonun ölçüsü veriyi A sisteminden B sistemine gönderebilmesi değildir. Doğru veriyi doğru kaynağa dayanarak aktarması, aynı işlemi gereksiz yere tekrarlamaması, hata çıktığında kaydı kaybetmemesi ve ne olduğunu sonradan gösterebilmesidir.