Firma Yazılıma Değil, Yazılım Firmaya Uymalı

Genel Bakış

**Büyük bir firmanın nakliye operasyonu, hazır bir özellik listesinden ibaret değildir.** Her kurumun müşteri yapısı, proje kurgusu, onay zinciri, taşıyıcı ağı, fiyatlama modeli, saha alışkanlıkları ve raporlama beklentisi farklıdır. Buna rağmen birçok yazılım projesi aynı cümleyle başlar: “Sistem böyle çalışıyor, süreçlerinizi buna göre değiştirmeniz gerekiyor.”

Bu yaklaşım küçük ve standart operasyonlarda kabul edilebilir olabilir. Ancak yüzlerce proje, farklı iş birimleri, binlerce taşıyıcı ve yüksek sevkiyat hacmi yöneten kurumlarda yazılımın sınırları kısa sürede operasyonun sınırlarına dönüşür. Ekipler sistemin karşılamadığı işleri Excel’de tamamlar, sürücüler farklı mesajlaşma gruplarına yönelir, müşteri talepleri manuel takip edilir ve yönetim tekrar ayrı raporlar hazırlatmaya başlar.

Kurumsal ölçekte doğru yaklaşım bunun tersidir: **Firma yazılıma değil, yazılım firmaya uymalıdır.** Bu; her şeyi sıfırdan geliştirmek anlamına gelmez. Güvenilir ve sahada doğrulanmış bir [TMS altyapısının](/nakliye-yonetim-sistemi), kurumun gerçek işleyişine göre yapılandırılması; ihtiyaç duyulan noktalarda sürücü mobil uygulaması, özel taşıyıcı pazaryeri ve kurumsal sistem entegrasyonlarıyla genişletilmesi anlamına gelir.

Standart yazılım büyük operasyonlarda neden yetersiz kalabilir?

Nakliye süreçleri dışarıdan benzer görünür: yük oluşturulur, araç atanır, sefer takip edilir ve teslimat tamamlanır. Fakat gerçek operasyonun ayrıntıları firmadan firmaya değişir.

Yazılım bu farklılıkları desteklemiyorsa kullanıcı sistemi terk etmez; sistemin etrafında yeni ve kontrolsüz çalışma biçimleri oluşturur. “Gölge Excel” dosyaları, kişisel notlar, mesajlaşma grupları ve birbirinden kopuk raporlar bu nedenle ortaya çıkar.

Sonuçta şirket yazılıma sahip olur ancak operasyon tek sistemden yönetilemez. Kurumsal bir nakliye yönetim sisteminin başarısı, yalnızca kaç özelliği olduğuyla değil; kurumun gerçek iş akışını ne kadar doğru taşıyabildiğiyle ölçülmelidir.

• Bir üretici, sevkiyatları fabrika, bayi, ürün grubu ve sipariş numarası üzerinden yönetebilir.
• Bir 3PL firması aynı anda birçok müşterinin farklı SLA ve raporlama kurallarıyla çalışabilir.
• Bir dağıtım şirketi çok duraklı teslimat, zaman penceresi ve teslimat doğrulaması isteyebilir.
• Bir lojistik firması kendi filosunu, sözleşmeli taşıyıcılarını ve spot araçları aynı havuzda yönetebilir.
• Bir kurumda fiyat onayı operasyon yöneticisindeyken başka bir kurumda satın alma ve finans onayı gerekebilir.

Özelleştirilebilir TMS ne demektir?

Özelleştirilebilir TMS, ekran rengini veya logoyu değiştirmekten daha kapsamlıdır. Sistemin veri yapısının, kullanıcı rollerinin, iş akışlarının, entegrasyonlarının ve raporlarının şirketin operasyon modeline uyarlanabilmesidir.

Kurumsal bir TMS’de aşağıdaki başlıklar yapılandırılabilir olmalıdır:

Buradaki amaç mevcut manuel sürecin bütün hatalarını yazılıma kopyalamak değildir. Önce operasyon analiz edilir; standartlaştırılması gereken bölümler ile şirkete rekabet avantajı sağlayan özel iş kuralları birbirinden ayrılır. TMS, bu analiz sonucunda kuruma uygun bir işletim sistemine dönüştürülür.

• Şirket, iş birimi, müşteri, proje, depo ve şube yapısı
• FTL, LTL, çok duraklı veya proje taşımacılığına uygun iş akışları
• Yük, araç, sürücü ve taşıyıcıya ait kuruma özel veri alanları
• Kullanıcı rolleri, yetkiler ve onay adımları
• Sefer statüleri, istisna nedenleri ve bildirim kuralları
• Müşteri, proje, güzergâh veya taşıyıcı bazlı fiyatlama modelleri
• Dijital evrak türleri ve belge kontrol süreçleri
• Operasyonel, finansal ve yönetim raporları
• ERP, muhasebe, e-fatura, e-irsaliye ve araç takip entegrasyonları

1. Kuruma göre şekillenen nakliye yönetim sistemi

Büyük firmalar için TMS’in merkezinde tek bir “yük listesi” değil, kurumun operasyon modeli bulunmalıdır. Hangi bilgiyle taşıma talebi açılacağı, aracın nasıl tedarik edileceği, kimin onay vereceği, müşteriye hangi bilginin gösterileceği ve finansal kapanışın ne zaman başlayacağı baştan tasarlanmalıdır.

Kamyoon TMS; taşıma talebi, araç ve sürücü atama, sefer, canlı izlenebilirlik, teslimat, dijital evrak, navlun, mutabakat, faturalama ve ödeme süreçlerini aynı veri hattında birleştirir. Bu çekirdek yapı; firmanın müşteri, proje, organizasyon ve yetki modeline göre uyarlanabilir.

Örneğin bir müşteride plaka değişikliği yalnızca operasyon kaydı olabilirken başka bir müşteride yeniden onay, bildirim ve fiyat kontrolü gerektirebilir. Bir şirkette teslim evrakı gelmeden sefer kapatılamazken diğerinde belirli bir kullanıcıya istisna yetkisi verilebilir. Terzi usulü TMS yaklaşımı, bu farkların kontrollü kurallara dönüştürülmesini sağlar.

2. Firmaya uygun sürücü mobil uygulaması

Ofiste kullanılan TMS ne kadar güçlü olursa olsun, saha süreci sisteme doğru veri üretmiyorsa görünürlük eksik kalır. Bu nedenle sürücü mobil uygulaması, kurumsal TMS projesinin sonradan eklenen bir parçası değil; operasyon tasarımının başlangıcından itibaren düşünülmesi gereken bileşenidir.

Kamyoon’un [Teslimat ve Kamyoncu Uygulaması](/teslimat-kamyoncu-uygulamasi), TMS ile aynı operasyon akışında çalışabilir. Kurumun ihtiyacına göre sürücünün göreceği görevler, dolduracağı alanlar, paylaşacağı konum, yükleme ve boşaltma adımları, fotoğraf ve evrak zorunlulukları, teslimat doğrulaması ve bildirimler yapılandırılabilir.

Kuruma uygun bir mobil saha akışında şu sorular cevaplanmalıdır:

Bu yapı sayesinde saha personeli gereksiz ekranlarla uğraşmaz; operasyon ekibi ise ihtiyaç duyduğu veriyi telefonla istemek zorunda kalmaz. Mobil uygulama şirkete yeni bir iş yükü eklemek yerine mevcut saha işini sadeleştirir.

• Sürücü hangi bilgileri görmeli, hangi bilgileri görmemeli?
• Yükleme veya boşaltma hangi işlemle doğrulanmalı?
• Hangi evrak türleri zorunlu olmalı?
• Konum paylaşımı hangi aşamada başlamalı ve sona ermeli?
• Hasar, gecikme veya reddedilen teslimat nasıl bildirilmeli?
• Mobil uygulamayı kullanamayan sürücüler için hangi kontrollü alternatif süreç işletilmeli?

3. Kuruma özel taşıyıcı pazaryeri ve kapasite ağı

Büyük operasyonlarda araç tedariki yalnızca açık pazardan araç bulmak değildir. Şirketin onaylı taşıyıcıları, sözleşmeli filoları, bölgesel kooperatifleri, dönemsel tedarikçileri ve spot kapasitesi farklı kurallarla yönetilebilir.

Kamyoon’un [Yük Borsası](/yuk-borsasi) altyapısı, TMS ile entegre biçimde çalışarak kuruma özel bir taşıyıcı pazaryeri kurgusuna dönüştürülebilir. Firma, yüklerini herkese açmak yerine belirlediği taşıyıcı gruplarına, bölgelere veya yeterlilik koşullarına göre dağıtabilir. Teklif, kabul ve ret süreçleri operasyon kaydıyla birlikte ilerler.

Kuruma özel pazaryeri yaklaşımında aşağıdaki yapılar tasarlanabilir:

Böylece pazaryeri TMS’den kopuk bir ilan ekranı olmaz. Araç tedariki, atama, sefer, teslimat, evrak ve finansal kapanış aynı operasyonun parçaları hâline gelir.

• Onaylı ve sözleşmeli taşıyıcı havuzları
• Bölge, araç tipi, güzergâh veya proje bazlı taşıyıcı grupları
• Teklif toplama, sabit fiyat veya sıra bazlı atama kuralları
• Belge, yetkinlik ve performans kriterlerine göre erişim
• Gerekli durumlarda daha geniş spot kapasiteye kontrollü açılım
• Tekliften teslimata kadar tek kayıt üzerinden izlenebilirlik

4. ERP ve mevcut kurumsal sistemlerle entegrasyon

Büyük bir firmada TMS tek başına çalışmaz. Sipariş ERP’de, müşteri kartı CRM’de, fatura muhasebe sisteminde, araç konumu farklı bir takip altyapısında bulunabilir. Başarılı bir TMS projesi bu sistemlerin yerine geçmeye çalışmaz; aralarında doğru görev paylaşımını kurar.

Kamyoon, API entegrasyonlarıyla ERP, muhasebe, finans, e-fatura, e-irsaliye, araç takip ve benzeri sistemlerle birlikte çalışabilecek şekilde tasarlanmıştır. Taşıma talebi başka bir sistemden alınabilir; operasyon TMS üzerinde yürütülebilir; teslimat, evrak, navlun ve mutabakat verileri ilgili kurumsal sisteme geri aktarılabilir.

Entegrasyon tasarımında “her veriyi her yere gönderme” yaklaşımı yerine veri sahipliği belirlenmelidir. Hangi sistem müşteri bilgisinin kaynağıdır? Sefer statüsünü hangi sistem üretir? Faturaya hazır kayıt hangi noktada oluşur? Bir hata olduğunda hangi sistemde düzeltilmelidir? Bu sorular cevaplanmadan kurulan entegrasyonlar veri tekrarını azaltmak yerine yeni uyuşmazlıklar üretebilir.

Her şey özelleştirilmeli mi?

Hayır. İyi bir kurumsal yazılım projesinde özelleştirme sınırsız değişiklik anlamına gelmez. Güvenlik, kayıt izleri, veri bütünlüğü, yedekleme, kullanıcı yönetimi ve temel ürün mimarisi gibi alanlar standart ve sürdürülebilir kalmalıdır.

Doğru model üç katmanlıdır:

Bu yaklaşım, sıfırdan yazılım geliştirmenin bakım riskini azaltırken şirketi katı bir standart pakete de mahkûm etmez. [TMS satın alma, abonelik ve özel yazılım seçenekleri](/blog/tms-satin-almak-kiralamak-ozel-yazilim) değerlendirilirken yalnızca bugünkü özellikler değil, sistemin değişen operasyonla nasıl gelişeceği de dikkate alınmalıdır.

• **Standart çekirdek:** Sahada çalışan, güncellenen ve güvenliği yönetilen TMS altyapısı.
• **Yapılandırılabilir katman:** Kuruma özgü alanlar, roller, iş akışları, fiyat kuralları, raporlar ve bildirimler.
• **Kontrollü özel geliştirme:** Standart yapılandırmayla karşılanamayan ve gerçek iş değeri üreten özel ihtiyaçlar.

Kurumsal TMS projesi nasıl ilerlemeli?

Bu süreçte başarı yalnızca yazılımın teknik olarak çalışması değildir. Kullanıcının sistemi benimsemesi, saha verisinin zamanında gelmesi, manuel iş yükünün azalması ve yönetimin doğru rapora ulaşabilmesi birlikte ölçülmelidir.

• **Operasyon keşfi:** Müşteriler, projeler, taşıma tipleri, ekipler, taşıyıcılar, evraklar, finans ve mevcut sistemler haritalanır.
• **Hedef süreç tasarımı:** Korunacak iş kuralları, sadeleştirilecek adımlar ve otomasyon fırsatları belirlenir.
• **Öncelikli kapsam:** İlk fazda iş değerini hızlı gösterecek süreçler seçilir; bütün istisnaları ilk güne sıkıştırmak yerine kontrollü bir yol haritası hazırlanır.
• **Yapılandırma ve entegrasyon:** TMS, mobil uygulama, taşıyıcı pazaryeri ve kurumsal sistem bağlantıları birlikte kurulur.
• **Pilot operasyon:** Seçilen müşteri, proje veya bölgede gerçek seferlerle test yapılır.
• **Kademeli yayılım:** Kullanıcı eğitimi, veri kalitesi ve performans göstergeleri izlenerek kapsam genişletilir.
• **Sürekli geliştirme:** Yeni müşteri ve operasyon ihtiyaçları ürün yol haritasına kontrollü şekilde eklenir.

Kamyoon’un kurumsal yaklaşımı

Kamyoon, büyük firmalara yalnızca hazır ekranlar sunan bir nakliye programı yaklaşımıyla değil; sahada kullanılan TMS altyapısını kurumun işleyişine uyarlayan bir çözüm modeliyle yaklaşır.

Taşıma planlama ve araç atamadan canlı izlenebilirliğe, sürücü mobil uygulamasından kuruma özel taşıyıcı pazaryerine, dijital evraktan [navlun, mutabakat, faturalama ve ödeme](/navlun-mutabakat-sistemi) süreçlerine kadar bütün yapı aynı veri hattında ele alınabilir. ERP, muhasebe ve diğer kurumsal sistemlerle ihtiyaç doğrultusunda entegrasyon kurulabilir.

Amaç firmayı hazır bir kalıba zorlamak değildir. Amaç, kurumun güçlü iş yapış biçimini koruyan; gereksiz manuel adımları azaltan; büyüdükçe yeni müşteri, proje ve taşıyıcı yapılarına uyum sağlayan dijital bir lojistik işletim sistemi kurmaktır.

Sonuç: Yazılım operasyonun önünde engel değil, gelişim alanı olmalı

Büyük firmaların nakliye operasyonları standart değildir; kullanacakları sistem de katı bir kalıp olmamalıdır. Kurumsal TMS, sürücü mobil uygulaması, taşıyıcı pazaryeri ve entegrasyonlar birbirinden ayrı projeler olarak değil, aynı operasyon mimarisinin parçaları olarak tasarlanmalıdır.

Doğru çözüm, şirkete “Bizim sisteme uyun” demez. Şirketin süreçlerini analiz eder, standartlaştırılması gereken alanları sadeleştirir ve farklılaşan iş kurallarını sürdürülebilir bir yazılım yapısına dönüştürür.

**Firma yazılıma değil, yazılım firmaya uymalı.** Kamyoon TMS’in kurumunuza özel nasıl yapılandırılabileceğini, sürücü mobil uygulaması ve taşıyıcı pazaryeriyle nasıl genişletilebileceğini değerlendirmek için [demo talep edebilirsiniz](/iletisim#demo-form).