Otellerde Kriz Yönetimi Nasıl Kurulur? Risk, Hazırlık ve Business Continuity Rehberi

Bir otelde kriz yönetimi, yangın çıktığında yangın tüpünü nereden alacağınızı bilmekten çok daha geniş bir yönetim sistemidir. Çünkü modern bir otel aynı anda insan, bina, elektrik, su, gıda, teknoloji, veri, ödeme sistemleri, tedarikçiler, çalışanlar, rezervasyonlar, nakit akışı ve marka itibarı yönetir. Bu sistemlerden herhangi birindeki ciddi bozulma yalnızca kendi alanında kalmayabilir; teknik bir problem operasyonel krize, operasyonel kriz finansal probleme, finansal problem de itibar krizine dönüşebilir.

Bu nedenle doğru soru yalnızca şu değildir:

“Kriz çıktığında ne yapacağız?”

Daha güçlü sorular şunlardır:

Ne yanlış gidebilir? Bunu nasıl önleyebiliriz? Önleyemezsek nasıl hazırlanacağız? Olay gerçekleştiğinde kim karar verecek? Kritik operasyonları nasıl sürdüreceğiz? Ne zaman normale döneceğiz? Ve krizden sonra sistemi nasıl daha güçlü hale getireceğiz?

Gerçek kriz yönetimi tam olarak bu soruların oluşturduğu yönetim sistemidir.

1. Otel Kriz Yönetimi Nedir?

Otel kriz yönetimi, işletmenin ciddi bir olay karşısında insan güvenliğini korumasını, olayın etkisini sınırlamasını, kritik operasyonları mümkün olduğu ölçüde devam ettirmesini, paydaş iletişimini yönetmesini ve işletmeyi kontrollü biçimde toparlamasını sağlayan sistemdir. Fakat kriz yönetimi kriz başladığında başlamaz. Asıl sistem şu döngüdür:

Önleme → Hazırlık → Müdahale → Toparlanma → Öğrenme

Kriz yönetimi mimarisi bu beş aşamayı birbirine bağlar; öğrenme tekrar önleme aşamasına dönerek sistemi sürekli geliştirir.

2. Problem, Incident, Emergency ve Crisis Aynı Şey Değildir

Otelde yaşanan her aksaklığı kriz olarak adlandırmak doğru değildir. Dört seviyeyi ayırmak yararlıdır.

Bu ayrım önemlidir çünkü şu şekilde bir büyüme zinciri oluşabilir:

Problem → Incident → Emergency → Crisis

Kriz yönetiminin görevlerinden biri de küçük olayların büyük krizlere dönüşmesini engellemektir.

3. Krizi Tanımlayan Yalnızca Olay Değil, Etkisidir

Aynı elektrik kesintisi iki otelde tamamen farklı sonuç yaratabilir. Birinci otelde jeneratör otomatik devreye girer, kritik aydınlatmalar çalışır, PMS için yedek prosedür vardır, resepsiyon misafirlere bilgi verir, teknik ekip hazırdır. Olay incident seviyesinde kalabilir. İkinci otelde:

• jeneratör çalışmaz,
• internet gider,
• PMS erişilemez,
• çalışanlar ne yapacağını bilmez,
• misafir listesine ulaşılamaz,
• ödeme sistemi durur.

Aynı elektrik kesintisi artık operasyonel krize dönüşebilir. Dolayısıyla:

Crisis Impact ≈ Event Severity × Organizational Vulnerability

Hazırlığın temel amacı olayın hiç gerçekleşmeyeceğini garanti etmek değil, organizasyonun kırılganlığını azaltmaktır. Hazırlıklı ve hazırlıksız iki otel aynı olaydan tamamen farklı sonuçlarla çıkabilir.

4. Risk Management ile Crisis Management Arasındaki Fark

Bu iki kavram bağlantılıdır ama aynı değildir. Risk Management şu soruyu sorar: “Ne yanlış gidebilir ve bunu nasıl önleyebiliriz?” Crisis Management ise “Önlememize rağmen ciddi olay gerçekleşirse ne yapacağız?” sorusunu sorar. Örneğin yangın riskinde:

• Risk Management: Elektrik tesisatının bakımı, yanıcı malzeme kontrolü.
• Preparedness: Alarm, tahliye planı, ekipman, eğitim.
• Response: Alarm, tahliye, misafir sayımı, acil servis koordinasyonu.
• Recovery: Hasar tespiti, oda kapasitesinin değerlendirilmesi, operasyonun yeniden kurulması.

Dolayısıyla tam sistem şöyle düşünülmelidir:

Prevention → Preparedness → Response → Recovery

5. İlk Adım: Risk Universe Oluşturmak

Bir otelin kriz planını yalnızca yangın, deprem ve sağlık acil durumu üzerine kurmak artık yeterli değildir. Risk evreni daha geniştir.

İnsan ve Güvenlik Riskleri

Yangın, yaralanma, sağlık acil durumu, kayıp çocuk, güvenlik olayı.

Bina ve Teknik Riskler

Elektrik, su, jeneratör, asansör, HVAC, yangın sistemi, yapı hasarı.

Operasyonel Riskler

PMS kesintisi, ödeme sisteminin çalışmaması, kritik personel eksikliği.

Gıda Riskleri

Gıda güvenliği, toplu rahatsızlık, soğuk zincir problemi.

Siber ve Veri Riskleri

Fidye yazılımı, phishing, veri ihlali, sistem erişim kaybı.

Tedarik Zinciri Riskleri

Kritik tedarikçinin hizmet verememesi, yakıt veya temel malzeme erişiminin kesilmesi.

Finansal Riskler

Nakit akışı problemi, uzun süreli kapanma, büyük refund yükü.

İtibar Riskleri

Viral sosyal medya olayı, ciddi online iddia, medya krizi.

Destinasyon Riskleri

Deprem, sel, şiddetli hava, bölgesel altyapı kesintisi, ulaşım problemi.

Modern otelde krizler çoğu zaman tek kategori içinde kalmaz. Örneğin siber saldırı PMS’yi durdurabilir, veri güvenliği sorununa dönüşebilir, rezervasyonları etkileyebilir ve ardından itibar ile finans problemleri yaratabilir.

6. Risk Register Kurun

Riskler yalnızca yöneticinin zihninde tutulmamalıdır. Basit bir Risk Register oluşturulabilir.

Risk Register’ın amacı yüzlerce satırlık bürokratik bir dosya oluşturmak değildir. Özellikle küçük otelde gerçekten yönetilen 15–25 kritik risk, kimsenin kullanmadığı yüzlerce risk kaydından daha değerlidir.

7. Risk = Yalnızca Olasılık × Etki Değildir

Klasik yaklaşım şöyledir:

Risk Score = Probability × Impact

Bu başlangıç için yararlıdır fakat tek başına yeterli değildir. Daha güçlü değerlendirme şunları da içerebilir:

• Probability — gerçekleşme olasılığı
• Impact — etkisinin büyüklüğü
• Velocity — ne kadar hızlı büyüyor?
• Detectability — ne kadar erken fark edilebilir?
• Dependency — başka hangi sistemler buna bağlı?
• Preparedness — bu riske ne kadar hazırız?

Risk önceliği yalnızca olasılık veya etkiye göre belirlenmemeli; hız, fark edilebilirlik, bağımlılık ve hazırlık seviyesi de dikkate alınmalıdır.

8. Risk Velocity Neden Önemlidir?

Bazı krizler yavaş gelişir. Örneğin nakit akışının bozulması. Bazıları ise dakikalar içinde büyür: yangın, veri ihlali, ciddi sağlık olayı, sosyal medyada viral güvenlik iddiası. Aynı finansal etkiye sahip iki riskten daha hızlı büyüyen risk için daha güçlü erken müdahale sistemi gerekebilir.

9. Detectability — Krizi Ne Kadar Erken Görebiliyoruz?

Bazı riskler erken sinyal verir. Örneğin:

• sık sık atan sigorta,
• tekrarlayan su kaçağı,
• jeneratör test başarısızlığı,
• phishing e-postalarının artması,
• ödeme terminalinde tekrarlayan kesintiler

Bu sinyaller göz ardı edilirse şu zincir oluşabilir:

near miss → incident → crisis

10. Küçük Otel, Küçük Risk Demek Değildir

Küçük işletmeler bazen “Biz altı odalı oteliz, büyük kriz yönetim sistemine ihtiyacımız yok.” diye düşünebilir. Fakat küçük otelde tek internet hattı, tek teknik personel, tek PMS, tek ödeme terminali, tek kritik tedarikçi olabilir. Üstelik altı odalı otelde iki odanın satış dışı kalması:

2 / 6 = %33,3 kapasite kaybı

demektir. 200 odalı otelde iki oda ise %1 kapasite kaybıdır. Dolayısıyla riskin büyüklüğü yalnızca mutlak rakamla değil, işletme üzerindeki oransal etkisiyle değerlendirilmelidir.

11. Crisis Management Plan Nedir?

Crisis Management Plan — CMP, ciddi olay gerçekleştiğinde şunları önceden tanımlayan yönetim yapısıdır:

• kimin karar vereceğini,
• hangi olayın hangi seviyede ele alınacağını,
• kimin kiminle iletişim kuracağını,
• kritik sistemlerin hangileri olduğunu,
• hangi alternatiflerin devreye gireceğini

Ama önemli bir ayrım vardır:

Crisis Management Plan ≠ Crisis Readiness

Bir PDF dosyasının bulunması işletmenin hazır olduğu anlamına gelmez.

12. Kriz Planı Bir Dosya Değil, Yetkinliktir

Gerçek hazırlık şunların birleşimidir:

Plan + İnsan + Yetki + İletişim + Kaynak + Yedeklilik + Eğitim + Tatbikat

Çalışan yangın alarmında ne yapacağını bilmiyorsa, gece vardiyası GM’ye ulaşamadığında kimin karar vereceğini bilmiyorsa, misafir listesi yalnızca çöken PMS’de bulunuyorsa, raftaki kriz planının pratik değeri sınırlıdır. Kriz planı organizasyonel refleks haline gelmelidir.

13. Crisis Management Plan Ne İçermeli?

Pratik bir CMP en azından şu başlıkları kapsayabilir:

1. Crisis governance
2. Incident classification
3. Activation thresholds
4. Crisis Management Team
5. Roles & responsibilities
6. Escalation matrix
7. Emergency contacts
8. Communication protocols
9. Critical systems
10. Business continuity procedures
11. Alternative suppliers
12. Offline procedures
13. Crisis playbooks
14. Recovery procedures
15. Training & drills
16. Incident reporting
17. After Action Review
18. Corrective action tracking

Amaç 300 sayfalık belge yazmak değil:

Kriz sırasında kullanılabilir bir sistem kurmaktır.

14. Activation Threshold Belirleyin

Her olayda kriz ekibini toplamak gerekmez. Bu nedenle önceden eşikler belirlenmelidir. Örneğin şunlar kriz escalation kriterleri olabilir:

• insan güvenliği riski,
• birden fazla misafirin etkilenmesi,
• kritik sistem kaybı,
• resmi kurum müdahalesi,
• önemli operasyon kesintisi,
• ciddi finansal etki,
• medya ilgisi,
• veri ihlali şüphesi

Böylece çalışan “Acaba bu ciddi mi?” diye kişisel yorum yapmak yerine belirlenmiş eşiklerden yararlanır.

15. Crisis Management Team Kurun

Belirli seviyenin üzerindeki olaylar tek kişinin yönetimine bırakılmamalıdır. Crisis Management Team — CMT oluşturulabilir. Büyük otelde fonksiyonlar:

Küçük otelde ayrı departmanlar olmayabilir. Ama:

Rol olmayabilir diye sorumluluk ortadan kalkmaz.

Aynı kişi birden fazla fonksiyon üstlenebilir. Küçük oteller için yalın fakat fonksiyonları tanımlanmış bir kriz ekibi modeli yeterlidir.

16. Primary ve Backup Owner Olmalı

Plan “Genel Müdür karar verir.” diyor. Peki GM şehir dışındaysa? Telefonuna ulaşılamıyorsa? Olaydan kendisi etkilenmişse? Bu nedenle kritik roller Primary + Backup şeklinde kurulmalıdır.

Hiçbir kritik fonksiyon tek kişinin varlığına bağımlı olmamalıdır.

17. Yetki Kriz Sırasında İcat Edilmemelidir

Kim tahliye kararı verebilir? Odaları satışa kapatabilir? Relocation başlatabilir? Önemli refund onaylayabilir? Medyaya açıklama yapabilir? Operasyonu kısmen durdurabilir? Dış teknik hizmet çağırabilir? Bu sorular olay başladıktan sonra tartışılmamalıdır.

Authority Before Emergency

kriz yönetiminin temel prensiplerinden biridir. Örnek escalation yapısında teknik arızadan yangın alarmına, ciddi yaralanmadan veri ihlaline kadar ilk yetkili ve escalation seviyeleri önceden tanımlanmalıdır.

18. Emergency Contact List Oluşturun

Liste yalnızca çalışan telefonlarından oluşmamalıdır. Şunları içerebilir:

• Crisis Management Team
• teknik servis
• elektrikçi
• jeneratör servisi
• IT sağlayıcısı
• güvenlik
• sigorta
• avukat
• sağlık kuruluşları
• kritik tedarikçiler

Ancak liste güncel değilse değeri yoktur. Bu nedenle şu döngü uygulanmalıdır:

Create → Verify → Update → Test

Ayrıca kritik iletişim bilgilerinin yalnızca internet bağlantısı gerektiren bir sistemde tutulması yeni bir bağımlılık yaratabilir; uygun offline erişim de düşünülmelidir.

19. Business Continuity Nedir?

Kriz yönetimi “Problemi nasıl çözeriz?” sorusunu sorar. Business Continuity ikinci soruyu ekler:

Problem çözülene kadar işletmenin kritik fonksiyonlarını nasıl sürdüreceğiz?

Bu ayrım çok önemlidir. Çünkü PMS’nin yeniden çalışması dört saat sürebilir. Ama misafirler şimdi check-in yapmak istiyor olabilir.

20. Otel Açık Olabilir Ama Operasyon Çalışmıyor Olabilir

Fiziksel kapının açık olması otelin gerçekten çalıştığı anlamına gelmez. Örneğin:

• elektrik var ama PMS yok,
• bina sağlam ama su yok,
• internet var ama ödeme sistemi çalışmıyor,
• odalar hazır ama rezervasyon sistemine erişilemiyor,
• fiziksel sistemler çalışıyor ama fidye yazılımı nedeniyle dijital sistemler kapalı

Bu nedenle Business Continuity, modern otel kriz yönetiminin merkezindedir.

21. Critical Business Functions Belirleyin

Her sistem eşit önemde değildir. İşletme şu soruyu sormalıdır:

Bu sistem olmadan ne kadar süre çalışabiliriz?

Kritik fonksiyonlar örneğin şunlar olabilir:

• misafir güvenliği,
• oda erişimi,
• elektrik,
• su,
• PMS,
• rezervasyon bilgileri,
• ödeme,
• iletişim,
• internet,
• yangın sistemleri,
• temel housekeeping,
• kritik F&B,
• çalışan iletişimi

22. Dependency Mapping Yapın

Bir operasyonun arkasındaki bağımlılıkları görünür hale getirin. Örneğin:

Check-In → PMS → Internet → Cloud Provider → User Credentials → Payment System → Door Lock System

Bu zincirde bir bağlantının kopması diğerlerini etkileyebilir. Business continuity bu nedenle yalnızca “Yedek jeneratörümüz var.” demek değildir.

23. Single Point of Failure Bulun

Şu soruyu sorun:

Bu tek şey çalışmazsa hangi operasyon tamamen duruyor?

Örneğin tek internet hattı, tek ödeme terminali, tek PMS erişim hesabı, tek teknik tedarikçi, tek anahtar kart programlama cihazı, tek kritik çalışan birer Single Point of Failure olabilir.

24. Minimum Viable Operation

Kriz sırasında hedef her zaman “Otel %100 normal çalışmaya devam etsin.” olmamalıdır. Bazı durumlarda bu mümkün değildir. Daha gerçekçi hedef şudur:

Minimum Viable Operation — MVO

Yani işletmenin güvenli ve kabul edilebilir biçimde sürdürebileceği minimum operasyon seviyesidir. Business continuity yaklaşımında amaç her koşulda normal operasyonu sürdürmek değil, güvenli minimum hizmet seviyesini korumaktır.

25. MVO İçin Sorulacak Sorular

Kriz sırasında şu soruların cevaplanması gerekir:

• kaç oda güvenle kullanılabilir?
• check-in yapılabilir mi?
• check-out yapılabilir mi?
• ödeme alınabilir mi?
• rezervasyon listesine erişiliyor mu?
• misafirlerle iletişim kurulabiliyor mu?
• oda anahtarları üretilebiliyor mu?
• su ve elektrik yeterli mi?
• hangi alanlar kapatılmalı?
• yeni rezervasyon kabul edilmeli mi?
• relocation gerekli mi?

26. Business Continuity Zinciri

Güçlü operasyon zinciri şöyledir:

Tespit Et → İzole Et → Sabitleştir → Yedeği Aktive Et → Kritik Operasyonları Sürdür → Onar → Geri Yükle → Doğrula

Bu model teknik, operasyonel ve siber krizlerde uygulanabilir.

27. Offline Procedures Hazırlayın

Dijital sistemlerin çalışmadığı senaryo özellikle test edilmelidir. Örneğin PMS yoksa:

• bugünkü arrivals nereden görülecek?
• in-house guest list nerede?
• room status nasıl izlenecek?
• check-in nasıl kaydedilecek?
• ödeme nasıl alınacak?
• oda değişiklikleri nasıl tutulacak?
• sistem geri geldiğinde manuel işlemler nasıl aktarılacak?

Bunların kriz sırasında ilk kez düşünülmemesi gerekir.

28. Offline Guest List

Özellikle kritik sistem bağımlılığında şu soru önemlidir:

PMS çalışmazsa otelde kimin kaldığını biliyor muyuz?

Bu yalnızca operasyon sorusu değildir. Acil durumda guest accountability açısından da önemlidir.

29. Backup Supplier Mantığı

Business continuity yalnızca teknoloji değildir. Örneğin kritik tedarikçiniz hizmet veremezse alternatifiniz var mı? Bu nedenle kritik tedarikçiler için şunlar tanımlanabilir:

• Primary Supplier
• Backup Supplier
• Emergency Contact
• Expected Response Time

30. Yedek Var mı Değil, Yedek Çalışıyor mu?

Jeneratör var. Ama en son ne zaman test edildi? Backup var. Ama restore edildi mi? İkinci internet hattı var. Ama gerçekten failover yapıyor mu? Bu nedenle:

Backup Exists ≠ Recovery Capability Exists

Yedek sistem test edilmedikçe gerçek hazırlık kanıtlanmış değildir.

31. İlk Öncelik İnsan Güvenliğidir

Kriz sırasında ilk soru “Otel ne kadar gelir kaybedecek?” olmamalıdır. İlk öncelik misafirlerin ve çalışanların güvenliğidir. Bu, kriz yönetiminin ilk başarısıdır.

32. İlk Dakikalarda Beş Soru

Ciddi olayda yönetim hızla şu soruları cevaplamalıdır:

1. Ne oldu?

Doğrulanmış bilgi nedir?

2. Kim etkileniyor?

Misafir, çalışan, bina, sistem?

3. İnsan güvenliği riski var mı?

Varsa öncelik değişir.

4. Olay büyüyor mu?

Stabil mi, kötüleşiyor mu?

5. Hangi sistemi aktive etmeliyiz?

Incident, emergency veya crisis?

33. Stabilization Önce Gelir

İlk hedef olayın büyümesini durdurmaktır. Örneğin:

• yangını izole etmek,
• suyu kesmek,
• etkilenen IT sistemini ağdan ayırmak,
• güvenli olmayan alanı kapatmak,
• satış envanterini kapatmak

Bu aşama Stabilization olarak düşünülebilir.

34. Crisis Playbook Kullanın

Kriz sırasında 200 sayfalık prosedür okunmaz. Bu nedenle kritik senaryolar için kısa Action Card / Crisis Playbook hazırlanabilir. Örneğin PMS kesintisinde:

1. Kesintiyi doğrula.
2. Siber olay ihtimalini değerlendir.
3. IT’yi bilgilendir.
4. Offline guest list’e geç.
5. Manuel check-in/out’u aktive et.
6. Alternatif ödeme planını kullan.
7. Misafir iletişimini başlat.
8. Recovery durumunu takip et.

Amaç düşünmeyi ortadan kaldırmak değil, yüksek stres altında kritik adımların unutulmasını engellemektir.

35. Command Center Mantığı

Büyük olayda bilgi dağılır. Resepsiyon başka bilgi alır. Teknik ekip başka şey söyler. Misafirler sosyal medyada başka şey paylaşır. Bu nedenle bir Single Coordination Point oluşturulmalıdır. Büyük işletmede fiziksel Crisis Room olabilir. Küçük otelde belirlenmiş ofis, telefon grubu veya dijital kriz kanalı olabilir. Amaç herkesin aynı güncel gerçeklik üzerinden hareket etmesidir.

36. Situation Report Oluşturun

Kriz boyunca kısa bir durum özeti tutulabilir:

Incident

Ne oldu?

Current Status

Şu anda durum ne?

People

Kim etkilendi?

Operations

Hangi hizmetler çalışıyor?

Closed Areas

Nereler kapalı?

Decisions

Hangi kararlar alındı?

Actions

Kim ne yapıyor?

Next Update

Bir sonraki değerlendirme ne zaman?

Bu yapı bilgi kirliliğini azaltır.

37. Decision Log Tutun

Kriz sırasında önemli kararlar kayıt altına alınmalıdır.

Bu kayıt daha sonra After Action Review için çok değerlidir.

38. Bilgi Eksikliği Sessizlik Gerekçesi Değildir

Krizde tüm cevaplar hemen bilinmeyebilir. Ama “Her şeyi bilmiyoruz.” ile “Hiç iletişim kurmayalım.” aynı şey değildir. Doğrulanmış bilgi paylaşılabilir:

“Teknik bir kesinti yaşıyoruz. Ekibimiz müdahale ediyor. Bir sonraki güncellemeyi 30 dakika içinde paylaşacağız.”

Bu yaklaşım belirsizliği yönetir.

39. Hızlı Ama Yanlış Bilgi Vermeyin

Kriz iletişiminde iki risk vardır: çok geç konuşmak ve doğrulamadan konuşmak. Bu nedenle şu ikisi birlikte yönetilmelidir:

Speed + Accuracy

40. Tek Sözcü Mantığı

Özellikle ciddi olaylarda her çalışanın, her yöneticinin, her sosyal medya hesabının ayrı açıklama yapması risklidir. Kim misafire, medyaya, resmi kurumlara, çalışanlara ve sosyal medyaya bilgi verecek önceden belirlenmelidir.

41. İç İletişim Dış İletişim Kadar Önemlidir

Çalışanlar doğru bilgiye sahip değilse misafirlere çelişkili mesaj verir. Bu nedenle şu zincir kurulmalıdır:

Internal Briefing → Consistent External Communication

42. Krizin Bitmesi ile İşletmenin Toparlanması Aynı An Değildir

Yangın söndü. Ama 12 oda kullanılamıyor olabilir. PMS geri geldi. Ama manuel işlemlerin sisteme aktarılması gerekebilir. Su geldi. Ama hijyen ve teknik kontroller tamamlanmamış olabilir. Bu nedenle:

Incident Contained ≠ Business Recovered

43. Recovery Plan

Toparlanma aşamasında yönetim şu başlıkları değerlendirebilir:

• insan güvenliği,
• bina durumu,
• oda envanteri,
• kritik sistemler,
• çalışan kapasitesi,
• gelecekteki rezervasyonlar,
• relocation,
• refund,
• tedarikçiler,
• finansal kayıp,
• sigorta,
• misafir recovery’si,
• itibar,
• yeniden açılış kriterleri

44. Normalleşme Kademeli Olabilir

Kriz sonrası işletme %0’dan %100’e bir anda dönmek zorunda değildir. Örneğin şu şekilde ilerleyebilir:

Closed → Limited Operation → Partial Operation → Normal Operation

Her aşamanın kriterleri önceden düşünülebilir.

45. Recovery Öncesi Doğrulama

Sistem “Çalışıyor.” demek yeterli olmayabilir. Soru şu olmalıdır:

Güvenli ve doğru çalıştığı doğrulandı mı?

Örneğin backup’tan PMS geri yüklendi. Ama rezervasyonlar doğru mu? Ödeme kayıtları eksik mi? Oda durumları güncel mi? Kontrol edilmelidir.

46. Krizden Sonra Eski Sisteme Dönmek Yeterli Değildir

İşletme normale döndü. Ama hiçbir prosedür değişmedi. Hiçbir bakım planı güncellenmedi. Kimse eğitim almadı. Risk Register değişmedi. Bu durumda otel krizi atlatmıştır ama krizden öğrenmemiştir. Olgun kriz yönetimi modeli bu nedenle şu zinciri kullanır: kriz → toparlanma → öğrenme → uyarlama → daha yüksek dayanıklılık.

47. After Action Review Yapın

Ciddi incident veya kriz sonrasında AAR — After Action Review yapılmalıdır. Dört temel soru:

Ne olmasını bekliyorduk?

Plan neydi?

Gerçekte ne oldu?

Olay nasıl gelişti?

Ne iyi/ne kötü çalıştı?

Hangi sistemler başarılıydı?

Bir daha neyi farklı yapacağız?

Amaç şudur:

Suçlu bulmak değil, sistemi anlamak.

48. Timeline Reconstruction

Olay sonrasında zaman çizelgesi oluşturmak son derece değerlidir.

Timeline “Kim suçlu?” sorusundan çok şu sorunun cevabıdır:

Karar sistemi nerede yavaşladı?

49. Root Cause Analysis

Örneğin jeneratör devreye girmedi. Sadece jeneratörü tamir etmek yeterli değildir. Şunlar sorulmalıdır:

• bakım periyodu doğru muydu?
• son test ne zaman yapıldı?
• yakıt seviyesi kontrol edildi mi?
• otomatik transfer sistemi çalışıyor muydu?
• test sorumlusu kimdi?
• başarısız test escalation edildi mi?

Teknik arıza böylece organizasyonel öğrenmeye dönüşür.

50. Corrective Action Sistemi

Her önemli bulgu için şu zincir kurulmalıdır:

Finding → Action → Owner → Deadline → Verification

Örneğin:

• Finding: Offline guest list yok.
• Action: Günlük güvenli offline liste prosedürü oluştur.
• Owner: Front Office Manager.
• Deadline: 15 gün.
• Verification: PMS outage drill sırasında test.

51. “SOP Yazıldı” Kapanış Değildir

Yeni SOP hazırlanmış olabilir. Ama çalışan bilmiyorsa risk devam eder. Bu nedenle doğru zincir şu olmalıdır:

Tasarla → Uygula → Eğit → Test Et → Doğrula → Kapat

Corrective action’ın ancak etkinliği doğrulandıktan sonra gerçekten kapatılmış sayılması önerilir.

52. Büyük Krizi Beklemeyin

Kurumsal öğrenme yalnızca büyük krizlerden başlamamalıdır. Örneğin:

• elektrik panosu sürekli sigorta atıyor,
• aynı noktada su kaçağı tekrarlanıyor,
• jeneratör testi bazen başarısız oluyor,
• çalışanlar sık phishing e-postası alıyor

Tek tek küçük görünürler. Birlikte systemic weakness gösterebilirler.

53. Incident Reporting Sistemi

Basit zincir şöyle kurulabilir:

Olay → Kaydet → Sınıflandır → Trend Analizi → Gerekiyorsa Escalate

Böylece yönetim büyük kriz oluşmadan önce kalıbı görebilir.

54. Near Miss Nedir?

Near Miss, ciddi sonuç doğurabilecek fakat şans veya zamanında müdahale nedeniyle doğurmamış olaydır. Örneğin elektrik panosu aşırı ısındı. Teknik ekip fark etti. Yangın çıkmadı. Yanlış sonuç “Bir şey olmadı.” demektir. Doğru sonuç şudur:

İşletme ücretsiz bir uyarı aldı.

Bu nedenle şu zincir kurulmalıdır:

Near Miss → Review → Learning → Prevention

55. Plan Test Edilmeden Plan Değildir

Kriz planının çalıştığı dosya okunarak anlaşılamaz. Test edilmelidir. Örneğin şunlar uygulanabilir:

• fire drill,
• PMS outage simulation,
• power failure drill,
• evacuation exercise,
• cyber tabletop exercise,
• emergency communication test,
• backup restore test

56. Tatbikatın Amacı Çalışanı Yakalamak Değildir

Tatbikat “Kim prosedürü bilmiyor?” avı olmamalıdır. Asıl soru şudur:

Sistem gerçekten çalışıyor mu?

Örneğin çalışan doğru hareket etmiş olabilir ama acil telefon listesi eski, yedek anahtar bulunamıyor, offline guest list yok, yetki belirsiz olabilir. Bunlar sistem problemidir.

57. Drill → Gap List

Her tatbikatın sonunda bir Gap List oluşmalıdır.

Tatbikatın değeri bulunan eksikliklerin kapatılmasıyla ortaya çıkar.

58. Kriz Yönetimi Kriz Olmadan Ölçülebilir

En önemli yönetim dönüşümlerinden biri budur. Kriz yönetiminin performansı yalnızca “Geçen kriz nasıl yönetildi?” ile ölçülmemelidir. Aynı zamanda şu soru ölçülmelidir:

Bugün kriz çıksa ne kadar hazırız?

59. Crisis Readiness Dashboard

Readiness dashboard’u bu yapıyla kriz öncesi hazırlığı görünür hale getirir.

60. Aktivite KPI ile Gerçek Hazırlığı Karıştırmayın

Training Completion %100 olabilir. Ama tatbikatta çalışanların yarısı ne yapacağını bilmiyorsa gerçek readiness %100 değildir. Bu nedenle:

Activity Metric ≠ Capability Metric

“Eğitim aldınız mı?” başka sorudur. “Gerçekten uygulayabiliyor musunuz?” başka sorudur.

61. Kriz Hazırlığı Maliyet Gibi Görünebilir

Jeneratör, UPS, yedek internet, yangın ekipmanı, sigorta, backup, siber güvenlik, eğitim ve tatbikat para harcatır. Üstelik bazıları yıllarca hiç kullanılmayabilir. Bu nedenle yönetim “Buna neden para harcıyoruz?” diye sorabilir.

62. Expected Loss Mantığı

Basitleştirilmiş model:

Expected Loss = Probability × Financial Impact

Örneğin düşük olasılıklı ama çok yüksek etkili bir olayda hazırlık yatırımı yine ekonomik olabilir. Ancak kriz yatırımlarında yalnızca finansal sonuç yoktur. Bazı olaylar şu gibi klasik ROI hesabına kolayca indirgenemeyen sonuçlar doğurabilir:

• insan hayatı,
• hukuki sorumluluk,
• işletme ruhsatı,
• marka itibarı

Kriz hazırlığı ekonomisinin kullanım sıklığı değil, kaçınılan kayıp üzerinden değerlendirilmesi önerilir.

63. Business Continuity Yatırım Kararı

Bir yedek sistemin değeri “Kaç kere kullandık?” sorusuyla ölçülmemelidir. Daha doğru soru şu olabilir:

Ana sistem kaybolduğunda ne kadar kaybı önleyebilir?

Bu bakış backup, redundancy, insurance ve preventive maintenance yatırımlarının ekonomik mantığını değiştirir.

64. 20 Crisis Management Karar Kapısı

Karar Kapısı 1

Otelin kritik riskleri tanımlandı mı?

Karar Kapısı 2

Risk Register güncel mi?

Karar Kapısı 3

Her kritik riskin owner’ı var mı?

Karar Kapısı 4

Incident / Emergency / Crisis ayrımı tanımlandı mı?

Karar Kapısı 5

Escalation thresholds belli mi?

Karar Kapısı 6

Crisis Management Team tanımlandı mı?

Karar Kapısı 7

Her kritik rolün backup’ı var mı?

Karar Kapısı 8

Karar yetkileri önceden tanımlandı mı?

Karar Kapısı 9

Emergency Contact List güncel mi?

Karar Kapısı 10

Kritik senaryolar için playbook var mı?

Karar Kapısı 11

Critical Business Functions belirlendi mi?

Karar Kapısı 12

Single Points of Failure belirlendi mi?

Karar Kapısı 13

Offline procedures mevcut mu?

Karar Kapısı 14

Backup sistemler gerçekten test edildi mi?

Karar Kapısı 15

Minimum Viable Operation tanımlandı mı?

Karar Kapısı 16

Kriz iletişimi sorumlusu belli mi?

Karar Kapısı 17

Incident ve Near Miss kayıt sistemi var mı?

Karar Kapısı 18

Tatbikat yapılıyor mu?

Karar Kapısı 19

After Action Review yapılıyor mu?

Karar Kapısı 20

Corrective actions gerçekten doğrulanarak kapatılıyor mu?

65. Otel Crisis Readiness Master Checklist

Risk Management

• Risk Universe oluşturuldu.
• Kritik riskler belirlendi.
• Risk Register mevcut.
• Probability değerlendirildi.
• Impact değerlendirildi.
• Velocity değerlendirildi.
• Detectability değerlendirildi.
• Dependencies belirlendi.
• Preparedness seviyesi ölçüldü.
• Risk owner’ları atandı.

Crisis Governance

• Incident seviyeleri tanımlandı.
• Activation thresholds tanımlandı.
• Escalation matrix oluşturuldu.
• Crisis Management Team kuruldu.
• Crisis Leader belli.
• Primary/backup roller tanımlandı.
• Yetki limitleri belli.
• Crisis communication owner belli.

Emergency Preparedness

• Emergency Contact List güncel.
• Offline kopyalar mevcut.
• Kritik playbook’lar hazır.
• Tahliye prosedürleri mevcut.
• Guest accountability sistemi var.
• Acil ekipmanlar kontrol ediliyor.
• Çalışan eğitimleri yapılıyor.

Business Continuity

• Critical Business Functions tanımlandı.
• Dependency Map oluşturuldu.
• Single Points of Failure belirlendi.
• Backup systems mevcut.
• Backup restore test edildi.
• Alternatif internet düşünüldü.
• Offline PMS prosedürü mevcut.
• Alternatif ödeme yöntemi mevcut.
• Backup supplier’lar belirlendi.
• Minimum Viable Operation tanımlandı.

Crisis Response

• İlk müdahale sorumluları belli.
• Stabilization prosedürü var.
• Command Center modeli tanımlandı.
• Situation Report formatı hazır.
• Decision Log formatı hazır.
• Misafir iletişim süreci tanımlandı.
• İç iletişim süreci tanımlandı.

Recovery

• Recovery criteria mevcut.
• Kademeli yeniden açılış düşünüldü.
• Gelecek rezervasyonların yönetimi planlandı.
• Relocation yaklaşımı var.
• Guest recovery sistemi var.
• Sigorta dokümantasyonu düşünülmüş.
• Sistem geri yükleme doğrulaması tanımlandı.

Organizational Learning

• Incident reporting var.
• Near miss reporting var.
• AAR prosedürü var.
• Timeline reconstruction yapılabiliyor.
• Root Cause Analysis yapılıyor.
• Corrective Action Register mevcut.
• Owner ve deadline belirleniyor.
• Aksiyonlar test ediliyor.
• Kapanış doğrulanıyor.
• Risk Register öğrenmelere göre güncelleniyor.

Testing

• Fire drill yapılıyor.
• Power outage senaryosu test ediliyor.
• PMS outage test ediliyor.
• Backup restore test ediliyor.
• Crisis communication test ediliyor.
• Gap List çıkarılıyor.
• Eksikler kapatıldıktan sonra retest yapılıyor.

66. Seviye 1 — Reactive

Kriz olduğunda herkes elinden geleni yapar. Sistem kişilere bağlıdır.

67. Seviye 2 — Documented

Plan ve prosedürler vardır. Fakat pratikte ne kadar çalıştığı bilinmez.

68. Seviye 3 — Prepared

Roller, yetkiler, playbook’lar ve yedek sistemler tanımlıdır.

69. Seviye 4 — Tested

Sistem tatbikatlarla test edilir. Eksiklikler görünür hale gelir.

70. Seviye 5 — Resilient

Risk, business continuity, crisis response ve recovery birlikte çalışır.

71. Seviye 6 — Learning Organization

Incident, near miss, tatbikat ve gerçek krizlerden öğrenilen bilgiler şu döngüye girer:

Risk Register → SOP → Eğitim → Teknik Sistem → CAPEX → Business Continuity → Yeni Test

Otel yalnızca krizleri yönetmez.

Her olaydan sonra daha dayanıklı hale gelir.

Sonuç: Kriz Yönetimi Kriz Anında Başlamaz

Güçlü kriz yönetimi yangın çıktığında, PMS çöktüğünde, deprem olduğunda, veri ihlali yaşandığında başlamaz. O anda yapılabileceklerin önemli bölümü daha önce verilmiş kararların sonucudur. Jeneratör daha önce test edilmiş midir? Backup gerçekten geri yüklenebilir mi? Çalışan kimin karar vereceğini biliyor mu? Misafir listesine offline erişilebilir mi? Alternatif tedarikçi var mı? Kriz liderine ulaşılamazsa backup kim? Kim açıklama yapacak? Hangi noktada relocation başlayacak? İşte kriz anındaki performansı bunlar belirler. Bu nedenle gerçek kriz yönetim zinciri şöyledir:

Riskleri Gör → Önle → Hazırlan → Yetkilendir → Test Et → Olayı Fark Et → Escalate Et → İnsanları Koru → Stabilize Et → Kritik Operasyonu Sürdür → İletişim Kur → Toparlan → İncele → Öğren → Sistemi Güçlendir

Bu yaklaşımın özü şudur:

İyi kriz yönetimi kriz sırasında kahramanlık göstermek değil, kriz gelmeden önce insanların ne yapacağını bildiği ve organizasyonun panikle değil sistemle hareket ettiği bir yapı kurmaktır.

Bir otelin gerçek dayanıklılığı hiç kriz yaşamamasıyla ölçülemez. Asıl soru şudur:

Beklenmeyen bir şey olduğunda bu işletme güvenliğini, karar verme kapasitesini ve kritik operasyonlarını ne kadar koruyabiliyor?

Ve kriz sona erdiğinde ikinci soru gelir:

Bu olaydan sonra işletme eski haline mi döndü, yoksa eskisinden daha güçlü mü hale geldi?

Gerçek kurumsal dayanıklılık ikinci sorunun cevabında ortaya çıkar.

Ayrıca okuyun: Otellerde Acil Durum ve Kriz Yönetimi Nasıl Kurulur? Yangın, Deprem, Tahliye ve Crisis Management Rehberi · Otellerde İş Sağlığı ve Güvenliği Yükümlülükleri Nelerdir? · Otel Kriz Planı Nasıl Hazırlanır? Acil Durum, Yetki, İletişim ve Crisis Team

Not: Bu içerik genel bilgilendirme amaçlıdır; hukuki, mali veya teknik tavsiye değildir. Mevzuat ve uygulamalar zamanla değişebilir. Karar vermeden önce ilgili alanda yetkin bir uzmandan (avukat, mali müşavir, mühendis vb.) görüş alın.

Otel Yatırım Rehberi — Cilt VIII

Bu makale Otel Yatırım Rehberi — Cilt VIII: Büyüme ve Sürdürülebilirlik kapsamında ele alınan kriz yönetimi, risk haritalama, Crisis Management Plan, Business Continuity, recovery ve kurumsal öğrenme sisteminden geliştirilmiştir.

Cilt VIII; misafir sadakati ve müşteri yaşam boyu değerinden kriz yönetimine, renovasyon ve CAPEX planlamasından ikinci otel, multi-property yönetimi ve sürdürülebilir otel markası kurmaya kadar işletmenin uzun vadeli dayanıklılığını ve büyüme kapasitesini sistem yaklaşımıyla ele alır.