Çok vardiyalı PDKS seçerken ilk adım cihaz modeli belirlemek değil, işletmenin gerçek çalışma akışını yazılı hâle getirmektir. Vardiya başlangıç ve bitişleri, gece yarısını aşan çalışmalar, mola kuralları, eksik kayıtlar, izinler ve puantaj onayları tanımlanmadan alınan bir sistem doğru kayıt üretse bile yanlış iş sonucuna yol açabilir. Bu nedenle ihtiyaç analizi; kimlik doğrulama yönteminden rapora, istisna yönetiminden veri sorumluluğuna kadar bütün süreci kapsamalıdır.
Cihazdan önce cevaplanması gereken temel soru
Bir çalışanın kapıdan geçtiğini kaydetmek ile o kaydı ücret, izin veya fazla mesai hesabına dönüştürmek aynı işlem değildir. İlk işlem bir olay kaydıdır; ikinci işlem ise işletme kurallarının uygulanmasını gerektirir. Çok vardiyalı yapılarda PDKS projesinin asıl zorluğu genellikle bu iki katman arasındaki eşleştirmedir.
Örneğin gece vardiyası 22.00’de başlayıp ertesi gün 06.00’da bittiğinde çıkış kaydı hangi iş gününe yazılacaktır? Çalışan planlanan vardiyadan önce gelirse bu süre otomatik olarak fazla mesai mi sayılacaktır, yoksa yönetici onayı mı beklenecektir? Bir çalışan kartını unuttuğunda kaydı kim, hangi gerekçeyle ve hangi iz iziyle düzeltecektir? Yazılım ve cihaz görüşmesine başlamadan önce bu soruların yanıtları bir süreç belgesinde bulunmalıdır.
Vardiya modelini istisnalarıyla birlikte tanımlayın
Sadece vardiya saatlerini listelemek yeterli değildir. Her vardiya için tolerans aralıkları, mola uygulaması, hafta tatili, vardiya değişimi ve gece yarısı geçişi ayrı ayrı tanımlanmalıdır. Sabit vardiya, dönüşümlü vardiya, esnek başlangıç veya çağrı üzerine çalışma gibi modeller aynı hesaplama mantığıyla yönetilemez.
İhtiyaç belgesinde en az şu senaryolar yer almalıdır:
- Planlanan saatte normal giriş ve çıkış
- Geç giriş, erken çıkış ve eksik hareket kaydı
- Gece yarısını geçen vardiya
- Aynı gün içinde birden fazla giriş ve çıkış
- Onaylı izin, saha görevi, eğitim veya sağlık raporu
- Vardiya değişimi ve geçici bölüm görevlendirmesi
- Resmî tatil veya hafta tatilinde çalışma
Bu liste, yazılım demosunu genel özellik gösteriminden çıkarıp gerçek bir kabul testine dönüştürür. Tedarikçiden yalnızca ekranları göstermesini istemek yerine her senaryonun sisteme nasıl girildiğini, kim tarafından onaylandığını ve puantaj raporuna nasıl yansıdığını göstermek daha sağlıklı bir değerlendirme sağlar.
Kimlik doğrulama yöntemini hukuki değerlendirmeden ayırmayın
Kart, PIN, parmak izi veya yüz tanıma arasında seçim yalnızca hız ve kullanım kolaylığı üzerinden yapılmamalıdır. Parmak izi ve yüz verisi, belirli bir kişiyi benzersiz biçimde tanımlamak veya doğrulamak için işlendiğinde biyometrik veri niteliği taşıyabilir. Kişisel Verileri Koruma Kurumu, biyometrik verileri özel nitelikli kişisel veriler arasında değerlendirir.
Ürün araştırması aşamasında TigerBio parmak izi okuma cihazları kategorisi ile TigerBio yüz tanıma sistemleri kategorisi, yalnızca TigerBio’nun resmî seçeneklerini görmek ve incelemek için kullanılabilir. Bir ürünün bu kategorilerde yer alması; doğruluk, kapasite, sahteciliğe karşı koruma, hukuki uyumluluk veya belirli bir projeye uygunluk bakımından tek başına kanıt oluşturmaz. Her modelin özellikleri ilgili ürün sayfası, teknik belge, demo veya güncel resmî teklif üzerinden ayrıca doğrulanmalıdır.
KVKK’nın 29 Nisan 2026 tarihli mesai takibi ilke kararı duyurusu, yalnızca mesai takibi amacıyla biyometrik veri işlenmesini ölçülülük ve hukuki dayanak yönünden değerlendirir; bu amaç için kart, PIN ve benzeri alternatiflerin dikkate alınması gerektiğini belirtir. Bu nedenle çok vardiyalı PDKS projesinde biyometrik yöntem otomatik başlangıç seçeneği olarak kabul edilmemelidir.
İşletme; veri işleme amacını, uygulanabilir hukuki sebebi, daha az müdahaleci alternatifleri, erişim yetkilerini, saklama süresini ve silme sürecini kendi somut koşullarına göre değerlendirmelidir. KVKK’nın özel nitelikli kişisel veriler rehberi bu değerlendirme için resmî bir başlangıç kaynağıdır. Nihai yöntem belirlenmeden önce kurumun hukuk veya veri koruma sorumlusundan görüş alınması gerekir; hiçbir cihaz tek başına KVKK uyumu sağlamaz.
İhtiyacı özellik listesi yerine kabul kriterine çevirin
“Vardiya modülü olsun” gibi geniş bir ifade, satın alma veya devreye alma sırasında ölçülemez. Bunun yerine her ihtiyaç gözlenebilir bir sonuç olarak yazılmalıdır. Böylece farklı seçenekler aynı ölçütlerle değerlendirilebilir.
| İhtiyaç sorusu | Aranacak işlev | Kabul testindeki kanıt |
|---|---|---|
| Gece vardiyası doğru güne bağlanıyor mu? | Gece yarısını aşan vardiya kuralı | Örnek giriş ve çıkışın beklenen iş gününde görünmesi |
| Eksik kayıt nasıl düzeltiliyor? | Yetkili düzeltme ve onay akışı | Değişikliği yapan kişi, zaman ve gerekçenin izlenebilmesi |
| Fazla mesai ne zaman oluşuyor? | Kural ve yönetici onayı | Onaysız erken girişin otomatik hak edişe dönüşmemesi |
| İzinli personel raporda nasıl görünür? | İzin ile devam kaydının eşleştirilmesi | Onaylı iznin devamsızlık olarak işaretlenmemesi |
| Dönem kapandıktan sonra değişiklik yapılabilir mi? | Dönem kilidi ve yetki kontrolü | Kapalı dönemde değişikliğin engellenmesi veya ayrıca onaylanması |
Kabul kriterleri sadece insan kaynaklarının işi değildir. Operasyon ekibi vardiya gerçeklerini, bilgi teknolojileri ekibi erişim ve süreklilik koşullarını, bordro sorumlusu çıktı beklentisini, hukuk veya veri koruma sorumlusu ise veri işleme çerçevesini tanımlar. Tek bir bölümün hazırladığı şartname, diğer bölümlerde sonradan ortaya çıkan ihtiyaçları kaçırabilir.
Puantaj sürecindeki sorumlulukları açıkça dağıtın
Her kayıt için bir sorumlu ve onay mercii belirlenmelidir. Çalışan kendi eksik kaydını bildirebilir; ancak kaydı doğrudan değiştirme yetkisi farklı bir rolde olabilir. Bölüm yöneticisi vardiya değişimini onaylarken insan kaynakları dönem kapanışını yapabilir. Bilgi teknolojileri ekibi sistemi çalışır tutsa da çalışma kuralının sahibi olmamalıdır.
Bu ayrım, hem hataların daha hızlı bulunmasını hem de değişikliklerin açıklanabilir olmasını sağlar. Özellikle puantaj kapandıktan sonra yapılan düzeltmeler için gerekçe, talep eden kişi, onaylayan kişi ve işlem zamanı görülebilmelidir. Bir raporun doğru görünmesi kadar, o sonuca hangi adımlarla ulaşıldığının anlaşılması da önemlidir.
Raporu değil, raporun kararını tarif edin
“Aylık rapor istiyoruz” ifadesi farklı bölümler için farklı anlamlara gelebilir. İnsan kaynakları geç kalma ve devamsızlık özetini, operasyon vardiya doluluğunu, bordro ekibi ise onaylanmış süreleri görmek isteyebilir. Aynı ham kayıtlardan üretilen bu çıktılar farklı kurallara dayanır. İhtiyaç analizinde her raporun kullanıcısı, dönemi, filtreleri, onay durumu ve hangi kararı desteklediği yazılmalıdır.
Bir rapor örneğini tablo biçiminde çizmek çoğu zaman uzun bir özellik listesinden daha açıklayıcıdır. Sütunlarda planlanan vardiya, ilk giriş, son çıkış, izin türü, eksik kayıt uyarısı, onaylanan fazla süre ve yönetici notu gibi gerçekten kullanılacak alanlar yer alabilir. Her alan için verinin nereden geldiği ve bir düzeltme olduğunda hangi kaydın esas alınacağı belirlenmelidir.
Ayrıca dönem kapanışını tanımlayın. Puantaj hangi tarihte kesinleşir, kapanıştan sonra gelen izin belgesi nasıl işlenir ve yeniden hesaplanan çıktı kime bildirilir? Bu sorular cevaplanmadığında sistem teknik olarak doğru çalışsa bile iki bölüm farklı sürümler üzerinden işlem yapabilir.
Veri akışını ve saklama sorumluluğunu görünür kılın
PDKS değerlendirmesinde verinin yalnızca cihaza nasıl geldiğini değil, daha sonra nerede işlendiğini de haritalayın. Kaydın oluştuğu nokta, yönetim ekranı, rapor çıktısı, varsa başka sisteme aktarım ve yedekleme adımı ayrı ayrı gösterilmelidir. Her adım için erişebilen roller, işlem amacı ve sorumlu ekip belirlenmelidir.
Saklama süresi “mümkün olduğu kadar uzun” şeklinde tanımlanmamalıdır. İşletme, uygulanabilir mevzuatı ve operasyonel ihtiyacı birlikte değerlendirerek her veri türü için süre, silme veya anonimleştirme yöntemi ve yetkili rol belirlemelidir. Çalışanın işten ayrılması, cihazın değiştirilmesi veya tedarikçi ilişkisinin sona ermesi hâllerinde uygulanacak süreç de baştan yazılmalıdır.
Saklama ve silme süreci tasarlanırken kişisel verilerin silinmesi, yok edilmesi veya anonim hâle getirilmesine ilişkin yönetmelik incelenmeli ve uygulanacak yöntem kurumun somut koşulları için ayrıca değerlendirilmelidir.
Bu harita teknik görüşmeyi somutlaştırır. Tedarikçiye genel olarak “veriler güvenli mi?” demek yerine erişim kayıtlarının nasıl tutulduğunu, yetkilerin nasıl sınırlandığını, dışa aktarılan dosyaların nasıl korunduğunu ve silme talebinin hangi adımlarla uygulandığını sorabilirsiniz. Yanıtların sözlü beyanla sınırlı kalmaması; güncel teknik doküman, sözleşme veya demo çıktısıyla desteklenmesi gerekir.
TigerBio yazılım sayfasını değerlendirirken neyi doğrulamalısınız?
TigerBio’nun personel devam kontrol yazılımı kategori sayfasında giriş-çıkış takibi, geç gelme, erken çıkma, devamsızlık, izin ile günlük ve aylık puantaj gibi modüllerden söz edilir. Bu başlıklar çok vardiyalı bir işletmenin ihtiyaç listesiyle ilişkilidir; ancak sayfadaki genel açıklama, her modülün her sürümde veya her kurulumda aynı kapsamda bulunduğunu tek başına kanıtlamaz.
Değerlendirme sırasında gereken modülün adıyla yetinmeyin. Vardiya senaryonuzu demo ortamında çalıştırın, çıktı örneğini görün, rol ve onay akışını test edin. Entegrasyon, veri aktarımı, kullanıcı kapasitesi, bağlantı yöntemi, barındırma modeli, destek koşulları ve lisans kapsamı gibi konuları güncel teklif veya teknik doküman üzerinde ayrıca doğrulayın. Bu maddeler, yalnızca genel bir kategori açıklamasından varsayılmamalıdır.
Küçük bir pilotla gerçek iş gününü sınayın
Canlı kullanıma geçmeden önce farklı vardiyaları ve istisnaları temsil eden sınırlı bir pilot grup seçin. Pilotun amacı yalnızca kayıt alınabildiğini görmek değildir. Bir tam puantaj döngüsü boyunca normal giriş, geç kalma, gece vardiyası, izin, eksik kayıt ve yönetici düzeltmesi gibi durumların rapora doğru yansıyıp yansımadığını izleyin.
Pilot sonunda bulunan her farkı “yazılım hatası” olarak sınıflandırmayın. Sorun; tanımsız iş kuralı, yanlış vardiya ataması, eksik kullanıcı eğitimi veya uygun olmayan yetki dağılımından da kaynaklanabilir. Her fark için kök neden, düzeltme sahibi ve yeniden test tarihi belirlemek, canlı geçişte aynı sorunun tekrarlanmasını önler.
Çok vardiyalı PDKS için iyi seçim, en uzun özellik listesini sunan seçenek değil; işletmenin tanımlanmış senaryolarını kanıtla karşılayan, sorumlulukları görünür kılan ve veri işleme koşulları hukuken değerlendirilen çözümdür. İlk görüşmeye vardiya tablonuz, istisna listeniz ve kabul kriterlerinizle gitmeniz, ürün adından bağımsız olarak daha doğru sorular sormanızı sağlar.
İhtiyaç listenizi bu çerçevede hazırladıktan sonra, açıklanan modülleri kendi vardiya senaryolarınızla karşılaştırmak için TigerBio personel devam kontrol yazılımı seçeneklerini inceleyin; gerekli kapsamı, lisans koşullarını ve teknik ayrıntıları güncel demo veya teklif üzerinden doğrulayın.
