Okul Güvenlik, Ziyaretçi ve Kayıp Eşya Yönetimi
Okul ziyaretçi girişleri, güvenlik kontrol listeleri, kayıp eşya, acil durum görevleri ve denetim kayıtlarını düzenlemek için geliştirilebilecek okul güvenliği yazılımları.

Yazılım Çözümleri
16 çözüm başlığını inceleyebilir, kurumunuza özel kapsam için bilgi isteyebilirsiniz.
Çözüm yaklaşımımız
Okul güvenliği; ziyaretçilerin uygun birimde karşılanması, kapı kontrollerinin sürekliliği, buluntu eşyanın doğru sahibine teslimi ve acil durumda sorumluların doğru bilgiye ulaşması gibi ayrı iş süreçlerinden oluşur. Bu süreçler tek bir büyük uygulama yerine kuruma göre seçilecek modüller halinde ele alınabilir.
Güvenlik ve ziyaretçi yönetiminde hangi süreçler dijitalleşebilir?
- Ziyaretçi kabulü: Ön kayıt, randevu onayı, geçici kart, QR destekli kapı kontrolü ve giriş-çıkış günlüğü.
- Kayıp eşya: Buluntu kaydı, kontrollü fotoğraf gösterimi, sahiplik başvurusu ve teslim tutanağı.
- Kontrol ve denetim: Bölge bazlı güvenlik listeleri, vardiyalar, olay kayıtları ve düzeltici faaliyetler.
- Acil durum hazırlığı: Yetkili duyurular, personel görev dağılımı ve tatbikat takibi.
Fiziksel güvenlik her zaman önceliklidir
Dijital kayıtlar kimlik kontrolünün, çocuk koruma kurallarının veya afet prosedürlerinin yerini almaz. Kurumun kapı sayısı, ziyaretçi hacmi ve personel yetkileri esas alınarak gerekli ekranlar belirlenir. Ziyaretçi verileri saklama süresi ve erişim rolleri ayrıca planlanmalıdır.
Okuldaki kullanım bağlamı
Okul Güvenlik, Ziyaretçi ve Kayıp Eşya Yönetimi, okul ve eğitim kurumlarında ziyaretçi girişleri, kayıp eşya tutanakları ve güvenlik vardiyalarının birbirinden kopuk yürütülmesi sorununu ele alan bir çözüm ailesi olarak değerlendirilebilir. Öncelik, yalnız bir ekran oluşturmak değil; işlemi başlatan kişiyle sonucu denetleyen kişinin aynı güncel kayda bakabilmesidir. Özellikle yoğun dönemlerde sözlü anlaşmalar kayda dönüşmediğinde hem görevli hem başvuran aynı soruyu tekrar tekrar sormak zorunda kalır. Kurumun büyüklüğü, öğrenci yaşı ve mevcut çalışma biçimi netleştirilmeden sabit bir özellik listesi kesin ihtiyaç gibi sunulmamalıdır.
İşlem için gereken kayıtlar
Kayıt yapısının odağında ziyaret sebebi, giriş saati, refakatçi, çıkış onayı ve eşya teslim kaydı bulunur. Bu bilgilerin her biri için kimlerin veri gireceği, hangi aşamada düzeltme yapılabileceği ve sürecin hangi kararla tamamlanacağı ayrı tanımlanmalıdır. Formun mobilde anlaşılabilir olması özellikle okul personelinin sahada ve velilerin hareket hâlindeyken yaptığı işlemlerde önemlidir. İlk kullanımda zorunlu görünen bir alanın gerçekten gerekli olup olmadığı, ilgili personelle örnek bir işlem yapılarak anlaşılabilir.
Uygun süreç tasarımı
Örnek bir işlem sırası ziyaretçi davetinin doğrulanması, giriş izni verilmesi, çıkışın kapatılması şeklinde kurulabilir. Bu sıralama okulun kendi uygulamalarına göre değiştirilebilir; tüm kurumlara aynı onay basamaklarını zorlamak doğru değildir. Zaman çizelgesi yalnız yapılacak işi değil, yapılan işlemin tarihini ve kararın sorumlusunu da gösterebilir. Böylece yarım kalmış talep, işleme alınmış kayıt ve kapanmış sonuç aynı listede belirsiz biçimde yan yana durmaz.
İptal, gecikme ve değişiklikler
Gerçek kullanımda kimliği doğrulanmayan ziyaretçi, sahipsiz eşya ve mesai sonrası teslim talebi gibi durumlar planı değiştirebilir. Bu senaryolar yalnız hata mesajı üretilecek teknik ayrıntılar değildir; kimin bilgilendirileceği ve önceki kaydın nasıl korunacağı da belirlenmelidir. İptal ve yeniden planlama senaryoları ilk tasarımda düşünülmezse günlük kullanımda sürekli yönetici müdahalesi gerekir. Özellikle yoğun dönemlerde alternatif işlem yolunun önceden yazılması, gereksiz telefon trafiğini azaltır.
Yetkilendirme mantığı
Kullanıcı rolleri bakımından güvenlik ekibi, danışma personeli ve okul yönetimi arasında açık sorumluluk paylaşımı gerekir. Her rolün görme, oluşturma, onaylama ve düzeltme hakları birbirinden ayrılabilir. Yetkilerin dönem sonunda gözden geçirilmesi, artık görev yapmayan kişilerin eski kayıtları gereksiz yere görmesini önler. Sistem kuruma özel geliştirilecekse erişim sınırları ve saklama süreleri yalnız yazılım tasarımında değil, kurumun yazılı işleyişinde de karşılık bulmalıdır.
İzleme ve değerlendirme
Yönetim tarafında açık ziyaretçi kayıtları, bulunamayan eşya sayısı ve giriş saatlerinin dağılımı gibi göstergeler izlenebilir. Ancak her şeyin sayılması zorunlu değildir; karar vermeye yardım eden ve veri kaynağı açık olan ölçümler seçilmelidir. Ölçümlerin kaynağı ve güncellik tarihi görünür tutulursa sonuçlar toplantıda tekrar elle doğrulanmak zorunda kalmaz. İyileştirme toplantısında bu verilerle birlikte personelin karşılaştığı somut güçlükler de ele alınmalıdır.
Pilot kullanım örneği
Örneğin kayıp montun velisi tarafından tarif edilip teslim tutanağıyla kapatılması durumunda çözümün kullanıcılara nasıl davranacağı başlangıçta konuşulabilir. Deneme sırasında bekleyen, reddedilen ve sonradan düzeltilen durumların rapora nasıl yansıdığı ayrıca kontrol edilmelidir. Önce mevcut işleyişin küçük bir örnek üzerinden doğrulanması, ardından gerçek ekran ve uyarıların tasarlanması daha güvenilir sonuç verir. Kullanım başlamadan önce kurum onayı, hata durumları ve bildirim metinleri birlikte test edilmelidir.