TMS Yazılımı Nedir? Lojistikte Dijital Dönüşüm Rehberi

TMS yazılımı (Transportation Management System, Türkçesiyle taşımacılık yönetim sistemi), bir yükün talep aşamasından teslimata ve faturalamaya kadar geçen bütün sürecini tek bir sistem üzerinden planlamaya, yürütmeye ve ölçmeye yarayan operasyonel yazılım katmanıdır.

Pratikte yaptığı şey basittir: nakliye operasyonunun kayıt defterini, planlama masasını ve raporlama merkezini aynı yerde toplar. E-postaya, Excel dosyalarına ve telefon görüşmelerine dağılmış bilgi tek bir akışa bağlanır; kim ne zaman ne yaptı sorusunun cevabı sistemde durur.

TMS bir muhasebe yazılımı değildir. Finansal sonucu üretir ve besler, ama asıl işi operasyonun kendisini yönetmektir.

Küresel tedarik zincirlerinde artan maliyet baskısı ve dalgalanan kapasite, firmaları sevkiyat planlaması ve takip süreçlerini uçtan uca dijitalleştirmeye yöneltti. Navlun fiyatlarının haftalar içinde değiştiği bir ortamda, hangi işin ne kadar kâr bıraktığını ay sonunu beklemeden görmek gerekiyor.

İkinci etken müşteri beklentisi. Yükünün nerede olduğunu sormak için telefon etmek zorunda kalan müşteri, bunu yapmayan bir rakibe geçiyor. Görünürlük artık ek özellik değil, temel beklenti.

Üçüncüsü ölçek sorunu: operasyon hacmi büyürken ekip aynı kalıyor. Manuel veri girişine dayanan bir süreç belirli bir dosya sayısından sonra hata üretmeye başlar. TMS yazılımı bu eşiği yukarı taşır.

Talep ve teklif yönetimi, sürecin giriş kapısıdır. Gelen taşıma talebi yapılandırılmış bir kayda dönüşür, teklif hazırlanır ve versiyonlanır. Tarife ve navlun yönetimi ise taşıyıcı sözleşmelerini, alış ve satış fiyatlarını, ek masrafları ve geçerlilik tarihlerini tutar.

Planlama ve rota optimizasyonu, kapasite ve zaman penceresi kısıtları altında yükleri araçlara ve seferlere dağıtır. Booking ve taşıyıcı iletişimi, seçilen taşıyıcıyla yer ayırtma ve statü alışverişini yönetir.

Sevkiyat takibi ve görünürlük katmanı, yükün konumunu ve tahmini varış zamanını hem operasyona hem müşteriye açar. Belge yönetimi konşimento, ordino, gümrük evrakı gibi dokümanları dosyaya bağlar; olgun sistemlerde bu belgeler otomatik okunup veriye çevrilir.

Son halka maliyet, fatura ve mutabakattır: taşıyıcı faturası beklenen maliyetle karşılaştırılır, fark varsa itiraz süreci başlar. Üstüne raporlama ve KPI modülü gelir.

Bu üçü sık karıştırılır ama farklı sorulara cevap verirler. ERP şirketin finans, muhasebe ve kaynak omurgasıdır; paranın ve kaynağın kaydını tutar. WMS deponun içiyle ilgilenir: raf yerleşimi, toplama, sayım, stok doğruluğu.

TMS ise kapıdan kapıya hareketi yönetir: hangi yük, hangi taşıyıcıyla, hangi navlunla, hangi evrakla nereye gidiyor. Depo kapısından çıktıktan sonrası TMS alanıdır.

Üçü rakip değil, birbirini besleyen katmanlardır. Tipik bir kurulumda TMS, ERP'ye maliyet ve fatura verisi gönderir; WMS'ten çıkış bilgisini alır. Bir yazılımın üçünü birden iyi yaptığını söylemesi genelde birinde derinlik olmadığı anlamına gelir.

Entegrasyon kapsamı, bir TMS projesinin gerçek maliyetini belirleyen kalemdir ve lisans bedelinden daha belirleyicidir. Asgari liste şöyledir: ERP ve muhasebe tarafı için fatura ve cari entegrasyonu, taşıyıcı ve acente sistemleri için booking ve statü alışverişi.

Denizyolu ve havayolunda liman, terminal ve havayolu sistemleriyle veri alışverişi; gümrük süreçleri için ilgili beyanname akışları devreye girer. Müşteri tarafında portal, EDI veya API ile entegrasyon beklenir.

Türkiye özelinde e-fatura ve e-irsaliye uyumu ayrıca sorulmalıdır. Bir sistemin API'si var demek yeterli değil; hangi işlemlerin API üzerinden yapılabildiği yazılı olarak istenmelidir.

Bu ayrım yanlış yapılırsa yazılım hiç oturmaz. Yük sahibi (shipper) kendi yükünü taşıtır; önceliği taşıyıcı seçimi, maliyet kontrolü ve teslimat performansıdır.

Freight forwarder ise başkasının yükünü taşır. Çok müşterili çalışır, alış ve satış navlunu ayrı yönetir, kâr marjını dosya bazında takip eder ve her dosyanın kendi muhasebesi vardır.

Forwarder için tasarlanmamış bir TMS, dosya kârlılığını ve çok taraflı masraf dağıtımını doğru modelleyemez. Demo sırasında kendi iş modelinize ait gerçek bir dosyanın baştan sona açılmasını isteyin.

Doğru uygulanan bir TMS ile ölçülebilir şekilde iyileşen başlıca kalemler şunlardır: zamanında teslimat oranı, teklif hazırlama süresi, dosya başına manuel veri girişi süresi, boş kilometre ve kapasite kullanım oranı.

Finans tarafında fatura itiraz oranı ve tahsilat süresi öne çıkar; taşıyıcı faturası ile beklenen maliyet sistemde karşılaştırıldığı için farklar erken yakalanır.

Operasyonel dayanıklılık tarafında ise aksaklığın fark edilme süresi kritik metriktir. Bir rollover veya gecikme ne kadar erken görülürse müşteriye haber verme ve alternatif üretme şansı o kadar yüksek olur.

Bu metrikleri projeye başlamadan önce ölçün. Başlangıç değeri olmayan bir iyileşme iddiası doğrulanamaz.

İlk kriter entegrasyon hazırlığıdır: ERP, muhasebe, taşıyıcı API'leri ve depo süreçleriyle bağlantı kapsamı. İkincisi çok modlu destek; bugün sadece karayolu yapıyor olsanız bile denizyolu veya havayoluna girdiğinizde aynı sistemde kalabilmek önemlidir.

Raporlama esnekliği çoğu zaman hafife alınır. Hazır rapor sayısı değil, kendi raporunuzu üretebilme ve veriyi dışarı alabilme yeteneği belirleyicidir. Veri sahipliği ve dışa aktarım koşulları sözleşmede açıkça yazmalıdır.

Kullanıcı deneyimi doğrudan benimsenmeyi etkiler; operasyon ekibinin kullanmadığı bir sistem teknik olarak ne kadar güçlü olursa olsun başarısızdır. Son olarak toplam sahip olma maliyetini lisans, uygulama, eğitim, entegrasyon ve yıllık bakım kalemlerinin toplamı olarak hesaplayın.

Bulut (SaaS) kurulumda yazılım tedarikçinin altyapısında çalışır; güncelleme, yedekleme ve ölçeklendirme sağlayıcıya aittir. Başlangıç maliyeti düşüktür ve yeni şube veya kullanıcı eklemek hızlıdır.

Yerinde (on-premise) kurulumda sistem kendi sunucunuzda çalışır. Veri şirket sınırları içinde kalır, özelleştirme serbestliği artar; buna karşılık sunucu, güvenlik ve sürüm yönetimi sizin sorumluluğunuza geçer.

Karar genelde teknik değil, uyum ve iç politika kaynaklıdır. Veri yerleşimi ve KVKK yükümlülükleriniz netse seçim kolaylaşır. Ara bir yol olarak yapay zekâ bileşenlerinin yerel modelle çalıştırılıp verinin dışarı çıkmadığı kurulumlar da mümkündür.

Fiyatlandırma genelde üç modelden birine dayanır: kullanıcı başına aylık abonelik, işlem veya dosya başına ücretlendirme, ya da sabit kurumsal lisans. Operasyon hacminiz dalgalıysa işlem başına model, ekip sabitse kullanıcı başına model daha öngörülebilir olur.

Görünen lisans bedeli toplam maliyetin genelde yarısından azıdır. Üzerine uygulama ve kurulum, veri taşıma, entegrasyon geliştirmeleri, eğitim ve yıllık bakım eklenir. Entegrasyon kalemi çoğu projede en büyük sürprizdir.

Teklif alırken üç yıllık toplam sahip olma maliyetini isteyin ve şu üç soruyu yazılı sordurun: kullanıcı eklemenin birim maliyeti nedir, standart dışı bir entegrasyon nasıl fiyatlanır, sözleşme biterse veri hangi formatta teslim edilir.

En sık yapılan hata, mevcut manuel süreci olduğu gibi yazılıma kopyalamaktır. Geçiş, süreci sadeleştirmek için bir fırsattır; hangi adımın neden var olduğu sorulmadan yapılan aktarım eski sorunları yeni sisteme taşır.

Tek bir taşıma modunda veya tek bir şubede pilot ile başlayın. Dar bir kapsamda çalışan bir kurulum, geniş kapsamda yarım kalmış bir kurulumdan değerlidir.

Veri temizliği projenin görünmeyen yüküdür: müşteri kartları, adresler, liman ve tarife verileri baştan düzeltilmezse sistem ilk günden yanlış çıktı üretir. Son olarak ekip benimsemesi için operasyondan bir kişinin projenin sahibi olması, danışman sayısından daha belirleyicidir.

Son yıllarda taşımacılık yönetim sistemlerindeki en belirgin değişim, veri girişinin ve belge okumanın otomatikleşmesi. Müşteriden serbest metinle gelen bir talebin yapılandırılmış bir forma dönüşmesi, taranmış bir konşimentonun veriye çevrilmesi ve aksaklıkların operasyona sorulmadan yorumlanması artık teknik olarak mümkün.

Bunun operasyondaki karşılığı, ekibin zamanının veri girişinden karar vermeye kaymasıdır. Kazanç hız değil, dikkattir: aynı ekip daha fazla dosyayı gözden kaçırmadan yönetebilir.

Kritik soru kararın kimde kaldığıdır. Denetlenebilir bir akışta yapay zekâ öneri üretir, değişikliği uygulamadan önce gösterir ve son onay insanda kalır. Bir TMS değerlendirirken yapay zekâ özelliklerinin ne yaptığından çok, yanıldığında ne olduğunu ve izinin nasıl sürüldüğünü sorun.