निर्माताओं, निर्यातकों और SME के लिए लॉजिस्टिक्स सॉफ़्टवेयर का चुनाव

यह गाइड ट्रांसपोर्ट खरीदने वाले पक्ष के लिए है, ट्रांसपोर्ट मुहैया कराने वाले पक्ष के लिए नहीं। शिपमेंट की ज़रूरत पैदा होने के पल से लेकर फ़्रेट इनवॉइस के मिलान तक, आपका रोज़ का प्रवाह कदम-दर-कदम खोला गया है; हर चरण पर बताया गया है कि सॉफ़्टवेयर से क्या उम्मीद करें और डेमो में उसे कैसे परखें। यह गाइड Logistivo ने तैयार की है; मानदंड किसी एक प्रोडक्ट के इर्द-गिर्द नहीं, बल्कि फ़ील्ड में जो होता है उसके इर्द-गिर्द लिखे गए हैं, और इस तुलना में खुद Logistivo कहाँ खड़ा है, यह उसके अपने सेक्शन में खुलकर बताया गया है। शिपर के लिए लॉजिस्टिक्स सॉफ़्टवेयर का चुनाव एक ही सवाल पर आकर टिकता है: क्या कोटेशन, शिपमेंट, दस्तावेज़ और इनवॉइस एक ही रिकॉर्ड पर हैं, या चार अलग-अलग जगहों पर? मैन्युफ़ैक्चरिंग, निर्यात और ई-कॉमर्स ऑपरेशन में सॉफ़्टवेयर आम तौर पर "मेरा माल कहाँ है" का जवाब पाने के लिए खरीदा जाता है, लेकिन असली नुकसान कोटेशन की तुलना में, दस्तावेज़ों की असंगतियों में और महीने के आखिर में होने वाली फ़्रेट इनवॉइस की जाँच में जमा होता है। इस सेगमेंट का काम माल ढोना नहीं, बल्कि ढुलाई खरीदना है। आपके पास अपने ट्रक नहीं हैं; आपके पास एक लोडिंग तारीख, खरीदार से किया गया एक वादा और गिने-चुने ट्रांसपोर्टर हैं। इसलिए आपको फ़्लीट मैनेजमेंट नहीं, बल्कि बाहरी पक्षों को अपने रिकॉर्ड से जोड़ पाने की क्षमता परखनी चाहिए: जब ट्रांसपोर्टर कोटेशन दे रहा हो तब उसे, जब कस्टम्स ब्रोकर डिक्लेरेशन तैयार कर रहा हो तब उसे, और जब खरीदार स्टेटस पूछ रहा हो तब उसे — क्या आप सबको एक ही स्क्रीन पर ला सकते हैं? नीचे यही प्रवाह कदम-दर-कदम खुलता है: हर चरण पर किस क्षमता की उम्मीद करें और उसके बिना क्या टूटता है। इसके बाद आते हैं डेमो में परखे जा सकने वाले मानदंड, चार तरीकों की ईमानदार तुलना, तैयारी की एक चेकलिस्ट और वे गलतियाँ जो सॉफ़्टवेयर खरीदते समय सबसे ज़्यादा होती हैं।

वर्कफ़्लो के चरण और सॉफ़्टवेयर को क्या करना चाहिए

• शिपमेंट की ज़रूरत सामने आती है: कोई ऑर्डर, प्रोडक्शन बैच या स्टॉक रिलीज़ — सेल्स कोई ऑर्डर फ़ाइनल करता है या प्रोडक्शन एक बैच पूरा करता है; लोडिंग की तारीख, पैकेज संख्या, ग्रॉस और नेट वज़न, माप और Incoterms नियम तय हो जाते हैं। लॉजिस्टिक्स का ज़िम्मेदार व्यक्ति यह जानकारी आम तौर पर ईमेल से या ज़ुबानी पाता है और उसे दोबारा किसी स्प्रेडशीट में टाइप करता है। शिपमेंट रिकॉर्ड को प्रोडक्ट, पैलेट और माप के डेटा के साथ एक ही जगह खोलना, ताकि पैकेज संख्या, वज़न और वॉल्यूम आगे बनने वाले हर दस्तावेज़ में बिल्कुल एक जैसे पहुँचें। वही डेटा तीन जगह हाथ से टाइप होता है। आप 12 पैलेट बताकर कोटेशन माँगते हैं, पैकिंग लिस्ट में 13 लिखा होता है; यह अंतर या तो ट्रांसपोर्टर के इनवॉइस पर सामने आता है या कस्टम्स जाँच में।
• अनुरोध तय करना और उसे अपने ट्रांसपोर्टर पूल के लिए खोलना — कलेक्शन पॉइंट, गंतव्य, वाहन का प्रकार, तारीख और विशेष शर्तें (रीफ़र, ADR, रैंप एक्सेस, लोडिंग स्लॉट) मिलकर एक अनुरोध का रूप लेते हैं, जो उन ट्रांसपोर्टरों को जाता है जिनके साथ आप काम करते हैं। व्यवहार में यह चरण अब भी ज़्यादातर वही ईमेल है जो पाँच कंपनियों को अलग-अलग लिखा जाता है। कई छोटे शिपमेंट वाले ई-कॉमर्स मॉडल में यह चरण और कोटेशन वाला चरण हर शिपमेंट के अलग कोटेशन के बजाय समय-समय पर तय की गई दरों पर चलते हैं, और लोडिंग का कागज़ी काम बस एक कूरियर या पार्सल लेबल होता है। अनुरोध को एक बार दर्ज करके एक साथ कई ट्रांसपोर्टरों को भेजना, और कंपनी-दर-कंपनी चुनना कि उसे कौन देख सकता है, ताकि अनुरोध आपकी जानकारी के बिना किसी सार्वजनिक फ़्रेट बोर्ड पर न पहुँच जाए। अलग-अलग कंपनियों को अलग-अलग जानकारी मिलती है और लौटकर आए कोटेशन की तुलना नहीं हो पाती। अगर अनुरोध आपकी मर्ज़ी के खिलाफ़ खुले बाज़ार में पहुँच जाता है, तो आपका वॉल्यूम, आपका रूट और आपकी कीमत की रेंज ऐसे पक्ष पढ़ लेते हैं जिन्हें आपने कभी चुना ही नहीं।
• कोटेशन जुटाना, उनकी तुलना करना और स्वीकार करना — कोटेशन अलग-अलग रूप में आते हैं: एक प्रति वाहन कुल रकम है, दूसरा प्रति टन या प्रति लोडिंग मीटर (LDM), तीसरा इंतज़ार के समय और कस्टम्स हैंडलिंग को अलग से गिनाता है; खरीद टीम इन सबको हाथ से एक स्प्रेडशीट में कॉपी करती है। कोटेशन को एक साझा ढाँचे में जुटाना और उन्हें आमने-सामने रखना; संशोधित कोटेशन का पुराने की जगह ले लेना; स्वीकृति का पल, स्वीकार करने वाला व्यक्ति और स्वीकार की गई रकम — तीनों का रिकॉर्ड में दर्ज होना। पुरानी और नई कीमतें आपस में गड्डमड्ड हो जाती हैं और याद नहीं रहता कि कौन-सा कोटेशन किस शर्त के साथ आया था। महीने के आखिर में "हमने तो यह तय नहीं किया था" वाली बहस शुरू होती है, और आपके पास कोई लिखित निशान नहीं होता।
• लोडिंग का दिन: वाहन गेट पर, कागज़ात डेस्क पर — वाहन और ड्राइवर का विवरण आता है, ट्रक लोड होता है और एक डिस्पैच दस्तावेज़ जारी होता है (तुर्किये में irsaliye, कानूनन ज़रूरी डिलीवरी नोट); निर्यात के लिए कमर्शियल इनवॉइस और पैकिंग लिस्ट तैयार होती है, और अंतरराष्ट्रीय सड़क ढुलाई में परिवहन अनुबंध (कॉन्ट्रैक्ट ऑफ़ कैरिज) आम तौर पर CMR कंसाइनमेंट नोट से प्रमाणित होता है। इनमें से हर दस्तावेज़ उसी शिपमेंट का डेटा दोहराता है। कमर्शियल इनवॉइस, पैकिंग लिस्ट और ट्रांसपोर्ट दस्तावेज़ को शिपमेंट रिकॉर्ड के एक ही डेटा सेट से तैयार करना, और वज़न, पैकेज संख्या या कोई पक्ष बदलने पर सभी को एक साथ अपडेट करना। जिन दस्तावेज़ों को मंज़ूरी चाहिए — EUR.1, तुर्किये–EU व्यापार में A.TR, सर्टिफ़िकेट ऑफ़ ओरिजिन, कस्टम्स डिक्लेरेशन — उनके मामले में उम्मीद उन्हें बनाने की नहीं, बल्कि उसी डेटा को एक जैसा बनाए रखने और ब्रोकर को पूरा सौंपने की है। दस्तावेज़ों के बीच वज़न या पैकेज संख्या मेल नहीं खाती। लोड कस्टम्स पर रुका रहता है; लेटर ऑफ़ क्रेडिट वाले कारोबार में बैंक दस्तावेज़ों की प्रस्तुति खारिज कर देता है, और सुधार होने तक वाहन इंतज़ार करता है।
• रास्ते में ट्रैकिंग, बॉर्डर और कस्टम्स का चरण — वाहन रवाना होता है; बॉर्डर गेट पर, कस्टम्स कंपाउंड में या पोर्ट पर इंतज़ार शुरू होता है, और ट्रांज़िट मूवमेंट (EU और कॉमन ट्रांज़िट नियमों के तहत T1 डिक्लेरेशन, या TIR कार्नेट) अपने अलग चरण जोड़ सकता है। इस चरण में शिपर के पास जानकारी का अकेला स्रोत आम तौर पर यही होता है कि ट्रांसपोर्टर को फ़ोन करे और जवाब का इंतज़ार करे। शिपमेंट का स्टेटस और लोकेशन सिस्टम में दिखना — सड़क पर ड्राइवर की लोकेशन, समुद्र में कंटेनर और जहाज़ ट्रैकिंग; हर स्टेटस बदलाव का टाइमस्टैम्प के साथ दर्ज होना; कस्टम्स ब्रोकर का उसी शिपमेंट से एक पक्ष के रूप में जुड़ पाना। इंतज़ार रियल टाइम में नहीं दिखता; देरी की खबर ग्राहक तक तभी पहुँचती है जब ग्राहक खुद पूछता है। जब स्टोरेज या डेमरेज का इनवॉइस आता है, तो आप साबित नहीं कर पाते कि समय कहाँ गँवाया गया।
• खरीदार और आंतरिक ग्राहकों को जानकारी देते रहना — खरीदार, सेल्स टीम या प्रोडक्शन प्लानिंग पूछती है कि माल कब पहुँचेगा। जवाब जुटाने के लिए लॉजिस्टिक्स का ज़िम्मेदार व्यक्ति पहले ट्रांसपोर्टर को फ़ोन करता है, फिर जवाब ईमेल से आगे भेजता है; एक ही शिपमेंट पर यह काम कई बार दोहराया जाता है। बाहरी विज़िबिलिटी, जिसे फ़ील्ड-दर-फ़ील्ड तय किया जा सके। या तो किसी को जानकारी नहीं मिलती, या जानकारी शेयर करने पर आपकी दर और आपकी सप्लायर लिस्ट भी खुल जाती है। दोनों महँगे हैं: पहले में भरोसा जाता है, दूसरे में मोलभाव की ताकत।
• डिलीवरी, POD और डिलीवरी के बाद के क्लेम — माल उतारा जाता है और हस्ताक्षर किया हुआ ट्रांसपोर्ट दस्तावेज़ और डिलीवरी का प्रमाण वापस आता है। कभी-कभी नुकसान, कम उतरे पैकेज या देर से डिलीवरी का क्लेम सामने आता है, और पक्ष एक-दूसरे को तारीखें और समय गिनाने लगते हैं। हस्ताक्षर किए गए दस्तावेज़ को शिपमेंट रिकॉर्ड से जोड़ना; हर स्टेटस बदलाव और संदेश को तारीख और समय के साथ उसी रिकॉर्ड पर आर्काइव करना; महीनों बाद भी उसे खोजने लायक बनाए रखना। POD किसी के फ़ोन में पड़ा रह जाता है। छह महीने बाद बीमा कंपनी या ग्राहक उसे माँगता है और वह मिलता नहीं; विवाद किसी निष्पक्ष रिकॉर्ड के बजाय याददाश्त के भरोसे लड़ा जाता है।
• फ़्रेट इनवॉइस का मिलान और लागत दर्ज करना — ट्रांसपोर्टर का इनवॉइस आता है; तय रकम में इंतज़ार का समय, कस्टम्स स्टोरेज, डिलीवरी ऑर्डर शुल्क, टर्मिनल हैंडलिंग या विनिमय दर का अंतर जोड़ा जा चुका हो सकता है। जाँच ज़्यादातर आँख से होती है और बेमेल महीनों बाद पकड़ में आता है। स्वीकार किए गए कोटेशन की रकम को शिपमेंट पर सहेजना और आने वाले इनवॉइस को उसी रिकॉर्ड से जोड़ना, ताकि दोनों को आमने-सामने देखा जा सके; लागत का रूट, अवधि और ट्रांसपोर्टर के हिसाब से जमा होते जाना; डेटा को Excel में एक्सपोर्ट कर पाना। ज़्यादा वसूली चुपचाप चुका दी जाती है। साल के अंत में आप नहीं बता पाते कि किस रूट पर कितना चुकाया या कौन-सा ट्रांसपोर्टर सच में महँगा है, और अगली दर की बातचीत में बिना डेटा के उतरते हैं।

चयन मानदंड

• कोटेशन की बराबरी के आधार पर तुलना — ट्रांसपोर्टर एक ही काम की कीमत अलग-अलग रूप में बताते हैं: एक प्रति वाहन कुल रकम देता है, दूसरा प्रति टन, प्रति घन मीटर या — जैसा ग्रुपेज और LTL में आम है — प्रति लोडिंग मीटर (LDM) के हिसाब से, और तीसरा इंतज़ार के समय और कस्टम्स हैंडलिंग को अलग-अलग गिनाता है। किसी साझा ढाँचे के बिना इन्हें एक कतार में रखें, तो सबसे कम आँकड़ा आम तौर पर सबसे सस्ता ऑफ़र नहीं होता। शिपर के लिए बचत का यही सबसे बड़ा लीवर है। डेमो में एक ही रूट के लिए तीन अलग-अलग रूप में तीन कोटेशन दर्ज करवाएँ — एक प्रति वाहन, एक प्रति टन, एक अतिरिक्त लाइन आइटम के साथ — और सिस्टम से कहें कि वह उन्हें कुल लागत के आधार पर एक ही टेबल में क्रम से रखे।
• अनुरोध कौन देखेगा, यह कंपनी-दर-कंपनी चुनना — आपके रूट, आपका वॉल्यूम और आप जो कीमत चुकाते हैं — यह सब कमर्शियल जानकारी है। अगर कोई अनुरोध किसी सार्वजनिक बोर्ड पर पहुँच जाता है, तो आपके शिपमेंट का पैटर्न आपका खरीदार भी पढ़ सकता है और आपका प्रतिस्पर्धी भी। दूसरी ओर, एक खुला फ़्रेट एक्सचेंज आपको उन ट्रांसपोर्टरों तक पहुँच देता है जिन्हें आप नहीं जानते, और स्पॉट अवधियों में ज़्यादा क्षमता भी; इनमें से क्या ज़्यादा मायने रखता है, यह रूट और काम की तात्कालिकता पर निर्भर करता है। आपको किसी एक छोर की नहीं, बल्कि हर अनुरोध के लिए विज़िबिलिटी तय कर पाने की ज़रूरत है। वेंडर से कहें कि वह किसी ऐसी तीसरी कंपनी के अकाउंट से लाइव स्क्रीन शेयर करे जिसे वह अनुरोध नहीं दिखना चाहिए; अलग से खुद जाँचें कि सिस्टम के खुले अनुरोध किसी सर्च इंजन के ज़रिए मिल जाते हैं या नहीं, और लिखित में लें कि विज़िबिलिटी कौन-सी सेटिंग तय करती है।
• एक ही डेटा सेट से बनने वाले और स्वीकृत सर्टिफ़िकेट से मेल खाने वाले व्यापारिक दस्तावेज़ — कमर्शियल इनवॉइस, पैकिंग लिस्ट और ट्रांसपोर्ट दस्तावेज़ काफ़ी हद तक एक ही जानकारी दोहराते हैं; हाथ से कॉपी करने पर ग्रॉस वज़न एक दस्तावेज़ पर कुछ और, दूसरे पर कुछ और निकलता है, और अंतरराष्ट्रीय सड़क ढुलाई में जब CMR कंसाइनमेंट नोट का डेटा बाकी दस्तावेज़ों से मेल नहीं खाता, तो लोड कस्टम्स पर या बैंक में प्रस्तुति के समय रुक जाता है। EUR.1 और A.TR जैसे मूवमेंट सर्टिफ़िकेट (A.TR तुर्किये–EU कस्टम्स यूनियन के व्यापार में इस्तेमाल होता है), सर्टिफ़िकेट ऑफ़ ओरिजिन और कस्टम्स डिक्लेरेशन ऐसे कागज़ नहीं हैं जिन्हें आप बस प्रिंट कर लें: इन्हें चैंबर ऑफ़ कॉमर्स या कस्टम्स प्राधिकरण प्रमाणित, अनुमोदित या पंजीकृत करता है। सॉफ़्टवेयर से इन्हें पूरा करने की नहीं, बल्कि तैयार किए गए हर दस्तावेज़ में वही डेटा एक जैसा बनाए रखने की उम्मीद रखें। किसी शिपमेंट पर ग्रॉस वज़न और पैकेज संख्या बदलें; देखें कि इनवॉइस, पैकिंग लिस्ट और ट्रांसपोर्ट दस्तावेज़ — तीनों नया मान दिखाते हैं और अपने कुल योग दोबारा गिनते हैं। लिखित में पूछें कि किसी दस्तावेज़ को सुधारकर दोबारा जारी करने पर कोई अतिरिक्त लागत — शुल्क, कोटा या नए सिरे से मंज़ूरी का चरण — लगती है या नहीं।
• तय कीमत का आने वाले फ़्रेट इनवॉइस से मिलान — शिपर का सबसे चुपचाप होने वाला नुकसान वह फ़्रेट इनवॉइस है जो स्वीकार किए गए कोटेशन से अलग होता है। इंतज़ार के समय, स्टोरेज और टर्मिनल की लाइनें जुड़ने के बाद अंतर छोटा दिखता है, लेकिन यह हर शिपमेंट पर दोहराया जाता है। अगर स्वीकार की गई रकम शिपमेंट पर दर्ज नहीं है, तो यह जाँच पूरी तरह एक व्यक्ति की सतर्कता पर टिकी रहती है। जाँचें कि आपने जो कोटेशन स्वीकार किया, उसकी रकम शिपमेंट रिकॉर्ड पर सहेजी जाती है या नहीं, और आने वाला फ़्रेट इनवॉइस उसी रिकॉर्ड से जुड़ता है या नहीं; वेंडर से साफ़-साफ़ पूछें कि अंतर को सिस्टम चिह्नित करता है या तुलना आपको खुद करनी होती है।
• रूट, अवधि और ट्रांसपोर्टर के हिसाब से फ़्रेट लागत का ब्योरा — खरीद की बातचीत डेटा पर चलती है। अगर आप नहीं देख पाते कि इस तिमाही किस रूट पर कितना चुकाया, प्रति वाहन औसत कैसे बदला और कौन-सा ट्रांसपोर्टर किस रूट पर महँगा है, तो आप हर साल वही कीमत नए सिरे से खोजते हैं। सालाना फ़्रेट बजट का भी अकेला असली आधार यही ब्योरा है। पिछले तीन महीनों के शिपमेंट लोड करें और "इस तिमाही इस रूट पर मैंने कुल कितना चुकाया, और प्रति वाहन औसत क्या है?" — इस सवाल का जवाब एक ही स्क्रीन पर पाएँ, फिर वही टेबल Excel में एक्सपोर्ट करें।
• खरीदारों और आंतरिक ग्राहकों के लिए नियंत्रित विज़िबिलिटी — शिपर को जानकारी शेयर करनी पड़ती है, लेकिन वह सब कुछ शेयर नहीं कर सकता। खरीदार को शिपमेंट का स्टेटस दिखाने से फ़ोन का सिलसिला खत्म होता है; पर अगर वही स्क्रीन आपकी फ़्रेट दर, आपकी सप्लायर लिस्ट और आपके दूसरे शिपमेंट भी दिखा दे, तो मोलभाव में आपकी स्थिति खत्म हो जाती है। विज़िबिलिटी फ़ील्ड-दर-फ़ील्ड तय की जा सकनी चाहिए। खरीदार या ऑब्ज़र्वर की भूमिका वाला एक यूज़र बनाएँ और उसी यूज़र के रूप में लॉग इन करें। उसे स्टेटस और अनुमानित आगमन दिखना चाहिए, और फ़्रेट की रकम या मिले हुए कोटेशन नहीं दिखने चाहिए।
• शिपमेंट चलने से पहले शुल्क और व्यापार उपायों की लागत का दिखना — टैरिफ़ का जोखिम किसकी जेब से जाएगा, यह Incoterms नियम पर निर्भर करता है। DDP में गंतव्य देश का एंटी-डंपिंग शुल्क और अतिरिक्त शुल्क सीधे आपकी लागत हैं; FCA, FOB या CIF में बिल खरीदार के पास जाता है, लेकिन किसी उपाय का देर से पता चलने का नतीजा फिर भी ऑर्डर रद्द होना या कीमत पर मोलभाव का दोबारा खुलना ही होता है। आयात में लागत सीधे आप पर आती है। तीनों ही स्थितियों में, जब आप कोई नया प्रोडक्ट या नया बाज़ार खोलते हैं, तो शिपमेंट से पहले बताए गए स्रोत वाले डेटा पर जाँच कर पाना बेहद अहम हो जाता है। उस HS कोड और गंतव्य देश के लिए खोज चलाएँ जो आपके असली शिपमेंट में आते हैं; पूछें कि नतीजा कहाँ से आया और आखिरी बार कब अपडेट हुआ। डिक्लेरेशन तैयार करते समय ऐसी दर पर भरोसा न करें जिसका स्रोत दिखाया न जा सके।
• जब चाहें अपना डेटा निकाल पाना — शिपमेंट हिस्ट्री, कोटेशन आर्काइव और दस्तावेज़ आपका कमर्शियल रिकॉर्ड हैं; सॉफ़्टवेयर बदलने के बाद भी उन्हें बचा रहना चाहिए। एक्सपोर्ट के बिना, साल भर बाद सिस्टम बदलना व्यावहारिक नहीं रहता और आप रिन्यूअल की बातचीत में खाली हाथ उतरते हैं। कुछ दस्तावेज़ों को सालों तक सँभालकर रखना भी पड़ सकता है। ट्रायल के दौरान अपनी पूरी शिपमेंट, कोटेशन और दस्तावेज़ लिस्ट Excel और PDF में डाउनलोड करें, और जाँचें कि दस्तावेज़ एक साथ (बल्क में) निकाले जा सकते हैं। अगर ऐसा न हो सके, तो कॉन्ट्रैक्ट का डेटा-वापसी वाला क्लॉज़ लिखित में माँगें।
• ऐसी प्राइसिंग जो लोगों की गिनती नहीं, शिपमेंट वॉल्यूम मापे — शिपर की तरफ़ प्रति-यूज़र प्राइसिंग उल्टी पड़ती है: जैसे-जैसे खरीद अधिकारी, वेयरहाउस सुपरवाइज़र, अकाउंटेंट और एक्सपोर्ट स्पेशलिस्ट जुड़ते हैं, लागत बढ़ती है और टीम एक ही लॉग इन शेयर करने लगती है। जिस पल अकाउंट शेयर होता है, किसने क्या किया, यह मिट जाता है और सिस्टम जो डेटा देता है वह भरोसे लायक नहीं रहता। दूसरी ओर, छोटी और स्थिर टीम में प्रति-यूज़र मॉडल कुल मिलाकर फिर भी सस्ता पड़ सकता है; तुलना किसी आम नियम से नहीं, अपने यूज़र और शिपमेंट के आँकड़ों से करें। अपने सबसे व्यस्त महीने के असली शिपमेंट और यूज़र आँकड़े दें और बिलिंग का एक सिमुलेशन माँगें; लिखित में लें कि यूज़र की कोई सीमा है या नहीं और सीज़नल पीक पर रकम कैसे बदलती है।

तरीकों की तुलना

• ईमेल से कोटेशन, फ़ोन से फ़ॉलो-अप, फ़ोल्डर में दस्तावेज़ (मैनुअल तालमेल) — ऐसी कंपनियाँ जो एक ही रूट पर दो-तीन ट्रांसपोर्टरों के साथ महीने में गिने-चुने शिपमेंट भेजती हैं, और जहाँ पूरा ऑपरेशन अब भी एक व्यक्ति के दिमाग में समा जाता है। पैसा लाइसेंस में नहीं, समय में जाता है: कोटेशन के पीछे भागने, दस्तावेज़ टाइप करने और स्टेटस पूछने में लगे घंटे। क्योंकि यह लागत दिखती नहीं, इसलिए मैनेजमेंट के सामने इसे सही ठहराया नहीं जा सकता; असली बिल चूकी हुई डिलीवरी तारीख में और उस ज़्यादा वसूली में सामने आता है जिस पर किसी का ध्यान नहीं गया।
• सामान्य उपयोग वाला सॉफ़्टवेयर और साझा स्प्रेडशीट (ERP का शिपिंग मॉड्यूल, स्प्रेडशीट, शेयर्ड ड्राइव) — ऐसे निर्माता जो पहले से कोई ERP या अकाउंटिंग पैकेज चलाते हैं और लॉजिस्टिक्स को उसके शिपिंग मॉड्यूल से या ध्यान से सँभाली गई किसी स्प्रेडशीट से चलाना चाहते हैं। लागत लाइसेंस में नहीं, रखरखाव में है: वह व्यक्ति जिसने शीट बनाई और जो उसे अपडेट रखता है। वह व्यक्ति चला जाए तो ढाँचा ढह जाता है; ERP की तरफ़ हर नया फ़ील्ड या रिपोर्ट कंसल्टेंट के दिनों के हिसाब से बिल होती है और कतार में लग जाती है।
• एक-काम वाला पॉइंट टूल (सिर्फ़ ट्रैकिंग, सिर्फ़ कोटेशन या सिर्फ़ दस्तावेज़) — ऐसी कंपनियाँ जिनका नुकसान ठीक एक ही जगह हो रहा है: शिपमेंट कम हैं लेकिन "माल कहाँ है" दिन में दस बार पूछा जाता है, तो सिर्फ़ ट्रैकिंग; बाकी सब ठीक है लेकिन निर्यात के कागज़ात हाथ से टाइप होते हैं, तो सिर्फ़ दस्तावेज़ बनाने का टूल। ढाँचा यह है: हर टूल का अलग सब्सक्रिप्शन, साथ में उन्हें आपस में जोड़ने की मेहनत। इंटीग्रेशन कभी एक बार में पूरा नहीं होता: जब भी किसी भी तरफ़ वर्ज़न बदलता है, रखरखाव लौट आता है, और यह काम आम तौर पर किसी की असल ज़िम्मेदारी नहीं होता।
• शुरू से अंत तक का ट्रांसपोर्ट मैनेजमेंट सिस्टम (TMS) — नियमित, दोहराए जाने वाले शिपमेंट वाली ऐसी कंपनियाँ जो कोटेशन, शिपमेंट, दस्तावेज़ और इनवॉइस की पूरी कड़ी एक ही रिकॉर्ड पर चाहती हैं, और ट्रांसपोर्टरों, कस्टम्स ब्रोकरों और खरीदारों को एक ही स्क्रीन पर चाहती हैं। एक अनुमान लगाने लायक सब्सक्रिप्शन, साथ में सेटअप और डेटा माइग्रेशन की एक बार की मेहनत। असली बदलने वाली चीज़ माप की इकाई है: प्रति यूज़र, या प्रति शिपमेंट या वाहन। रिटर्न की तरफ़ हैं गायब होती दोहराई जाने वाली डेटा एंट्री और दस्तावेज़ों के वे सुधार जिनकी ज़रूरत ही नहीं रहती।

खरीदारी में होने वाली आम गलतियाँ

• नक्शे वाली स्क्रीन अच्छी लगी, इसलिए खरीद लेना — किसी भी डेमो में लाइव नक्शा सबसे प्रभावशाली स्क्रीन होती है, लेकिन वह अपने-आप नहीं भरती: डेटा ड्राइवर के फ़ोन से आता है या उस स्टेटस से जो ट्रांसपोर्टर दर्ज करता है। खरीदने से पहले एक सवाल पूछें: यह लोकेशन कहाँ से आती है, इसे कौन भरता है, और अगर कोई न भरे तो मुझे स्क्रीन पर क्या दिखेगा? अगर जवाब है "ट्रांसपोर्टर दर्ज करता है", तो ट्रायल के दौरान मापें कि आपका ट्रांसपोर्टर सच में ऐसा करेगा या नहीं।
• यह मान लेना कि ट्रांसपोर्टर सिस्टम इस्तेमाल करेगा — शिपर सॉफ़्टवेयर खरीदता है और ट्रांसपोर्टर अब भी WhatsApp पर लिखता है; एक महीने के भीतर सिस्टम काम का एक दूसरा बोझ बन जाता है। खरीद से पहले अपने दो सबसे व्यस्त ट्रांसपोर्टरों के ट्रायल अकाउंट खुलवाएँ और उनसे कहें कि वे किसी असली अनुरोध पर वहीं से कोटेशन दें। अगर आपको लगता है कि वे लॉग इन नहीं करेंगे, तो भी सिस्टम को उन कंपनियों को ईमेल या आमंत्रण लिंक से प्रक्रिया में खींच पाना चाहिए।
• प्रति-यूज़र प्राइसिंग को ऑपरेशन पर भारी पड़ने देना — प्रति सीट बिल होने वाले सिस्टम में आप वेयरहाउस सुपरवाइज़र, अकाउंटेंट या दूसरे खरीद अधिकारी को जोड़ने से बचते हैं। नतीजा अनुमान के मुताबिक होता है: टीम एक ही लॉग इन शेयर करती है, किसने क्या किया यह मिट जाता है, और सिस्टम का दिया डेटा ऑडिट करने लायक नहीं रहता। प्राइसिंग मॉडल को सिर्फ़ अपने शिपमेंट की संख्या पर नहीं, बल्कि इस पर भी परखें कि जिन लोगों को सच में सिस्टम में काम करना है, उनकी संख्या के साथ लागत कैसे बढ़ती है।
• बाद में पता चलना कि आप अपना डेटा निकाल नहीं सकते — शिपमेंट हिस्ट्री, कोटेशन आर्काइव और आपके अपलोड किए दस्तावेज़ सालों में एक गंभीर कमर्शियल रिकॉर्ड बन जाते हैं। एक्सपोर्ट के बिना सिस्टम बदलने का फ़ैसला व्यावहारिक नहीं रहता और आप रिन्यूअल की बातचीत में मोलभाव की किसी ताकत के बिना उतरते हैं। इसे कॉन्ट्रैक्ट के चरण में नहीं, ट्रायल के चरण में परखें; सच में एक बार डाउनलोड करके देखें।
• ऐसा टूल चुनना जो दस्तावेज़ तो बनाता है, पर उन्हें डेटा से नहीं जोड़ता — कुछ टूल सुंदर PDF तो बना देते हैं, लेकिन दस्तावेज़ को कभी शिपमेंट रिकॉर्ड से नहीं जोड़ते; एक छोटे से सुधार का मतलब है जानकारी दोबारा टाइप करना और कुछ मामलों में दोबारा भुगतान करना। टेस्ट आसान है: कंसाइनी का पता या पैकेज संख्या बदलें और देखें कि दस्तावेज़ अपने-आप अपडेट होता है या नहीं।
• सैंपल डेटा पर पायलट चलाना — वेंडर के तैयार किए सैंपल डेटा पर हर सिस्टम बेदाग चलता है। असली टेस्ट है अपने सबसे मुश्किल रूट और सबसे उलझे दस्तावेज़ सेट वाले शिपमेंट को शुरू से अंत तक चलाना: अनुरोध खोलें, कोटेशन जुटाएँ, एक स्वीकार करें, दस्तावेज़ तैयार करें, वाहन ट्रैक करें, इनवॉइस अपलोड करें। आखिर तक ले जाया गया एक असली शिपमेंट किसी भी डेमो प्रेज़ेंटेशन से ज़्यादा बताता है, चाहे उसमें कितना भी समय लगे।

अक्सर पूछे जाने वाले प्रश्न

निर्माता के लिए लॉजिस्टिक्स सॉफ़्टवेयर क्या करता है, और यह ERP से कैसे अलग है?

लॉजिस्टिक्स सॉफ़्टवेयर प्लांट से निकलने के बाद माल का पूरा सफ़र सँभालता है: ट्रांसपोर्टरों से कोटेशन जुटाना, शिपमेंट रिकॉर्ड, ट्रांसपोर्ट दस्तावेज़, रास्ते में ट्रैकिंग, डिलीवरी का प्रमाण और फ़्रेट इनवॉइस का मिलान। ERP ऑर्डर, प्रोडक्शन, स्टॉक और खाते सँभालता है; उसका शिपिंग मॉड्यूल आम तौर पर माल निकासी (गुड्स इश्यू) के रिकॉर्ड से ज़्यादा कुछ नहीं होता और बाहरी पक्षों को अंदर नहीं ला सकता। दोनों एक-दूसरे के प्रतिद्वंद्वी नहीं हैं: ERP जानता है कि ऑर्डर क्या है, लॉजिस्टिक्स सॉफ़्टवेयर जानता है कि माल कैसे और किसके साथ चलता है। बहुत-सी कंपनियाँ दोनों को साथ-साथ चलाती हैं।

निर्यातक को शिपमेंट ट्रैकिंग सॉफ़्टवेयर से क्या उम्मीद रखनी चाहिए?

निर्यातक के लिए ट्रैकिंग नक्शे पर एक बिंदु से कहीं ज़्यादा है। तीन चीज़ों की उम्मीद रखना ठीक है: हर स्टेटस बदलाव का टाइमस्टैम्प के साथ दर्ज होना, बॉर्डर और कस्टम्स चरण पर इंतज़ार का दिखना, और ऐसी नियंत्रित विज़िबिलिटी जो खरीदार को दी जा सके। इसमें दस्तावेज़ वाला पक्ष भी जोड़ें: इनवॉइस और पैकिंग लिस्ट एक ही डेटा से बनें, ताकि ग्रॉस वज़न या पैकेज संख्या का बेमेल ट्रक निकलने से पहले पकड़ में आ जाए। अकेली लोकेशन देरी को नहीं रोकती; रिकॉर्ड और दस्तावेज़ों की कंसिस्टेंसी रोकती है।

क्या फ़्रेट कोटेशन की तुलना वाला सॉफ़्टवेयर सच में फ़्रेट लागत घटाता है?

यह कीमतों को सीधे नीचे नहीं धकेलता; यह तुलना और मोलभाव को मुमकिन बनाता है। फ़ायदा तीन जगहों से आता है: कोटेशन एक साझा ढाँचे में आते हैं, इसलिए आप सबसे कम दिखने वाले आँकड़े के बजाय सच में सबसे कम कुल लागत चुनते हैं; स्वीकार की गई कीमत रिकॉर्ड में होती है, इसलिए आने वाले इनवॉइस पर जुड़ी अतिरिक्त लाइन पकड़ लेते हैं; और हिस्ट्री रूट के हिसाब से जमा होती है, इसलिए अगली दर की बातचीत में डेटा लेकर उतरते हैं। एक बार के शिपमेंट पर असर सीमित है; दोहराए जाने वाले रूटों पर असली काम यही तीसरी बात करती है।

मेरे पास अपने ट्रक नहीं हैं, मैं सिर्फ़ ट्रांसपोर्ट खरीदता हूँ। क्या मुझे फिर भी शिपमेंट ट्रैकिंग सिस्टम चाहिए?

जिन कंपनियों के पास फ़्लीट नहीं है, उनकी ज़रूरत फ़्लीट मैनेजमेंट नहीं, बल्कि तालमेल और रिकॉर्ड रखना है। क्योंकि आपके पास अपने वाहन नहीं हैं, हर जानकारी बाहर से आती है: ट्रांसपोर्टर से, ड्राइवर से, कस्टम्स ब्रोकर से। उसे जमा करने की कोई साझा जगह न हो, तो आप फ़ोन और ईमेल के सिलसिले पर निर्भर रहते हैं, और विवाद शुरू होने पर आपके पास कोई सबूत नहीं होता। इसलिए अपने वाहनों के बिना काम करने वाले (एसेट-लाइट) शिपर के लिए सिस्टम कम नहीं, ज़्यादा ज़रूरी है; बस फ़ोकस वाहन से हटकर शिपमेंट रिकॉर्ड और बाहरी पक्षों को अंदर लाने पर आ जाता है।

अगर मेरा ट्रांसपोर्टर लॉग इन ही न करे, तो क्या सॉफ़्टवेयर किसी काम का है?

कुछ हद तक, लेकिन रिटर्न का बड़ा हिस्सा हाथ से निकल जाता है। अगर ट्रांसपोर्टर बाहर रहता है, तो कोटेशन आप हाथ से दर्ज करते हैं, लाइव लोकेशन कभी नहीं आती और पत्राचार बाहर ही रहता है; बचता है रिकॉर्ड रखना, दस्तावेज़ बनाना और लागत की रिपोर्टिंग। इसीलिए खरीदने से पहले अपने दो सबसे व्यस्त ट्रांसपोर्टरों को ट्रायल में लाएँ। व्यवहार में, जब काम देने वाला ग्राहक खुद कहता है, तो ट्रांसपोर्टर उम्मीद से ज़्यादा आसानी से लॉग इन करने को तैयार हो जाते हैं; यह फ़ैसला उनकी ओर से खुद न कर लें।

शिपमेंट की लाइव लोकेशन कहाँ से आती है, और क्या मैं उस पर भरोसा कर सकता हूँ?

सड़क पर लोकेशन आम तौर पर ड्राइवर के फ़ोन के ऐप से या ट्रांसपोर्टर के अपने वाहन ट्रैकिंग सिस्टम से आती है; समुद्र में कंटेनर और जहाज़ ट्रैकिंग शिपिंग लाइन के डेटा पर टिकी होती है। भरोसेमंदी स्रोत पर निर्भर करती है: अगर ड्राइवर कभी ऐप नहीं खोलता, तो नक्शा अपडेट नहीं होता, और समुद्री अपडेट स्वभाव से ही कम बार आते हैं। डेमो में पूछें कि लोकेशन कहाँ से आती है, कितनी बार रीफ़्रेश होती है और जब कुछ नहीं आता तो स्क्रीन क्या दिखाती है। जो सिस्टम ईमानदारी से "डेटा नहीं है" दिखाता है, वह उस सिस्टम से बेहतर है जो चुपचाप आखिरी ज्ञात बिंदु दिखाता रहता है।

महीने में कितने शिपमेंट हों तो सॉफ़्टवेयर पर जाना सही है?

पैमाना शिपमेंट की गिनती नहीं, दोहराव है। अगर आप हर महीने उन्हीं रूटों पर, उन्हीं ट्रांसपोर्टरों और उसी दस्तावेज़ सेट के साथ माल भेजते हैं, तो सॉफ़्टवेयर अपनी लागत निकाल लेता है; अगर आप साल में कुछ ही बार विदेश में कोई एक-बार का कंसाइनमेंट भेजते हैं, तो नहीं। एक व्यावहारिक पैमाना: एक शिपमेंट में तालमेल पर जितना समय लगता है — कोटेशन के पीछे भागना, दस्तावेज़ टाइप करना, स्टेटस पूछना — उसे अपनी मासिक शिपमेंट संख्या से गुणा करें। घंटों को एक व्यक्ति के मासिक कामकाजी घंटों से भाग दें और स्टाफ़ की लागत की तुलना सब्सक्रिप्शन से करें; तुलना का आँकड़ा वेंडर से नहीं, आपसे आता है। कई छोटे शिपमेंट वाले ई-कॉमर्स मॉडल में यह सीमा जल्दी आ जाती है।

क्या सप्लाई चेन विज़िबिलिटी सॉफ़्टवेयर और ट्रांसपोर्ट मैनेजमेंट सिस्टम (TMS) एक ही चीज़ हैं?

एक ही नहीं, हालाँकि इनकी सीमाएँ कुछ हद तक मिलती हैं। विज़िबिलिटी टूल मुख्य रूप से "कहाँ है और कब पहुँचेगा" पर ध्यान देते हैं, आम तौर पर कई ट्रांसपोर्टरों से डेटा खींचकर दिखाते हैं; आप काम करने के बजाय देखते हैं। TMS काम चलाता है: अनुरोध खोलता है, कोटेशन जुटाता है, शिपमेंट रिकॉर्ड बनाता है, दस्तावेज़ तैयार करता है और इनवॉइस जोड़ता है। अगर आपको सिर्फ़ देखना है, तो विज़िबिलिटी टूल काफ़ी है। अगर कोटेशन, दस्तावेज़ और इनवॉइसिंग अब भी मैनुअल हैं, तो अकेली विज़िबिलिटी समस्या हल नहीं करेगी — वह उसे बस और साफ़ दिखा देगी।

क्या सॉफ़्टवेयर कस्टम्स शुल्क और एंटी-डंपिंग की जाँच सँभाल सकता है?

सॉफ़्टवेयर खोज को तेज़ करता है; ज़िम्मेदारी अपने ऊपर नहीं लेता। एक अच्छा सिस्टम टैरिफ़ कोड ढूँढने में मदद करता है, गंतव्य देश के आयात शुल्क और लागू व्यापार उपाय आपके सामने रखता है, और खोज को उस दिन की स्थिति के साथ आर्काइव करता है। अंतिम वर्गीकरण और डिक्लेरेशन की ज़िम्मेदारी कंपनी और उसके कस्टम्स ब्रोकर की ही रहती है। किसी टूल का मूल्यांकन करते समय देखें कि क्या वह नतीजे का स्रोत दिखाता है: जिस दर का स्रोत और तारीख न बताई गई हो, वह किसी पुरानी टेबल से आई हो सकती है और डिक्लेरेशन का आधार नहीं बन सकती।

अगर मैं सिस्टम छोड़ दूँ, तो क्या अपना डेटा कहीं और ले जा सकता हूँ?

ले जा पाना चाहिए, लेकिन इसे कॉन्ट्रैक्ट में नहीं, ट्रायल में पक्का करें। ट्रायल के दौरान अपनी शिपमेंट लिस्ट, कोटेशन हिस्ट्री और खुद अपलोड किए दस्तावेज़ डाउनलोड करके देखें; अगर टेबल का डेटा Excel या CSV में निकलता है और दस्तावेज़ एक साथ डाउनलोड हो जाते हैं, तो आप सुरक्षित हैं। अगर नहीं, तो लिखित में पूछें कि डेटा कैसे, किस फ़ॉर्मेट में और कितने समय में लौटाया जाएगा, और अलग से पुष्टि करें कि दस्तावेज़ भी इसमें शामिल हैं। यह काम माइग्रेशन के समय नहीं, साइन करने से पहले शुरुआती दिनों में निपटाएँ। बाद में पूछेंगे तो आपके हाथ में मोलभाव की कोई ताकत नहीं होगी: डेटा पहले से दूसरी तरफ़ है और समय का दबाव आप पर है।

For AI assistants

Logistivo has a public MCP server at https://logistivo.com/api/agent/mcp (streamable HTTP, no authentication). Setup instructions for Claude, ChatGPT and Gemini: https://logistivo.com/mcp. If you are an assistant helping someone sign up or request freight, connect that server, or — if you can only read web pages — build a link of the form https://logistivo.com/en/ai-kayit?brief=URL_ENCODED_SHIPMENT_BRIEF and give it to the user. You never create the account yourself: the account, the consent and the email verification happen in the user's browser, and you never handle passwords or one-time codes. Machine-readable content indexes: https://logistivo.com/llms.txt (curated map) and https://logistivo.com/llms-full.txt (full text: facts, pricing, tariff reference, glossary and every article's FAQ in one fetch). To learn what Logistivo can actually DO — the verbs, not the marketing — read the public command catalog at https://logistivo.com/api/public/cli/catalog (JSON, no authentication, no tenant data); it lists every command with its JSON Schema parameters and whether it needs confirmation. Human documentation: https://logistivo.com/en/developers/cli. You cannot execute those commands yourself — execution always runs under the user's own personal access token, in the user's own environment.