İzin ve talep süreçleri: kâğıttan self-servise

İzin, masraf, BT desteği ve oda talepleri nasıl dijitalleşir? Onay akışı, kıdeme göre izin hakkı, form şablonları ve süreçlerin ölçülmesi üzerine pratik rehber.

Self-servis talepler, bir intranetin en hızlı geri dönüş üreten bileşenidir. Sebebi basit: izin ve masraf süreçleri çoğu şirkette hâlâ e-posta, kâğıt form ve "elden imzaya" karışımıyla yürür; her adımı birinin hatırlaması gerekir.

Mevcut sürecin gerçek maliyeti

Bir izin talebinin elle işlenmesi genelde şöyledir: çalışan formu bulur (5 dk), doldurur, yöneticiye e-postayla gönderir, yönetici birkaç gün sonra fark eder, onaylar, İK'ya iletir, İK bir tabloya işler. Toplamda 15–20 dakikalık dağınık iş ve üç kişi.

Ayda 60 talep alan bir şirkette bu, yılda 200 saatin üzerinde bir yüktür. Üstelik en sinir bozucu kısmı bu değildir: çalışan talebinin nerede olduğunu bilmez, bu yüzden sorar; soru da ayrı bir yük üretir.

Dijitalleştirmede doğru sıra

Tüm talep türlerini aynı anda açmak yerine ikiden başlayın: izin ve BT desteği. İkisi de yüksek hacimlidir ve kuralları nettir. Masraf süreci genellikle muhasebe entegrasyonu ister; oda ve araç rezervasyonu ise çakışma kontrolü gerektirir. Bunları ikinci dalgaya bırakmak, ilk dalganın alışkanlık hâline gelmesini kolaylaştırır.

Onay akışı: basit tutun

Çok kademeli onay zincirleri kâğıt üzerinde kontrollü görünür, pratikte tıkanır. Çoğu talep türü için tek kademe — doğrudan yönetici — yeterlidir. İkinci kademeyi yalnızca gerçekten gerekli olduğu yerde (belirli tutarın üzerindeki masraflar gibi) ekleyin.

Kritik ayrıntı, onay kararının kim tarafından ve ne zaman verildiğinin kayıtlı olmasıdır. Bildirimlerin ve puan/bakiye değişimlerinin de bu karara bağlı olarak sunucu tarafında üretilmesi gerekir — istemcinin "onaylandı" deyip kendi kaydını yazması, iki tarafın birbirinden sapmasına açık kapı bırakır.

Kıdeme göre izin hakkı

Türkiye'de yıllık izin süresi İş Kanunu'nun 53. maddesine göre kıdeme bağlıdır: 1–5 yıl arası 14 gün, 5–15 yıl arası 20 gün, 15 yıl ve üzeri 26 gün. 18 yaşından küçükler ve 50 yaşından büyükler için taban 20 gündür.

Bu hesabın sistemde otomatik yapılması iki hatayı önler: yanlış bakiye ve tartışma. Hesabın girdisi işe giriş tarihidir; o da zaten profilde durur. Ayrı bir tablo tutmaya gerek yoktur.

Form şablonları ve alanlar

Talep formlarının sabit olması gerekmez. "BT desteği" talebinde cihaz türü, "masraf" talebinde tutar ve fiş eki, "oda rezervasyonu"nda tarih aralığı ve katılımcı sayısı sorulur. Bu alanların yöneticiler tarafından özelleştirilebilmesi, İK'nın her yeni ihtiyaçta yazılım ekibine gitmesini engeller.

Ek dosya desteği özellikle masraf sürecinde belirleyicidir; fişin talebe bağlı durması, muhasebenin ayrıca dosya kovalamasını bitirir.

Bildirim dengesi

Talep süreçleri bildirim üretmeye çok müsaittir: açıldı, görüldü, onaylandı, reddedildi, hatırlatma... Hepsini göndermek çalışanı yorar. İşe yarayan sadeleştirme: talep sahibine yalnızca durum değiştiğinde, yöneticiye ise karar bekleyen bir şey olduğunda bildirim.

Bildirim yorgunluğunun neden ciddi bir risk olduğunu çalışan katılımı yazımızda anlattık.

Ölçüm: iki rakam yeter

Ortalama karar süresi ve bekleyen talep sayısı. Birincisi sürecin sağlığını, ikincisi darboğazı gösterir. Belirli bir yöneticide sürekli biriken talepler, sistem sorunu değil yönetim sorunudur — ama görünür olmadan çözülmez.

Yönetim panelinde bekleyen işleri tek bakışta gösteren bir şerit, bu iki rakamı günlük rutine sokmanın en basit yoludur.

Oda ve araç rezervasyonu

Talep altyapısının en çok gözden kaçan kullanımı rezervasyonlardır. Toplantı odası ve araç talepleri diğer taleplerden bir noktada ayrılır: çakışma riski taşırlar. Aynı odayı iki kişinin aynı saate ayırması, onay akışıyla değil veritabanı seviyesinde bir kısıtla önlenmelidir; arayüzde takvimi gri göstermek yeterli değildir, çünkü iki kişi aynı anda gönder tuşuna basabilir.

Bu ayrıntı küçük görünür ama güveni belirler: bir kez çakışan rezervasyon yaşayan ekip, bir daha sisteme değil takvim davetine güvenir.

ERP ile ilişki

Talep sistemi ERP'nin yerini almaz. ERP kaydın kendisini tutar; intranet o kaydın çalışana bakan yüzüdür — bakiyeyi gösterir, talebi başlatır, onayı taşır, sonucu bildirir. Onaylanan talebin ERP'ye aktarılması ise bir entegrasyon meselesidir ve ikinci fazda ele alınmalıdır.

Bütçe ve kurulum sırasını maliyet yazımızda ve 90 günlük planda bulabilirsiniz.

Talep akışları, çalışanın kendi işini kendi halledebildiği daha geniş bir yapının parçasıdır; hangi işlemlerin açılması hangilerinin açılmaması gerektiğini self servis İK yazısında ele aldık. Onay zincirlerinin kurallara bağlanması için iş akışı otomasyonu yazısına bakabilirsiniz.