Yetkinlik Ne Demek? Kurumsal L&D’de Yetkinlik Modeli, Seviye Tanımı ve Ölçüm Rehberi

Yetkinlik Ne Demek? Kurumsal L&D’de Yetkinlik Modeli, Seviye Tanımı ve Ölçüm Rehberi

Yetkinlik kelimesi kurum içinde bir kez “herkes anladı” sanıldığında, genelde iki ay sonra aynı toplantıda üç farklı anlama bölünür: biri “bilgi”, biri “beceri”, biri de “performans” der. Sonra eğitim bütçesi, hedefe değil; kelimeler arasındaki boşluğa akar.

Ben yetkinliği üç köşeli bir şey olarak ele alıyorum: rol, davranış göstergesi ve kanıt. Rol “neyi başarmalıyım?” der. Davranış göstergesi “bunu nasıl yaparım?” der. Kanıt ise “gerçekten yapabiliyor muyum?” sorusunu kapatır. Bu üçü birlikte yoksa, “yetkinlik” sadece güzel bir etiket olur.

Aşağıda adım adım, kurumsal L&D’de yetkinlik modelini nasıl somutlaştıracağınızı; seviye tanımını nasıl yazacağınızı; açığı hangi verilerle bulacağınızı ve ölçümü nasıl tasarlayacağınızı anlatacağım. Araya KVKK ve İSG gibi “kanıt”ın hayati olduğu alanları da serpiştireceğim; çünkü bu iki başlık, yetkinlik modelinin romantik değil operasyonel bir şey olduğunu insana hemen hatırlatır.

“The map is not the territory.” [Alfred Korzybski, 1931]
Yetkinlik modeli haritadır; işin kendisi değil. Harita iyi değilse, en iyi niyetli yolculuk bile kaybolur.

1) Yetkinlik, beceri, bilgi: Kurumsal sözlükte ayrım yapmadan ölçüm olmaz

Kurumsal eğitimde en sık gördüğüm hata şu: bilgi, beceri ve yetkinlik aynı kutuya atılıyor; sonra o kutu “eğitim kataloğu” oluyor. Oysa bunlar farklı şeyler.

Benim kullandığım pratik ayrım:

Bir an “yetkinlik = beceri + bilgi” diye yazacaktım; eksik. Yetkinlikte bağlam ve tutarlılık var. Bir gün doğru yapıp ertesi gün dağılıyorsanız, beceri vardır; yetkinlik henüz oturmamıştır.

Kurumsal sözlüğünüzde şu iki cümleyi netleştirmek, bütçeyi doğrudan etkiler:

  1. “Bu başlık eğitimle mi (bilgi/beceri), yoksa iş tasarımı ve yöneticilikle mi (yetkinlik) çözülür?”
  2. “Bu yetkinliği kanıtlamak için hangi davranışı, hangi iş çıktısıyla göreceğiz?”

Mini örnek sözlük (aynı konu, üç farklı katman)

Konu Bilgi Beceri Yetkinlik (rol bağlamında)
İSG: Risk Risk türlerini sayar Risk değerlendirme formu doldurur Sahada riskleri proaktif görür, uygunsuzluğu durdurur ve raporlar
Satış: İtiraz İtiraz tiplerini bilir İtiraz karşılama cümleleri kurar Müşteri bağlamına göre doğru tekniği seçer, marjı koruyarak kapatır
KVKK Veri kategorilerini bilir Aydınlatma metni kontrol listesi uygular Süreçlerde veri minimizasyonu ve erişim kontrolünü sürdürülebilir kılar

Bu tabloyu “kurumsal sözlük” diye saklamayın; yetkinlik modelinizin giriş kapısı yapın. Çünkü ölçüm tasarımı burada başlar.

2) Yetkinlik modeli: Rol × davranış göstergesi × kanıt üçgeni

Yetkinlik modelini “liste” sanmak kolay. Liste yapmak rahatlatıcıdır: 12 madde yazarsınız, biter. Ama yetkinlik listesi tek başına bir şey yapmaz; tıpkı Borges’in sonsuz kütüphanesi gibi, her şey vardır ama aradığınız şeyi bulamazsınız (Borges, “The Library of Babel”, 1941).

Benim için model, üç soruya aynı anda cevap vermeli:

  1. Rol: Bu rolün başarı tanımı ne? (çıktı, sorumluluk, risk)
  2. Davranış göstergesi: Başarılı kişi neyi, nasıl yapar? (gözlenebilir)
  3. Kanıt: “Yaptı” dediğimizde elimizde ne olacak? (assessment / iş çıktısı / veri)

Bu üçgeni bir şablon gibi düşünün. Bir yetkinliği yazarken, cümleyi şu şekilde zorlayın:

Şablon (kurum içinde standartlaştırılabilir)

Yetkinlik adı:
Bağlı rol(ler):
Tanım (1 cümle):
Davranış göstergeleri (3–6 madde, gözlenebilir):
Seviye tanımı (L1–L4 veya Junior–Senior):
Kanıt türleri (en az 2):
İlgili KPI / risk / uyum başlığı:

Burada “kanıt türleri” satırı kritik. Çünkü “kanıt” yazmadığınız her yetkinlik, bir süre sonra sadece eğitim atama bahanesi olur.

3) Rol bazlı yetkinlik matrisi: Seviye tanımı nasıl yazılır?

Seviye tanımı yazmak, insanlara garip şekilde zor gelir. Çünkü çoğu kurum “junior–senior”u kıdem yılıyla karıştırır. Yıl önemli olabilir ama yetkinlik seviyesini belirleyen şey, benim gözümde daha çok şudur: özerklik, karmaşıklık, etki alanı ve risk yönetimi.

Bir seviye çerçevesi kurarken 4 basamak çoğu kurumda yeterli çalışır:

“L4 = yönetici” demek zorunda değilsiniz. Bazı uzman rollerinde L4, yöneticilik değil sistem kuruculuğudur.

Örnek: “KVKK Uyumlu Veri İşleme” yetkinliği (davranış odaklı seviye)

Seviye Davranış göstergesi Tipik kanıt
L1 Kişisel veri ile anonim veriyi ayırt eder, temel kuralları ihlal etmez Mini sınav + senaryo soruları
L2 Süreçte veri minimizasyonu uygular, erişim taleplerini doğru yönlendirir İş üstünde kontrol listesi + örnek kayıt
L3 İstisna durumlarda (acil durum, üçüncü taraf) doğru aksiyonu seçer Vaka analizi + 360 geri bildirim
L4 Süreci iyileştirir; riskleri azaltan yeni kontrol noktaları önerir Süreç değişikliği çıktısı + KPI trendi

İSG tarafında da benzer: L1 “kuralı bilir”, L2 “uygular”, L3 “istisnada doğru karar verir”, L4 “sistemi iyileştirir”.

Rol bazlı matrise dönüştürme

Matrisi iki eksende kurun:

Bu noktada kurumlar genelde matrisi Excel’de tutar. Bu kötü değil; ama Excel, “kanıt”ı canlı tutmakta zayıf kalır. Çünkü kanıtlar zamanla dağılır: bir sınav başka yerde, sertifika PDF’i başka yerde, 360 notları e-postalarda.

Nextrain’de bu parçalanmayı azaltmak için Passport’ı kullanıyorum: çalışanların rollerini, yetkinliklerini, eğitim geçmişini ve sertifikalarını tek profilde toplamak, matrisi “kağıt üstünde” olmaktan çıkarıyor. Özellikle İSG ve KVKK gibi denetim başlıklarında “kim neyi almış?” sorusunun 3 saniyede kapanması, yetkinlik modelinin pratik değerini yükseltiyor.

4) Yetkinlik açığı analizi: Hangi veriyle bulunur, hangi hatalar yapılır?

Yetkinlik açığı analizi (gap analysis) iki sayının farkı değildir; iki tanımın farkıdır:

Açığı doğru bulmak için önce “mevcut”u doğru ölçmek gerekir. İnsanlar burada kestirme yapmayı seviyor: “Eğitimi tamamladı → yetkinlik tamam.” Bu, benim için en pahalı yanılgı.

Ben açığı üç veri sınıfıyla aramayı seviyorum:

  1. Değerlendirme verisi: mini sınav, vaka, rubrik puanı, checkpoint sonuçları
  2. Davranış verisi: içerikte nerede takıldı, kaç kez denedi, hangi soruda zorlandı
  3. İş kanıtı: gerçek iş çıktısı, gözlem, 360 geri bildirim, kalite/hata kayıtları

Nextrain tarafında “davranış verisi” dediğim şey, sistemin event-level izlediği şeyler: izleme, tıklama, cevap, süre. Bunlar tek başına yetkinlik değildir; ama “nerede zorlanıyor?” sorusuna çok iyi cevap verir. Bir çalışan bir modülü üç kez izliyorsa, bu bazen motivasyon değil; bazen belirsizlik demektir. (Bazen de sadece arka planda açık bırakmıştır; evet, bunu da gördüm.)

Sık yapılan 6 hata (ve nasıl düzeltilir)

İnsanların aynı gün içinde iki zıt şey istemesi burada da çıkıyor karşıma: “Herkes aynı standarda gelsin” diyorlar, sonra “ama kimseye zaman kaybettirmeyelim” diyorlar. İkisi de makul. Çözüm, standardı kanıt ile sabitleyip, yolu kişiselleştirerek kısaltmak.

5) Ölçüm tasarımı: Rubrik, mini sınav, iş üstünde kanıt, 360 (ve ne zaman hangisi?)

Ölçüm tasarımında benim temel kuralım şu: Yetkinlik davranışsa, ölçüm de davranışa yaklaşmalı. Sadece bilgi ölçerseniz, sadece bilgi geliştirirsiniz.

Aşağıdaki dört aracı birlikte düşünün:

5.1 Rubrik (davranışın ölçüm dili)

Rubrik, “iyi”yi kelimeye çevirir. Yöneticinin “fena değil” dediği şeyi, gözlenebilir hale getirir.

Basit bir rubrik örneği (satış görüşmesi – itiraz yönetimi):

Rubrik, 360 geri bildirimi de daha az “yorum”, daha çok “kanıt” yapar.

5.2 Mini sınav (bilgi + hızlı tarama)

Mini sınavı seviyorum çünkü hızlıdır; ama sınavı “final” yapmayı sevmiyorum. İyi kullanım: tarama ve kapı.

Nextrain’de bu “kapı” mantığını AI Gates ile kurabiliyorum: başarısız olursa tekrar eğitimi, başarılı olursa ileri seviyeye geçiş. Bu mekanizma, ölçümü sadece rapor değil, akış kararı haline getiriyor.

5.3 İş üstünde kanıt (gerçek dünyaya temas)

İş üstünde kanıt, “öğrendim”i “yaptım”a çevirir. Örnekler:

Burada dikkat: Her iş çıktısı yetkinlik kanıtı değildir. Çıktının “kişinin davranışı” ile bağlantısını kurmak gerekir.

5.4 360 geri bildirim (algı değil, örüntü)

360, tek başına tehlikeli olabilir; çünkü popülerlik yarışına dönebilir. Ama rubrikle birleşince çok işe yarar: aynı davranış göstergesine birden fazla gözden bakarsınız.

Ben 360’ı özellikle şu iki durumda anlamlı buluyorum:

6) KPI’lara bağlama: Yetkinlik modeli “rapor” değil, karar sistemidir

KPI bağlantısı yapılmadığında, yetkinlik modeli bir süre sonra “İK dokümanı” gibi muamele görür: vardır, ama kimse onunla karar vermez.

Bağlantıyı kurmanın pratik yolu:

  1. Yetkinliği seç (rol bağlamında)
  2. Davranış göstergesini yaz (gözlenebilir)
  3. Kanıtı seç (assessment + iş kanıtı)
  4. KPI’yı seç (iş metriği / risk metriği)
  5. Zaman penceresini belirle (30-60-90 gün)

Örnek eşleştirmeler:

Nextrain Analytics tarafında ben bu ilişkiyi kurarken, eğitim verilerini “tek ekran”da izlemeyi ve gerektiğinde Akira’ya doğal dille soru sorup hızlı kırılımlar almayı seviyorum. “Hangi bölgede skor düşük?” sorusu basit görünüyor; ama doğru sorulduğunda yetkinlik açığını rol + bölge + eğitim adımı düzeyinde görünür kılıyor. Sonra müdahale tasarımı başlıyor: içerik mi, seviye mi, yoksa iş süreci mi?

Burada küçük bir not: KPI’larınızın hepsi eğitim sisteminin içinde yaşamaz. Bazıları CRM’dedir, bazıları HR’dedir. Bu yüzden veri akışını düşünmek gerekir. Nextrain’de bu entegrasyon tarafında DataBridge ile HR sistemleri, CRM ve iç araçlara gerçek zamanlı veri akışı kurgulanabildiği için, “eğitim skoru” ile “iş sonucu” arasındaki köprü daha az el emeği ister.

7) Adım adım uygulama planı (90 günde yetkinlik modelini ayağa kaldırmak)

Yetkinlik modeli “büyük proje” gibi paketlenince kurumlar ya hiç başlamıyor ya da 9 ay sonra hâlâ sözlük tartışıyor. Ben daha küçük, daha kanıt odaklı bir planı tercih ediyorum.

0–30 gün: Sözlük + pilot rol

Çoğu kurum bu aşamada “her rolü kapsayalım” diyor. Hayır. Pilot rol, modelinizin laboratuvarıdır.

30–60 gün: Seviye tanımı + ölçüm prototipi

Bu aşamada ölçümü “tek sınav”a sıkıştırma eğilimi olur. Ben bunu görünce, genelde Saadet Dinç’in (bizim “We’ll Handle It” Specialist) müşteri tarafında en çok duyduğu cümleyi hatırlıyorum: “Eğitimi verdik ama sahada değişen bir şey yok.” Sahada değişmeyen şey, çoğu zaman ölçümün sahaya hiç değmemesidir.

60–90 gün: Açık analizi + akış kararı

Nextrain’de bu “kapı” mantığını AI Gates ve kullanıcıya özel akış kurgusunu AI Rules ile tasarlamak mümkün olduğu için, yetkinlik modeli sadece “hedef tablo” değil, yaşayan bir yolculuk haline gelebiliyor. Ve evet: çalışan tarafında bunun görünür olması önemli. Bu yüzden Passport’ın profilde yetkinlikleri ve sertifikaları tek yerde toplaması, “ben neredeyim?” sorusunu azaltıyor.

Notlar

  1. Alfred Korzybski, Science and Sanity: An Introduction to Non-Aristotelian Systems and General Semantics (1931) — “The map is not the territory.”
  2. Jorge Luis Borges, “The Library of Babel” (1941) — sınırsız bilgi içinde yön bulma problemi.