Nakliye Yazılımı Seçerken Dikkat Edilmesi Gereken 15 Kriter

Bir nakliye yazılımı demosunda çoğu şey düzgün görünür.

Harita açıktır. Sevkiyat kartları sıralıdır. Raporlar birkaç saniyede gelir. Ekran renkli, sunum etkileyicidir.

Gerçek operasyon ise demo gibi ilerlemez.

Saat 08.30’da yükleme başlayacaktır. Saat 08.10’da atanan araç gelemeyeceğini bildirir. Operasyon alternatif kapasite arar. Saha yeni plakayı bekler. Müşteri güncel varış saatini sorar. Finans değişen navlunun onayını ister.

Yazılımın asıl sınavı tam olarak bu anda başlar.

Yapılan değişiklik yalnızca araç atama ekranında kalıyorsa, operasyonun geri kalanına otomatik veya kontrollü biçimde yansımıyorsa ortada güzel bir panel olabilir; fakat güçlü bir Nakliye Yönetim Sistemi yoktur.

Bu nedenle nakliye yazılımı seçimi, özellik sayısı karşılaştırılarak yapılmamalıdır. Doğru soru “Kaç modülü var?” değil, “Bizim gerçek operasyonumuzu başından sonuna kadar nasıl yönetecek?” olmalıdır.

Aşağıdaki 15 kriter, lojistik firmalarının, taşıma işleri organizatörlerinin, üretici ve dağıtıcıların nakliye yazılımı seçerken daha doğru karar vermesine yardımcı olur.

Nakliye Yazılımı Seçimine Nereden Başlanmalı?

Yazılım firmalarıyla görüşmeden önce mevcut operasyonun sade bir haritası çıkarılmalıdır.

Bir sevkiyatın şirketinizde nasıl ilerlediğini düşünün:

Taşıma talebi nerede oluşuyor?
Araç hangi kanaldan bulunuyor?
Araç ve sürücü atamasını kim yapıyor?
Sefer durumu nasıl takip ediliyor?
Teslim evrakı nasıl geliyor?
Navlun farkları nerede kaydediliyor?
Mutabakat hangi bilgiye göre yapılıyor?
Fatura ve ödeme süreci ne zaman başlıyor?

Bu soruların cevabı farklı kişilerde, farklı dosyalarda ve farklı iletişim kanallarındaysa, yeni yazılımın ilk görevi bu dağınıklığı başka bir ekrana taşımak değil, süreçleri aynı veri hattında birleştirmek olmalıdır.

1. Yazılım Operasyon Modelinize Uygun mu?

Her nakliye operasyonu aynı değildir.

Bir firma ağırlıklı olarak FTL, yani komple taşımacılık yapabilir. Başka bir firmada LTL, yani parça taşımacılık ve çoklu teslimatlar öne çıkabilir. Bir yapı yalnızca sözleşmeli taşıyıcılarla çalışırken başka bir işletme yoğun biçimde spot kapasite kullanabilir.

Bu nedenle yazılım şu senaryoları ne ölçüde destekliyor, açıkça incelenmelidir:

• FTL ve LTL operasyonları
• Tek ve çok noktalı teslimatlar
• Sözleşmeli ve spot taşıyıcı kullanımı
• Özmal, kiralık ve dış kaynaklı araçlar
• Proje ve müşteri bazlı iş akışları
• Farklı fiyatlama ve mutabakat modelleri
• Lojistik firması, TİO, kooperatif veya yük sahibi firma senaryoları

Sunum sırasında genel cevap almak yerine, kendi gerçek operasyonunuzdan bir örnek gösterilmesini isteyin.

2. Süreci Uçtan Uca Yönetiyor mu?

Bazı yazılımlar yük kaydı tutar. Bazıları yalnızca araç konumu gösterir. Bazıları da güçlü raporlar sunar ancak saha ve finans süreçleriyle bağlantı kuramaz.

Gerçek bir TMS; taşıma talebinden teslimata, teslim evrakından mutabakata, navlundan faturalama ve ödeme takibine kadar kesintisiz bir süreç sunmalıdır.

Buradaki kritik nokta, her modülün ayrı ayrı var olması değildir.

Bir yükte yapılan değişiklik araç atamasına, sefer takibine, müşteriye verilen bilgiye, teslimat kaydına ve finansal sürece yansıyabiliyor mu?

Aynı veri tekrar tekrar giriliyorsa süreç dijitalleşmiş değil, yalnızca ekranlara bölünmüş demektir.

3. Yük ve Sevkiyat Oluşturmak Pratik mi?

Nakliye yazılımının en sık kullanılan alanlarından biri taşıma talebi oluşturma ekranıdır.

Bu ekran yavaşsa, çok fazla manuel giriş istiyorsa veya operasyon ekibinin alışkanlıklarına uymuyorsa kullanıcılar kısa süre sonra tekrar Excel’e dönmeye başlar.

Değerlendirme sırasında şunlara bakılmalıdır:

• Tekil yük oluşturma
• Toplu yük aktarımı
• Excel, ERP veya API üzerinden veri alma
• Müşteri ve proje şablonları
• Zorunlu alan ve veri kontrolü
• Tekrarlayan sevkiyatların hızlı oluşturulması
• Yükleme ve boşaltma bilgilerinin standartlaştırılması

Başarılı bir sistem, operasyon ekibine yeni bir veri giriş yükü oluşturmamalı; mevcut işi daha düzenli hale getirmelidir.

4. Sözleşmeli ve Spot Kapasiteyi Birlikte Yönetiyor mu?

Sözleşmeli taşıyıcılar her zaman bütün talebi karşılamayabilir.

Yoğun sezon, son dakika çıkan yük, yeni bir güzergâh veya dönüş aracı ihtiyacı oluştuğunda spot kapasiteye erişmek gerekir.

Bu sürecin sadece telefonla yürütülmesi ciddi bilgi kaybı yaratır. Kimin arandığı, hangi fiyatın verildiği, teklifin neden kabul edildiği ve taşıyıcının geçmiş performansı kayıt altında kalmaz.

Nakliye yazılımı şu sorulara cevap verebilmelidir:

• Sözleşmeli taşıyıcı havuzu yönetilebiliyor mu?
• Spot kapasiteye kontrollü erişim sağlanıyor mu?
• Yükler seçili taşıyıcılara teklif olarak gönderilebiliyor mu?
• Kabul ve ret cevapları kayıt altına alınıyor mu?
• Alternatif teklifler karşılaştırılabiliyor mu?
• Taşıyıcının geçmiş operasyonları görülebiliyor mu?

Araç tedariki operasyonun dışında kaldığında, TMS’in en kritik halkalarından biri eksik kalır.

5. Araç ve Sürücü Atama Süreci Kontrollü mü?

Araç atamak yalnızca plaka yazmak değildir.

Araç tipi, kasa yapısı, sürücü, taşıyıcı, yükleme zamanı, rota ve müşteri koşulları aynı atama içinde değerlendirilmelidir.

Ayrıca sahada plan her zaman ilk haliyle ilerlemez. Atanan araç değişebilir. Sürücü işi reddedebilir. Plaka yükleme öncesinde güncellenebilir.

İyi bir sistem şu akışları yönetebilmelidir:

• Araç ve sürücü ataması
• Taşıyıcının kabul veya ret cevabı
• Atama değişikliği
• Yeni plaka veya sürücü güncellemesi
• Değişiklik geçmişinin izlenmesi
• Aynı yüke mükerrer araç atanmasının engellenmesi
• Atama bilgisinin ilgili taraflara yansıması

Kritik soru şudur: Atama değiştiğinde eski bilgi sistemin başka bir bölümünde kalıyor mu?

6. Canlı Takip Gerçek Operasyon Görünürlüğü Sağlıyor mu?

Harita üzerinde bir araç noktası görmek tek başına yeterli değildir.

Operasyon ekibinin ihtiyacı aracın yalnızca nerede olduğunu değil, sevkiyatın hangi aşamada olduğunu anlayabilmektir.

Yazılımda şu bilgiler birlikte görülebilmelidir:

• Araç konumu
• Yükleme durumu
• Sefer başlangıcı
• Boşaltma aşaması
• Tamamlanma bilgisi
• Tahmini varış zamanı
• Gecikme ve istisnalar
• Geçmiş konum ve sefer hareketleri

Asıl değer, sorun oluştuktan sonra konumu göstermek değil, gecikme ihtimalini zamanında görünür hale getirmektir.

7. Saha ve Sürücü Sürece Nasıl Bağlanıyor?

Ofiste kullanılan yazılım ne kadar güçlü olursa olsun, saha verisi sisteme geç ve eksik geliyorsa operasyon yine telefonla yürür.

Bu nedenle mobil uygulama veya sürücü tarafındaki kullanım deneyimi mutlaka test edilmelidir.

Sürücü veya saha kullanıcısı şu işlemleri kolayca yapabilmelidir:

• Kendisine atanan işi görüntüleme
• İşi kabul veya reddetme
• Yükleme ve teslimat adımlarını güncelleme
• Konum paylaşma
• Teslim evrakı yükleme
• Fotoğraf ve belge ekleme
• Operasyon ekibiyle aynı sevkiyat kaydı üzerinden çalışma

Saha uygulamasının fazla karmaşık olması, verinin yeniden WhatsApp’a dönmesine neden olur. Bu yüzden yalnızca özelliğe değil, kullanım kolaylığına da bakılmalıdır.

8. Dijital Evrak ve POD Süreci Güçlü mü?

Teslimat tamamlanmış olsa bile teslim evrakı ulaşmadıysa operasyon finansal olarak kapanmamıştır.

POD, irsaliye, taşıma senedi veya teslimat fotoğrafı sürücünün telefon galerisinde kaldığında mutabakat ve faturalama gecikir.

Yazılımın dijital evrak tarafında şu özellikler değerlendirilmelidir:

• Evrakın doğrudan ilgili sevkiyata bağlanması
• Mobil cihazdan belge yüklenmesi
• Evrak türlerinin ayrıştırılması
• Eksik evrakların görülebilmesi
• Yükleme ve teslimat belgelerinin ayrı izlenmesi
• Belgenin kim tarafından ve ne zaman yüklendiğinin kaydı
• Finans ekibinin evraka aynı sistemden ulaşabilmesi

Dijital evrak yalnızca arşiv kolaylığı sağlamaz. Operasyonun finansal kapanış hızını da doğrudan etkiler.

9. Navlun, Mutabakat, Fatura ve Ödeme Aynı Akışta mı?

Birçok sistem operasyon tamamlandığında görevini bitirir.

Oysa lojistik firmasında taşıma tamamlandığında navlun kontrolü, ek masraf, müşteri mutabakatı, taşıyıcı hakedişi, fatura ve ödeme süreci devam eder.

Yazılım şu yapıları destekleyebilmelidir:

• Sefer bazlı navlun tanımı
• Müşteri ve taşıyıcı için farklı fiyat modelleri
• Bekleme, uğrama ve ek masraf kayıtları
• Çok taraflı mutabakat
• Faturalanacak işlemlerin belirlenmesi
• Tahsilat ve ödeme vadelerinin izlenmesi
• Tamamlanan taşımanın finansal duruma aktarılması
• Proje, müşteri ve taşıyıcı bazında finansal görünürlük

Operasyon verisi ile finansal veri ayrı kaynaklardan geliyorsa, ay sonunda yine Excel karşılaştırması yapılır.

Doğru sistemde operasyon bittiğinde finans başlamaz; finans, operasyonla aynı veri üzerinden ilerler.

10. ERP ve Diğer Sistemlerle Entegre Olabiliyor mu?

ERP kullanan firmaların önemli bir kısmında nakliye operasyonu yine ayrı ilerler.

Sipariş ERP’de oluşur, araç ataması telefonda yapılır, konum başka uygulamada görülür, evrak WhatsApp’tan gelir ve navlun farklı bir tabloda hesaplanır.

TMS’in ERP’nin yerine geçmesi gerekmez. Doğru yaklaşım, ERP ile saha arasında güçlü bir nakliye operasyon katmanı kurmaktır.

Entegrasyon değerlendirmesinde şu sorular sorulmalıdır:

• Sipariş verisi TMS’e nasıl aktarılıyor?
• Sevkiyat durumları ERP’ye geri gönderilebiliyor mu?
• Müşteri, ürün, adres ve proje kartları senkronize edilebiliyor mu?
• API dokümantasyonu var mı?
• Hatalı veri aktarımı nasıl izleniyor?
• Entegrasyon kesildiğinde kayıtlar kayboluyor mu?
• Aynı bilgi iki sisteme manuel girilmek zorunda mı?

Entegrasyon yalnızca teknik bağlantı değildir. Verinin hangi sistemde doğduğu ve hangi sistemin ana kaynak olduğu da netleştirilmelidir.

11. Çok Müşterili ve Çok Projeli Operasyonları Yönetebiliyor mu?

Bir lojistik firmasında bütün müşteriler aynı süreçle çalışmaz.

Bir müşteride sabit navlun vardır. Diğerinde ton veya kilometre bazlı fiyatlama kullanılır. Bazı projelerde canlı konum zorunludur. Bazılarında farklı evrak ve mutabakat kuralları bulunur.

Yazılımın şu yapıları desteklemesi gerekir:

• Müşteri bazlı operasyon kurgusu
• Proje bazlı fiyat ve iş akışı
• Şube ve lokasyon yönetimi
• Taşıyıcı ve yüklenici bazlı kurallar
• Farklı kullanıcı rolleri
• Yetki sınırları
• Müşteriye özel raporlama
• Farklı operasyonların tek merkezde izlenmesi

Her yeni müşteri için ayrı Excel oluşturuluyorsa yazılım ölçeklenebilir bir yapı kuramamış demektir.

12. Raporlama Gerçekten Karar Aldırıyor mu?

Rapor sayısının fazla olması tek başına değerli değildir.

Asıl mesele yöneticinin kritik sorulara hızlı cevap alabilmesidir:

Hangi taşıyıcı daha düzenli çalışıyor?
Hangi hatta gecikme daha fazla?
Teslim evrakı en geç hangi projede geliyor?
Hangi müşteri daha fazla ek masraf oluşturuyor?
Hangi taşımalarda navlun sapması yaşanıyor?
Sefer, müşteri veya güzergâh bazında kârlılık görülebiliyor mu?

Raporlama yalnızca geçmişi anlatmamalı, aksiyon alınması gereken alanı da göstermelidir.

Demo sırasında hazır grafiklere bakmak yerine kendi operasyonunuza uygun bir raporun nasıl üretildiğini test edin.

13. Kullanıcı Deneyimi Operasyon Ekibine Uygun mu?

Bir yazılım teknik olarak güçlü olabilir ancak kullanıcı tarafından benimsenmeyebilir.

Ekranlar karmaşıksa, sık kullanılan işlemler çok fazla adım gerektiriyorsa veya kullanıcı her işlem için destek almak zorunda kalıyorsa sistem kısa sürede ek iş yüküne dönüşür.

Karar öncesinde yazılımı yalnızca yönetici veya bilgi teknolojileri ekibi değil, şu kullanıcılar da test etmelidir:

• Operasyon uzmanı
• Planlama ekibi
• Finans ve mutabakat ekibi
• Saha kullanıcısı
• Sürücü veya taşıyıcı
• Rapor alan yönetici

En doğru test, gerçek bir sevkiyatı sistem üzerinde baştan sona yürütmektir.

14. Veri Güvenliği ve Yetkilendirme Yeterli mi?

Nakliye yazılımında müşteri, taşıyıcı, fiyat, konum, evrak ve finans verileri birlikte tutulabilir.

Bu nedenle güvenlik yalnızca bilgi teknolojileri ekibinin konusu değildir. Ticari gizlilik ve operasyonel süreklilik açısından yönetimin de değerlendirmesi gereken bir alandır.

Tedarikçiye şu sorular yöneltilmelidir:

• Kullanıcılar rol bazlı yetkilendirilebiliyor mu?
• Kim hangi fiyat ve müşteri bilgisini görebiliyor?
• Yapılan değişikliklerin işlem kaydı tutuluyor mu?
• Veri yedekleme politikası nedir?
• Verinin sahibi kimdir?
• Sözleşme bittiğinde veriler nasıl teslim edilir?
• Kişisel veriler ve konum verileri nasıl korunur?
• Sistem kesintileri ve güvenlik olayları nasıl yönetilir?

Bu konular sözlü anlatımla bırakılmamalı, sözleşme ve teknik dokümanlarda açıkça yer almalıdır.

15. Uygulama, Destek ve Toplam Maliyet Net mi?

Nakliye yazılımının maliyeti yalnızca aylık veya yıllık lisans bedeli değildir.

Toplam maliyet hesabına şu kalemler de dahil edilmelidir:

• Kurulum
• Entegrasyon
• Veri aktarımı
• Eğitim
• Kullanıcı ve mobil uygulama ücretleri
• Ek rapor veya geliştirme talepleri
• Destek hizmeti
• API kullanımı
• Yeni şube, proje veya müşteri ekleme maliyeti
• Sözleşme yenileme koşulları

En düşük fiyatlı çözüm, operasyonu karşılamıyorsa en pahalı tercih haline gelebilir.

Yazılım sağlayıcısının yol haritası, lojistik sektöründeki deneyimi, destek ekibinin erişilebilirliği ve yeni ihtiyaçlara yaklaşımı da değerlendirilmelidir.

Çünkü nakliye operasyonu sabit kalmaz. Müşteri sayısı, sevkiyat hacmi, taşıyıcı yapısı ve finansal kurallar zaman içinde değişir.

Seçilen sistemin bu değişime uyum sağlaması gerekir.

Demo Sırasında Uygulanabilecek Gerçek Operasyon Testi

Sunum yerine aşağıdaki senaryonun sistem üzerinde canlı olarak gösterilmesini isteyin:

1. Gerçek bir taşıma talebi oluşturun.
2. Taşıyıcıya teklif gönderin.
3. Araç ve sürücü atayın.
4. Atanan aracın gelemediğini varsayarak plakayı değiştirin.
5. Yeni bilginin operasyon ve takip ekranlarına nasıl yansıdığını görün.
6. Seferi yükleme, yolda, boşaltma ve tamamlandı aşamalarından geçirin.
7. Teslim evrakını mobil uygulama üzerinden yükleyin.
8. Bekleme veya ek masraf ekleyin.
9. Taşıyıcı ve müşteri mutabakatını oluşturun.
10. Faturalama ve raporlama ekranına geçin.

Bu akış kesilmeden tamamlanabiliyorsa yazılım gerçek operasyonu yönetmeye yakındır.

Süreç boyunca veri tekrar giriliyor, farklı ekranlarda eski bilgiler kalıyor veya finans tarafına Excel aktarımı gerekiyorsa eksik noktalar daha satın alma yapılmadan görünür hale gelir.

Kamyoon TMS Bu Değerlendirmede Nasıl Konumlanır?

Kamyoon, nakliye operasyonu yapan bir firma değildir. Operasyonu yöneten kurumlara dijital altyapı sağlar.

Kamyoon TMS; yük oluşturma, araç ve sürücü atama, sefer takibi, canlı izlenebilirlik, dijital evrak, yük/araç pazar yeri üzerinden spot kapasiteye kontrollü erişim, navlun, mutabakat, faturalama, ödeme ve raporlama süreçlerini aynı sistem yaklaşımıyla birleştirir.

Buradaki amaç yalnızca yeni bir ekran sunmak değildir.

Operasyon, saha, araç tedariki ve finansın aynı taşıma kaydı üzerinden ilerlemesini sağlamaktır.

Bu nedenle Kamyoon değerlendirilirken tek tek özelliklere değil, bir sevkiyatın yük oluşturulmasından finansal kapanışına kadar nasıl ilerlediğine bakılmalıdır.

Sonuç olarak;

Nakliye yazılımı seçmek, yalnızca teknoloji satın almak değildir.

Şirketin taşıma operasyonunu hangi kurallarla yöneteceğine karar vermektir.

Yanlış sistem, mevcut dağınıklığı dijital ekrana taşır. Doğru sistem ise yük, araç, sürücü, saha, teslimat, evrak ve finans süreçlerini aynı veri üzerinde birleştirir.

Karar verirken şu üç soruyu merkeze alın:

Yazılım bizim gerçek operasyonumuza uyuyor mu?
Süreçleri uçtan uca birbirine bağlıyor mu?
Operasyon büyüdüğünde aynı sistemle kontrol sağlayabilir miyiz?

Bu soruların cevabı net değilse, özellik listesi ne kadar uzun olursa olsun karar için henüz erken demektir.

Nakliye yazılımı arayışınızı ve mevcut operasyon yapınızı değerlendirmek için Kamyoon TMS’i yakından inceleyebilirsiniz.

Süreçlerinizi birlikte değerlendirebiliriz.