Web Sitesi Hizmeti Kurumsal Çoklu Marka Sitelerinde Yetki ve İçerik Yönetimiyle Nasıl Ölçeklenir?

Çoklu marka web sitesi hizmeti nasıl yapılandırılmalı?

Çoklu marka web sitesi hizmeti, bütün siteleri tek bir yönetim ekranında toplamakla sınırlı görülmemelidir. Ölçeklenebilir yapı; ortak teknoloji çekirdeğini, yeniden kullanılabilir sayfa bileşenlerini ve merkezi güvenlik politikalarını paylaşırken her markanın içerik, görsel kimlik, alan adı ve yayın sorumluluğunu gerektiği ölçüde bağımsız bırakmalıdır. Merkezi platform ile marka özerkliği arasındaki sınır proje başlamadan tanımlandığında yeni siteler eklemek daha öngörülebilir hale gelir.

Ortak çekirdek ve marka katmanını ayırmak

İlk gereksinim çalışmasında marka sayısı kadar markalar arasındaki benzerlik ve farklılıklar da incelenmelidir. Aynı kurumsal yapı, kariyer modülü veya haber bileşeni paylaşılabilirken ürün anlatımı, kampanya sayfaları ve bazı navigasyon yapıları farklı olabilir. Bu karar modeli, çok markalı ve çok dilli web ekosisteminin nasıl kurulacağını değerlendirirken ortak altyapının nerede bitip marka bağımsızlığının nerede başlaması gerektiğini somutlaştırır.

• Ortak teknik çekirdek ve sürüm yapısı
• Marka bazlı alan adı ve görsel kimlik
• Yeniden kullanılabilir sayfa bileşenleri
• Merkezi ve yerel içerik ayrımı
• Dil ve pazar bazlı yapılandırmalar
• Marka ekiplerine tanımlanan yönetim sınırları

“There has to be something that ‘this organization stands for.’”- Peter F. Drucker

Hangi içerikler markalar arasında ortak yönetilmeli?

Markalar arasında ortak yönetilmesi gereken içerikler, kurumsal doğruluğu merkezi olarak korunması gereken veya birden fazla sitede aynı kaynaktan beslenmesi operasyonel fayda sağlayan içeriklerdir. Grup politikaları, ortak insan kaynakları bilgileri, yatırımcı içerikleri veya belirli kurumsal açıklamalar bu modele uygun olabilir. Buna karşılık marka konumlandırması, ürün anlatımı, kampanya içeriği ve yerel pazar mesajları çoğu durumda marka ekiplerinin kontrolünde kalmalıdır.

İçerik sahipliğini tekrar kullanımından ayırmak

Merkezi içerik yönetimi projesinde “ortak içerik” ifadesi yalnızca aynı metnin farklı sitelerde gösterilmesi anlamına gelmemelidir. İçeriğin asıl sahibi, hangi sitelerde kullanılabileceği, yerel ekiplerin düzenleme yetkisi ve kaynak içerik değiştiğinde türevlerin nasıl davranacağı tanımlanmalıdır. Özellikle çok dilli yapılarda içerik modeli; ana kayıt, çeviri, marka varyasyonu ve ülke uyarlaması arasındaki ilişkiyi açık biçimde göstermelidir.

• Grup düzeyindeki kurumsal bilgiler
• Ortak politika ve yönetişim içerikleri
• Markaya özgü ürün ve hizmet anlatımları
• Yerel kampanya ve duyuru içerikleri
• Merkezi içeriklerin dil sürümleri
• Marka veya ülkeye özgü içerik varyasyonları

Editör ve yayın onay yetkileri nasıl ayrılmalı?

Editör ve yayın onay yetkileri, kullanıcıların yalnızca hangi yönetim ekranını görebildiğine göre değil, hangi marka, dil, içerik türü ve işlem üzerinde yetkili olduğuna göre ayrılmalıdır. Bir editör kendi markasının haberlarını hazırlayabilirken grup düzeyindeki kurumsal sayfaları değiştiremeyebilir; başka bir kullanıcı yalnızca belirli dil sürümünü yönetebilir. Rol tabanlı yetkilendirme, teknik erişim ile kurumsal sorumluluğu aynı modelde buluşturmalıdır.

Hazırlama, inceleme ve yayınlama rollerini tanımlamak

Kurumsal CMS yetkilendirme modelinde içerik oluşturma ile doğrudan yayınlama aynı izin olmak zorunda değildir. Kritik içerikler editör, marka yöneticisi ve gerektiğinde merkezi kurumsal iletişim ekibinden geçen bir onay akışına bağlanabilir. Gereksinim matrisi hazırlanırken rollerin hangi sitelerde çalıştığı, kimlerin kullanıcı açabildiği, geri alma yetkisinin kimde olduğu ve acil yayınlarda normal sürecin nasıl değişeceği belirlenmelidir.

• Marka bazlı editör erişimleri
• Dil bazlı içerik yönetim izinleri
• İçerik hazırlama ve taslak yetkileri
• İnceleme ve yayın onayı rolleri
• Kullanıcı ve rol yönetimi sorumluluğu
• Yayın geri alma ve acil müdahale yetkileri

Yeni marka sitesi eklemek ne kadar geliştirme gerektirir?

Yeni marka sitesi eklemek için gereken geliştirme miktarı, yeni sitenin mevcut platform kurallarından ne kadar ayrıldığına bağlıdır. Alan adı, renkler, tipografi, içerik ve mevcut şablonlarla çözülebilen bir marka açılışı çoğunlukla yapılandırma ve içerik çalışması ağırlıklıdır. Yeni içerik modelleri, entegrasyonlar, kullanıcı akışları veya özel bileşenler gerekiyorsa çalışma gerçek bir geliştirme kapsamına dönüşür. Bu nedenle site sayısından tek başına süre veya maliyet çıkarmak sağlıklı değildir.

Yeni site açılışını standart bir sürece dönüştürmek

Kurumsal web platformu geliştirme sırasında yeni marka açılışı için tekrarlanabilir bir süreç tasarlanmalıdır. Alan adı bağlantısı, tema değişkenleri, kullanıcı rolleri, varsayılan sayfalar, dil seçenekleri, analitik yapılandırması ve yayın kontrolleri mümkün olduğunca standartlaştırılabilir. CMS ile sunum katmanının daha bağımsız tasarlanması gereken projelerde CMS ve API tabanlı kurumsal platform mimarisi de değerlendirilebilir; ancak headless yaklaşım her çoklu site projesi için otomatik gereklilik değildir.

• Yeni markanın mevcut şablonlara uyumu
• Alan adı ve teknik yayın yapılandırması
• Tema ve tasarım değişkenlerinin tanımlanması
• Yeni içerik türü veya bileşen ihtiyacı
• Harici sistem ve veri entegrasyonları
• İçerik taşıma ve açılış kontrolleri

Merkezi değişiklikler diğer marka sitelerini nasıl etkiler?

Merkezi bir değişiklik bütün marka sitelerini otomatik olarak ve kontrolsüz biçimde etkilememelidir. Ortak bileşen, güvenlik güncellemesi veya teknik çekirdek değiştiğinde hangi sitelerin aynı sürümü kullandığı ve marka bazlı özelleştirmelerin bu değişiklikten nasıl etkileneceği bilinmelidir. Paylaşılan kodun etkisi sürümleme, test ve geri alma mekanizmalarıyla yönetildiğinde merkezi altyapı avantaj sağlar; aksi durumda tek hata birçok siteye aynı anda taşınabilir.

Ortak sürüm ile marka özelleştirmelerini korumak

Bir marka için yapılan değişikliğin ortak bileşene mi yoksa yalnızca o markanın yapılandırmasına mı ait olduğu geliştirme sürecinde ayrılmalıdır. Çekirdek kodu marka bazlı kopyalamak kısa vadede hızlı görünse de sonraki güvenlik ve özellik güncellemelerinde sürüm parçalanmasına neden olabilir. Bu nedenle değişiklik taleplerinin ortak ürün geliştirmesi, marka özelleştirmesi veya içerik güncellemesi olarak sınıflandırılması bakım operasyonunu daha ölçülebilir hale getirir.

• Ortak çekirdek için sürüm politikası
• Marka yapılandırmalarının çekirdekten ayrılması
• Değişiklik öncesi etki analizi
• Marka bazlı kabul ve regresyon testleri
• Kademeli yayın ve geri alma planı
• Değişiklik ve sürüm kayıtlarının tutulması

Tek platformda güvenlik ve bakım nasıl yönetilmeli?

Tek platformda güvenlik ve bakım, bütün sitelerin aynı uygulamayı kullandığı varsayımıyla tek kalem halinde bırakılmamalıdır. Ortak uygulama çekirdeği, sunucu altyapısı, CMS, eklentiler veya bağımlılıklar, alan adları, sertifikalar, yedekler ve marka bazlı entegrasyonlar farklı sorumluluklara sahip olabilir. Site sayısı arttıkça bakım planı yalnızca hata düzeltmeyi değil izleme, güncelleme, test, yedekleme ve olay müdahalesini de kapsamalıdır.

Bakım kapsamını sorumluluk matrisiyle netleştirmek

Sağlayıcının hangi katmanları yönettiği ve kurumun BT ekibinde hangi sorumlulukların kaldığı sözleşmede ayrıştırılmalıdır. Güvenlik güncellemesi sonrasında bütün marka sitelerinin test edilip edilmeyeceği, içerik hatalarının teknik destek kapsamına girip girmediği ve performans sorunlarının hangi koşullarda inceleneceği açık olmalıdır. web geliştirme bakımında güvenlik, sürüm ve performans kapsamının planlanması, sürekli hizmet teklifindeki kalemlerin ayrıştırılmasına yardımcı olur.

• Uygulama ve bağımlılık güncellemeleri
• Sunucu, yedekleme ve izleme sorumlulukları
• Güvenlik olaylarına müdahale süreci
• Marka siteleri için regresyon kontrolleri
• Performans izleme ve teknik iyileştirmeler
• Destek taleplerinin kapsam ve öncelikleri

İlk platform ve sonraki siteler nasıl tekliflendirilmeli?

İlk platform ile sonraki site açılışları aynı tür iş olarak tekliflendirilmemelidir. İlk aşamada gereksinim analizi, bilgi mimarisi, CMS modeli, yetkilendirme sistemi, ortak bileşenler, teknik altyapı ve ilk marka uygulaması gibi temel yatırım kalemleri bulunur. Sonraki sitelerde ise mevcut altyapının yeniden kullanımı ile markaya özgü tasarım, içerik, veri taşıma ve entegrasyon ihtiyaçları ayrıştırılmalıdır. Böylece çoklu site yönetimi teklifleri yalnızca toplam site adedi üzerinden karşılaştırılmaz.

Kurulum, uyarlama ve sürekli hizmeti ayırmak

Teklifte ilk platform geliştirmesi, her yeni marka için uyarlama modeli, mevcut sitelerden veri taşıma, ekip eğitimi ve sürekli destek ayrı kapsamlar halinde gösterilebilir. Çok dilli içerik veya kapsamlı veri aktarımı gerekiyorsa bunun varsayımları da yazılmalıdır. içerik taşıma, çok dilli yapı ve bakım giderlerinin kapsamlandırılması, ilk yatırım ile devam eden operasyonun birbirine karışmasını önleyen tamamlayıcı bir değerlendirme sunar.

• Platform keşfi ve mimari tasarım
• Ortak CMS ve yetkilendirme geliştirmesi
• İlk marka sitesinin uygulama kapsamı
• Yeni marka için uyarlama kapsamı
• Veri taşıma ve ekip eğitimi
• Sürekli bakım ve destek hizmeti

Çoklu site hizmeti teklifinde hangi teslimler istenmeli?

Çoklu site hizmeti teklifinde yalnızca tasarlanacak sayfa sayısı ve geliştirilecek modüller değil, platformun kurum tarafından nasıl işletileceğini gösteren teslimler de istenmelidir. Yetki matrisi, içerik modeli, marka-site ilişkisi, bileşen envanteri, yayın akışı, bakım sorumlulukları ve yeni site açma prosedürü teklif kapsamına girdiğinde farklı sağlayıcıların çözümleri aynı kriterlerle değerlendirilebilir. İşletilebilir bir platform, teknik teslimin yanında yönetim kurallarının ve devir sürecinin de tanımlandığı platformdur.

Kapsam görüşmesine hazırlıklı başlamak

Teknik görüşme öncesinde marka ve site sayısı, alan adları, diller, mevcut CMS yapıları, içerik hacmi, editör ekipleri, onay seviyeleri, entegrasyonlar ve bakım beklentileri listelenmelidir. Sağlayıcıdan bu gereksinimleri ortak platform, marka bazlı uyarlama ve sürekli işletim başlıklarında ayırması istenebilir. Kod ve operasyon sahipliğinin proje sonrasında nasıl devam edeceğini değerlendirmek için kod sahipliği ve yayın sonrası SLA kriterleri de teklif incelemesine dahil edilebilir.

• Site ve marka mimarisi dokümantasyonu
• İçerik modeli ve yetki matrisi
• Ortak bileşen ve şablon envanteri
• Yayın, test ve geri alma prosedürleri
• Yeni marka açılış kontrol listesi
• Bakım, destek ve devir teslim planı