Logistika şirkətində «sifariş» tək bir kartdan daha geniş əməliyyatı ifadə edə bilər. Müştərinin tələbi, yükün xüsusiyyətləri, götürülmə və təhvil ünvanları, marşrut, daşıyıcı və sənədlər bir-biri ilə əlaqəlidir. CRM və əməliyyat sistemi hazırlanarkən əvvəl bu əlaqələr müəyyən edilməlidir. Əks halda status dəyişir, amma real işin hansı hissəsinin tamamlandığı görünmür.
Logistika CRM sistemi bütün şirkətlər üçün eyni məhsul deyil. Şəhərdaxili yükdaşıma, beynəlxalq ekspeditorluq və avtopark idarəetməsi fərqli başlanğıc məlumatı və qərar nöqtələri tələb edir. CRM-in ümumi təyinatını başa düşdükdən sonra sahə axınını ayrıca yazmaq lazımdır.
Müraciətlə təsdiqlənmiş sifarişi ayırın
İlkin müraciətdə yükün hər detalı məlum olmaya bilər. Müştəri yalnız marşrut və təxmini həcm deyə bilər. Təsdiqlənmiş sifarişdə isə razılaşdırılmış xidmət, əlaqə şəxsləri, tarixlər və məsuliyyət müəyyənləşməlidir. Bu iki mərhələdə eyni məcburi sahələri tələb etmək ilkin işi ağırlaşdıra bilər.
İzahlı nümunə: şirkət A nöqtəsindən B nöqtəsinə daşıma üçün sorğu alır. Bu, real əməliyyat və ya müəyyən xidmət vədi deyil. Əvvəl tələb qeydə alınır, sonra nəqliyyat və şərtlər dəqiqləşir, bundan sonra sifariş icraya ötürülür. Hər keçidin şərti proqramda aydın olmalıdır.
Yük, ünvan və əlaqəli tərəflər
Bir sifarişdə bir neçə yük vahidi və ya dayanacaq ola bilər. Ünvan tək mətn kimi saxlanıldıqda əlaqə şəxsi, giriş qeydi və vaxt aralığı qarışa bilər. Hansı məlumatın ayrıca sahə, hansının qeyd olacağını real işə baxaraq seçmək lazımdır.
- Göndərən və qəbul edən tərəfin əlaqəsi.
- Yükün təsviri və razılaşdırılmış ölçü məlumatları.
- Götürülmə və təhvil nöqtələri.
- Daşınma üzrə məsul əməkdaş və tərəfdaş.
- Əlaqəli sənədlər və əməliyyat qeydləri.
Məxfi və lazımsız məlumatı bütün rollara açmaq doğru deyil. Müştəri ilə işləyən komanda, sürücü və maliyyə tərəfinin ehtiyacları fərqli ola bilər. Bu ayrılma rol və səlahiyyət matrisində göstərilməlidir.
Status real hadisəni ifadə etməlidir
«Yoldadır» statusu avtomobilin çıxması, yükün qəbul edilməsi və ya sürücünün telefonla məlumat verməsi mənasına gələ bilər. Bir sistemdə bu məna dəqiq olmalıdır. Statusun mənbəyi də görünməlidir: əməkdaş daxil edib, inteqrasiya göndərib və ya sənəd təsdiqlənib?
Planlaşdırılan tarixlə faktiki hadisə vaxtını ayırmaq faydalıdır. Gecikmə hesabatı üçün hansı müqayisənin aparıldığı məlum olmalıdır. Statusun səhv seçilməsi və geri qaytarılması qaydası da yazılmalıdır; tarixçəni silərək düzəliş etmək sonrakı araşdırmanı çətinləşdirir.
Marşrut, avtopark və yanacaq əhatəsi
Bəzi şirkətlərə öz nəqliyyat vasitələri üzrə uçot, digərlərinə yalnız daşıyıcı tərəfdaşın təyinatı lazımdır. Marşrut planlaması və yanacaq qeydi ayrıca modullar ola bilər. Onların yalnız adını yazmaq tələbi tamamlamır: hansı məlumatdan hansı hesabat alınacağı göstərilməlidir.
Logistex layihəsi CV-də sifariş, marşrut, maliyyə və yanacaq uçotu istiqamətləri ilə təsvir olunur. 166 Cargo isə sifariş, qiymətləndirmə, status və sənəd əməliyyatları ilə qeyd olunub. Bu nümunələr sahənin müxtəlif əhatələrini göstərir, hər logistika layihəsinə eyni modul və nəticə vəd etmir.
İnteqrasiyalar və qeyri-müəyyən cavablar
GPS, mühasibat və digər xarici xidmətlə əlaqə planlaşdırılırsa, məlumatın əsas mənbəyi seçilməlidir. Bağlantı kəsiləndə son mövqe köhnəlmiş ola bilər; onu cari fakt kimi göstərmək istifadəçini çaşdıra bilər. Yenilənmə vaxtı və səhv vəziyyəti interfeysdə anlaşılan olmalıdır.
Təkrar göndərilən əməliyyat eyni sifarişi iki dəfə yaratmamalıdır. Bu məsələ və digər əlaqə sualları API inteqrasiyası hazırlanarkən ayrıca nəzərdən keçirilir.
Qəbul yoxlaması üçün ssenarilər
- Natamam ilkin sorğu və sonradan təsdiqlənən sifariş.
- Birdən çox dayanacaqlı daşınma.
- İcra zamanı məsul şəxs və ya nəqliyyat dəyişikliyi.
- Sənəd əlavə edilməsi və yanlış faylın düzəldilməsi.
- İnteqrasiya cavabı gəlmədən əvvəl təkrar sorğu.
- Ləğv olunan sifarişin hesabatdakı vəziyyəti.
Nümunə: gecikmiş status məlumatı
Əməkdaş telefonla yükün təhvil verildiyini öyrənib, inteqrasiyadan isə əvvəlki «yoldadır» məlumatı sonradan gəldiyini düşünün. Bu şərti ssenaridə son gələn cavab həmişə son baş vermiş hadisə deyil. Məlumatın alınma vaxtı ilə hadisənin vaxtı ayrılmalıdır.
Hansı mənbəyə üstünlük veriləcəyi və ziddiyyətin necə göstəriləcəyi əvvəl müəyyən olunur. Tarixçəni səssizcə dəyişmək əvəzinə məsul şəxsə aydın yoxlama yolu vermək lazım ola bilər. Bu davranış sənəd təsdiqi, sürücü məlumatı və tərəfdaş cavabı arasında da fərqlənə bilər.
- Hadisə və qəbul vaxtını ayrı yoxlayın.
- Statusun mənbəyini görünən saxlayın.
- Əl ilə düzəlişin səbəbini qeyd edin.
- Köhnə cavabın tamamlanmış işi geri açmadığını sınayın.
Belə sınaq «inteqrasiya işləyir» ifadəsindən daha dəqiq qəbul meyarıdır. Məqsəd məlumatın sadəcə gəlməsi deyil, əməliyyatın real mənasının qorunmasıdır.
Tez verilən suallar
Müştəri yükü canlı izləyə bilərmi?
Bu ayrıca tələbdir. Məlumat mənbəyi, icazə, yenilənmə tezliyi və köhnəlmiş məlumatın göstərilməsi razılaşdırılmalıdır.
Sadə CRM kifayət edərmi?
Yalnız satış əlaqəsi izlənirsə, bəli. İcra, yük və marşrut əlaqələri artdıqda sahəyə uyğun əməliyyat modeli lazım ola bilər.
Öz nümunə sifarişinizi və istədiyiniz hesabatı hazırlayaraq logistika üçün CRM və ERP hazırlığı üzrə konkret əhatə müəyyən etmək mümkündür.
