Personel takip cihazı bakımı, cihazın açılması veya arıza ışığının sönmesiyle tamamlanmış sayılmamalıdır. Bakım penceresini kapatmak için müdahale öncesi oluşturulan kontrollü giriş ve çıkışların cihaz saati, gerçek aktarım yolu, yazılımdaki ham kayıt ve günlük-aylık puantaj boyunca aynı kişi, aynı zaman ve aynı adetle korunması gerekir. Bu dört katmandan biri doğrulanamıyorsa cihazı vardiya trafiğine geri açmayın; önce farkın başladığı katmanı bulun ve aynı testi tekrarlayın.
PDKS, yani Personel Devam Kontrol Sistemi, terminalde oluşan giriş-çıkış olaylarını çalışma planı ve puantaj sonucuna taşıyan donanım-yazılım zinciridir. Bu nedenle bakım kararı yalnız IT veya teknik servisin “cihaz çalışıyor” onayıyla kapanmaz. İnsan kaynakları test kişisini ve vardiyayı, IT saat ile aktarımı, puantaj sorumlusu da ham olayın günlük ve aylık sonuca etkisini imzalamalıdır. En güvenli başlangıç, gerçek çalışan verisini topluca değiştirmeden önce bir test kişisi ve bilinen sayıda olayla taban oluşturmaktır.
Personel takip cihazı bakımı hangi kanıtlarla kapanmalı?
Bakım öncesi ve sonrası aynı ölçüleri kullanın: cihazın gösterdiği saat, test olayının terminaldeki sıra veya adedi, yazılıma ulaşma zamanı, ham listedeki kişi-zaman-cihaz eşleşmesi ve puantaj sonucu. “Bağlantı geldi”, “ekran açıldı” veya “bir çalışan okutma yaptı” tek başına kabul kanıtı değildir; çünkü bu gözlemler olayın doğru kişiye ve doğru hesap dönemine taşındığını göstermez.
Bakım penceresine başlamadan önce kapsamı yazılı dondurun. Hangi cihaz veya cihazlar müdahaleye girecek, hangi yazılım sürümü ve veri yolu kullanılacak, ilk vardiya ne zaman başlayacak, bakım sırasında kayıt nasıl alınacak ve başarısızlıkta kim durdurma kararı verecek? Bu sorulara isim ve saat içeren yanıt verilmezse teknik işlem bitse bile operasyonel sahiplik belirsiz kalır.
| Kontrol | Bakım öncesi kanıt | Bakım sonrası aynı ölçüm | Durdurma koşulu |
|---|---|---|---|
| 1. Kapsam ve kimlik | Cihaz etiketi, konum, test kişisi ve yetkili ekip kaydedilir. | Aynı cihaz ve test kişisiyle çalışma doğrulanır. | Yanlış cihaz, yanlış kişi veya belirsiz sorumluluk. |
| 2. Saat tabanı | Terminal, yazılım ve güvenilen referans saat aynı anda fotoğraflanır veya forma yazılır. | Aynı üç saat yeniden karşılaştırılır. | Önceden belirlenen fark eşiğinin aşılması. |
| 3. Kontrollü olay | Bir giriş ve bir çıkış; kişi, zaman ve terminalle kaydedilir. | Yeni giriş ve çıkış aynı sıra ile üretilir. | Eksik, çift, ters sıralı veya başka kişiye bağlı olay. |
| 4. Aktarım yolu | Projede gerçekten kullanılan USB, TCP/IP, Wi-Fi veya IP yolu ve sorumlusu yazılır. | Test olayları aynı üretim yolundan taşınır. | Geçici bir yolun üretim yolu sanılması veya olay adedinin değişmesi. |
| 5. Ham kayıt | Kişi kodu, terminal, olay zamanı ve adet saklanır. | Dört alan satır satır eşleştirilir. | Alanlardan birinin kaybolması, değişmesi veya çoğalması. |
| 6. Günlük ve aylık sonuç | Test gününün günlük sonucu ve ilgili aylık satırı kaydedilir. | Yeni olayın yalnız hedeflenen satıra etkisi incelenir. | Geçmiş satırın sessiz değişmesi veya hedef dışı çalışan etkisi. |
| 7. Yeniden açma | Kabul eşiği, geri dönüş adımı ve imza sahipleri bellidir. | IT, İK ve puantaj kanıt paketini birlikte kapatır. | Eksik kanıt, açıklanamayan fark veya geri dönüşün prova edilmemesi. |
Aynı formu her bakım penceresinde kullanmak, sonuçları önceki dönemle karşılaştırmayı ve tekrar eden bir arızanın ilk kez hangi katmanda göründüğünü ayırmayı kolaylaştırır.
Bakım öncesi tabanı gerçek üretim yolunda dondurun
Önce cihaz envanterini bakım listesine değil, olay zincirine bağlayın. Cihaz etiketi, fiziksel nokta, güç kaynağı, ağ noktası, kullanılan kayıt yöntemi, bağlı yazılım ve sorumlu ekip aynı satırda olmalıdır. Daha önce hazırlanan enerji, ağ ve servis erişimini sekiz ölçümle sınayan kurulum planı, bakım sırasında yanlış terminale veya yanlış bağlantı noktasına müdahale edilmesini önleyecek saha tabanını sağlar.
Ardından düşük riskli bir zamanda iki kontrollü olay üretin. Test kişinin bir giriş ve bir çıkış yapması yeterlidir; amaç yoğunluk testi değil, karşılaştırılabilir taban oluşturmaktır. Formda terminalin gösterdiği zamanı, olayın cihazdaki adet veya sırasını, yazılıma erişme zamanını ve ham kayıttaki kişi kodunu saklayın. Ham kayıt ekranının biçimi sürüme göre değişebileceği için alan adını tahmin etmeyin; teslim edilen yazılımda hangi alanlar görünüyorsa onları tarihli kanıt olarak kullanın.
Saat farkını olay kaybından önce ayırın
Bakım sonrası “kayıt yanlış” şikâyeti çoğu zaman tek bir nedenden doğmaz. Terminal saati kaymış olabilir, olay doğru oluşup geç aktarılmış olabilir veya yazılım doğru olayı farklı çalışma gününe bağlamış olabilir. Bu üç ihtimali aynı anda düzeltmeye çalışmak kanıtı yok eder. Önce terminal, yazılım ve kurumun kabul ettiği referans saat arasındaki farkı ölçün; sonra tek bir yeni olay üretip zinciri yeniden izleyin.
NIST, bilgisayar ve diğer cihaz saatlerinde Network Time Protocol (NTP) kullanımını en yaygın eşitleme yolu olarak açıklar; ancak bu bilgi belirli bir TigerBio modelinde NTP bulunduğunu kanıtlamaz. NIST’in bilgisayar saati eşitleme açıklamasını kurumunuzun zaman referansını seçmek için kullanın, cihazın gerçek ayar ve eşitleme davranışını ise model menüsü, tarihli teknik belge ve sahadaki tekrar ölçümüyle doğrulayın.
Veri aktarımını bakımın ayrı bir kabul adımı yapın
TigerBio’nun USB, TCP/IP, Wi-Fi ve IP aktarım yollarını ayıran veri rehberi, yöntemin modele göre seçildiğini belirtir. Bakım formunda bütün seçenekleri işaretlemek yerine kurulu cihazın gerçekten kullandığı yolu kaydedin. Örneğin üretimde TCP/IP kullanılıyorsa, USB ile tek seferlik başarılı aktarım üretim bağlantısının onarıldığını göstermez. Aynı şekilde Wi-Fi adı görmek, sinyal kararlılığını veya kesinti sonrası olay sırasını kanıtlamaz.
Kontrol için olay adedini iki tarafta sayın: bakım öncesi ve sonrası terminalde üretilen test olayları ile yazılıma ulaşan ham satırlar eşit olmalıdır. Sonra kişi kodu, zaman, cihaz ve sırayı satır bazında karşılaştırın. Bir fark varsa hemen puantajı düzeltmeyin; önce olayın terminalde oluşup oluşmadığını, seçilen yoldan taşınıp taşınmadığını ve yazılımda hangi anda göründüğünü ayırın. Böylece teknik servis ile puantaj ekibi aynı fark üzerinde konuşur.
Ham kaydı koruyup puantaj sonucunu ayrı doğrulayın
Bakımın hedefi geçmiş hareketleri yeniden yazmak değil, yeni olayların güvenilir biçimde akmasını kanıtlamaktır. NIST’in log yönetimi rehberi, olay kayıtlarının üretilmesi, iletilmesi, saklanması ve erişilmesi için planlı süreçler kurulmasını önerir. Bu çerçeveyi PDKS’ye uyarlarken ham olayı, hesaplanan günlük sonucu ve aylık puantaj satırını üç ayrı kanıt olarak tutun; biri diğerinin yerine geçmesin.
TigerBio’nun giriş-çıkıştan günlük ve aylık puantaja uzanan yazılım başlıkları, bakım sonrası kontrolün hangi sonuç katmanlarına ulaşması gerektiğini gösterir. Teslim edilen sürümde bir test girişinin ve çıkışının doğru kişide, doğru çalışma gününde ve doğru aylık satırda göründüğünü kontrol edin. Formül, tolerans, onay akışı veya otomatik yeniden hesaplama sayfada açıklanmadığı için bunları mevcut özellik kabul etmeyin; kendi kural setiniz ve test vardiyanızla ölçün.
Bakım penceresini yalnız ölçülebilir PASS ile kapatın
Yeniden açma kararı üç olası sonuçtan biri olmalıdır. PASS: saat farkı eşik içinde, test olayları eksiksiz, ham kayıt eşleşmiş ve yalnız hedeflenen puantaj satırı etkilenmiştir. Düzeltme sonrası tekrar test: neden bulunmuş, düzeltme sınırlandırılmış ama aynı iki olay henüz yeniden çalıştırılmamıştır. STOP: veri kaybı, çift kayıt, açıklanamayan saat farkı, hedef dışı puantaj değişikliği veya geri dönüş belirsizliği vardır. “Kısmen çalışıyor” vardiya başlangıcı için kabul sonucu değildir.
Bakım sırasında erişilen kayıtlar çalışanlara ait kişisel veri içerebilir. KVKK’nın veri güvenliği yükümlülükleri açıklaması, riskle uyumlu teknik ve idari tedbirlerin kurumun yapısı ve işlenen verinin niteliğine göre belirlenmesi gerektiğini söyler. Bu nedenle servis hesabı, uzaktan erişim, kanıt ekranı, saklama süresi ve kimin hangi kaydı görebileceği kurumun yetkili veri ve hukuk ekipleri tarafından belirlenmelidir; bu makale hukuki görüş veya tek tip saklama süresi önermez.
TigerBio bakım görüşmesine yedi satırlık kanıt paketiyle gidin
Teknik görüşmeye yalnız “cihaz bazen kayıt göndermiyor” notuyla gitmeyin. Cihaz etiketi, bakım saati, önceki ve sonraki saat farkı, iki kontrollü olay, gerçek aktarım yolu, ham kayıt karşılaştırması, günlük-aylık puantaj sonucu ve STOP eşiğini tek sayfada toplayın. Bu paket, sorunun güç, saat, terminal, ağ, aktarım veya hesaplama katmanlarından hangisinde başladığını gösterir ve tekrar edilebilir bir servis testi oluşturur.
Personel takip cihazı bakımı için hazırladığınız yedi kontrolü, kurulu model ve yazılım sürümünün gerçek davranışıyla eşleştirmek üzere bakım kanıt paketinizle TigerBio teknik görüşmesi planlayın. Görüşme sonunda her satır için sorumlu kişi, beklenen kanıt, kabul eşiği ve başarısızlıkta uygulanacak adım yazılı değilse cihazı yoğun vardiyaya açmak yerine kontrollü testi tamamlayın.
