Otel Kriz Planı Nasıl Hazırlanır? Acil Durum, Yetki, İletişim ve Crisis Team

Bir otelde kriz başladığında zaman farklı işler. Normal bir operasyon gününde birkaç saat boyunca değerlendirilebilecek bir kararın birkaç dakika içinde verilmesi gerekebilir. Bilgi eksiktir, çalışanlar farklı şeyler görür, misafirler cevap bekler, teknik ekip problemi çözmeye çalışır ve yönetimin aynı anda güvenlik, operasyon, iletişim ve finansal sonuçları düşünmesi gerekir. Tam da bu nedenle kriz anı şunun için en kötü zamandır:

“Kimin ne yapacağını belirlemek”

“Kimin karar vereceği?”, “Genel müdüre ulaşılamazsa yetki kimde olacak?”, “Misafirleri kim bilgilendirecek?”, “Hangi noktada kriz ekibi aktive edilecek?”, “Kim resmi kurumlarla konuşacak?”, “PMS çalışmazsa misafir listesine nasıl ulaşılacak?” gibi soruların cevapları kriz başlamadan önce verilmelidir.

İyi hazırlanmış bir Crisis Management Plan — CMP, işletmeye bütün krizlerin cevabını veren sihirli bir dosya değildir. Asıl amacı belirsizlik altında karar vermeyi kolaylaştıracak bir yönetim sistemi kurmaktır.

Kriz planı yalnızca ne yapılacağını değil; kimin, ne zaman, hangi yetkiyle, hangi bilgiye dayanarak ve kiminle koordinasyon içinde hareket edeceğini tanımlar.

1. Crisis Management Plan Nedir?

Crisis Management Plan, ciddi bir olay meydana geldiğinde işletmenin şunları yapmasını sağlayan yönetim çerçevesidir:

• olayı sınıflandırmasını,
• gerekli yönetim seviyesini aktive etmesini,
• insan güvenliğini korumasını,
• karar yetkisini belirlemesini,
• kriz ekibini organize etmesini,
• kritik operasyonları yönetmesini,
• iç ve dış iletişimi koordine etmesini,
• alınan kararları kaydetmesini,
• toparlanmayı başlatmasını

Kriz planının amacı bütün ihtimalleri tahmin etmek değildir. Bu mümkün de değildir. Ama işletme önceden şunları belirleyebilir:

Kim karar verecek? → Kim uygulayacak? → Kim bilgilendirilecek? → Ne zaman escalation yapılacak? → Hangi alternatif devreye alınacak? → Bilgi nerede toplanacak? → Kim iletişim kuracak?

Kriz planının gerçek değeri burada ortaya çıkar.

2. Önce Belge Değil, Yönetim Modeli Tasarlayın

Kriz planı hazırlanırken yapılan yaygın hatalardan biri doğrudan prosedür yazmaya başlamaktır. Yangın prosedürü. Deprem prosedürü. Elektrik kesintisi prosedürü. Siber saldırı prosedürü. Bunların hepsi gereklidir; fakat önce bütün senaryoların üzerinde çalışacak ortak yönetim mimarisi kurulmalıdır. Çünkü olay değişse bile bazı sorular değişmez:

• Olayın seviyesi nedir?
• Kim liderlik edecek?
• Kimler bilgilendirilecek?
• Hangi noktada kriz ekibi aktive olacak?
• Kim hangi kararı verebilir?
• Misafir iletişimini kim yönetecek?
• Operasyon devam edebilir mi?
• Bir sonraki değerlendirme ne zaman yapılacak?

Bu nedenle güçlü bir kriz planının temeli şu birleşimdir:

Scenario Procedures + Common Crisis Governance

3. Crisis Governance Nedir?

Crisis Governance, kriz sırasında karar verme sistemidir. Normal operasyonda organizasyon şeması yeterli olabilir. Ama kriz sırasında zaman daralır, bilgi eksilir, kararların etkisi büyür, normal departman sınırları birbirine karışır. Bu nedenle kriz yönetişimi normal organizasyon yapısının üzerine eklenen özel bir karar mekanizmasıdır. İyi bir governance modeli dört şeyi netleştirir:

Authority → Accountability → Escalation → Coordination

Yani: Kim yetkili? Kim sonuçtan sorumlu? Olay ne zaman üst seviyeye çıkacak? Departmanlar nasıl koordine olacak?

4. Her Sorun Kriz Değildir

Planın ilk bölümlerinden biri olay sınıflandırması olmalıdır. Pratik bir model dört seviyeden oluşabilir.

Amaç terminoloji yaratmak değil, farklı olaylara farklı yönetim seviyeleri uygulamaktır. Tek odadaki televizyon arızasıyla büyük deprem aynı karar sistemini aktive etmemelidir.

5. Incident Classification Neden Gereklidir?

Sınıflandırma yapılmazsa iki hata oluşabilir.

Under-Reaction

Ciddi olay küçük problem gibi yönetilir. Escalation gecikir.

Over-Reaction

Küçük olay gereksiz yere kriz seviyesine çıkarılır. Organizasyon sürekli alarm halinde çalışmaya başlar.

Bu nedenle plan olayın kendisini değil, etkisini değerlendirmelidir.

6. Crisis Activation Threshold Oluşturun

Çalışanların “Bu kriz mi değil mi?” diye kişisel yorum yapmasını azaltmak için aktivasyon kriterleri belirlenmelidir. Örneğin aşağıdaki durumlardan biri veya birkaçı varsa escalation düşünülebilir:

• insan güvenliği riski,
• ciddi yaralanma,
• birden fazla misafirin etkilenmesi,
• kritik operasyonun kaybı,
• uzun süreli elektrik veya su kesintisi,
• önemli oda kapasitesi kaybı,
• resmi kurum müdahalesi,
• ciddi veri güvenliği şüphesi,
• büyük finansal etki,
• yoğun medya ilgisi,
• viral sosyal medya olayı,
• otelin faaliyetini sürdürememe ihtimali

Buradaki temel prensip şu olmalıdır:

Activation by Criteria, Not by Personal Feeling

7. Escalation Ne Demektir?

Escalation, olayın mevcut yönetim seviyesinden daha yüksek bir karar seviyesine taşınmasıdır. Her olay doğrudan genel müdüre gitmemelidir. Ama bazı olaylar da alt seviyede gereğinden uzun tutulmamalıdır. Bu nedenle bir Escalation Matrix hazırlanabilir.

Bu yapı sayesinde olay sırasında “Kimi aramalıyım?” sorusunun cevabı önceden bellidir.

8. Escalation Sadece Olay Türüne Bağlı Olmamalıdır

Aynı olay farklı koşullarda farklı seviyeye çıkabilir. Örneğin internet kesintisi tek bir ofis bilgisayarını etkiliyorsa incident olabilir. Ama aynı kesinti PMS’yi, ödeme sistemini, rezervasyonları ve telefon sistemini etkiliyorsa kriz seviyesine yaklaşabilir. Bu nedenle escalation kriterleri şu unsurlar birlikte değerlendirilerek oluşturulmalıdır:

Type + Scale + Safety + Duration + Operational Impact + Reputation

9. Crisis Management Team Nedir?

Belirli seviyenin üzerindeki olayların tek kişinin omzuna bırakılması doğru değildir. Bunun yerine Crisis Management Team — CMT oluşturulur. CMT’nin amacı herkesin aynı anda karar vermesi değildir. Tam tersine:

Karar, bilgi ve uygulamanın organize edilmesidir.

10. Büyük Otelde Crisis Management Team

Daha büyük bir işletmede CMT şu fonksiyonlardan oluşabilir:

Ama bu tabloyu olduğu gibi her otele kopyalamak doğru değildir.

11. Küçük Otelde Crisis Management Team

Altı veya on odalı bağımsız bir otelde IT Director, Security Director, Communication Director ve Crisis Manager gibi ayrı pozisyonların bulunması gerçekçi değildir. Ama fonksiyonların ortadan kalktığı anlamına da gelmez. Örneğin:

Temel prensip şudur:

Departman olmayabilir; sorumluluk mutlaka olmalıdır.

12. Crisis Leader’ın Görevi Her İşi Yapmak Değildir

Kriz liderinin görevi yangını söndürmek, misafirlere tek tek açıklama yapmak, IT sistemini tamir etmek, tedarikçiyi aramak değildir. Asıl görevi bütün resmi görmek ve karar sistemini yönetmektir. Crisis Leader:

• öncelikleri belirler,
• olay seviyesini değerlendirir,
• gerekli ekipleri aktive eder,
• kritik kararları verir,
• çelişkili bilgileri değerlendirir,
• operasyon ile güvenlik arasındaki dengeyi yönetir,
• bir sonraki değerlendirme zamanını belirler

13. Crisis Leader Mikro Operasyona Gömülmemelidir

Kriz lideri “Jeneratörün hangi sigortası atmış?” sorusuna gömülürse, aynı anda misafir relocation, operasyon kapasitesi, çalışan güvenliği, medya iletişimi ve gelecek rezervasyonlar gibi büyük resmi kaçırabilir. Bu nedenle şu ayrım korunmalıdır:

Technical Problem Solving ≠ Crisis Leadership

14. “GM Karar Verir” Tek Başına Yeterli Değildir

Kriz planlarının klasik zayıflıklarından biri kilit kişi bağımlılığıdır. Plan şöyle yazılmış olabilir: “General Manager karar verir.” Peki GM otelde değilse, telefonu kapalıysa, uçaktaysa, hastanedeyse, olaydan kendisi etkilenmişse? Plan burada durmamalıdır.

15. Primary + Backup Sistemi

Her kritik rol için en az bir yedek tanımlanmalıdır.

Amaç Key Person Dependency riskini azaltmaktır. Kriz sisteminin kritik fonksiyonlarından hiçbiri tek kişinin varlığına bağlı olmamalıdır.

16. Backup Gerçekten Yetkili Olmalı

Kağıt üzerinde “GM yoksa Duty Manager karar verir.” yazmak yeterli değildir. Duty Manager gerçekten hangi kararları verebileceğini, hangi harcamayı onaylayabileceğini, hangi noktada oteli kısmen kapatabileceğini ve relocation başlatıp başlatamayacağını bilmelidir. Aksi halde backup vardır ama gerçek yetki yoktur.

17. Yetki Kriz Sırasında Pazarlık Konusu Olmamalıdır

Kriz sırasında şu diyaloglar yaşanmamalıdır: “Odaları satışa kapatabilir miyiz?” “Bunun için sahibin onayı gerekiyor mu?” “Misafiri başka otele gönderebilir miyiz?” “Refund verebilir miyiz?” “Sosyal medyada açıklama yapabilir miyiz?” Bu soruların kritik bölümü önceden cevaplanmalıdır.

18. Crisis Authority Matrix Örneği

Gerçek yetki yapısı otelin büyüklüğüne göre tasarlanmalıdır. Ama prensip değişmez:

Authority Must Exist Before Urgency.

19. Emergency Contact List Telefon Rehberi Değildir

İyi bir Emergency Contact List yalnızca çalışanların cep telefonu numaralarından oluşmaz. Şunları içerebilir:

Internal

• Crisis Leader
• GM
• Duty Manager
• Front Office
• Technical
• Security
• IT
• Finance
• HR

External

• elektrikçi
• jeneratör servisi
• tesisatçı
• IT provider
• PMS provider
• internet provider
• güvenlik firması
• sağlık kuruluşu
• sigorta
• avukat
• kritik tedarikçiler

20. Emergency Contact List Yaşayan Bir Dokümandır

Üç yıl önce işletmeden ayrılmış teknik sorumlunun telefon numarasının listede bulunması hiçbir işe yaramaz. Bu nedenle şu döngü uygulanmalıdır:

List → Verify → Update → Test → Repeat

Belirli aralıklarla listedeki kritik numaralar gerçekten doğrulanmalıdır.

21. Listeye İnternet Yoksa da Ulaşılabilmeli

Kriz planının yalnızca Google Drive, PMS, cloud storage veya şirket server’ı üzerinde bulunması yeni bir risk yaratabilir. Çünkü kriz bunlardan birine erişimi engelleyebilir. Bu nedenle kritik bilgilerin şu modelle tutulması düşünülebilir:

Online + Appropriate Offline Access

Amaç onlarca kontrolsüz kağıt kopya üretmek değil, sistem erişimi kaybolduğunda kritik bilgiye ulaşabilmektir.

22. Krizde İletişimin Üç Hedefi Vardır

İyi kriz iletişimi üç şeyi sağlamalıdır.

Doğru Bilgi

Yanlış bilgi yayılmamalıdır.

Doğru Kişi

Herkes kendi açıklamasını yapmamalıdır.

Doğru Zaman

Bilgi gereksiz yere geciktirilmemelidir.

Bu nedenle şu üçü birlikte yönetilmelidir:

Accuracy + Authority + Timing

23. Bilmediğinizi Söylemek Yanlış Bilgi Vermekten Daha İyidir

Kriz sırasında tüm cevapların bilinmesi mümkün değildir. Örneğin “Kesintinin kesin süresini henüz bilmiyoruz. Teknik ekip müdahale ediyor. Bir sonraki güncellemeyi 30 dakika içinde paylaşacağız.” ifadesi, “10 dakikada düzelecek.” deyip iki saat boyunca sistemi düzeltememekten daha güvenilir olabilir.

24. Tek Sözcü Prensibi

Özellikle ciddi olaylarda medya ve kamu iletişimi Authorized Spokesperson üzerinden yürütülmelidir. Çünkü aynı olay için resepsiyon başka, GM başka, sosyal medya ekibi başka açıklama yaparsa kriz büyüyebilir.

25. Misafir İletişimi Ayrı Bir Fonksiyondur

Kriz iletişimi yalnızca medya iletişimi değildir. Oteldeki misafir ne olduğunu, kendisinin etkilenip etkilenmediğini, ne yapması gerektiğini ve ne zaman yeni bilgi alacağını bilmek ister. Bu nedenle misafir iletişimi CMT içinde açık bir sorumluluk olmalıdır.

26. Çalışan İletişimini Unutmayın

Misafirlerden önce çalışanların doğru bilgiye ihtiyacı olabilir. Çünkü çalışanlar misafirlerle doğrudan temas halindedir. Bu nedenle şu zincir kurulmalıdır:

Crisis Team → Internal Briefing → Guest-Facing Teams → Consistent Guest Communication

27. Krizde Tek Bir Gerçeklik Oluşturun

Büyük olayların önemli problemlerinden biri bilgi parçalanmasıdır. Teknik ekip “Sistem bir saate gelir.” diyebilir. Resepsiyon “Bize üç saat dendi.” diyebilir. Sosyal medya ekibi “Problem çözüldü.” diye paylaşabilir. Bu nedenle ciddi krizlerde bir Command Center mantığı kurulmalıdır.

28. Command Center Fiziksel Bir Oda Olmak Zorunda Değildir

Büyük otelde özel bir kriz odası olabilir. Küçük otelde ise belirlenmiş bir ofis, telefon grubu, güvenli dijital kanal veya tek bir yönetim masası aynı işlevi görebilir. Amaç fiziksel mekan değil, Single Coordination Point oluşturmaktır.

29. Command Center’da Ne Takip Edilir?

En azından şunlar takip edilebilir:

• current situation,
• affected guests,
• affected employees,
• closed areas,
• operational status,
• critical systems,
• decisions,
• assigned actions,
• external contacts,
• next update time

30. Situation Report Nedir?

Kriz ilerledikçe herkesin aynı bilgiyi kullanmasını sağlayan kısa durum raporudur. Örnek:

Incident

Ana elektrik beslemesi kesildi.

Current Status

Jeneratör devrede; bazı alanlarda enerji yok.

Guest Impact

12 oda etkileniyor.

Safety

Doğrudan güvenlik tehdidi bulunmuyor.

Operations

Reception ve temel aydınlatma çalışıyor.

Action

Elektrikçi ve jeneratör servisi sahada.

Decision

Yeni check-in geçici olarak bekletiliyor.

Next Update

30 dakika sonra.

Bu rapor kriz sırasında bilgi kirliliğini önemli ölçüde azaltabilir.

31. Update Rhythm Belirleyin

Kriz iletişiminin önemli unsurlarından biri ritimdir. Örneğin her 30 dakikada durum değerlendirmesi belirlenebilir. Bu süre olayın ciddiyetine göre 5 dakika, 15 dakika, 30 dakika veya 1 saat olabilir. Önemli olan bir sonraki değerlendirme zamanının bilinmesidir.

32. Kriz Sırasında Önemli Kararları Kaydedin

Yoğun krizlerde birkaç saat sonra “Bu kararı kim verdi?”, “Saat kaçta öğrendik?”, “Envanteri neden kapattık?” sorularının cevabı unutulabilir. Bu nedenle Decision Log kullanılabilir.

Bu kayıt yalnızca hukuki veya idari amaç taşımaz. Aynı zamanda kriz sonrası öğrenmenin hammaddesidir.

33. 200 Sayfalık Plan Kriz Sırasında Kullanılmaz

Ana CMP kapsamlı olabilir. Fakat operasyon ekibinin kritik anda ihtiyacı olan şey çoğu zaman tek sayfalık Action Card olabilir.

34. Yangın Action Card Örneği

FIRE

1. Alarmı doğrula.
2. Emergency procedure’ü aktive et.
3. Gerekli tahliyeyi başlat.
4. Acil servisleri bilgilendir.
5. Guest accountability başlat.
6. Crisis Leader’ı bilgilendir.
7. Etkilenen alanı izole et.
8. Bilgi akışını merkezi hale getir.
9. Operasyon etkisini değerlendir.
10. Recovery kararını bekle.

Ama bu kart ilgili teknik ve yasal acil durum prosedürlerinin yerine geçmez. Görevi yüksek stres altında yönetim zincirini hatırlatmaktır.

35. PMS Outage Action Card Örneği

PMS DOWN

1. Kesintiyi doğrula.
2. Lokal/genel kapsamı belirle.
3. Siber olay ihtimalini değerlendir.
4. IT/PMS provider’ı bilgilendir.
5. Offline guest list’e geç.
6. Manuel check-in/out prosedürünü aktive et.
7. Alternatif ödeme yöntemini değerlendir.
8. Housekeeping/FO veri akışını manuel hale getir.
9. Misafir iletişimini başlat.
10. Recovery durumunu takip et.
11. Sistem geri geldiğinde veriyi doğrula.
12. Manuel işlemleri sisteme aktar.

36. Elektrik Kesintisi Action Card

POWER FAILURE

1. Kesintinin kapsamını belirle.
2. İnsan güvenliği riskini değerlendir.
3. Emergency lighting kontrol et.
4. Jeneratör durumunu doğrula.
5. Asansör durumunu kontrol et.
6. Kritik sistemleri değerlendir.
7. Teknik servisi aktive et.
8. Guest Care’i bilgilendir.
9. Kesinti uzuyorsa Business Continuity’yi aktive et.
10. Recovery sonrası sistemleri doğrula.

37. Crisis Plan Sorunu Yönetir, BCP İşletmeyi Yaşatır

Crisis Management Plan ile Business Continuity Plan birbirini tamamlar. CMP “Krizi nasıl yöneteceğiz?” sorusunu cevaplar. Business Continuity ise “Kriz devam ederken kritik operasyonları nasıl sürdüreceğiz?” sorusunu cevaplar. Örneğin PMS kesintisinde kriz planı kimlerin aktive olacağını belirler. Business continuity ise PMS olmadan check-in’in nasıl yapılacağını tanımlar.

38. Her Kritik Kriz Senaryosunun Continuity Sorusu Olmalı

Örneğin:

Elektrik yoksa

Minimum operasyon nasıl sürdürülecek?

Su yoksa

Kaç saat çalışılabilir?

PMS yoksa

Misafir bilgisine nasıl ulaşılacak?

İnternet yoksa

Ödeme ve rezervasyon nasıl yönetilecek?

Ana tedarikçi yoksa

Alternatif kim?

Otelin bir bölümü kapanırsa

Misafirler nereye taşınacak?

Bu bağlantı kurulmazsa kriz planı yalnızca müdahale planı olarak kalır.

39. Crisis Plan Architecture

Pratik bir yapı şu şekilde kurulabilir:

Bölüm 1 — Governance

Roller, yetkiler, escalation.

Bölüm 2 — Contact Directory

İç/dış kritik iletişim.

Bölüm 3 — Emergency Procedures

Yangın, sağlık, tahliye vb.

Bölüm 4 — Crisis Playbooks

Kritik senaryo kartları.

Bölüm 5 — Business Continuity

Offline ve alternatif operasyonlar.

Bölüm 6 — Communication

Misafir, çalışan, medya, paydaşlar.

Bölüm 7 — Recovery

Normale dönüş kriterleri.

Bölüm 8 — Forms

Situation Report, Decision Log, Incident Report.

Bölüm 9 — Training & Drills

Eğitim ve test sistemi.

Bölüm 10 — Review & Learning

AAR ve corrective actions.

40. Planı “Living Document” Olarak Yönetin

Kriz planı bir kere hazırlanıp beş yıl boyunca aynı kalmamalıdır. Çünkü çalışanlar değişir, tedarikçiler değişir, telefon numaraları değişir, PMS değişebilir, bina değişebilir, yeni riskler ortaya çıkabilir. Bu nedenle plan şu döngüde yaşamalıdır:

Create → Train → Test → Learn → Update → Retest

41. Her Çalışanın 200 Sayfalık Planı Bilmesi Gerekmez

Çalışanın bilmesi gereken şey kendi rolüdür. Örneğin resepsiyon çalışanı kimi arayacağını, misafiri nasıl yönlendireceğini, hangi bilgiyi paylaşabileceğini, guest accountability sürecini ve PMS yoksa ne yapacağını bilmelidir. Teknik ekip ise farklı şeyler bilmelidir. Bu nedenle Role-Based Crisis Training daha etkilidir.

42. Yeni Çalışan Onboarding’ine Kriz Rolünü Ekleyin

Yeni çalışan Wi-Fi şifresini, kahvaltı saatini, check-in prosedürünü öğreniyor. Ama yangın alarmında ne yapacağını bilmiyorsa onboarding eksiktir. Temel kriz rolü çalışan işe başladığında aktarılmalıdır.

43. Planın Çalışıp Çalışmadığını Tatbikat Gösterir

Kriz planının en tehlikeli hali kağıt üzerinde kusursuz görünmesi ama gerçek hayatta çalışmamasıdır. Bu nedenle plan test edilmelidir.

44. Tabletop Exercise

Her test fiziksel tahliye olmak zorunda değildir. Yönetim ekibi masa başında senaryo çalışabilir:

“Saat 21.15. Otel %95 dolu. PMS ve internet aynı anda gitti. Sistem sağlayıcısına ulaşılamıyor. Resepsiyonda altı check-in bekliyor. Ne yapıyoruz?”

Sonra şu sorular üzerinden sistem test edilir:

• kim karar veriyor?
• kim aranıyor?
• hangi plan aktive oluyor?
• misafire ne söyleniyor?
• ödeme nasıl alınacak?
• guest list nerede?

45. Tatbikatta Çalışanı Değil Sistemi Test Edin

Bir çalışanın yanlış hareket etmesi eğitim problemi olabilir. Ama aynı zamanda prosedür anlaşılmaz, yetki belirsiz, telefon listesi eski veya ekipman erişilemez olabilir. Bu nedenle tatbikat People Test değil, System Test olarak görülmelidir.

46. Tatbikatın Çıktısı Gap List Olmalı

Örneğin:

Tatbikatın amacı “tatbikat yaptık” kutusunu işaretlemek değildir. Amaç şu döngüyü başlatmaktır:

Gap → Corrective Action → Verification → Retest

47. Kriz Planında En Yaygın 15 Hata

1. Planı yalnızca yangın ve depremden ibaret görmek.
2. Yüzlerce sayfalık kullanılmaz doküman hazırlamak.
3. Olay seviyelerini tanımlamamak.
4. Crisis activation kriteri oluşturmamak.
5. Her kararı GM’ye bağlamak.
6. Backup yetki tanımlamamak.
7. Kriz ekibinde rol dağılımı yapmamak.
8. Telefon listesini güncellememek.
9. Planı yalnızca online sistemde tutmak.
10. Misafir iletişimini unutmak.
11. Her çalışanın açıklama yapmasına izin vermek.
12. Business Continuity’yi plana bağlamamak.
13. Offline operasyonları hazırlamamak.
14. Tatbikat yapmamak.
15. Tatbikatta bulunan eksikleri kapatmamak.

48. 20 Kriz Planı Karar Kapısı

Planınızı bu sorularla test edin.

Karar Kapısı 1

Hangi olayın problem, incident, emergency veya crisis olduğu belli mi?

Karar Kapısı 2

Crisis activation thresholds tanımlı mı?

Karar Kapısı 3

Escalation Matrix var mı?

Karar Kapısı 4

Crisis Leader kim?

Karar Kapısı 5

Crisis Leader’a ulaşılamazsa kim devralıyor?

Karar Kapısı 6

CMT fonksiyonları belli mi?

Karar Kapısı 7

Her rolün sorumluluğu açık mı?

Karar Kapısı 8

Acil karar yetkileri önceden tanımlı mı?

Karar Kapısı 9

Emergency Contact List güncel mi?

Karar Kapısı 10

Kritik bilgilere offline erişilebiliyor mu?

Karar Kapısı 11

Misafir iletişiminden kim sorumlu?

Karar Kapısı 12

Medya iletişiminden kim sorumlu?

Karar Kapısı 13

Command Center nasıl kurulacak?

Karar Kapısı 14

Situation Report formatı hazır mı?

Karar Kapısı 15

Decision Log hazır mı?

Karar Kapısı 16

Kritik kriz senaryolarının Action Card’ları var mı?

Karar Kapısı 17

CMP ile Business Continuity birbirine bağlı mı?

Karar Kapısı 18

Çalışanlar kendi kriz rollerini biliyor mu?

Karar Kapısı 19

Plan tatbikatla test edildi mi?

Karar Kapısı 20

Tatbikat bulguları doğrulanarak kapatıldı mı?

49. Governance

• Incident seviyeleri tanımlandı.
• Crisis activation kriterleri belirlendi.
• Escalation Matrix hazırlandı.
• Crisis Leader belirlendi.
• Backup Crisis Leader belirlendi.
• Crisis Management Team oluşturuldu.
• Roller yazılı hale getirildi.
• Authority Matrix hazırlandı.
• Kritik harcama/compensation yetkileri belirlendi.

50. Communication

• Emergency Contact List oluşturuldu.
• Liste doğrulandı.
• Offline erişim mevcut.
• Misafir iletişim sorumlusu belli.
• Çalışan iletişim sorumlusu belli.
• Authorized Spokesperson belli.
• İletişim onay mekanizması belli.
• Update rhythm tanımlandı.

51. Crisis Coordination

• Command Center modeli tanımlandı.
• Situation Report formatı hazır.
• Decision Log formatı hazır.
• Action Tracking sistemi var.
• Crisis Team iletişim kanalı belli.
• Dış paydaş escalation sistemi var.

52. Playbooks

• Yangın Action Card mevcut.
• Sağlık acil durumu Action Card mevcut.
• Elektrik kesintisi Action Card mevcut.
• Su kesintisi Action Card mevcut.
• PMS outage Action Card mevcut.
• Internet outage Action Card mevcut.
• Siber olay Action Card mevcut.
• Deprem/doğal afet Action Card mevcut.
• Kritik tedarik kesintisi planlandı.
• İtibar krizi escalation modeli var.

53. Business Continuity

• Critical Business Functions belirlendi.
• Minimum Viable Operation tanımlandı.
• Offline guest list sistemi var.
• Manuel check-in/out mümkün.
• Alternatif ödeme yöntemi değerlendirildi.
• Backup suppliers mevcut.
• Kritik sistem yedekleri test edildi.
• Recovery prosedürü tanımlandı.

54. People

• Çalışanlar temel kriz prosedürlerini biliyor.
• Role-based training yapıldı.
• Yeni çalışan onboarding’inde kriz eğitimi var.
• Gece vardiyasının yetkileri açık.
• Backup roller eğitim aldı.

55. Testing

• Tabletop exercise yapıldı.
• Fiziksel tatbikatlar yapıldı.
• İletişim sistemi test edildi.
• Offline prosedür test edildi.
• Backup erişimi test edildi.
• Gap List oluşturuldu.
• Corrective actions atandı.
• Retest yapıldı.

56. Küçük Oteller İçin “Minimum Viable Crisis Plan”

Küçük bağımsız otel yüzlerce sayfalık kriz yönetim kitabına ihtiyaç duymayabilir. Ama en azından şu dokuz bileşene sahip olabilir:

1. Risk List

En kritik riskler.

2. Escalation Matrix

Kimin kimi arayacağı.

3. Crisis Roles

Kim ne yapacak?

4. Primary + Backup

İlk kişi yoksa kim?

5. Emergency Contacts

İç ve dış kritik kişiler.

6. Action Cards

En önemli senaryolar.

7. Offline Procedures

Sistemler yoksa operasyon nasıl çalışacak?

8. Communication

Misafire ve çalışana kim ne söyleyecek?

9. Drill

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

Bu yalın yapı gerçekten uygulanıyorsa, kullanılmayan yüzlerce sayfalık bir plandan daha değerlidir.

57. Seviye 1 — Kişiye Bağımlı

“Bir şey olursa müdürümüz halleder.”

En kırılgan seviyedir.

58. Seviye 2 — Dokümante

Plan vardır. Ama roller ve testler zayıftır.

59. Seviye 3 — Organize

Crisis Team, escalation, yetki ve iletişim tanımlıdır.

60. Seviye 4 — Operational

Action Card’lar, offline procedures ve business continuity gerçek operasyona bağlanmıştır.

61. Seviye 5 — Tested

Plan düzenli olarak şu yöntemlerle doğrulanır:

• tabletop,
• drill,
• backup test,
• communication test

62. Seviye 6 — Adaptive

Her incident, near miss, tatbikat ve gerçek kriz planı geliştirir. Artık kriz planı statik belge değildir.

Yaşayan bir yönetim sistemidir.

Sonuç: İyi Kriz Planı Size Her Cevabı Vermez; Doğru Kararı Daha Hızlı Vermenizi Sağlar

Hiçbir Crisis Management Plan gelecekte yaşanabilecek bütün olayları öngöremez. Yeni bir teknoloji problemi çıkabilir. Beklenmedik doğal afet olabilir. Daha önce hiç düşünülmemiş bir operasyonel kriz yaşanabilir. Bu nedenle iyi kriz planının başarısı “Her senaryonun cevabını yazmış olmak” değildir. Başarı şudur:

Beklenmeyen senaryoda bile organizasyonun nasıl karar vereceğini bilmesidir.

Bunun için sistem şu zinciri kurmalıdır:

Olayı Fark Et → Sınıflandır → Escalate Et → Liderliği Aktive Et → İnsan Güvenliğini Koru → Bilgiyi Topla → Karar Ver → Sorumluluk Ata → İletişim Kur → Kritik Operasyonu Koru → Durumu Yeniden Değerlendir → Recovery’yi Başlat → Kaydet → Öğren → Planı Güncelle

Bu zincirin en kritik bölümü kriz başladığında kurulmaz. Krizden önce kurulmuş olmalıdır. İyi hazırlanmış otelde çalışanlar kriz sırasında “Şimdi ne yapacağız?” diye organizasyon kurmaya çalışmaz. Sistem zaten vardır. Kimin liderlik edeceği bellidir. Kimlerin aranacağı bellidir. Yetkiler bellidir. Backup roller bellidir. İletişim kanalları bellidir. Kritik operasyonların nasıl devam edeceği bellidir. Ve bu sistem yalnızca kağıt üzerinde değil, daha önce test edilmiştir. Bu nedenle otel kriz planının ana prensibi şudur:

Kriz planı rafta duran bir belge değil; belirsizlik altında çalışan bir karar verme sistemidir.

Planın gerçek testi dosyanın ne kadar ayrıntılı olduğu değildir. Gerçek test şudur:

Saat 03.00’te ciddi bir olay meydana geldiğinde, genel müdüre ulaşılamadığında ve ana sistemlerden biri çalışmadığında organizasyonun yine de doğru kararları verebilmesidir.

İşte o noktada kriz planı bir doküman olmaktan çıkar ve kurumsal dayanıklılığa dönüşür.

Ayrıca okuyun: Otellerde Acil Durum ve Kriz Yönetimi Nasıl Kurulur? Yangın, Deprem, Tahliye ve Crisis Management Rehberi · Otelde Güvenlik Sistemi Nasıl Kurulur? Günlük Güvenlik, Olay Yönetimi ve Incident Report Rehberi · Otellerde Kriz Yönetimi Nasıl Kurulur? Risk, Hazırlık ve Business Continuity Rehberi

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 Crisis Management Plan, kriz yönetişimi, yetkilendirme, Crisis Management Team, kriz iletişimi, Business Continuity ve organizasyonel dayanıklılık yaklaşımından geliştirilmiştir.

Cilt VIII; misafir sadakatinden 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.