Bir holdingin eğitim operasyonu, tek şirketli bir yapının birkaç katman üstündedir. Merkez ofis ortak müfredatı ve zorunlu eğitimleri izlemek isterken grup şirketleri kendi hedeflerini, şubeler ise günlük operasyonunu yönetir. Bu katmanlar aynı LMS içinde buluştuğunda ilk soru genellikle şudur: Lisansı kimin adına tanımlayacağız ve hangi yönetici neyi görebilecek?

Yanıt yalnızca toplam kullanıcı sayısını bilmekten geçmez. Çoklu şube LMS yönetimi için organizasyon ağacı, şube kotası, merkezî lisans havuzu, rol tabanlı görünürlük ve kullanıcı yaşam döngüsü birlikte tasarlanmalıdır. Qulak ile bu akışın nasıl kurulabileceği; kurumun mevcut planına, sözleşmesine, entegrasyonlarına ve bilgi güvenliği gereksinimlerine göre keşif aşamasında doğrulanır.

Çoklu şube LMS yönetimi neden merkezi lisans havuzu gerektirir?

Şube bazında ayrı lisans paketleri açmak ilk bakışta düzenli görünür. Ancak çalışanların şirketler veya lokasyonlar arasında geçici görevlendirilmesi, yeni şubelerin açılması ve sezonluk ekiplerin sisteme katılması bu düzeni kısa sürede zorlayabilir. Bir şubede kullanılmayan koltuk beklerken diğer şube ek lisans talep edebilir. Bu durum, kapasitenin nerede boş, nerede sıkışık olduğunu anlamayı güçleştirir.

Merkezi lisans havuzu yaklaşımında toplam kapasite grup seviyesinde izlenir. Bunun altında her şube için bir hedef kota, uyarı eşiği veya onay gerektiren limit tanımlanabilir. Bu ifadeler ürünün kesin özelliği olarak değil, Qulak üzerinde kurumun mevcut planı doğrulanarak tasarlanabilecek işletim seçenekleri olarak değerlendirilmelidir.

Şube kotaları nasıl tasarlanmalı?

Kota belirlerken yalnızca mevcut çalışan sayısını baz almak sağlıklı değildir. İşe alım planı, yüksek devir oranı olan pozisyonlar, zorunlu eğitim kapsamı ve yakın dönemde açılacak lokasyonlar da dikkate alınmalıdır. Buradaki amaç her şubeyi dar bir sayıya hapsetmek değil, kapasite kullanımını öngörülebilir hale getirmektir.

Pratikte üç farklı kota mantığı birlikte kullanılabilir. Sabit kota, bütçesi veya kapasitesi net olan küçük birimlerde anlaşılır bir sınır sunar. Esnek kota, merkezî havuzda boş kapasite varsa şubenin geçici olarak daha fazla kullanıcı almasına izin veren bir modeldir. Onaylı taşma ise kota aşıldığında talebin merkez veya grup şirketi yöneticisine gitmesini sağlar. Qulak ile hangi yaklaşımın uygulanacağı, kurumun lisans sözleşmesi ve operasyon kuralına göre netleştirilmelidir.

Kota politikasını yazılı hale getirmek de teknik ayar kadar önemlidir. “Kota dolduğunda ne olur?”, “Kullanılmayan lisans ne zaman havuza döner?”, “Şube değişikliğinde eski kayıt nasıl kapatılır?” ve “Merkezî rezerve kim tarafından kullanılabilir?” sorularının yanıtı yöneticiler için açık olmalıdır. Böylece lisans yönetimi kişiye bağlı bir e-posta trafiği olmaktan çıkar, denetlenebilir bir sürece dönüşür.

Holding yapısında yetki ve görünürlük modeli

Çoklu şirket yapısında tüm yöneticilere aynı ekranı açmak operasyonu kolaylaştırmaz; tersine gereksiz veri görünürlüğü yaratabilir. Daha güvenli yaklaşım, organizasyon ağacını rol ve kapsamla birlikte düşünmektir. NIST’in RBAC yaklaşımında yetkiler tek tek kullanıcılara dağılmak yerine rollere bağlanır; kullanıcılar sorumluluklarına uygun rollere atanır. Bu yaklaşımın holding LMS’ine nasıl uyarlanacağı kurumun rol kataloğu ve güvenlik politikasıyla doğrulanmalıdır.

Bu modelde “görebilme” ile “değiştirebilme” aynı şey değildir. Bir merkez yöneticisi konsolide kullanım raporunu okuyabilir, fakat her şubenin kullanıcılarını tek başına değiştiremeyebilir. Benzer şekilde bir şube yöneticisi eğitim ataması yapabilir, ancak lisans kotasını yükseltme yetkisine sahip olmayabilir. Qulak üzerinde tasarlanacak rol matrisi bu ayrımları menü, rapor, kullanıcı ve işlem seviyesinde ayrı ayrı değerlendirmelidir.

Organizasyon ağacı, çalışan hareketliliğinde de belirleyici olur. Bir kişi şube değiştirdiğinde önce hedef şubenin kotası ve rolü doğrulanmalı, ardından yeni ilişki kurulmalı ve son olarak eski ilişki kapatılmalıdır. Microsoft’un grup tabanlı lisanslama dokümantasyonu da hizmet kesintisi riskini azaltmak için benzer geçiş sırasını; önce hedef gruba ekleme, atamayı doğrulama, sonra kaynak gruptan çıkarma şeklinde açıklar. Bu, Qulak için kesin bir ürün davranışı iddiası değildir; geçiş tasarımında dikkate alınabilecek genel bir kontrol ilkesidir.

Lisans yaşam döngüsünü operasyonel bir akışa dönüştürün

Merkezi havuzun değeri yalnızca lisans atarken değil, lisans geri kazanılırken de ortaya çıkar. Yeni işe başlayan kişinin doğru şirket ve şubeye bağlanması, görev değişikliğinde rolünün güncellenmesi, uzun süre kullanılmayan hesabın incelenmesi ve işten ayrılan kişinin erişiminin kapatılması aynı yaşam döngüsünün parçalarıdır.

1. Tanımla: Şirket, şube, departman, maliyet merkezi ve kullanıcı türleri için ortak veri sözlüğü oluşturun.
2. Yetkilendir: Her rolün hangi kapsamda kullanıcı, katalog, rapor ve lisans işlemi yapabileceğini yazılılaştırın.
3. Atamayı doğrula: Yeni kullanıcıya lisans vermeden önce şube kotasını, zorunlu eğitim kapsamını ve veri aktarım dayanağını kontrol edin.
4. İzle: Toplam havuz, şube kullanımı, bekleyen onaylar, başarısız atamalar ve boşta kalan hesapları periyodik raporlayın.
5. Geri kazan: Şube değişikliği veya ayrılış sonrasında eski atamaları kapatın; istisnaları kayıt altına alın.

Bu akışın bazı adımları API veya HRIS senkronizasyonu ile otomatikleştirilebilir, bazıları ise insan onayı gerektirebilir. Qulak’ın mevcut planında hangi entegrasyonların ve otomasyonların kullanılabileceği, teknik keşifte kurum sistemleriyle birlikte doğrulanmalıdır. API ve HRIS entegrasyonu rehberi, bu yaşam döngüsünü mevcut İK sistemleriyle birlikte düşünmek isteyen ekipler için tamamlayıcı bir çerçeve sunar.

Veri güvenliği ve KVKK kontrolleri

Şube bazlı raporlama, çalışan adı, e-posta adresi, görev, eğitim durumu veya sınav sonucu gibi kişisel verileri içerebilir. KVKK’nın kişisel verilerin işlenmesine ilişkin resmî açıklamalarına göre hangi verinin hangi amaçla ve hangi hukuki şartla işlendiği kurum tarafından değerlendirilmelidir. Bu nedenle lisans yönetimi ekranını tasarlarken “yönetici görebiliyor” demek yeterli değildir; neden görmesi gerekiyor ve daha az veriyle aynı amaç sağlanabilir mi? soruları da yanıtlanmalıdır.

KVKK’nın kişisel veriler sayfası, açık rıza dışındaki işleme şartları uygulanabiliyorsa ayrıca açık rıza alınmaması gerektiğini açıklar. Açık rıza açıklaması ise rızanın belirli konuya ilişkin, bilgilendirmeye dayalı ve özgür iradeyle verilmesi gerektiğini belirtir. Bu ilkeler, lisans atamasının kendisinden çok, kullanıcı doğrulama, yüz teyidi veya hassas raporlama gibi ek veri işleme adımlarında özellikle önem kazanır.

Örneğin yüz teyidi içeren bir giriş veya sınav akışı planlanıyorsa açık rıza ile aydınlatma birbirine karıştırılmamalı; mümkünse alternatif doğrulama yöntemi sunulmalı, veri minimizasyonu uygulanmalı, saklama süresi belirlenmeli ve sonuçlar insan denetimi olmadan otomatik karara bağlanmamalıdır. KVKK’nın 18 Şubat 2026 tarihli 2026/347 sayılı ilke kararı duyurusunda da aydınlatma yükümlülüğünün onaya bağlı olmadığı, açık rıza gerekiyorsa iki metnin ayrı düzenlenmesi gerektiği vurgulanır. Uygulama öncesinde hukuk ve bilgi güvenliği ekiplerinin görüşü alınmalıdır.

Qulak ile kurumunuza uygun modeli nasıl doğrularsınız?

Sağlıklı bir keşif görüşmesi, “kaç lisans var?” sorusuyla başlayıp bitmez. Önce organizasyonun nasıl çalıştığı görünür hale getirilir. Ardından lisansın hangi olaylarda atanacağı, hangi durumda havuza döneceği ve hangi raporun hangi yöneticiye açılacağı belirlenir. Böylece teknik konfigürasyon, satın alma varsayımlarından bağımsız olarak gerçek operasyonla eşleşir.

Görüşmeye şu bilgilerle gelmeniz süreci hızlandırabilir: şirket ve şube hiyerarşisi, yaklaşık kullanıcı türleri, ortak ve yerel eğitim ayrımı, kota veya bütçe kuralları, HRIS/SSO beklentisi, rapor kapsamı, geçici kullanıcı senaryoları ve veri saklama politikası. Qulak ile merkezi lisans havuzu ve çoklu şube yapısı bu bilgiler üzerinden tasarlanabilir; kesin özellik, limit ve entegrasyon kapsamı ise kurumun mevcut planına göre doğrulanır.

Sıkça Sorulan Sorular

İlgili rehberler