Personel takip cihazı teknik şartnamesi, katalogdaki özellikleri arka arkaya sıralayan bir belge değil; işletmenin ihtiyacını, teklif sahibinin sunacağı kanıtı ve teslim sırasında uygulanacak kabul testini aynı maddede buluşturan bir karar aracıdır. PDKS, yani Personel Devam Kontrol Sistemi, terminalde oluşan giriş-çıkış olaylarını iş kurallarıyla ilişkilendirip devam ve puantaj çıktısına taşıyan bütündür. Bu nedenle şartname yalnız cihazı değil, veri aktarımını, yazılım sonucunu, kullanıcı yaşam döngüsünü ve destek sorumluluğunu da kapsamalıdır.
Kısa yöntem şudur: çalışan sayısı, on iki aylık büyüme, en yoğun vardiya penceresi, kayıt noktaları, kullanılacak yöntem, bağlantı koşulu ve beklenen puantaj çıktısını önce ölçün. Her gereksinimi “zorunlu değer + sunulacak belge + sahada yapılacak test + başarısızlıkta karar” biçiminde yazın. Belgesi olmayan özellik teklif aşamasında açık madde, kabul testini geçmeyen işlev ise canlıya geçişi durduran bulgu olarak kalmalıdır.
Personel takip cihazı teknik şartnamesi hangi kararı vermeli?
Belgenin ilk sayfasında işin amacını tek cümleyle tanımlayın: yalnız çalışma saatlerini kaydetmek mi, puantaj üretmek mi, yoksa bunlardan ayrı olarak kontrollü alana geçişi yönetmek mi? Mesai kaydı ile kapı erişimini aynı hedef gibi yazmak, gereksiz donanım istemeye veya önemli bir kabul testini atlamaya yol açabilir. Her kullanım için kullanıcı grubu, kayıt noktası, beklenen çıktı ve sorumlu ekip ayrı belirtilmelidir.
Ardından kapsam dışını yazın. Örneğin bordro entegrasyonu, turnike yönetimi, mobil kayıt veya biyometrik yöntem proje ihtiyacı değilse bunları belirsiz bir “gerektiğinde destekler” cümlesiyle şartnameye eklemeyin. Gerçekten gerekiyorsa arayüz adı, veri alanı, sorumlu sistem ve örnek işlemle test edilecek biçimde ayrı kalem yapın. Böylece tekliflerin görünürde aynı, uygulamada farklı kapsamlar sunması önlenir.
İhtiyaç, kanıt ve kabul testini aynı satırda bağlayın
| Şartname alanı | İhtiyaç verisi | Teklifte istenecek kanıt | Kabul testi |
|---|---|---|---|
| Kapasite | Aktif kullanıcı, büyüme ve yöntem dağılımı | Teklif edilen modelin tarihli teknik belgesi | Örnek kullanıcıların kaydı ve sayaç kontrolü |
| Yoğunluk | En yoğun 10 dakikadaki kişi sayısı | Önerilen terminal ve kurulum planı | Gerçekçi vardiya kuyruğu denemesi |
| Aktarım | Ağ, USB ve kesinti koşulu | Model, sürüm ve etkin arayüz listesi | Normal, kesintili ve tekrar aktarım testi |
| Yazılım | Günlük ve aylık karar çıktıları | Sürüm, lisans ve rapor kapsamı | Ham olaydan puantaja örnek senaryo |
| Destek | Kritik arıza ve sorumlu ekip | Müdahale yöntemi, süre ve kapsam | Örnek destek kaydı ve eskalasyon provası |
“Yeterli kapasite”, “hızlı okuma”, “kolay kullanım” veya “tüm sistemlerle uyum” gibi ölçüsüz ifadeler teklifleri karşılaştırmaya elverişli değildir. Değer gerçekten önemliyse birim, sınır ve test yöntemi yazılmalıdır. Değer bilinmiyorsa önce pilotta ölçülecek başlık olarak bırakılmalı; rastgele bir sayı zorunlu koşula dönüştürülmemelidir.
Kapasite maddesini çalışan sayısından çıkarın
Kapasite hesabını yalnız bordrodaki mevcut kişi sayısıyla yapmayın. Aktif çalışanlar, dönemsel ekip, taşeron, test hesabı, ayrılma sürecindeki kullanıcı ve on iki aylık büyüme ayrı satırlarda yer alsın. Yüz, parmak izi, kart veya şifre gibi yöntemler değerlendiriliyorsa kişi sayısı ile şablon ya da kimlik bilgisi sayısının aynı olmayabileceğini hesaba katın. Teklif edilen modelde her kapasite değeri kendi adıyla ve teknik belge tarihiyle verilmelidir.
Hareket hafızası için günlük olay sayısını ölçün. Bir çalışanın yalnız giriş ve çıkış mı, yoksa mola ve ek hareketler de mi üreteceğini belirleyin. Olağan gün ile en yoğun günü ayırın; aktarım sıklığını ve kesinti süresini ekleyin. Kabul sırasında belirli sayıda test kullanıcısı oluşturun, olay üretin ve cihazdaki sayaçla hedef yazılımdaki tekil olayları karşılaştırın. Üst sınırı görmek yerine, ihtiyacın ne kadar payla karşılandığını belgeleyin.
Kayıt yöntemini amaç ve işletim yüküyle tanımlayın
Şartname “kartlı”, “şifreli”, “yüz” veya “parmak izi” kelimesiyle bitmemelidir. Hangi çalışan grubunun hangi yöntemi, hangi noktada ve hangi yedek akışla kullanacağı yazılmalıdır. Kart için tahsis, kayıp, iptal ve iade; kişisel şifre için oluşturma, unutma, sıfırlama ve paylaşım riski; biyometrik yöntem için amaç, alternatif, erişim, saklama ve silme değerlendirmesi gerekir. Çok yöntemli bir terminal, teslim edilen birimde her yöntemin etkin olduğu anlamına gelmez; gerekli yöntem teklif satırında ve test senaryosunda açıkça bulunmalıdır.
TigerBio’nun satın alma öncesi ihtiyaç, yöntem, yazılım ve destek başlıkları şartname hazırlığı için bir kontrol çerçevesi sunar. Bunu genel bir özellik listesi olarak bırakmayın: seçilen yöntemle bir kullanıcı oluşturma, normal giriş-çıkış, başarısız deneme, yedek akış ve işten ayrılma senaryolarının her biri için beklenen sonucu yazın.
Veri aktarımı ve altyapıyı model bazında kanıtlayın
TigerBio’nun şartnameye aktarılabilecek veri iletim başlıkları USB bellek, TCP/IP LAN, Wi-Fi ve statik/geçerli IP yöntemlerini açıkça sayar. Şartnamede bunların tamamını otomatik zorunluluk yapmak yerine, gerçek kurulum için seçilen yolu yazın. Teklif edilen modelin o yolu desteklediği tarihli teknik belgede gösterilmeli; IP planı, sorumlu ekip, yetkili aktarım işlemi ve kesinti sonrası kontrol adımı belirtilmelidir.
Kabul testinde önce bilinen sayıda olay üretin ve normal aktarımı tamamlayın. Sonra kontrollü bağlantı kesintisinde yeni olaylar oluşturun; bağlantı geri geldiğinde kişi, özgün zaman ve olay sayısını karşılaştırın. Aynı veri ikinci kez alındığında yinelenen kayıt oluşup oluşmadığını da ölçün. Bu davranışlar önceden ürün vaadi sayılmamalı; teslim edilen cihaz, yapılandırma ve yazılım sürümünde kanıtlanmalıdır.
Yazılım maddesini menü adına değil çıktıya bağlayın
TigerBio’nun giriş-çıkıştan günlük ve aylık puantaja uzanan yazılım başlıkları geç gelme, erken çıkma, devamsızlık ve izin alanlarını da listeler. Şartnamede bu adları görmekle yetinmeyin. Normal gün, eksik çıkış, geç giriş, izinli gün, geceyi aşan vardiya ve sonradan yapılan düzeltme için ham olay, günlük sonuç ve aylık toplam yan yana gösterilmelidir.
İstenen sürüm ve lisans, kullanıcı rolü, rapor alanı, dışa aktarma biçimi ve varsa başka sisteme aktarılacak veri ayrı kalemlerde tanımlansın. Resmî sayfada ayrıntısı doğrulanmayan bordro bağlantısı, değişiklik günlüğü, dönem kilidi, çoklu şube veya API gibi işlevleri var kabul etmeyin; gerekiyorsa veri örneği ve canlı demo üzerinden zorunlu kabul maddesi yapın.
Destek ve yaşam döngüsü için sorumluluk yazın
Teknik destek maddesi yalnız telefon numarası içermemelidir. Arızayı kimin açacağı, hangi bilgilerin paylaşılacağı, ilk yanıt ile çözüm hedefinin nasıl ayrılacağı, uzaktan ve yerinde müdahalenin kapsamı, yedek cihaz veya geçici kayıt süreci, yazılım güncellemesi ve yeniden kabul testi tanımlanmalıdır. Eğitimde de katılımcı sayısından çok görevler önemlidir: kullanıcı açma-kapatma, olay kontrolü, aktarım, istisna inceleme ve dönem çıktısı ayrı görevler olarak sınanmalıdır.
Çalışan kaydı kişisel veri içerdiği için yetki, erişim kaydı, dışa aktarılan dosya, saklama ve silme beklentileri satın alma dosyasına girmelidir. KVKK’nın veri güvenliği yükümlülükleri açıklaması teknik ve idari tedbirlerin kurumun yapısı, faaliyeti ve riskiyle uyumlu belirlenmesini ister. Belge tek başına hukuki uygunluk sağlamaz; kurumun yetkili hukuk ve veri koruma sorumluları somut veri akışını değerlendirmelidir.
Dokuz kabul maddesini teslim tutanağına taşıyın
- Teslim kapsamı: Model, donanım varyantı, etkin yöntem, yazılım sürümü, lisans ve opsiyonlar teklifle birebir eşleşsin.
- Kullanıcı kapasitesi: Temsilî kullanıcılar kaydedilsin; sayaç, yöntem ve kalan pay tutanağa yazılsın.
- Yoğun vardiya: Belirlenen zaman penceresinde kuyruk, tekrar deneme ve başarısız olay sayısı ölçülsün.
- Normal aktarım: Üretilen olayların kişi, zaman ve türü hedef yazılımla karşılaştırılsın.
- Kesinti ve tekrar: Bağlantı kesintisi sonrası eksik, yinelenen veya zamanı değişen olay bulunmasın.
- Vardiya ve puantaj: Onaylı örneklerde ham olay, günlük sonuç ve aylık toplam aynı kurala bağlansın.
- Yetki ve veri: Kullanıcı açma, dışa aktarma, ayar ve silme görevleri belirlenen rollerle denensin.
- Yaşam döngüsü: Yeni başlayan, yöntem değiştiren ve ayrılan test kullanıcısının tüm adımları tamamlansın.
- Destek provası: Örnek arıza kaydı açılıp yönlendirme, iletişim, kanıt ve kapanış süresi izlensin.
Kabul ölçütleri testten önce dondurulmalı ve her madde için “geçti, koşullu geçti, kaldı” kararı verilmelidir. Kritik maddelerden biri kalırsa toplam özellik sayısı veya düşük fiyat canlı kullanım kararını tek başına değiştirmemelidir. Çalışma sürelerinin uygun araçlarla belgelenmesi çerçevesi için Çalışma ve Sosyal Güvenlik Bakanlığının çalışma süreleri yönetmeliği incelenebilir; iş kuralları uzmanlarca belirlenip kabul senaryolarına çevrilmelidir.
Marka yerine ölçülebilir işlevi, tekliften önce kırmızı çizgiyi yazın
Kamu alımı yapan kurumlar için EKAP’ta yayımlanan Kamu İhale Kurulu kararındaki teknik şartname çerçevesi, kriterlerin verimlilik ve işlevselliğe yönelmesini, rekabeti engellememesini ve belirli marka/model tanımından kaçınılmasını açıklar. Kamu ihalesi olmayan alımlarda da aynı disiplin yararlıdır: marka adı yerine gerekli sonucu, sunulacak kanıtı ve kabul testini yazmak alternatif teklifleri karşılaştırılabilir kılar. Kurumunuza uygulanacak satın alma ve ihale kuralları için yetkili uzman görüşü alın.
Son kontrol için her şartname maddesinin karşısında ihtiyaç sahibi, kanıt, test sorumlusu, kabul eşiği ve başarısızlık işlemi bulunmalıdır. Personel takip cihazı teknik şartnamesi bu beş sorudan birini cevapsız bırakıyorsa, teklif istemeden önce maddeyi daraltın veya ölçülebilir hâle getirin. Dokuz maddelik tablonuzu ve örnek vardiya dosyanızı hazırladıktan sonra şartname ve kabul senaryolarınızla TigerBio teknik görüşmesi planlayın; teslim kararını belge, yapılandırma ve sahada tekrarlanan test sonucuna bağlayın.
