SaaS'ta Kullanıcı Lisansı Kullanım Oranı Nasıl Ölçülür?

SaaS lisans kullanım oranı, aktif kullanıcıların toplam lisanslara bölünmesiyle hesaplanır. Atıl hesapları tespit ederek kurumsal yazılım bütçesinin optimize edilmesini sağlar.

Kurumsal yazılım harcamalarının şirket bütçelerindeki payı her geçen çeyrekte genişlerken, SaaS'ta Kullanıcı Lisansı Kullanım Oranı Nasıl Ölçülür? sorusu doğrudan CFO'ların, BT yöneticilerinin ve operasyon liderlerinin öncelikli gündem maddesi haline gelmiştir. Kullanılmayan veya düşük verimle çalıştırılan yazılım lisansları, şirket kaynaklarının verimsiz tüketilmesine yol açmakla kalmaz; aynı zamanda kapatılmamış hesaplar üzerinden ciddi siber güvenlik ve uyumluluk açıkları üretir. Lisans verimliliğini doğru metriklerle analiz etmek, gerçek kullanıcı etkileşimini tespit etmek, gölge BT harcamalarını engellemek ve sözleşme yenilemelerinde masaya veri odaklı oturabilmek için uygulanması gereken net metodolojiler bulunmaktadır.

SaaS Lisans Kullanım Oranı Nedir ve Formülü Nasıl Uygulanır?

SaaS lisans kullanım oranı (SaaS License Utilization Rate), bir kurumun satın aldığı toplam yazılım koltuğu (seat) havuzunun ne kadarının belirli bir zaman diliminde kurum personeli tarafından aktif ve işlevsel biçimde kullanıldığını gösteren temel performans göstergesidir. Kurumsal satın almalarda yazılımlar genellikle departman bazlı büyüme tahminlerine göre toplu paketler halinde 1 ila 3 yıllık taahhütlerle tedarik edilir. Ancak satın alınan lisans sayısı ile günlük operasyonel rutinde gerçekten ihtiyaç duyulan lisans sayısı arasında zamanla ciddi sapmalar meydana gelir. Bu metriğin düzenli olarak hesaplanması, kurumun gereksiz kapasite maliyetini (shelfware) ortaya çıkarır.

Matematiksel düzeyde formül son derece basittir: Lisans Kullanım Oranı = (Belirli Dönemdeki Aktif Kullanıcı Sayısı / Satın Alınan Toplam Lisans Sayısı) × 100. Örneğin, kurumsal bir proje yönetim aracı için 500 adet kurumsal kullanıcı lisansı satın alınmış ve son 30 günlük izleme periyodunda yalnızca 320 çalışanın bu aracı aktif olarak kullandığı telemetri verileriyle doğrulanmışsa, kullanım oranı (320 / 500) × 100 = %64 olarak hesaplanır. Geriye kalan %36'lık dilim, doğrudan kurum kasasından çıkan ancak hiçbir iş çıktısı üretmeyen atıl sermayeyi temsil eder.

Bu hesaplamanın sağlıklı sonuç verebilmesi için formüldeki değişkenlerin doğru tanımlanması zorunludur. Toplam lisans sayısı, sözleşmede yer alan ve faturası ödenen tüm tahsis edilmiş (assigned) ve boştaki (unassigned) koltukları kapsamalıdır. Yalnızca tahsis edilmiş hesaplar üzerinden hesaplama yapmak, şirketin satın alıp personele atamadığı "yedek" lisansları formül dışı bırakacağı için kullanım oranını yapay olarak yüksek gösterir. Bu durum yönetim kurullarına yanıltıcı bir operasyonel verimlilik tablosu sunulmasına neden olur.

+-----------------------------------------------------------------------------------+
|                        SAAS LİSANS KULLANIM ORANI FORMÜLÜ                         |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|                                Aktif Kullanıcı Sayısı (30/60/90 Gün)              |
|   Lisans Kullanım Oranı (%) = ---------------------------------------  x 100      |
|                                 Satın Alınan Toplam Lisans Sayısı                 |
|                                                                                   |
+-----------------------------------------------------------------------------------+

"Aktif Kullanıcı" Kavramının Kurumsal Tanımı

Lisans kullanım ölçümünde en sık düşülen tuzak, "aktif kullanıcı" tanımının yüzeysel bırakılmasıdır. Birçok yazılım sağlayıcısı, kullanıcının sisteme davet edilmesini (invited) veya son 90 gün içinde yalnızca bir kez giriş yapmış olmasını (login) "aktif" statüsünde raporlar. Ancak kurumsal verimlilik açısından oturum açma eylemi tek başına yeterli bir gösterge değildir. Bir çalışanın yalnızca şifre sıfırlamak veya şirket içi bir duyuruyu okumak için giriş yapıp aracı terk etmesi, o lisansın haklı bir maliyet kalemi olduğunu kanıtlamaz.

Gerçek bir aktif kullanıcı tespiti için eyleme dayalı telemetri (event-based telemetry) kriterleri uygulanmalıdır. Örneğin bir CRM yazılımında aktiflik; yeni bir anlaşma kaydı girmek, müşteri notu güncellemek veya satış hattını ilerletmek gibi temel iş fonksiyonlarının gerçekleştirilmesiyle tanımlanmalıdır. Bir tasarım aracında dosya açma ve düzenleme süresi, bir kod havuzunda (repository) commit atma veya pull request inceleme sıklığı esas alınmalıdır.

Kullanıcı aktivitesini sınıflandırırken üç kademeli bir eşik modeli kurumsal yapılarda kabul gören standarttır:

• Yüksek Düzeyde Aktif (Power User): Haftalık bazda aracın kritik fonksiyonlarını düzenli çalıştıran, günlük iş akışı bu araca bağımlı olan kullanıcılar.

• Düşük/Pasif Aktif (Casual User): Ayda 1-2 kez yalnızca görüntüleme (read-only) veya onay verme amacıyla giriş yapan kullanıcılar.

• Tamamen Atıl (Dormant/Inactive): Son 30 ila 90 gün boyunca sistem üzerinde hiçbir oturum açma veya arka plan API tetiklemesi bulunmayan hesaplar.

Kullanım Oranı Formülü: Hesaplama ve Yorumlama

Elde edilen kullanım oranı yüzdesinin nasıl yorumlanacağı, yazılımın kurum içindeki işlevine ve lisanslama tipine göre değişir. Genel bir kural olarak, kurumsal ölçekte %85 ile %95 arasındaki kullanım oranları sağlıklı kabul edilir. %100 kullanım oranı her zaman ideal bir durum değildir; şirkette yeni başlayan personelin lisans bulamamasına, operasyonel tıkanıklıklara ve acil durumlarda plansız ek koltuk alımlarına (çoğunlukla liste fiyatından indirim uygulanmaksızın) yol açabilir. Bu nedenle %5 ila %10 aralığında bir esneklik marjı (buffer) bırakılması operasyonel süreklilik için tavsiye edilir.

Kullanım oranının %70'in altına düştüğü senaryolar, acil müdahale gerektiren sermaye kaçaklarına işaret eder. Bu seviyedeki düşük oranlar şu temel sorunlardan kaynaklanır:

1. Aşırı Tahsisat (Over-provisioning): Satın alma sürecinde ekiplerin büyüme projeksiyonlarının gerçekçi yapılmaması.

2. Yetersiz Adaptasyon (Low Adoption): Aracın çalışanlara yeterince tanıtılmaması veya arayüz zorlukları nedeniyle çalışanların alternatif yöntemlere yönelmesi.

3. Mükerrer Yazılım Kullanımı: Aynı amaca hizmet eden birden fazla aracın farklı departmanlarca bağımsız satın alınması.

Lisans Türlerine Göre Ölçüm Farklılıkları

SaaS sağlayıcıları farklı gelir modelleri uygular. Bu durum, kullanım oranının hesaplanma mantığını doğrudan etkiler. Kullanıcı başı sabit ücretli (Seat-based) lisanslarda formül kişi sayısı üzerinden yürütülürken; kullanım bazlı (Consumption/Usage-based) modellerde hesaplama API çağrıları, işlenen veri hacmi veya tüketilen kredi miktarı üzerinden kurgulanır.

Katmanlı (Tiered/Feature-based) lisanslamalarda ise çalışanların sahip olduğu lisans tipi (Örn: Enterprise, Pro, Standard, View-only) ile fiilen kullandıkları modüller karşılaştırılmalıdır. Bir çalışan yalnızca standart raporları görüntülüyorsa, bu kişiye tahsis edilmiş olan Enterprise lisansı tam kapasiteyle kullanılmıyor demektir. Burada "koltuk kullanımı" %100 görünse dahi "özellik kullanımı" (feature utilization) %20 seviyesinde kalmaktadır. Bu analiz yapılmadığında kurumlar, ihtiyaç duyulmayan özellikler için her ay kullanıcı başına onlarca dolar fazladan ödeme yapar.

Düşük Kullanım Oranlarının Yarattığı Bütçe ve Güvenlik Riskleri

Kurumsal SaaS portföylerinde düşük lisans kullanım oranları yalnızca finansal bir verimsizlik konusu değildir; aynı zamanda şirketin siber güvenlik mimarisinde ve yasal uyumluluk süreçlerinde ciddi gedikler açar. Bir yazılımın satın alınıp personelin kullanımına bırakılması, yönetim ve denetim sorumluluğunun sona erdiği anlamına gelmez. Kullanılmayan hesaplar zamanla görünmez hale gelir ve kontrolsüz erişim noktalarına dönüşür.

Sektörel araştırmalar ve kurumsal denetim raporları, orta ve büyük ölçekli şirketlerdeki SaaS harcamalarının yaklaşık %25 ila %35'inin tamamen atıl lisanslardan veya yetersiz kullanılan abonelik paketlerinden kaynaklandığını göstermektedir. Binlerce çalışanı olan bir organizasyonda bu oran, yıllık bazda yüz binlerce dolarlık doğrudan nakit kaybı anlamına gelir. Üstelik bu kayıp sadece yinelenen abonelik ücretleriyle sınırlı kalmaz; yazılımların bakım, entegrasyon ve destek maliyetleri de boşa harcanan tutarı katlar.

Aşağıdaki tablo, kurumsal ortamlarda yaygın olarak kullanılan yazılım kategorilerinde atıl lisansların yarattığı ortalama maliyet ve güvenlik risk profilini özetlemektedir:

Atıl Hesaplar ve Çöpe Giden Bütçeler

Atıl hesaplar (idle/dormant accounts), lisansı atanmış ancak kullanıcısı tarafından uzun süredir ziyaret edilmeyen aboneliklerdir. Şirket içi rol değişiklikleri, terfiler, departman transferleri veya personelin projeden ayrılması gibi durumlarda lisans geri alma (deprovisioning) süreçleri manuel yürütülüyorsa bu hesaplar sistemde açık kalır. Sonuç olarak şirket, artık ilgili araca ihtiyacı olmayan bir çalışan için aylık veya yıllık lisans bedeli ödemeye devam eder.

Bütçe israfı yalnızca doğrudan lisans bedeliyle sınırlı değildir. Şirketler genellikle belirli kullanıcı barajlarına ulaştıklarında (örneğin 100 kullanıcıdan sonra) bir üst kurumsal pakete veya minimum taahhüt tutarına zorlanırlar. Gerçekte 70 aktif kullanıcısı olan ancak sistemde 110 kayıtlı hesabı bulunan bir işletme, hem gereksiz 40 hesabın ücretini öder hem de alt paketlerin sunabileceği avantajlı fiyatlandırma modellerinden mahrum kalır.

Offboarding İhlalleri ve Gölge BT (Shadow IT) Tehlikesi

Personel işten ayrıldığında insan kaynakları, idari işler ve BT departmanları arasındaki koordinasyon kopuklukları "yetim hesapların" (orphaned accounts) ortaya çıkmasına neden olur. Şirket ile ilişiği kesilmiş bir çalışanın SaaS hesapları merkezi kimlik doğrulama sisteminden (SSO/IdP) kopuksa veya tek tek deaktive edilmemişse, eski çalışan kurumsal verilere, müşteri veritabanlarına ve fikri mülkiyet niteliğindeki dosyalara aylarca erişebilir. Bu durum KVKK, GDPR ve ISO 27001 standartlarına göre doğrudan bir veri ihlali suçudur.

Gölge BT (Shadow IT) ise merkezi BT yönetiminin onayı ve bilgisi dışında departmanların veya bireysel çalışanların şirket kredi kartlarıyla satın aldığı yazılımlardır. Şirket genelinde lisans kullanım oranlarının ölçülmediği ortamlarda çalışanlar mevcut kurumsal araçların varlığından haberdar olmayabilir veya kurumsal aracı beğenmeyerek paralel SaaS çözümleri satın alabilir. Bu durum hem aynı işlev için mükerrer fatura ödenmesine yol açar hem de bu harici yazılımların şirket güvenlik politikalarına tabi olmaması sebebiyle veri sızıntısı riskini zirveye taşır.

Adım Adım SaaS Kullanım Oranı Ölçüm Metodolojisi

Kurumsal ölçekte SaaS lisans kullanım oranını doğru ölçmek, e-tablolar üzerinden manuel takip edilemeyecek kadar dinamik bir süreçtir. Yüzlerce çalışanın ve onlarca farklı yazılım sağlayıcısının bulunduğu bir ekosistemde ölçümün hatasız yapılabilmesi, sistemli ve tekrarlanabilir bir metodoloji gerektirir. Bu süreç, dağınık durumdaki tüm yazılım varlıklarının tek bir havuzda toplanmasıyla başlar ve gerçek zamanlı kullanım analizine kadar uzanır.

1. Adım: Merkezi Yazılım Envanterinin Çıkarılması

Ölçüm sürecinin temeli, kurum içinde kullanılan her bir SaaS uygulamasının eksiksiz tespit edilmesidir. Bu aşamada üç farklı kaynaktan veri çekilerek konsolide bir yazılım envanteri oluşturulmalıdır:

• Muhasebe ve Finans Kayıtları: Kurumsal kredi kartı ekstreleri, ERP fatura girişleri ve satın alma siparişleri (PO) taranarak düzenli ödeme yapılan tüm yazılım sağlayıcıları listelenir.

• Sözleşme Deposu: Hukuk ve satın alma birimlerindeki aktif yazılım sözleşmeleri incelenerek lisans tipleri, taahhüt edilen koltuk sayıları ve yenileme tarihleri belirlenir.

• Ağ ve Kimlik Doğrulama Kayıtları: Güvenlik duvarı (Firewall), Güvenli Web Ağ Geçidi (SWG) ve Kurumsal E-posta günlükleri taranarak çalışanların eriştiği kayıt dışı bulut servisleri saptanır.

2. Adım: SSO (Tek Oturum Açma) ve API Entegrasyonları ile Veri Toplama

Envanter çıkarıldıktan sonra her bir uygulamanın kullanım verilerine doğrudan erişim sağlanmalıdır. Bunun en sağlıklı yolu, yazılımları Okta, Microsoft Entra ID (eski adıyla Azure AD) veya Google Workspace gibi merkezi Kimlik Sağlayıcılara (IdP) bağlamaktır. SSO entegrasyonu sayesinde kullanıcıların hangi uygulamaya, ne zaman ve hangi cihazdan giriş yaptığı merkezi olarak loglanır.

Ancak SSO verisi yalnızca oturum açma anını kaydeder. Uygulama içi detaylı aktiviteleri ölçmek için doğrudan SaaS sağlayıcısının yönetimsel API'leri (Admin API) kullanılmalıdır. SCIM (System for Cross-domain Identity Management) protokolü ve doğrudan API bağlantıları; kullanıcının son işlem tarihi, belge oluşturma sayısı, depolama alanı kullanımı ve lisans yetki seviyesi gibi granüler telemetri verilerini çekmeyi mümkün kılar.

3. Adım: Kullanım Eşik Değerlerinin Belirlenmesi

Her yazılımın kullanım sıklığı işin doğası gereği aynı olamaz. Bu nedenle her uygulama kategorisi için kurum politikalarına uygun bir "inaktivite eşik değeri" (inactivity threshold) tanımlanmalıdır.

Örneğin, bir kurumsal e-posta veya anlık mesajlaşma aracında 7 gün boyunca giriş yapılmaması anormal bir durum kabul edilebilirken; ay sonu kapanışlarında kullanılan bir finansal konsolidasyon yazılımında 25 günlük hareketsizlik normal sayılabilir. Standart kurumsal uygulamalarda genel geçer kabul gören eşik değerleri şunlardır:

• Günlük Operasyonel Araçlar (Slack, Teams, CRM): 14-30 gün inaktivite sonrası atıl statüsüne alma.

• Haftalık/Dönemsel Araçlar (BI Araçları, İK Portalları): 45-60 gün inaktivite sonrası inceleme.

• Seyrek Kullanılan Uzmanlık Yazılımları (Vergi yazılımları, anket araçları): 90 gün inaktivite sonrası lisans geri çağırma (harvesting) değerlendirmesi.

4. Adım: Metriklerin Konsolidasyonu ve Raporlama

Toplanan ham veriler ve belirlenen eşik değerleri bir araya getirilerek her bir yazılım için Lisans Kullanım Oranı hesaplanır. Raporlama aşamasında veriler yalnızca şirket geneli bazında değil; departman, yönetici, maliyet merkezi ve lokasyon bazında kırılımlara ayrılmalıdır. Bu kırılımlar, hangi departmanın bütçesini verimli kullandığını, hangi birimlerin ise atıl lisans biriktirdiğini net biçimde gösterir.

Lisans Optimizasyonu ile SaaS Bütçesi Nasıl Küçültülür?

Ölçüm süreci tamamlanıp atıl ve az kullanılan lisanslar tespit edildikten sonra, asıl değer üreten aşama olan lisans optimizasyonuna geçilir. Lisans optimizasyonu yalnızca kullanılmayan koltukları iptal etmek anlamına gelmez; mevcut kullanıcıların yetki seviyelerini iş gereksinimlerine göre yeniden ayarlamak, boştaki lisansları yeni talepler için yeniden dağıtmak ve sözleşme şartlarını veri gücüyle müzakere etmek gibi bir dizi proaktif stratejiyi kapsar.

Kullanım Düzeyine Göre Lisansları Optimize Etme (Rightsizing)

Yazılım üreticileri, en yüksek marjı sağlayan üst paketleri (Enterprise/Tier-1) satmak üzere lisans paketlerini kurgularlar. Ancak bir organizasyondaki personelin tamamı bu paketlerde sunulan gelişmiş otomasyonlara, sınırsız API erişimlerine veya ileri düzey analitik araçlarına ihtiyaç duymaz.

Rightsizing (Doğru Ölçeklendirme) stratejisinde, personelin geçmiş dönemdeki özellik kullanım alışkanlıkları taranır. Örneğin kurumsal bir e-imza platformunda personelin %80'i yalnızca gelen evrakları imzalıyor (ücretsiz veya temel paket gereksinimi), ancak sadece %20'si evrak şablonu oluşturup dağıtıyorsa (Enterprise lisans gereksinimi); tüm çalışanlara Enterprise lisansı tanımlanmış olması ciddi bir kaynak israfıdır. İmzacı personelin lisansı "View/Sign-only" seviyesine düşürülerek (downgrade) kullanıcı başı maliyet anında %70'e varan oranlarda azaltılabilir.

Atıl Lisansları Yeniden Dağıtma Stratejileri (License Harvesting)

Şirket içi operasyonlarda sürekli yeni lisans talepleri ortaya çıkar. Bir departmana yeni bir personel katıldığında veya yeni bir proje başladığında, BT departmanlarının refleks olarak satıcıdan ek lisans satın alması yaygın bir hatadır. Bunun yerine "Lisans Hasadı" (License Harvesting) mekanizması devreye sokulmalıdır.

Lisans hasadı yaklaşımında:

1. Yeni bir lisans talebi geldiğinde öncelikle mevcut atıl lisans havuzu kontrol edilir.

2. Son 60 gündür araca giriş yapmamış veya belirlenen eşik değerinin altında kalmış bir kullanıcının lisansı otomatik veya bildirimli olarak geri alınır (reclaimed).

3. Geri alınan bu koltuk, yeni talepte bulunan personele tahsis edilir.

4. Böylece sağlayıcıya tek bir kuruş ek ödeme yapılmaksızın yeni personelin ihtiyacı karşılanmış olur.

Bu sürecin sürdürülebilir olması için şirket içi bir "Lisans Geri Alma Politikası" yayımlanmalı, personelin lisansı geri alındığında projeye yeniden ihtiyaç duyarsa tek tıkla lisansı geri talep edebileceği şeffaf bir self-servis portal altyapısı kurulmalıdır.

+-----------------------------------------------------------------------------------+
|                        LİSANS HASADI (HARVESTING) DÖNGÜSÜ                         |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|   [ Yeni Lisans Talebi ]                                                          |
|            │                                                                      |
|            ▼                                                                      |
|   [ Atıl Lisans Havuzu Kontrolü ] ──(Atıl Lisans Var)──► [ Lisansı Geri Al ve ]   |
|            │                                             [ Yeni Personele Ver ]   |
|            │ (Atıl Lisans Yok)                                                    |
|            ▼                                                                      |
|   [ Sözleşme/Ek Koltuk Satın Alma ]                                               |
|                                                                                   |
+-----------------------------------------------------------------------------------+

Sözleşme Yenilemelerinde Tasarruf Fırsatları

Yıllık veya çok yıllık SaaS sözleşmelerinin yenileme dönemleri, lisans optimizasyonunun en somut finansal kazanca dönüştürüldüğü anlardır. Satıcılar genellikle otomatik yenileme (auto-renewal) maddelerine ve şirketlerin iç kullanım verilerine hakim olmamasına güvenirler.

Yenileme tarihinden en az 60 ila 90 gün önce detaylı lisans kullanım raporu hazırlanmalıdır. Satıcının masaya sunduğu "Kullanıcı sayınızı %20 artıralım, birim fiyatta %10 indirim yapalım" teklifine karşı, eldeki somut telemetri verileriyle cevap verilmelidir. Örneğin, "500 lisansımızın son 12 aydaki tepe kullanım oranı %65'i geçmemiştir; bu nedenle yeni dönem sözleşmemizi 350 lisans üzerinden revize etmek istiyoruz" argümanı, satıcı karşısında tartışmasız bir pazarlık gücü kazandırır.

SaaS Yönetim Platformları (SMP) ve Otomasyonun Rolü

Şirketlerin kullandığı SaaS uygulama sayısı arttıkça (orta ölçekli şirketlerde ortalama 50-100, büyük kurumlarda 200+ uygulama), lisans kullanım oranlarının manuel yöntemlerle ölçülmesi ve yönetilmesi imkansız hale gelir. Bu noktada devreye SaaS Yönetim Platformları (SaaS Management Platforms - SMP) girer. SMP çözümleri, tüm yazılım ekosistemini tek bir kontrol panelinden izleme, analiz etme ve optimize etme imkanı sunar.

SMP araçları (örneğin Zylo, Torii, BetterCloud, Zluri veya Productiv gibi kurumsal platformlar), doğrudan kimlik sağlayıcılara (IdP), finansal sistemlere (ERP/Gider Yönetimi) ve SaaS uygulamalarının kendi yönetim API'lerine çift yönlü entegre olur. Bu sayede platform, şirket bünyesindeki her bir yazılımın lisans kullanımını gerçek zamanlı olarak takip eder.

Bu platformların sağladığı başlıca otomasyon kabiliyetleri şunlardır:

1. Otomatik Lisans Geri Çağırma İş Akışları: Bir kullanıcı 45 gün boyunca belirli bir yazılıma giriş yapmadığında, sistem kullanıcıya Slack veya E-posta üzerinden otomatik bir anket gönderir: "X yazılımını son 45 gündür kullanmadığınızı fark ettik. Bu lisansa hala ihtiyacınız var mı?" Kullanıcı belirli bir süre içinde yanıt vermezse veya "Hayır" derse, lisans API aracılığıyla otomatik olarak geri alınır ve havuza aktarılır.

2. Akıllı Rol ve Paket Eşleme: Kullanıcının sistem üzerindeki tıklama ve işlem logları analiz edilerek, sahip olduğu pahalı lisans tipi yerine daha düşük maliyetli bir paketin yeterli olup olmadığı makine öğrenimi modelleriyle tespit edilir ve BT yöneticisine öneri olarak sunulur.

3. Sözleşme ve Yenileme Bildirimleri: Yaklaşan sözleşme yenileme tarihleri 90, 60 ve 30 gün önceden ilgili kategori yöneticisine otomatik kullanım raporuyla birlikte iletilir. Böylece ekipler masaya hazırlıksız oturmaz.

Kurumsal Lisans Denetimi ve Sürekli İzleme Süreci

Lisans kullanım oranının ölçülmesi bir kerelik bir tasarruf projesi değil, sürekli işletilmesi gereken bir kurumsal yönetişim (governance) sürecidir. Şirketler büyüdükçe, personel sirkülasyonu yaşandıkça ve yeni dijital araçlar devreye girdikçe lisans verimliliği hızla bozulma eğilimi gösterir. Bu nedenle kurum içinde standart bir denetim ve yaşam döngüsü modeli kurulmalıdır.

Periyodik Lisans Denetim Takvimi Oluşturma

Lisans optimizasyonunun kurumsal bir disiplin haline gelmesi için periyodik denetim takvimleri belirlenmelidir. Uygulamanın maliyetine ve kritiklik düzeyine göre şu denetim frekansları uygulanmalıdır:

• Aylık Denetimler (Tier-1 Yüksek Maliyetli Araçlar): Kurumsal ERP, CRM, ana iletişim platformları ve bulut altyapı hesapları gibi şirket bütçesinin en büyük kısmını oluşturan yazılımlar her ay taranmalıdır.

• Üç Aylık (Çeyreklik) Denetimler (Tier-2 Departman Araçları): Tasarım, proje yönetimi, pazarlama otomasyonu gibi departman bazlı lisanslar çeyrek dönem sonlarında departman yöneticileriyle birlikte incelenmelidir.

• Yıllık Genel Portföy Denetimi (Tier-3 Tüm Ekosistem): Şirketteki tüm yazılımların, eklentilerin (plugins) ve bireysel aboneliklerin dahil edildiği, mükerrer araçların elimine edildiği genel konsolidasyon denetimi.

Lisans Yaşam Döngüsü Yönetimi (Provisioning ve Deprovisioning)

Lisans kullanım oranlarının kalıcı olarak yüksek kalması, İnsan Kaynakları süreçleri ile BT operasyonlarının tam entegre çalışmasına bağlıdır. Bir personelin işe alımından (onboarding), rol değişikliklerine ve işten ayrılışına (offboarding) kadar geçen tüm süreçte lisans hareketleri otomatik kurallara bağlanmalıdır.

SCIM protokolü üzerinden kurgulanan otomatik yetkilendirme altyapısı, İK sisteminde (HRIS) bir personelin işten ayrıldığı işaretlendiği anda, personelin tüm SaaS hesaplarını dakikalar içinde askıya almalı ve tahsis edilmiş lisansları otomatik olarak boştaki lisans havuzuna transfer etmelidir. Bu otomasyon hem atıl hesap oluşumunu kaynağında engeller hem de yetkisiz erişim kaynaklı güvenlik risklerini tamamen ortadan kaldırır.

Departman Bazlı Sorumluluk ve Lisans Tahsis Modelleri

Lisans israfını engellemenin en etkili yollarından biri de maliyet sorumluluğunu (Chargeback/Showback modeli) doğrudan ilgili departmanlara yüklemektir. Yazılım bütçelerinin tamamı merkezi BT bütçesinden ödendiğinde, departman yöneticileri ihtiyaç duymadıkları lisansları talep etmekte ve atıl kalan koltukları bildirmemekte sakınca görmezler.

Chargeback modelinde her departman, kendi çalışanlarına tahsis edilen lisansların maliyetini kendi operasyonel bütçesinden (OPEX) karşılar. Showback modelinde ise fatura merkezi ödense dahi departman yöneticilerine her ay "Departmanınız bu ay X yazılımı için $5.000 harcamıştır ve lisans kullanım oranınız %60 seviyesindedir" şeklinde detaylı iç raporlar sunulur. Maliyetin görünür kılınması, departman liderlerinin atıl lisansları kendi inisiyatifleriyle havuza iade etmelerini sağlayan güçlü bir teşvik mekanizması oluşturur.