Buluttan Kapıya: Geçiş Kontrol ve PDKS'yi Uçtan Uca Çözmenin Doğru Yolu

Bir IT yöneticisiyle geçtiğimiz ay yaptığım görüşmede ilginç bir tablo çıktı ortaya. Şirketlerinde üç farklı sistemden veri akıyordu: kapı okuyucularından gelen ham geçiş kayıtları bir yerde, PDKS yazılımı başka bir yerde, mobil yoklama ise üçüncü bir uygulamada. Hiçbiri tam olarak konuşmuyordu. Ay sonu puantajını hazırlamak için İK ekibi üç sistemden veri çekip Excel'de birleştiriyordu. Saatlerce süren bir iş.

Bu sefer de o tanıdık soruyu sorduk: "Neden böyle bir yapı var?"

Cevap her zaman aynı: "Önce kapı okuyucusu aldık, sonra PDKS yazılımı aldık, mobil ihtiyaç çıkınca başka bir uygulama ekledik." Her bileşen ayrı bir tedarikçiden, ayrı bir dönemde, ayrı bir bütçeyle alınmıştı. Entegrasyon hiç gündeme gelmemişti.

Bu yazıda, geçiş kontrol ve PDKS'nin neden tek bir ekosistem içinde çözülmesi gerektiğini anlatmak istiyorum. Ve bu yapıyı kurarken bulut ile uç donanımın birbirini nasıl tamamladığını.

Önce kavramı netleştirelim: GKS ile PDKS aynı şey değil

Uygulamada sıkça karıştırılıyor, bu yüzden kısaca ayırt etmek gerekiyor.

GKS (Geçiş Kontrol Sistemi) fiziksel erişimi yönetir. Kim, hangi kapıdan, ne zaman geçebilir? Yetkisiz kişiyi dışarıda tutar. Bir güvenlik sistemidir.

PDKS (Personel Devam Kontrol Sistemi) ise zamanı yönetir. Çalışan işe kaçta geldi, kaçta ayrıldı, kaç saat mesai yaptı? Bir İK ve bordro sistemidir.

İkisi aynı fiziksel noktadan — kapıdan — veri alır. Ama bu veriyi farklı amaçlarla işler. Sorun tam burada başlıyor:çoğu işletme bu iki sistemi ayrı tedarikçilerden, ayrı yazılımlarla alıyor ve iki sistemi birbirine bağlamaya çalışırken kaynak harcıyor.

Bulut tabanlı yönetim neden işin sadece bir parçası

Son birkaç yılda PDKS ve geçiş kontrol pazarı hızla buluta taşındı. "Bulut tabanlı" olmak bir pazarlama artısı olmaktan çıktı, temel bir altyapı beklentisine dönüştü.

Ve haklı bir beklenti. Bulutun getirdiği avantajlar gerçek:

Merkezi yönetim. İstanbul, Ankara ve İzmir'deki üç şubeyi aynı panelden yönetebilmek, VPN altyapısı kurmak zorunda kalmamak, yeni bir kapı eklemek için sistemci beklemek zorunda kalmamak — bunlar küçük kolaylıklar değil, gerçek iş verimliliği.

Anlık görünürlük. Kim şu an binadayken çıkmış göründüğünü görmek, bir güvenlik olayında erişim loglarına anında ulaşmak, devamsızlık uyarısını sahadan değil masadan almak.

Ölçeklenebilirlik. Şirket büyüdükçe sistemi büyütmek için yeni sunucu almak, lisans yenilemek zorunda kalmamak. SaaS modeli bu esnekliği doğası gereği sağlıyor.

Otomatik güncellemeler. Güvenlik yamaları, yeni özellikler, mevzuat güncellemeleri otomatik geliyor. IT ekibine bakım yükü düşmüyor.

Ama burada önemli bir soruyu sormak gerekiyor: bulut yazılımı tek başına yeterli mi?

Bulutun çözemediği yer: fiziksel kapı

Bulut tabanlı bir PDKS yazılımı aldığınızda elinizdeki şey bir yönetim platformu. Verimli, erişilebilir, ölçeklenebilir. Ama bu platform, kapıdaki veriye ihtiyaç duyuyor.

O veriyi kim sağlıyor?

İşte burada sistemin en kritik halkası devreye giriyor: uç noktadaki donanım. Kapı okuyucusu, turnike kontrolörü, QR tarayıcı — bunlar olmazsa bulut platformunun işleyeceği ham veri yok.

Ve bu noktada işletmeler iki yoldan biriyle ilerliyor:

Yol 1: Farklı bir donanım tedarikçisinden okuyucu alıp PDKS yazılımına entegre etmeye çalışmak. Teoride makul görünüyor. Pratikte farklı protokoller, uyumsuz firmware versiyonları, "bu cihaz bizim sistemle tam çalışmıyor" sorunları ortaya çıkıyor. Entegrasyon proje bütçesinin önemli bir bölümünü yiyor, sonra da bakımda sorun kaynağına dönüşüyor.

Yol 2: Hem yazılım hem donanımı aynı ekosistemden almak. Tek tedarikçi, tek destek hattı, tasarım aşamasından itibaren birlikte çalışan bileşenler.

Uçta veri üretmek: okuyucunun yazılımla entegre tasarlanması farkı

Armongate'i geliştirirken bu ikinci yolu seçmemizin pratik bir gerekçesi vardı.

Kapı okuyucusu sadece "kim geçti" bilgisini vermez. Doğru tasarlandığında çok daha zengin veri üretir:

• Geçiş yönü (giriş mi çıkış mı)

• Kimlik doğrulama yöntemi (QR, NFC, kart, TC kimlik kartı, pasaport)

• Geçiş süresi (okuma-doğrulama-kapı açılma latency'si)

• Başarısız doğrulama denemeleri
  

Bu veri, PDKS için de GKS için de altın değerinde. Ama bu verinin üretilmesi, okuyucunun yazılımla aynı dili konuşmasına bağlı. Farklı tedarikçilerden alınan sistemlerde bu derinlikte veri aktarımı genellikle mümkün olmuyor; sadece ham timestamp geçiyor.

Armongate okuyucuları — VPass serisi — bulut platformuyla aynı ekip tarafından tasarlandı. Okuyucudan gelen her veri noktası, platformun anlayacağı formatta, gerçek zamanlı olarak buluta akıyor. Aradaki "çeviri" katmanı yok.

360 derece çözüm ne anlama geliyor?

"360 derece çözüm" kavramı pazarlamada çok kullanılıyor. Somutlaştırmak gerekirse şunu kastediyoruz:

Bir çalışanın iş gününü düşünün. Sabah kapıdan girişinden akşam çıkışına kadar olan sürede şu noktalar var:

Fiziksel geçiş. Kapıdan geçerken okuyucu kimliği doğrular, kapıyı açar, geçişi kaydeder. Bu GKS'nin alanı.

Devam kaydı. Aynı geçiş verisi PDKS'ye işlenir: giriş saati, çalışma süresi, mesai hesabı.

Saha ve uzaktan çalışma. Ofise gelmeyen, sahada çalışan personel mobil uygulama üzerinden QR kodu okutarak giriş kaydı yapar. Sistem, yalnızca QR okutma anında telefonun konumunu yakalar ve tanımlı çalışma noktasıyla eşleşip eşleşmediğini kontrol eder. Sürekli bir konum takibi söz konusu değildir; tek bir anlık eşleştirmedir. Bu veri de aynı platforma akar.

Ziyaretçi. Misafir lobide self-servis QR kodu ile kaydolur, yetkili alanlara geçebilmesi için geçici dijital kimlik üretilir.

Yemekhane ve sosyal alan. Öğle yemeği hakkı aynı kimlik üzerinden doğrulanır, kullanım kaydedilir.

Otopark. Araç girişi plaka tanıma veya dijital kimlikle yönetilir, aynı platforma entegre.

İzin ve vardiya. PDKS modülü üzerinden izin talepleri onaylanır, vardiya planları güncellenir.

Raporlama ve bordro. Tüm veriler tek kaynaktan alınır, Logo, SAP, Netsis gibi İK ve ERP sistemlerine aktarılır.

Tüm bu akışın tek bir platformda, tek bir kullanıcı arayüzünde yönetilmesi, yöneticinin gün içinde beş farklı sistemde gezinmek zorunda kalmaması — işte 360 derece bu.

"Tek tedarikçi riski" itirazına yanıt

Bu yaklaşımı önerdiğimizde bazı IT yöneticileri haklı bir soru soruyor: "Tek tedarikçiye bağımlı olmak riskli değilmi?"

Anlıyorum bu kaygıyı. Ama burada birkaç faktörü göz önüne almak gerekiyor.

Entegrasyon riski vs. tedarikçi riski. Çok tedarikçili yapı tedarikçi bağımlılığını azaltıyor, ama entegrasyon karmaşıklığını artırıyor. İki sistem arasındaki entegrasyon koparsa her iki taraf da birbirini suçlar, siz ortada kalırsınız. Tek tedarikçide destek hattı nettir.

Açık entegrasyon. Armongate, REST API üzerinden üçüncü taraf sistemlerle entegrasyona açık. Yarın farklı bir İK yazılımı ya da farklı bir okuyucu eklemek isterseniz, platform buna izin veriyor. Kapalı kutu değil.

Modüler kullanım. Tüm modülleri birden almak zorunda değilsiniz. Sadece GKS ve PDKS ile başlayıp ihtiyaç büyüdükçe ziyaretçi yönetimi, yemekhane, otopark gibi modülleri açabilirsiniz.

Kurumların gözden kaçırdığı gerçek maliyet

Fiyat karşılaştırmalarında genellikle lisans ücreti ve donanım maliyeti görünür. Gizli maliyetler görünmez.

Farklı tedarikçilerden oluşan bir ekosistemi bir yıl boyunca işlettikten sonra şu kalemleri toplayın: entegrasyonprojesinin danışmanlık ücreti, iki sistem arasında veri tutarsızlığı çıktığında harcanan IT saatleri, firmware güncellemesi sonrası bozulan entegrasyonu düzeltme maliyeti, iki farklı destek hattıyla yazışma süreleri, ay sonu raporunu Excel'de birleştirmek için harcanan İK saatleri.

Bunların toplamı çoğu zaman entegre bir çözümün fiyat farkını fazlasıyla karşılıyor.

Sahada ne görüyoruz?

Toprak Mahsulleri Ofisi geçişini bulut tabanlı Armongate platformuna taşıdığında öncelikli motivasyon hız ve güvenlikti. Sonuçta elde ettikleri şey bunun ötesine geçti: birden fazla lokasyonun tek merkezden yönetimi, geçiş raporlarına anlık erişim ve İK süreçlerine entegrasyon. Daha önce ayrı sistemlerde dağılmış olan veri, tek kaynakta birleşti.

Bu tablo şantiyelerden üniversite kampüslerine, AVM'lerden üretim tesislerine kadar tekrar ediyor. Her seferinde aynı şeyi öğreniyoruz: asıl dönüşüm, birden fazla sorunu aynı anda çözdüğünüzde başlıyor.

Sonuç: Kapıdan buluta, buluttan karara

Geçiş kontrol ve PDKS artık iki ayrı sorun değil. Aynı fiziksel noktadan akan, farklı katmanlarda işlenen ve birbirini tamamlayan veri akışları.

Bunu uçtan uca çözmenin yolu, kapıdaki donanımın ve buluttaki yazılımın birlikte tasarlanmasından geçiyor. Okuyucu veriyi üretiyor, platform veriyi anlamlandırıyor, entegrasyon kararı besliyor.

Ayrı sistemler bu döngünün herhangi bir halkasını kırıyor. Birleşik ekosistem ise halkayı tamamlıyor.

Kurumunuzun mevcut GKS ve PDKS yapısını değerlendirmek ya da yeni bir mimari tasarlamak için bizimle iletişime geçebilirsiniz.

Bu yazı Armongate ürün ve mühendislik ekibi tarafından hazırlanmıştır. Teknik sorularınız için destek@armongate.com adresine ulaşabilirsiniz.