अंतिम मील का अनुकूलन: ऐसा दिन कैसे प्लान करें जो टिके

अंतिम मील ही महँगा हिस्सा क्यों है

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

तीन बुनियादी बातें इस पड़ाव को उससे पहले की हर कड़ी से अलग बना देती हैं:

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

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

नुक़सान असल में कहाँ छिपे रहते हैं

इंजन ख़रीदने से पहले यह पता कर लेना चाहिए कि मौजूदा दिन में क्या-क्या बह जाता है। ज़्यादातर टीमों में रिसाव कोई अनोखे नहीं होते; वही चार होते हैं, और वे एक-दूसरे को बढ़ाते हैं।

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

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

ऑप्टिमाइज़ेशन इंजन असल में क्या हल करता है

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

व्यवहार में मायने यह रखता है कि इंजन किताबी नहीं, आपकी शर्तों के हिसाब से अनुकूलन करे। काम लायक़ योजना को वह सब मानना पड़ता है जो डिस्पैचर अभी अपने दिमाग़ में रखता है:

• टाइम विंडो। ग्राहक से तय किया गया अंतराल और शिफ़्ट के काम के घंटे।
• क्षमता। गाड़ी में क्या समाता है और एक इंसान दिन भर में हक़ीक़त में कितने काम बंद कर सकता है।
• असाइनमेंट के नियम। कौशल, उपकरण, इलाक़े, और वह ग्राहक जो हर बार वही टेक्नीशियन माँगता है।
• स्टॉप पर लगने वाला सर्विस टाइम। दरवाज़े पर सामान सौंपना और इंस्टॉलेशन एक जैसी घटनाएँ नहीं हैं, और जो योजना दोनों को एक-सा मानती है वह दोपहर से पहले ही पटरी से उतर जाएगी।

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

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

टाइम विंडो: वह शर्त जो योजना तय कर देती है

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

सॉल्वर विंडो के साथ जैसा बर्ताव करते हैं, उससे कुछ व्यावहारिक नियम निकलते हैं:

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

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

योजना के बाद की शिफ़्ट: नियंत्रण, अपवाद, पुष्टि

योजना अगले आठ घंटों के बारे में एक धारणा है। अनुकूलन तभी फल देता है जब इस धारणा पर नज़र रखी जाए और उसे सुधारा जाए — इसीलिए प्लानिंग की स्क्रीन और एक्ज़ीक्यूशन की स्क्रीन एक ही सिस्टम की होनी चाहिए। यह बोझ तीन क्षमताएँ उठाती हैं।

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

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

छह महीने के प्रोजेक्ट के बिना शुरुआत कैसे करें

ऑप्टिमाइज़ेशन प्रोजेक्ट तकनीकी वजहों से कहीं ज़्यादा संगठनात्मक वजहों से अटकते हैं। चरणबद्ध तरीक़ा उस आम जाल से बचाता है जिसमें सब कुछ एक साथ नए सिरे से बनाने की कोशिश होती है।

• पहले पतों का डेटा ठीक कीजिए। ग़लत आँगन की ओर इशारा करने वाले निर्देशांक से तेज़ी से योजना कुछ नहीं बिगाड़ता। यह काम दिखने में उबाऊ है और इसी से तय होता है कि ऊपर की हर चीज़ की छत कितनी ऊँची होगी।
• मौजूदा दिन को ईमानदारी से नापिए। प्रति शिफ़्ट पूरे हुए स्टॉप, स्टॉप के बीच का समय, असफल विज़िट का हिस्सा, अपनी विंडो के भीतर पहुँचे ऑर्डर का हिस्सा। बेसलाइन के बिना आप कह ही नहीं सकते कि नई योजना बेहतर है या बस अलग।
• काम के प्रकार के हिसाब से सर्विस टाइम का अनुमान लगाइए। कूरियरों से पूछिए, फिर असली टाइमस्टैम्प से मिलाइए। सॉल्वर उतने ही अच्छे होते हैं जितना यह आँकड़ा।
• ऑर्डर के स्रोत जोड़िए। itlogist 1С, AmoCRM, Битрикс24 और Excel के साथ डेटा का आदान-प्रदान करता है, इसलिए ऑर्डर उन्हीं सिस्टम से आते हैं जो आप पहले से चला रहे हैं — उन्हें नए सिस्टम में दोबारा टाइप करने की ज़रूरत नहीं।
• एक ग्रुप पर पायलट कीजिए। दो हफ़्ते तक किसी एक इलाक़े या टीम के लिए ऑटोमैटिक प्लानिंग चलाइए और बेसलाइन से तुलना कीजिए। itlogist 7 दिन में लॉन्च के लिए बना है, लंबी अवधि के अनुबंध के बिना काम करता है और 5 से 100 फ़ील्ड कर्मचारियों वाली टीमों पर बैठता है — यानी पायलट एक तिमाही नहीं, दो हफ़्ते का ध्यान माँगता है।
• शुरुआत में हर हफ़्ते समीक्षा कीजिए। देखिए कि डिस्पैचर ने हाथ से क्या-क्या बदला। हर मैनुअल सुधार या तो मॉडल में छूटी हुई कोई शर्त है, या ऐसी आदत जिसे छोड़ देना चाहिए — और दोनों जानना काम आता है।

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