Havacılıkta ERP: Uçak Başına Kârlılığı Hesaplayamıyorsanız Sistemi Yanlış Kurmuşsunuz

Bir havacılık şirketinin operasyon müdürü size ‘sistemimiz var, her şeyi kayıt altına alıyoruz’ dediğinde şu soruyu sormanız yeterli: ‘Hangi uçağın, hangi sözleşme kapsamında, bu ay sizi zarara uğrattığını beş dakikada gösterebilir misiniz?’ Bu sorunun cevabı çoğunlukla sessizlik oluyor. ERP kurulu, muhasebe çalışıyor, bakım kayıtları düzgün tutuluyor — ama uçak başına gerçek kârlılık hesabı hâlâ yöneticinin kafasında, bir Excel sayfasında ya da ortada hiçbir yerde. İşte tam bu noktada sivil havacılıkta ERP uygulamalarının neden sık sık yarım kaldığını anlıyorsunuz.Tezimi açık söylemeliyim: havacılık şirketleri ERP’yi önce bakım ve teknik modülle hayata geçiriyor, sözleşme ve kârlılık yönetimini ise ‘sonraki aşamaya’ bırakıyor. Bu tercih değil, kaderci bir erteleme. Bakım takibi olmadan hava aracını uçaramazsınız, doğru. Ama sözleşme kârlılığını modellemeden ERP kurmak, fabrika ekipmanını sigortalayıp ürün maliyetini bilmemek gibi bir şey. Sistem çalışıyor görünür, işler yürüyor; yalnızca hangi işin sizi zenginleştirip hangisinin tükettiğini anlamazsınız.Ankara merkezli, ağırlıklı olarak charter ve özel jet kiralama hizmetleri veren orta ölçekli bir havacılık şirketinde (412 çalışan, sekiz uçaklık filo) yürütülen bir ERP projesinde bu dinamiği net biçimde gözlemledim. Şirketin teknik direktörü, projeye başlamadan önce iki kritik şeyin tanımlı olduğuna emindi: bakım döngüleri ve rota planlaması. Ancak müşteri sözleşmeleri incelendiğinde tablo oldukça karmaşıklaştı. Sekiz uçak için yirmi dörtten fazla farklı sözleşme şablonu vardı; bazıları saatlik uçuş bedeli esasına dayanıyor, bazıları aylık garanti ödeme içeriyor, bir kısmı ise yakıt maliyetini müşteriye yansıtırken diğerleri sabit ücrete dahil ediyordu. ERP standart bakım modülü bunların hiçbirini birbiriyle konuşturamıyordu. Sistem bakım maliyetini kaydediyordu — ama hangi sözleşmenin o maliyeti karşılayıp karşılamadığını göremiyordu.Bu yapının çözülmesi için atılması gereken ilk adım teknik değil, kavramsal. Şirketteki ‘kâr merkezi’ tanımı netleşmeden ERP’de ne kurarsanız kurun, modüller birbirinden kopuk çalışmaya devam eder. Havacılıkta kâr merkezi uçak mı, müşteri sözleşmesi mi, yoksa rota mı? Bu üçünün cevabı farklı şirketlerde farklı çıkıyor ve ERP’nin konfigürasyonu bu tanıma göre şekilleniyor. Bahsettiğim Ankara projesinde 14 haftalık bir analiz süreciyle sözleşme yapısı dörde indirildi, her uçağa maliyet merkezi atandı ve bakım döngüleriyle sözleşme garanti saatleri aynı tabloya işlendi. Bu adım atılmadan kurulan herhangi bir modül zamanla kendi içine kapanan bir ada haline geliyor.Pratik zorlukların başında muhasebe ile operasyon arasındaki veri farklılıkları geliyor. Muhasebe ekibi uçuş saatlerini fatura kesme birimi olarak kaydediyor; teknik ekip aynı saati bakım eşiği olarak takip ediyor; operasyon koordinatörü ise bunu kapasite planlaması için kullanıyor. Üç farklı departman, aynı veriyi üç farklı biçimde tutuyor ve ERP projesi başlayıncaya kadar bu tutarsızlığın farkında olan neredeyse kimse yok. Entegrasyon toplantısında bu tablo ortaya çıktığında şirketin CFO’su ‘bunları zaten biliyorduk’ dedi. Ama bilmekle kayıt altına alıp sistem üzerinden karşılaştırmak arasındaki mesafe, projenin neden gerekli olduğunun en kısa açıklaması.Bakım modülü kendi içinde yeterince karmaşık. Sivil havacılıkta her uçak için Sivil Havacılık Genel Müdürlüğü’nün (SHGM) zorunlu kıldığı düzenli bakım döngüleri var; bunlar saatlik (A, B, C, D kontrolü) ve takvim bazlı olabiliyor. ERP bu döngüleri takip edecek şekilde yapılandırılmazsa bakım hatırlatmaları yine Excel’de, bakım sorumlusunun not defterinde ya da belki sadece deneyimli bir teknisyenin hafızasında kalıyor. Sekiz uçaklı filoda bu belki yönetilebilir. On altı uçağa geçtiğinizde sistem olmadan hata payı tehlikeli biçimde büyüyor. Projedeki çözüm, her uçak için SHGM döngülerini ERP içinde bağımsız zaman-saat kombinasyonları olarak tanımlamak ve bir eşiğe 48 saat kala otomatik uyarı oluşturmaktı. Bu tek özellik, projeyi meşrulaştırmak için yeterince güçlü bir argüman oldu.Bir diğer konu, personel ve sertifikasyon yönetimi. Pilotların uçuş saati sınırları, tüm teknik personelin geçerli SHGM onaylı lisansları ve simülatör eğitim takvimleri — bunların hepsi denetim sırasında belgelenebilir olması gereken veriler. Bu verileri muhasebeden, İK’dan ve teknik birimden ayrı ayrı toplayıp raporlamak hem zaman alan hem de hata riski taşıyan bir süreç. ERP’nin İK modülü sertifikasyon bitiş tarihlerini ve yenileme eşiklerini işaret ettiğinde bu bilgi otomatik olarak tek bir noktaya toplanıyor. Bahsettiğim projede bu modülün kurulumu toplam proje süresinin yaklaşık %46’sını aldı; teknik ekibin en çok değer atfettiği alan da burası oldu.Satın alma ve envanter yönetimi, havacılık ERP’sinin görece daha anlaşılır ama küçümsenmemesi gereken bir diğer bileşeni. Yedek parça stoğu havacılıkta hem kritik hem de pahalı. Stokta tutmak sermaye bağlıyor; stokta tutmamak ise operasyonel risk doğuruyor. ERP’nin satın alma modülü minimum stok eşiği ve tedarikçi teslim süresi kombinasyonuyla yeniden sipariş noktasını otomatik hesapladığında hem gereksiz stok hem de ani temin çabası azalıyor. Bu proje kapsamında yedek parça kategorileri ilk kez sistematik biçimde SHGM gereklilikleri doğrultusunda sınıflandırıldı — ve bu sınıflandırma, satın alma sürecindeki önceliklendirmeyi de yeniden yapılandırdı.Sonuç olarak sivil havacılıkta ERP, bakım takibinden ibaret bir yazılım değil; sözleşme yapısı, kâr merkezi tanımı ve düzenleyici gereklilikler doğru modellenmediğinde hiçbir teknik modülün bu açığı kapatamayacağı bir iş yönetim aracı. Ankara projesinin çıkardığı en sert ders şuydu: teknik direktör değiştiğinde beraberinde o kişinin hafızasında taşınan on yıllık operasyonel bilgi de gidiyor. ERP bu bilgiyi kurumun sistemine yazan şey. Eğer yöneticiniz size ‘önce bakım modülü, sözleşme yönetimi sonra’ diyorsa, ona şunu sorun: o ‘sonra’ ne zaman gelecek? Çünkü çoğu zaman gelmiyor.