Haziran geldiğinde İK'nın masasındaki tablo değişiyor. Yıl boyunca dengeli akan izin talepleri, birdenbire aynı haftaya yığılıyor. Aynı ekipten üç kişi aynı anda izin istiyor. Yönetici kendisi izindeyken bir talep geliyor, kime gidecek belli değil. Köprü tatil öncesi herkes aynı günü hedefliyor.
Bu kaos yeni değil; her yaz tekrarlanıyor. Ama tekrarlanması, önlenemez olduğu anlamına gelmiyor.
"Kim ne zaman izin isteyecek" sorusunu tam olarak tahmin etmek mümkün değil; hava durumu, aile planları, uçak bileti fiyatları gibi pek çok değişken şirketin kontrolü dışında. Bu belirsizliği tamamen ortadan kaldırmak gerçekçi bir hedef değil.
Ama çözülebilir olan farklı bir şey var: görünürlük eksikliği. Bir yönetici, ekibindeki bir talebi tek başına değerlendirdiğinde, o talebin başka bir talep ile çakıştığını göremiyor. Sonuç, iki kişinin aynı haftaya onay alması ve son anda "ikinizden biri vazgeçmeli" konuşmasının yapılması. Bu deneyim hem yöneticiyi hem çalışanı yıpratıyor.
Paylaşılan bir takım takvimi, bu sorunun büyük kısmını çözüyor. Çalışan, kendi talebini oluşturmadan önce ekibinin o hafta ne durumda olduğunu görebiliyorsa, çakışmayı kendisi fark edip farklı bir tarih seçebiliyor. Sorun, talep verildikten sonra çözülmek yerine, talep verilmeden önce önleniyor.
"Müdürüm bana sözlü onay verdi" cümlesi, İK'nın en çok duyduğu ve en az güvenebildiği cümlelerden biri. Yönetici gerçekten onay vermiş olabilir; ama bu onay hiçbir yerde yazılı değilse, iki sorun birden doğuyor.
Birincisi, çakışma riski. Sözlü onaylanan bir talep sisteme girmediyse, başka bir çalışanın aynı tarihe talebi onaylanabilir; iki kişi aynı anda izinli çıkar, kimse bunu önceden göremez.
İkincisi, ispat sorunu. Bir anlaşmazlık çıktığında, sözlü onay hiçbir tarafı korumuyor. Çalışan "izin aldım" diyor, yönetici "öyle bir şey hatırlamıyorum" diyebiliyor. Bu belirsizlik, güven ilişkisini de zedeliyor.
Burada net bir kural gerekiyor: sözlü onay geçici bir işaret olabilir; ama sistemde yazılı hale gelmeden kesinleşmiş sayılmamalı. Bu kural katı görünebilir; ama aslında hem çalışanı hem yöneticiyi koruyor.
Yaz aylarının en sık gözden kaçan sorunu bu. Bir çalışan izin talebi oluşturuyor; ama onaylaması gereken yönetici zaten izinde. Talep havada asılı kalıyor. Çalışan takip ediyor, kimseye ulaşamıyor, tarih yaklaşıyor.
Bu senaryo, aslında bir tasarım eksikliğinin sonucu. Onay akışında "birincil onaylayan müsait değilse ikincil onaylayana yönlendir" kuralı tanımlanmadığında, sistem (ister dijital ister kağıt üzerinde) bir kişiye bağımlı kalıyor. O kişi izindeyken süreç de izine çıkmış oluyor.
Çözüm karmaşık değil: her onay zincirinde bir yedek onaylayan tanımlamak. Bu, teknik bir detay gibi görünse de yaz aylarındaki gecikmelerin büyük bölümünü ortadan kaldırıyor.
Köprü tatiller, izin planlamasının en yoğun olduğu dönem. Herkes aynı üç veya dört günü hedefliyor; çünkü resmi tatille birleştiğinde çok daha az izin günüyle çok daha uzun bir tatil elde ediliyor. Bu matematik, İK'nın kontrolünde değil; ama sonuçları İK'nın masasına düşüyor.
İki yaklaşım öne çıkıyor. Birincisi ilk gelen ilk alır sistemi; basit ama kıdemli çalışanların erken davranma avantajı nedeniyle adalet algısı zayıf kalabiliyor. İkincisi rotasyon sistemi; bu yıl öncelik alan çalışan gelecek yıl geriye düşüyor, uzun vadede daha adil bir dağılım sağlıyor. Hangi yöntem seçilirse seçilsin, kritik olan kuralın önceden belirlenmiş ve tüm ekibe açıkça duyurulmuş olmasıdır. Kural son anda uydurulduğunda, sonucu ne olursa olsun taraflı algılanıyor.
Ofis ortamındaki izin yönetimi ile üretim tesisindeki toplu kapanış yönetimi aynı mantıkla çalışmıyor. Fabrikanın belirli bir dönem için tamamen kapanması (örneğin yaz tatili kapanışı), tekil izin taleplerinden çok daha büyük bir operasyonel planlama gerektiriyor.
Bu senaryoda İK'nın işi bireysel onaylardan çok, toplu atama ve iletişim. Hangi çalışan grubunun bu döneme denk gelen izin hakkı ne kadar, kapanış süresi izin hakkını aşan çalışanlara nasıl bir çözüm sunulacak, kapanış öncesi ve sonrası üretim planı nasıl etkilenecek? Bu sorular tek tek onay vermekten çok daha stratejik bir planlama gerektiriyor ve genellikle aylar öncesinden başlaması gerekiyor.
Bir çalışan resmi izin almadan şehir dışına çıkabilir mi? Bu soru kulağa basit gelse de pratikte belirsizlik yaratıyor. Hafta sonu şehir dışına çıkan bir çalışan, Pazartesi işe gelemeyecek bir durumla karşılaştığında (trafik, uçuş iptali, sağlık sorunu) bu durumun izin kapsamında mı yoksa mazeret kapsamında mı değerlendirileceği net değilse, hem çalışan hem yönetici belirsizlikte kalıyor.
Bu, izin politikasının açıkça tanımlaması gereken bir alan: hangi durumlar önceden onay gerektiriyor, hangi durumlar sonradan bildirimle kabul ediliyor. Belirsizlik burada bırakıldığında, her olay ayrı bir tartışma konusuna dönüşüyor.
Bu kadar çok yapısal sorunu sıraladıktan sonra dürüst bir uyarı gerekiyor: dijital bir izin yönetim sistemi bu sorunların tamamını otomatik olarak çözmüyor. Sistem, çakışan talepleri görünür kılabilir; ama hangi talebin öncelikli olacağına insan karar vermeli. Sistem, yedek onaylayana otomatik yönlendirme yapabilir; ama o yedek onaylayanın kararını sistem vermez. Sistem, kuralları uygular; kuralları koymak hâlâ İK'nın işi.
Yaz yoğunluğunun getirdiği kaosun büyük bölümü, aslında yaz gelmeden çözülebilecek bir tasarım sorunu. Yönetici gelişmemişse, kural belirlenmemişse, yedek onaylayan tanımlanmamışsa, en gelişmiş sistem bile bu boşlukları kapatamıyor.
Ming'in İzin Yönetimi modülü, çalışanların yıllık izin, mazeret izni ve hastalık izni gibi tüm izin türlerini uygulama üzerinden talep etmesini sağlıyor. Yöneticiler talepleri onaylarken ekibin genel izin durumunu görebiliyor; çakışan talepler önceden fark edilebiliyor. Şirketler genel izin politikalarını sisteme tanımlayarak sürecin standart bir çerçevede işlemesini sağlıyor ve departman bazında raporlama ile yaz döneminin nasıl geçtiğini analiz edebiliyor.
Yaz aylarındaki izin karmaşasını azaltmak, doğru sistemle başlıyor ama doğru politika ve netleştirilmiş kurallarla tamamlanıyor. İzin süreçlerinizi bu yaza hazırlamak isterseniz, bize ulaşabilir, ekibinize özel bir değerlendirme talep edebilirsiniz.
Kaynaklar
