Geçiş Kontrol ve PDKS Pazarındaki Sessiz Çıkmaz: Neden Herkes Şikâyetçi Ama Kimse Değiştiremiyor?

Yıllardır geçiş kontrol (GKS) ve personel devam kontrol (PDKS) projelerinin içindeyim. Fabrikalarda, plazalarda, kampüslerde, şantiyelerde yüzlerce sistemin kuruluşuna, daha da önemlisi yüzlerce sistemin tıkanışına şahit oldum. Bu yazıyı, sahada her hafta duyduğum ama sektörün pek yüksek sesle konuşmadığı iki yapısal soruna dikkat çekmek için yazıyorum.

Çünkü müşterilerin yaşadığı hayal kırıklığı bireysel bir şanssızlık değil. Pazarın kuruluş biçiminden kaynaklanan, sistematik bir çıkmaz.

Hikâye hep aynı başlıyor

Bir gün şirkete ithal bir cihaz alınır. Turnike, kart okuyucu, geçiş paneli… Donanım fena değildir; metali sağlamdır, ışığı yanar, kapı açılır. Sorun, yazılım ekranı açıldığında başlar.

Aradan birkaç ay geçer ve şikâyet listesi şekillenir: İstenen rapor alınamıyor. İK ve bordro yazılımıyla entegrasyon kurulamıyor. Güncelleme gelmiyor, destek talepleri cevapsız kalıyor. Her yeni ihtiyaç için alınan cevap aynı: "Yapılamıyor."

Burada yıllar içinde fark ettiğim çarpıcı bir örüntü var: Şikâyetlerde donanım hep en sonda geliyor. Cihaz çalışıyor; sistemi yönetemeyen taraf yazılım. Bunun nedeni basit: pazarın önemli bir kısmı, yurt dışından donanım ithal edip yanına "idare eder" seviyede bir yazılım iliştiren bir modelle kurulmuş. Bu modelde yazılım bir ürün değil, donanımı satabilmek için katlanılan bir zorunluluk. Yazılıma yatırım yapılmıyor, çünkü para donanımdan kazanılıyor.

Müşterinin kapanı: "Donanıma bu kadar para verdik"

İşin acı tarafı şu: müşteri sorunun yazılımda olduğunu görüyor ama sistemi değiştiremiyor. Çünkü ortada ciddi bir donanım yatırımı var. Turnikeler sahaya monte edilmiş, kablolar çekilmiş, okuyucular kapılara takılmış. "Her şeyi söküp yeniden mi alacağız?" sorusu, her değişim fikrini daha doğmadan öldürüyor.

Bu noktada müşteri kendince mantıklı bir çıkış arıyor: "Mevcut donanımı koruyalım, sadece yazılımı değiştirelim." Ve piyasada bu talebe verilen klasik cevap devreye giriyor: cihaz entegrasyonu için SDK istenir, yazılım entegrasyonu için kaynak kod istenir.

Müşteri zanneder ki bu ikisi eline geçse sistem sonsuza kadar idame edilebilir; bundan sonraki yatırımlar boşa gitmez. Sahada gördüğüm gerçek ise farklı. SDK'lar çoğu zaman eksik dokümante edilmiştir, sürüm değiştikçe kırılır, üretici desteği olmadan ayakta tutulamaz. Kaynak kod ise devredilse bile onu geliştirecek, güncelleyecek, mevzuata uyduracak bir ekip gerektirir. Yani müşteriye çözüm diye verilen şey, aslında sorumluluğun müşteriye devredilmesidir. Sahte bir umuttur.

İkinci kırık: Bölünmüş çözümler ve Geçiş Kontrol'de "muhatap kim?" sorusu

Birinci sorun yazılımın zayıflığıysa, ikinci ve daha az konuşulan sorun pazarın bölünmüşlüğü. Piyasadaki firmaların büyük çoğunluğu entegre çözüm sunmuyor. İki tipik senaryo var:

Birinci senaryo: PDKS yazılımı geliştiren firmanın kendi donanımı yok. Kapıdaki geçiş cihazı üçüncü partiden geliyor. Entegrasyon gerektiğinde muhatabınız PDKS firması; ama cihazın asıl üreticisi okyanus ötesinde. Talebiniz üreticiye "iletiliyor". Dönüş ne zaman gelir, gelir mi, belli değil. Siz bu arada eksik veriyle bordro kapatmaya çalışıyorsunuz.

İkinci senaryo: Önce kapıya cihaz alınmış, PDKS ihtiyacı sonradan doğmuş. Cihazı satan bayinin işi kutuyu teslim etmekle bitmiş; yazılım entegrasyonuyla ilgilenmiyor. İlgilense de yapabildiği kısıtlı, çünkü yazılım onun ürünü değil.

İki senaryonun ortak sonucu aynı: sorun çıktığında herkes birbirini gösteriyor. Yazılımcı üreticiyi, bayi yazılımcıyı, üretici mesafeyi… Ve ortada tek bir soru kalıyor: Muhatap kim?

Bu soruya net cevap verilemeyen her projede kaybeden taraf bellidir: müşteri.

Üçüncü kaygı: "Bugün yeterli görünüyor ama 5 yıl sonra?"

Değişimi düşünen müşterilerle konuştuğumda çok haklı bir tereddütle karşılaşıyorum: "Beş yıl önce aldığımız sistem de o gün yeterli görünüyordu. Bugün anlattıklarınız da yeterli görünüyor. Ya yarın gelişen ihtiyaçlarımızı bu sistem de karşılayamazsa?"

Bu kaygıyı küçümsemiyorum; tam tersine, en meşru soru bu. Cevabı da bir vaatte değil, modelde aramak gerekiyor.

Bir sistemin gelecekte de yaşayacağının tek güvencesi, yazılımın satın alındığı gün donmuş bir kutu değil, sürekli geliştirilen canlı bir ürün olmasıdır. Yazılımını kendisi geliştirmeyen, ithal ettiği donanımın yanındaki yazılıma müdahale şansı olmayan bir tedarikçi bu güvenceyi yapısal olarak veremez. Çünkü değişen mevzuata, yeni entegrasyon ihtiyacına, yeni bir rapor talebine cevap üretecek geliştirme gücü onda yok.

Armongate'te bu yüzden yazılımı kendimiz geliştiriyoruz ve bulutta yayında olan GKS+PDKS yazılımımıza ayda iki sprint çıkıyoruz. Bu sprintlerin içeriği bazen yeni bir özellik, bazen bir iyileştirme, bazen bir yama, bazen de PDKS tarafındaki mevzuat değişikliklerinin sisteme işlenmesi oluyor. Bugün kurumsal müşterilerimiz aktif-aktif sunucu mimarisinde çalışabilen, kesintisizlik hedefiyle tasarlanmış bu altyapıyı sahada kullanıyor. "Gelecekte ne lazım olur?" sorusunun cevabını müşterinin bugünden tahmin etmesine gerek kalmıyor; çünkü sistem ihtiyaçla birlikte gelişiyor.

Doğru modelin dört şartı

Bütün bu tecrübenin bizi getirdiği yer, sağlıklı bir geçiş kontrol ve PDKS yatırımının dört şartı olduğu:

Yazılım hizmet olarak (SaaS) alınmalı. Kutuda değil, bulutta; sürümü eskimeyen, sürekli güncellenen bir hizmet olarak. Böylece "5 yıl sonra eskir mi?" sorusu anlamını yitirir.
Yazılımı geliştiren ile sistemi kuran aynı olmalı. Talebiniz okyanus ötesine "iletilmemeli"; talebi alan ekip, kodu yazan ekip olmalı.
Cihaz KVKK'ya mimariden uyumlu olmalı. Biyometrik veriyi cihazda ve sistemde saklamayan bir tasarım, kişisel verilerin korunması yükünü sonradan yamanan bir prosedür olmaktan çıkarıp baştan çözer.
Cihaz çevrimdışı da çalışabilmeli. İnternet kesildiğinde kapılar durmamalı; geçişler cihazda işlenmeli, bağlantı geldiğinde senkronize olmalı.

Tek yazılım, tek lisans, tek muhatap

Bölünmüşlük sorununa dönersek: Armongate'i kurgularken en baştan verdiğimiz karar, geçiş kontrol ve PDKS'yi iki ayrı ürün olarak yapıp sonradan "entegre etmek" değil, ikisini aynı yazılımın içinde doğurmaktı. Bizde GKS ile PDKS arasında entegrasyon yoktur, çünkü gerek yoktur. Kapıdan geçen kartın verisi ile bordroya giden puantaj verisi aynı sistemin içinde yaşar.

Bu bütünlük lisanslamamıza da yansıyor: lisanslarımızı ya GKS ya da PDKS olarak yapıyoruz ve PDKS lisansı alan bir müşteri, GKS'yi de kapsayan bir lisansa sahip oluyor. İki ürün, iki sözleşme, iki fatura, iki destek hattı yok. Tek lisans, tek yazılım ve sorun her ne olursa olsun tek muhatap.

"Muhatap kim?" sorusunun cevabı bizde tek kelime: biz.

Kapanış: Sorun sizde değil, modelde

Eğer bugün geçiş sisteminizden memnun değilseniz ama "donanıma bu kadar yatırım yaptık" diye değiştiremiyorsanız; entegrasyon talepleriniz firmalar arasında paslaşılıyorsa; bir sonraki sistemin de birkaç yıl içinde eskiyeceğinden korkuyorsanız, bilin ki yalnız değilsiniz ve sorun sizin yanlış seçiminiz değil. Sorun, pazarın uzun yıllardır alıştığı modelin kendisi.

O modelin alternatifi var: kendi yazılımını geliştiren, iki haftada bir güncellenen, KVKK'ya mimariden uyumlu, çevrimdışı çalışabilen cihazlarla desteklenen, GKS ve PDKS'yi tek yazılımda ve tek lisansta birleştiren bir yaklaşım.

Sorularınız, itirazlarınız, "bizim sahadaki durum şöyle" diyeceğiniz tecrübeleriniz varsa yorumlarda ya da mesaj kutumda konuşalım. Bu sektörün bu tartışmaya ihtiyacı var.