Satış sürecinizi taşıma şemanızı ve söyleyelim önce neyin otomatikleştirileceğini
Talepler nereden geliyor, rotalar şu anda nasıl planlanıyor, durumları kim yürütüyor ve verileriniz hangi programlarda duruyor.
Lojistik yazılımı
Talepler, rotalar, yükler ve teslimat tek sistemde
Taşıma sayısı azken hepsi akılda, tabloda ve yazışmada tutulur. Hacim büyüdükçe bu yürümez olur: yükün nerede olduğunu yalnızca sürücü, kimin kime ne söz verdiğini yalnızca talebi alan bilir. Lojistik programı bu çalışma biçimini ortadan kaldırır: talep, rota, yük ve teslimat durumu tek sistemde kayıtlara dönüşür, dispeçer ise onları tek ekranda görür. Aşağıda bunun nasıl kurgulandığı anlatılıyor — talebin gelişinden teslim alma onayına kadar.
Nedir
lojistik yönetim sistemi
Lojistik yönetim sistemi — taşımaların kaydını tutan programdır: talepleri alır, onlardan rotalar oluşturur, sorumluları atar, yükün hareketini izler ve her teslimatta ne olduğunun geçmişini saklar.
Farkı tek bir örnekte görmek mümkün. Sistemsiz talep mesajlaşma uygulamasında, rota dispeçerin kâğıdında, yükün durumu ise sürücünün aklında yaşar. Müşteriye «yüküm nerede» diye sorduğunda yanıt vermek için üç kişiyi aramak gerekir. Yarın kaç aracın dolu olduğunu kimse bilmez, çünkü bu sayı hiçbir yerde hesaplanmamıştır.
Sistemde bunların hepsi kayıttır. Talebin numarası, göndereni, alıcısı, süresi ve güncel durumu vardır. Rotanın nokta listesi, geziş sırası ve sorumlusu vardır. Yükün ise sözle değil programdaki bir işlemle değişen bir durumu. «Yük nerede» sorusunun yanıtı saniyeler alır ve bugün kimin vardiyada olduğuna bağlı değildir.
Örnek. Müşteri perşembe günü taşıma talebi bıraktı. Operatör adresi ve ölçüleri denetledi, talebi cuma rotasına koydu, sistem onu altı başka noktayla birlikte sürücüye atadı. Sabah sürücü görev listesini açtı, yükün alındığını işaretledi, akşam teslimatı. Bu sırada müşterinin durumu değişiyordu; cuma akşamına şirketin elinde özet hazırdı: kaç nokta gezildi, kaçı süresinde yetişti ve hangi teslimatta aksama oldu.
Lojistik otomasyonu üç sorunun yanıtı dispeçerin aklında durmaz olduğunda başlar: şu anda kaç talep işlemde, belirli bir yük nerede ve dün iki teslimat neden ertesi güne kaldı.
- 1Talep
- 2Doğrulama
- 3Rota
- 4Sorumlu
- 5Sevkiyat
- 6Hareket
- 7Teslimat
- 8Dispeçer
Bağ iki yönlüdür: görev soldan sağa gider, sorumlunun işaretleri ve olaylar geri döner. Teslimat, sürücü adresten ayrıldığında değil, teslim alma onaylandığında gerçekleşmiş sayılır. Bu adım olmadan sistem, yükler hakkında olup biteni değil inandığı şeyi anlatırdı.
Sistem her taşıma hakkında ne bilir
- Neyi taşıdığımızı — yükün adı, kap sayısı, ağırlık, hacim, özel taşıma koşulları
- Nereden nereye — alım adresi, teslimat adresi, iki taraftaki ilgili kişiler
- Ne zaman — teslim süresi, alıcıdaki zaman aralığı, fiili çıkış ve teslim alma zamanı
- Kimin sorumlu olduğunu — sürücü ya da kurye, araç, rota, ofisteki sorumlu çalışan
- Hangi durumda olduğunu — güncel durum ve yazarı ile zamanıyla tüm değişim zinciri
- Neyle kanıtlandığını — belgeler, fotoğraflar, alıcının imzası, sorumlunun notları
Sistemin kendisinin yapmadıkları
Program araç kullanmaz ve dispeçerin yerini almaz. Kararın çevresindeki elle yapılan işi ortadan kaldırır: talepleri tek yerde toplar, doluluğu gösterir, noktanın kaybolmasına izin vermez ve her değişikliği kayda geçirir. Acil siparişin kime verileceğine ve geciken müşterinin beklenip beklenmeyeceğine insan karar verir — ama kararı hatırayla değil tam bir tabloyla verir.
Aynı şekilde sistem trafiği ve havayı kendiliğinden «bilmez»: dış veriler ona entegrasyonla gelir ve kapsamları projeyle belirlenir.
Genellikle nereden başlanır
Sisteme önce rotalar ve haritalar değil, taleplerin kaydı taşınır. Nedeni basittir: talepler yazışmada yaşadığı sürece her rota eksik bir listeye göre kurulur ve her rapor, birinin yazmayı unutmadığı şeye göre hesaplanır.
Hangi görevleri sistem çözer
Aşağıdaki bir işlev listesi değil, lojistiğin otomatikleştirilmesinin altı nedenidir. Her biri aynı biçimde ifade edilir: programsız ne olur ve onunla ne değişir.
Talepler kaybolmaz
Sistemsiz talep mesajlaşma uygulamasına, e-postaya ve telefona gelir; kaderi ise birinin onu yazıp yazmadığına bağlıdır. Sistemde her talep numarası, yazarı ve süresi olan bir kayıttır: ya işlemdedir ya kapalıdır, üçüncü bir durum yoktur. Kaybolan talep müşteri aradığında değil, hemen görünür olur.
Rota hatıradan değil taleplerden kurulur
Dispeçer yarınki tüm noktaları liste halinde görür: adresler, aralıklar, ölçüler. Noktalar rotalara toplanır, rotanın bir sorumlusu ve geziş sırası olur. Unutulan nokta fark edilmeden ertesi güne kalmaz — dağıtılmamış olarak kalır ve ayrı bir listede görünür.
İnsanların ve araçların doluluğu görülür
Araca kaç nokta atandığı, ağırlık ve hacim olarak ne kadar yer kaldığı, hangi sürücünün bir saat sonra vardiyayı bitireceği. Bu sayılar olmadan yük göz kararıyla dağıtılır ve bir araç yarı boş yola çıkarken diğeri akşama yetişemez.
Yükün durumu telefonla öğrenilmez
Teslimatın durumunu, onu yapan kişi işlem anında değiştirir. Dispeçer, müşteri temsilcisi ve müşteri aynı kayda bakar. «Yüküm nerede» sorusu üç kişilik bir iş olmaktan çıkar.
Teslim alma onayı kayda geçer
Yükü kimin, ne zaman ve hangi dayanakla teslim aldığı bir hatıra değil, sistemdeki bir kayıttır. İmza, fotoğraf ya da onay kodu belirli bir teslimata bağlıdır. «Getirdiler — getirmediler» tartışması bir soruşturmayla değil, kartın açılmasıyla çözülür.
Aksamalar olgulara göre incelenir
Gecikmeler, iptaller, iadeler ve başarısız teslimatlar nedeni olan ayrı olaylara dönüşür. Ay sonunda «her şey olabilir» değil, somut bir liste görünür: kaç aksama, hangi yönlerde ve neden.
Nelerden oluşur: sistem
Sistem modüllerden kurulur. Hepsi her şirkete gerekmez: şehir içi teslimat servisine şehirlerarası sefer kaydı, kendi aracı olan üretime ise sipariş borsası gerekmez. İçerik göreve göre belirlenir, ama modüller sonradan yandan eklenmez, birbirine önceden geçer.
Taleplerin alınması ve işlenmesi
Sistemin giriş noktası: göndereni, alıcısı, yük içeriği, süresi ve koşulları olan taşıma talebi. Talepler müşteri temsilcisinden, müşterinin kendi hesabından ya da API üzerinden dış bir sistemden gelir — sonrasında hepsi aynı kurallarla yaşar.
Rotalar ve teslimat noktaları
Noktaların rotaya toplanması, geziş sırası, araç ve sorumlu ataması, gün içinde rotanın değiştirilmesi. Rota da talep gibi bir muhasebe nesnesidir: tarihi, durumu ve değişiklik geçmişi vardır.
Yük kaydı
Tam olarak neyin taşındığı: kaplar, ağırlık, hacim, ambalaj, özel koşullar. Yük; talebe, rotaya, belgelere ve güncel duruma bağlıdır, bu yüzden herhangi bir taraftan diğerleri bulunur.
Araçlar ve sorumlular
Araç ve kişi kataloğu: taşıma kapasitesi, kasa hacmi, araç tipi, çalışma programı, hizmet bölgesi. Doluluk buradan gelir — bugün bu araca kaç nokta daha konabilir.
Dispeçer paneli
Çalışanın çalışma alanı: etkin teslimatlar, rotalar, sorumlular, durumlar, gecikmeler ve sorunlu siparişler tek ekranda. Tarayıcıda açılır, kurulum gerektirmez.
Durumlar ve olaylar
Teslimat durumlarının sonlu kümesi ve aralarındaki geçiş kuralları. Her değişiklik; yazarı, zamanı ve dayanağı olan bir olaydır; olaylar, aksamanın sonradan inceleneceği bir geçmişe dönüşür.
Depoyla bağlantı
Toplama ve sevkiyatla birleşme noktası: ne toplandı, ne devre hazırlandı, fiilen sürücüye ne verildi. Bu olmadan depo ve teslimat iki ayrı kayıtta yaşar ve daha öğlene ayrışır.
Sorumlunun çalışma alanı
Sürücü ve kuryenin uygulaması ya da mobil arayüzü: görev listesi, adresler, geziş sırası, yüke dair veriler, durum değişimi, alım ve teslim onayı, dispeçerle iletişim.
Bildirimler
Müşteriye ve çalışana mesajlar: talep alındı, yük alındı, kurye yola çıktı, teslimat ertelendi, teslimat gerçekleşmedi. Mesaj iletim kanalları devreye alma sırasında seçilir ve entegrasyonla bağlanır.
Roller ve yetkiler
Talep operatörü, dispeçer, depo görevlisi, sürücü, yönetici. Rotanın değiştirilmesi, teslimatın iptali, adresin düzeltilmesi ve alıcıların kişisel verilerine erişim tek bir «çalışan» paketi değil, ayrı yetkilerdir.
Analitik ve raporlama
Teslimat sayısı, süresinde tamamlananların oranı, araç ve insan doluluğu, rotaların verimliliği, sorunlu siparişler listesi. Raporlar dosya olarak aktarılır ve programa göre oluşturulur.
API ve entegrasyonlar
Sistemin dış arayüzü: talep oluştur, durumu öğren, rotayı al, teslim onayını ilet, günlüğü çek. Bunun üzerinden çevrimiçi mağaza, CRM, ERP ve depo sistemi bağlanır.
Sipariş yönetimi
talepten teslimata
Taşıma talebi — neyin nereye, hangi süreye kadar, kimin hesabına ve hangi koşullarla taşınacağını sabitleyen belgedir. Sonrasındaki her şey — rota, sorumlu, durumlar, belgeler — onun numarasına bağlıdır.
Talep sisteme üç yoldan biriyle girer: müşteri temsilcisi oluşturur, müşteri kendi hesabından açar ya da şirketin başka bir programı API üzerinden iletir. Kaynak farklı, sonraki yol aynıdır — aksi halde siparişlerin bir bölümü için kendi gayriresmî işleme düzeni doğardı.
Doğrulama — biçimsel bir adım değil, ayrı bir adımdır. Sistem zorunlu alanların dolu olup olmadığına, alıcının katalogda bulunup bulunmadığına, yükün izin verilen ölçülere sığıp sığmadığına, sürenin mümkün olanın dışına çıkıp çıkmadığına bakar. Tartışmalı talep sessizce rotaya gitmez: anlaşılır bir nedenle netleştirme listesinde kalır.
Talep neleri içerir:
- Numara, oluşturulma tarihi, yazar ve kaynak — kimin nereden açtığı
- Farklı kişilerse müşteri ve ödeyen
- İlgili kişileriyle alım adresi ve teslimat adresi
- Yükün içeriği: ad, kap sayısı, ağırlık, hacim, ambalaj
- Teslim süresi ve alıcıya uygun zaman aralığı
- Koşullar: teslimde ödeme, kırılabilir yük, kata çıkarma gerekiyor, ikinci kişi gerekiyor
- İlişkili belgeler: irsaliye, fatura, başka bir sistemden sipariş
Teslimata atama — talebin bir niyet olmaktan çıkıp işe dönüştüğü an. Belirli bir günün rotasına girer, bir sorumlusu olur, sorumlunun listesinde ise bir görev belirir. Bu andan itibaren talep hem dispeçer panelinde hem sürücünün uygulamasında hem de müşterinin geçmişinde görünür.
Düzeltmelerin bir bölümü günün planını değiştirir: yeni adres rotanın dışına düşebilir, artan ağırlık atanan araca sığmayabilir. Böyle bir talep sessizce düzeltilmez — nedeniyle birlikte yeniden planlama için dispeçere döner.
Tek bir talebin yolu
- OluşturulduMüşteri temsilcisi talebi açtı: iki kap, 46 kg, depodan alım, cuma günü 18:00'e kadar alıcının adresine teslim
- DenetlendiAdres katalogda bulundu, ölçüler araç tipine sığıyor, süre gerçekçi — talep planlamaya alındı
- Rotaya konduNokta cuma rotasına, geziş sırasında dördüncü olarak eklendi
- Sorumlu atandıRota bir sürücüye ve araca bağlandı; görev, onun yarınki listesinde belirdi
- Yük alındıSürücü depoda alımı işaretledi, sistem çıkış zamanını yazdı ve talebi harekete geçirdi
- Teslim edildiAlıcı yükü teslim aldı, onay talebe eklendi, teslim alma zamanı kayda geçti
- KapatıldıBelgeler teslim edildi, sapma yok; talep geçmişe gider ve dönem raporuna girer
Sistem ekran görüntüsü, veriler örnektir. Beşinci adım önemlidir: alım işaretini yükü fiilen alan kişi koyar. Bunu dispeçer «telefon üzerine» koyarsa sistem taşımayı değil, taşımaya dair anlatıyı betimlemeye başlar.
Atanmış talebin düzeltilmesi
Düzeltme serbest bir düzenleme değil, yönetilen bir işlemdir. Adresin, sürenin ya da yük içeriğinin değişmesi önceki sürümü saklar ve iz bırakır: kim değiştirdi, ne zaman ve tam olarak neyi. Aksi halde tartışmalı teslimatın incelenmesi «peki başlangıçtaki adres neydi» sorusuna takılır.
Rota yönetimi
noktalar, sıra ve sorumlular
Rota — bir sorumlunun bir vardiyada gezdiği nokta listesi ve geziş sırası. Nokta, bir adreste yapılacak somut işlemdir: yükü al, yükü teslim et, iadeyi al.
Rota oluşturma seçilen tarihteki dağıtılmamış taleplerle başlar. Dispeçer onları liste halinde görür: adres, bölge, alıcıdaki aralık, ağırlık ve hacim. Noktalar elle ya da bir kuralla — örneğin «bu bölgenin yarınki tüm teslimatları» — rotaya toplanır ve rota hemen toplam ağırlığı, hacmi ve durak sayısını gösterir.
Durakların sırası açıkça belirlenir ve herkese görünür kalır: panelde dispeçere, uygulamada sürücüye. Sıra noktanın sürüklenmesiyle değişir; sistem bu sırada rotanın yükünü yeniden hesaplar ve çakışmayı bildirir — örneğin «12:00'a kadar» aralıklı bir nokta sekizinci sıraya düştüğünde.
Sorumlu ataması — rotanın bir sürücüye ya da kuryeye ve bir araca bağlanmasıdır. Sistem taşıma kapasitesini ve kasa hacmini gözetir: atanan araca sığmayan rota, yükleme sırasında keşfedilmez, yola çıkmadan işaretlenir.
Rotanın değiştirilmesi gün içinde olur ve bu bir arıza değil olağan bir senaryodur. Nokta eklenebilir, çıkarılabilir, başka bir rotaya ya da başka bir güne aktarılabilir. Sorumlu değişikliği kendi listesinde görür, rotanın geçmişinde ise bir kayıt kalır: ne değişti, kim değiştirdi ve saat kaçta.
Yürütmenin denetimi — planla fiilinin karşılaştırılması: rotanın kaç noktası kapandı, kaçı kaldı, sorumlu geziş sırasından nerede saptı, hangi noktalar aralığa göre gecikti. Rota, tüm noktaları kapandığında kapanır — başarısız teslimatla biten noktalar dahil.
Geziş sırasının otomatik seçimi
En uygun rotanın otomatik kurulması, muhasebe sisteminin yerleşik işlevi değil ayrı bir modüldür. Bunu bir uygulama seçeneği olarak değerlendirmek anlamlıdır: yol verisi kaynağı, hesaplama kuralları ve şirketin gerçek seferlerinde doğrulama gerektirir.
Olası seçenekler — noktaların bölgelere ve zaman aralıklarına göre basitçe sıralanmasından dış bir harita servisiyle hesaplamaya kadar. Neyin bağlanacağı ve hangi verilerle hesaplanacağı incelemede belirlenir: hazır bir optimizasyonu önceden ilan etmek bir betimleme değil, bir vaat olurdu.
Temel çevre onsuz da çalışır: noktalar, sıra, sorumlu ve yürütmenin denetimi, durakları insanın mı algoritmanın mı dizdiğine bağlı değildir.
Muhasebe nesnesi olarak rota
Rotanın da talep gibi bir tarihi, sorumlusu, aracı, durumu ve değişiklik geçmişi vardır. Bu yüzden «bu adres dün neden bugüne kaldı» sorusu vardiyanın hatırasına göre değil, rotanın kaydına göre incelenir.
| № | Nokta | Eylem | Aralık | Kap | Ağırlık | Durum |
|---|---|---|---|---|---|---|
| 1 | Depo, Promışlennaya sok. | Yük alımı | 08:00–09:00 | 14 | 310 kg | tamamlandı |
| 2 | «Merkez» mağazası | Teslimat | 09:00–12:00 | 4 | 86 kg | tamamlandı |
| 3 | Müşteri ofisi, 4. kat | Teslimat | 10:00–13:00 | 2 | 18 kg | yolda |
| 4 | Teslim noktası, Asanbay mah. | Teslimat | 18:00'e kadar | 6 | 142 kg | bekliyor |
| 5 | «Doğu» mağazası | Teslimat + iade | 14:00–17:00 | 2 | 64 kg | bekliyor |
Geziş sırasını hem dispeçer hem sürücü görür, bu yüzden «yer değiştirdiler» bir tartışmaya dönüşmez. 3. satır, sorumlu sonucu işaretlemeden kapanmaz: kata çıkarma, teslimatın geciktiği tipik yerdir ve sistem bunu kapıda duran kişiden öğrenmelidir.
Yük yönetimi
neyi, nereden, nereye taşıyoruz ve kim sorumlu
Yük — fiziksel olarak yer değiştiren şeydir. Sistemde talebe bağlı ayrı bir kayıttır: tek talep birkaç yük kabı taşıyabilir, tek sefer ise birkaç talebin yüklerini.
Bu ayrım muhasebe titizliği için değildir. En sık sorulan sorular tam da yük düzeyinde yanıtlanır: kaç kap yola çıktı, hepsi vardı mı, hangisi hasarlı, ne geri döndü.
Yükün durumundaki her değişiklik, zamanı ve yazarı olan bir olaydır. Bu yüzden taşımanın geçmişi bütünüyle geri getirilir: yük saat kaçta alındı, sorumlular arasında nerede devredildi, alıcıya ne zaman teslim edildi ve bunu kim onayladı.
Sorumlular arasında devir — bir yan etki değil, ayrı bir işlemdir. Depodan ayrıştırmaya, oradan adrese giden yük sorumlusunu en az iki kez değiştirir. Her devir açıkça kayda geçer, aksi halde kayıp durumunda yükün kaybolduğu bölüm söylenemez.
«Kim suçlu» sorusunun yanıtı da buradan gelir — suçlu arama anlamında değil, bölüm anlamında. Alıcının bulduğu hasar, yükün belirli bir sorumlunun üstünde göründüğü yol parçasına bağlanır.
İlişkili belgeler
İrsaliye, teslim tutanağı, ambalaj fotoğrafı, alıcının imzası yükün yanında yaşar. Belge hem yüke hem talebe bağlıdır, bu yüzden hem müşteriden hem seferden bulunur — yazışmada aramaya gerek yoktur.
Alımda ve teslimde fotoğraf, hasar tartışmasını kapatmanın en ucuz yoludur: bilinen bir anda bilinen bir kişi tarafından çekilmiştir ve alıcının imzasıyla aynı kartta durur.
Yük ve talep ayrı kayıtlardır
Tek talep birkaç kap taşıyabilir, tek sefer birkaç talebin yükünü. Bu tek bir kayıt olduğu sürece her kısmi durum — beş kaptan üçü alındı, biri iade edildi — açıklamada sözcüklerle anlatılmak zorunda kalır.
- Ne taşınıyorzorunluAd, kap sayısı, ağırlık, hacim, ambalaj tipi, özel koşullar — kırılabilir, sıcaklık rejimi, iki kişi gerekiyor
- NeredenzorunluAlım adresi, çıkış deposu ya da sahası, göndericinin ilgili kişisi
- NereyezorunluTeslimat adresi, alıcı, kabul aralığı, giriş ve kata çıkarmaya dair not
- Kimin sorumlu olduğunuzorunluGüncel sorumlu: sürücü, kurye, depo ya da ayrıştırma sahası — devir geçmişiyle
- Güncel durumişlemde değişirTeslimat çevresinin durumlarından biri; alanın elle düzeltilmesiyle değil, sorumlunun işlemiyle değişir
- Çıkış zamanıolguyla kayda geçerYükün sorumlu tarafından alındığı ve çıkış noktasından fiilen ayrıldığı an
- Teslim alma zamanıolguyla kayda geçerAlıcıya teslim anı ve onay yöntemiyle birlikte
- Belgeler ve bağlargerektiğindeİrsaliye, tutanak, fotoğraflar, imza, talep numarası, dış sistemdeki sipariş numarası
Zorunlu alanlar, yükün rotaya konabilmesi için gereken en azdır. Gerisi ayarlanır: mobilya taşımasıyla belge teslimatının önemli alan kümesi farklıdır ve gereksizini doldurtmak, çizgilerle dolu bir katalog elde etmenin kesin yoludur.
Teslimat denetimi: durumlar ve istisnalar
Durum, ekrandaki bir etiket değil, izin verilen işlemlerin kendisinden türediği bir hâldir. Durum kümesi sonludur: açıkça adlandırılmadığı sürece her çalışan «işlemde»yi kendince anlar ve rapor derlenecek bir şey kalmaz.
- OluşturulduTalep alındı ve denetlendi. Yük henüz toplanmadı, sorumlu atanmadı, ama müşteriye karşı yükümlülük çoktan sabitlendi
- HazırlandıYük toplandı ve tamamlandı, kaplar etiketlendi, belgeler hazır. Bu andan sonra yük içeriği ayrı bir işlem olmadan değişmez
- Teslimata verildiYük sorumlu tarafından fiilen teslim alındı: işareti onu alan koyar. Sorumluluk depodan sorumluya geçer
- YoldaSorumlu rotada ilerliyor. Burada ara olaylar belirir: noktaya vardı, boşaltmaya başladı, bir önceki adreste gecikti
- Teslim edildiAlıcı yükü teslim aldı, onay teslimata eklendi. Teslimat ancak şimdi yerine getirilmiş sayılır — adresten ayrılma anında değil
Sıra tam olarak bu biçimde önemlidir. Her geçişi, işlemi yapan kişi ve işlem anında yapar — aksi halde sistem taşımanın durumunu değil dispeçerin niyetini gösterir. Ara durumlar («ayrıştırmada», «yükleniciye devredildi») şirketin sürecine göre eklenir, ama küme sonlu ve açık kalır.
| Ne oldu | Sistem ne yapar | Durum |
|---|---|---|
| Gecikme: alıcıdaki aralık doluyor | Noktayı gecikmiş diye işaretler, dispeçere ayrı bir listede gösterir, alıcıya erteleme bildirimi hazırlar | inceleme |
| Müşteri siparişi sevkiyattan önce iptal etti | Talebi iptal nedeniyle kapatır, noktayı rotadan çıkarır ve yükü depo stokuna döndürür | olağan |
| Müşteri, yük yoldayken siparişi iptal etti | Teslimatı sessizce kapatmaz: onu iadeye çevirir ve sorumlunun rotasına ters bir nokta koyar | inceleme |
| Alıcı yerinde değil | Başarısız teslimatı nedeni ve sorumlunun notuyla kayda alır, yükü onun üstünde bırakır ve yeniden deneme sorusunu gündeme getirir | inceleme |
| Alıcı yükü kısmen teslim aldı | Teslimatı böler: alınan kaplar kapanır, reddedilenler ayrı bir kayıtla iadeye gider | inceleme |
| Yük taşıma sırasında hasar gördü | Fotoğraflarla ve hasar anındaki sorumluyla bir olay açar, teslimatın olağan biçimde kapatılmasına izin vermez | inceleme |
| Sorumlu vardiyaya gelmedi | Rotasını yeniden atama için serbest bırakır ve etkilenen tüm noktaları dispeçere tek listede gösterir | uyarı |
Genel ilke: başarısız sonuç kaybolmaz ve başarıya dönüşmez. Teslimat açık kalır ve inceleme kuyruğuna düşer — bu, sorunların yazılacak yeri olmadığı için görünmediği bir rapordan ucuzdur.
Şirkete tam olarak hangi istisnaların gerektiği incelemede kararlaştırılır. Mobilya taşımasına iade ve hasar incelemesi, belge teslimatına yeniden deneme ve alıcının kimlik doğrulaması gerekir. Durum kümesi ayarlanır ama kural ortak kalır: teslimatın her bitişinin bir nedeni vardır ve neden rapora girer.
Dispeçer paneli
dispeçer ve yönetici ne görür
Dispeçer paneli — günün yönetildiği çalışma alanıdır. Görevi «veri göstermek» değil, şu anda karar gerektiren her şeyi tek ekranda toplamak ve gerisini göstermemektir.
Bu yüzden panel vardiyanın masası gibi kurgulanmıştır: üstte yanan işler, altta günün genel tablosu, derinde geçmiş ve kataloglar. Çalışanın, müşterinin telefonuna yanıt vermek için neyin nerede olduğunu hatırlaması gerekmez.
Panelde neler görünür:
- Etkin teslimatlar — şu anda işlemde olan tüm noktalar, sorumlusu ve güncel durumuyla
- Günün rotaları — kaç nokta kapandı, kaçı kaldı, rota nerede plandan geri kaldı
- Sorumlular — kim vardiyada, kim rotada, kim boşaldı, kimin mesaisi bitiyor
- Durumlar — teslimatların durumlara göre dağılımı tek listede, elle sayılmadan
- Gecikmeler — alıcıdaki aralığı dolan ya da çoktan dolmuş noktalar
- Sorunlu siparişler — başarısız teslimatlar, iadeler, hasarlar, alıcı retleri
- Doluluk — araca ne kadar ağırlık ve hacim atandı ve ne kadar boş yer kaldı
- Dağıtılmamışlar — henüz hiçbir rotaya girmemiş talepler
- İşlem geçmişi — herhangi bir talep, rota ya da yükle ne olduğu; yazarı ve zamanıyla
Erişim yetkileri paneli rollere göre ayırır. Dispeçer kendi bölgesini, yönetici tüm yönleri, çağrı merkezi operatörü ise durumları ve iletişim bilgilerini görür, finansal verileri değil.
Ayrım, her çalışanda bir onay kutusu kümesiyle değil rolle belirlenir. Aksi halde altı ay sonra yeni gelenin yetkileri «Ivanov'daki gibi» ayarlanır ve ona tam olarak neyin açık olduğunu artık kimse söyleyemez.
Vardiya özeti
118teslimat işlemde
9nokta gecikme riskiyle
4sorunlu sipariş
12talep dağıtılmadı
Sistem ekran görüntüsü, sayılar örnektir. Kutucukların sırası rastgele seçilmemiştir: önce toplam hacim değil, karar gerektiren şey gelir. Dağıtılmamış talepler sonda durur, çünkü dispeçerin kendi başına ve sonuna kadar kapattığı tek kutucuk odur.
İşlem geçmişi
Geçmiş «ne olur ne olmaz» diye tutulan bir arşiv değil, inceleme aracıdır. Kayıtlar düzenlenmez: düzeltme yeni bir kayıtla yapılır. Bu yüzden «teslimatı yarına kim erteledi» sorusunun sürümleri değil, yanıtı vardır.
Genellikle üç uçtan birinden bakılır: talepten — başına ne geldiği, sorumludan — vardiyada ne yaptığı, rotadan — gün içinde nasıl değiştiği.
Depoyla bağlantı
toplamadan teslimata devretmeye kadar
Depo ve lojistik, ortak sohbeti olan iki bölüm değil, tek sürecin iki parçasıdır. «Toplandı ama devredilmedi» yük ile «devredildi ama işaretlenmedi» yük iki farklı durumdur ve bunları karıştırmak pahalıya patlar.
Tek bir dijital süreç şu demektir: depo ile teslimat arasındaki her geçiş bir mesajla değil bir işlemle kayda geçer. Depo görevlisi toplamayı, sürücü yükün alınmasını, alıcı teslim almayı işaretler. Bu işaretler arasında yük her zaman belirli bir parçanın üstünde görünür.
Bu birleşme depoya ne verir: neyin çoktan yola çıktığını, neyin ikinci gündür sevkiyat alanında durduğunu görür. Lojistiğe ne verir: rota henüz toplanmamış yük için planlanmaz ve sürücü, yüklenecek bir şey olmadan kapıya gelmez.
Tam depo kaydı — mal kabul, yerleştirme, sayım, partiler ve son kullanma tarihleri — ayrı bir sayfanın konusudur. Burada yalnızca birleşme noktası anlatılıyor: deponun lojistiğe ne verdiği ve karşılığında ne aldığı.
- 1Sipariş
- 2Toplama
- 3Hazırlık
- 4Devir
- 5Teslimat
- 6Onay
Dördüncü geçiş, yükün sorumlusunun değiştiği tek geçiştir. Tam da bu yüzden iki taraflı ayrı bir işlem olarak yapılır: depo teslim etti, sorumlu aldı. Bu adım atlanırsa kap kaybolduğunda hangi parçada olduğu söylenemez ve inceleme vardiyayı sorgulamaya dönüşür.
Depo ile lojistik arasında ne aktarılır
- Depodan lojistiğe — toplanan siparişin içeriği, kap sayısı, ağırlık ve hacim, sevkiyata hazır olma, etiket numaraları
- Lojistikten depoya — aracın planlanan geliş saati, yükü kimin alacağı, hangi rotaya gireceği
- Depoya geri — iadeler, reddedilen kaplar ve teslim edilemeyen yükler; geri dönme nedenleriyle
- İkisi için ortak — kabın hareket geçmişi: nerede olduğu, kimin teslim aldığı ve sorumlunun ne zaman değiştiği
Depo başka bir programda çalışıyorsa
Bu olağan bir durumdur: depo kaydı zaten mevcut bir sistemde tutulur, kimse onu değiştirmeyi düşünmez. O zaman birleşme veri alışverişiyle kurulur — lojistik siparişlerin hazır olduğunu ve kap içeriğini alır, karşılığında durumları ve onayları döndürür.
Alışverişin içeriği ve sıklığı, dış sistemin neyi verebildiğine göre belirlenir. Belirli bir programın imkânları incelemede netleştirilir — hazır bir entegrasyonu önceden ilan etmek, başkasının ürünü adına söz vermek olurdu.
Talepler ve rotalar
Yükler ve durumlar
Dispeçer paneli
Teslimat raporlaması
Çalışanlar sistemle nasıl çalışır
Her rolün kendi çalışma alanı ve kendi işlem kümesi vardır. Bu, sınırlama olsun diye konmuş bir sınırlama değildir: ekranda ne kadar az gereksiz şey olursa vardiyada o kadar az hata olur ve yeni gelenin eğitimi o kadar kısalır.
Talep operatörü
Talepleri tüm kanallardan alır, adresleri ve yük içeriğini denetler, tartışmalı olanı müşteriyle netleştirir. Netleştirme kuyruğunu ve kendi taleplerini görür; rotalara ve araç doluluğuna dokunmaz.
Dispeçer
Rotaları kurar, sorumluları atar, günü yürütür: noktaları aktarır, gecikmelere tepki verir, sorunlu teslimatları inceler. Panelin başlıca kullanıcısı ve gün içindeki değişikliklerin ana kaynağıdır.
Depo görevlisi
Toplamayı ve sevkiyata hazır olmayı işaretler, yükün sorumluya devrini ve iadelerin kabulünü yapar. Rotalarla değil, kaplar ve etiketlerle çalışır.
Sürücü
Vardiya rotasını alır, alımı ve teslimatı işaretler, nokta kapanmadıysa nedenini kayda geçirir. Yalnızca o güne ait kendi görevlerini ve onları yerine getirmek için gereken verileri görür.
Kurye
Aynı senaryo, ama mobil arayüzde ve vardiyada daha çok sayıda kısa noktayla. Teslim almayı onaylar, fotoğraf ya da imza ekler, adrese dair not yazar.
Yönetici
Vardiyaya değil döneme bakar: teslimat hacmi, süresinde tamamlananların oranı, doluluk, yinelenen aksamaların listesi. Operasyonel işlemlere değil, dayanabileceği sayılara ihtiyacı vardır.
Kuryeler ve sürücüler
sorumlunun çalışma arayüzü
Sorumluya «sisteme erişim» değil, şimdi ne yapacağının kısa bir listesi gerekir. Bu yüzden onun çalışma alanı ayrı bir arayüzdür: mobil uygulama ya da uyarlanmış bir web sayfası; dispeçerdeki panelin aynısı değil.
İçinde neler var:
- Vardiya görevlerinin geziş sırasına göre listesi
- Giriş, kat ve kapıya dair notlarla adresler
- Sipariş bilgisi: ne taşınıyor, kaç kap, alıcı kim, teslimde ödeme var mı
- Tek işlemle durum değişimi: vardım, aldım, teslim ettim
- Çıkış noktasında yükün alındığının onayı
- Teslim onayı: imza, fotoğraf ya da alıcıdan kod
- Bir şey plana göre gitmediğinde noktaya not
- Görev kartından dispeçerle iletişim, telefonda numara aramadan
Böyle bir arayüzden beklenen önemli bir şey de kötü bağlantıda çalışmaktır. Ağ dışında yapılan işaretler cihazda saklanır ve bağlantı geldiğinde gönderilir; yeniden gönderim ikinci bir teslimat oluşturmaz.
Sorumlunun işinin ayrıntılı incelemesi «Kuryeler için» sayfasının konusudur. Burada başka bir şey önemlidir: bu arayüzdeki işaretler, fiili durumların tek kaynağıdır; bu yüzden en son değil en önce tasarlanır.
Yerinde işaret şirkete ne kazandırır
Sorumlunun işlem anındaki işareti, denetim olsun diye yapılan bir denetim değildir. Fiili teslim zamanı, noktada geçen süre ve aksamanın nedeni ondan çıkar. Onsuz bu üç gösterge gün sonunda hatıradan geri getirilir, yani getirilemez.
İkinci etki dispeçerin üzerinden kalkan yüktür: durumları telefondaki sözlere göre o yürüttüğü sürece vardiyanın yarısı başkasının işini sisteme geçirmeye gider.
Bu neden ayrı bir arayüzdür
Sorumlunun çalışma koşulları farklıdır: bir elde telefon, diğerinde koli, ekranda güneş, bağlantı bir var bir yok. Dispeçer paneli bu koşullarda kullanılmaz — büyük öğeler, en az sayıda alan ve ağsız anlaşılır davranış gerekir.
Bu yüzden onun çalışma alanı verinin bütünlüğüne göre değil vardiyaya göre tasarlanır: ekranda yalnızca güncel nokta ve bir sonraki bulunur, gerisi derine alınır.
Analitik
hangi veriler ölçülebilir
Raporlar yalnızca verinin sisteme işlem anında girdiği yerde anlamlıdır. Durumlar akşam «gün sonu değerlendirmesiyle» işaretleniyorsa her rapor, olup bitenle ilgisi olmayan düzgün bir tablo gösterir.
Birikmiş verilere göre neler hesaplanır:
- Teslimat sayısı — gün, hafta, ay bazında; yönlere, müşterilere ve sorumlulara göre
- Tamamlanan ve sorunlu siparişler — süresinde teslim edilenlerin oranı ve başka türlü biten teslimatların nedenleriyle listesi
- Teslim süreleri — talepten teslime ve teslimata devirden teslim almaya kadar geçen fiili süre
- Doluluk — araca ve sorumluya kaç nokta, ağırlık ve hacim düşüyor, ne kadar boş yer kalıyor
- Rotaların verimliliği — vardiyadaki nokta sayısı, plana göre kapananların oranı, duraklar arası süre
- İşlem geçmişi — yalnızca özet sayılar için değil, somut bir vakanın incelenmesi için de kaynak
Gösterge tanımları bir kez belirlenir ve tüm raporlarca kullanılır. «Süresinde teslim edildi» ifadesi dispeçerin raporunda ve yöneticinin raporunda aynı şeyi anlatmalıdır — aksi halde tek güne ait iki özet tutmaz ve ikisi de güven vermez olur.
Raporlar dosya olarak aktarılır, programa göre oluşturulur ve API üzerinden dış bir analitik sistemine gidebilir — aktarımın kapsamı projeyle belirlenir.
Haftalık özet
612teslimat dönemde
27tamamlandı olağan dışı
Sistem ekran görüntüsü, sayılar örnektir. İkinci kutucuk birincisinden önemlidir: olağan dışı bitişlerin içeriği — iptaller, iadeler, başarısız teslimatlar — incelenmedikçe toplam hacim yalnızca doluluğu anlatır, işin kalitesini değil.
Entegrasyonlar ve veri alışverişi
Lojistik sistemi nadiren tek başına durur: siparişler bir programdan gelir, müşteriler ikincisinde tutulur, stoklar üçüncüsünde. Aşağıda alışverişin en sık kurulduğu yönler yer alıyor. Entegrasyonun kesin kapsamı, dış sistemin neyi verebildiğiyle belirlenir ve incelemede netleştirilir.
Çevrimiçi mağaza
Oluşturulan sipariş lojistiğe otomatik olarak talep biçiminde aktarılabilir, teslimat durumu ise alıcıya kendi hesabına dönebilir. Vitrinin kendisinin ve sipariş kaydının nasıl kurgulandığı şu sayfada anlatılmıştır: e-ticaret.
CRM
Müşteri kataloğu ve fırsat geçmişiyle entegrasyon mümkündür: talep müşteri kartından oluşturulur, teslimatın sonucu ise temsilciye döner. Karşı tarafların yinelenmemesi için alışveriş müşteri kimliğiyle yürür.
ERP ve muhasebe sistemi
Şirketin muhasebe çevresiyle birlikte çalışabilir: siparişler, irsaliyeler, karşılıklı hesaplar. Alışverişin yönü ve belge kümesi, hangi muhasebenin esas kabul edildiğine göre belirlenir.
Depo sistemi
Siparişlerin hazır olması, kap içeriği ve etiketleme depodan gelir; durumlar ve iadeler geri gider. Depo dış bir programda tutuluyorsa birleşme veri alışverişiyle kurulur — yukarıdaki depoyla bağlantı bölümüne bakınız.
Kuryeler için program
Sorumlunun çalışma alanı sistemin bir parçası olabilir ya da API üzerinden bağlı ayrı bir uygulama: görevleri alır, durumları ve onayları döndürür. İkinci seçenek, uygulamanın zaten kullanıldığı yerde gerekir.
Ödeme sistemleri
Teslimde ödeme olan yerde, ödeme servisiyle ya da sorumlunun terminaliyle entegrasyon mümkündür: ödenecek tutar talepten gelir, ödemenin sonucu teslimata döner. Kapsam sağlayıcıya bağlıdır.
Dış servisler
Haritalar ve adreslerin coğrafi kodlanması, araç telemetrisi, bildirim servisleri, yüklenici taşıyıcılar. Böyle her bağlantı ayrı bir alışveriş modülüdür; hazır bir bağlayıcının varlığı önceden ilan edilmez.
API
Sistemin kendi arayüzü: talep oluştur, durumu ve rotayı al, teslim onayını ilet, işlem günlüğünü çek. Ayrı modülü olmayan her şey bunun üzerinden bağlanır.
Alışverişin kuralları her yerde aynıdır: her işlemin bir anahtarı vardır, bu yüzden yeniden aktarım ikinci bir talep oluşturmaz; sapmalar kaybolmaz, inceleme kuyruğuna düşer; her gönderim ve her yanıt alışveriş günlüğüne yazılır. Bu üç kural olmadan entegrasyon tam olarak ilk bağlantı kopmasına kadar çalışır.
Devreye alma sırası
Lojistik tek günde bütünüyle sisteme taşınmaz: çalışanlar durumları eski usulle yürüttüğü sürece raporlardaki veriler hiçbir şey ifade etmez. Bu yüzden devreye alma parça parça gider ve her sonraki parça, çalışan bir öncekine dayanır.
1. İnceleme
Talepler şu anda nasıl geliyor, rotaları kim planlıyor, durumlar neyle yürütülüyor, hangi programlar kurulu ve neyi verebiliyorlar. Sonuç — sürecin betimlenmesi ve önce neyin otomatikleştirileceğinin listesi.
2. Tek yönde pilot
Bir şehir, bir teslimat servisi ya da bir depo. Talepler, rotalar, durumlar ve sorumluların işaretleri, süreç tüm şirketi kapsamadan önce gerçek taşımalarda tam bir tur atar.
3. Roller ve kurallar
Kim neyi değiştirebilir, hangi istisnalar gerekir, iade ve başarısız teslimat nasıl işlenir, bildirimler kime gider. Yetkiler ve rotanın elle değiştirilme düzeni de burada ayarlanır.
4. Yaygınlaştırma ve veri alışverişi
Kalan yönler denenmiş şemaya göre, entegrasyonlar ise ayrı alışveriş modülleriyle. Sonrasında geçmiş birikir, dönemsel raporlar ve araç planlaması için veriler ortaya çıkar.
Müşteri referanslarımız
Lojistiğinizi konuşalım
Hemen bizimle iletişime geçin
Günde kaç teslimat olduğunu, taleplerin nereden geldiğini, kendi aracınız mı yükleniciler mi olduğunu, deponuz var mı ve verilerinizin hangi programlarda durduğunu yazın. Önce neyin otomatikleştirileceğini, mevcut sistemlere neyin bağlanabileceğini ve pilota nereden başlamanın makul olduğunu söyleyelim.
