Aydınlatma metni yükleniyor…
Nişantaşı ve Teşvikiye çevresinde mağaza, showroom, klinik veya randevulu hizmet işleten markalarda web sitesi çoğu zaman tek başına çalışmaz. Stok bilgisi ticari sistemde, uygun saatler takvimde, müşteri kaydı CRM’de, sadakat bakiyesi ayrı bir uygulamada, ürün metinleri ise içerik ekibinde olabilir. Web yazılımının görevi bu kaynakların kopyasını üretmek değil; hangi verinin nereden okunacağını, nerede değiştirileceğini ve uyuşmazlıkta hangi kaynağın geçerli sayılacağını açıkça yönetmektir.
Bu rehber bölge adını fiziksel ofis veya yerel başarı iddiası olarak kullanmaz. Perakende ve hizmet markalarının stok, randevu, müşteri, sadakat ve içerik verilerini kapsayan uygulanabilir bir yazılım briefi hazırlamasına yardımcı olur.
Entegrasyon listesinden önce veri nesnelerini çıkarın
“ERP, CRM ve takvim entegre edilecek” cümlesi kapsam değildir. Önce ürün, varyant, mağaza, stok miktarı, rezervasyon, randevu, müşteri, izin, sadakat hareketi, kampanya ve içerik gibi veri nesnelerini listeleyin. Her nesne için hangi alanların gerekli olduğunu, hangi ekibin sahibi olduğunu ve hangi kullanıcı görevini desteklediğini yazın.
Aynı sistem her alanın ana kaynağı olmak zorunda değildir. Ürün kodu ticari sistemden, pazarlama başlığı içerik platformundan, satışa uygunluk ise stok ve rezervasyon kurallarının birleşiminden gelebilir. Bu yüzden kaynak sahipliği sistem düzeyinde değil, kritik alan düzeyinde kararlaştırılmalıdır.
Veri mutabakat sözleşmesi: altı karar sütunu
Kumsal Ajans’ın bu içerik için geliştirdiği veri mutabakat sözleşmesi, her veri grubunu altı kararla eşleştirir: ana kaynak, yazma yetkisi, senkronizasyon yönü, gecikme toleransı, çakışma kuralı ve kesinti sonrası mutabakat. Bu kayıt, entegrasyon diyagramını işletilebilir bir kabul belgesine dönüştürür.
| Veri grubu | Karar örneği | Kabul kanıtı |
|---|---|---|
| Stok | Ana kaynak, rezervasyon düşümü ve gecikme sınırı | Eşzamanlı talep testi |
| Takvim | Kapasite, süre, mola ve iptal kuralı | Çakışan randevu testi |
| CRM | Müşteri eşleştirme ve güncelleme sahibi | Tekilleştirme senaryosu |
| Sadakat | Hareket defteri, bakiye ve iade sırası | Tekrarlı istek testi |
| İçerik | Ürün alanları, medya ve yayın onayı | Eksik alan/yayın testi |
Stokta “anlık” ifadesini ölçülebilir hale getirin
Stok ekranında sayı mı, “var/yok” durumu mu, yoksa mağaza bazında uygunluk mu gösterileceğini belirleyin. Sepet, mağazadan teslim veya randevu sırasında ürün ayırma varsa rezervasyon süresi ve serbest bırakma koşulu tanımlanmalıdır. Beş dakikalık gecikme bazı kataloglar için kabul edilebilirken sınırlı adetli ürünlerde yanlış satışa yol açabilir.
Kapsam; veri gelmediğinde son bilinen değerin gösterilip gösterilmeyeceğini, bilgiye zaman damgası eklenmesini ve kullanıcıya hangi alternatifin sunulacağını da söylemelidir. “Sistem çalışıyor” testi yerine eşzamanlı iki talep, iptal, iade ve bağlantı kesintisi senaryoları denenmelidir.
Randevu takvimini boş saat listesinden ibaret görmeyin
Uygunluk; çalışan, oda, ekipman, hizmet süresi, hazırlık payı, çalışma saati, tatil ve lokasyon kapasitesinin birleşimidir. Takvim ana kaynağı ile web arayüzü arasında aynı slotun iki kişiye verilmesini önleyen atomik rezervasyon veya yeniden doğrulama adımı bulunmalıdır.
Çok adımlı akışlarda durumun yalnız arayüz tarafından korunması yeterli değildir. OWASP, iş akışlarının sunucu tarafında açık durumlar ve izin verilen geçişlerle modellenmesini önerir (OWASP Business Logic Security). Taslak, beklemede, onaylı, iptal ve tamamlandı durumları ile her geçişi yapabilecek rol briefte yazılmalıdır.
CRM’de tek müşteri kaydının nasıl bulunacağını belirleyin
E-posta, telefon ve mağaza kartı farklı yazım biçimleriyle birden fazla müşteri oluşturabilir. Eşleştirme anahtarı, normalleştirme, olası eşleşmenin insan incelemesine düşmesi ve birleştirme sonrası geçmişin korunması tanımlanmalıdır. Web formu CRM’de hangi alanları açabilir, hangilerini yalnız okuyabilir sorusu ayrıca yanıtlanmalıdır.
İzin, iletişim tercihi ve profil bilgisi aynı şey değildir. Bir kanaldaki değişiklik diğer kanallara otomatik yayılacaksa hukuki dayanak, zaman damgası ve kaynağı izlenebilmelidir. Kişisel Verileri Koruma Kurumu; kişisel verilerin doğru ve gerektiğinde güncel, belirli ve meşru amaçlarla bağlantılı, sınırlı ve ölçülü, gerekli süre kadar saklanması ilkelerini belirtir (KVKK temel ilkeler). Veri alanlarını “ileride lazım olur” düşüncesiyle çoğaltmak yerine amaç ve saklama kararıyla sınırlandırın.
Sadakat bakiyesini değiştirilebilir bir sayı değil hareket defteri olarak kurun
Puan kazanma, kullanma, iptal, iade, süre sonu ve manuel düzeltme ayrı hareketler olmalıdır. Bakiye bu hareketlerden hesaplanır; geçmişteki kaydı sessizce değiştirmek yerine ters kayıt oluşturulur. Aynı isteğin ağ hatası nedeniyle yeniden gönderilmesi ikinci kez puan yazmamalıdır. Bunun için her işlem benzersiz bir anahtar ve açık sonuç durumu taşımalıdır.
Kampanya kuralı değiştiğinde geçmiş hareketlerin etkilenip etkilenmeyeceği, yuvarlama ve para birimi davranışı ile mağaza–web arasında kullanım sırası kabul örnekleriyle belirlenmelidir.
Ürün içeriği ve ticari alanların sahipliğini ayırın
Ürün kodu, fiyat ve stok gibi ticari alanları içerik editörünün değiştirmesi risklidir; başlık, açıklama, görsel, kullanım önerisi ve SEO alanları ise ticari sistemde yönetilemeyebilir. Alan bazlı sahiplik, zorunlu alan, yayın onayı ve eksik veri davranışı tanımlayın. Kaynaktan silinen ürünün webde hemen kaldırılması mı, arşivlenmesi mi gerektiğine ayrıca karar verin.
İki dilde içerik kullanılıyorsa çeviri tamamlanmadan yayın, kaynak metin değiştiğinde uyarı ve locale özel görsel kuralları belirlenmelidir. Böylece veri senkronizasyonu yanlışlıkla bütün içerik editörlüğünün yerine geçmez.
Senkronizasyon yöntemini veri ihtiyacına göre seçin
Her alanın gerçek zamanlı akması gerekmez. Stok ve randevu olay bazlı aktarım veya işlem anında doğrulama isteyebilir; içerik ve kampanya gecelik ya da onay sonrası aktarılabilir. Yöntemi sistem alışkanlığına göre değil, kabul edilen gecikme, işlem hacmi ve hata maliyetine göre seçin.
Her akış için yeniden deneme sayısı, artan bekleme, zaman aşımı, sıra dışı bırakma, manuel tekrar ve geriye dönük mutabakat işi tanımlanmalıdır. Kaynak sistem bir süre kapalı kaldığında kaçırılan kayıtların hangi aralıkla ve hangi kimlikle geri alınacağı net değilse entegrasyon tamamlanmış sayılmaz.
Kayıt ve izleme operasyon ekibinin sorularını yanıtlamalıdır
“Neden bu müşterinin puanı düşmedi?”, “hangi sistem randevuyu iptal etti?” veya “stok ne zaman güncellendi?” soruları işlem kimliği, kaynak, zaman, eski/yeni durum ve sonuç olmadan yanıtlanamaz. OWASP, uygulama olay kayıtlarının tutarlı sınıflandırılmasını ve olayların yeniden kurulmasına yetecek iz bırakmasını önerir (OWASP Logging Cheat Sheet).
Loglara gereksiz kişisel veri veya sır yazılmamalı; erişim, saklama ve maskeleme kuralları belirlenmelidir. İş göstergeleri de teknik hata oranından ayrı izlenmelidir: stok güncelliği, randevu çakışması, CRM tekilleştirme kuyruğu, sadakat mutabakat farkı ve başarısız içerik yayını gibi.
Teklifte ve devirde aranacak teslimatlar
- Veri nesnesi ve alan sahipliği kataloğu
- Ana kaynak, okuma/yazma yetkisi ve senkronizasyon yönü matrisi
- Gecikme, zaman aşımı, yeniden deneme ve çakışma kuralları
- Stok, randevu, CRM, sadakat ve içerik için hata senaryoları
- Kişisel veri amacı, erişim, saklama ve silme kararları
- Olay kayıtları, uyarılar, işletme göstergeleri ve sorumlular
- Test verisi, kabul senaryoları, rollback ve manuel işletim planı
Bu çerçeveyi ayrıntılı kapsam belgesine dönüştürmek için hazır altyapı ve projeye özel web yazılım rehberini kullanabilir, uygulama yaklaşımını Kumsal Ajans web yazılım hizmeti üzerinden inceleyebilirsiniz. Sağlam entegrasyon, çok sayıda sistem bağlamak değil; her verinin sahibi, geçerlilik süresi ve hata anındaki davranışı üzerinde anlaşmaktır.