İşe Alım Hunisi Raporu Nasıl Hazırlanır: Adım Adım

Bir işe alım yöneticisi bir pozisyonu doldurmanın ne kadar sürdüğünü soruyor. Siz 34 gün diyorsunuz. Odadaki başka biri ise 51 diyor.

İkiniz de aynı aday takip sistemini okuyorsunuz. Siz talebin onaylandığı günden itibaren ölçüyorsunuz, onlar ise iş ilanının yayınlandığı günden itibaren ölçüyor.

İşe alım metriklerinde sürekli tekrarlanan sorun budur. Aşama adları standart görünür, ancak başlangıç ve bitiş noktaları standart değildir.

Bu kılavuz, bir işe alım hunisi raporunda nelerin yer alması gerektiğini ve iki hız metriğinin neden karıştırıldığını ele almaktadır. Ardından, aşama tanımlarınızı nasıl düzelteceğinizi ve bir dışa aktarma dosyasından bu raporu nasıl oluşturacağınızı açıklamaktadır.

Bir işe alım hunisi raporunda neler yer almalıdır

Bir işe alım hunisi raporu, bir dizi sayı ve bu sayılar arasındaki düşüşten oluşur. Geri kalan her şey bunlardan türetilir.

Belirli bir dönem için aşama sayılarıyla başlayın. Alınan, değerlendirilen, mülakat yapılan, teklif sunulan ve kabul edilen başvurular.

Rapor satırı	Ne olduğu	Nereden geldiği
Aşama sayıları	Her aşamaya ulaşan adaylar	Aday takip dışa aktarımı
Verim oranları	Her aşamanın bir önceki aşamaya bölünmesi	Sayılardan türetilir
Time to fill	Talep onayından kabul edilmeye kadar geçen süre	Talep tarihleri
Time to hire	Aday havuzuna girişten kabul edilmeye kadar geçen süre	Aday tarihleri
Teklif kabul oranı	Yapılan tekliflere oranla kabul edilen teklifler	Teklif kayıtları
İşe alım başına maliyet	İşe alımlara oranla işe alım maliyetleri	Takip sistemi değil, finans departmanı

Ardından ardışık aşamalar arasındaki dönüşümü ekleyin. Workable bunlara işe alım verim oranları adını verir ve ham sayıları bir teşhise dönüştüren şey de bunlardır.

Sırada iki hız ölçümü var ve bunların ayrı tanımlara ihtiyacı var. Bunlar hakkında daha fazla bilgi aşağıda yer almaktadır.

Raporu, Workable'ın kabul edilen tekliflerin toplam teklif sayısına bölünmesi olarak tanımladığı teklif kabul oranı ile bitirin. Bu, listedeki en az maliyetli ve genellikle en çok şey gösteren metriktir.

Nelerin hariç tutulacağı konusunda bir uyarı. Workable, bir aday takip sisteminin, pozisyon doldurma süresini ve verim oranlarını raporlasa bile "işe alım başına ortalama maliyetinizi hesaplayamayacağını" belirtmektedir.

Dolayısıyla, işe alım başına maliyet için sadece işe alım hunisine değil, finans verilerine de ihtiyaç vardır. Bunun formülü, iç ve dış işe alım maliyetlerinin toplamının toplam işe alım sayısına bölünmesidir.

Time to fill ve time to hire aynı metrikler değildir

En çok tartışmaya yol açan tanım budur ve kaynak bu konuda son derece nettir.

Workable'ın time to fill ve time to hire kılavuzu, time to fill metriğini "iş talebinin onaylanmasından adayın kabulüne kadar geçen süre" olarak tanımlar.

Time to hire ise farklıdır. Bu metrik, "bir adayın sürece girmesinden iş teklifini kabul etmesine kadar geçen süreyi ölçer."

Sırada duvara asılmaya değer o cümle var. Workable, "time to hire'ın genellikle time to fill ile eş anlamlı kullanıldığını" belirtiyor. Ayrıca bunları "ayrı metrikler olarak ele alıp farklı içgörüler de elde edebileceğinizi" ekliyor.

Dolayısıyla, bu iki isim pratikte birbirinin yerine kullanılmaktadır. Rakamlarınızın başka bir şirketin rakamlarıyla eşleşmemesinin nedeni tam olarak budur.

Bu ayrımı bir kez netleştirdiğinizde oldukça faydalıdır. Time to fill, henüz kimse başvurmadan önceki haftalar da dahil olmak üzere tüm süreci ölçer. Time to hire ise sonunda seçtiğiniz kişiyi ne kadar hızlı fark edip harekete geçirdiğinizi ölçer.

Workable'ın kendi pratik örneği bunu somutlaştırıyor. Pozisyon birinci günde açıldıysa, işe alınan kişi onuncu günde başvurduysa ve yirmi beşinci günde kabul ettiyse, time to hire süresi on beş gündür.

Saymaya başlamadan önce tanımları netleştirmek

Dört kararın yazılı hale getirilmesi gerekir. Bunları atlarsanız, trend çizginiz yalnızca kendi tutarsızlığınızı ölçecektir.

Sürenin ne zaman başladığı. Workable savunulabilir üç seçenek sunar: işe alım yöneticisinin pozisyonu göndermesi, İK veya finansın bunu onaylaması ya da bir işe alım uzmanının ilan vermesi.

Burmadaki talimat, birini seçip tutarlı olmaktır. Kılavuz, "şirketiniz için en mantıklı olanı seçmenizi" ve ardından bunu "tüm pozisyonlar ve ekipler için" aynı şekilde saymanızı öneriyor.

Hangi taleplerin hariç tutulacağı. Workable bu konuda nettir ve sürekli açık olan (evergreen) pozisyonların hariç tutulmasını tavsiye eder. Her zaman açık olan pozisyonlar, "işe alım sürecinizin verimliliğini yansıtmadan ortalama time to fill sürenizi büyük ölçüde şişirecektir."

Takvim günleri mi yoksa iş günleri mi. Workable'ın tanımı takvim günlerini kullanır. Eğer NETWORKDAYS işlevini kullanırsanız, yayınlanan sürümle karşılaştırılamayacak kadar küçük bir sayı elde edersiniz.

Ortalama mı yoksa medyan mı. Çoğu raporun gösterdiği şey ortalamadır ve 200 günlük tek bir talep bu ortalamayı ciddi şekilde yukarı çeker. Hacim düşük olduğunda, yanına median değerini de raporlayın.

Workable'ın ortalama alma örneği, sadeliği nedeniyle kopyalamaya değerdir. 20, 30 ve 40 günlük üç pozisyon, 30 günlük bir ortalama verir.

Manuel olarak nasıl yapılır

Seçenek 1: Aşama sayıları ve oranları

Döneme ve aşama alanına göre filtrelenmiş olarak her aşamayı COUNTIFS ile sayın.

Sayıların azalarak gittiğini kontrol edin. Sonraki bir aşama önceki bir aşamayı aşıyorsa, dışa aktarma dosyanız bir aşamayı atlayan veya sürece yeniden dahil olan adaylar içeriyor demektir.

Ardından her aşamayı bir önceki aşamaya bölün. Bu oranlar, en basit haliyle işe alım hunisidir.

Aynı sayıların yer aldığı bir huni grafiği, tablodan daha hızlı okunur. Huni grafiği nedir hakkındaki açıklayıcı yazımız, bu şeklin ne zaman yardımcı olacağını ele almaktadır.

Burmadaki sınır, tek bir dönem için tek bir oran seti elde etmenizdir; hangi pozisyonların veya ekiplerin bunlara neden olduğuna dair hiçbir bilgi içermez.

Seçenek 2: Her talep için bir satır

Her talep için bir satır içeren bir tablo oluşturun. Açılış tarihi, ilan tarihi, kabul tarihi, başvuru sayısı ve gün farkları için sütunlar ekleyin.

Sonraki tarihten önceki tarihi çıkararak gün farklarını hesaplayın. Microsoft'un DATEDIF işlevine ilişkin kılavuzu, bu işlevin "belirli senaryolar altında yanlış sonuçlar hesaplayabileceği" konusunda uyarmaktadır.

Artık rapor kırılımlara ayrılabilir. Departmana, kıdeme, işe alım uzmanına veya kaynağa göre.

Cevap bu kırılımlarda gizlidir. Harmanlanmış 40 günlük bir rakam, genellikle mühendislikteki 70 günü ve destekteki 18 günü gizler.

Burmadaki sınır ise birleştirmedir. Bir aday dışa aktarım dosyasını bir talep tablosuyla eşleştirmek, formüllerin kolayca halledebileceği aşamayı aşar.

Seçenek 3: Tanımlar sekmesi

Yukarıdaki dört kararı, kullanılan aşama adlarını ve listenin dondurulduğu tarihi kaydedin.

Hariç tutulanlar listesini açıkça ekleyin. Sürekli açık pozisyonlar, iptal edilen talepler ve şirket içi transferlerin her birinin nasıl ele alınacağının belirtilmesi gerekir.

Sınırlandırma tanıdıktır. Bir kuralı belgelemek onu uygulamaya koymaz ve birileri önümüzdeki çeyrekte filtreleri zaten yeniden oluşturacaktır.

Ortak sınır. Her üçü de dışa aktarım dosyanızın yalnızca mevcut aşamayı değil, aşama geçmişini de gösterdiğini varsayar. Eğer adayların yalnızca bugün nerede olduğunu gösteriyorsa, geçen çeyreğin hunisini hiçbir şekilde yeniden oluşturamazsınız.

Manuel yöntemin yavaşladığı yerler

İlk işe alım hunisi raporu bir sabahınızı alır. Dördüncüsü ise daha uzun sürer, çünkü süreç bu süre zarfında değişmiştir.

Aşama yeniden adlandırmaları genellikle asıl sorumludur. Bir ekip telefon değerlendirmesini ön değerlendirme ile birleştirir ve işe alımda hiçbir değişiklik olmamasına rağmen iki aşama arasındaki oran bozulur.

İptal edilen talepler ise ikincisidir. İşe alım yapılmadan kapatılan bir pozisyonun bitiş tarihi yoktur ve bu durum ya ortalamadan kaybolur ya da orada boş bir alan olarak kalır.

Bir de kıyaslama sorusu var. Birisi 42 günün iyi olup olmadığını sorar ve Workable'ın kendi uyarısı devreye girer: diğer şirketler "time to fill süresini sizinkiyle aynı şekilde hesaplamıyor olabilir."

Bu işin araçlar boyutu, AI tools for HR and people analytics yazımızda kendi derlemesine sahiptir.

Powerdrill Bloom ile nasıl oluşturulur

Adım 1: ATS dışa aktarım dosyanızı yükleyin

Aday dışa aktarım dosyasını veya aday ve talep dosyalarını birlikte yükleyin. Powerdrill Bloom, sütunları yükleme anında analiz eder; böylece boş tarihler, tutarsız aşama adları ve yinelenen aday kayıtları, herhangi bir oran hesaplanmadan önce ortaya çıkar.

Adım 2: Raporu doğal dille tanımlayın

Tanımları oluşturmak yerine onları ifade edin. Süre başlangıcını, aşama sırasını, hariç tutulanları ve takvim günleri mi yoksa iş günleri mi istediğinizi belirtin.

Ardından hataları yakalayan soruları sorun. Hangi taleplerin bitiş tarihi olmadığını sorun. Hangi aşama adlarının dönemin yalnızca bir kısmında göründüğünü sorun. Son olarak, departmana ve kıdeme göre ayrılmış işe alım hunisini isteyin.

Adım 3: Grafiği, raporu veya sunumu dışa aktarın

Aşama sayılarını oranlarıyla birlikte, aynı rakamların huni grafiğini veya sayıların yanında tanımları taşıyan slaytları alın.

Sık yapılan hatalar

Time to fill ve time to hire metriklerini tek bir sayı olarak ele almak. Farklı anlarda başlarlar. Hangisini raporluyorsanız etiketleyin ve bu etikete sadık kalın.

Sürekli açık (evergreen) pozisyonları ortalamada bırakmak. Her zaman açık olan pozisyonlar, süreç hızı hakkında hiçbir şey söylemeden rakamı şişirir.

Rakamınızı başka bir şirketin rakamıyla karşılaştırmak. Farklı başlangıç noktaları karşılaştırmayı anlamsız kılar. Bunun yerine kendi trendinizi takip edin.

Düşük hacimde ortalama raporlamak. Altı işe alım ve bir zorlu arama süreci, yanıltıcı bir ortalama üretir. Yanında medyanı da gösterin.

İptal edilen talepleri sessizce göz ardı etmek. İşe alım yapılmadan kapatılan bir pozisyon gerçek bir sonuçtur. Filtrelemek yerine bunu bir yerde hesaba katın.

Takvim günleri ile iş günlerini karıştırmak. Her ikisi de savunulabilir ancak birbiriyle karşılaştırılamaz. Birini seçin ve rapora yazın.

Yeniden adlandırılan aşamaları göz ardı etmek. Birleştirilmiş bir aşama bir oranı bozar ve geri kalanını olduğu gibi bırakır; bu da gerçek bir bulgu gibi görünür ama aslında değildir.

Sonuç

Süre başlangıcını netleştirin, sürekli açık pozisyonları hariç tutun, her aşamayı sayın ve oranları elde etmek için ardışık aşamaları bölün. Ardından iki hız metriğini ayrı adlar altında raporlayın.

Sayılar nihai çıktı değildir. Adayların durduğu aşama, gelecek ay neyi değiştirmeniz gerektiğini size söyleyen şeydir.

Tek bir ortalamadan bahsetmek yerine bir işe alım hunisi raporu oluşturmanın tüm esprisi budur. Tek bir sayı size nasıl yaptığınızı söyler, huni ise nerede yaptığınızı gösterir.

Her döngüde bu görünümü yeniden oluşturmak çeyreğinizi yiyip bitiriyorsa, ATS dışa aktarım dosyanızda Powerdrill Bloom'u deneyin. Ayrıca kadro ve işten ayrılma raporu oluşturma kılavuzumuza ve AI report generator sayfamıza göz atın.

Sıkça sorulan sorular

Time to fill ve time to hire arasındaki fark nedir?

Time to fill, talep onayından kabule kadar geçen süreyi kapsar. Time to hire ise nihayetinde işe alınan kişinin sürece girmesinden aynı kabule kadar geçen süreyi kapsar.

Ortalama time to fill süresini nasıl hesaplarım?

Dönem içinde doldurulan her pozisyon için time to fill süresini toplayın, ardından pozisyon sayısına bölün. Workable, her zaman açık olan pozisyonların bu ortalamadan hariç tutulmasını tavsiye eder.

İyi bir time to fill süresi nedir?

Workable, Society for Human Resource Management'tan alınan ortalama 42 günlük bir süreyi aktarmaktadır. Ayrıca diğer şirketlerin bu metriği sizinle aynı şekilde hesaplamıyor olabileceği konusunda da uyarmaktadır.

Bir işe alım hunisi raporu hangi aşamaları içermelidir?

Sürecinizin gerçekte sahip olduğu aşamalar neyse, sırasıyla, sayılarla ve her bir çift arasındaki dönüşümle birlikte yer almalıdır. Dönemler arasındaki tutarlılık, bir şablona uymaktan daha önemlidir.

Aday takip sistemim bu raporu oluşturabilir mi?

Genellikle aşama sayılarını, verim oranlarını ve time to fill süresini raporlayabilir. Workable, finans verilerine ihtiyaç duyan işe alım başına ortalama maliyeti hesaplayamayacağını belirtmektedir.