Teslimat yönetim sistemleri: hangi türleri var ve nerede ayrılıyorlar

Teslimat yönetim sistemi denince ne anlaşılıyor

Bu ad altında piyasada birbirinden bayağı farklı ürünler yaşıyor, bu yüzden önce sınırlarda anlaşmak gerekiyor. Teslimat yönetim sistemi operasyonel halkadan sorumludur — yani siparişin ortaya çıkmasıyla sahada tamamlandığının onaylanması arasında olan her şeyden. Tipik görev seti şöyle:

• siparişlerin kabulü ve saha çalışanlarına dağıtımı;
• harita üzerinde gerçek zamanlı rotalar;
• fotoğraflı raporlar ve kontrol listeleriyle saha çalışanının mobil uygulaması;
• durum takipli müşteri paneli;
• teslimat zaman pencerelerini ve kısıtları dikkate alan rota optimizasyonu;
• işin yerinde tamamlandığının onaylanması.

Sistemi muhasebe yazılımından ve CRM'den ayıran da budur: onlar paradan, belgelerden, müşterilerden ve satış fırsatlarından sorumludur; kuryenin şu an nerede olduğundan ve mutabık kalınan zaman penceresine neden yetişemediğinden değil. Pratikte sınırlar bulanıktır — bazı işlevler hem muhasebede hem de ayrı mobil servislerde karşımıza çıkar. Bu nedenle çözümleri kategori adına göre değil, sipariş döngüsünün hangi bölümünü gerçekten kapattıklarına göre karşılaştırmak anlamlıdır.

Böyle bir ürüne olan ihtiyacın genellikle nereden doğduğunu bilmek de işe yarar. Neredeyse hiç kimse onu "ileride gerekir" diye aramaz: gerekçe hep somut bir aksaklıktır. Dispeçer, saha çalışanlarından hangisinin nerede olduğunu aklında tutamaz hale gelir. Müşteri, ziyaretin ertelendiğini şirket öğrenmeden önce arar. Vardiya sonuçları akşam elle toplanır, tutarsızlıklar ise ertesi gün ortaya çıkar. Tam olarak hangi aksaklığı kapattığınızı biliyorsanız piyasa taraması kat kat kısalır: seçeneklerin çoğu, darboğazınıza dair ilk soruda elenir.

Beş çözüm sınıfı ve her birinin sınırı

Bugün teslimatın yönetildiği hemen her araç bu beş sınıftan birine giriyor. Aralarındaki fark işlev sayısında değil, çözümün hangi ölçekte yetersiz kalmaya başladığında.

• Tablolar ve mesajlaşma uygulamaları. Excel artı bir iş sohbeti: hiçbir maliyeti yok ve herkese tanıdık. Tavana hızla varılır — durumlar yalnızca yazışmanın içinde vardır, dağıtım elle yapılır, geçmiş kaybolur ve "teslim edildi mi edilmedi mi" tartışmasını çözecek bir dayanak kalmaz.
• Navigasyon uygulamaları ve haritalar. Noktalar arası güzergâhı iyi kurar ama siparişleri yönetmez: onları saha çalışanlarına dağıtmaz, zaman pencerelerini ve kısıtları dikkate almaz, işin yapıldığını kayda geçirmez ve raporlama vermez.
• Muhasebe sistemi veya CRM içindeki teslimat modülü. Veriler siparişlerin yanında durur, bu bir artı. Zayıf noktası saha tarafıdır: saha çalışanının telefondan rahat çalışması, fotoğraflı raporlar ve kontrol listeleri böyle modüllerde genellikle yüzeysel kapatılır.
• Sıfırdan yazılan özel geliştirme. Tam sizin sürecinize göre olur ama bedeli süreyle, belirli geliştiricilere bağımlılıkla ve süreç her değiştiğinde ortaya çıkan bakım maliyetiyle ödenir.
• Uzmanlaşmış platformlar — kurye ve saha çalışanı yönetimi için. Siparişin kabulünden yerinde onaylanmasına kadar tüm halka tek pencerede yaşar ve sizin veri kaynaklarınıza bağlanır.

itlogist bu son sınıfa girer: 5 ile 100 saha çalışanı arasındaki ekipler için bir kurye ve saha çalışanı yönetim sistemidir — itlogist'in özellikleri tek bir dispeçer halkasında toplanmıştır; sipariş dağıtımı, harita üzerindeki rotalar, saha çalışanının mobil çalışması ve müşteri için durum takibi dâhil.

Seçimin başında şirkette çoğu zaman tek bir sınıf değil, bir melez çalışır: siparişler CRM'e düşer, noktaların sırası navigasyonda kabaca kestirilir, vardiya raporu tabloda toparlanır ve bütün bunları sohbetteki yazışma birbirine bağlar. Bu düzen uzun süre ayakta kalır, hatta bedavaymış gibi görünür — maliyet dispeçerin saatleriyle ve boşa giden ikinci ziyaretlerle sayılmaya başlanana kadar. Uzmanlaşmış sınıfa geçmenin anlamı daha çok işlev elde etmek değil, araçlar arasındaki elle yapılan ekleme yerlerini ortadan kaldırmaktır: veriler tam da o ek yerlerinde kaybolur.

Karşılaştırma eksenleri: neye inanmalı değil, neye bakmalı

Çözüm sınıfı seçildikten sonra kendi içindeki karşılaştırmayı birkaç eksene indirmek kolaylık sağlar. Bu eksenler sağlamdır: her ürünü demoda bunlara göre, pazarlama cümlelerine güvenmeden sınayabilirsiniz.

• Döngü kapsamı. Sistem siparişi gelişinden tamamlanma onayına kadar yürütüyor mu, yoksa yalnızca tek bir aşamayı kapatıp geri kalanı birkaç ayrı servisten mi toplanıyor.
• Saha tarafı ve giriş eşiği. Saha çalışanının işe başlaması ne kadar kolay. itlogist'te bu, uygulama kurmayı zorunlu kılmayan mobil bir web arayüzüdür: kurye bağlantıyı açar ve kendi siparişlerini ve rotasını görür.
• Rotalama. Adresleri basitçe sıralamak ile gerçek optimizasyon arasında fark vardır. itlogist'te teslimat zaman pencerelerini ve kısıtları dikkate alan, OR-Tools tabanlı bir motor çalışır.
• Entegrasyonlar. Siparişler sisteme alışılmış kaynağınızdan düşmelidir: 1C, AmoCRM, Bitrix24 ve Excel destekleniyor.
• Müşteri için şeffaflık. Durum takipli müşteri paneli, dispeçerin üzerinden "siparişim nerede" telefonlarının akışını alır.
• Başlangıç koşulları. 7 günde devreye alma ve uzun vadeli sözleşme olmaması, sistemi aylar süren bir kurulum projesine girmeden kendi siparişlerinizde sınama olanağı verir.

Pratikten bir öneri: bu eksenlere göre kendi siparişlerinizle karşılaştırın. Demo veri seti her zaman derli toplu görünür — sizin gerçek adresleriniz, zaman pencereleriniz ve ertelemeleriniz sistemi daha dürüst gösterir.

Eksenlerin ağırlığı eşit değildir ve ağırlığı sizin darboğazınız belirler. Zaman siparişleri saha çalışanlarına paylaştırmaya gidiyorsa belirleyici olan dağıtım ve rotalamadır. En çok "yapıldı mı yapılmadı mı" tartışması yaşanıyorsa öne fotoğraflı raporlar ve kontrol listeleriyle saha tarafı çıkar. Yöneticiler verileri bir programdan diğerine yeniden giriyorsa en önemlisi entegrasyonlar ve durumların geri akışıdır. Eksenleri kendi önceliğinize göre önceden sıralayın — yoksa karşılaştırma, vardiya sonucunu hiç etkilemeyen arayüz ayrıntılarının tartışılmasına kayar.

Karşılaştırma tablolarında görünmeyenler

"İşleve karşı işlev" tabloları kullanışlıdır ama birkaç önemli şey neredeyse hiç bu tablolara girmez. Sistemin tutup tutmayacağını, yoksa kimsenin girmediği ikinci bir pencere olarak mı kalacağını sonradan tam da onlar belirler.

• Verinin geri akışı. Siparişi sisteme girmek kolaydır — soru, sonucun sizin muhasebenize dönüp dönmediğidir: yapıldığı gerçeği ve zamanı, durum, onaylar. Geri akış olmadan yönetici her şeyi elle girmeye devam eder.
• Doldurma disiplini. Verileri sisteme sahadaki çalışan girer. Arayüz ondan ne kadar çok işlem isterse, dayandığınız veriler o kadar cılız ve o kadar geç gelir.
• Kataloğu kim tutuyor. Müşteriler ve adresler iki yerde açılıyorsa mükerrer kayıtlar başlar — kuralı en baştan belirlemek gerekir.
• Hata durumundaki davranış. Adres boşsa veya müşteri bulunamıyorsa siparişe ne olur: sessizce kaybolur mu, yoksa incelenmek üzere bir kuyruğa mı düşer.
• Vaat edilen tasarruf yüzdeleri. Karşılaştırmayı bunlara göre yapmak olmaz: etki, noktaların yoğunluğuna, zaman pencerelerinin uzunluğuna ve saha çalışanlarının disiplinine bağlıdır. Bunu bir pilotta kendi rotalarınızda sınamak gerekir.

Demoda yapılacak pratik test beş dakika sürer: kendi siparişlerinizden birini baştan sona geçirmelerini isteyin — kaynaktan sisteme, saha çalışanına, mobil arayüze ve durumuyla birlikte geri. Yol elle kopyalama olmadan tamamlanıyorsa entegrasyon çalışıyor demektir.

Tablolarda görünmeyen bir kalem daha var: sahip olma maliyeti. Lisans veya abonelik tutarın yalnızca bir parçasıdır; buna sizin sürecinize göre yapılandırma, dispeçerlerin ve saha çalışanlarının eğitimi ve çalışma kuralları her değiştiğinde gereken destek eklenir. Özel geliştirme burada en sinsi olanıdır: geliştirme tek seferlik bir yatırım gibi görünür, bakım ise sürekli ve belirli kişilere bağımlı çıkar. Bu yüzden karşılaştırmada aylık fiyatı değil, şu sorunun cevabını masaya koymak daha dürüsttür: kararın alınmasından, bir vardiyanın baştan sona koltuk değneği olmadan sistemin içinde geçtiği ana kadar ne kadar zaman geçecek.

Sizin segmentinize ne uyar

Sistemden beklenenler, sahadaki çalışanlarınızın ne işle uğraştığına göre belirgin biçimde farklılaşır. Aynı ürün kurye teslimatını mükemmel kapatırken saha servisinin ihtiyaçlarının yanından geçebilir.

• Kurye teslimatı. Sipariş akışının hızlı dağıtımı, harita üzerinde gerçek zamanlı rotalar, durum takibi ve teslimatın onaylanması kritiktir. Noktaların yoğunluğu yüksektir; öncelik işlem hızı ve alıcı için şeffaflıktır.
• Saha servisi — montaj, onarım, ölçüm, bakım. Ziyaret uzun ve içerikli olur: yalnızca "geldim" işareti değil, kontrol listeleri, fotoğraflı raporlar ve işin yerinde tamamlandığının onaylanması önemlidir.
• Dağıtım ve satış temsilcileri. Satış noktalarına düzenli rotalar, ziyaret kontrolü ve verilerin doğrudan sahada toplanması gerekir.

Buradan basit bir seçim kuralı çıkar: bir sistem baştan tek bir senaryo için yapılmışsa komşu senaryoları ancak zorlama ile kapatır. itlogist gibi platformlar üç segmenti de tek halkayla kapsar — şirkette hem teslimat, hem saha işleri, hem de saha satışları varsa ve birbirinden kopuk üç araç taşımak istenmiyorsa bu rahatlık sağlar.

Ekibin bileşimine de bakın. Bir kısmı kadrolu, bir kısmı sezon zirvesinde devreye giren karma bir kadro kendi koşulunu getirir: yeni gelen daha ilk gün çalışmaya başlayabilmeli, telefonuna kurulum ve ayar yapmadan. Sezonluk dalgalanma ise ikinci koşulu ekler: sezon dışında beş saha çalışanıyla da, zirvede birkaç düzine kişiyle de süreçleri yeniden kurmadan rahatça yaşayabilmek. 5 ile 100 saha çalışanı aralığı tam da böyle ekipleri anlatır: sistem ne alt sınırda ne üst sınırda çatlamamalı.

Kısa bir seçim algoritması

Genel bakışı, gereksiz karşılaştırma turları olmadan karara gitmeyi kolaylaştıran bir adım dizisinde toplayalım.

• Darboğazınızı tanımlayın. Şu anda zamanı tam olarak ne yiyor: elle dağıtım, saha çalışanlarını tek tek arama, kaybolan siparişler yoksa tartışmalı ziyaret sonuçları.
• Uygun olmayan sınıfı eleyin. İşin yapıldığının kaydı ve sahada mobil çalışma gerekiyorsa tablolar ve navigasyon uygulamaları hemen devre dışı kalır — bu katmanı kapatmıyorlar.
• Sipariş kaynağıyla entegrasyonu kontrol edin. 1C, CRM veya Excel — siparişler sisteme elle taşınmadan düşmelidir.
• Kendi verilerinizle pilot yapın. Bir iki gerçek vardiyanın tamamı, her sunumdan fazlasını gösterir.
• Giriş koşullarını değerlendirin. Kısa devreye alma ve uzun sözleşmelerin olmayışı, hata bedelinin küçük olduğu anlamına gelir.

Genel bakışın sonucu basittir: "en çok işlevli" sistem seçilmez; dispeçerin ve saha çalışanlarının tablolara ve telefon görüşmelerine kıyasla daha hızlı çalıştığı ve yapılan işe dair verilerin muhasebenize kendiliğinden ulaştığı sistem seçilir.

Pilota önceden başarı ölçütleri koymak gerekir — yoksa tartışmanın sonu zevk meselesine döner. Makul bir asgari set: dispeçer vardiyayı kimseyi aramadan kurdu; saha çalışanları noktaları fotoğraflı onayla kapattı; müşteri durumları kendi başına gördü; vardiya sonucu elle taşınmadan muhasebeye düştü; ertelemeler ve iptaller sohbette kalmayıp gerekçesiyle kayda geçti. Beş maddeden dördü daha ilk hafta sağlanıyorsa sınıf da ürün de doğru seçilmiş. Sağlanmıyorsa hata neredeyse her zaman ayarlarda değil çözüm sınıfındadır ve ilk adıma dönmek gerekir.