कूरियर डिलीवरी का ऑटोमेशन: लागू करने की शुरुआत कहाँ से करें

कूरियर सेवा में असल में क्या ऑटोमेट किया जाता है

डिलीवरी ऑटोमेट करने का मतलब «प्रोग्राम ख़रीदना और कूरियरों को फ़ोन बाँट देना» नहीं है। बात यह है कि हर दोहराया जाने वाला काम किसी एक व्यक्ति की याददाश्त पर निर्भर रहना बंद कर दे। कूरियर सेवा में ऐसे पाँच काम होते हैं, और वे मिलकर एक ही शृंखला बनाते हैं।

• ऑर्डर लेना। ऑर्डर ऑनलाइन स्टोर से, ईमेल से, मैसेंजर से और अकाउंटिंग सिस्टम से आते हैं। जब तक उन्हें हाथ से एक टेबल में जोड़ा जाता है, कुछ खो जाते हैं और कुछ दो बार दर्ज हो जाते हैं।
• कर्मचारियों में बँटवारा। कौन जाएगा, किस क्रम में जाएगा और क्या वह शिफ़्ट में पूरा कर पाएगा — यह फ़ैसला डिस्पैचर दिन में दर्जनों बार लेता है और लगभग हमेशा अंदाज़े से।
• पते पर कूरियर का काम। वहाँ ठीक-ठीक क्या करना है, कौन-सी चीज़ें लेनी हैं, पूरा होने की पुष्टि कैसे करनी है — यह सब कर्मचारी के फ़ोन में होना चाहिए, न कि ज़ुबानी तय बातों में।
• ग्राहक को जानकारी देना। «मेरा ऑर्डर कहाँ है» सवाल डिस्पैचर का उतना समय लेता है जितना लगता नहीं, और यह पूरी तरह ग्राहक पोर्टल में दिख रहे स्टेटस से हल हो जाता है।
• रिपोर्टिंग के लिए तथ्य जुटाना। पहुँचने का समय, विज़िट का नतीजा, फ़ोटो रिपोर्ट — यह डेटा या तो घटना के वक़्त दर्ज होता है, या फिर उसका अस्तित्व ही नहीं होता।

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

संकेत कि हाथ से चलाना अब ऑटोमेशन से महँगा पड़ रहा है

हर सेवा को सिस्टम अभी इसी वक़्त नहीं चाहिए। लेकिन कुछ लक्षण ऐसे हैं जिनमें से हर एक असुविधा नहीं, सीधा पैसा है।

• सुबह प्लानिंग में ही निकल जाती है। अगर डिस्पैचर ऑर्डर बाँटने में डेढ़-दो घंटे लगाता है, तो यह एक पूरी तनख़्वाह है जो टेबल में घुल रही है।
• कर्मचारी कहाँ है, यह फ़ोन करके पता चलता है। हर कॉल डिस्पैचर का एक मिनट, कूरियर का एक मिनट और रूट में देरी है।
• दिन का हिसाब शाम को बनता है। यानी दिन भर सेवा चलाई नहीं जाती, सिर्फ़ नतीजे दर्ज किए जाते हैं।
• विवाद ज़ुबानी सुलझते हैं। «किसी ने दरवाज़ा नहीं खोला», «गार्ड के पास छोड़ दिया», «ग्राहक ने मना कर दिया» — फ़ोटो और विज़िट के समय के बिना यह न ग्राहक के लिए सबूत है, न आंतरिक जाँच के लिए।
• सारा ज्ञान एक ही आदमी के पास है। डिस्पैचर छुट्टी पर जाते ही सेवा लड़खड़ाने लगती है। यह वफ़ादारी का नहीं, सिस्टम में नियम न होने का मामला है।
• ऑर्डर बढ़ने पर लोग कम पड़ जाते हैं। 30% ज़्यादा वॉल्यूम के लिए एक और डिस्पैचर चाहिए — मतलब प्रक्रिया स्केल नहीं होती।
• दोबारा जाने के मामले गिने ही नहीं जाते। दूसरी कोशिशों का हिस्सा पता नहीं है, जबकि वही सीधे लागत बनाता है।

अगर इनमें से कम से कम तीन बातें मिलती हैं, तो सवाल «कभी लागू करेंगे» का नहीं, बल्कि अभी हो रहे नियमित नुक़सान का है। और शुरुआत की दहलीज़ उतनी ऊँची नहीं जितनी मानी जाती है: इस श्रेणी के प्लेटफ़ॉर्म 5 से 100 कर्मचारियों वाली टीमों के लिए बने हैं, यानी ऑटोमेशन अब सिर्फ़ बड़ी राष्ट्रीय सेवाओं की कहानी नहीं रह गया।

शुरुआत कहाँ से करें: वह क्रम जो वाक़ई काम करता है

सबसे बड़ी ग़लती है सब कुछ एक साथ चालू करने की कोशिश। जो क्रम काम करता है, वह ऑर्डर की शृंखला के साथ चलता है: उसके आने से लेकर पुष्ट नतीजे तक। हर अगला क़दम पिछले क़दम के डेटा पर टिका होता है।

• क़दम 1. ऑर्डर के लिए एक ही प्रवेश बिंदु। चैनल कोई भी हो, सारे ऑर्डर एक ही जगह आएँ। जब तक स्रोत कई हैं, आगे की हर रिपोर्ट अधूरी रहेगी।
• क़दम 2. कर्मचारियों में बँटवारा। हर ऑर्डर को एक ज़िम्मेदार और एक समयसीमा मिलती है। इसी चरण पर असली लोड दिखने लगता है: किसकी शिफ़्ट ठुँसी हुई है और कौन ख़ाली बैठा है।
• क़दम 3. कर्मचारी का मोबाइल इंटरफ़ेस। कूरियर पतों की सूची, टिप्पणियाँ और चेकलिस्ट देखता है, नतीजा दर्ज करता है और फ़ोटो जोड़ता है। यह कुंजी वाला क़दम है: इसके बिना सिस्टम डिस्पैचर की स्क्रीन पर एक सुंदर तस्वीर भर रह जाता है और रूट से तथ्य नहीं पाता।
• क़दम 4. रियल टाइम स्टेटस। नक्शे पर रूट और ऑर्डर की मौजूदा स्थिति «तुम कहाँ हो» वाली ज़्यादातर कॉल ख़त्म कर देते हैं।
• क़दम 5. ग्राहक पोर्टल। ग्राहक ख़ुद स्टेटस देख लेता है — डिस्पैचर पर बोझ और एक दर्जा घट जाता है।
• क़दम 6. रूट ऑप्टिमाइज़ेशन। जब पते, विंडो और पाबंदियाँ सिस्टम में आ चुकी हैं, तब घूमने के क्रम की गणना चालू होती है — और वह कचरे पर नहीं, सही डेटा पर चलती है।
• क़दम 7. अकाउंटिंग सिस्टम के साथ इंटीग्रेशन। सबसे आख़िर में 1С, AmoCRM, Bitrix24 या Excel के साथ डेटा का आदान-प्रदान जोड़ा जाता है, ताकि ऑर्डर और नतीजे हाथ से न ढोने पड़ें।

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

वे ग़लतियाँ जिनकी वजह से सिस्टम जड़ नहीं पकड़ता

प्रोजेक्ट अक्सर तकनीक पर नहीं, संगठन पर बिगड़ता है। आम परिदृश्य एक सेवा से दूसरी सेवा में दोहराते रहते हैं।

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

एक काम का नियम: लॉन्च से पहले तीन-चार «जैसा है» मीट्रिक लिख लें — प्रति शिफ़्ट पते, दूसरी कोशिशों का हिस्सा, प्लानिंग का समय, स्टेटस पूछने वाली इनकमिंग कॉल की संख्या। महीने भर बाद तुलना में पाँच मिनट लगेंगे।

अपनी सेवा के लिए सिस्टम कैसे चुनें

सप्लायरों की फ़ीचर सूचियाँ एक जैसी दिखती हैं, इसलिए तुलना इस आधार पर करना बेहतर है कि आपके रोज़ाना परिदृश्य में क्या होता है। कुछ सवाल, जो कुछ भी साइन करने से पहले पूछ लेने चाहिए।

• क्या सिस्टम पूरी शृंखला कवर करता है? ऑर्डर लेना और बाँटना, पते पर कर्मचारी का काम, ग्राहक के लिए स्टेटस, रिपोर्टिंग — अगर कोई हिस्सा टेबल में ही रह गया, तो कड़ी टूटी रहेगी।
• कूरियर क्या देखता है और क्या करता है? पतों की सूची, चेकलिस्ट, फ़ोटो रिपोर्ट, मौक़े पर ही पूरा होने की पुष्टि — यही स्क्रीन ऊपर की सारी जानकारी की गुणवत्ता तय करती है।
• क्या रूट ऑप्टिमाइज़ेशन सचमुच का है? इलाक़ों के हिसाब से छाँटना और डिलीवरी विंडो व पाबंदियों को ध्यान में रखकर घूमने का क्रम निकालना दो बिलकुल अलग चीज़ें हैं।
• आपके सिस्टम के साथ डेटा का आदान-प्रदान कैसे बना है? 1С, AmoCRM, Bitrix24, Excel — अहम यह नहीं कि साइट पर लोगो लगा है, बल्कि यह कि कौन-से ऑब्जेक्ट किस दिशा में जाते हैं।
• लॉन्च में कितना समय लगता है और जोखिम क्या है? बिना लंबे अनुबंध के एक हफ़्ते में शुरुआत और अग्रिम भुगतान वाला कई महीने का प्रोजेक्ट — वादे एक जैसे होने पर भी जोखिम का स्तर अलग है।
• क्या पैमाना मेल खाता है? सैकड़ों गाड़ियों के लिए बने समाधान दस कूरियरों की सेवा के लिए ज़रूरत से ज़्यादा हैं, और उल्टा भी सच है।

यह सब प्रेज़ेंटेशन से नहीं, अपने डेटा पर जाँचना ज़्यादा सुविधाजनक है: एक सामान्य दिन लीजिए, असली पते अपलोड कीजिए और देखिए क्या निकलता है। itlogist में ऐसी जाँच जिन सुविधाओं से बनती है — ऑर्डर लेना और बाँटना, नक्शे पर रियल टाइम रूट, फ़ोटो रिपोर्ट और चेकलिस्ट वाला कर्मचारी का मोबाइल ऐप, स्टेटस के साथ ग्राहक पोर्टल और मौक़े पर काम पूरा होने की पुष्टि — उन्हें कूरियर प्रबंधन पेज पर विस्तार से देखा जा सकता है।

पहले महीने में क्या बदलना चाहिए

ऑटोमेशन का असर भावनाओं में नहीं, कुछ ठोस आँकड़ों में दिखता है। अगर महीने भर बाद वे हिले ही नहीं, तो कुछ क़दम सिर्फ़ दिखावे के लिए उठाए गए हैं।

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

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

व्यावहारिक निष्कर्ष सीधा है: शुरुआत सबसे जटिल हिस्से से नहीं, बल्कि वहाँ से करनी चाहिए जहाँ डेटा जन्म लेता है — ऑर्डर लेने और कर्मचारी की स्क्रीन से। बाक़ी सब कुछ, रूट की गणना और अकाउंटिंग सिस्टम से आदान-प्रदान समेत, उसी के ऊपर बनता है और ठीक उतना ही अच्छा चलता है जितना नीचे का डेटा ईमानदार होता है।