Otel Organizasyon Şeması Nasıl Kurulur? Görev, Yetki ve Sorumluluk Dağılımı Rehberi

Bir otelde organizasyon problemi yaşandığını anlamak için organizasyon şemasına bakmanız gerekmeyebilir.

Operasyonda kullanılan bazı cümleler yeterlidir:

“Ben onun benden sorumlu olduğunu bilmiyordum.”

“Bunu housekeeping yapıyor sanıyordum.”

“Resepsiyon teknik ekibe söylemiş.”

“Müdüre haber verdik.”

“Benim yetkim yok.”

“Patrona soralım.”

“Herkes birbirine söylemiş ama kimse yapmamış.”

Bu cümleler çoğu zaman personelin kötü niyetinden kaynaklanmaz.

Asıl problem:

organizasyonun görev, yetki ve sorumluluk açısından yeterince açık tasarlanmamış olmasıdır.

Özellikle küçük ve butik otellerde:

“Biz küçük bir ekibiz, herkes her işi yapıyor.”

yaklaşımı başlangıçta esnek ve pratik görünebilir.

Ancak otel büyüdükçe bunun bedeli ortaya çıkar:

• görevler birbirine karışır,
• bazı işler iki kişi tarafından yapılır,
• bazı işler hiç yapılmaz,
• çalışanlar birbirini suçlar,
• kararlar yöneticide birikir,
• işletme sahibi operasyonun merkezine çekilir.

Bu nedenle organizasyon şeması yalnızca:

kimin kime bağlı olduğunu gösteren bir çizim

değildir.

Doğru tasarlandığında organizasyon sistemi şu beş soruya cevap verir:

1. Kim?
2. Neden sorumlu?
3. Kime rapor ediyor?
4. Hangi kararı verebilir?
5. Departmanlar arası işlerde sorumluluk kimde?

İyi bir organizasyonun temel amacı:

insanlara unvan vermek değil, işlerin doğru sahiplerini belirlemektir.

1. Organizasyon Şeması Nedir?

Organization Chart — Organizasyon Şeması, oteldeki:

• yönetim seviyelerini,
• departmanları,
• pozisyonları,
• raporlama ilişkilerini

gösteren yapıdır.

Basit bir örnek:

Owner / Board → General Manager → Front Office — Housekeeping — F&B — Technical — Finance → Operational Team

Ancak profesyonel organizasyon tasarımı bununla bitmez.

Çünkü şema yalnızca:

“Kim kime bağlı?”

sorusunu cevaplar.

Oysa operasyonun çalışabilmesi için ayrıca:

“Kim ne yapıyor?”

ve:

“Kim hangi kararı verebilir?”

soruları da cevaplanmalıdır.

Bu nedenle organizasyon sisteminin dört temel bileşeni vardır:

Organization Chart + Job Description + Authority Matrix + Responsibility Matrix

2. Organizasyon Şeması Neden Gereklidir?

Otel operasyonu birçok fonksiyonun aynı anda çalışmasını gerektirir.

Örneğin:

misafir saat 13.00'te erken gelir.

Oda henüz hazır değildir.

Bu tek olayda bile:

• Front Office,
• Housekeeping,
• Supervisor,
• Guest Relations

birlikte çalışabilir.

Eğer odada teknik problem varsa:

Technical

da sürece girer.

Eğer misafire recovery uygulanacaksa:

yetkili yönetici

devreye girebilir.

Yani otel:

birbirinden bağımsız departmanlardan değil, birbirine bağlı süreçlerden oluşur.

Organizasyon yapısının görevi bu bağlantılardaki sorumluluğu netleştirmektir.

3. Organizasyon Tasarımı İsimlerle Başlamamalıdır

Sık yapılan hata:

önce mevcut çalışanlara bakıp organizasyon kurmaktır.

Örneğin:

“Ahmet uzun zamandır bizimle, onu müdür yapalım.”

“Ayşe zaten birçok işle ilgileniyor, satın almayı da ona verelim.”

Böylece organizasyon:

işletmenin ihtiyacına göre değil,

mevcut insanların özelliklerine göre şekillenmeye başlar.

Daha doğru sıra:

Hotel Concept → Service Model → Operational Functions → Departments → Positions → Responsibilities → Required Competencies → People

olmalıdır.

Yani önce:

“Hangi pozisyona ihtiyacımız var?”

sonra:

“Bu pozisyona kim uygun?”

sorusu sorulmalıdır.

4. Pozisyon ile Kişiyi Ayırın

Organizasyon sisteminin temel prensiplerinden biri:

Position ≠ Person

ayrımıdır.

Örneğin:

Front Office Supervisor

bir pozisyondur.

Ayşe:

o pozisyonu bugün üstlenen kişidir.

Ayşe yarın işletmeden ayrılabilir.

Ama:

Front Office Supervisor fonksiyonu devam eder.

Bu ayrım yapılmadığında işletmelerde:

“Bu işi Ahmet biliyor.”

“Rezervasyonları Zeynep yapıyor.”

“Satın alma Mehmet'te.”

gibi kişiye bağlı sistemler oluşur.

Çalışan ayrıldığında:

bilgi de işletmeden ayrılır.

Profesyonel organizasyonda:

iş kişiye değil, pozisyona bağlanır.

5. Önce Otelin Fonksiyonlarını Haritalayın

Organizasyon şeması hazırlamadan önce:

Function Map — Fonksiyon Haritası

oluşturmak faydalıdır.

Bir otelde örneğin şu fonksiyonlar bulunabilir:

Management

• strateji,
• bütçe,
• performans,
• koordinasyon.

Front Office

• reception,
• check-in/out,
• guest requests,
• room assignment.

Reservations

• rezervasyon,
• değişiklik,
• iptal,
• channel coordination.

Revenue

• fiyat,
• inventory,
• forecast,
• pickup.

Housekeeping

• oda temizliği,
• public area,
• linen,
• room inspection.

F&B

• breakfast,
• kitchen,
• service,
• stock.

Technical

• maintenance,
• Work Order,
• preventive maintenance.

Guest Relations

• guest experience,
• complaint,
• service recovery.

Finance

• cash,
• payment,
• accounting coordination,
• reporting.

HR

• recruitment,
• onboarding,
• training,
• performance.

Purchasing

• supplier,
• order,
• receiving,
• stock.

Security

• access,
• incident,
• emergency.

Bunların tamamı ayrı departman olmak zorunda değildir.

Ama:

fonksiyonun var olması ile ayrı departmanın var olması farklı şeylerdir.

6. Küçük Otelde Departman Sayısı Azalabilir, Fonksiyonlar Kaybolmamalıdır

10 odalı butik otelde:

10 ayrı departman yöneticisi bulunması gerçekçi değildir.

Ancak:

Revenue Management yapmamak,

İK yapmamak,

teknik bakım yapmamak

veya:

güvenlik sorumluluğunu tanımlamamak

da doğru değildir.

Çözüm:

Role Consolidation — Rol Birleştirme

olabilir.

Örneğin:

General Manager

aynı zamanda:

• Revenue,
• HR,
• Purchasing

fonksiyonlarının Owner'ı olabilir.

Front Office

aynı zamanda:

• Reservations,
• Guest Relations

yürütebilir.

External Provider

• accounting,
• payroll,
• specialist maintenance

işlerini üstlenebilir.

Temel prensip:

Küçük otelde organizasyon küçülebilir; sorumluluk ortadan kalkamaz.

7. Butik Otel Organizasyon Şeması Örneği

Örneğin küçük bir butik otelde:

Owner / Management → Hotel Manager / General Manager → Front Office Supervisor, Housekeeping Supervisor, F&B / Breakfast Responsible, Technical Responsible → Operational Team

şeklinde sade bir yapı kurulabilir.

Bunun yanında:

• Finance,
• Payroll,
• Legal,
• IT,
• Specialist Maintenance

dış kaynaklarla yürütülebilir.

Ancak dış kaynak kullanılması:

sorumluluğun tamamen dışarı devredildiği anlamına gelmez.

Otelde mutlaka:

Internal Owner

bulunmalıdır.

8. Internal Owner Nedir?

Örneğin muhasebe dışarıdaki mali müşavir tarafından yürütülüyor.

Bu durumda:

“Muhasebe mali müşavirde.”

demek yeterli değildir.

Otelde bir kişi:

• belgelerin zamanında gönderilmesinden,
• kasa kontrolünden,
• raporların alınmasından,
• finansal bilgilerin yönetimle paylaşılmasından

sorumlu olmalıdır.

Benzer şekilde teknik bakım dışarıdan alınabilir.

Ama:

“Klima firması ilgileniyor.”

operasyonel sorumluluk tanımı değildir.

Otelde bir kişi:

Work Order'ın açılmasını,

servisin çağrılmasını,

işin tamamlanmasını

ve:

sonucun doğrulanmasını

takip etmelidir.

Outsource edilen işin bile içeride bir sahibi olmalıdır.

9. Job Description — Görev Tanımı

Organizasyon şemasındaki her kritik pozisyon için Job Description hazırlanmalıdır.

İyi bir görev tanımı şu alanları içerebilir:

Position Title

Pozisyon adı.

Department

Departman.

Reports To

Kime bağlı?

Direct Reports

Kimler ona bağlı?

Position Purpose

Pozisyon neden var?

Key Responsibilities

Temel sorumluluklar.

Daily Responsibilities

Günlük görevler.

Periodic Responsibilities

Haftalık/aylık görevler.

Decision Authority

Hangi kararları verebilir?

Escalation

Hangi durumda üst yönetime gider?

KPI

Performansı nasıl ölçülür?

Required Competencies

Hangi yetkinlikler gerekir?

Backup

Yokluğunda kim devralır?

Bu yapı görev tanımını:

iş listesi

olmaktan çıkarır.

10. Görev Tanımında En Önemli Bölüm: Position Purpose

Görev tanımlarında sık yapılan hata:

çok uzun görev listeleri yazmaktır.

Örneğin Front Office Supervisor için:

• telefonlara cevap verir,
• rezervasyon kontrol eder,
• check-in yapar,
• mail okur,
• kasa sayar...

liste uzar.

Ama çalışan:

pozisyonunun neden var olduğunu

anlamayabilir.

Bu nedenle Job Description içinde kısa bir:

Position Purpose

olması faydalıdır.

Örneğin:

“Front Office operasyonunun doğru, hızlı ve misafir deneyimi standardına uygun şekilde yürütülmesini sağlamak.”

Bu cümle:

yüzlerce görev maddesinin üstündeki ana amacı tanımlar.

11. Task ile Accountability Aynı Şey Değildir

Önemli bir ayrım:

Task

İşi yapan kişi.

Accountability

Sonuçtan sorumlu kişi.

Örneğin:

Room Attendant:

odayı temizler.

Housekeeping Supervisor:

odanın standarda uygun şekilde Ready hale gelmesinden sorumludur.

Yani:

Doing the Work ≠ Owning the Result

Bu ayrım özellikle yöneticilik pozisyonlarında kritiktir.

12. Sorumluluk Verip Yetki Vermemek

Bir Supervisor'a:

“Misafir memnuniyetinden sen sorumlusun.”

diyoruz.

Ama:

• room move yapamıyor,
• küçük recovery uygulayamıyor,
• personelin görev dağılımını değiştiremiyor,
• teknik işe öncelik veremiyor.

Bu durumda:

sorumluluk var,

ama yetki yok.

Sonuç:

her konu yöneticiye gider.

Doğru prensip:

Responsibility ↔ Authority

birbirine mümkün olduğunca uyumlu olmalıdır.

13. Yetki Verip Sorumluluk Vermemek de Sorundur

Tersi de risklidir.

Bir çalışan:

• indirim yapabiliyor,
• complimentary verebiliyor,
• satın alma yapabiliyor,
• oda değiştirebiliyor,

ama bu kararların sonucundan açık şekilde sorumlu değilse:

kontrol zayıflar.

Bu nedenle yetki:

sınırsız özgürlük

değildir.

Doğru yapı:

Authority + Limit + Documentation + Accountability

olmalıdır.

14. Authority Matrix Nedir?

Authority Matrix — Yetki Matrisi, hangi kararın hangi seviyede alınabileceğini gösterir.

Örneğin:

Buradaki limitler:

her otelin kendi büyüklüğüne ve yönetim modeline göre belirlenmelidir.

Amaç:

her karar için patronu arama ihtiyacını azaltmak

ve aynı zamanda kontrolü korumaktır.

15. Authority Matrix Neden Misafir Deneyimini Etkiler?

Misafir:

odasındaki problem nedeniyle resepsiyona gelir.

Resepsiyonist:

“Bir müdürüme sorayım.”

der.

Müdür cevap vermez.

10 dakika geçer.

Misafir tekrar sorar.

Resepsiyonist:

“Henüz dönüş alamadım.”

der.

Buradaki sorun çalışan olmayabilir.

Sorun:

yetki tasarımıdır.

Doğru yetkilendirilmiş çalışan:

belirlenen sınırlar içinde problemi hemen çözebilir.

Dolayısıyla:

Authority Matrix yalnızca yönetim dokümanı değil, Service Speed aracıdır.

16. RACI Matrisi Nedir?

Departmanlar arası süreçlerde en kullanışlı araçlardan biri:

RACI Matrix

olabilir.

RACI:

R — Responsible

İşi yapan.

A — Accountable

Sonuçtan nihai sorumlu.

C — Consulted

Görüş alınan.

I — Informed

Bilgilendirilen.

Örneğin:

VIP Room Preparation

sürecinde:

Bu yapı:

“Kim yapacaktı?”

sorusunu azaltır.

17. RACI'nin Altın Kuralı: Bir Accountable

Bir süreçte:

çok sayıda Responsible olabilir.

Ama ideal olarak:

tek bir Accountable

bulunmalıdır.

Çünkü:

“Hepimiz sorumluyuz.”

çoğu zaman pratikte:

“Hiç kimse tam olarak sorumlu değil.”

anlamına dönüşebilir.

Bu nedenle her kritik sürecin:

bir Owner'ı bulunmalıdır.

18. RACI Nerelerde Kullanılabilir?

Her küçük iş için RACI hazırlamak gereksiz bürokrasi yaratabilir.

Ancak departmanlar arası kritik süreçlerde çok faydalıdır.

Örneğin:

• Room Ready
• VIP Arrival
• Guest Complaint
• Room Move
• Lost & Found
• Refund
• Overbooking
• Technical OOO
• Emergency
• Purchasing
• Inventory Count
• Recruitment
• Staff Termination
• Incident Management

gibi süreçlerde kullanılabilir.

Özellikle:

“Bu iş kimin?”

tartışması sık yaşanıyorsa RACI gereklidir.

19. Room Ready İçin RACI Örneği

Bir oda temizleniyor.

Room Attendant:

temizliği yapıyor.

Supervisor:

kontrol ediyor.

Technical:

arıza varsa müdahale ediyor.

Front Office:

PMS üzerinden oda durumunu takip ediyor.

Bu durumda:

sistem örneğin şöyle kurulabilir:

Cleaning

R: Room Attendant

A: HK Supervisor

Technical Defect

R: Technical

A: Technical Responsible

Final Room Release

R: HK Supervisor

A: HK Supervisor

Guest Assignment

R: Reception

A: Front Office Supervisor

Bu sayede:

oda Ready olmadan misafire verilmesi

gibi risklerin sorumluluk zinciri görünür hale gelir.

20. Raporlama Hattı Net Olmalıdır

Her çalışan:

kime rapor verdiğini

bilmelidir.

Örneğin:

Room Attendant:

Housekeeping Supervisor'a.

Receptionist:

Front Office Supervisor'a.

Supervisor:

Hotel Manager'a.

Bu basit görünür.

Ancak küçük işletmelerde çalışan aynı anda:

• otel sahibinden,
• sahibin eşinden,
• GM'den,
• Supervisor'dan

farklı talimatlar alabiliyorsa:

organizasyon bozulur.

Bir çalışanın birden fazla kişiden çelişkili talimat alması yönetim sistemi değildir.

21. Owner Bypass Problemi

Butik otellerde sık görülen sorunlardan biri:

işletme sahibinin organizasyon hattını sürekli atlamasıdır.

Örneğin:

Owner:

Room Attendant'a doğrudan:

“Bugün önce 205'i temizle.”

diyor.

HK Supervisor:

aynı çalışana:

“Önce 101–104 bitecek.”

demiş.

Çalışan hangisini yapmalı?

Owner açısından küçük bir talimat gibi görünür.

Ama organizasyon açısından:

Chain of Command

bozulmuştur.

Daha doğru yöntem:

Owner → GM / Supervisor → Team

şeklinde ilerlemektir.

Acil durumlar elbette istisna olabilir.

Ama:

organizasyon şeması yalnızca çalışanların uyması gereken bir yapı değildir; işletme sahibinin de uyması gerekir.

22. Chain of Command Ne İşe Yarar?

Chain of Command:

iletişimi yavaşlatmak için değil,

sorumluluğu korumak için vardır.

Her küçük konuda:

Owner → GM → Supervisor → Employee

şeklinde bürokratik iletişim kurulması gerekmez.

Günlük operasyon doğrudan akabilir.

Ancak:

• görev değişikliği,
• performans talimatı,
• disiplin,
• vardiya,
• öncelik değişikliği

gibi yönetim kararlarında:

raporlama hattının korunması önemlidir.

23. Escalation Matrix Nedir?

Her problemi frontline çalışan çözemez.

Bu nedenle:

Escalation Matrix

gereklidir.

Örneğin:

L1 — Frontline

Normal günlük problem.

L2 — Supervisor

Standart dışı ama sınırlı problem.

L3 — Manager

Yüksek misafir veya finansal etki.

L4 — General Manager

Ciddi operasyonel / itibari risk.

L5 — Crisis / Owner / Emergency

Can güvenliği, ciddi hukuki, finansal veya kriz durumu.

Amaç:

her problemi yukarı taşımak değil, doğru problemi doğru seviyeye taşımaktır.

24. Ne Zaman Escalate Edileceği Yazılı Olmalıdır

Örneğin şu durumlar:

üst seviyeye çıkarılabilir:

• güvenlik riski,
• ciddi guest complaint,
• yüksek tutarlı refund,
• polis/jandarma olayı,
• ciddi teknik arıza,
• veri güvenliği olayı,
• sağlık acil durumu,
• medya riski,
• yangın,
• ciddi personel olayı.

Böylece çalışan:

“Bunu kendim mi çözmeliyim, yöneticiyi mi aramalıyım?”

sorusunda kalmaz.

25. Decision Rights — Karar Hakları

Organizasyon tasarımında yalnızca:

kim ne yapıyor?

değil:

kim neye karar veriyor?

sorusu da önemlidir.

Örneğin:

Oda fiyatını kim değiştirir?

Revenue / GM?

Odayı OOO'ya kim alabilir?

Technical + FO?

Misafire upgrade'i kim onaylar?

Supervisor?

Yeni tedarikçiyi kim seçer?

Purchasing / GM?

Personeli kim işe alır?

GM + Owner?

CAPEX'i kim onaylar?

Owner?

Bunların cevapları yazılı olmadığında:

kararlar kişisel ilişkilere göre alınmaya başlayabilir.

26. Approval Limit Kullanılabilir

Finansal kararlarda:

Approval Limit

belirlemek faydalıdır.

Örneğin sistem:

• küçük operasyonel harcama → Supervisor,
• orta harcama → GM,
• yüksek harcama → Owner

şeklinde olabilir.

Burada önemli olan belirli rakamlar değil:

kararın finansal etkisine göre yetki seviyesinin tanımlanmasıdır.

Bu yapı:

hem hızı

hem kontrolü

korur.

27. Segregation of Duties — Görevlerin Ayrılığı

Finansal kontrol açısından kritik bir prensip:

aynı kişinin işlemin bütün aşamalarını tek başına kontrol etmemesidir.

Örneğin aynı kişi:

• tedarikçiyi seçiyor,
• sipariş veriyor,
• ürünü teslim alıyor,
• faturayı onaylıyor,
• ödemeyi yapıyorsa

kontrol riski artar.

Daha sağlıklı yapı:

Request → Approval → Purchase → Receiving → Invoice Control → Payment

adımlarının uygun ölçüde ayrılmasıdır.

Küçük otelde her aşama farklı kişide olmayabilir.

Ama en azından:

kritik finansal işlemlerde ikinci kontrol noktası

oluşturulmalıdır.

28. Organizasyon Şeması Operasyon Akışını Takip Etmelidir

Şema güzel görünebilir.

Ama workflow ile uyumlu değilse işe yaramaz.

Örneğin Guest Complaint süreci:

Reception → Guest Relations → Department → Supervisor → Resolution → Guest Follow-Up

şeklinde çalışıyorsa:

organizasyon ve yetki yapısı bu akışı desteklemelidir.

Eğer Guest Relations sorumlusu problemin Owner'ı ama hiçbir departmandan aksiyon isteyemiyorsa:

organizasyon tasarımı eksiktir.

29. Matrix Organization Küçük Otelde Nasıl Görünebilir?

Bazı roller iki farklı açıdan sorumluluk taşıyabilir.

Örneğin:

Receptionist:

operasyonel olarak Front Office Supervisor'a bağlıdır.

Ama:

Revenue ile ilgili belirli uygulamalarda Revenue Manager'ın standardına uyar.

Bu:

matrix ilişkisidir.

Ancak küçük otellerde fazla matrix yapı:

karışıklık yaratabilir.

Bu nedenle:

Primary Reporting Line

her zaman net olmalıdır.

30. Organizasyon Şeması Vardiyayı da Düşünmelidir

Kağıt üzerinde:

GM

ve altında üç Supervisor olabilir.

Ama gece 02.00'de:

kim yetkili?

Pazar günü GM izinliyken:

kim karar verecek?

Bu nedenle organizasyon:

yalnızca gündüz ofis saatlerini değil:

24/7 Operational Authority

yapısını düşünmelidir.

Burada:

Duty Manager

veya:

Manager on Duty

rolü kullanılabilir.

31. Duty Manager Nedir?

Duty Manager:

belirli zaman diliminde otelin operasyonel karar yetkisini taşıyan kişidir.

Örneğin:

• guest complaint,
• room move,
• emergency coordination,
• service recovery,
• security incident,
• department coordination

konularında yetkili olabilir.

Bu rol özellikle:

• akşam,
• gece,
• hafta sonu,
• yönetici izinlerinde

önemlidir.

32. Kritik Pozisyonları Belirleyin

Her pozisyon aynı operasyonel riske sahip değildir.

Critical Role

şu soruyla belirlenebilir:

“Bu pozisyon bugün boş kalırsa otel ciddi şekilde etkilenir mi?”

Örneğin:

• Night Auditor,
• Front Office Supervisor,
• Technical Responsible,
• Housekeeping Supervisor

bazı işletmelerde kritik olabilir.

Sonra:

Critical Role Register

oluşturulabilir.

33. Kritik Pozisyonların Yedeği Olmalıdır

Örneğin yalnızca bir kişi Night Audit biliyor.

Bu kişi:

hastalandı.

Ne olacak?

Profesyonel sistem:

Primary

Ana görevli.

Backup

Yedek.

Emergency Backup

Acil durumda görevi devralabilecek kişi.

şeklinde kurulabilir.

Bu yaklaşım:

Key Person Dependency

riskini azaltır.

34. Succession Planning Yalnızca Büyük Oteller İçin Değildir

Succession Planning:

bir yönetici ayrıldığında yerine kimin geçebileceğini önceden düşünmektir.

Örneğin:

Front Office Supervisor ayrılırsa:

hangi receptionist gelişmeye hazır?

Housekeeping Supervisor ayrılırsa:

hangi senior room attendant hazırlanabilir?

GM ayrılırsa:

kim geçici olarak operasyonu yönetebilir?

Bu plan:

özellikle küçük otellerde çok değerlidir.

Çünkü tek bir kişinin ayrılması operasyonu ciddi etkileyebilir.

35. Cross-Training Organizasyonun Dayanıklılığını Artırır

Cross-training:

çalışanın ikinci bir fonksiyonu temel seviyede öğrenmesidir.

Örneğin:

Reception:

Reservations.

Housekeeping Supervisor:

basic room status management.

F&B:

basic guest request handling.

Manager:

Night Audit overview.

Ama cross-training:

organizasyon şemasını ortadan kaldırmaz.

Tam tersine:

Primary Responsibility net olduğu için Secondary Capability güvenli şekilde kurulabilir.

36. Organizasyon Şemasında Fazla Yönetici Problemi

Küçük otellerde başka bir hata:

gereğinden fazla yönetim katmanı oluşturmaktır.

Örneğin 12 çalışan için:

• GM,
• Assistant GM,
• Operations Manager,
• FO Manager,
• FO Supervisor

gibi aşırı hiyerarşi:

maliyet ve karar yavaşlığı yaratabilir.

Organizasyon:

otelin büyüklüğüyle orantılı olmalıdır.

Unvan üretmek organizasyon kurmak değildir.

37. Flat Organization Her Zaman Daha İyi Değildir

Tersi de geçerlidir.

Hiç yönetici katmanı olmayan:

Owner

↓

Everyone

modeli de ölçeklenmez.

Bu durumda:

12 çalışan:

her problem için aynı kişiye gider.

Sonuç:

Owner Bottleneck.

Doğru yapı:

gereksiz hiyerarşiden kaçınırken:

Accountability Layers

oluşturmaktır.

38. Span of Control

Bir yöneticinin doğrudan kaç kişiyi etkin şekilde yönetebildiği:

Span of Control

ile ilişkilidir.

Tek bir ideal sayı yoktur.

Çünkü:

• işin karmaşıklığı,
• çalışan deneyimi,
• vardiyalar,
• coğrafi dağılım,
• standardizasyon,
• teknoloji

sonucu değiştirir.

Ama şu soru önemlidir:

“Bu yöneticinin gerçekten koçluk, kontrol ve karar desteği verebileceğinden fazla doğrudan raporu var mı?”

Eğer cevap evetse:

organizasyon yeniden tasarlanmalıdır.

39. Organizasyon Şemasında Misafir Görünmez Ama Merkezde Olmalıdır

Organizasyon şeması:

Owner → GM → Managers → Employees

şeklinde görünür.

Ama hizmet organizasyonunu farklı düşünmek de faydalıdır.

Misafir açısından:

Guest → Frontline Employees → Supervisors → Managers → GM → Owner

Burada yönetimin görevi:

frontline çalışanın misafire iyi hizmet verebilmesi için gerekli sistemi sağlamaktır.

Yani:

organizasyonun amacı yöneticilere statü vermek değil, misafire değer üreten çalışanları desteklemektir.

40. Yönetici Ne İş Yapar?

Yönetici:

en iyi receptionist,

en hızlı Room Attendant

veya:

en iyi garson

olmak zorunda değildir.

Yöneticinin görevi:

• hedef koymak,
• işi planlamak,
• kaynak sağlamak,
• sorumluluk dağıtmak,
• çalışanı geliştirmek,
• performansı ölçmek,
• problemi çözmek,
• departmanlar arası koordinasyon sağlamak,
• sistemi iyileştirmek

olmalıdır.

Kısacası:

Yönetici işi yapan değil, işin doğru yapılmasını sağlayan kişidir.

41. Supervisor ile Manager Arasındaki Fark

Küçük işletmelerde unvanlar birbirine karışabilir.

Basit ayrım:

Supervisor

Günlük saha uygulamasını yönetir.

Manager

Sistemi ve performansı yönetir.

Örneğin Housekeeping Supervisor:

bugünkü odaların:

• dağılımını,
• temizliğini,
• inspection'ını

yönetebilir.

Housekeeping Manager:

• staffing,
• budget,
• productivity,
• SOP,
• training,
• linen cost,
• quality trends

gibi daha geniş sistemi yönetebilir.

Küçük otelde iki rol tek kişide olabilir.

Ama:

fonksiyonel farkı bilmek önemlidir.

42. Organizasyon Tasarımında Meeting Structure

Organizasyon yalnızca şemadan oluşmaz.

İletişim ritmi de tasarlanmalıdır.

Örneğin:

Daily Operations Meeting

Operasyonel koordinasyon.

Weekly Department Meeting

Departman performansı.

Weekly Management Meeting

KPI ve sorunlar.

Monthly Management Review

Finans, kalite, insan ve operasyon.

Bu toplantılarda:

kimin katıldığı,

hangi veriyi getirdiği,

hangi kararları alabildiği

tanımlanmalıdır.

43. Handover Organizasyonun Parçasıdır

Bir vardiya diğerine bilgi aktarmıyorsa:

organizasyon kağıt üzerinde çalışıyor olabilir.

Ama operasyonel olarak kopuktur.

Handover'da örneğin:

• open guest requests,
• complaints,
• payment issues,
• VIP,
• technical problems,
• OOS/OOO,
• security incidents,
• special instructions

aktarılmalıdır.

Temel soru:

“Bir sonraki vardiyanın harekete geçmesini veya dikkatli olmasını gerektiren ne var?”

olmalıdır.

44. Organizasyon Şeması ile SOP Arasındaki İlişki

Her SOP şu sorulara cevap vermelidir:

Responsible: Kim yapacak?

Accountable: Kim sonuçtan sorumlu?

Escalation: Problem olursa kime gidecek?

Bu bilgiler:

organizasyon şeması ve yetki matrisiyle uyumlu olmalıdır.

Örneğin SOP:

“GM onayı gerekir.”

diyor.

Authority Matrix:

“Supervisor yetkilidir.”

diyorsa:

sistem kendi içinde çelişir.

45. Organizasyon Değişince SOP'lar da Kontrol Edilmelidir

Yeni Operations Manager geldi.

Bazı yetkiler GM'den ona geçti.

Bu durumda yalnızca Organization Chart değiştirilmemelidir.

Ayrıca:

• Job Descriptions,
• Authority Matrix,
• RACI,
• SOP,
• Escalation Matrix,
• Approval Limits

kontrol edilmelidir.

Çünkü:

organizasyon değişikliği operasyon sisteminin birçok dokümanını etkiler.

46. İnsan Kaynakları ile Organizasyon Şeması Arasındaki Bağ

Organizasyon şeması:

HR sisteminin başlangıç noktalarından biridir.

Çünkü şemadan:

Position List

çıkar.

Position List'ten:

Job Description

çıkar.

Job Description'dan:

Competency Requirement

çıkar.

Sonra:

Recruitment Profile

oluşur.

Yani:

Organization → Position → Job Description → Competency → Recruitment → Training → Performance

zinciri kurulur.

Bu nedenle yanlış organizasyon:

yanlış işe alımlara kadar uzanabilir.

47. Performans KPI'ları Pozisyona Bağlanmalıdır

Her çalışan aynı KPI ile ölçülemez.

Örneğin:

Front Office Supervisor

• check-in waiting,
• payment accuracy,
• guest request closure,
• handover quality.

Housekeeping Supervisor

• Room Ready,
• inspection pass,
• re-clean,
• cleanliness feedback.

Technical Responsible

• PM compliance,
• response time,
• repeat failure,
• OOO room hours.

Revenue Responsible

• ADR,
• RevPAR,
• forecast accuracy,
• pickup management.

KPI:

pozisyonun sorumluluğunu ölçmelidir.

48. Sorumlu Olmadığı KPI ile Çalışanı Ölçmeyin

Bir çalışanın kontrol edemediği sonuçtan tek başına sorumlu tutulması adaletsiz ve verimsizdir.

Örneğin:

Receptionist'i toplam otel RevPAR'ından bireysel olarak sorumlu tutmak mantıklı olmayabilir.

Çünkü:

fiyatlama ve inventory kararları başka seviyede olabilir.

Bu nedenle:

Accountability ile KPI arasında bağlantı bulunmalıdır.

49. Departman KPI'ları Ortak Hedefler de İçermelidir

Sadece departman KPI'ları kullanılırsa silo davranışı oluşabilir.

Örneğin:

Housekeeping:

Cleaning Productivity'yi yükseltmek ister.

Front Office:

Room Ready'yi hızlandırmak ister.

Technical:

Work Order sayısını azaltmak ister.

Ama misafir:

tek otel deneyimler.

Bu nedenle bazı ortak KPI'lar kullanılabilir:

• Review Score,
• Complaint Rate,
• Room Ready,
• Guest Satisfaction,
• GOP

gibi.

Bu:

Department First yerine Hotel First

kültürünü destekler.

50. “Ben Söyledim” Yönetim Sistemi Değildir

Bir problem yaşandı.

Manager:

“Ben söylemiştim.”

Supervisor:

“Ben WhatsApp'tan yazdım.”

Reception:

“Housekeeping'e haber verdik.”

Technical:

“Bize gelmedi.”

Bu yapı:

bilgi var ama ownership yok

anlamına gelebilir.

Profesyonel süreç:

Issue → Owner → Action → Deadline → Status → Verification → Closure

şeklinde olmalıdır.

51. WhatsApp Organizasyon Şemasının Yerini Tutmaz

WhatsApp:

hızlı iletişim için faydalıdır.

Ama:

• görev sahipliği,
• audit trail,
• deadline,
• escalation,
• closure

konularında tek başına yeterli olmayabilir.

Örneğin:

“205 klima çalışmıyor.”

mesajı gruba atıldı.

Kim yapacak?

Ne zaman?

Önceliği ne?

Çözüldü mü?

Kim kontrol etti?

Bunlar belli değilse:

mesaj gönderilmiş,

ama:

iş yönetilmemiştir.

52. Organizasyon Tasarımında 15 Yaygın Hata

1. Organizasyonu kişilere göre kurmak

2. Pozisyon ile kişiyi birbirine karıştırmak

3. Küçük otelde fonksiyonları tamamen yok saymak

4. “Herkes her işi yapar.” demek

5. Job Description hazırlamamak

6. Sorumluluk verip yetki vermemek

7. Yetki verip limit koymamak

8. Departmanlar arası süreçlerde Owner belirlememek

9. Bir süreçte birden fazla nihai sorumlu yaratmak

10. Escalation seviyelerini tanımlamamak

11. İşletme sahibinin sürekli Chain of Command'i atlaması

12. Kritik pozisyonlara yedek yetiştirmemek

13. Gereğinden fazla yönetim katmanı kurmak

14. Bütün çalışanları doğrudan Owner'a bağlamak

15. Organizasyon değiştiği halde SOP ve yetki matrislerini güncellememek

Bu hataların ortak sonucu:

işler yapılır ama sistem kimin yaptığını ve sonucun kime ait olduğunu bilemez.

53. 15 Karar Kapısı — Organizasyonunuz Gerçekten Kurulu mu?

Karar Kapısı 1

Otelin tüm temel fonksiyonları tanımlı mı?

Karar Kapısı 2

Organization Chart güncel mi?

Karar Kapısı 3

Pozisyonlar kişilerden bağımsız mı?

Karar Kapısı 4

Her kritik pozisyonun Job Description'ı var mı?

Karar Kapısı 5

Her çalışan kime rapor ettiğini biliyor mu?

Karar Kapısı 6

Her kritik sürecin Owner'ı belli mi?

Karar Kapısı 7

Sorumluluk ile yetki uyumlu mu?

Karar Kapısı 8

Authority Matrix var mı?

Karar Kapısı 9

Approval Limit'ler belli mi?

Karar Kapısı 10

Departmanlar arası kritik süreçlerde RACI kullanılıyor mu?

Karar Kapısı 11

Escalation seviyeleri tanımlı mı?

Karar Kapısı 12

Gece ve hafta sonu karar yetkisi belli mi?

Karar Kapısı 13

Kritik pozisyonların Backup'ı var mı?

Karar Kapısı 14

Owner organizasyon hattına uyuyor mu?

Karar Kapısı 15

Organizasyon değişiklikleri SOP ve KPI sistemine yansıtılıyor mu?

Bu soruların çoğunun cevabı:

“Evet.”

ise organizasyon şemanız artık yalnızca duvardaki bir grafik değildir.

Gerçek bir yönetim sistemi haline gelmeye başlamıştır.

54. Butik Otel İçin Minimum Organizasyon Doküman Seti

Küçük bir otelde bile aşağıdaki temel dosyalar kurulabilir:

1. Organization Chart
2. Function Map
3. Position Master List
4. Job Description Set
5. Reporting Line Matrix
6. Authority Matrix
7. Approval Limits
8. RACI Matrix
9. Escalation Matrix
10. Duty Manager Matrix
11. Critical Role Register
12. Backup / Cross-Training Matrix
13. Succession Plan
14. Meeting Structure
15. Shift Handover Structure
16. KPI Ownership Matrix
17. Outsourced Function Responsibility Matrix
18. Organization Change Log

Amaç:

daha fazla doküman üretmek değildir.

Amaç:

“Kim ne yapıyor?” bilgisini insanların hafızasından çıkarıp işletmenin sistemine taşımaktır.

55. Yatırımcı İçin Organizasyon Stres Testi

Bir yatırımcı organizasyonunun gücünü birkaç senaryoyla test edebilir.

Senaryo 1

GM üç gün otelde değil.

Kim karar veriyor?

Senaryo 2

Housekeeping Supervisor hastalandı.

Kim Room Ready sürecini yönetiyor?

Senaryo 3

Saat 23.30'da ciddi misafir şikâyeti oluştu.

Kim ne kadar yetkili?

Senaryo 4

Bir oda teknik nedenle OOO olacak.

Kim karar veriyor, kim PMS'i güncelliyor?

Senaryo 5

Yüksek tutarlı refund talebi geldi.

Kim onaylıyor?

Senaryo 6

Yangın alarmı devreye girdi.

Kim Incident Commander?

Senaryo 7

Kritik çalışan istifa etti.

Backup kim?

Bu sorulara cevap vermek için:

“Patronu ararız.”

deniyorsa:

organizasyon henüz tam olarak kurumsallaşmamıştır.

56. Organizasyonun Tam Yönetim Zinciri

Profesyonel bir yapı şu şekilde düşünülebilir:

Hotel Strategy → Service Model → Functions → Organization Chart → Positions → Job Descriptions → Responsibilities → Authority → Approval Limits → RACI → Escalation → Staffing → Competency → Recruitment → Training → Daily Operation → KPI → Performance Review → Organization Review → Improvement

Bu zincirde organizasyon şeması:

başlangıç noktalarından biridir.

Ama tek başına sistem değildir.

57. Organizasyonun Gerçek Testi

Bir otelde organizasyonun çalışıp çalışmadığını anlamak için şu üç soruyu rastgele çalışanlara sorun:

1.

“Senin temel sorumluluğun nedir?”

2.

“Bu konuda hangi kararı kendin verebilirsin?”

3.

“Yetkinin dışına çıkarsa kime gidersin?”

Çalışanlar bu sorulara:

net,

benzer

ve:

tereddütsüz

cevap verebiliyorsa:

organizasyon büyük ölçüde anlaşılmıştır.

Eğer cevaplar kişiden kişiye değişiyorsa:

duvarda organizasyon şeması olabilir.

Ama:

sahada organizasyon henüz oluşmamıştır.

Sonuç: Organizasyon Şeması Kutular Değil, Karar Sistemidir

İyi bir organizasyon şeması:

yalnızca kimin kime bağlı olduğunu göstermez.

Şunu da açıklar:

Kim ne yapacak?

Kim sonuçtan sorumlu?

Kim hangi kararı verebilir?

Yetkinin sınırı nedir?

Kim bilgilendirilecek?

Problem ne zaman yukarı taşınacak?

Bir kişi yoksa görevi kim devralacak?

Bu nedenle profesyonel otel organizasyonu:

Organization Chart + Job Description + Responsibility + Authority + RACI + Escalation + Backup

bütünüdür.

Küçük otellerde bazı insanlar birden fazla rol üstlenebilir.

Bu normaldir.

Ancak:

insanların esnek olması, organizasyonun belirsiz olması gerektiği anlamına gelmez.

Tam tersine küçük ekiplerde rol netliği daha da önemlidir.

Çünkü tek bir sorumluluk boşluğu bütün operasyonu etkileyebilir.

İyi kurulmuş bir organizasyonda çalışan:

ne yapacağını bilir.

Supervisor:

neyin sonucundan sorumlu olduğunu bilir.

Manager:

hangi kararın kendisinde olduğunu bilir.

General Manager:

neyin escalate edilmesi gerektiğini bilir.

Owner ise:

her küçük kararın merkezinde olmak zorunda kalmaz.

Ve organizasyonun gerçek başarısı tam olarak burada görülür:

İşletme sahibinin her şeye karar verdiği otel güçlü değildir. Doğru kararların, doğru seviyede, doğru insanlar tarafından alınabildiği otel güçlüdür.

Otel Yatırım Rehberi — Cilt VI

Cilt VI — Yönetim, otelin günlük operasyonunun arkasındaki yönetim sistemini ele alır. İnsan kaynakları bölümünde organizasyon tasarımından görev tanımlarına, personel planlamasından işe alıma, eğitimden performansa, yetkilendirmeden çalışan bağlılığına kadar insan sistemi bütünsel olarak incelenmektedir.

Amaç yalnızca çalışanların olduğu bir otel kurmak değil;

görevlerin, yetkilerin, sorumlulukların ve karar mekanizmalarının çalışan değişse bile ayakta kaldığı bir organizasyon oluşturmaktır.