Seyahat Endüstrisi ERP Uygulaması: GDS, Kanal Yöneticisi ve CRM
Bir seyahat şirketinde ERP'yi uygulamak, ticari dünyadaki en karmaşık dış veri ekosistemlerinden bazılarına bağlanmayı gerektirir. GDS sistemleri, milyonlarca uçuş segmenti, otel ve araç kiralama için gerçek zamanlı envanter tutar ve fiyatları günde binlerce kez değişir. Kanal yöneticileri otel envanterini aynı anda onlarca çevrimiçi seyahat acentesine dağıtır. Müşteri veritabanları, onlarca yıldır acenteyle rezervasyon yapan müşterilerin seyahat geçmişini ve tercihlerini tutar.
Her entegrasyonun kendi teknik standartları, veri formatları ve performans gereksinimleri vardır. GDS bağlantısı, onlarca yıl önce geliştirilen EDIFACT veya XML tabanlı mesajlaşma protokollerini gerektirir. Kanal yöneticisi API'leri satıcıya göre değişir. CRM geçişi, seyahat acentesinin en değerli rekabet varlığı olan ilişki geçmişini korumalıdır.
Bu kılavuz, seyahat uygulamalarını diğer sektörlerden ayıran harici sistem entegrasyonlarına özel önem vererek, seyahat ERP uygulaması için uygulayıcı düzeyinde bir çerçeve sunmaktadır.
Önemli Çıkarımlar
- GDS entegrasyonu, yerel API bağlantısı veya doğrudan tedarikçi API'leri aracılığıyla GDS'den bağımsız rezervasyon gerektirir
- Kanal yöneticisi entegrasyonu, gerçek zamanlı envanter güncellemelerini her iki yönde de saniyeler içinde gerçekleştirmelidir
- Müşteri veri geçişi, ilişki kalitesini korumak için onlarca yıllık seyahat geçmişini korumalıdır
- Yeni sistemde herhangi bir rezervasyon oluşturulmadan önce çoklu para biriminden oluşan finansal kurulumun tamamlanması gerekir
- Tedarikçi sözleşmesi ve tahsis verilerinin taşınması, dijital girişten önce mevcut şartların yasal olarak incelenmesini gerektirir
- ATOL ve mevzuata uygunluk yapılandırması, düzenlenen ilk işlemden önce doğrulanmalıdır
- Gelir tahakkuku yapılandırmasının mali yıl sonundan önce dış denetçi tarafından gözden geçirilmesi gerekir
- Personel eğitimi, istisna senaryoları (iptaller, değişiklikler, şikayetler) dahil olmak üzere tüm rezervasyon iş akışını içermelidir
Uygulama Öncesi: Sistem Ekosistem Haritalaması
ERP uygulamasını planlamadan önce, seyahat işletmesinin halihazırda kullandığı sistem ekosisteminin tamamını haritalandırın:
| İşlev | Mevcut Sistem | Kal/Değiştir/Entegrasyon |
|---|---|---|
| GDS rezervasyonları | Amadeus/Sabre/Travelport | Entegrasyon |
| Tur paketleme | Eski TourOp sistemi | Değiştir |
| Otel kanal yönetimi | SiteMinder/RateGain | Entegrasyon |
| Alacak hesapları | Elektronik Tablo | Değiştir |
| Komisyon takibi | Elektronik Tablo | Değiştir |
| Müşteri veritabanı | Eski CRM veya veritabanı | ERP CRM'ye Geçiş |
| Finans/GL | Bağımsız muhasebe | Değiştir |
| Tedarikçi ödemeleri | Kılavuz/bankacılık portalı | Değiştir |
Bu eşleme, entegrasyon mimarisini ve veri taşıma kapsamını belirler. "Entegre" olarak işaretlenen sistemler API bağlantıları gerektirir; "Değiştir" olarak işaretlenen sistemler tam veri geçişini gerektirir.
1. Aşama: Finans Temeli ve Çoklu Para Birimi Kurulumu (1-3. Aylar)
Seyahat Hesap Planı
Seyahat şirketi hesap planı şunları desteklemelidir:
- Ürün türüne göre gelir (paketler, uçuşlar, oteller, geziler, sigorta)
- Satış kanalına göre gelir (doğrudan, acente, çevrimiçi, kurumsal)
- Mevduat ve avans ödemeleri için ertelenmiş gelir
- Brüt gelir ve net gelir (tedarikçi satış maliyetlerinden sonra)
- Paket gelirinden ayrı olarak komisyon geliri (perakende acenteleri için)
- Çoklu para birimi işlemleri için para birimi çeviri hesapları
Çoklu Para Birimi Yapılandırması
Uluslararası seyahat operatörleri için çoklu para birimi yapılandırması en kritik finans kurulum görevidir. Bu şunları içerir:
- Temel raporlama para biriminin tanımlanması
- Döviz kuru kaynaklarını yapılandırma (manuel günlük giriş, merkez bankası beslemesi veya hazine yönetimi API'si)
- Her işlem türü için para birimi çeviri kurallarının oluşturulması (rezervasyon tarihi oranı - ödeme tarihi oranı - dönem ortalama oranı)
- Çok para birimli banka hesaplarının ve ödeme yöntemlerinin kurulması
- Ay sonu döviz değerleme sürecinin yapılandırılması
Rezervasyonlar girildikten sonra keşfedilen para birimi yapılandırma hatalarının, işlemleri geri alıp yeniden girmeden düzeltilmesi son derece zordur. Bu yapılandırmanın, herhangi bir gerçek rezervasyon oluşturulmadan önce örnek işlemlerle test edilmesi ve doğrulanması gerekir.
Ertelenmiş Gelir Yapılandırması
Ertelenmiş gelir yapılandırması, her rezervasyon türü için muhasebeleştirme planını tanımlamalıdır:
- Depozitolar: Seyahat tarihine kadar yükümlülük olarak kabul edilir
- Peşin alınan son ödemeler: Hizmetler teslim edildikçe aşamalı olarak kabul edilir
- Rezervasyona gelmeme geliri: Bir müşteri iptal etmeden rezervasyona gelmediğinde, gelirin ne zaman ve nasıl kaydedileceği şirketin muhasebe politikası tarafından tanımlanmalıdır.
Seyahat gelirinin nasıl ele alındığı yoruma tabi olabileceğinden ve uygulama sonrası denetçiyle anlaşmazlıklar yıkıcı olabileceğinden, bu yapılandırma, hayata geçirilmeden önce dış denetçi tarafından incelenmelidir.
2. Aşama: Tedarikçi ve Ürün Kataloğu Kurulumu (2-5. Aylar)
Tedarikçi Ana Verileri
Tedarikçi veri tabanı tüm aktif tedarikçilerle doldurulmalıdır: kruvaziyer şirketleri, oteller, havayolları, yer operatörleri, sigorta şirketleri, araç kiralama şirketleri ve vize hizmetleri. Her tedarikçi için ERP'nin aşağıdakilere ihtiyacı vardır:
- Tedarikçi iletişim bilgileri ve hesap numaraları
- Ödeme koşulları ve tercih edilen ödeme yöntemi
- Faturalama ve ödeme için para birimi
- Komisyon oranı programları ve geçersiz kılma eşikleri
- İptal ve değişiklik politikaları (müşteri rezervasyonlarında iptal ücreti hesaplamalarını yönlendiren)
Tedarikçi verilerinin, etkin olmayan tedarikçilerin kaldırılması ve iletişim bilgilerinin güncellenmesi için yapılan bir incelemeden sonra mevcut tedarikçi veritabanından taşınması en iyisidir.
Ürün Kataloğu Yapılandırması
Ürün kataloğu bir tur operatörünün temel konfigürasyonudur; acentelerin rezervasyon yapabileceği her satılabilir ürünü tanımlar. Orta ölçekli bir tur operatörü için bu şunları içerebilir:
- 50-200 temel tur ürünü (seyahat planları, kalkış tarihleri, kabin/oda kategorisine göre fiyatlandırma)
- Oda tipleri ve sezonluk fiyatlara sahip 500-2.000 otel mülkü
- Varış noktasına göre 20-50 yer operatörü hizmeti
- 10-25 seyahat sigortası ürünü
Bu kataloğun yapılandırılması, her tedarikçi sözleşmesi ve tahsis sözleşmesindeki verileri gerektirir. Veri girişi çabası oldukça önemlidir; tek bir kişinin kataloğun tamamını girmesi ve doğrulaması için 4-8 haftalık bir bütçe gerekir.
Parti ve Getiri Yönetimi Kurulumu
Sözleşmeli tahsisleri olan tur operatörleri için tahsis yönetimi yapılandırması şunları içerir:
- Tahsis sözleşmesi koşulları (oda/kabin sayısı, kategori başına fiyat, çıkış tarihleri)
- Minimum ve maksimum grup boyutları
- Çocuk indirimleri ve tek ek ücretler
- Satış durdurma tarihleri (envanterin sunulamadığı kesinti dönemleri)
Aşama 3: GDS Entegrasyonu (3-7. Aylar)
GDS entegrasyonu teknik olarak seyahat ERP uygulamasındaki en karmaşık entegrasyondur. GDS, endüstri standardı XML veya EDIFACT mesaj formatlarını kullanarak iletişim kurar; ERP'nin kendi veri modeli ile GDS mesaj formatı arasında çeviri yapması gerekir.
Entegrasyon Mimarisi Seçenekleri
GDS entegrasyonu için üç mimari seçeneği mevcuttur:
-
Doğrudan GDS API bağlantısı: ERP, sertifikalı API (SOAP/XML veya REST) aracılığıyla doğrudan GDS'ye bağlanır. Bu, en fazla kontrolü sağlar ancak 6-12 ay sürebilen resmi bir test ve onay süreci olan GDS sertifikasyonunu gerektirir.
-
Ara katman yazılımı/toplayıcı: Üçüncü taraf bir ara katman yazılımı platformu (Verteil, Duffel, Kiwi.com API), ERP ile GDS arasında yer alır ve GDS protokolünün karmaşıklığını yönetir ve ERP'ye daha basit bir API sunar. Bu, entegrasyon çabasını azaltır ancak rezervasyon başına maliyet ekler.
-
Rezervasyon portalı entegrasyonu: ERP, doğrudan GDS API yerine GDS terminal rezervasyon sistemiyle entegre olur ve tamamlandıktan sonra rezervasyon verilerini yakalar. Bu teknik olarak daha basittir ancak ERP odaklı rezervasyon iş akışlarını desteklemez.
Çoğu seyahat ERP uygulaması için ara katman yazılımı/toplayıcı seçeneği, yetenek ve uygulama hızı arasında en iyi dengeyi sağlar.
GDS Veri Haritalaması
GDS, uçuş müsaitliğini ve fiyatlarını yapılandırılmış XML veya EDIFACT mesajlarıyla döndürür. Bu verileri ERP rezervasyon veri modeliyle eşlemek şunları gerektirir:
- Uçuş segmenti verileri (havayolu şirketi, uçuş numarası, kalkış/varış saatleri, hizmet sınıfı, duraklar)
- Ücret verileri (ücret esas kodu, toplam ücret, vergi dökümü, biletleme son tarihi)
- Rezervasyon sınıfının kullanılabilirliği (her ücret sınıfında mevcut koltuk sayısı)
ERP'nin, rezervasyon acentelerine doğru fiyatlandırma ve müsaitlik durumunu göstermek için bu mesajları doğru şekilde ayrıştırması gerekir.
Biletleme Entegrasyonu
Uçuş rezervasyonu onaylandıktan sonra biletin düzenlenmesi gerekir; bu, uçak bileti belgesinin oluşturulması ve ödemenin havayoluna iletilmesi sürecidir. Biletleme, Elektronik Çeşitli Belgeler (EMD) veya geleneksel uçak bileti numaraları kullanılarak GDS aracılığıyla gerçekleştirilir. ERP biletleme iş akışı aşağıdakileri gerçekleştirmelidir:
- Rezervasyon onayında otomatik biletleme (hemen ödeme işlemleri için)
- Biletleme son tarihi takibi ile ertelenmiş biletleme
- Bilet değişiklikleri ve iadeleri (uygun havayolu ücreti kesintisi ile)
- Havayolu uzlaşması net bilet satışlarına ilişkin gelir muhasebesi
4. Aşama: Kanal Yöneticisi Entegrasyonu (3-8. Aylar, Oteller)
Konaklama işletmeleri (oteller, pansiyonlar, konaklama bileşenleri olan küçük tur operatörleri) için kanal yöneticisi entegrasyonu, envanter ve fiyatlandırmanın tüm dağıtım kanallarında tutarlı olmasını sağlar.
Kanal Yöneticisi Mimarisi
Kanal yöneticileri (SiteMinder, RateGain, Cloudbeds), otelin mülk yönetim sistemi ile OTA kanalları (Booking.com, Expedia, Airbnb) arasında bir merkez görevi görür. ERP'nin aşağıdakileri gerçekleştirmek için kanal yöneticisiyle entegre olması gerekir:
- Oda envanteri ve fiyat güncellemelerini kanal yöneticisine iletin (onları OTA'lara dağıtır)
- Kanal yöneticisinden rezervasyon bildirimleri alın (OTA'dan rezervasyon alındığında)
- Rezervasyon onaylandığında odaları tüm kanallarda tükenmiş olarak işaretleyin
Gerçek Zamanlı Envanter Güncelleme Gereksinimleri
Kanal yöneticisi entegrasyonu neredeyse gerçek zamanlı olmalıdır. Bir oda bir kanal üzerinden satılıyorsa ve diğer kanallara güncelleme birkaç dakikadan uzun sürüyorsa talebin yoğun olduğu dönemlerde fazla rezervasyon yapılması muhtemeldir. Entegrasyon, planlanmış yoklama (ERP belirli bir zaman aralığında yeni rezervasyonları kontrol eder) yerine webhook geri aramalarını (kanal yöneticisi bir rezervasyon alındığında ERP'ye hemen bilgi verir) kullanmalıdır.
Kur Paritesi Yönetimi
Pek çok otelin OTA'larla fiyat eşitliği anlaşmaları vardır; kendi doğrudan kanalları üzerinden sundukları fiyatların aynısını veya daha düşük fiyatları OTA aracılığıyla sunmayı taahhüt ederler. Kanal yöneticisi entegrasyonu, ERP fiyatlandırma değişikliklerinin tüm bağlı kanallara aynı anda doğru şekilde iletilmesini sağlayarak oran eşitliğini uygulamalıdır.
Aşama 5: CRM ve Müşteri Verilerinin Geçişi (5-9. Aylar)
Müşteri Veritabanı Taşıma
Seyahat şirketleri için müşteri verilerinin taşınması, derinliği ve değeri açısından benzersizdir. 20 yaşındaki bir seyahat acentesinin, yirmi yıl öncesine uzanan tam seyahat geçmişine sahip müşteri kayıtları olabilir: 2004'teki Karayip gezisi, 2009'daki Afrika safarisi, 2015'teki Ren nehri gezisi. Bu tarih, ilişkiye dayalı satışın hammaddesidir.
Taşıma Kapsamı
Müşteri geçişi şunları içermelidir:
- İletişim bilgileri (isim, adres, e-posta, telefon, pasaport bilgileri)
- Seyahat geçmişi (tarihler, varış yerleri, ürünler ve harcamalarla birlikte tamamlanan tüm rezervasyonlar)
- Tercihler (kabin kategorisi, beslenme gereksinimleri, tercih edilen havayolları, yıldönümü tarihleri)
- Sadakat bakiyeleri ve kademe durumu
- İletişim tercihleri ve katılım geçmişi
- Mali bilgiler (kayıtlı ödeme yöntemleri, kredi limitleri, ödenmemiş bakiyeler)
Veri Kalitesi Hazırlığı
Geçişten önce müşteri veri kalitesi incelemesini gerçekleştirin:
- Yinelenen müşteri kayıtlarını tanımlayın ve birleştirin (aynı müşteri birden çok kez girildi)
- Pasaportun son kullanma tarihlerini doğrulayın (süresi dolan pasaportlar güncel olarak taşınmamalı, işaretlenmelidir)
- Sadakat puanı bakiyelerini uzlaştırın (sistemin gösterdiğinden daha fazla puana sahip olduğuna inanan müşteriler)
- Etkin olmayan müşterileri taşımak yerine arşivleyin (7+ yıldır rezervasyon yok)
İlişki Değerinin Korunması
Seyahat danışmanları ile uzun vadeli müşteriler arasındaki ilişki geçmişi, acentenin en değerli varlığıdır. Yeni sistemin müşteri kişilerini tercih ettikleri danışmana doğru şekilde yönlendirmesi için seyahat danışmanı atamalarının her müşteri kaydıyla birlikte taşındığından emin olun.
Aşama 6: Eğitim ve Canlı Yayına Geçiş Hazırlığı
Rol Tabanlı Eğitim
Seyahat ERP eğitimi role özgü olmalıdır:
- Seyahat danışmanları: Tam rezervasyon iş akışı (arama, fiyatlandırma, rezervasyon, değişiklik ve iptal) artı müşteri profili yönetimi ve sadakat programı yönetimi
- Finans personeli: Ertelenmiş gelir yönetimi, tedarikçi ödeme planlaması, komisyon mutabakatı ve para biriminin yeniden değerlemesi
- Operasyon personeli (DMC'ler, tur operatörleri): Yer operasyonlarının planlanması, rehber yönetimi, araç sevkiyatı
- Yönetim: Raporlama ve analizler — ürüne göre rezervasyon hacmi, kanala göre gelir, müşteriyi elde tutma ölçümleri
Rezervasyon İş Akışı Testi
Canlı kullanıma geçmeden önce gerçekçi senaryolarla uçtan uca rezervasyon iş akışı testleri yapın:
- Uçuş, otel ve transfer dahil FIT (Yabancı Bağımsız Seyahat) rezervasyonunu tamamlayın
- Depozito, taksit ödemesi ve son ödeme ile grup rezervasyonu
- Ceza hesaplaması ve iade işlemi ile iptal
- Değişiklik (Rezervasyon sonrası kalkış tarihinin değiştirilmesi, fiyatların yeniden hesaplanması)
- Şikayetlerin ele alınması (hizmet kalitesi şikayetinin kaydedilmesi ve çözülmesi)
Her senaryo sadece uygulama ekibi tarafından değil, üretimde gerçekleştirecek personel tarafından da test edilmelidir.
Sıkça Sorulan Sorular
Uygulamaya geçiş sırasında döngünün ortasında olan geçmiş rezervasyon verilerini nasıl ele alırız?
Geçiş sırasında aktif olan (onaylanmış ancak henüz seyahat edilmemiş) rezervasyonlar, ilgili tüm verilerle birlikte yeni sisteme taşınmalıdır: rezervasyon durumu, bileşen ayrıntıları, ödeme geçmişi, ödenmemiş bakiye ve tedarikçi ödeme planı. Bu "uçuş sırasındaki" rezervasyonlar, çok dikkatli bir geçiş gerektirir çünkü hatalar, yakın zamanda seyahat etmeyi bekleyen müşterileri etkiler. Üretim geçişini taahhüt etmeden önce, etkin ayırmaların bir örneğinin geçişini eski sistem kayıtlarıyla karşılaştırarak test edin.
Yeni ERP'de ATOL uyumluluğunun düzenleyici etkisi nedir?
ATOL uyumluluğu, her ATOL korumalı rezervasyonun doğru şekilde tanımlanmasını, ATOL vergisinin (şu anda yolcu başına 2,50 £) hesaplanmasını ve hesaba katılmasını ve CAA'ya yapılan yıllık ATOL iadelerinin doğru yolcu hacimlerini içermesini gerektirir. ERP, hangi rezervasyonların ATOL korumalı olduğunu (genellikle Birleşik Krallık'ta satılan bir uçuşu içeren paketler) belirlemek, her biri için vergiyi hesaplamak ve raporlamak ve yıllık ATOL iade verilerini oluşturmak için yapılandırılmalıdır. Bu yapılandırmanın, ilk korumalı ayırma yeni sistemde işlenmeden önce bilinen ATOL korumalı ayırma senaryolarına göre test edilmesi gerekir.
GDS sertifikasyonu ne kadar sürer ve tamamlanmadan yayına geçebilir miyiz?
Doğrudan API entegrasyonu için GDS sertifikasyonu (Amadeus, Sabre, Travelport) genellikle 6-12 ay sürer ve teknik testleri, güvenlik incelemesini ve GDS tarafından resmi onayı içerir. Sertifikasyon dönemi boyunca acenteler, diğer ERP fonksiyonları etkinken uçuş rezervasyonları için eski GDS terminalini kullanmaya devam edebilirler. Alternatif olarak, doğrudan GDS entegrasyonu yerine bir ara katman yazılımı toplayıcının kullanılması, sertifika gerekliliğini ortadan kaldırır ve daha hızlı hayata geçirmeyi sağlar.
Uygulama, uzaktan çalışan seyahat danışmanlarını nasıl ele alıyor?
Modern bulut ERP platformlarına internete bağlı herhangi bir cihazdan tam olarak erişilebilmesi, ek altyapı olmadan uzaktan çalışmaya olanak sağlar. Evden çalışan seyahat danışmanları ERP'ye bir web tarayıcısı aracılığıyla erişir. Mobil erişim, danışmanların müşteri taleplerine her yerden hizmet vermelerini sağlar. Güvenlik kontrolleri (MFA, IP kısıtlaması, oturum zaman aşımı), uzak çalışma ortamlarında müşteri verilerini korur.
Her müşterinin seyahat geçmişi için hangi verileri taşımamız gerekiyor?
Her müşteri için taşınacak minimum seyahat geçmişi verileri şunları içerir: rezervasyon referansı, seyahat tarihleri, varış noktası, ürün türü, yolcu sayısı, toplam rezervasyon değeri, ödeme durumu ve atanan seyahat danışmanı. İdeal olarak, bileşen dökümü, tedarikçi adları, kabin/oda kategorisi gibi tüm rezervasyon ayrıntılarının da ilişkiye dayalı satış konuşmaları için gereken tam bağlamı sağlayacak şekilde taşınması gerekir.
Sonraki Adımlar
ERP uygulamasını planlayan seyahat şirketleri, entegrasyon ve geçiş gereksinimlerinin tüm kapsamını anlamak için bir sistem ekosistemi haritalaması ve tedarikçi veri denetimi ile başlamalıdır. ECOSIRE'ın Odoo uygulama uygulaması, GDS entegrasyon uzmanlığı, kanal yöneticisi bağlantıları ve çoklu para birimi finansal yönetimi ile seyahat ve turizm ERP uygulamaları sunar.
Seyahat sektörü uzmanlığımızın, rezervasyon yönetiminden finansal raporlamaya kadar ERP dönüşümünüze nasıl rehberlik edebileceğini öğrenmek için ECOSIRE'ın Odoo ERP Uygulama hizmetlerini keşfedin.
Yazan
ECOSIRE Research and Development Team
ECOSIRE'da kurumsal düzeyde dijital ürünler geliştiriyor. Odoo entegrasyonları, e-ticaret otomasyonu ve yapay zeka destekli iş çözümleri hakkında içgörüler paylaşıyor.
İlgili Makaleler
Multi-Currency Accounting: Setup and Best Practices
Complete guide to multi-currency accounting setup, forex revaluation, translation vs transaction gains, and best practices for international businesses.
Odoo Accounting vs QuickBooks: Detailed Comparison 2026
In-depth 2026 comparison of Odoo Accounting vs QuickBooks covering features, pricing, integrations, scalability, and which platform fits your business needs.
AI + ERP Integration: How AI is Transforming Enterprise Resource Planning
Learn how AI is transforming ERP systems in 2026—from intelligent automation and predictive analytics to natural language interfaces and autonomous operations.