Roller, hatırlatmalar, versiyon geçmişi ve denetime hazır raporlarla çalışan politika onaylarını takip eden bir web uygulamasının nasıl planlanıp inşa edileceğini öğrenin.
Politika kabul takibi, belirli bir kişinin belirli bir iç politikayı, belirli bir versiyon altında, belirli bir zamanda onayladığını kaydetme sürecidir. "Çalışan politika onayları" gibi düşünün; ancak arama yapılabilir, tutarlı ve daha sonra kanıtlamak için uygun bir şekilde saklanır.
Farklı ekipler farklı nedenlerle önemser:
E-posta zincirleri ve "onay için yanıtla" iş akışları basit hissettirir—ta ki temiz bir kanıta ihtiyaç duyana kadar.
Yaygın başarısızlık biçimleri şunlardır:
Web uygulamanız denetime hazır kabul kayıtları üretmelidir: açık, değiştirilmesi zor bir cevap sunar:
Bu, resmi bir imza aracının aşırı olduğu dahili politikalar için pratik bir e-imza alternatifi olabilir.
MVP ile temel bilgileri (politika, versiyon, kullanıcı, zaman damgası) ve basit hatırlatmaları yakalayın. Bu çalıştıktan sonra otomasyon (SSO, erişim kontrolü, yükseltmeler) ve daha güçlü raporlama ile dışa aktarmaları ekleyin.
Ekranları tasarlamadan veya teknoloji yığını seçmeden önce, sistemin kimler için olduğunu ve kuruluşunuzda "kabul"ün hukuki ve operasyonel olarak ne anlama geldiğini netleştirin. Bu, İK, Güvenlik ve Hukuk boşlukları fark ettiğinde yeniden çalışmayı önler.
Çoğu politika kabul izleme aracı dört temel hedef kitleye hizmet eder:
Her grubun başarı kriterini yakalayın. Örneğin, Güvenlik "işe alımdan sonra 7 gün içinde kabul"e önem verebilirken İK "belirli lokasyonlara uygulanması" ile ilgilenebilir.
Gerekli kanıt seviyesini açıkça belirtin:
Kuralı yazın: politika metni erişilebilir haldeyse kabul geçerli mi? Yoksa kullanıcı metni açıp görüntülemek zorunda mı?
İzleyeceğiniz politikalarla başlayın: Davranış Kuralları, Bilgi Güvenliği, Uzaktan Çalışma, NDA ek maddesi ve yerel/düzenleyici onaylar. Politikaların ülke, tüzel kişi, rol veya istihdam türüne (çalışan vs yüklenici) göre farklılık gösterip göstermediğini not edin.
En azından beklentileri doğrulayın:
Zaten işe alım kontrol listeleri veya HRIS iş akışlarınız varsa, entegrasyon için bunları şimdi not edin.
Net bir iş akışı, onayların tutarlı ve denetime uygun olmasını sağlar. En basit yolu tanımlayın; ardından yalnızca düzenleyici, risk veya eğitim ihtiyaçları olduğunda isteğe bağlı adımlar ekleyin.
Politikayı yayınla: Bir yönetici politikayı “Aktif” olarak işaretler ve yürürlülük tarihini ayarlar.
Çalışanları bilgilendir: Sistem e-posta/Slack/Teams mesajı gönderir ve politikaya bir bağlantı sağlar.
Çalışan kabul eder: Çalışan giriş yapar, politikayı okur ve “Kabul ediyorum”a tıklar. Zaman damgası ve politika versiyonu kaydedilir.
Raporla: Uyumluluk veya İK tamamlanma oranlarını görür ve kabul listelerini dışa aktarır.
Bu akış, kim hangi versiyonu ne zaman kabul ettiğini güvenilir şekilde kanıtlayabildiğiniz sürece birçok kuruluş için yeterlidir.
Kısa sınavlar veya anlama kontrolleri
Politika güvenlik, finans veya düzenlemeyle ilişkiliyse kısa bir quiz kullanın. Quiz puanını saklayın ve geçme/kalma durumuna göre kabulün izin verilip verilmeyeceğini belirleyin.
Güncellemelerde yeniden onay
Politika değiştiğinde, bunun küçük bir düzeltme mi yoksa yeniden onay gerektiren maddi bir değişiklik mi olduğunu karar verin. Pratik yaklaşım: yayıncının yeni versiyon için “onay gerektirir” seçeneğini işaretlediğinde yeniden onay tetikleyin.
Yöneticinin takibi
Yönetici görünürlüğü gerekiyorsa, kimin geciktiğini görebilen ve hatırlatma gönderebilen hafif bir görünüm ekleyin.
Bir standart kabul penceresi tanımlayın (örneğin, bildirimden itibaren 14 gün) ve şu gibi yükseltme kuralları belirleyin:
İstisnaları açık tutun: izinli olma, yükleniciler veya rol bazlı muafiyetler.
Daha yüksek riskli politikalar için belirli araçları kullanmadan önce onay gerektirebilirsiniz (ör. gider sistemi, müşteri veri platformu). Bunu yaparsanız iş akışında belgeleyin: “Gecikirse erişimi kısıtla” mı yoksa “erişime izin ver ama yükselt” mı? Risk azaltırken en az kesintiye yol açan seçeneği tercih edin.
Kabul kayıtlarının denetimde dayanıklı olmasını istiyorsanız, her kabul kesin, değiştirilemez bir politika versiyonuna işaret etmelidir. "Davranış Kurallarını kabul ettim" belirsizdir; "Davranış Kuralları v3.2 (yürürlülük 2025-01-01) kabul edildi" doğrulanabilir.
Yayınlandıktan sonra politikalar genellikle düzenlenir (yazım hatası, biçimlendirme, açıklama). Uygulamanız yalnızca "en son metni" saklıyorsa, eski kabul kayıtları çalışanların kayıtlarının altında sessizce değişebilir.
Bunun yerine her yayınlandığında yeni bir versiyon oluşturun ve bu versiyonu salt okunur olarak saklayın:
Bu, çalışanın o an ne gördüğünü daha sonra yeniden üretilebilir kılar, politika güncellense bile.
Politika içeriğini kimlikten ayrı tutun. Sabit bir Policy ID (örn. HR-COC-001) tüm versiyonları birbirine bağlar.
Her yayınlanan versiyon için saklayın:
Bu meta veriler güven oluşturur: çalışanlar neyin değiştiğini ve neden yeniden onay istendiğini görebilir.
Her düzenleme yeniden onay tetiklememelidir. Basit bir kural seti tanımlayın:
Bunu her versiyon için bir "yeniden onay gerekli" bayrağı olarak uygulayın; kabul ekranında kısa bir gerekçe gösterin.
Açık bir veri modeli, politika kabul izlemesini güvenilir, aranabilir ve denetime uygun kılar. Amaç basittir: her zaman "kim neyi, ne zaman kabul etmek zorundaydı ve hangi kanıt var?" sorusuna cevap verebilmelisiniz.
En azından şu nesneleri planlayın (isimler teknoloji yığınına göre değişebilir):
Durumu kullanıcı başına versiyon düzeyinde modelleyin, sadece politika düzeyinde değil:
Hedefli atamalar için department/location bilgisini ya Kullanıcı kaydında ya da join tablolar (Departments, Locations, UserDepartments) aracılığıyla saklayın.
Acceptances içinde şunları yakalayın:
Politika kabul uygulaması, kimlik ve izinlerin güvenilirliği kadar güvenilirdir. Her "Kabul ediyorum" doğru kişiye bağlı olmalı ve kimlerin neyi değiştirebileceği net olmalıdır.
Orta ve büyük ölçekli organizasyonlar için kimlikleri HR/IT kaynak doğrusuyla eşleştiren Tek Oturum Açma (SSO) kullanın:
Her ikisini destekliyorsanız, mevcutsa SSO'yu tercih edin; parola oturum açmayı yükleniciler veya pilot ekipler için yedek olarak tutun.
Rolleri gerçek sorumluluklarla hizalayarak basit tutun:
Yetkilendirme katmanınızda birkaç katı kural tanımlayın:
Bir kullanıcı ayrıldığında, kabul kayıtlarını silmeyin. Bunun yerine:
İyi bir UX, "bir politika portalımız var" durumunu "insanlar zamanında onaylıyor" haline getirir. Ekran sayısını az tutun, sonraki adımı belirgin kılın ve sonrasında ne olduğunu kanıtlamayı kolaylaştırın.
1) Benim Politikalarım (gösterge tablosu)
En çok kullanılacak ana ekrandır. Atanmış politikaları gösterin:
Büyük organizasyonlar için "Gecikmiş" ve "Tamamlandı" filtreleri ile arama ekleyin.
2) Oku & Kabul Et
Okuma deneyimini dikkati dağıtmayacak şekilde tutun. Politika başlığı, versiyon, yürürlülük tarihi ve sonunda belirgin bir onay bölümü gösterin.
PDF gösteriliyorsa mobilde okunabilir olmasına dikkat edin: duyarlı görüntüleyici, yakınlaştırma kontrolleri ve bir "PDF indir" seçeneği. Erişilebilirlik için HTML sürümü sunmayı da düşünün.
3) Kabul Geçmişi
Çalışanlar neyi ve ne zaman kabul ettiklerini görmelidir. Politika adı, versiyon, kabul tarih/saat ve kabul edilen versiyona bağlantı gösterin. Bu, "Bunu tamamladığımı doğrular mısınız?" destek taleplerini azaltır.
1) Politika editörü
Yöneticiler bir politika kaydı oluşturmalı, içerik yüklemeli ve gelecekteki yeniden onay döngüleri için kısa bir "Ne değişti?" özeti yazabilmelidir.
2) Yayınla & hedef kitle ata
Taslak oluşturmayı yayından ayırın. Yayın ekranı yanlış versiyonun yanlış kişilere gitmesini zorlaştırmalı ve kimin atanacağını (bölümler, lokasyonlar, roller veya "tüm çalışanlar") açıkça göstermelidir.
Basit bir "Takım Tamamlama" sayfası genellikle yeterlidir: tamamlanma oranı, gecikmiş liste ve hatırlatma göndermek için tek tık.
UI etiketlerinde açık, sade dil kullanın; klavye ile gezinebilirlik ve ekran okuyucu desteği (doğru başlıklar ve buton etiketleri) sağlayın; kontrastı yüksek tutun. Mobil öncelikli tasarım, çalışanların dizüstü bilgisayar olmadan da onayları tamamlamasını kolaylaştırır.
Bir denetim izi ancak inandırıcıysa yararlıdır. Denetçiler iç soruşturmalar veya dış denetimler için şu hikayeyi ister: hangi politika versiyonu gösterildi, kimlere gösterildi, hangi işlemler oldu ve ne zaman.
Güçlü bir iz dört özellikle öne çıkar:
En azından şunları kayıtlayın:
Ayrıca "politika arşivlendi", "kullanıcı devre dışı bırakıldı" veya "son tarih değişti" gibi olaylar ekleyebilirsiniz; ancak temel olayların tutarlı ve aranabilir olmasına öncelik verin.
Güveni zedeleyen özelliklerden kaçının:
Bir sayfanın açılması, kaydırma veya sayfada geçirilen süre gibi "okundu" sinyalleri eğitim ve UX için yardımcı olabilir, ancak anlaşmayı kanıtlamaz. Kabul, belirli bir politika versiyonuna bağlanan açık bir eylemi (onay kutusu + gönder, isim yazma veya "Kabul ediyorum" düğmesi) kaydeder. Okundu kayıtlarını tamamlayıcı meta veri olarak değerlendirin.
Bildirimler "politikayı yayınladık" ile "çalışanların kabul ettiğini kanıtlayabiliriz" arasındaki farktır. Mesajlaşmayı iş akışının bir parçası olarak ele alın.
Çoğu ekip birden fazla kanal kullanır:
Yöneticiler düşük riskli güncellemeler için kanalları kapatıp açabilsin, böylece şirketi gereksiz yere rahatsız etmezsiniz.
İyi bir ritim öngörülebilir ve sınırlıdır. Örnek: ilk bildirim, 3 gün sonra bir hatırlatma, sonra son tarihe kadar haftalık hatırlatmalar.
Durdurma koşullarını net belirleyin:
Gecikmiş kullanıcılar için yükseltmeler (çalışan → yönetici → uyumluluk posta kutusu) ekleyin; yükseltmeler her zaman son tarihi içermelidir.
Şablonlar otomatik olarak şunları içermelidir:
Kopyayı kısa, spesifik ve kanallar arasında tutarlı tutun.
Çok dilli bir iş gücünüz varsa, şablon çevirilerini saklayın ve kullanıcı tercihine göre gönderin. En azından konu satırları ve çağrıları yerelleştirin; çeviri yoksa varsayılan dile dönün.
Raporlama, politika kabul izleme uygulamanızın pratik bir uyumluluk aracına dönüşmesini sağlar. Amaç insanları grafiklerle boğmak değil—sık sorulan soruları hızla cevaplamaktır: “Bittik mi?”, “Kim gecikti?” ve “Bunu kanıtlayabiliyor muyuz?”
İşe doğrudan eylemle bağlı metriklerle başlayın:
Bu metrikleri tek bir panelde görünür tutun ki İK/Uyumluluk genel durumu hızlıca görebilsin.
Her sayıya tıklanabilme imkanı verin, böylece kullanıcılar altta yatan kişilere ve kayıtlara inebilir. Yaygın filtreler:
Yükleniciler veya birden fazla işçi türünü destekliyorsanız, sadece atamalar ve raporlama için gerekliyse işçi türü filtresi ekleyin.
Dışa aktarmalar genellikle bir iç denetim talebini hızlıca karşılamanın en hızlı yoludur:
Denetim paketini tek tıkla PDF olarak kaydedilebilecek şekilde tasarlayın. Tam olay geçmişi için paketten "tam denetim geçmişini görüntüle"ye bağlantı verin.
Raporlama, ekstra kişisel veriler toplama isteğini tetiklememeli. Kabul kanıtı ve takip için gerekenleri toplayın:
Sade bir raporlama katmanı güvenlik açısından daha kolaydır ve genellikle uyumluluk için yeterlidir.
Politika kabul uygulaması denetimlerde ve İK ihtilaflarında bir "kayıt kaynağı" haline gelirse, onu bir kayıt sistemi gibi ele alın. Güvenlik ve saklama kararlarını açık, belgelenmiş ve açıklaması kolay yapın.
Her yerde HTTPS kullanın (iç ortamlar dahil) ve HSTS etkinleştirin. Oturumları sertleştirin: secure, httpOnly çerezler, adminler için kısa boşta kalma süreleri, CSRF koruması ve güvenli parola sıfırlama akışları. Offboard edildiğinde tüm cihazlardaki oturumu kapatın.
En az ayrıcalık (least-privilege) prensibini uygulayın. Çoğu çalışan sadece politikaları görüntüleyip onaylamalıdır. Yayınlama, versiyon değişikliği ve dışa aktarma gibi yetkiler dar bir role verilmeli ve periyodik olarak gözden geçirilmelidir.
Gereksiz izleme (ayrıntılı cihaz parmak izi, sürekli konum, fazla IP geçmişi) yapmaktan kaçının. Birçok organizasyon için kullanıcı ID, zaman damgası, politika versiyonu ve sınırlı meta veri yeterlidir.
IP adresi veya user agent kaydediyorsanız, neden kaydettiğinizi ve ne kadar süre sakladığınızı şeffaf şekilde bildirin. İç belgeler ve gizlilik politikası uygulamanın gerçek davranışıyla uyumlu olmalıdır.
Kayıt türüne göre saklama tanımlayın: politika belgeleri, kabul olayları, yönetici eylemleri ve dışa aktarmalar. Kabul kayıtlarını yasal/İK gereksinimlerinize uygun süre boyunca saklayın; sonra silin veya anonimleştirin.
Saklama ayarlarını yöneticilerin okuyabileceği bir yerde (ör. dahili /security sayfası) belgeleyin, böylece "bunu ne kadar süre saklıyorsunuz?" sorusuna kodu karıştırmadan cevap verebilirsiniz.
Veritabanı ve yüklenen politika dosyalarını yedekleyin ve geri yüklemeyi periyodik olarak test edin. Yedekleme izi (ne zaman, nerede, başarılı mı) saklayın. Kurtarmadan sonra bütünlüğü kanıtlamak için kayıtların benzersiz ID ve oluşturulma zaman damgalarını koruyun ve verileri kimlerin silme/temizleme yetkisi olduğunu sınırlayın.
İlk sürümünüzün yanıtlaması gereken tek soru: "Bir kişinin hangi politika versiyonunu ve ne zaman kabul ettiğini kanıtlayabiliyor muyuz?" Geri kalan her şey isteğe bağlı olsun.
MVP kapsamı (küçük bir ekip için 4–6 hafta):
Daha hızlı ilerlemek isterseniz sohbet tabanlı bir spesifikasyondan çekirdek uygulamayı üretebilen bir vibe-coding iş akışı yardımcı olabilir; örneğin Koder.ai çekirdek uygulamayı üretebilir, sonra plan ile sürdürüp kaynak kodu dışa aktarabilirsiniz.
İşe alımı kolay ve dağıtımı basit bir yığın seçin:
Aşama 1 (MVP): onaylar, versiyonlama, dışa aktarımlar, temel hatırlatmalar.
Aşama 2: HRIS dizin senkronizasyonu (Workday/BambooHR vb.) otomatik sağlama ve grup eşlemesi; yönetici görünümleri; yükseltmeler.
Aşama 3: daha zengin raporlama, API entegrasyonları ve politika yazma geliştirmeleri.
Entegrasyon fikirleri: kullanıcı özniteliklerini HRIS'ten gece senkronu ile çekin; son tarihler geçtiğinde Jira/ServiceNow üzerinde ticket oluşturun; plan katmanlarını /pricing üzerinde gösterin; /blog/policy-versioning-best-practices gibi ilişkili bir açıklayıcı yazı ekleyin.
Policy acceptance tracking, belirli bir kişinin, belirli bir politika versiyonunu ve belirli bir zaman damgasını içeren açık bir onayı kaydeder. Arama yapılabilir ve denetlenebilir şekilde tasarlanmıştır—e-posta yanıtları veya dağınık PDF'ler gibi versiyonlaması, raporlanması ve kanıtlanması zor yöntemlerin aksine.
Başlamak için ihtiyacınız olan en az kanıt seviyesini belirleyin:
Ayrıca, "polika erişilebilir durumdaydı"nın yeterli olup olmadığını veya kullanıcıların açıp/okuyup onay düğmesini etkinleştirmeden önce kaydırma/görüntüleme yapmasının gerekip gerekmediğini netleştirin ve belgeleyin.
Sürümleme, kanıtlarınızı savunulabilir kılar. Her yayınlanan politika için değiştirilemez bir versiyon (ör. v3.2, yürürlülük 2025-01-01) oluşturun ve kabul kayıtları bu versiyona referans vermelidir. Aksi takdirde, "en son metin" üzerinde yapılan düzenlemeler birinin neye onay verdiğini gizlice değiştirebilir.
Pratik bir MVP veri modeli genellikle şunları içerir:
Bu yapı: kim hedeflendi, hangi versiyonu kabul etmesi gerektiği ve hangi kanıtın mevcut olduğu sorularına cevap verir.
En azından şunları saklayın:
Gerekçeniz varsa isteğe bağlı olarak IP adresi ve user agent ekleyin. "Sadece ihtimal için" fazla kişisel veri toplamaktan kaçının.
Mümkünse SSO (OIDC/SAML) kullanın, böylece kimlik HR/IT kaynak doğrusuyla eşleşir ve offboarding güvenilir olur. Rolleri basit tutun:
Ayrıca kimlerin yayınlayabileceğini veya versiyonları emekliye ayırabileceğini sınırlandırın ve ihracatları kaydedin.
Basit iş akışı:
İhtiyaç oldukça (test, yönetici takibi, yükseltmeler) opsiyonel adımlar ekleyin.
Standart bir pencere tanımlayın (ör. 14 gün) ve sınırlı, öngörülebilir bir ritim otomatikleştirin:
Kabul, muafiyet, deprovision veya kampanya kapanışı gibi koşullarda hemen durdurun. İstisnaları (izin, yükleniciler, kapsam dışı roller) açıkça tanımlayın.
Çalışanlar için vazgeçilmez ekranlar:
Yayınlama/atanma işlemlerini ayıran yönetici ekranları, yanlış versiyonun gönderilmesini engeller.
Temel raporlar şu sorulara hızlı cevap vermelidir: “İş bitti mi?”, “Kim gecikti?” ve “Bu versiyon için kanıt gösterebilir miyiz?” İçerikler:
Ayrıca, denetimler için tek tıklamayla PDF kaydedilebilen bir "denetim paketi" görünümü faydalıdır.
