Kurumsal İntranet Portalı: Mobil Öncelik, Kişiselleştirme ve Yönetişim
İntranet portallarının çoğu masaüstü için tasarlanıp mobile sıkıştırılıyor, kişiselleştirme ise rol tabanlı bir vaat olarak kalıyor. Portalın değeri tek bir şeyle ölçülür: çalışan aradığını kaç adımda buluyor. Mobil öncelik, kişiselleştirmenin bakım maliyeti ve içerik sahipliğinin kimde olduğu, o sayının üç belirleyicisi.
Portal artık kapı değil, çalışma yüzeyi
İntranetin ilk kuşağı bir bağlantı listesiydi. Bugün beklenen şey farklı: izin sistemi, bordro, dosya arşivi, duyurular ve rehber tek oturumla, tek arayüzden. Tek oturum açma (SSO) bu beklentinin teknik tarafını büyük ölçüde çözdü, deneyim tarafı ise açık kaldı.
Aradaki farkı görmek kolay. Bağlantı listesi olan bir portal, çalışanın sorusunu çözmez, sadece bir tık öteye taşır. Çalışan hâlâ hangi sistemde ne olduğunu bilmek zorundadır. Entegrasyonun ölçüsü kaç sistemin bağlandığı değil, kaç sorunun portaldan çıkmadan cevaplandığıdır.
Mobilde uyarlamak yetmiyor
Responsive şablon bir ekran boyutu kararıdır, önceliklendirme kararı değil. Masaüstündeki yirmi başlıklı mega menü mobilde hamburger simgesinin arkasına girdiğinde tasarım mobil olmaz, sadece küçülür.
Mobil görev listesini anketle değil, kayıtlarla çıkar. Son üç ayın mobil oturumlarında hangi sayfalar açılmış, liste zaten orada duruyor. Tipik olarak bir avuç iş öne çıkar: izin talebi, rehberden numara bulma, bordro görüntüleme, duyuru okuma. Bunları ana ekrana koy, geri kalanı menünün içinde bırak.
Bir adım daha ileri gitmek istersen, mobil oturumların ne kadar sürdüğüne bak. Masaüstünde beş dakika süren bir oturumun mobil karşılığı çoğu portalda bir dakikanın altındadır. O bir dakikaya üç adımlık onay akışı sığmaz, akışı kısaltman gerekir.
Kişiselleştirme bir kere kurulmaz, sürekli bakılır
İki şey birbirine karışıyor. Kişiselleştirme, sistemin role bakıp içeriği otomatik seçmesidir. Özelleştirme, kullanıcının kendi tercihini elle yapmasıdır. İkisi birlikte sunulabilir ama ağırlıkları eşit değil: kullanıcıların büyük çoğunluğu varsayılanı hiç değiştirmez.
Buradan pratik bir sonuç çıkar. Özelleştirme ekranını yayına almadan önce varsayılanı ölç: bir ay sonra kaç kullanıcının tercihini değiştirdiğine bak, oran düşükse o ekranın bakım bütçesini varsayılanı düzeltmeye aktar. Kimsenin dokunmadığı bir ayar ekranı, bakımı süren ölü koddur.
Rol tabanlı kişiselleştirmenin görünmeyen maliyeti de kural sayısında saklıdır. On iki rol ve yirmi içerik türü varsa ortada iki yüz kırk eşleme kararı var demektir ve her yeni içerik türü bu sayıyı rol sayısı kadar büyütür. Eşleme yapılmadığında sistem genellikle güvenli tarafa düşer, yani içeriği herkese gösterir. Böylece azaltmak için kurduğun bilgi yükü geri gelir. Kişiselleştirme kuralları bir veri modelidir ve sahibi olmayan veri modeli bozulur.
Yönetişim yayınlamada değil, silmede çöker
İntranet projelerinde yönetişim genelde katmanlı kurulur ve bu yapı işe yarar:
- Kurumsal iletişim: ana sayfa ve resmi duyurular
- Bölüm içerik sahipleri: kendi alanlarındaki belgeler ve sayfalar
- Deneyim ekibi: eğitim, denetim, yeni içerik sahiplerinin yönlendirilmesi
- Yürütme kurulu: yatırım ve öncelik kararları
Modelin zayıf halkası içeriğin ömrüdür. Herkes yayınlamayı ister, kimse silmek istemez. İki yıllık prosedür belgesi arşivde kaldıkça arama sonuçları kirlenir; çalışan iki kez yanlış belgeye düşünce aramayı bırakır ve yan masaya sormaya döner. Portalın çözdüğü iddia edilen sorun aynen geri gelmiş olur.
Çözüm yordamsal: her içeriğe sahip ve gözden geçirme tarihi ata, tarih geldiğinde sahibine haber gitsin, yenilenmezse içerik otomatik arşivlensin. Bu kuralı en baştan koymak, iki yıl sonra on binlerce belgeyi elle temizlemeye çalışmaktan çok daha ucuzdur.
Nereden başlanır
Sırayı şöyle kur: önce arama ve içerik yaşam döngüsü, sonra rol tabanlı varsayılanlar, en son özelleştirme ve sosyal özellikler. Ters sıra, yani parlak özelliklerle başlamak, temizlenmemiş bir arşivin üstüne kişiselleştirme kurmak anlamına gelir ve orada kişiselleştirme yanlış içeriği daha hızlı önüne getirmekten başka bir işe yaramaz.