Şikâyet sayısı düşüyordu, ama yolcu memnuniyeti de düşüyordu. Bu paradoks, 2015 yılı başında İstanbul merkezli orta ölçekli bir havayolu catering firmasında sahada karşılaştığım tablonun tam özüydü. Firma, 378 çalışanıyla hem charter hem de düzenli sefer operasyonlarına hizmet veriyordu; aylık sekiz ila on bin yemek porsiyonunu hazırlayıp uçuşlara teslim ediyordu. Yönetim kurulu, şikâyet rakamlarındaki düşüşü başarı göstergesi olarak okuyordu. Oysa saha bambaşka bir şey söylüyordu: şikâyetler kayıt altına alınmıyor, bazıları informal kanallardan çözülüyor, bir kısmı ise hiç görünmez hale getiriliyordu. Şikâyet yönetimi sisteminin kendisi, sorunun hem ilk hem de son savunma hattıydı. Bu makale o deneyimden yola çıkarak tek bir tezi savunuyor: havayolu catering operasyonlarında ERP tabanlı şikâyet takibi kurulmadan önce departmanlar arası sorumluluk sınırlarının netleştirilmesi şarttır; bu sınırlar çizilmeden kurulan her sistem şikâyetleri kayıt altına alır ama kök nedeni asla bulamaz.Catering operasyonunun şikâyet yönetimi açısından en aldatıcı yanı, sorumluluk zincirinin görünürde çok net, gerçekte ise son derece muğlak olmasıdır. Mutfak üretim departmanı tarif uyumunu ve porsiyonlamayı kontrol eder; lojistik departmanı araç ve soğuk zincir süreçlerini yönetir; uçuş operasyon ekibi teslim zamanlamasını ve troley yerleşimini belirler. Bir yolcu ‘soğuk yemek’ şikâyetinde bulunduğunda bu üç departmanın her biri farklı bir kök nedene işaret eder: mutfak ‘gıda biz gönderirken sıcaktı’ der, lojistik ‘araç soğuk zinciri korudu’ der, operasyon ‘uçuşa giriş saatinde teknik gecikme vardı’ der. Bu ayrışma tesadüf değildir; sistem şikâyetin sahibini değil, şikâyetin kaydını tuttuğunda ortaya çıkar. Dolayısıyla kök neden analizi teknik bir sorun değil, önce organizasyonel bir tasarım sorunudur.Peki bu ayrışmayı nasıl çözüyorsunuz? Yaygın yaklaşım, şikâyeti alan departmana sahipliği vermek ve ardından o departmanı raporlamakla sorumlu tutmaktır. Bu yaklaşımın mantıklı göründüğü yerde tam olarak başarısız olduğu nokta şudur: şikâyeti alan departman aynı zamanda o şikâyetin kök nedenini araştıran taraftır. Hakem ile sanığı aynı sandalyeye oturtmak gibi bir şeydir bu. İstanbul’daki projede üretim departmanı, teslim gecikmesiniydi. Lojistik ekibi ise paketleme hatasını gösteriyordu. Üçüncü ay raporlarında şikâyetlerin yüzde 57’sinin ‘operasyonel gecikmeden kaynaklı’ olarak kodlandığı görüldüğünde, bu rakamın operasyon ekibi tarafından girildiğini de not etmek gerekiyordu. Rakamlara güvenmek için önce rakamların nereden geldiğine bakmak zorundasınız. ERP sisteminin veri kalitesi, o veriye kimin müdahil olabileceğiyle doğrudan ilişkilidir.Projenin ilk sekiz haftasında yapılan ihtiyaç analizi, sistemin teknik kapasitesinden çok kullanıcı davranışı ve veri girişi alışkanlıkları üzerine yoğunlaştı. Sahada gördüğümüz tablo şuydu: şikâyetlerin üçte biri vardiyalı çalışanlar tarafından forma değil, bir WhatsApp grubuna not düşülerek iletiliyordu. Shift süpervizörü o mesajları gün sonunda sisteme aktarmayı çoğu zaman unutuyordu ya da ‘çözüldü’ diye kayıt açmıyordu. Bu davranışın kökünde teknik bir sorun yoktu; çalışanlar sistemin yavaş ve formun uzun olduğunu söylüyordu. Sekiz alanlı şikâyet kayıt ekranını doldurmanın ortalama 4,5 dakika sürdüğünü ölçtüğümüzde şaşırmadık. Bir müşteri hizmetleri çalışanı bu süreyi çoğu zaman ‘zaten çözülecek şeyi niye kayıt altına alıyorum’ mantığıyla geçiştirir. Kullanıcı deneyimi tasarımını ihmal eden bir şikâyet sistemi, sisteme değil telefona yönlendiren bir süreçtir. Bu nedenle form sadeleştirmesi hem kullanıcı benimsemesi hem de veri kalitesi açısından teknik konfigürasyondan önce gelen bir adımdır.Kök neden analizi için yapılandırılmış bir çerçeve olmadan toplanan veriler, ancak şikâyet sıklığını gösterebilir; nedenselliği değil. Türkiye’deki havayolu catering sektöründe yaygın olarak kullanılan yaklaşım, şikâyetleri kategoriye göre ayırmak ve her kategori için sorumlu departman belirlemektir. Bu başlangıç için makul bir adımdır; ama yeterli değildir. Sorunun gerçek ağırlık merkezi şudur: aynı kategori şikâyeti farklı kök nedenlere işaret edebilir ve hangi kök nedenin geçerli olduğunu belirlemek ancak çapraz departman verisiyle mümkündür. ‘Sıcaklık şikâyeti’ kategorisini ele alalım. Bu şikâyet troley içi sıcaklık ölçümüyle, araç soğuk zinciri loglarıyla ve mutfak çıkış sıcaklık kayıtlarıyla birlikte değerlendirildiğinde kök neden görünür hale gelir. Bu üç veri kaynağını tek bir ekranda bir araya getiremeyen bir ERP sistemi, aslında analiz değil arşiv görevi yapar. Projede tercih ettiğimiz yaklaşım, şikâyet kaydını tetikleyici olarak kullanmak ve bu tetikleyiciye bağlı otomatik sorgu ekranları açmaktı; böylece sorumlu departman yöneticisi sisteme girdiğinde şikâyetle ilgili operasyonel verileri tek ekranda görüyordu. Ancak bu entegrasyonun kurulabilmesi için lojistik, mutfak üretim ve operasyon modüllerinin aynı veritabanını paylaşması ya da en azından standart bir raporlama katmanıyla bağlantılı olması gerekiyordu. Bu teknik gereksinimin karşılanıp karşılanmadığı, yazılım seçiminden önce sorulması gereken birinci sorudur.Yönetim cephesindeki asıl gerilim ise şikâyet raporlarının nasıl yorumlandığı üzerinde şekillendi. Üst yönetim, şikâyet sayısındaki azalmayı performans iyileşmesi olarak okuma eğilimindeydi. Departman yöneticileri ise şikâyet sayısının düşmesinin kayıt kapsamının daralmasından kaynaklandığını biliyor ama bunu açıkça söylemiyordu. Bu sessizlik, raporlama kültürü ile hesap verebilirlik yapısı arasındaki boşluğun bir yansımasıdır. Sistemin gerçek değeri, şikâyet sayısını düşürmek değil; hangi departmanın, hangi süreçte, ne sıklıkla arıza ürettiğini görünür kılmaktır. Bu bağlamda ‘departman performans karnesi’ kavramı, şikâyet verisini tek boyutlu bir sayı olmaktan çıkarıp çok değişkenli bir değerlendirme aracına dönüştürebilir. Kaç şikâyet geldi sorusu değil; bu şikâyetlerin kaçı ilgili departman tarafından zamanında ve doğru şekilde kayıt altına alındı, kök neden hangi süreçte tespit edildi ve bu sorun tekrarladı mı soruları asıl ölçüm eksenidir. Şikâyet yönetimi olgunluğunu bu eksenle ölçen bir havayolu catering firması, kaç şikâyetin geldiğinden bağımsız olarak süreç kalitesini değerlendirebilir. Bu yaklaşım, Türkiye’deki catering operatörleri için 2015 itibarıyla hâlâ büyük ölçüde hayata geçirilmemiş bir fırsat alanıdır.Benzer bir projeye başlamayı düşünen bir operasyon müdürüne şu üç soruyu önce sorarım: Şikâyet formunu kim dolduruyorsa, o kişi aynı zamanda sorumluluk zincirinin içinde mi, dışında mı? Çapraz departman şikâyetlerinde kök neden kimin tarafından ve hangi veriyle belirleniyor? Şikâyet azalması ile yolcu memnuniyeti endeksi arasında pozitif bir korelasyon var mı, yoksa bu iki metrik birbirinden bağımsız mı hareket ediyor? Bu soruların yanıtı, hangi yazılımın alınacağından çok daha belirleyicidir. İstanbul’daki projede en sonunda gerçek değeri yaratan şey, ERP sisteminin şikâyet modülü değildi; departmanlar arası sorumluluk sınırlarını yeniden tanımlayan süreç çalışmasıydı. Yazılım o sınırları görünür kıldı. Sınırlar olmadan yazılım sadece bir kayıt defteri olurdu.