Kurumsal web yönetişimi için RACI modeli nasıl kurulur?

Belirsiz sorumluluk, web sitesini parçalı ve riskli hâle getirir

Kurumsal iletişim metni değiştirir, BT kodu yayımlar, hukuk son anda görüş verir, ajans tasarımı yönetir, SEO ekibi ayrı bir başlık önerir ve iş birimi kendi sayfasını sahiplenir. Bu yapı açık karar kapıları olmadan çalıştığında farklı menü ve footer sürümleri, eski unvanlar, çelişkili iddialar, kontrolsüz scriptler ve kimsenin kaldırmadığı sayfalar oluşur.

RACI, her işi tek ekibe devretmek için değil; çok disiplinli yapıda kararın nerede birleşeceğini göstermek için kullanılır. GOV.UK ve W3C rehberleri de dijital hizmetlerin içerik, ürün, geliştirme, araştırma ve erişilebilirlik becerilerini içeren çok disiplinli ekip ve açık sorumluluklarla yürütülmesini önerir.

RACI harfleri görev değil, karar ilişkisidir

Matris departmanlara değil, karar alanlarına göre kurulmalıdır

• Bilgi mimarisi, menü ve footer sırası.
• Yeni sayfa açma, birleştirme ve kaldırma.
• Kurumsal iddia, sayı, unvan ve mevzuat metni.
• İçerik güncelleme ve kaynak doğrulama.
• Tasarım sistemi ve bileşen değişikliği.
• Kod, altyapı, performans ve sürüm yayını.
• SEO, GEO, metadata, schema ve yönlendirmeler.
• Erişilebilirlik ve kullanıcı testi.
• Çerez, veri toplama, üçüncü taraf script ve gizlilik.
• Güvenlik olayı, yanlış bilgi ve acil düzeltme.
• Analitik, KPI ve dönüşüm raporlaması.
• Tedarikçi ve ajans erişimi.

“Web sitesi — pazarlama sorumludur” gibi tek satırlı matris, teknik ve risk kararlarını görünmez bırakır.

Örnek RACI matrisi kurum yapısına göre uyarlanmalıdır

Bu tablo örnektir; kurumun iş modeli ve yasal rolüne göre değiştirilmelidir. Özellikle hukuk, veri koruma ve güvenlikte yetki ve hesap verebilirlik resmî görev tanımlarıyla uyumlu olmalıdır.

İçerik yayını için konu uzmanı ile editoryal sahip ayrıştırılmalıdır

Konu uzmanı teknik doğruluğu sağlayabilir; ancak kullanıcı ihtiyacı, dil, yapı, başlık ve yayın portföyü editoryal uzmanlık gerektirir. İçerik tasarımcısı da hukuki veya finansal iddianın tek doğrulayıcısı olmamalıdır.

Yayına alınan her içerikte konu sahibi, editoryal sahibi, teknik sürüm ve son gözden geçirme tarihi kayıtlı olmalıdır.

Teknik, SEO ve analitik kararları ortak teslim kapısında birleşmelidir

• Geliştirici kodun çalışmasından; ürün sahibi kullanıcı ve iş sonucundan hesap verir.
• SEO uzmanı öneri üretir; kurumsal iddianın sahibi değildir.
• Schema yalnız görünür ve doğrulanmış içeriği işaretler.
• Canonical, redirect, sitemap ve robots değişikliği teknik ve SEO onayı alır.
• Analitik veya üçüncü taraf script gizlilik ve güvenlik onayı olmadan eklenmez.
• Menü, mobil menü ve footer tek merkezî veri/bileşenden üretilir.
• Yayın öncesi masaüstü, mobil, klavye, zoom ve hata testleri çalıştırılır.

RACI’nin değeri, departmanlar arasında belge dolaştırmak değil; değişikliğin tek kabul kapısından geçmesini sağlamaktır.

Erişilebilirlik, güvenlik ve hukuk son kontrol değil sürekli sorumluluktur

W3C WAI, erişilebilirlik hedeflerinin ve sorumluluklarının organizasyon içinde açıkça atanmasını; ilerlemenin standart raporlama süreçlerine bağlanmasını önerir. Benzer şekilde güvenlik ve gizlilik, yayından hemen önce “onay” istenen tek seferlik kontroller olmamalıdır.

Acil durumlar için normal yayın akışından ayrı yetki tanımlanmalıdır

Yanlış fiyat, kritik güvenlik açığı, hatalı mevzuat bilgisi, ele geçirilmiş sayfa veya kişisel veri olayı normal haftalık yayın toplantısını bekleyemez. Acil RACI; kimin sayfayı geçici kapatacağı, kimin teknik izolasyon yapacağı, kimin hukuk ve iletişim kararını vereceği ve kimin geri dönüş onayı sağlayacağını önceden belirlemelidir.

1. Tespit: Her ekip olay kaydı açabilir.
2. İlk sahiplik: Nöbetçi teknik veya içerik sorumlusu etkiyi sınırlar.
3. Hesap verebilir karar: Olay türüne göre güvenlik, hukuk veya ürün sahibi A olur.
4. Düzeltme: Çalışma kopyası, kanıt ve rollback ile uygulanır.
5. Yayın: İkinci kişi kontrolü ve açık iletişimle devreye alınır.
6. İnceleme: Kök neden, RACI açığı ve kalıcı kontrol kaydedilir.

RACI, ritim ve ölçümle yaşayan bir yönetişim sistemi olmalıdır

• İlk 30 günde bütün web kararlarını ve mevcut fiilî sahipleri envanterleyin.
• Her satırda tek A hedefleyin; gereksiz C ve I listelerini azaltın.
• Görev tanımı ile gerçek erişim yetkilerini eşitleyin.
• Aylık içerik/ürün kurulu, haftalık yayın akışı ve olay kanalı oluşturun.
• Ajans ve tedarikçiyi R veya C yapın; kurum içi A’yı dışarı devretmeyin.
• Personel, tedarikçi veya organizasyon değiştiğinde matrisi güncelleyin.
• Geciken karar, tekrar iş, yayın hatası ve sahipsiz sayfa sayısını ölçün.