Otelde Güvenlik Sistemi Nasıl Kurulur? Günlük Güvenlik, Olay Yönetimi ve Incident Report Rehberi

Bir otelde kamera sistemi var.

Yangın söndürücüler yerinde.

Elektronik oda kilitleri çalışıyor.

Gece kapılar kapanıyor.

Peki otel güvenli midir?

Bunu yalnızca bu bilgilere bakarak söyleyemeyiz.

Çünkü otel güvenliği:

ekipman satın almak değil, risk yönetmek işidir.

Bir arka kapı sürekli açık kalıyorsa,

kameralardan biri aylardır kayıt yapmıyorsa,

Master Key'in kimde olduğu bilinmiyorsa,

gece vardiyası acil durumda kimi arayacağını bilmiyorsa,

bir güvenlik olayı yaşanmış ama Incident Report hazırlanmamışsa,

otelde çok sayıda güvenlik ekipmanı bulunmasına rağmen:

gerçek bir güvenlik sistemi olmayabilir.

Profesyonel otel güvenliği şu döngüyle çalışmalıdır:

Riskleri Tanımla → Önlem Al → Kontrol Et → Tespit Et → İlk Müdahaleyi Yap → Stabilize Et → Bildir → Escalate Et → Kayıt Altına Al → Analiz Et → CAPA Oluştur → SOP / Eğitim / Ekipmanı Güncelle → Tekrarını Önle

Çünkü iyi güvenliğin temel prensibi şudur:

Olay olduğunda hızlı müdahale etmek önemlidir; fakat daha güçlü sistem olayın meydana gelme ihtimalini önceden azaltmaya çalışır.

1. Otel Güvenliği Nedir?

Otel güvenliği yalnızca:

• güvenlik görevlisi,
• CCTV,
• elektronik kilit,
• yangın sistemi

değildir.

Güvenlik sistemi:

Misafir Güvenliği

Misafirin konaklama boyunca korunması.

Personel Güvenliği

Çalışanların güvenli çalışma ortamı.

Fiziksel Güvenlik

Bina, oda, depo, teknik alan ve diğer fiziksel varlıkların korunması.

Erişim Güvenliği

Kimin nereye girebildiğinin kontrolü.

Bilgi Güvenliği

Misafir ve işletme bilgilerinin korunması.

Operasyonel Güvenlik

Günlük süreçlerin risk yaratmayacak şekilde yürütülmesi.

Acil Durum Yönetimi

Yangın, deprem, sağlık olayı, su baskını, elektrik kesintisi ve benzeri olaylara hazırlık.

Kriz Yönetimi

Normal operasyonun ötesine geçen ciddi olayların koordinasyonu.

Dolayısıyla:

Security = İnsan + Bina + Sistem + Prosedür + Eğitim + Kontrol + Kayıt

olarak düşünülmelidir.

2. Güvenlik Sadece Güvenlik Departmanının İşi Değildir

Housekeeping:

odada olağan dışı bir durum fark edebilir.

Resepsiyon:

otele kimin girdiğini görebilir.

Teknik ekip:

yangın veya mekanik sistemlerde risk tespit edebilir.

F&B:

gıda veya ekipman kaynaklı risk görebilir.

Gece vardiyası:

şüpheli hareket fark edebilir.

Dolayısıyla:

güvenlik departmanlar arası ortak sorumluluktur.

Güvenlik sorumlusu sistemi koordine edebilir.

Ama:

bütün çalışanların güvenlik rolü vardır.

3. Güvenlik Sisteminin İlk Adımı Kamera Satın Almak Değildir

İlk soru:

“Otelimizde ne olabilir?”

olmalıdır.

Yani:

Risk Assessment — Risk Değerlendirmesi

yapılmalıdır.

Örneğin:

• yetkisiz kişi girişi,
• oda kartı kaybı,
• Master Key kaybı,
• hırsızlık şüphesi,
• misafir yaralanması,
• çocuk güvenliği,
• havuz kazası,
• yangın,
• elektrik kesintisi,
• su baskını,
• gaz kaçağı,
• deprem,
• sağlık olayı,
• kavga,
• şüpheli kişi,
• kayıp eşya,
• CCTV arızası

gibi riskler değerlendirilebilir.

4. Risk Register Oluşturun

Risklerin hafızada tutulması yerine:

Risk Register

oluşturulabilir.

Örneğin:

Ama amaç:

tabloyu doldurmak değildir.

Risk Register'ın görevi:

hangi risklere önce yatırım,

kontrol,

eğitim

ve SOP gerektiğini göstermektir.

5. Risk = Olasılık × Etki Mantığı

Basit bir yaklaşım:

Risk Score = Probability × Impact

olabilir.

Örneğin:

olasılık:

1–5

etki:

1–5

olarak değerlendirilebilir.

Bir olay:

nadiren gerçekleşiyor olabilir.

Ama sonucu:

çok ciddi olabilir.

Bu nedenle:

düşük frekanslı risk, düşük öncelikli risk anlamına gelmez.

Yangın bunun tipik örneklerinden biridir.

6. Riskleri Önceliklendirin

Her risk için aynı bütçeyi harcamak mümkün değildir.

Bu nedenle:

Critical Risk

Derhal kontrol gerekir.

High Risk

Öncelikli aksiyon gerekir.

Medium Risk

Planlı kontrol gerekir.

Low Risk

İzlenebilir.

Bu yapı:

güvenlik bütçesini:

“Ne satın alalım?”

sorusundan çıkarıp:

“En büyük riskimiz nedir?”

sorusuna taşır.

7. Prevention Güvenliğin En Değerli Aşamasıdır

Bir olay gerçekleştiğinde:

müdahale gerekir.

Ama daha güçlü sistem:

olayın oluşmasını engellemeye çalışır.

Örneğin:

arka kapıdan yetkisiz giriş yaşandı.

Reaktif yaklaşım:

kişiyi çıkarmaktır.

Proaktif yaklaşım:

• kapı neden açıktı?
• kart sistemi var mı?
• kamera görüyor mu?
• aydınlatma yeterli mi?
• personel prosedürü biliyor mu?

sorularını sormaktır.

İyi güvenlik olay kovalamaz; risk azaltır.

8. Günlük Güvenlik Operasyonu Nasıl Kurulur?

Güvenlik:

yalnızca acil durumda kullanılan prosedürlerden oluşmamalıdır.

Her gün kontrol edilmelidir.

Basit bir:

Daily Security Checklist

oluşturulabilir.

Örneğin:

Girişler

• ana giriş,
• personel girişi,
• servis girişi,
• arka kapılar.

Acil Çıkışlar

• önü açık mı?
• erişilebilir mi?

CCTV

• kritik kameralar çalışıyor mu?
• kayıt devam ediyor mu?

Access Control

• kritik kapılar kapalı mı?
• kart sistemi çalışıyor mu?

Lighting

• otopark,
• bahçe,
• dış alan,
• kritik koridorlar.

Previous Shift

• açık güvenlik olayı var mı?
• Follow-Up gerekiyor mu?

Ama:

Checklist'in amacı kutucuk işaretlemek değil, gerçekten kontrol etmektir.

9. Security Walkthrough Nedir?

Yönetici veya sorumlu personel:

oteli güvenlik perspektifiyle fiziksel olarak gezebilir.

Örneğin:

• açık kapı,
• kırık kilit,
• karanlık alan,
• kapatılmış acil çıkış,
• sahipsiz eşya,
• hasarlı korkuluk,
• kaygan zemin,
• çalışmayan kamera,
• açık teknik alan

aranır.

Bu:

Security Walkthrough

olarak standartlaştırılabilir.

10. Gündüz ve Gece Güvenliği Aynı Değildir

Gündüz güvenli görünen alan:

gece farklı risk yaratabilir.

Örneğin:

arka bahçe gündüz görünürdür.

Gece:

aydınlatma yetersiz olabilir.

Otopark gündüz kontrollüdür.

Gece:

personel sayısı azalabilir.

Bu nedenle:

Night Security Walkthrough

ayrıca yapılmalıdır.

11. Gece Vardiyası Güvenlik Açısından Kritik Bir Vardiyadır

Gece:

• personel sayısı azalır,
• yönetici bulunmayabilir,
• giriş çıkış daha az görünür olabilir,
• misafirlerin büyük bölümü odalardadır,
• dış destek daha geç gelebilir.

Gece yaşanabilecek olaylar:

• şüpheli kişi,
• kavga,
• gürültü,
• hırsızlık şüphesi,
• odaya izinsiz giriş,
• Lost & Found,
• misafirler arası konflikt,
• yetkisiz ziyaretçi

olabilir.

Bu nedenle gece personeli:

“Bir şey olursa müdürü ararım.”

seviyesinde bırakılmamalıdır.

12. Gece Personeli İlk 5 Dakikayı Bilmelidir

Çalışanın şu soruya cevap verebilmesi gerekir:

“Bu olay olduğunda kimi arayacağım ve ilk olarak ne yapacağım?”

Örneğin:

Detect → Protect → Stabilize → Notify → Escalate → Document

Bu sıra:

olayın türüne göre değişebilir.

Ama çalışan:

ilk hareketini bilmelidir.

13. Güvenlikte İletişim Zinciri Kurulmalıdır

Basit zincir:

Olayı Fark Eden → İlk Müdahale → Sorumlu Yönetici → Gerekli Dış Kurum → Üst Yönetim → Kayıt

olabilir.

Buradaki önemli konu:

kimin kimi ne zaman arayacağının olay sırasında düşünülmemesidir.

Önceden belirlenmelidir.

14. Her Olay Aynı Seviyede Değildir

Basit bir:

Incident Severity Matrix

kurulabilir.

Level 1 — Minor

Küçük ve lokal olay.

Level 2 — Moderate

Misafir veya operasyonu belirgin etkileyen olay.

Level 3 — Serious

Ciddi güvenlik, finansal veya operasyonel etki.

Level 4 — Critical / Crisis

Can güvenliği, ciddi yaralanma, büyük tahliye, ciddi hukuki veya işletme devamlılığı riski.

Seviye yükseldikçe:

Escalation

da yükselmelidir.

15. Güvenlikte En Büyük Hatalardan Biri Geç Bildirimdir

Örneğin:

büyük bir su kaçağı var.

Personel:

kendi başına çözmeye çalışıyor.

30 dakika sonra yönetici öğreniyor.

Bu yanlış olabilir.

Bazı olaylar:

günlük raporu beklememelidir.

Özellikle kritik olaylarda:

Detect → Stabilize → Notify → Escalate → Document

mantığı kullanılmalıdır.

Önce:

insan ve alan güvenliği.

Sonra:

yönetim ve gerekli dış destek.

Ardından:

kayıt.

16. Access Control Nedir?

Access Control:

kimin hangi alana hangi yetkiyle girebildiğinin kontrolüdür.

Otelde:

• Guest Areas,
• Staff Areas,
• Technical Areas,
• Storage,
• Back Office,
• Server / IT,
• Cash Areas,
• Master Key Storage

farklı erişim seviyelerine sahip olabilir.

Temel soru:

“Bu alana gerçekten kimlerin girmesi gerekiyor?”

olmalıdır.

17. “Kapı Kilitli” Olması Access Control Sistemi Olduğu Anlamına Gelmez

Çünkü:

• anahtar kimde?
• kart yetkisi kimde?
• ayrılan personelin erişimi kapatıldı mı?
• Master Key kimde?
• kayıp kart iptal edildi mi?
• giriş kayıtları tutuluyor mu?

bilinmiyorsa:

kilit vardır.

Ama:

kontrollü erişim sistemi yoktur.

18. Master Key Yönetimi Kritik Bir Süreçtir

Master Key:

çok geniş erişim sağlayabilir.

Bu nedenle:

• kim aldı?
• ne zaman aldı?
• neden aldı?
• ne zaman iade etti?

izlenebilir olmalıdır.

Basit:

Master Key Log

bile ciddi kontrol sağlar.

Temel prensip:

Master Key'in yalnızca nerede olduğunu değil, kimin sorumluluğunda olduğunu bilmeliyiz.

19. Personel Ayrıldığında Erişimler Kapatılmalıdır

Offboarding yalnızca:

maaş ve insan kaynakları işlemi değildir.

Ayrılan çalışanın:

• oda kartı,
• personel kartı,
• fiziksel anahtarı,
• CCTV hesabı,
• PMS hesabı,
• diğer sistem erişimleri

kapatılmalıdır.

Bu:

HR + IT + Security ortak workflow'u

olmalıdır.

20. Ziyaretçi Yönetimi

Misafir:

ziyaretçi kabul edebilir.

Tedarikçi gelebilir.

Teknik servis gelebilir.

Kurye gelebilir.

Ama:

otele giren herkesin misafir olduğu varsayılmamalıdır.

Otelin konseptine göre:

• ziyaretçi tanımlama,
• kime geldiği,
• hangi alana gideceği,
• gerekirse kayıt,
• çıkış kontrolü

tanımlanabilir.

Ama güvenlik prosedürü:

misafir deneyimini gereksiz biçimde sertleştirmemelidir.

Risk ile hospitality arasında denge gerekir.

21. Şüpheli Kişi Nasıl Yönetilmelidir?

Şüpheli davranış görüldüğünde:

personelin amacı:

kahramanlık yapmak değildir.

Öncelik:

• gözlem,
• güvenli mesafe,
• doğru kişiyi bilgilendirme,
• gerekiyorsa profesyonel destek,
• olayın kayıt altına alınması

olmalıdır.

Personel:

kendi eğitim ve yetki sınırının dışında fiziksel müdahaleye zorlanmamalıdır.

22. Güvenlikte “Kovalamak” Her Zaman Doğru Değildir

Özellikle ciddi tehdit durumunda:

çalışanın:

• kişiyi kovalamaya çalışması,
• fiziksel mücadeleye girmesi,
• zorla engellemeye çalışması

daha büyük risk yaratabilir.

Temel prensip:

personel güvenliği önce gelir.

Gerektiğinde:

profesyonel güvenlik veya ilgili dış destek devreye alınmalıdır.

23. CCTV Güvenlik Sisteminin Tamamı Değildir

Bir otelde:

50 kamera olabilir.

Ama:

• 7'si çalışmıyor,
• kayıt cihazının saati yanlış,
• gece görüntüsü kötü,
• kritik giriş görünmüyor,
• kayıt bulunamıyor

ise:

kamera sayısının anlamı azalır.

CCTV'nin değer zinciri:

Kamera = Görme

Kayıt = Kanıt

İzleme = Tespit

Prosedür = Müdahale

Analiz = Öğrenme

olarak düşünülmelidir.

24. Kamera Nereye Konulmalı?

Doğru soru:

“Nereye kamera takabiliriz?”

değil;

“Hangi riski hangi görüntüyle yönetmek istiyoruz?”

olmalıdır.

Risk haritasına göre:

• girişler,
• otopark,
• bahçe,
• ortak alanlar,
• kritik geçiş noktaları

değerlendirilebilir.

CCTV:

risk haritasından türemelidir.

25. CCTV'nin Amacı Nedir?

CCTV:

• güvenlik olaylarını tespit etmek,
• şüpheli hareketleri incelemek,
• yetkisiz erişimi araştırmak,
• hırsızlık veya hasar olaylarını incelemek,
• olay zaman çizelgesi oluşturmak,
• acil durumda durumu değerlendirmek

için kullanılabilir.

Ama:

misafir mahremiyetini ihlal eden veya personeli kontrolsüz şekilde sürekli gözetleyen bir sisteme dönüşmemelidir.

Güvenlik ile mahremiyet birlikte düşünülmelidir.

26. CCTV Günlük Kontrol Edilmelidir

Örneğin:

• kritik kameralar online mı?
• görüntü geliyor mu?
• kayıt yapılıyor mu?
• tarih/saat doğru mu?
• NVR çalışıyor mu?
• kritik kamera arızası var mı?

kontrol edilebilir.

Çünkü:

olaydan sonra kameranın üç haftadır kayıt yapmadığını öğrenmek çok geçtir.

27. CCTV'yi Olay Perspektifinden Test Edin

Yönetici kendine şunu sorabilir:

“Saat 22:00'de arka kapıdan biri girse hangi kameradan görebilirim?”

veya:

“205 numaralı odaya yetkisiz erişim iddiası olsa hangi kayıtları kontrol ederim?”

Bu yaklaşım:

kameranın yalnızca çalışıp çalışmadığını değil:

olay çözmek için gerçekten kullanılabilir olup olmadığını

test eder.

28. Lost & Found Güvenlik Sürecidir

Misafir:

odada değerli eşya unuttu.

Housekeeping buldu.

Sonra ne olacak?

Doğru sistem:

Found → Do Not Remove Unrecorded → Record → Identify → Secure → Store → Guest Contact → Return / Disposal According to Policy

şeklinde olabilir.

Amaç:

eşyanın bulunduğu andan teslim edildiği ana kadar izlenebilirlik sağlamaktır.

29. Güvenlik Olayı Nedir?

Incident:

normal operasyonun dışında gerçekleşen ve:

• insan,
• bina,
• ekipman,
• bilgi,
• işletme

üzerinde güvenlik veya operasyonel etki yaratan olaydır.

Örneğin:

• düşme,
• yaralanma,
• hırsızlık şüphesi,
• kavga,
• yetkisiz giriş,
• ciddi teknik arıza,
• su baskını,
• yangın,
• havuz kazası,
• güvenlik ihlali.

Ama:

her operasyon hatası aynı zamanda Incident olmayabilir.

Otel kendi sınıflandırmasını tanımlamalıdır.

30. Incident Report Nedir?

Incident Report:

bir olay sonrasında:

• ne olduğunu,
• ne zaman olduğunu,
• nerede olduğunu,
• kimlerin etkilendiğini,
• hangi aksiyonların alındığını,
• kimlerin bilgilendirildiğini,
• hangi kanıtların bulunduğunu,
• sonucun ne olduğunu

kayıt altına alan rapordur.

Ancak güçlü Incident Report:

yalnızca:

“Ne oldu?”

sorusunu cevaplamaz.

Şunu da sorar:

“Neden oldu ve tekrarını önlemek için ne yapacağız?”

31. Incident Report Neden Tutulur?

Amaç:

personeli suçlamak değildir.

Incident Report:

işletmenin kurumsal hafızasını oluşturur.

Çünkü çalışan:

olayı hatırlayabilir.

Ama altı ay sonra:

personel değişebilir.

Detaylar unutulabilir.

Aynı olay tekrar yaşanabilir.

Kayıt sistemi:

kişisel hafızayı kurumsal bilgiye dönüştürür.

32. Incident Report'ta Hangi Alanlar Olmalı?

Örneğin:

Temel Bilgi

• Incident No
• tarih
• saat
• lokasyon
• olay türü
• severity.

Etkilenen

• misafir,
• çalışan,
• ziyaretçi,
• bina,
• ekipman.

Olay Açıklaması

Ne oldu?

Timeline

Hangi saatte ne oldu?

Immediate Action

İlk müdahale neydi?

Notification

Kim bilgilendirildi?

External Support

Gerekli dış destek kullanıldı mı?

Damage / Impact

Yaralanma, hasar veya operasyon etkisi.

Evidence

• CCTV,
• fotoğraf,
• kayıt,
• tanık,
• sistem logları.

Follow-Up

Sonraki aksiyon.

Root Cause

Neden oldu?

CAPA

Tekrarını önlemek için ne yapılacak?

33. Incident Report Tarafsız Yazılmalıdır

Kötü ifade:

“Resepsiyonistin dikkatsizliği nedeniyle kişi içeri girdi.”

Daha objektif ifade:

“22:14'te ziyaretçinin resepsiyon kontrolü yapılmadan asansör alanına geçtiği CCTV kayıtlarında görüldü.”

Önce:

fact

yazılmalıdır.

Sonra:

analiz yapılmalıdır.

Olay raporu yorumdan önce olguyu kaydetmelidir.

34. Görülen ile Duyulanı Ayırın

Örneğin:

Gözlem

“Misafir saat 21:10'da lobby zemininin yanında yerde bulundu.”

Beyan

“Misafir, kayarak düştüğünü ifade etti.”

Bunlar aynı şey değildir.

Rapor:

gözlem ile ifadeyi birbirine karıştırmamalıdır.

Bu yaklaşım:

raporun güvenilirliğini artırır.

35. Incident Timeline Neden Önemlidir?

Örneğin:

22:14 — şüpheli kişi arka girişten görüldü.

22:15 — resepsiyon bilgilendirildi.

22:17 — Duty Manager geldi.

22:20 — CCTV kontrol edildi.

22:23 — kişi binadan ayrıldı.

22:30 — Incident Log açıldı.

Timeline:

müdahalenin hızını ve karar sırasını

görmeyi sağlar.

36. Kanıt Yönetimi

Olay sonrasında:

• CCTV,
• fotoğraf,
• kart erişim kaydı,
• PMS kaydı,
• tanık bilgisi,
• teknik kayıt

önemli olabilir.

Ancak:

bu bilgilerin:

• kim tarafından alındığı,
• nerede saklandığı,
• kimlerin eriştiği

kontrollü olmalıdır.

Kanıt toplamak kadar kanıtın bütünlüğünü korumak da önemlidir.

37. Olay Bittiğinde Süreç Bitmez

Örneğin:

yetkisiz kişi otele girdi.

Personel fark etti.

Kişi çıktı.

İlk bakışta:

olay sona erdi.

Ama profesyonel süreç:

Incident Report → CCTV Review → Access Record Review → Witness / Staff Information → Risk Analysis → Root Cause → CAPA → SOP Revision → Staff Briefing

şeklinde devam etmelidir.

38. Root Cause Analysis Güvenlikte Neden Önemlidir?

Soru:

“Yetkisiz kişi neden içeri girdi?”

Cevap:

“Kapı açıktı.”

Bu:

kök neden olmayabilir.

Neden kapı açıktı?

Personel mal kabul yapıyordu.

Neden kapı kontrolsüz kaldı?

Kapının otomatik kapanma mekanizması yoktu.

Neden prosedür bunu yönetmiyordu?

Servis giriş SOP'sinde güvenlik kontrolü tanımlanmamıştı.

Kök neden:

sistem tasarımı

olabilir.

39. 5 Why Kullanılabilir

Örneğin:

Neden olay oldu?

Yetkisiz kişi personel alanına girdi.

Neden?

Kapı açıktı.

Neden?

Personel kapıyı açık bıraktı.

Neden?

Mal taşıyordu.

Neden?

Servis girişinde kontrollü geçiş sistemi yok.

Bu analiz:

“çalışan hata yaptı”

seviyesinden:

“sistemde hangi kontrol eksik?”

seviyesine geçmemizi sağlar.

40. Corrective Action ile Preventive Action Ayrımı

Corrective Action

Mevcut problemi düzeltir.

Örneğin:

bozuk kapı kilidini tamir etmek.

Preventive Action

Benzer problemin tekrarını azaltır.

Örneğin:

• otomatik kapanma sistemi,
• günlük kapı kontrolü,
• servis giriş SOP'si,
• personel eğitimi.

İkisi birlikte:

CAPA — Corrective and Preventive Action

sistemini oluşturur.

41. CAPA Açmak Yetmez

CAPA tablosunda:

• Problem
• Root Cause
• Action
• Owner
• Deadline
• Status
• Verification

bulunmalıdır.

En önemli nokta:

CAPA'nın açılması değil, gerçekten kapatılmasıdır.

Aksiyon yazılıp:

üç ay sonra hâlâ yapılmadıysa:

risk devam etmektedir.

42. Near Miss Nedir?

Near Miss:

Ramak Kala

olayıdır.

Yani:

gerçek bir zarar oluşmamıştır.

Ama oluşabilirdi.

Örneğin:

zemin çok kaygan.

Personel fark etti.

Kimse düşmeden alan kapatıldı ve temizlendi.

Kaza yoktur.

Ama:

potansiyel olay vardır.

Bu kayıt çok değerlidir.

43. Near Miss Neden Incident Kadar Değerlidir?

Çünkü:

olay gerçekleşmeden:

sistemdeki zayıflığı gösterir.

Örneğin:

yetkisiz kişi personel alanına girmeye çalıştı.

Resepsiyon fark etti.

İçeri giremedi.

Hiçbir zarar olmadı.

Ama soru:

“Nasıl bu noktaya kadar gelebildi?”

olmalıdır.

Near Miss:

bedel ödemeden öğrenme fırsatıdır.

44. Near Miss Sayısının Artması Her Zaman Kötü Değildir

Bir ay:

2 Near Miss.

Sonraki ay:

15 Near Miss.

Bu:

güvenliğin kötüleştiği anlamına gelmeyebilir.

Belki personel:

raporlamaya başlamıştır.

Bu nedenle güvenlik KPI'ları:

bağlam içinde okunmalıdır.

Amaç:

sıfır kayıt değil, daha az gerçek risk ve daha güçlü raporlama kültürüdür.

45. Personel Olay Bildirmekten Korkmamalıdır

Eğer çalışan:

“Bunu bildirirsem beni suçlarlar.”

diye düşünüyorsa:

olaylar saklanmaya başlayabilir.

Bu:

çok tehlikelidir.

Yönetimin mesajı:

“Olayı bildirmek problem değildir; ciddi olayı saklamak ve aynı riskin tekrarına izin vermek problemdir.”

olmalıdır.

46. Güvenlik Kültürü Nedir?

Security Culture:

personelin:

kimse kontrol etmese bile

risk gördüğünde:

• fark etmesi,
• müdahale etmesi,
• bildirmesi,
• kayıt açması

davranışıdır.

Örneğin Housekeeping çalışanı:

acil çıkışın önünde malzeme gördü.

“Güvenlik departmanı ilgilensin.”

dememelidir.

Riskin giderilmesini başlatmalıdır.

47. Acil Durum ile Güvenlik Olayı Aynı Şey Değildir

Her Incident:

Emergency değildir.

Örneğin:

kayıp eşya:

Incident olabilir.

Ama Emergency değildir.

Yangın:

hem Incident

hem Emergency olabilir.

Büyük deprem:

Emergency'nin ötesinde:

Crisis

haline gelebilir.

Bu ayrım:

doğru yönetim seviyesini belirler.

48. Otelde Temel Acil Durum Senaryoları

Otelin yapısına göre en azından:

• yangın,
• deprem,
• ciddi sağlık olayı,
• elektrik kesintisi,
• su baskını,
• gaz / teknik risk,
• tahliye,
• havuz acil durumu,
• kayıp çocuk,
• ciddi güvenlik olayı,
• aşırı hava koşulları

gibi senaryolar değerlendirilmelidir.

Ama:

internetten 50 SOP indirip klasöre koymak acil durum sistemi değildir.

Prosedür:

otelin gerçek binasına,

ekibine,

risklerine

ve operasyonuna göre tasarlanmalıdır.

49. Acil Durum SOP'si Nasıl Olmalı?

Bir çalışan:

kriz sırasında:

20 sayfalık prosedür okumaz.

Acil durum SOP'si:

net olmalıdır.

Örneğin:

Event

Ne oldu?

Immediate Safety

İlk güvenlik aksiyonu nedir?

Alarm / Notification

Kim bilgilendirilecek?

Escalation

Kim yönetimi devralacak?

External Support

Hangi dış destek gerekli?

Guest Communication

Misafire kim bilgi verecek?

Documentation

Hangi kayıt açılacak?

Recovery

Normal operasyona nasıl dönülecek?

50. Acil Durum İletişim Listesi Hazır Olmalıdır

Kriz sırasında:

telefon numarası aramak

zaman kaybettirebilir.

Liste:

• yöneticiler,
• teknik sorumlular,
• güvenlik,
• ilgili acil hizmetler,
• kritik tedarikçiler

gibi operasyon için gerekli temasları içerebilir.

Liste:

güncel tutulmalıdır.

Eski telefon numarası:

acil durumda işe yaramaz.

51. Emergency Contact List'in Yedeği Olmalıdır

Liste yalnızca:

bir bilgisayarın içinde bulunmamalıdır.

Elektrik veya sistem problemi olduğunda:

erişilemeyebilir.

Otel:

kendi riskine göre:

• dijital,
• kontrollü basılı,
• yönetici erişimi

gibi yedek yöntemler planlayabilir.

Acil durum sistemi, normal sistem çalışmadığında da çalışabilmelidir.

52. Yangın Olayında Temel Mantık

Yangın senaryosu otelin özel prosedürüne göre yönetilmelidir.

Operasyonel akış genel olarak:

Alarm → Emergency Procedure → Life Safety → Evacuation if required → External Authorities → Management → Guest Communication → Incident / Crisis Documentation

şeklinde düşünülebilir.

Burada:

mal güvenliğinden önce insan güvenliği

gelir.

53. Elektrik Kesintisi de Guest Safety Konusudur

Elektrik kesintisi:

yalnızca teknik arıza değildir.

Etkileyebilir:

• aydınlatma,
• asansör,
• elektronik kilit,
• CCTV,
• internet,
• POS,
• su sistemleri,
• HVAC,
• misafir iletişimi.

Dolayısıyla:

Technical + Security + Front Office + Management

ortak senaryosudur.

54. Su Baskını Örneği

Temel akış:

Detect → Source Control if safe → Area Safety → Technical → Electrical Risk Check → Management → Guest / Room Impact → Recovery → Incident Report → Root Cause → CAPA

olabilir.

Ama personel:

kendi güvenliğini tehlikeye atacak müdahaleye zorlanmamalıdır.

55. Sağlık Olaylarında İlk Öncelik İnsan Güvenliğidir

Misafir veya çalışan:

ciddi sağlık problemi yaşıyor.

Öncelik:

rapor yazmak değildir.

Öncelik:

uygun acil yardım sürecini başlatmaktır.

Sonra:

• alan kontrolü,
• yönetim bilgilendirmesi,
• gerekli iletişim,
• olay kaydı

gelir.

Bu nedenle:

Document hiçbir zaman Life Safety'nin önüne geçmemelidir.

56. Crisis Log Nedir?

Bazı olaylar:

çok hızlı gelişir.

İlk bilgi:

eksik olabilir.

Yeni bilgiler:

dakika dakika gelir.

Bu durumda:

Crisis Log

kullanılabilir.

Crisis Log:

krizin zaman çizelgesi + karar kaydı + iletişim hafızasıdır.

Incident Report'tan farklıdır.

57. Crisis Log ile Incident Report Farkı

Basit ifade:

Crisis Log = canlı kayıt

Incident Report = olay sonrası analiz

58. Crisis Log Ne Zaman Açılmalı?

Her küçük olay için gerekmez.

Ama örneğin:

• yangın,
• deprem,
• büyük elektrik kesintisi,
• ciddi su baskını,
• tahliye,
• kayıp çocuk,
• büyük güvenlik olayı

gibi durumlarda kullanılabilir.

Otel:

Incident Severity Matrix ile:

hangi seviyede Crisis Log açılacağını

önceden belirlemelidir.

59. Crisis Log Owner Olmalıdır

Kriz sırasında:

herkes ayrı kayıt tutarsa:

bilgi karmaşası oluşabilir.

Bir:

Crisis Log Owner

belirlenebilir.

Büyük olaylarda:

Scribe — Kayıt Sorumlusu

atanabilir.

Crisis Manager:

karar verir.

Scribe:

kararı ve zamanı kaydeder.

Bu ayrım:

çok değerlidir.

60. Crisis Log Örneği

Birkaç saat sonra:

“Tam olarak ne zaman ne olmuştu?”

sorusunun cevabı bellidir.

61. Krizde “Bilgi” ile “Karar” Ayrılmalıdır

Örneğin:

Bilgi

“Bodrum katta su seviyesi yükseliyor.”

Karar

“Bodrum kat kullanıma kapatılacak.”

Bunlar farklı şeylerdir.

Aynı şekilde:

Known

ve:

Unknown

ayrımı yapılabilir.

Örneğin:

Bilinen:

ana elektrik beslemesi kesildi.

Bilinmeyen:

şebekenin ne zaman döneceği.

Bu:

tahminlerin gerçek bilgi gibi yayılmasını önler.

62. Krizde Tek İletişim Kaynağı Önemlidir

Bir çalışan:

“10 dakikaya elektrik gelir.”

Başka çalışan:

“İki saat sürebilir.”

diyorsa:

misafir güveni azalır.

Bu nedenle ciddi olaylarda:

Single Source of Truth

mantığı kullanılmalıdır.

Bilgi:

doğrulanır.

Sonra:

tutarlı biçimde paylaşılır.

63. Kriz İletişimi de Operasyonun Parçasıdır

Misafir:

her teknik detayı bilmek zorunda değildir.

Ama şunları bilmek ister:

• ne oldu?
• güvende miyim?
• ne yapmam gerekiyor?
• ne zaman yeni bilgi gelecek?

Bu nedenle iletişim:

kısa,

doğru,

doğrulanmış,

sakin

olmalıdır.

64. Bilmediğiniz Şeyi Tahmin Etmeyin

Krizde:

“Elektrik 15 dakika içinde kesin gelir.”

demek

ama bunu bilmiyor olmak:

güven kaybettirir.

Daha doğru:

“Teknik ekip müdahale ediyor. Şu anda kesin dönüş süresi belli değil. 20 dakika içinde size yeni bilgi vereceğiz.”

olabilir.

Belirsizliği doğru yönetmek, yanlış kesinlik vermekten daha profesyoneldir.

65. Tatbikat Neden Yapılır?

SOP'nin kağıt üzerinde çalışması:

sahada çalışacağı anlamına gelmez.

Tatbikat:

şunları test eder:

• personel prosedürü biliyor mu?
• iletişim zinciri çalışıyor mu?
• ekipman erişilebilir mi?
• tahliye akışı mantıklı mı?
• kim karar veriyor?
• kayıt tutuluyor mu?

Amaç:

personeli sınamak değil, sistemi sınamaktır.

66. Tabletop Exercise Nedir?

Her tatbikat:

tam tahliye olmak zorunda değildir.

Yönetim ekibine senaryo verilebilir:

“Saat 02:15. Otoparkta şüpheli hareket bildirildi. CCTV görüntüsünde bir kişi görülüyor. Gece vardiyasında iki çalışan var. Ne yapıyoruz?”

Ekip:

adım adım karar verir.

Bu:

Tabletop Exercise

olarak kullanılabilir.

Düşük maliyetli ama öğretici bir yöntemdir.

67. Tatbikattan Sonra Ne Yapılmalı?

Tatbikat bitti.

Fotoğraf çekildi.

Personel dağıldı.

Bu yeterli değildir.

Sorulmalıdır:

• ne iyi çalıştı?
• ne çalışmadı?
• kim neyi bilmiyordu?
• hangi ekipman eksikti?
• hangi SOP belirsizdi?
• hangi iletişim gecikti?

Sonra:

Lessons Learned → CAPA → SOP Revision → Training

yapılmalıdır.

68. Güvenlik Dokümantasyonu

Minimum sistemde:

Security Log

Günlük güvenlik kayıtları.

Incident Register

Tüm olayların ana listesi.

Incident Report

Önemli olayların detaylı raporu.

Near Miss Log

Ramak kala olaylar.

Key Log

Anahtar hareketleri.

CCTV Incident Log

Kamera ile ilişkili olaylar.

Emergency Drill Log

Tatbikat kayıtları.

Training Log

Eğitim kayıtları.

CAPA Log

Düzeltici ve önleyici aksiyonlar.

Crisis Log

Ciddi olayların canlı zaman çizelgesi.

bulunabilir.

Amaç:

bürokrasi üretmek değil, sistem hafızası yaratmaktır.

69. Incident Register ile Incident Report Aynı Şey Değildir

Incident Register:

özet listedir.

Örneğin:

Incident Report ise:

tek olayın:

detaylı analizidir.

Bu ayrım:

çok sayıda olayı yönetmeyi kolaylaştırır.

70. Olay Sonrası 5 Dosyalı Sistem

Ciddi olay için:

1. Incident Register

Olayın ana kaydı.

2. Incident Report

Ne oldu?

3. Root Cause Analysis

Neden oldu?

4. CAPA

Ne değiştireceğiz?

5. Lessons Learned

Sistem ne öğrendi?

Bu yapı:

olayı rapordan iyileştirmeye taşır.

71. Incident Report'un En Değerli Sorusu

Raporun sonunda şu soru bulunmalıdır:

“Bir daha olmaması için neyi değiştireceğiz?”

Cevap:

• hiçbir şey,
• eğitim,
• SOP,
• ekipman,
• fiziksel yatırım,
• Access Control,
• personel planlaması,
• teknoloji

olabilir.

Ama:

soru mutlaka sorulmalıdır.

72. Güvenlik KPI'ları

Güvenlik de ölçülebilir.

Örneğin:

Incident

• Total Incidents
• Serious Incidents
• Guest Safety Incidents
• Staff Safety Incidents.

Near Miss

• Near Miss Count
• Repeat Near Miss.

Response

• Average Response Time
• Emergency Response Time.

Systems

• CCTV Uptime
• Critical Camera Downtime
• Electronic Lock Failures
• Fire System Faults.

Training

• Security Training Completion
• Drill Participation.

Improvement

• Open CAPA
• Overdue CAPA
• Closed CAPA
• Repeat Incident Rate.

Ama KPI:

rapor üretmek için değil, sistemin gerçekten çalışıp çalışmadığını görmek için kullanılmalıdır.

73. CCTV Uptime Örneği

Formül:

CCTV Uptime = Çalışan Kamera Süresi / Planlanan Kamera Süresi × 100

Ama genel oran:

%99

olabilir.

Kritik giriş kamerası:

3 gündür çalışmıyor olabilir.

Bu nedenle:

kritik ekipman ayrı takip edilmelidir.

Ortalama bazen riski gizleyebilir.

74. Repeat Incident Rate Neden Önemlidir?

Bir olay:

tesadüf olabilir.

Aynı olay:

beş kez tekrar ediyorsa:

sistem problemi olabilir.

Örneğin:

aynı arka kapıdan:

tekrar tekrar yetkisiz giriş riski oluşuyor.

Her seferinde:

Incident Report yazmak yeterli değildir.

Artık:

kalıcı kontrol gerekir.

75. Güvenlik Dashboard'u

Örneğin:

Yönetici:

30 saniyede:

nerede risk biriktiğini

görebilir.

76. Güvenlik KPI'larını Yanlış Kullanmayın

Yönetim:

“Bu ay Incident sayısı arttı, kötü.”

diyebilir.

Ama:

personel daha fazla olay kaydetmeye başlamış olabilir.

Tersi:

Incident:

0.

Bu:

mükemmel güvenlik anlamına gelmeyebilir.

Belki:

kimse kayıt açmıyordur.

Dolayısıyla:

Incident + Near Miss + Reporting Culture + Repeat Incident + CAPA

birlikte okunmalıdır.

77. Güvenlik Sisteminin Periyodik Yönetimi

Günlük

• kritik sistem kontrolleri,
• girişler,
• CCTV,
• açık olaylar.

Haftalık

• Security Walkthrough,
• teknik güvenlik kontrolü,
• açık aksiyonlar.

Aylık

• Incident,
• Near Miss,
• KPI,
• CAPA,
• trend analizi.

Sezon Öncesi

• tam güvenlik denetimi,
• eğitim,
• tatbikat,
• risk değerlendirmesi.

Sezon Sonrası

• Lessons Learned,
• yatırım ihtiyaçları.

Ciddi Olay Sonrası

• Crisis Log,
• Incident Report,
• Root Cause,
• CAPA,
• SOP revizyonu.

Böylece güvenlik:

yılda bir kontrol edilen dosya olmaktan çıkar.

78. Güvenlik Yatırımı Nasıl Önceliklendirilir?

Yatırımcı:

“Daha fazla kamera alalım.”

demeden önce:

şunlara bakmalıdır:

Risk

En büyük risk nedir?

Existing Control

Şu anda hangi kontrol var?

Gap

Nerede açık var?

Incident Data

Geçmişte ne yaşandı?

Near Miss

Ne olmak üzereydi?

CAPA

Hangi aksiyonlar açık?

Cost

Risk azaltmanın maliyeti ne?

Böylece:

güvenlik CAPEX'i ekipman isteğinden risk bazlı yatırım kararına dönüşür.

79. Incident Data CAPEX Kararına Dönüşebilir

Örneğin:

arka bahçede:

sürekli Near Miss ve yetkisiz giriş riski var.

Analiz:

• aydınlatma yetersiz,
• kamera kör noktada,
• kapı kontrolsüz.

Çözüm:

• yeni aydınlatma,
• Access Control,
• CCTV repositioning

olabilir.

Bu:

Incident → Analysis → CAPEX

dönüşümüdür.

80. Güvenlikte 15 Büyük Hata

1. Güvenliği yalnızca kamera sanmak

2. Risk Assessment yapmamak

3. Günlük güvenlik kontrolü yapmamak

4. Kritik kapıları kontrolsüz bırakmak

5. Master Key hareketlerini izlememek

6. Ayrılan personelin erişimini açık bırakmak

7. CCTV'nin kayıt yaptığını kontrol etmemek

8. Gece vardiyasını güvenlik eğitimi olmadan bırakmak

9. Olayları yalnızca sözlü aktarmak

10. Incident Report hazırlamamak

11. Near Miss kaydetmemek

12. Personeli olay bildirdiği için suçlamak

13. Root Cause yapmadan olayı kapatmak

14. CAPA açıp kapanışını takip etmemek

15. Tatbikat yapmadan SOP'nin çalışacağını varsaymak

Bu hataların ortak sonucu:

güvenliğin sistem yerine kişilere ve şansa bağlı kalmasıdır.

81. Güvenlik İçin 15 Karar Kapısı

Karar Kapısı 1

Otelin Risk Register'ı var mı?

Karar Kapısı 2

Kritik riskler belirlenmiş mi?

Karar Kapısı 3

Her kritik riskin Owner'ı var mı?

Karar Kapısı 4

Daily Security Checklist uygulanıyor mu?

Karar Kapısı 5

Gece güvenlik prosedürü var mı?

Karar Kapısı 6

Access Control yetkileri belli mi?

Karar Kapısı 7

Master Key izleniyor mu?

Karar Kapısı 8

CCTV gerçekten kayıt yapıyor mu?

Karar Kapısı 9

Incident Severity tanımlı mı?

Karar Kapısı 10

Escalation Chain belli mi?

Karar Kapısı 11

Incident Report standart mı?

Karar Kapısı 12

Near Miss kaydı tutuluyor mu?

Karar Kapısı 13

Ciddi olaylarda Root Cause yapılıyor mu?

Karar Kapısı 14

CAPA kapanışı doğrulanıyor mu?

Karar Kapısı 15

Sistem düzenli tatbikatlarla test ediliyor mu?

Bu soruların çoğuna:

“Evet.”

cevabı verilemiyorsa:

güvenlik ekipmanı olabilir ama güvenlik yönetim sistemi henüz tamamlanmamıştır.

82. Butik Otel İçin Minimum Güvenlik Dosyası

Küçük otelde yüzlerce prosedür gerekmeyebilir.

Ama minimum sistem:

1. Security Philosophy
2. Risk Register
3. Risk Matrix
4. Daily Security Checklist
5. Night Security Checklist
6. Access Control Matrix
7. Key / Master Key Log
8. CCTV Control Checklist
9. Visitor Procedure
10. Suspicious Person SOP
11. Lost & Found SOP
12. Emergency Contact List
13. Fire Emergency SOP
14. Evacuation SOP
15. Earthquake SOP
16. Medical Emergency SOP
17. Technical Emergency SOP
18. Incident Register
19. Incident Report
20. Near Miss Log
21. Crisis Log
22. Root Cause Analysis
23. CAPA Log
24. Training Log
25. Drill Log
26. Security KPI Dashboard

ile kurulabilir.

Bu:

butik otelin güvenlik yönetim omurgası

olabilir.

83. Güvenlik Sisteminin Tam Döngüsü

Profesyonel güvenlik sistemi:

Security Philosophy → Risk Assessment → Risk Register → Risk Matrix → Preventive Controls → Access Control → CCTV → Daily Security Check → Training → Drills → Detection → Immediate Safety → Notification → Escalation → External Support if Needed → Incident Register → Incident Report → Crisis Log if Required → Evidence Review → Root Cause → CAPA → Lessons Learned → SOP Revision → Training / Equipment / CAPEX → Updated Risk Register → Stronger Security System

Bu döngü kapanıyorsa:

otel yalnızca güvenlik olaylarına müdahale etmiyor; her olaydan sonra daha güvenli hale geliyor demektir.

84. Otel Yatırımcısı İçin 30 Saniyelik Güvenlik Dashboard'u

Yatırımcının her Incident Report'u günlük okumasına gerek olmayabilir.

Ama şu sekiz göstergeyi düzenli görmesi güçlü bir başlangıçtır:

1. Serious Incidents

Ciddi olay yaşandı mı?

2. Near Miss

Hangi riskler gerçekleşmeden yakalandı?

3. Repeat Incidents

Aynı olay tekrar ediyor mu?

4. Critical System Status

CCTV, kilit, yangın ve diğer kritik sistemler çalışıyor mu?

5. Emergency Response

Kritik olaylara ne kadar hızlı müdahale ediliyor?

6. Training & Drills

Personel gerçekten hazır mı?

7. Open / Overdue CAPA

Bilinen risklerden hangileri hâlâ kapatılmadı?

8. Security CAPEX

Hangi fiziksel veya teknolojik yatırım gerekiyor?

Yatırımcının olay raporuna bakarken sorması gereken soru yalnızca:

“Ne oldu?”

olmamalıdır.

Daha değerli soru:

“Bu olay bize sistem ve yatırım açısından ne öğretti?”

olmalıdır.

Sonuç: Güvenlik Olay Olduğunda Başlayan Bir İş Değildir

Zayıf güvenlik sistemi:

olay olur.

Personel müdahale eder.

Yönetici aranır.

Olay biter.

Hayat devam eder.

Bir süre sonra:

aynı olay tekrar olur.

Güçlü güvenlik sistemi ise:

riski önceden tanımlar.

önleyici kontrol kurar.

günlük olarak kontrol eder.

çalışanları eğitir.

tatbikat yapar.

olayı hızlı tespit eder.

doğru kişiyi bilgilendirir.

Incident Report oluşturur.

Near Miss'i bile kaydeder.

Root Cause araştırır.

CAPA açar.

aksiyonun gerçekten kapandığını doğrular.

SOP'yi değiştirir.

gerekiyorsa yatırım yapar.

Ve:

aynı olayın tekrar etme ihtimalini azaltır.

Bu nedenle güvenliğin en önemli çıktısı:

kameraların duvarda olması değildir.

Incident Report klasörünün dolu olması da değildir.

Asıl çıktı:

misafirin, personelin ve işletmenin daha düşük risk altında çalışmasıdır.

Bir otelin gerçek güvenlik seviyesi:

kriz olmadığı günlerde yaptığı hazırlıkla belirlenir.

Çünkü kriz başladığında:

yeni bir sistem kurmak için artık çok geç olabilir.

İyi yönetilen otel:

“Bir şey olursa ne yaparız?”

diye düşünmekle yetinmez.

Şunu önceden belirler:

“Ne olabilir, bunu nasıl önleriz, olursa ilk kim ne yapar, kim bilgilendirilir, nasıl kayıt altına alınır ve bir daha olmaması için neyi değiştiririz?”

İşte bu soruların cevapları:

gerçek bir otel güvenlik sistemini oluşturur.

Otel Yatırım Rehberi — Cilt V

Bu makale, Otel Yatırım Rehberi — Cilt V: Operasyon kapsamında ele aldığım Güvenlik ve Acil Durum Yönetimi yaklaşımından hazırlanmıştır.

Cilt V'te otel güvenliği;

• Security Philosophy,
• Risk Register,
• Risk Matrix,
• Guest / Staff Safety,
• Access Control,
• Key & Master Key Management,
• CCTV,
• Night Security,
• Suspicious Person,
• Lost & Found,
• Emergency Management,
• Evacuation,
• Crisis Communication,
• Incident Report,
• Crisis Log,
• Near Miss,
• Root Cause,
• CAPA,
• Security KPI,
• tatbikatlar,
• Lessons Learned

ile birlikte bütünsel bir güvenlik yönetim sistemi içinde ele alınmaktadır.