Aydınlatma metni yükleniyor…
Bağdat Caddesi, Suadiye ve Caddebostan çevresinde birden fazla şube yöneten işletmelerde web yazılımının asıl güçlüğü şube sayısı değil, kararların nerede alınacağıdır. Fiyat, stok, menü, hizmet, kampanya ve rezervasyon verisinin bir bölümü merkezden gelmeli; bir bölümü şubenin gerçek koşullarına göre değişebilmelidir. Sınırlar açık değilse merkez yerel gerçeği ezer, şube ekipleri de aynı verinin birbirinden kopuk kopyalarını üretir.
Bu rehber bölge adını ofis veya yerel başarı iddiası olarak kullanmaz. Gerçekten çok lokasyonlu çalışan markaların merkez–şube veri modeli, yetkileri, entegrasyonları ve kesinti davranışı için uygulanabilir bir teknik brief hazırlamasına yardımcı olur.
Önce kararları merkez, şube ve sistem arasında bölün
Her veri alanını “merkez yönetir” veya “şube yönetir” diye topluca sınıflandırmak yeterli değildir. Ürün kodu ve marka açıklaması merkezden gelirken stok, günlük uygunluk veya geçici kapanış şubeye ait olabilir. Fiyat merkez politikasıyla belirlenip yalnız tanımlı aralıkta yerel değişikliğe izin verebilir.
Her alan için ana kaynak, görüntüleme yetkisi, değişiklik yetkisi, onay gereksinimi, geçerlilik süresi ve eski değere dönüş davranışı yazılmalıdır. Yerel değişiklik sınırsız bir kopya değil; nedeni, süresi ve sahibi kayıtlı bir override olmalıdır.
Merkez–şube işletim zarfı: beş kontrol sınırı
Kumsal Ajans’ın bu içerik için geliştirdiği işletim zarfı, her veri grubunu beş sınırla tanımlar: merkez standardı, yerel esneklik, yayın koşulu, kesinti modu ve mutabakat kanıtı. Böylece “şubeler güncelleyebilir” gibi belirsiz bir gereksinim, test edilebilir iş kuralına dönüşür.
| Veri | Merkez standardı | Yerel hareket alanı |
|---|---|---|
| Ürün/menü | Kod, ad, marka içeriği | Bulunurluk ve geçici gizleme |
| Fiyat/kampanya | Politika ve geçerlilik | İzinli aralık veya katılım |
| Stok | Ürün ve birim kuralları | Sayım, rezervasyon ve düzeltme |
| Rezervasyon | Hizmet, durum ve iptal modeli | Kapasite, personel ve mola |
| Şube bilgisi | Marka ve zorunlu alanlar | Saat, duyuru ve erişim notu |
Ürün, menü ve hizmet modelini tekrar üretmeden yerelleştirin
Merkez kataloğu ürün veya hizmet kimliğini, kategori ağacını, temel açıklamayı ve medya kurallarını tutabilir. Şube katmanı bulunurluk, hazırlama süresi, günlük seçenek veya geçici durumu ekler. Şube, merkez kaydını kopyalayıp bağımsızlaştırmak yerine kimlik üzerinden genişletmelidir.
Merkez bir ürünü değiştirdiğinde yerel alanların korunup korunmayacağı; ürün kaldırıldığında şubedeki rezervasyon veya sipariş geçmişinin ne olacağı belirtilmelidir. İki dil varsa merkez metni güncellendiğinde çeviri ve yerel ek açıklama ayrı “güncelliğini yitirdi” uyarıları almalıdır.
Fiyat ve kampanyada yetki sınırını görünür yapın
Fiyatı kim değiştirebilir, hangi aralıkta, hangi tarihler arasında ve hangi onayla soruları cevaplanmalıdır. Kampanyaya katılan şubeler, hariç ürünler, kanal farkı, çakışan indirimlerin önceliği ve süresi dolan kuralın otomatik kapanması kabul örnekleriyle yazılmalıdır.
Kullanıcıya gösterilen fiyat ile sipariş veya rezervasyon anında hesaplanan fiyat aynı kural motorundan gelmelidir. Arayüzden gelen toplam veya indirim güvenilir kabul edilmemelidir. OWASP, güvenlikle ilgili ve ticari değerlerin sunucu tarafında güvenilir kaynaktan yeniden türetilmesini önerir (OWASP Business Logic Security).
Stok ve rezervasyonu aynı kapasite dilinde buluşturun
Stok yalnız fiziksel sayı değildir; ayrılmış, satışa kapalı, yolda, hasarlı veya sayım bekleyen miktarlar olabilir. Rezervasyonda da çalışan, masa, oda, ekipman ve hazırlık süresi kapasiteyi oluşturur. Her iki alanda “satılabilir/rezervasyon yapılabilir” değeri, ham kayıttan iş kurallarıyla türetilmelidir.
Şube cihazı aynı kaydı iki kez gönderirse işlemin tekrarlanmaması, eşzamanlı taleplerde kapasitenin eksiye düşmemesi ve iptalde doğru hareketin geri alınması gerekir. İşlem anahtarı, durum geçişleri ve yeniden doğrulama teknik kabul listesinde yer almalıdır.
Rol modelini ekran menüsünden değil işlemlerden kurun
“Merkez yönetici”, “şube yöneticisi” ve “personel” adları tek başına yeterli değildir. Hangi rol fiyat görür, değişiklik önerir, onaylar, yayınlar, geri alır, müşteri verisine erişir veya rapor indirir ayrı ayrı tanımlanmalıdır. Kullanıcı birden fazla şubeye atanabiliyorsa kapsam geçici vekâlet ve görev değişimiyle birlikte ele alınmalıdır.
Yetki kontrolü yalnız menüyü gizlemek değildir; her işlem sunucu tarafında kullanıcı, şube, veri alanı ve mevcut duruma göre doğrulanmalıdır. Kritik değişiklikler ikinci onay, neden alanı veya zaman sınırlı yetki gerektirebilir.
Kesinti modunu “site kapalı” seçeneğinin ötesinde tasarlayın
Merkez bağlantısı kesildiğinde şube son bilinen menüyü gösterebilir mi? Yeni rezervasyon kabul edilir mi? Stok doğrulanamıyorsa iletişim talebine mi dönülür? Her fonksiyon için güvenli devam, yalnız okuma, sıraya alma veya durdurma seçeneklerinden biri belirlenmelidir.
Yerel işlemler kuyrukta tutuluyorsa sıra, benzersiz kimlik, zaman ve tekrar deneme bilgisi korunmalıdır. Bağlantı geldiğinde merkez ve şube aynı alanı değiştirmişse otomatik kazanan, insan incelemesi ve uyarı koşulları tanımlanmalıdır. Sessizce “son yazan kazanır” yaklaşımı veri kaybını görünmez kılar.
Mutabakat ve kayıt olmadan entegrasyon işletilemez
Gün sonu veya belirli aralıklarla merkez toplamları ile şube hareketleri karşılaştırılmalıdır. Eksik, tekrarlı, reddedilmiş ve bekleyen kayıtlar ayrı sınıflandırılmalı; farkın sahibi ve çözüm süresi belirlenmelidir. Başarı yalnız API’nin yanıt vermesi değil, iş sonuçlarının tutarlı olmasıdır.
OWASP uygulama loglarında olay türü, sonuç, kimlik, zaman ve izlenebilir bağlamın tutarlı biçimde kaydedilmesini önerir (OWASP Logging Cheat Sheet). Loglar gereksiz kişisel veri ve sır içermemeli; işletme ekibinin “hangi şube neyi ne zaman değiştirdi?” sorusunu yanıtlamalıdır.
Kişisel veriyi lokasyonlar arasında varsayılan olarak açmayın
Müşteri, randevu ve sadakat verisinin bütün şubelerce görülmesi operasyon için gerekli olmayabilir. Erişim amacı, alan kapsamı, saklama süresi, dışa aktarma ve görev sona erdiğinde erişimin kaldırılması tanımlanmalıdır. Kişisel Verileri Koruma Kurumu, verilerin belirli ve meşru amaçlarla bağlantılı, sınırlı ve ölçülü işlenmesini ve gerekli süre kadar saklanmasını genel ilkeler arasında sayar (KVKK temel ilkeler).
Bu bölüm hukuki görüş yerine geçmez. İş modeline, veri kategorisine ve aktarım taraflarına göre yetkili hukuk ve bilgi güvenliği ekiplerinin incelemesi gerekir.
Teklif ve devirde aranacak teslimatlar
- Alan bazlı merkez–şube sahiplik ve override matrisi
- Ürün, fiyat, stok, rezervasyon ve şube bilgisi veri sözlüğü
- Rol–işlem–şube kapsamı yetki tablosu
- Onay, yayın, geri alma ve süre sonu durum makineleri
- Kesinti, kuyruk, tekrar deneme ve çakışma çözüm planı
- Mutabakat raporları, uyarılar, log ve sorumluluk zinciri
- Kişisel veri erişim, saklama ve yetki kaldırma kararları
Teknik briefi derinleştirmek için hazır altyapı ve projeye özel web yazılım rehberini kullanabilir, uygulama kapsamını Kumsal Ajans web yazılım hizmeti üzerinden inceleyebilirsiniz. Sağlam merkez–şube yazılımı, bütün yetkiyi tek tarafa vermek yerine standardı korurken doğrulanmış yerel gerçeğe kontrollü alan açar.