İK'da Departman ve Şube Hiyerarşisi Kurmak: Onay Zincirinin Temeli

Departman ve şube hiyerarşisi neden ilk gün kurulmalı

Departman ve şube hiyerarşisi, bir İK sisteminde en son eklenen ama en çok şeyi belirleyen yapı taşıdır. Şirketler genelde sisteme personel kaydıyla başlar, hiyerarşiyi "sonra düzenleriz" diyerek erteler — oysa onay akışının kime gideceği, kimin kimin puantajını gördüğü ve hangi duyurunun hangi ekibe ulaşacağı, tamamen bu hiyerarşinin nasıl kurulduğuna bağlıdır. Hiyerarşi eksik ya da gerçek raporlama hattından kopuk kurulduğunda, sistem teknik olarak çalışır ama pratikte yanlış kişilere talep yönlendirir, yanlış kişilere görünürlük verir.

Bu yazı, bir kez doğru kurulduğunda bir daha dokunmaya gerek kalmayan bir hiyerarşinin nasıl tasarlanacağını ele alıyor — sonradan yama yapmak yerine baştan doğru kurmanın yollarını.

Hiyerarşi sadece bir organizasyon şeması değildir

Çoğu şirket hiyerarşiyi insan kaynakları belgesi gibi düşünür: kimin kime rapor verdiğini gösteren bir şema. Ama bir İK platformunda departman ve şube yapısı üç ayrı şeyi aynı anda belirler:

• Onay zincirinin başlangıç noktasını. Bir izin ya da harcama talebi açıldığında, sistem "bu personelin doğrudan yöneticisi kim" sorusunu hiyerarşiden okur. Hiyerarşi yanlışsa talep hiç var olmayan ya da yanlış bir yöneticiye düşer.
• Görünürlük sınırlarını. Bir saha yöneticisi yalnızca kendi sahasındaki personeli görmeli, bir departman sorumlusu yalnızca kendi departmanının taleplerini onaylamalı. Bu sınır hiyerarşiden türetilir; elle her kullanıcıya tek tek yetki tanımlamak yerine, yapı bir kere kurulduğunda yetki otomatik oluşur.
• Raporlama ve duyuru hedeflemesini. "Bu duyuru sadece İstanbul şubesine gitsin" ya da "bu rapor sadece satış departmanını kapsasın" gibi filtreler, hiyerarşi doğru kurulmadan anlamsızlaşır.

Yani hiyerarşi kurulumu bir kerelik idari iş değil, sistemin geri kalanının üzerine oturduğu temeldir.

Kağıt şema ile gerçek raporlama hattı arasındaki fark

En sık yapılan hata, resmi organizasyon şemasını olduğu gibi sisteme aktarmaktır. Ancak kağıt üzerindeki şema ile gerçekte kimin kime iş teslim ettiği çoğu zaman örtüşmez: bir bölge müdürü şemada genel müdüre bağlı görünür ama günlük operasyonda saha koordinatörüne raporlar; bir muhasebe elemanı departman olarak finansa bağlıdır ama harcama onayları operasyon müdüründen geçer. Sistem kağıt şemaya göre kurulursa, onay talepleri teknik olarak "doğru" bir role gider ama gerçek karar verici bu sürecin dışında kalır — talep onaylanır, sonra gerçek yönetici durumdan habersiz kalır ya da tam tersi, talep gerçek yöneticiye ulaşmadığı için beklemede kalır.

Doğru yaklaşım, hiyerarşiyi kurmadan önce şu soruyu sormaktır: bu personelin işiyle ilgili bir sorun çıktığında, gerçekte kim müdahale ediyor? Cevap, şemadaki kutudan değil bu sorudan gelmelidir.

Kurulum sırası: şube, departman, personel

Pratikte hiyerarşi üç katmanda kurulur ve sıra önemlidir:

1. Şubeler tanımlanır. Fiziksel ya da operasyonel olarak ayrışan birimler (İstanbul ofisi, Ankara şubesi, üretim sahası) önce şube olarak açılır. Çok şubeli bir işletmede her şubenin kendi onay hattı ve raporlama kapsamı olur.
2. Departmanlar her şubenin altına yerleştirilir. Aynı departman adı (örneğin "Muhasebe") birden fazla şubede tekrarlanabilir; önemli olan her departmanın hangi şubeye bağlı olduğunun net olmasıdır.
3. Personel departmanlara atanır ve doğrudan yöneticisi tanımlanır. Bu adım en kritik olanıdır çünkü onay zinciri buradan başlar. Her personelin tam olarak bir doğrudan yöneticisi olmalı; belirsiz ya da çift bağlı personel, onay akışında tıkanmaya yol açar.

Bu sıra atlanırsa — örneğin önce personel eklenip departman sonradan atanırsa — geçiş dönemi boyunca sistemde "yöneticisiz" personel birikir ve bu personelin talepleri hiçbir yere gitmeden bekler.

Çok şubeli yapılarda sık karşılaşılan senaryolar

Tek şubeli küçük bir ekipte hiyerarşi basittir ve nadiren sorun çıkarır. Büyüme ile birlikte üç senaryo düzenli olarak karşımıza çıkar:

• Aynı personel birden fazla sahada çalışıyor. Örneğin bir teknik personel hem İstanbul hem Kocaeli şubesine hizmet veriyor olabilir. Böyle durumlarda personelin birincil bağlı olduğu şube net tanımlanmalı, ikincil görevlendirmeler ayrı bir mekanizmayla (geçici atama gibi) izlenmelidir; aksi halde raporlama hangi şubeye ait olduğunu karıştırır.
• Bir sahanın birden fazla yöneticisi var. Vardiya bazlı çalışan sahalarda gündüz ve gece yöneticisi farklı olabilir. Hiyerarşi bu durumu desteklemiyorsa, gece vardiyasındaki personelin talepleri gündüz yöneticisine düşer ve saatlerce beklemede kalır.
• Yeni şube açılıyor. Şube sayısı arttıkça hiyerarşiyi elle yeniden kurmak zaman kaybettirir. İyi tasarlanmış bir yapıda yeni şube ve departman eklemek, mevcut onay mantığını bozmadan yapılabilmelidir — yeni şube açılış sürecini ele aldığımız yazıda bu adımın işletme tarafındaki karşılığına da değinmiştik.

Hiyerarşi bozukluğunun somut maliyeti

Yanlış ya da eksik kurulmuş bir hiyerarşinin etkisi soyut değildir. Doğrudan yöneticisi tanımsız bir personelin izin talebi kimseye görünmez ve günler boyunca "beklemede" kalır. Departmanı yanlış tanımlanmış bir çalışanın harcama talebi, o harcamayı değerlendirecek bilgiye sahip olmayan bir role gider. Bir şubeye özel duyuru, hiyerarşi yanlış kurulduğu için başka bir şubedeki personele de ulaşır ve gereksiz karışıklık yaratır. Bu sorunların ortak noktası, hiçbirinin sistemin "arızası" olmamasıdır — sistem tam olarak kurulduğu hiyerarşiye göre çalışmaktadır, sorun kurulumdadır.

Kurulumda dört pratik kural

Vekaleti unutmayın. Bir departman sorumlusu izinliyken talep zincirinin kilitlenmemesi için, her kritik role bir vekil ya da otomatik yükselme kuralı tanımlanmalıdır. Doğrudan yönetici izinliyken talebin bir üst role otomatik yükselmesi, hiyerarşinin gerçek raporlama hattını yansıtmasının doğal bir sonucudur.

Rolü kişiyle karıştırmayın. "Bu departmanı Ayşe yönetiyor" değil, "Bu departmanın sorumlusu şu rol, o role şu an Ayşe atanmış" mantığıyla kurun. Personel değişikliğinde yalnızca atama değişir, hiyerarşinin kendisi bozulmaz.

Toplu aktarımı hiyerarşi kurulduktan sonra yapın. Mevcut personel listesini CSV ile içe aktarmadan önce şube ve departman yapısının tanımlı olması, her personelin doğru yere düşmesini garanti eder; aksi halde aktarım sonrası tek tek düzeltme gerekir.

İlk ay çıktılarını gözden geçirin. Hiyerarşi kurulduktan sonraki ilk birkaç hafta, hangi taleplerin beklemede kaldığına ve hangi duyuruların hedefine ulaşmadığına bakmak, kağıt üzerinde doğru görünen ama pratikte eksik kalan bağlantıları ortaya çıkarır.

Sonuç

Departman ve şube hiyerarşisi, İK sisteminin görünmeyen ama her şeyi belirleyen omurgasıdır. Doğru kurulduğunda onay akışı, görünürlük ve raporlama kendiliğinden düzgün işler; yanlış kurulduğunda ise her modül ayrı ayrı "bozuk" gibi görünür çünkü asıl sorun hiçbirinde değil, temelde saklıdır. HR-Tech'in saha takipli İK platformunda şirket kaydı self-service yapılır ve hemen ardından şube-departman-personel hiyerarşisi kurulur; bu yapı bir kere doğru tanımlandığında onay akışı, yetki görünürlüğü ve hedefli duyurular otomatik olarak üzerine oturur. Hiyerarşinizi sıfırdan kurmak ya da mevcut yapınızı gözden geçirmek isterseniz iletişim sayfamızdan ulaşın.