Kuralı yayına almadan önce sorun. Sahada değil, masabaşında.

Bir kuralın sonucunu kim, ilk kim görmeli

Bir yetki kuralı yazıldığı an etkilidir. Kaydet düğmesine basıldığında sahadaki karar motoru o kuralı hemen uygulamaya başlar. Bu hız açısından avantajlıdır, ama bir riski de beraberinde getirir: yanlış yazılan bir kural, ilk sonucunu gerçek bir kişinin kapıda beklemesiyle verir. Kural simülatörü bu sırayı tersine çevirir. Aynı karar motorunun bir kopyasını, hiçbir kayda yazmadan çalıştırır.

Erişim simülasyonu nasıl çalışır

Simülatöre üç girdi verilir: kişi, bölge, tarih-saat. Sistem bu üç bilgiyle, gerçek bir kart okutulduğunda karar motorunun izleyeceği aynı sırayı uygular. Önce kişinin grup üyeliği kontrol edilir, hangi gruplara kayıtlı. Sonra bu grupların hedef bölgeye yetkisi olup olmadığına bakılır; bölge iç içe olduğu için üst bölgeden gelen yetki de hesaba katılır. Ardından zaman programı kontrol edilir: seçilen tarih-saat, tanımlı mesai ya da vardiya bloğuna denk düşüyor mu, resmî tatile denk geliyor mu. Son olarak bölgeye özel bir belge şartı ya da günlük kota tanımlıysa bu da sınanır. Her adımın sonucu ayrı ayrı gösterilir. Sonuç ACCESS_GRANTED ise hangi kuralın izin verdiği, reddedilirse hangi adımda hangi sebep koduyla durduğu ekranda yazar.

Çakışan kuralın kazananını önceden görmek

Bir bölgeye birden fazla kural tanımlı olabilir: gruba yazılan genel bir yetki, kişiye yazılan bir istisna, alt bölgeye yazılan ayrı bir kısıtlama. Bu kurallar aynı kişi için farklı sonuç üretebildiğinde, hangisinin geçerli olduğunu tahmin etmek yerine simülatörden sorulur. Simülatör, hangi kuralın en özel olduğu için kazandığını ve diğer kuralların neden geride kaldığını sırayla listeler. Yeni bir kural yazarken sistem bunu otomatik de yapar: kaydetmeden önce mevcut kurallarla bir çelişki varsa uyarı çıkar, kural kaydedilmeden düzeltme fırsatı doğar.

Sıfır yan etki: test, gerçek geçiş gibi görünmez

Bir simülasyon sorgusu hiçbir kayda yazılmaz, hiçbir terminale komut göndermez. Geçiş olayları listesinde "Ahmet, dün 22:40'ta Depo'yu denedi" gibi bir satır oluşmaz. Çünkü böyle bir deneme gerçekte yaşanmamıştır, yalnızca sorgulanmıştır. Bu ayrım önemlidir: test amaçlı çalıştırılan yüzlerce sorgu, gerçek geçiş istatistiklerini bozmaz, denetim izini şişirmez.

Kaç kişi bu ekranı kullanmayı öğrenecek?

Genelde iki, üç kişi: yetki matrisini yöneten İK sorumlusu, güvenlik amiri, bazen saha müdürü. Ekran teknik bir araç değildir, kişi, bölge ve saat seçip "sorgula" düğmesine basmaktan ibarettir. Kurulum sürecinde bu ekran birlikte denenir, kurulum tamamlandığında ilgili kişiler ilk gerçek kuralı sizinle birlikte, sizin sorularınızla test eder. Ayrı bir eğitim günü planlamanız gerekmez.

Depo ve lojistik senaryosunda tipik kullanım

Vardiyalı çalışan bir depoda gece vardiyasına yeni katılan bir ekip için zaman programının doğru tanımlanıp tanımlanmadığı, ilk gece vardiyasından önce simülatörde sınanır. Sevkiyat kapısına yalnız belirli saatlerde giren sürücü firmaları için tanımlanan kural, saha dışından bir plan değişikliği geldiğinde yeniden test edilir. Kural değişmeden önce, yeni senaryonun sonucu görülür.

Yeni işe başlayan biri için ilk sorgu

Bir personel işe başladığında yetkisi genelde bir kerede tam doğru yazılmaz: üretim grubuna eklenir ama hangi alt bölgelere gireceği ilk günlerde netleşir. İK sorumlusu kişiyi gruba ekledikten sonra, "bu kişi yarın Boyahane'ye girebilir mi, Depo'ya girebilir mi" gibi birkaç soruyu simülatörden art arda sorar. Eksik kalan bir yetki varsa kural burada tamamlanır, kişi ilk gününde nizamiyede beklemez. Aynı kontrol, bir kişi departman değiştirdiğinde ya da geçici olarak başka bir hatta görevlendirildiğinde de tekrarlanır.

Toplu senaryo: bir vardiya planı değiştiğinde

Bazen değişen tek bir kişi olmaz, bir vardiyanın tamamı birden etkilenir. Üç vardiyalı bir üretim hattında gece vardiyasının başlangıç saati bir saat kaydırılacaksa, bu değişiklik yayına alınmadan önce o vardiyadaki birkaç kişi için ayrı ayrı simüle edilir. Yeni saatte kimin hâlâ yetkili olduğu, kimin zaman programı dışında kaldığı tek tek görülür. Sorun varsa vardiya planı toplantısında düzeltilir, ilk gece vardiyasında değil.

Adana ve Çukurova'daki tesislerde kurulum öncesi test

Kurulum sürecinde, yazılım tarafı aktifleştikten sonra ama saha ekibi kablolama ve turnike montajını bitirmeden önce, tanımlanan tüm kurallar kural simülatöründe sırayla denenebilir. Adana ve Çukurova'daki tesislerde bu, kurulum gününde sahada "bu kart neden çalışmadı" sorularıyla uğraşmak yerine, kuralların önceden doğrulanmış olarak sahaya çıkması demektir.

Kural testi ile geçiş raporunu karşılaştırmak

Simülatörün verdiği cevap ile sahada gerçekleşen sonucu karşılaştırmak, bir kuralın beklendiği gibi çalışıp çalışmadığını doğrulamanın en somut yoludur. Bir kural yayına alındıktan bir hafta sonra geçiş olayları listesinden aynı kişi ve bölge için gerçek kayıtlara bakılır; simülatörün öngördüğü sonuçla sahadaki sonuç örtüşüyorsa kural doğru çalışıyor demektir. Örtüşmüyorsa, örneğin beklenmedik bir OUTSIDE_SCHEDULE reddi birikmişse, zaman programı yeniden simülatörde gözden geçirilir, düzeltme masabaşında yapılır. Bu karşılaştırmayı düzenli yapan tesislerde kural setinin zamanla sahayla örtüşme oranı yükselir, ilk kurallardaki küçük hatalar birkaç hafta içinde temizlenir.