एआई की तैयारी भरोसेमंद उत्पाद डेटा से शुरू होती है

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

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

जब कंपनियाँ उद्यम प्रणालियों का आधुनिकीकरण करती हैं और उत्पाद जीवनचक्र प्रबंधन (PLM), उद्यम संसाधन नियोजन (ERP), कॉन्फ़िगर-प्राइस-क्वोट (CPQ) और सेवा प्लेटफ़ॉर्म को जोड़ती हैं, तो विन्यास तर्क में मौजूद विसंगतियाँ चुपचाप आगे की प्रक्रियाओं की सटीकता और एआई-आधारित सुझावों की प्रभावशीलता को कमज़ोर कर सकती हैं। भरोसेमंद विन्यास तर्क न हो, तो एआई निर्णयों को बेहतर बनाने के बजाय गलतियों को तेज़ी से बढ़ाता है।

उत्पाद विन्यास छिपी हुई बुनियाद क्यों है

आज निर्माता ऐसे परस्पर जुड़े तंत्र पर लगातार अधिक निर्भर हो रहे हैं, जिसमें PLM, ERP, CPQ, विनिर्माण और सेवा शामिल हैं। उत्पाद विन्यास उस जोड़ने वाली कड़ी का काम करता है, जो इंजीनियरिंग की मंशा को विनिर्माण, बिक्री, मूल्य निर्धारण और सेवा की आवश्यकताओं में ढालता है।

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

पुराने नियमों से पैदा होता अदृश्य जोखिम

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

उद्यम के आधुनिकीकरण की परियोजनाएँ, जैसे SAP S/4HANA में माइग्रेशन, आम तौर पर अनुप्रयोगों, बुनियादी ढाँचे और कस्टम कोड पर ज़ोर देती हैं, जबकि विन्यास तर्क को गौण मानती हैं। इससे एक जोखिम नज़रअंदाज़ हो जाता है: प्रणालियाँ सफलतापूर्वक माइग्रेट हो सकती हैं, लेकिन विन्यास का व्यवहार सूक्ष्म तरीक़ों से बदल सकता है, जिन्हें पारंपरिक परीक्षण से पकड़ना मुश्किल होता है।

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

यह सिर्फ़ भ्रम की स्थिति नहीं है; विन्यास तर्क में गड़बड़ी व्यावसायिक समस्या बन जाती है। विफलता के दो प्रकार हैं और दोनों महँगे पड़ते हैं:

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

पहली तरह की विफलता का पता अंततः कारखाने के फ़र्श पर चल जाता है। दूसरी चुपचाप होती है; ऑर्डर बुक में ऐसी कोई बिक्री दर्ज नहीं होती जिसे विन्यास प्रणाली ने कभी होने ही नहीं दिया।

सत्यापन एक रणनीतिक क्षमता बनता जा रहा है

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

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

इसमें शामिल पैमाने को सटीक रूप से समझना ज़रूरी है। 30 चर वाले किसी मॉडल में, जहाँ हर चर के लिए पाँच विकल्प हों, लगभग 10²¹ संयोजन संभव होते हैं—पृथ्वी पर रेत के कणों की अनुमानित संख्या से कहीं ज़्यादा; और वास्तविक औद्योगिक मॉडल इससे काफ़ी बड़े होते हैं। यूज़र इंटरफ़ेस पर क्लिक करके कोई भी कितने ही लोग इस पूरे दायरे की जाँच नहीं कर सकते; गणित इसकी अनुमति नहीं देता।

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

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

AI को नियतात्मक इंजन के ऊपर होना चाहिए, उसकी जगह नहीं लेनी चाहिए

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

विश्वसनीय डेटा ही AI कार्यक्रमों की सफलता का आधार है

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

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