विचार नेता

अगला एआई विभाजन: मध्य‑स्तर की लॉजिस्टिक्स कंपनियों को एआई का उपयोग करने से पहले अपनी बुनियादी ढांचे को क्यों सुधारना चाहिए

mm
Unite.AI को Google पर अपने पसंदीदा स्रोतों में जोड़ें

एआई के बारे में बातचीत अक्सर पहुंच पर केंद्रित होती है, यह मानते हुए कि एक कंपनी के पास सही मॉडल और उपकरणों तक पहुंच हो जाने पर अगली चुनौती यह पता लगाना है कि उनका उपयोग कैसे किया जाए। मध्य‑स्तर की लॉजिस्टिक्स कंपनियों के लिए, समस्या जरूरी नहीं कि वहीं से शुरू हो।

कई गोदामों और थर्ड‑पार्टी लॉजिस्टिक्स प्रदाताओं (3PLs) में, अंतर अक्सर कोई अनुपस्थित प्रणाली नहीं होता। अधिकांश कंपनियों के पास पहले से ही गोडाम प्रबंधन प्रणाली (WMS), एंटरप्राइज़ रिसोर्स प्लानिंग सॉफ़्टवेयर (ERP) या लेखा पैकेज, कैरियर कनेक्शन और बड़े ग्राहकों के साथ EDI होते हैं। समस्या यह है कि इन प्रणालियों के बीच क्या होता है।

पॉइंट‑टू‑पॉइंट कनेक्शन समय के साथ जमा होते जाते हैं। एक ग्राहक या व्यापारिक साझेदार एक तरीके से जुड़ता है, दूसरा साझेदार दूसरे तरीके से जुड़ता है और अंततः कोई भी यह पूरी तस्वीर नहीं देख पाता कि कौन क्या से संवाद करता है। एकीकरण लोगों पर भी निर्भर करता है, जैसे जब कोई ग्राहक पोर्टल से आदेशों को फिर से दर्ज करता है या प्रत्येक सुबह स्प्रेडशीट में कल के शिपमेंट को मिलाता है। एक 3PL यह नहीं जान पाता कि लेन‑देन विफल हो गया है जब तक ग्राहक कॉल करके अपने आदेश की स्थिति पूछता नहीं।

इनमें से कुछ भी आईटी एसेट सूची में नहीं दिखता, इसलिए समस्या को कम आंकना बहुत आसान हो जाता है।

हस्तांतरण बिंदुओं में समस्या

सबसे बड़े परिचालन समस्याएँ अक्सर हैंड‑ऑफ़ पर होती हैं, जहाँ एक ऑर्डर, रसीद या शिपमेंट एक प्रणाली या कंपनी से दूसरी में स्थानांतरित होता है:

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

एक 3PL के लिए, ये समस्याएँ बढ़ जाती हैं क्योंकि प्रत्येक ग्राहक के अपने फ़ॉर्मेट, नियम और अपेक्षाएँ होती हैं। गोदाम का संचालन आमतौर पर ठीक रहता है, लेकिन उसके आसपास की सूचना प्रवाह टूट जाता है।

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

लॉजिस्टिक्स में, उपयोगी प्रश्न अक्सर इन सीमाओं को पार करते हैं, इसलिए किसी ऑर्डर के बारे में उत्तर देने के लिए WMS, ERP और एक ट्रांसपोर्टेशन या ग्राहक प्रणाली से जानकारी चाहिए हो सकती है। एक एआई टूल जो केवल प्रक्रिया के एक भाग को देखता है, वह अधूरी तस्वीर से काम कर रहा है।

कंपनियों के बीच एक बढ़ता हुआ अंतर है जिनका बुनियादी ढांचा एआई को आवश्यक सूचना के साथ काम करने देता है और कंपनियों के जिनकी प्रणालियाँ अभी भी असंबद्ध हैं, और यही वह जगह है जहाँ अगला एआई विभाजन उभर रहा है।

एआई को ऐसी नींव चाहिए जिस पर वह वास्तव में काम कर सके

एक वास्तविक एआई‑तैयार बुनियादी ढांचा तकनीकी शब्दों के बजाय परिचालन शब्दों में वर्णित होना चाहिए। प्रत्येक महत्वपूर्ण घटना, जैसे ऑर्डर, रसीद, इन्वेंटरी मूव या शिपमेंट, एक सामान्य हब से होकर गुजरनी चाहिए न कि अलग‑अलग कनेक्शन के संग्रह के रूप में। ट्रेडिंग पार्टनर द्वारा भेजा गया फ़ॉर्मेट अब गोदाम की समस्या नहीं होना चाहिए। X12, EDIFACT, XML या JSON को एक ही ऑर्डर में सामान्यीकृत किया जाना चाहिए इससे पहले कि नीचे की ओर कोई फ़ॉर्मेट के बारे में सोचे।

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

जब ये शर्तें पूरी हो जाती हैं, तो एआई जोड़ना बहुत अधिक सरल हो जाता है। इसका मतलब यह नहीं है कि मध्य‑स्तर की कंपनी को अपनी पूरी तकनीकी स्टैक बदलनी पड़े। वास्तव में, एक मध्य‑स्तर का 3PL लगभग कभी भी एआई‑तैयार होने के लिए नया WMS या ERP नहीं लेता। अधिक व्यावहारिक तरीका यह है कि कोर प्रणालियों को जैसा है वैसा ही छोड़ें और उनके बीच के कनेक्शन को ठीक करें।

एक एकल हब, जिससे प्रत्येक प्रणाली और साझेदार जुड़ते हैं, एक‑एक लिंक के जाल से कहीं अधिक प्रबंधित करने में आसान है।

एआई बुनियादी ढाँचा बनाने में मदद कर सकता है

यह वह जगह भी है जहाँ एआई मध्य‑स्तर की कंपनियों के लिए विशेष रूप से उपयोगी हो सकता है। पारंपरिक रूप से, एकीकरण के लिए लोगों को साझेदार की विशिष्टताओं को पढ़ना, फ़ील्ड को हाथ से मैप करना और प्रत्येक ट्रेडिंग पार्टनर के लिए उन मैपिंग्स का परीक्षण करना आवश्यक होता था। एक एकल पार्टनर मैप को कई हफ़्तों का व्यावहारिक काम, परीक्षण और साझेदार के साथ निरंतर संवाद चाहिए होता है।

वर्तमान एआई मॉडल विशिष्टताओं और नमूना फ़ाइलों को पढ़ने, मैपिंग का प्रस्ताव करने और उसे वास्तविक लेन‑देन के विरुद्ध परीक्षण करने में सक्षम हैं। फिर कोई व्यक्ति परिणाम की समीक्षा और अनुमोदन कर सकता है।

AI EDI मैपिंग के पहले संस्करण को बनाने के लिए आवश्यक व्यावहारिक कार्य को कम कर सकता है। विशेषज्ञ एक मसौदे से शुरू कर सकता है, फिर उसे समीक्षा करके सही कर सकता है, इससे पहले कि वह साझेदार की मौजूदा समीक्षा चक्र के माध्यम से भेजा जाए, जिससे विशेषज्ञ फ़ील्ड‑दर‑फ़ील्ड मैपिंग बनाने में कम समय खर्च कर सकें जबकि अंतिम आउटपुट पर नियंत्रण बनाए रखें।

लेकिन एक महत्वपूर्ण अंतर है AI को एकीकरण के लिए उपयोग करने और AI पर एकीकरण को भरोसा करने के बीच।

जब मैं यह करता हूँ, तो मैं एक दृष्टिकोण अपनाता हूँ जिसे मैं “Propose, Ground, Verify, Confirm.” कहता हूँ।

AI साझेदार सेटअप और फ़ील्ड मैपिंग का प्रस्ताव करता है। यह वास्तविक विनिर्देश और नमूना फ़ाइलों पर आधारित है, न कि फ़ील्ड या कोड बनाकर। एक अलग सत्यापन प्रक्रिया मैपिंग को फ़ील्ड‑दर‑फ़ील्ड वास्तविक दस्तावेज़ के विरुद्ध तुलना करती है। फिर एक व्यक्ति परिणाम की पुष्टि करता है इससे पहले कि वह लाइव ग्राहक प्रवाह तक पहुँचे। 

हमने यह समझा कि वह अनुशासन क्यों महत्वपूर्ण है, AI‑जनित मानचित्रों को वास्तविक उत्पादन दस्तावेज़ों के खिलाफ परीक्षण करके।

एक परीक्षण में, AI‑जनित मानचित्र ने वेयरहाउस ट्रांसफ़र दस्तावेज़ को शून्य त्रुटियों के साथ पढ़ा और फिर भी सभी 15 लाइन आइटम छोड़ दिए। दूसरे परीक्षण में, उसने शिपिंग ऑर्डर पर सभी छह पक्षों को बरकरार रखा, लेकिन वह कोड खो दिया जो यह पहचानता था कि कौन सा पक्ष शिप‑टू है, साथ ही सड़क पता भी। हमारी स्वचालित जांच ने मानचित्र को साफ़ कहा, और एक EDI विशेषज्ञ ने उस अंतर को पकड़ लिया।

भले ही संदर्भ डेटा गलत हो सकता है। एक मानक फ़ाइल जिसने दावा किया था कि वह क्रॉस‑चेक की गई है, वह हमारे द्वारा परीक्षण किए गए प्रत्येक विवादित खंड पर प्रकाशित मानक से असहमत थी।

सबक यह है कि एक आंशिक परिणाम को देखना एक गायब परिणाम से अधिक कठिन हो सकता है। सत्यापन को वास्तविक दस्तावेज़ के प्रत्येक फ़ील्ड की तुलना मानचित्र द्वारा कैप्चर किए गए से करनी चाहिए। यह पुष्टि करना कि दस्तावेज़ पार्स हो रहा है, पर्याप्त नहीं है। 

विश्वसनीय परिणाम मॉडल के आसपास के अनुशासन पर निर्भर करते हैं, चाहे वह उपयोग का तरीका हो या उसके आउटपुट की समीक्षा का तरीका।

मूल्य AI के निर्णय लेने से पहले शुरू होता है

इन्फ्रास्ट्रक्चर कार्य का मूल्य AI एजेंट के संचालन संबंधी सिफ़ारिशें देने से बहुत पहले ही होता है। एक 3PL जिसके साथ हमने काम किया, वह अपने वेयरहाउस सिस्टम के साथ SAP चलाता था। प्रत्येक इनबाउंड रिसीट को मैन्युअल रूप से दर्ज करने में तीन से पाँच मिनट लगते थे, और SAP में इन्वेंट्री डॉक से लगभग 20 मिनट पीछे चल रही थी।

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

उस परियोजना से हमने जो सबक सीखा वह श्रम बचत से अधिक था। जब दो सिस्टम एक ही वर्तमान चित्र साझा करते हैं, तो वही चित्र AI एजेंट को उपयोगी बनने के लिए आवश्यक होता है।

उन्हें जोड़ना वह कदम है जो उसके बाद सब कुछ संभव बनाता है। 

AI की तैयारी एकीकरण से शुरू होती है

शुरुआत कहां से करनी है यह तय करने वाली कंपनियों के लिए, एकीकरण को पहले आना चाहिए, जिसमें AI एकीकरण कार्य का अधिकांश हिस्सा करता है। अक्सर संचालन की गलती यह होती है कि वे AI को केवल प्रक्रिया के अंत में ही रखने वाला मानते हैं। यह शुरुआत में एकीकरण कार्य को तेज़ और कम खर्चीला बनाने में मदद कर सकता है, फिर निर्णय लेने में मदद करता है एक बार वह बुनियाद स्थापित हो जाए। 

मिड‑मार्केट लॉजिस्टिक्स कंपनियों को अनिवार्य रूप से अधिक प्रौद्योगिकी की आवश्यकता नहीं है। कई कंपनियों के पास पहले से ही आवश्यक सिस्टम हैं। अवसर यह है कि इन सिस्टमों को एक साथ काम करने के लिए तैयार किया जाए। यही वह जगह है जहाँ AI एक ऐसी भूमिका निभा सकता है जो स्क्रीन पर एक और उत्तर उत्पन्न करने से आगे जाती है। 

Suresh Chappidi SC Codeworks के अध्यक्ष एवं CEO हैं, जहाँ वह एक सिद्धांत पर सॉफ़्टवेयर बनाते हैं: कृत्रिम बुद्धिमत्ता को उत्पाद बनना चाहिए, न कि किसी फीचर के रूप में जोड़ा गया हो।