Bir rota optimizasyon yazılımı satın almayı düşünen işletmeler genellikle benzer sorularla başlar: Yazılım kaç teslimatı planlayabiliyor? Rotaları ne kadar hızlı hesaplıyor? Harita üzerinde sonuçları gösterebiliyor mu?

Bunlar önemli sorulardır. Ancak tek başlarına doğru yazılımı seçmek için yeterli değildir.

Bir optimizasyon yazılımı, yüzlerce teslimatı kısa sürede planlayabilir. Fakat müşterilerin teslimat saatlerini karşılamıyor, araç kapasitelerini yanlış değerlendiriyor veya mevcut operasyon iş akışına uymuyorsa hızlı sonuç üretmesi işletmeye beklenen faydayı sağlamayabilir.

Doğru rota optimizasyon yazılımı, yalnızca iyi rotalar hesaplayan değil, işletmenin gerçek kısıtlarını doğru modelleyen ve sonuçları uygulanabilir planlara dönüştüren yazılımdır.

Bu rehberde bir yazılımı satın almadan önce hangi özelliklerin incelenmesi gerektiğini, farklı çözümlerin nasıl karşılaştırılabileceğini ve gerçek operasyon verileriyle nasıl pilot çalışma yapılabileceğini ele alacağız.

1. Önce probleminizi tanımlayın

Bir yazılımın uygunluğunu değerlendirmeden önce işletmenin çözmek istediği problem netleştirilmelidir.

Örneğin aşağıdaki işletmelerin ihtiyaçları aynı değildir:

  • Her gün aynı müşterilere sevkiyat yapan bir distribütör.
  • Siparişlerin günlük değiştiği bir e-ticaret dağıtım operasyonu.
  • Farklı kapasitelere sahip araçlar kullanan bir lojistik şirketi.
  • Görevleri birden fazla güne dağıtmak zorunda olan bir üretici.
  • Teslimat saatlerinin kritik olduğu bir mağaza zinciri.

Bu nedenle ihtiyaç analizi yalnızca teslimat sayısıyla sınırlı kalmamalıdır.

İşletmenin araç sayısı, sürücü sayısı, teslimat noktaları, planlama sıklığı, yük çeşitleri ve mevcut iş kuralları da belirlenmelidir.

Örneğin bir işletme için temel sorun gereksiz seyahat mesafesiyken başka bir işletme için en büyük sorun siparişlerin uygun araçlara ve teslimat günlerine atanması olabilir.

Satın alınacak yazılımın başarısı, bu sorunlardan hangilerini çözebildiğine göre değerlendirilmelidir.

2. Optimizasyon motoru gerçek kısıtlarınızı destekliyor mu?

Araç Rotalama Problemi (Vehicle Routing Problem — VRP), farklı operasyonel kısıtlarla genişletilebilen bir matematiksel optimizasyon problemidir.

Google OR-Tools’un teknik dokümantasyonunda araç kapasitesi, zaman pencereleri, depo kaynakları ve bazı ziyaretlerin ceza maliyetiyle atlanabilmesi gibi farklı problem türleri açıklanmaktadır. [1]

Ancak bir optimizasyon kütüphanesinin belirli bir kısıtı desteklemesi, o kütüphaneyi kullanan her ticari yazılımın aynı özelliği sunduğu anlamına gelmez.

Bu nedenle yazılımın kullanıcıya sunduğu gerçek yetenekler ayrıca doğrulanmalıdır.

Kontrol edilmesi gereken başlıca kısıtlar

  • Araç kapasitesi: Yükler ağırlık, hacim veya diğer kapasite birimleriyle değerlendirilebiliyor mu?
  • Teslimat zaman pencereleri: Müşterilerin kabul saatleri ve durak hizmet süreleri dikkate alınıyor mu?
  • Araç ve sürücü uygunluğu: Kullanılamayan kaynaklar planlama dışında bırakılabiliyor mu?
  • Farklı araç özellikleri: Araçların kapasite, maliyet ve erişim koşulları ayrı ayrı tanımlanabiliyor mu?
  • Görev-atama kuralları: Bazı teslimatların yalnızca uygun kaynaklara atanması sağlanabiliyor mu?
  • Çok günlü planlama: Görevlerin hangi gün gerçekleştirileceği de planlamanın bir parçası olabiliyor mu?
  • Karşılanamayan görevler: Bütün görevler planlanamadığında sistem nedenlerini ve sonuçlarını anlaşılır şekilde gösterebiliyor mu?

Son soruya özellikle dikkat edilmelidir. Bazı optimizasyon modelleri, belirli görevleri gerçekleştirmemeye izin veren ceza maliyetleri içerebilir. Bu yöntem matematiksel olarak anlamlı olsa da işletme açısından zorunlu bir teslimatın atlanması kabul edilemez olabilir. [2]

Dolayısıyla yazılımın, planlanamayan görevleri sessizce göz ardı etmemesi önemlidir.

3. Yazılımı yalnızca toplam kilometre üzerinden karşılaştırmayın

İki rota optimizasyon yazılımının sonuçlarını değerlendirirken en sık yapılabilecek hatalardan biri, yalnızca toplam mesafeyi karşılaştırmaktır.

Örneğin:

Ölçüt Yazılım A Yazılım B
Toplam mesafe 420 km 450 km
Planlanan teslimat 48 50
Planlanamayan teslimat 2 0

Bu tabloya yalnızca mesafe açısından bakıldığında Yazılım A daha iyi görünebilir.

Ancak A çözümü iki teslimatı karşılamamaktadır.

Eğer bu iki teslimat zorunluysa, A’nın düşük kilometresi tek başına bir avantaj değildir.

Hatta işletmenin kurallarına göre bu plan kabul edilemez olabilir.

Karşılaştırma yapılırken önce zorunlu kısıtların karşılanıp karşılanmadığı, ardından uygun çözümlerin maliyet ve performans değerleri değerlendirilmelidir.

Yukarıdaki rakamlar temsili bir karşılaştırmadır; gerçek yazılım testlerinden elde edilmiş sonuçlar değildir.

4. Aynı veri setiyle, aynı koşullarda test yapın

Bir yazılımı değerlendirmek için en yararlı yöntemlerden biri, işletmenin gerçek operasyonunu temsil eden verilerle pilot çalışma gerçekleştirmektir.

Ancak pilot testin doğru tasarlanması gerekir.

Farklı araç sayıları, farklı seyahat süresi tahminleri veya farklı zorunlu kısıtlar kullanan iki sistemi doğrudan karşılaştırmak yanıltıcı olabilir.

Bu nedenle testte aşağıdaki unsurlar mümkün olduğunca eşitlenmelidir:

  • Aynı sipariş ve teslimat noktaları.
  • Aynı kullanılabilir araç ve sürücü bilgileri.
  • Aynı kapasite değerleri.
  • Aynı teslimat ve çalışma saatleri.
  • Aynı zorunlu görevler.
  • Aynı veya karşılaştırılabilir seyahat süresi ve mesafe verileri.
  • Aynı hedef fonksiyonu veya açıkça tanımlanmış ortak değerlendirme ölçütleri.

Özellikle rota optimizasyonunda kullanılan mesafe matrisi önemlidir. Bir yazılım farklı yol ağı verisiyle hesaplama yapıyorsa toplam kilometre farkı yalnızca optimizasyon algoritmasından kaynaklanmayabilir.

Çözüm süresi nasıl karşılaştırılmalı?

Algoritmaların hesaplama bütçesi sonuç kalitesini etkileyebilir.

OR-Tools, rota optimizasyonunda farklı arama stratejilerinin ve süre sınırlarının kullanılabileceğini belgelendirir. [3]

Bu nedenle bir yazılımı 10 saniye, diğerini 10 dakika çalıştırıp yalnızca sonuç mesafelerini karşılaştırmak dengeli bir değerlendirme olmayabilir.

Ayrıca rastgelelik içeren yöntemlerde aynı problem birden fazla kez çalıştırıldığında farklı sonuçlar elde edilebilir.

PyVRP’nin resmî karşılaştırma yöntemi, işlemci performansına göre normalize edilmiş süre bütçeleri ve farklı rastgele başlangıç değerleriyle tekrarlanan çalıştırmalar kullanır. [4]

Bir işletmenin pilot çalışmasında bu düzeyde akademik test altyapısı kurulması zorunlu değildir. Ancak tekrar eden denemeler, sabit veri sürümleri ve kayıt altına alınmış çalışma süreleri daha güvenilir karşılaştırmalar sağlar.

5. Beş senaryolu bir pilot test hazırlayın

Tek bir başarılı demo, yazılımın gerçek operasyonların tamamında uygun çalışacağını göstermez.

Bu nedenle satın alma öncesinde aşağıdaki beş senaryonun denenmesini öneriyoruz.

Senaryo Test edilmek istenen konu
Normal operasyon günü Günlük iş yükünün doğru planlanması
Yoğun sipariş günü Artan görev sayısında çözümün davranışı
Dar teslimat pencereleri Zaman kısıtlarına uygunluk
Araç veya sürücü eksikliği Kaynak yetersizliğinin yönetimi
Çok günlü operasyon Gün seçimi ve kaynak uygunluğu

Her senaryo için yalnızca hesaplama süresi değil, oluşturulan planın uygulanabilirliği de incelenmelidir.

Örneğin bir aracın kullanılamadığı senaryoda yazılımın geçersiz bir plan üretmek yerine kısıtları dikkate alması, planlanamayan görevleri bildirmesi veya uygulanabilir alternatifleri göstermesi önemlidir.

Bu senaryo listesi, satın alma değerlendirmesi için geliştirdiğimiz editoryal bir kontrol çerçevesidir; belirli bir bilimsel standardın zorunlu test listesi değildir.

6. Planlama sonucu operasyon ekibi tarafından anlaşılabiliyor mu?

Optimizasyon motorunun hesapladığı çözüm ile planlama ekibinin kullanabildiği sonuç aynı şey değildir.

İşletmenin aşağıdaki sorulara kolayca cevap bulabilmesi gerekir:

  • Hangi görev hangi araca atandı?
  • Hangi teslimat hangi sırada yapılacak?
  • Araç kapasitesi ne kadar kullanılıyor?
  • Hangi görevler planlanamadı?
  • Rotaların tahmini başlangıç ve bitiş saatleri nedir?
  • Gerekirse plan nasıl inceleniyor veya yeniden değerlendiriliyor?

Harita ve zaman çizelgesi gibi görsel bileşenler, planların anlaşılmasına yardımcı olabilir.

Ancak görsel açıdan etkileyici bir harita, tek başına doğru planlama yapıldığını kanıtlamaz.

Bu nedenle yazılımın hesaplama sonuçlarını açık, denetlenebilir ve operasyonel kararlara dönüştürülebilir biçimde sunması önemlidir.

7. Veri aktarımı ve entegrasyon ihtiyacını değerlendirin

Rota optimizasyonu, işletmenin diğer süreçlerinden bağımsız çalışmaz.

Siparişlerin hangi sistemde oluşturulduğu, müşteri adreslerinin nerede tutulduğu ve planlama sonuçlarının hangi ekiplerle paylaşılacağı önemlidir.

Bu nedenle satın alma öncesinde şu konular doğrulanmalıdır:

  • Veri aktarımı: Sipariş ve müşteri bilgileri nasıl içe aktarılıyor?
  • Veri doğrulama: Eksik adres veya hatalı kapasite bilgileri nasıl ele alınıyor?
  • Entegrasyon: Mevcut ERP, WMS veya TMS sistemleriyle bağlantı kurulabiliyor mu? Hangi bağlantılar hazır, hangileri özel geliştirme gerektiriyor?
  • Operasyon aktarımı: Onaylanan planlar saha ekiplerine hangi yöntemle iletiliyor?
  • Veri güvenliği: Erişim kontrolü, veri saklama, yedekleme ve hizmet sürekliliğine ilişkin koşullar nelerdir?

Burada satıcının pazarlama materyali yerine gerçek ürün davranışının, teknik belgelerinin ve sözleşme şartlarının değerlendirilmesi gerekir.

ISO/IEC 25010:2023 standardı, yazılım ürünlerinin kalitesini gereksinim tanımlama ve değerlendirme aşamalarında ele almak için kullanılabilecek bir kalite modeli sunar. [5]

Bu standardın varlığı, incelenen herhangi bir yazılımın kendiliğinden standarda uygun veya sertifikalı olduğu anlamına gelmez.

8. Toplam sahip olma maliyetini hesaplayın

Rota optimizasyon yazılımının toplam maliyeti yalnızca aylık abonelik ücretinden oluşmayabilir.

Değerlendirmeye aşağıdaki maliyet kalemleri dahil edilebilir:

  • Yazılım aboneliği veya lisansı.
  • Kurulum ve ilk yapılandırma.
  • Veri hazırlama ve entegrasyon.
  • Kullanıcı eğitimi.
  • Devam eden destek.
  • Kullanıma bağlı ek ücretler.
  • İş süreçlerini değiştirmek için gereken iç kaynaklar.

Benzer şekilde yazılımın sağlayabileceği faydalar da tek bir kilometre metriği üzerinden hesaplanmamalıdır.

Planlama için harcanan zaman, operasyonel hatalar, araç kullanımı, teslimat uyumu ve toplam taşıma maliyeti birlikte değerlendirilebilir.

Ölçülmemiş tasarruf oranları yerine, işletmenin kendi başlangıç verileriyle karşılaştırılabilir sonuçlar kullanılmalıdır.

9. Son kararı vermek için iki aşamalı değerlendirme kullanın

Yazılım karşılaştırmasını iki aşamada yürütmek yararlı olabilir.

Aşama 1: zorunlu gereksinimler

Önce yazılımın işletmenin vazgeçilmez ihtiyaçlarını karşılayıp karşılamadığı belirlenir.

Örneğin kapasite sınırı ve teslimat zaman pencereleri zorunluysa bunları karşılamayan bir yazılım, diğer alanlarda yüksek puan alsa bile uygun seçenek olmayabilir.

Aşama 2: uygun seçeneklerin puanlanması

Zorunlu koşulları karşılayan çözümler, işletmenin önceliklerine göre değerlendirilebilir.

Örnek bir puanlama:

Değerlendirme alanı Örnek ağırlık
Planın maliyet ve operasyonel başarımı %30
Kullanılabilirlik ve sonuçların incelenmesi %20
Entegrasyon ve veri yönetimi %20
Performans ve güvenilirlik %15
Toplam sahip olma maliyeti ve destek %15
Toplam %100

Bu ağırlıklar örnektir; bilimsel olarak bütün işletmeler için doğrulanmış ideal oranlar değildir.

Bir işletme entegrasyona daha fazla önem verebilirken başka bir işletme planlama esnekliğine veya operasyonel performansa öncelik verebilir.

Trackinia değerlendirme sürecinde nasıl ele alınabilir?

Trackinia; araç ve sürücü planlaması, operasyonel kısıtlara dayalı rota optimizasyonu ve günlük veya çok günlü planlama ihtiyaçlarına odaklanan bir platformdur.

Araç kapasiteleri, zaman pencereleri, kaynak uygunlukları ve görev atama koşulları gibi kısıtlar planlama sürecinde değerlendirilebilir.

Oluşturulan planların harita ve zaman çizelgesi üzerinden incelenmesi, sonuçların operasyon ekipleri tarafından değerlendirilmesine yardımcı olur.

Ancak herhangi bir yazılımda olduğu gibi Trackinia’nın uygunluğu da işletmenin gerçek verileri, iş kuralları ve ihtiyaçları üzerinden test edilmelidir. Bunun için teslimat yapınız ve iş kurallarınız üzerinden bir Trackinia demosu talep edebilirsiniz.

Sonuç

Rota optimizasyon yazılımı seçimi, yalnızca en kısa rotayı üreten ürünü bulma süreci değildir.

Doğru seçim; gerçek kısıtların desteklenmesini, planların uygulanabilirliğini, kullanıcı deneyimini, entegrasyon olanaklarını ve toplam maliyeti birlikte değerlendirmeyi gerektirir.

Satın alma kararından önce işletmenin kendi verileriyle küçük ama temsil gücü yüksek bir pilot çalışma yapılması, pazarlama vaatlerinden daha yararlı sonuçlar sağlayabilir.

Editoryal not: bu makaledeki yazılım karşılaştırma tablosu, beş pilot senaryo ve ağırlıklı puanlama modeli, satın alma değerlendirmesini açıklamak için tarafımızdan hazırlanmıştır. Gerçek bir karşılaştırmalı ürün testi veya bilimsel deney sonucu değildir.