Holding ve çok şirketli yapılarda intranet: ortak mı, ayrı mı?

Holding yapılarında intranet kararı, tek şirketten çok daha karmaşık: şirketlerin kültürleri, İK politikaları ve hatta çalışma saatleri farklı olabiliyor. Bazıları sendikalı, bazıları değil. Biri perakende, diğeri üretim.

Soru şu: tek bir platform mu, her şirkete ayrı kurulum mu?

Üç model

1. Tamamen ayrı kurulumlar. Her şirket kendi sistemini kuruyor. Tam bağımsızlık; ama grup genelinde duyuru yapmak imkânsız, maliyet çarpan etkisiyle artıyor ve BT yönetimi dağılıyor.

2. Tek kurulum, tek alan. Tüm grup tek bir intranet kullanıyor. Ekonomik ve ortak kültür için iyi; ancak şirketlerin kendi kimliği kayboluyor ve yetki tasarımı karmaşıklaşıyor — bir şirketin İK yöneticisinin diğer şirketin verisini görmemesi gerekiyor.

3. Tek platform, ayrı alanlar (çok kiracılı). Her şirket kendi alanında, kendi markası ve verisiyle; altyapı ve yönetim ortak. Grup genelinde duyuru yapılabiliyor, veri izolasyonu korunuyor.

Üçüncü model, orta ve büyük holdinglerde en yaygın çözüm. Mimarisini çok kiracılı mimari ve veri izolasyonu yazısında ele aldık.

Veri izolasyonu: en kritik teknik konu

Farklı tüzel kişiliklerin çalışan verisi birbirinden ayrı olmak zorunda. Bu yalnızca bir tercih değil, KVKK açısından da gereklilik: A şirketinin İK yöneticisinin B şirketinin özlük verisine erişmesi için hukuki bir sebep gerekiyor.

Sorulması gereken teknik soru: izolasyon nerede uygulanıyor? Yalnızca arayüzde filtreleme yapan bir sistem yeterli değil; kısıt veritabanı seviyesinde olmalı. Yetki tasarımının genel ilkelerini çalışan verisi ve yetki modeli yazısında anlattık.

Ortak ve özel içerik dengesi

Pratikte içerik üç kategoriye ayrılıyor:

Grup geneli. Holding stratejisi, ortak değerler, üst yönetim mesajları, grup çapındaki kampanyalar. Tek yerden yayınlanıp tüm şirketlere ulaşıyor.

Şirkete özel. İK politikaları, yan haklar, çalışma saatleri, yemekhane, servis. Her şirkette farklı ve karışmamalı.

Paylaşılan hizmetler. Ortak BT destek, ortak satın alma, ortak eğitim kataloğu. Birden fazla şirkete hizmet veren birimler.

Üçüncü kategori tasarımda en çok atlanan: ortak servis birimlerinin hangi şirketlere görünür olacağı ve taleplerin nasıl yönleneceği baştan planlanmalı. Akış tasarımını talep formu şablonları ve onay zinciri yazısında ele aldık.

Örnek: ortak duyurunun yanlış yere düşmesi

Bir holdingde grup İK'sı, tüm gruba yönelik bir yan hak güncellemesi duyuruyor. Ancak duyuru, yan hakların şirketten şirkete farklı olduğunu hesaba katmıyor.

Sonuç: üretim şirketindeki çalışanlar, kendilerinde uygulanmayan bir hakkı duyuruda görüp İK'ya soruyor. İK haftalarca "o bizde yok" açıklaması yapıyor ve duyurunun yarattığı beklenti hayal kırıklığına dönüşüyor.

Çözüm iki yönlü: grup geneli duyurular yalnızca gerçekten herkes için geçerli olan konularda yapılmalı, ve hedefleme mekanizması şirket bazında çalışmalı. Segmentleme yaklaşımını hedef kitle segmentleri yazısında anlattık.

Bu örnek, teknik izolasyonun yetmediğini gösteriyor: içerik yönetişimi de şirket bazlı kurulmalı.

Yetki ve roller

Holding yapısında tipik rol katmanları:

• Grup yöneticisi: tüm şirketleri görebiliyor (sınırlı kapsamda)
• Şirket yöneticisi: yalnızca kendi şirketi
• Ortak servis rolü: birden fazla şirkette belirli bir işlev
• Çalışan: yalnızca kendi şirketi

Grup yöneticisinin ne görebileceği hukuki değerlendirme gerektiriyor: konsolide raporlama için toplulaştırılmış veri genellikle yeterli, kişi bazlı erişim ise ayrı bir gerekçe istiyor. Raporlama tasarımını İK analitiği yazısında ele aldık.

Maliyet ve sözleşme

Çok şirketli yapıda lisans modeli önemli: toplam kullanıcı üzerinden mi, şirket başına mı? Grup sözleşmesi genellikle daha avantajlı ama faturalama şirketlere dağıtılabilmeli — mali işler bunu soruyor. Modelleri intranet fiyatlandırma modelleri yazısında karşılaştırdık.

Kültür farkını yok saymamak

Teknik mimari çözüldükten sonra geriye en zor kısım kalıyor: grup şirketlerinin kültür farkı.

Bir holdingde 30 kişilik bir teknoloji şirketiyle 800 kişilik bir üretim tesisi aynı platformu kullanabilir; ama aynı iletişim diliyle, aynı içerik sıklığıyla ve aynı tonla yönetilemez.

İşe yarayan yaklaşım, grup düzeyinde çerçeve, şirket düzeyinde uygulama belirlemek. Çerçeve ortak olanı tanımlıyor: kurumsal değerler, marka kullanımı, zorunlu duyuru türleri, veri ve gizlilik kuralları. Uygulama ise şirkete bırakılıyor: içerik takvimi, ton, kanal tercihleri, ritim.

Merkezden dayatılan tek tip bir iletişim planı, şirketlerin kendi ihtiyaçlarına uymuyor ve genellikle uygulanmıyor. Tersine, tamamen serbest bırakmak da grup kimliğini kaybettiriyor.

Denge için pratik bir ölçü: grup geneli içeriğin toplam içeriğe oranı. Bu oran çok yüksekse şirketler kendi sesini bulamıyor, çok düşükse grup diye bir şey kalmıyor. İçerik planlamasını iç iletişim içerik takvimi yazısında ele aldık.

Sık sorulan sorular

Şirketler farklı hızlarda ilerleyebilir mi? Evet ve genellikle daha sağlıklı: bir şirkette pilot yapıp sonra yaygınlaştırmak, tüm gruba aynı anda açmaktan daha az riskli. Yöntemi intranet pilot projesi yazısında anlattık.

Şirketler arası geçiş yapan çalışan ne olacak? Kıdem ve özlük devri hukuki bir konu; sistemde de kaydın taşınması gerekiyor. Devir kurallarını işyeri devri ve çalışan hakları yazısında ele aldık.

Her şirket kendi markasını kullanabilir mi? Çok kiracılı yapılarda evet; logo ve vurgu rengi şirket bazında ayarlanabiliyor. Sınırları kurumsal kimlik ve tema özelleştirme yazısında ele aldık.

Yeni şirket satın alındığında? Yeni bir alan açılıp veri taşınıyor. Bu senaryonun ne kadar sürdüğü, satın alma aşamasında sorulması gereken bir soru.