Net politikalar ve onaylar için izin talebi sistemi tasarımı

Çoğu izin sürecinde ne bozuluyor

İnsanlar bir izin talebinin bir toplantı ayarlamak gibi hissettirmesini bekler: tarihleri seç, bakiyeni gör, net bir evet ya da hayır al ve gereken her yerde görünsün. Bu şekilde çalışmadığında ekipler "sadece bana mesaj at"a döner ve sistem güvenilir bir araç yerine kayıt tutma işi haline gelir.

Talepler genellikle devralmalarda takılır: doğru yöneticiyi kaçıran bir e-posta zinciri, kimsenin güncellemediği bir elektronik tablo veya daha sonra denetlenmesi imkânsız bir sohbet onayı. Çalışan kendini korunduğunu düşünür, yönetici İK'nın halledeceğini düşünür ve İK maaş zamanı geldiğinde bakiyenin yanlış olduğunu görür.

Zaman-off talep sistemi tasarımının gerçek hedefi sıkıcı ama önemlidir: doğru bakiyeler, net onaylar ve tek bir gerçek kaynağı. Bakiyen doğru ama onaylar belirsizse, yöneticiler sürekli "Bunu onayladım mı?" diye sorar. Onaylar mükemmel ama takvim yanlışsa ekipler yine çakışma yaşar.

Aynı iş akışına dört grup ihtiyaç duyar, ama farklı nedenlerle:

• Çalışanlar: hızlı talepler, anında durum ve kayda alındığına dair güven
• Yöneticiler: karar vermek için yeterli bağlamla doğru talebin onlara yönlendirilmesi
• İK/maaş: politikaların tutarlı uygulanması ve ödeme kurallarına uyan bakiyeler
• İş: özel ayrıntıları açığa çıkarmadan ekip görünürlüğü

"Okunabilir bir iş akışı" demek, adımlara bakıp düz bir dille açıklayabilmek demektir: isteği ne tetikliyor, kim onaylıyor, reddedildiğinde ne oluyor ve ne geri yazılıyor (bakiye, durum, takvim). Bunu hızlıca açıklayamıyorsanız, insanlar sistemi atlayacaktır.

AppMaster gibi araçlar, mantığı görsel ve merkezi tutarak politika değişikliklerinin e-posta ve istisna labirentine dönüşmesini önlemeye yardımcı olabilir.

İhtiyacınız olan temel veriler (aşırıya kaçmadan)

İyi bir izin aracı çoğunlukla temiz bir kayıt seti ve birkaç net ilişkidir. Temelleri doğru alırsanız, izin talebi sistemi tasarımınız okunaklı kalır, politikalar ve onaylar sonradan büyüse bile.

Bir dakikada açıklayabileceğiniz küçük bir çekirdek nesne setiyle başlayın:

• Employee: izin isteyen kişi (ve onu kim onaylar).
• TimeOffRequest: gerçek talep (tarihler, tür, durum).
• Policy: bir izin türü için kurallar (PTO, hastalık, ücretsiz izin).
• Balance: bir çalışanın ve politikanın mevcut kullanılabilir miktarı.
• Approval: bir taleple bağlantılı kararlar ve yorumlar.

Talepler için gerçek dünya acısını önleyen alanlar gösterişli değildir. Özgül olmalıdırlar. Başlangıç ve bitiş tarih/saatini, kısmi gün olup olmadığını ve talep sırasında çalışanın zaman dilimini saklayın. Kısa bir neden ekleyin ve İK süreciniz kanıt gerektiriyorsa ekleri izin verin (örneğin doktor raporu). Ekleri isteğe bağlı tutun ki normal PTO engellenmesin.

Durumlar az ve öngörülebilir olmalıdır: taslak (kaydedildi ama gönderilmedi), gönderildi, onaylandı, reddedildi ve iptal edildi. Gerçekten ihtiyaç yoksa "İK bekliyor" gibi ekstra durumlardan kaçının.

Denetim kaydını atlamayın. En azından "kimi, neyi ve ne zaman değiştirdi" kaydı ihtilaflarda sizi kurtarır. En azından gönderme, onaylama, reddetme, iptal ve tarih düzenlemelerini kaydedin.

Ekipler, lokasyonlar ve departmanlar için bunları ayrı referans verisi olarak ele alın. Çalışanları bu gruplara bağlayın ve politikalara uygulandıkları grupları bağlayın. Böylece biri ofis değiştirdiğinde bir çalışan kaydını güncellersiniz, her politikayı değil.

Bunu AppMaster'da kuruyorsanız her nesneyi önce basit tutun, sonra veri stabil olduğunda doğrulamalar ve iş akışı adımları ekleyin.

Politika kuralları: açık ve test edilebilir tutun

İyi politikalar kasıtlı olarak sıkıcıdır. İnsanlar Click Submit etmeden önce sonucu tahmin edebilmelidir. İzin talebi sistemi tasarımında güvenin en hızlı kaybı aynı talebin bir hafta onaylanıp ertesi hafta reddedilmesidir.

İzin türlerinizi adlandırarak başlayın ve her biri için bir düz cümle yazın. Tatil veya PTO planlı uzak kalmadır. Hastalık izni plansız sağlık kaynaklı izindir. Ücretsiz izin maaşsız izindir. Ebeveyn izni genellikle özel tarihler ve belgeler içerir. Fazla mesai karşılığı verilen "comp time" gibi kazanılan saatler PTO gibi harcanır.

Uygunluk kuralları bir hukuki belge gibi değil, bir kontrol listesi gibi okunmalıdır. Kim kullanabilir (tam zamanlı, yarı zamanlı, sözleşmeli), ne zaman başlar (deneme süresinden sonra, X gün sonra) ve hizmet süresine bağlı olup olmadığı gibi açık olun. Bir kuralın istisnaları varsa, istisnayı ayrı bir kural olarak yazın, dipnot olarak değil.

Karışıklığın genelde başladığı yer talep kurallarıdır. Bildirim süreleri, karartma tarihleri ve izin verilen en küçük zaman birimi konusunda spesifik olun. Örneğin: "Tatil talepleri acil durumlar hariç 5 iş günü öncesinden gönderilmelidir, acil durumlar İK tarafından onaylanır" denilebilir. "Erken gönderin" gibi ifadeler test edilebilir değildir.

Devretme ve sona erme kuralları bir cümleye sığmalıdır. Örnek: "En fazla 40 saat sonraki yıla devreder ve 31 Mart'ta expirer." İkinci cümle gerekiyorsa, politika fazla karmaşık demektir.

Politika metni ile kural mantığını senkron tutmanın basit bir yolu:

• Her kurala kısa bir ID verin (örneğin PTO-NOTICE-5D)
• Kural yapılandırmasının yanında düz dilde metni saklayın
• Her kural için 2-3 örnek vaka ekleyin (onaylandı veya reddedildi) olarak testler
• Kural yapılandırması değiştiğinde yalnızca politika metnini değiştirin (ve tersi)

Örnek: Deneme süresindeki bir çalışan yarın için 2 saatlik PTO talep eder. Sistem bunu iki okunaklı nedenle engellemelidir: "PTO 60 günden sonra başlar" ve "PTO için 5 iş günü önceden bildirim gerekir." AppMaster'da bunları kural düğümlerinin yakınında tutun ki güncellemeler zaman içinde kaymasın.

Kazanım (accrual) hesaplaması: kafa karıştıran desenler

Kazanım, küçük kuralların biriktiği yer olduğu için izin talebi sistemi tasarımında çoğu zaman karmaşaya neden olur. Hedef gösterişli matematik değil; HR ve çalışanların bakiyeyi kontrol ettiğinde beklediği tahmin edilebilir sonuçlardır.

Yaygın bir karışıklık kazanım stillerinin karıştırılmasıdır. Bazı şirketler her bordro döneminde saat ekler, bazıları aylık ekler, bazıları çalışılan saate göre kazanım yapar, bazıları ise yıllık miktarı sabit bir tarihte verir. Sorunlar yalnızca "bakiye"yi saklayıp "nasıl kazanıldığı"nı unutunca başlar. Olayları açıkça kaydedin: verme (grant), kazanım (accrue), düzeltme (adjustment) ve kullanım (usage).

Prorasyon (orantıl hesap) başka bir tuzaktır. Ay ortasında başlayan yeni bir çalışan ya da yarı zamanlıdan tam zamanlıya geçen bir çalışan için elle elektronik tablo düzeltmesi yapmamak istersiniz. Bir kural belirleyin ve ona sadık kalın. Örneğin: dönemdeki takvim günlerine göre prorate edin veya planlanan saatlere göre. Hangisini seçerseniz seçin, düz cümleyle yazın ve her yerde aynı şekilde kodlayın.

Limitler (cap) ve negatif bakiyeler "yanlış görünüyor" biletlerine yol açar. Devretmeye izin veriyorsanız cap'i belirli bir anda uygulayın (yıl sonu, kazanım dönemi sonu veya her kazanım sonrası). Negatif bakiyelere izin veriliyorsa limiti ve işten ayrılmada ne olacağını tanımlayın.

Yuvarlama kuralları sessiz sürüklenmeye sebep olur. Bir yuvarlama düzeyi seçin (dakika, çeyrek saat, yarım gün) ve bunu hem kazanım hem de kullanım için tutarlı uygulayın. Dakikada kazanıp yarım gün talep ediyorsanız çalışanlar sistemin hep yanlış olduğunu hisseder.

Geri tarihli talepler ve düzeltmeler denetim kaydı gerektirir. Birisi geçen hafta için talep gönderirse, sistem isteğin yapıldığı tarihten itibaren yeniden hesaplamalı ve değişikliği kaydetmelidir.

Çoğu ihtilafı önleyen basit kontrol listesi:

• Bakiyede yapılan değişiklikleri tek bir sayı olarak değil tarihli işlemler (transactions) olarak saklayın
• Politika girdileri değiştiğinde etkin tarihten itibaren yeniden hesaplayın
• Cap ve yuvarlamayı ortak bir fonksiyonda uygulayın
• Elle yapılan düzeltmeleri kazanım mantığından ayrı tutun
• Gösterilen her bakiyede "tarihe göre" (as of date) gösterin

AppMaster'da bu genellikle bir Transactions tablosuna ve bir talep onaylandığında veya düzeltildiğinde bakiyeleri yeniden hesaplayan küçük bir iş sürecine net olarak eşlenir.

Yönetici onayları: kenar durumları kapsayan basit yönlendirme

Bir yönetici onay iş akışı bir soruyu yanıtlamalı: kim "evet" diyebilir ve emin olabilir? Her org şeması detayını modellemeye çalışırsanız, izin talebi sistemi tasarımınız okunması zor ve düzeltmesi daha da zor hale gelir.

Varsayılan bir kural ile başlayın: çalışanın doğrudan yöneticisi onaylar. Risk veya sorumluluğu değiştiren istisnaları yalnızca ekleyin. Kural sırasını açık tutun, böylece ayarları kazmadan sonucu açıklayabilirsiniz.

Tek adımlı vs çok adımlı onaylar

Çoğu ekip standart PTO için tek onay adımı kullanabilir. Onaylama, maaş, uyumluluk veya ekipler arası kapsama etki ettiğinde adımlar ekleyin.

Okunaklı kalan yaygın desenler:

• Tek adım: Yönetici standart PTO ve ücretsiz izin için onaylar.
• İki adım: Yönetici sonra İK; belgeler veya politika kontrolleri gereken izin türleri için.
• İkinci onaycı: Vardiyalı kapsama (örneğin nöbet rotasyonu) etkileniyorsa bölüm başkanı eklenir.
• Otomatik onay: Riske düşük talepler (1-2 saatlik randevu) veya zaten planlı bir programda önceden onaylı zamanlar.
• Yönetici yok: Yönetimi net olmayan veya sözleşmeli roller için yalnızca İK onayı.

Vekâlet, reddetmeler ve yeniden gönderimler

Onaylar, onaylayan kişi yokken bozulur. Vekâleti birinci sınıf kural yapın, manuel bir çözüm değil. Yönetici dışındaysa talebi vekile yönlendirin; vekil yoksa yöneticinin yöneticisine (veya son çare İK'ya) yönlendirin. Hangi kuralın onaylayıcıyı seçtiğini her zaman kaydedin.

Reddetmeler ve düzenlemeler sistemlerin karmakarışık olduğu yerlerdir. Basit tutun: bir reddetme talebi zorunlu bir nedenle kapatır. Çalışan tarihleri veya izin türünü düzenlerse, bunu yeniden gönderim olarak ele alın ve yönlendirmeyi baştan çalıştırın. Bu, artık onaylananla eşleşmeyen "yarı-onaylı" taleplerin önüne geçer.

Pratik bir örnek: Alex 3 gün hastalık izni talep eder. Sistem bunu yöneticiye yönlendirir, ancak politika kontrollü bir izin türü olduğu için İK yalnızca yönetici onayından sonra ikinci adım alır. Yönetici yoksa vekil onaylar ve denetim kaydı nedenini gösterir.

AppMaster'da bunu kurarken yönlendirme mantığını tek görsel süreçte, açık sırayla küçük kurallarla tutun ki sonradan herkes okuyup sürdürebilsin.

Talebi kabul etmeden önceki doğrulama kuralları

İyi doğrulama, özel durumların onaylara sızmasını önlediği için izin talebi sistemi tasarımını okunaklı tutar. Açıklaması kolay ve test etmesi kolay kurallara odaklanın.

Rezervasyon kurallarıyla başlayın. Çakışma kontrolleri onaylı izinler ve bekleyen taleplerle çakışmaları yakalamalıdır. Kısmi günler konusunda açık olun: tarihi artı AM, PM veya saat gibi basit bir birim saklayın ki yarım günler kazara tam güne yuvarlanmasın. Hafta sonları ve resmi tatillerle ne yapacağınıza da karar verin: engelleyin ya da izin verin ama gün sayımında dikkate almayın.

Bakiye kontrolleri göründüğünden daha karmaşıktır. Birçok ekip gönderme anında bakiyeyi doğrular (insanların spam yapmaması için) ve onay anında tekrar kontrol eder (çünkü kazanımlar ve diğer onaylar bakiyeyi değiştirebilir). Her iki kontrolü de yapıyorsanız, kullanıcının hangi noktada başarısız olduğunu gösterin.

Çoğu durumu kapsayan temiz bir doğrulama seti:

• Tarihler geçerli (başlangıç bitişten önce, aynı zaman dilimi, eksik yarım gün seçimi yok)
• Mevcut izinlerle çakışma yok (yarım günler dahil)
• Gün sayımı hafta sonları ve tatilleri hariç tutar (politikaya göre)
• Belirli izin türleri için gerekli ekler mevcut (örneğin hastalık izni için rapor)
• Bakiye yeterli (göndermede ve onayda kontrol edilir)

Ekip kapsama kontrolleri yardımcı olabilir, ama zor bloklardan kaçının. Daha iyi bir varsayılan yöneticinin karar vermesine izin veren uyarıdır. Örnek: "O gün takımınızda iki kişi zaten yok. Yine de gönderilsin mi?"

Hata mesajlarını adil ve düzeltilebilir yapın. Kullanıcıya neyin başarısız olduğunu, nerede olduğunu ve nasıl düzeltebileceğini söyleyin. Örnek: "Talebiniz 12 Mar (ÖS) tarihinde onaylı bir PTO ile çakışıyor. Farklı bir zaman seçin veya mevcut talebi düzenleyin."

AppMaster'da bunu kurarken doğrulamaları talep formuna yakın tutun ve aynı kontrolleri onay adımında yeniden kullanın ki kurallar zaman içinde kaymasın.

Adım adım: oluşturup sürdürebileceğiniz okunabilir iş akışı

İyi bir izin talebi sistemi tasarımı en iyi anlamda sıkıcı hisseder: her talep aynı yolu izler ve her kararın tek bir nedeni vardır. Okunaklı tutmanın en kolay yolu politika verisini (kurallar ne) iş akışı mantığından (Submit'a tıklanınca ne olur) ayırmaktır.

Daha sonra da ek izin türleri geldiğinde bile basit kalan bir sıra:

• Her izin türünü ve kuralını tek bir yerde tutun (isimler, uygunluk, devretme, karartma dönemleri). Burada yazılı olmayan bir kural başka hiçbir yerde olmamalıdır.
• Bakiyeleri tek sayı olarak değil bir zaman çizelgesi şeklinde modelleyin. Açılış bakiyesi, kazanılan (accrual), kullanılan ve düzeltmeler saklayın ki herhangi bir tarihte herhangi bir bakiyeyi açıklayabilesiniz.
• Talep formunu erken kontrollerle oluşturun. Tarihleri, kısmi günleri, çakışmaları, bildirim sürelerini ve "başlangıç tarihine kadar yeterli bakiye"yi onaylardan önce doğrulayın.
• Onayları çalışan, doğrudan yönetici, İK gibi küçük bir rol seti kullanarak yönlendirin. İstisnaları (örneğin "10+ günse İK incelemesi gerekir") veri olarak ekleyin, sert kodlamayın.
• Takvim etkinliklerini yalnızca onaydan sonra oluşturun ve bunları talep değiştiğinde güncellenebilir veya iptal edilebilir aynalar olarak ele alın.

İş akışını okunaklı tutmak için her kararı düz dille kaydedin (örneğin: "Reddedildi: mevcut onaylı izinle çakışıyor"). AppMaster’ın İş Süreci Editörü gibi görsel bir araç kullanıyorsanız adımları bir insanın okuyacağı şekilde etiketleyin.

Lansmandan önce gerçek senaryolarla test edin: geri tarihli talepler, yönetici izinli, yıl ortası politika değişikliği ve onay sonrası bir düzenleme. Sonuç İK'yı şaşırtıyorsa, kural henüz yeterince açık değildir.

Zamanla doğru kalan takvim entegrasyonu

Bir takvim hızlıca şu soruyu cevaplamalı: kim ne zaman yok? Takvim etkinliğini tüm talep kaydı haline getirmeye çalışmayın. Planlamaya yardımcı olanı koyun ve geri kalanını İK sisteminizde tutun.

Etkinlik içeriği için tutarlı olun. İyi bir varsayılan kısa başlık: "İzinli - Maya" gibi ve izin türü gerekiyorsa parantez içinde ("PTO", "Hastalık"). Gizlilik için ayrıntıları minimumda tutun. Birçok ekip etkinliği "Meşgul" olarak gösterip gerekçeleri, bakiyeleri ve notları yalnızca talepte saklamayı tercih eder.

Takvim etkinliklerini kaynak değil ayna olarak ele alın

Her talebin sabit bir dahili ID'si olmalı ve her takvim etkinliği o ID'yi saklamalıdır (örneğin özel bir alan ya da açıklamada). Böylece talepler değiştiğinde doğru etkinliği güvenle oluşturup güncelleyebilir veya silebilirsiniz.

Durum yönetimi sistemlerin kaydığı noktadır. Önceden belirleyin geçici taleplerin gösterilip gösterilmeyeceğini. Gösteriyorsanız farkı belirgin yapın (örneğin başlık ön eki "Beklemede" ve farklı bir uygunluk ayarı). Bir talep onaylandığında aynı etkinliği güncelleyin, yeni bir tane oluşturmayın. Talep onaylandıktan sonra iptal veya reddedilirse etkinliği silin ki takvimler yanlış bilgi göstermesin.

Zaman dilimleri ve "tuhaf" günler

Zaman dilimleri tam ve kısmi gün izinlerinde en çok sorun çıkarır. Başlangıç ve bitişi çalışanın yerel zaman dilimindeki kesin zaman damgaları olarak saklayın ve talepte o zaman dilimini de kaydedin.

Tüm gün etkinlikleri yalnızca gerçekten tam gün izinler için kullanın. Kısmi günler için zamanlı etkinlikler oluşturun (örneğin 13:00-17:00) ki diğer bölgelerdeki iş arkadaşları çakışmayı doğru görsün.

• Tam gün: çalışanın zaman diliminde tüm gün etkinliği
• Kısmi gün: başlangıç ve bitiş zaman damgaları ile zamanlı etkinlik
• Çok günlük: tüm gün etkinlikleri uygundur ama bitiş tarihinin dahil mi hariç mi olduğunu kontrol edin

Takvim senkronizasyonu başarısız olursa bunu gizlemeyin. Görevi sıraya alın, geriye çekmeli yeniden deneme yapın ve "Takvim güncellenmedi" gibi net bir durum ve manuel "yeniden dene" eylemi gösterin. AppMaster gibi araçlarda bu genellikle basit bir arka plan süreci ve İK'nın sorunları düzenlemeden çözebilmesi için başarısız senkron denemelerini listeleyen bir yönetici ekranıdır.

Yaygın hatalar ve nasıl kaçınılır

İzin talebi sistemi tasarımındaki çoğu başarısızlık kuralların zaman içinde sessizce büyümesinden kaynaklanır. Sistem hâlâ "çalışır", ama kimse bakiyelere güvenmez ve her tuhaf vaka bir destek bileti olur.

Hata 1: Kazanım mantığını istisnelerin içine gömmek

Kazanım birçok özel duruma bölündüğünde (yeni işe başlayanlar, devretme, ücretsiz izin, yarı zamanlı) insanlar bakiyelerini tahmin edemez.

Her izin türü için bir açık kazanım modeli tutun, sonra istisnaları adlandırılmış, test edilebilir kurallar olarak ekleyin. Birkaç örnek çalışan ve belirli tarihler için beklenen bakiyeleri yazın ve politikalar değiştiğinde bunları tekrar kontrol edin.

Hata 2: Onay akışlarının sonsuza dek çatallanması

Sonsuz dallanan onaylar test edilmesi imkânsız hale gelir ve yöneticiler talebin neden başkasına gittiğini bilmez.

Daha güvenli desen:

• Bir varsayılan onaylayıcı (genellikle doğrudan yönetici)
• Basit koşullara bağlı isteğe bağlı ikinci onaycı (İK veya bölüm başkanı)
• Onaylayıcı yoksa açık bir yedek (vekil veya sonraki yönetici)
• Her talep için bir nihai durum (onaylandı, reddedildi, iptal edildi)

Hata 3: Politika metni ile matematiği aynı alanda karıştırmak

Politika metni insanlar içindir (ne sayılır, kim uygun). Matematik kuralları sistem içindir (oran, cap, yuvarlama, devretme). Bunları ayrı saklayın ki metni değiştirmek hesaplamayı boğmasın ve hesaplamaları test etmek metni değiştirmeye bağlı olmasın.

Hata 4: Düzenlemeler ve iptaller kaydedilmiyor

Talepleri üzerine yazarsanız, bakiye değişikliğinin arkasındaki "neden"i kaybedersiniz.

Her zaman bir denetim izi tutun: kimi neyi, ne zaman değiştirdi ve önceki değerler neydi. AppMaster'da bu, bir talep geçmişi tablosu ve İş Sürecinde durum geçişleri olarak modellemek kolaydır.

Hata 5: Zaman dilimleri ve tatiller sonradan düşünülüyor

İzin tarihleri tarih aralığıdır, ama onaylar ve takvim girişleri zaman damgalarını kullanır. Bir "politik zaman dilimi"nde normalleştirin ve çalışanın yerel zaman dilimini de saklayın. Ayrıca resmi tatillerin istenen gün sayısını azaltıp azaltmayacağına erken karar verin ve kuralı tutarlı uygulayın.

Yayına almadan önce kısa kontrol listesi

Herkese duyurmadan önce gerçek bir çalışan, bir yönetici ve İK'dan oluşan kısa bir kontrol setiyle geçin. Sistemin sadece çalıştığını değil, açık hissettirdiğini doğrulamak istersiniz.

Bu kontrol listesi zaman-off talep sistemi tasarımınız için go/no-go kapısı olarak kullanın:

• Bakiye görünürlüğü: Çalışan bugünkü bakiyeyi ve onaylı yakındaki izinlerin bakiyeyi nasıl etkileyeceğini görebilmeli (sonradan negatif bakiye keşfetmesin).
• Politika açıklığı: Her kural düz dilde yazılmış (devretme, karartma tarihleri, minimum bildirim, yarım günler) ve mantık bu sözlerle tam olarak eşleşiyor.
• Yardımcı doğrulamalar: Bir talep engellendiğinde mesaj hangi değişikliği yapmanız gerektiğini söylüyor (tarih, izin türü, saatler, eksik ek), sadece "hata" veya "izin verilmiyor" demiyor.
• Yönetici hazır onaylar: Yönetici tek bir ekrandan onaylayabilir; yeterli bağlam (kalan bakiye, çakışan ekip izinleri, devralma notları) var ve uzun bir gidip gelmeye gerek kalmadan değişiklik isteyebilir.
• Takvim ve denetim: Takvim etkinlikleri onaylandığında oluşturuluyor ve değişiklik/iptal durumlarında senkron kalıyor; ayrıca her durum değişikliği kim tarafından ve ne zaman yapıldığını kaydediyor.

Hızlı, pratik bir test: bir talep oluşturun, onaylayın, tarihleri düzenleyin, sonra iptal edin. Herhangi bir adım yanlış bakiye, eski takvim etkinliği veya açıklanmayan bir durum bırakıyorsa, lansmandan önce bunu düzeltin.

AppMaster ile inşa ediyorsanız iş akışını okunaklı tutmak için her adımı kullanıcı eylemi olarak adlandırın (Submit, Validate, Route to Manager, Update Balance, Create/Update Calendar, Log Event) ki politika geliştikçe davranış açık kalsın.

Örnek senaryo: talepten takvim davetine

Yeni bir çalışan, Maya, 10 Mart'ta işe başlar. İzin talebi sistemi tasarımınız aylık kazanımı destekliyor, yani Maya her ayın ilk günü PTO kazanır. 12 Nisan'da gelecek Cuma için 3 saatlik kısmi izin talep eder (tıbbi randevu).

Herkes farklı şeyler görür:

• Çalışan (Maya): mevcut bakiye, bu talebin kaç saati kullanacağı ve negatif olma durumunda net bir uyarı.
• Yönetici: kısa bir özet (tarih, saat, kapsama notu) ve onaylama, reddetme veya vekile yönlendirme seçenekleri.
• İK: hesaplama için kullanılan politika, denetim kaydı ve kurallar değiştiğinde yeniden hesaplama yolu.

Maya talebi gönderir. Yöneticisi tatilde olduğu için sistem vekâlet ayarını kontrol eder ve görevlendirilen yöneticiyi seçer. Görevlendirilen yönetici onaylar.

Onaylandığında iki şey olur: talep kullanıldığı politika versiyonuna kilitlenir ve doğru tarih ve zaman aralığında "Maya - PTO (3s)" için bir takvim etkinliği oluşturulur. Maya hemen "Onaylandı" ve takvim durumu "Eklendi" görür.

Haziran'da İK yıl ortasında politikayı günceller (örneğin 90 günden sonra kazanım artıyor). Bakiyeler yeniden hesaplanmalı, ama geçmişte onaylanmış talepler gizlice değiştirilmemelidir. Sistem Maya'nın mevcut bakiyesini etkin tarihten itibaren yeniden hesaplar ve önce/sonra değerlerinin denetim kaydını tutar.

Bir hafta sonra Maya randevuyu değiştirdiği için talep tarihini düzenler. İzin zaten onaylandığı için bu değişiklik yeni bir "Değişiklik talebi" olur ve tekrar vekil onayına gider. Tekrar onaylandığında mevcut takvim etkinliği güncellenir (aynı etkinlik ID'si), çoğaltılmaz.

Bu, AppMaster gibi bir araçla modellenmesi kolaydır: tek onay yolu, tek vekâlet kontrolü, tek takvim oluştur/güncelle adımı ve İK'nın politika değiştiğinde çalıştırabileceği ayrı bir yeniden hesaplama eylemi tutun.

Sonraki adımlar: ilk sürümü gönderin ve güvenli şekilde yineleyin

İzin talebi sistemi tasarımını tamamlamanın en güvenli yolu, insanların güveneceği küçük bir sürümü yayınlamak, sonra genişletmektir. Bir politika (örneğin PTO) ve bir onay yolu (çalışan -> yönetici) ile başlayın. Bu sıkıcı ve güvenilir hissettikten sonra bir sonraki politika türünü, bölgeyi veya kenar durumunu ekleyin.

Daha fazla kural eklemeden önce gerçeğin kaynağının nerede olduğuna karar verin. İK sisteminiz ana kayıt ise uygulamanız çoğunlukla doğrulamalı, onayları yönlendirip sonuçları geri senkronize etmelidir. Uygulamanız ana kayımsa daha açık denetim kayıtlarına ve İK verileri değiştiğinde (yeni yönetici, departman taşınması, işten ayrılma tarihleri) ne olacağına dair bir plana ihtiyacınız vardır.

Pratik bir ilk sürüm planı:

• Bir izin türü ile net bir bakiye ve tek bir kazanım kuralı uygulayın.
• Tek bir yönetici onay adımı ve bir İK müdahale yolu ekleyin.
• Sadece onaylanan izinler için basit bir takvim senkronu oluşturun.
• Politika ayarlarının teknik olmayan sahipler tarafından okunabilir olduğu bir yönetici ekranı tutun.
• Kim yok ve yaklaşan izinler gibi temel raporlamayı ekleyin.

Her değişiklikten sonra yeniden çalıştırmak için kendi ekibinizden 5-10 gerçek test vakası yazın. Kullanım örneklerini kendi ekibinizden alın, uydurma örneklerden değil. Örneğin: biri Perşembe'den Cuma'yı isteyebilir, biri onay sonrası tarihini değiştirebilir veya yönetici farklı bir zaman dilimindeyken onay verebilir.

No-code ile inşa ediyorsanız, görünürlük özelliklerden en az önemli değildir. AppMaster'da veri modelini (izin türleri, bakiyeler, onaylar) ve onay iş akışını görsel editörlerde tutarak İK ve operasyonların sistemin gerçekten ne yaptığını incelemesini sağlayabilirsiniz. Ayrıca politika geliştikçe karmaşık yamalar yığmak yerine API'ler aracılığıyla takvim senkronu sağlayıp temiz kaynak kod üretme seçenekleriyle ilerleyebilirsiniz.

İlk sürüm stabil olduğunda, bir boyutu aynı anda genişletin: önce daha fazla politika, sonra daha fazla yönlendirme kuralı, ardından daha fazla entegrasyon.