İşe alım süreci aşamaları nelerdir?

İşe alım aşaması, adayın süreçte nerede olduğunu ve orada kimin ne yapacağını söyleyen bir duraktır. Bir aşama toplantı bittiğinde değil, kayıt değiştiğinde biter. Durum güncellenmemişse aşama, konuşulmuş olsa bile, sistem için gerçekleşmemiştir.

Türkçe kaynaklar süreci genelde sabit bir sayıyla anlatır: yedi aşama, on üç adım. Bu sayı kimsenin şirketinden çıkmıyor. Bir şirkette teknik ödev ayrı bir aşamadır, diğerinde mülakatın içindedir; birinde referans kontrolü vardır, birinde yoktur. Sabit olan sayı değil, sıradır.

GoTeam tarafında bu sıranın karşılığı sabit bir durum kümesidir. Başvuru durumu şemada sekiz değer alır; beşi işe alım kararına kadar olan yolu anlatır: Bekliyor, İnceleniyor, Mülakat, Kabul, İşe Alındı. Kalan üçü Red ile işe alım sonrasıdır. Kendi aşamalarınızı bu kümenin üstüne kurarsınız; kümeyi değiştirmez, doldurursunuz.

• Aşamanın çıktısı bir belge değil, bir durum değişimidir. Kaydedilmeyen çıktı sonraki aşamayı açmaz.
• Geçişi insan yapar. Yapay zeka öneri üretir, hiçbir başvurunun durumunu kendiliğinden değiştirmez.
• Süreçteki tek otomatik durum değişimi son adımdadır: aday bilgi formunu gönderdiğinde başvuru İşe Alındı olur.

Süreç ilanla değil, rolün tanımıyla başlar. Panelde unvan ve departman ilandan ayrı kayıtlardır: Dahili Pozisyon (başlık, departman, seviye, aktiflik) ve Departman. İlan formunda dahili pozisyonu seçtiğinizde departman kendiliğinden dolar; formdan çıkmadan yeni bir pozisyon ya da departman da açabilirsiniz. Yayınlanan iş ilanı ile şirket içi unvan kodda ayrı kavramlardır, ikisini karıştırmak sonraki aşamalarda çalışan kaydının yanlış unvana bağlanmasına yol açar.

İlan formu tek ekranda dört işi birden alır: temel bilgiler, ilan metni, ağırlıklı gereksinimler ve sorumluluklar, puanlama bantları ve ilana özel başvuru soruları. Gereksinim ağırlıklarının toplamı tam 100 olmadan ilan kaydedilmez. Kural iki tarafta birden uygulanır: kaydet düğmesi istemcide açılmaz, sunucu da yazma anında şemayla yeniden doğrular. Sebebi üçüncü adımda görünür, aynı liste değerlendirmenin de kaynağıdır.

İlanı yayına aldığınızda paketinizin aktif ilan hakkı kontrol edilir; hak dolmuşsa yayına alma reddedilir, sınırsız planlarda kontrol atlanır. İlanın arama sonuçlarına girmesi için iki kapının birden açık olması gerekir: ilan aktif olacak, açıklama, gereksinimler ve sorumluluklar toplamı 300 karakteri geçecek. Eşik tahminle değil ölçümle kondu: yayındaki 13 aktif ilanın en kısa gövdesi 310, ortancası 489 karakterdi.

• Bu aşamanın çıktısı: yayında bir ilan, ağırlıkları 100 olan bir gereksinim listesi ve o ilana bağlı bir başvuru formu.
• Karar bantları ilan başına ayarlanır. Varsayılanları güçlü 55, inceleme 35, zayıf 20 ve azalan sırada olmak zorunda.
• Başvuru son tarihi geçen aktif ilanı sistem kapatır, kapanan ilanın adresi 404 döner.

Başvurular şirketin kariyer sayfasından toplanır. Sayfanın adresi /c/ ile başlar, ilan detayı kendi adresinde açılır, başvuru formu ilanın altındadır. Aday tarafında CV yüklemesi yalnızca PDF kabul eder, dosya sınırı 5 MB. Word belgesi yalnız Kurumsal pakette Drive içe aktarımı yoluyla girer, aday alımında değil.

Başvuru kaydedildiği anda arka planda iki iş başlar: adaya alındı e-postası gider ve CV analizi hattı kuyruğa girer. Başvuran bunun için bir şey yapmaz, panelde de bir düğmeye basılmaz. Kayıt Bekliyor durumunda doğar ve ilk insan eylemini, yani incelemeyi bekler.

Burada durum kavramını doğru yerleştirmek gerekiyor, çünkü sürecin geri kalanı buna dayanıyor. Durum bir etiket değil, sonraki aşamanın anahtarıdır. Mülakat planlarken otomatik durum ilerlemesi yalnız Bekliyor ve İnceleniyor durumundaki başvurularda çalışır; belge talebi yalnız Kabul ve İşe Alındı durumundaki başvurularda açılır. Durumu güncellemeden ilerleyen bir süreçte sonraki aşamanın düğmesi hiç açılmaz.

Değerlendirme aşamasında başvuru listesi uyum puanına göre sıralanır ve her satırda bir karar bandı rozeti durur: güçlü eşleşme, incelemede, zayıf eşleşme, kriter dışı. Bantların eşiği ilan başına ayarlanır, yani "güçlü" kelimesi her ilanda aynı sayıyı göstermez. İlk okumada bakılacak yer sıralamanın kendisi değil, bandın ilanın kriterleriyle uyuşup uyuşmadığıdır.

Puanın nasıl çıktığı, puana ne kadar güvenileceğini belirler. Model puan vermez: her kriter için "bu belgede kanıtlı mı" sorusunu cevaplar ve birebir alıntı bırakır, toplamayı kod yapar. Kanıt bulunamayan bir kriter yarım puan sayılmaz, paydadan düşer; kanıtın yokluğu adayın eksiği değildir. Zorunlu işaretli bir kriter karşılanmadığında aday listeden düşmez, puanına tavan konur; varsayılan tavan 54, yani güçlü bandının hemen altı.

Zorunlu kriterlerdeki yıl hesabı modele sorulmaz, kodda yapılır; 12 zor sınır vakasının 12'sinde doğru karar verdi ve hatalı eleme çıkmadı. Sistem geçmiş işe alım sonuçlarından da öğrenmez: kimin mülakata çağrıldığı ya da işe alındığı puanlamaya girmez. Bu aşamanın çıktısı bir puan değil, bir durum değişimidir. Devam edilecek adaylar İnceleniyor, devam edilmeyecekler Red durumuna alınır.

Mülakat Planla penceresinde adayı, tarihi, süreyi ve mülakat tipini seçersiniz. Pencerede "başvuruyu Mülakat durumuna taşı" seçeneği ayrı durur; işaretlerseniz durum kendiliğinden ilerler. Ama yalnız başvuru Bekliyor ya da İnceleniyor durumundaysa. Başka bir durumdaysa geçiş sessizce atlanır, planlama yine de başarılı olur. Bu, planlamanın durum yüzünden düşmemesi için verilmiş bilinçli bir karardır. Sonucu da şu: mülakat takvimde görünürken başvuru eski durumunda kalabilir.

Online mülakat, Google Workspace bağlı değilken planlanamaz; toplantı bağlantısı oradan üretilir. Yüz yüze mülakat Workspace bağlı olmadan da planlanır, yalnız takvim etkinliği oluşmaz. Aynı adaya çakışan saatte ikinci bir mülakat kurulamaz; çakışma kontrolü aday e-postası, saat ve süre üzerinden yapılır ve gerektiğinde elle geçilebilir.

Bu aşamada en çok şaşırtan şey e-postadır. Aşama değişince adaya haber gitmesi bir seçimdir, otomatik değil: durum değiştirdiğinizde panel iki düğme sunar, "Sadece Güncelle" ve "E-posta Gönder". Şirkette e-posta gönderimi kapalıysa yalnız güncelleme düğmesi kalır, pencere bunu yazar. Şablonlu bildirim ise yalnız üç durum için var: Kabul, Red ve İnceleniyor.

Kabul kararı bu süreçte bir bitiş değil, bir kapı açma işlemidir. Belge ve bilgi talebi yalnız Kabul ya da İşe Alındı durumundaki başvurularda açılır; başka bir durumdaki başvuruya talep göndermek servis seviyesinde reddedilir. Talep ekranında son tarih verirsiniz, hazır belge setlerinden seçersiniz, teslim edilen dosyaları aynı ekranda incelersiniz.

Kabul ya da İşe Alındı durumundan geri dönüş serbest değildir. O başvuruya bağlı açık bir belge ya da bilgi talebi varsa sistem uyarı üretir ve geçişin sürmesi için gerekçe yazmanızı ister; gerekçe ayrı bir denetim alanı olarak kaydedilir. Kullanıcılar bunu çoğu zaman hata sanıp vazgeçiyor, oysa kapı bilinçli: açık talebi olan bir adayı sessizce geri almak, adayın hâlâ belge yüklediği bir süreci kapatır.

Son adım süreçteki tek otomatik durum değişimidir. Aday bilgi formunu gönderdiğinde aynı işlemde üç şey birden olur: çalışan kaydı açılır, istihdam dönemi başlar ve başvuru İşe Alındı durumuna geçer. Üçü tek veritabanı hareketidir, biri olmazsa hiçbiri olmaz. Aynı kişi daha önce çalıştıysa yeni bir çalışan kaydı açılmaz; var olan kayıt tazelenir, eski istihdam dönemi kapatılır, yeni dönem açılır ve kurumsal e-posta yeniden kullanılır.

Bir süreci kâğıt üstünde kurmak kolaydır; işleten şey aşamalar arasındaki bağdır. GoTeam'de bu bağ gevşek değil: bir aşamanın çıktısı kaydedilmemişse sonraki aşamanın aracı açılmaz. Bu yüzden aşamaları "kim ne yapar" diye değil, "ne üretir ve o üretim neyi açar" diye okumak gerekiyor.

Aşağıdaki tablo bunu satır satır gösteriyor. Sağ sütun, o çıktı yokken kullanıcının panelde neyle karşılaşacağını yazar. Hata mesajı çıkmaz; düğme hiç görünmez ya da işlem sessizce atlanır.

Aynı ürünü kullanan iki şirket aynı sayıda aşama görmez. Sebep yalnız süreçlerinin farklı olması değil: hangi ekranın kime açılacağını üç ayrı kapı belirler ve bu kapılar birbirinden bağımsızdır. Bir ekranın görünmesi için üçünün de açık olması gerekir.

"Bizde belge aşaması yok" cümlesi çoğu zaman süreçle ilgili değil, kapalı bir kapıyla ilgilidir. Hangi kapının kapalı olduğu bilinmeden süreç yeniden tasarlanırsa aynı yere geri dönülür.

Aşağıdakiler süreç tasarımı hatası değil, işletme hatasıdır: süreç doğru kurulmuştur, aşamalar arasındaki bağ elle bozulur. Dördü de aynı yerden çıkar, bir aşamanın çıktısını kaydetmemekten.

• Durumu en sona bırakmak. Aşama biter bitmez kaydetmek yerine "sonra toplu geçerim" demek, aradaki bütün kapıları kapalı tutar. Mülakat planlanır ama otomatik geçiş çalışmaz, kabul verilir ama belge talebi açılmaz.
• Yapay zekanın önerisini karar sanmak. Puan sıralar ve işaretler; adayı sonraki aşamaya taşıyan işlem her zaman bir kullanıcının onayıdır ve o kullanıcının adıyla kayda geçer.
• İşe Alındı durumunu elle işaretlemek. Çalışan kaydı ve istihdam dönemi yalnız adayın bilgi formu gönderimiyle oluşur; elle işaretlenen bir başvuru süreci yarıda bırakır.
• Aşama değiştirince adaya haber gittiğini varsaymak. E-posta gönderimi pencerede ayrı seçilir ve şablonu olan yalnız üç durum var: Kabul, Red ve İnceleniyor.