सामग्री प्रबंधन में उत्पाद का वजन दर्ज किया जाता है। सूत्रीकरण प्रणाली में पुनर्नवीनीकृत सामग्री का अनुपात दर्ज किया जाता है। आपूर्तिकर्ता का प्रमाणपत्र नेटवर्क ड्राइव पर पीडीएफ के रूप में संग्रहीत किया जाता है। उत्पाद पासपोर्ट के लिए इन तीनों सूचनाओं को एक ही डेटा रिकॉर्ड में शामिल करना आवश्यक है, और यही एकीकरण परियोजना का मुख्य उद्देश्य है - केवल दो प्रणालियों को जोड़ना नहीं।
‘निर्बाध ईआरपी एकीकरण’ एक मानक वादा है, जिसके बाद व्यवहार में एक तीन महीने की परियोजना होती है। हम अपनी गाइड प्रकाशित कर रहे हैं ताकि आपका आईटी विभाग अनुबंध पर हस्ताक्षर करने से पहले यह जांच सके कि वास्तव में किस डेटा की आवश्यकता है। यह लेख समझाता है कि पासपोर्ट को आपकी प्रणालियों से किस डेटा की आवश्यकता है, वे तीन तरीके जिनसे यह हमें भेजा जाता है, और यह दो सप्ताह में क्यों हासिल किया जा सकता है।
आपकी ईआरपी प्रणाली को वास्तव में क्या प्रदान करने की आवश्यकता है
डीपीपी बनाने के लिए, हमें प्रत्येक उत्पाद के लिए निम्नलिखित की आवश्यकता है:
- मास्टर डेटा - आइटम नंबर, विवरण, वेरिएंट, वजन, आयाम, छवियां
- बिल ऑफ मटेरियल्स डेटा - मात्राओं और पुनर्नवीनीकरण सामग्री के साथ घटक
- उत्पत्ति डेटा - उत्पादन स्थल, बैच संख्या, उत्पादन तिथि
- पर्यावरणीय डेटा - प्रति इकाई CO₂ समतुल्य, जल खपत, ऊर्जा खपत
- आपूर्तिकर्ता डेटा - कौन कौन सा घटक आपूर्ति करता है (उचित परिश्रम आवश्यकताओं के लिए)
सिद्धांत रूप में, यह सारा डेटा आपके ईआरपी सिस्टम में उपलब्ध है। हालाँकि, व्यवहार में, यह 4 से 7 मॉड्यूलों में फैला हुआ है: सामग्री प्रबंधन, उत्पादन, गुणवत्ता, आपूर्तिकर्ता मास्टर डेटा, कभी-कभी पर्यावरणीय डेटा के लिए एक अलग मॉड्यूल, और कभी-कभी फॉर्मूलेशन और बिल ऑफ मटेरियल्स के लिए एक समर्पित सिस्टम।
एकीकरण के संबंध में प्रश्न यह नहीं है: ‘क्या आपका ERP एक DPP को डेटा प्रदान करता है?’ यह है: ‘आप पाँच सबसिस्टमों से डेटा को एक सुसंगत डेटासेट में कैसे एक साथ लाते हैं?’
तीन आजमाए हुए और परखे हुए दृष्टिकोण
दृष्टिकोण 1: ERP से डेटा प्राप्त करना
आधुनिक ईआरपी (SAP S/4HANA Cloud, Dynamics 365, Odoo) के साथ अच्छी तरह से काम करता है। डीपीपी प्रदाता ईआरपी के इंटरफ़ेस (तकनीकी रूप से OData या REST) के माध्यम से डेटा प्राप्त करता है। केवल परिवर्तन प्राप्त किए जाते हैं, या तो निर्धारित आधार पर या किसी घटना द्वारा ट्रिगर किए जाते हैं।
फायदे: आपके हिस्से पर न्यूनतम विकास की आवश्यकता; आप रीड एक्सेस प्रदान करते हैं, और प्रदाता रूपांतरण को संभालता है।
नुकसान: एक अतिरिक्त इंटरफ़ेस परत के बिना पुराने SAP ECC इंस्टॉलेशन के साथ काम नहीं करता है। आपको यह नियंत्रित करने वाले स्पष्ट नियमों की आवश्यकता है कि कौन किस डेटा को पढ़ने के लिए अधिकृत है।
विकल्प 2: बदलाव अग्रेषित करें
आपका ईआरपी हर बदलाव को एक इवेंट के रूप में रिपोर्ट करता है (SAP इवेंट मेष, अपाचे काफ़्का या रैबिटएमक्यू के माध्यम से), और DPP प्रदाता उन्हें प्राप्त करता है।
फ़ायदे: लगभग वास्तविक समय में, आपके व्यवसाय के साथ बढ़ता है, सिस्टम एक-दूसरे पर निर्भर नहीं होते हैं।
अनुपात: सेट-अप जटिल है और इसके लिए ऐसे बुनियादी ढांचे की आवश्यकता होती है जो हर आईटी विभाग के पास नहीं होता है। आमतौर पर छोटी कंपनियों के लिए यह अत्यधिक होता है।
विकल्प 3: मौजूदा इंटीग्रेशन लेयर का उपयोग करें
ERP और बाहरी सिस्टम के बीच आपके पास पहले से ही एक इंटीग्रेशन लेयर (म्यूल्सॉफ्ट, बूमी, इन्फॉर्मेटिका, एज़्योर डेटा फैक्ट्री) है। यह लेयर मध्यस्थ के रूप में कार्य करती है: DPP प्रदाता इसके साथ संवाद करता है, कभी भी सीधे ERP के साथ नहीं।
फायदे: मौजूदा निवेश का उपयोग किया जा सकता है, नियम स्थिर रहते हैं, और तीसरे पक्षों के लिए सीधी ERP पहुंच नहीं होती है।
नुकसान: एकीकरण परत के लिए आपके खर्च उसी के अनुसार बढ़ जाते हैं।
विशिष्ट परियोजनाओं में हम क्या अलग करते हैं
कई प्रदाता सीधे आपके ERP से जुड़ना चाहते हैं। हम हमेशा एक मध्यवर्ती चरण शामिल करते हैं: हमारा इंटरफ़ेस एक तटस्थ डेटा प्रारूप (एक JSON स्कीमा) स्वीकार करता है, जिसे आप अपनी पसंद के किसी टूल का उपयोग करके भरते हैं। इसका मतलब है:
- आप स्वयं डेटा तैयार कर सकते हैं, उन टूल का उपयोग करके जिनसे आपकी टीम परिचित है
- आप प्रदाताओं को बदल सकते हैं - तटस्थ प्रारूप पोर्टेबल है
- आप किसी भी समय अपना पूरा डेटा सेट प्राप्त कर सकते हैं - CSV, XLSX, JSON-LD और SQL के रूप में, साथ ही REST API के माध्यम से भी
- हम एक आयात सत्यापनकर्ता प्रदान करते हैं जो अपलोड से पहले आपके डेटा की जाँच करता है
पूरा फ़ॉर्मेट और सभी क्वेरीज़, OpenAPI के अनुसार एक इंटरफ़ेस विवरण के रूप में, API दस्तावेज़ीकरण में सार्वजनिक रूप से प्रलेखित हैं। आपकी आईटी टीम अनुबंध पर हस्ताक्षर करने से पहले इंटरफ़ेस की समीक्षा कर सकती है - जिसमें नमूना अनुरोध, त्रुटि प्रतिक्रियाएं और प्रमाणीकरण विवरण शामिल हैं।
व्यावहारिक रूप से इस दृष्टिकोण के लिए समयरेखा:
- दिन 1 से 2: मैपिंग कार्यशाला। कौन सा ERP फ़ील्ड किस DPP फ़ील्ड के अनुरूप है?
- दिन 3 से 5: ERP से प्रारंभिक JSON एक्सपोर्ट, हमारे वैलिडेटर द्वारा जाँचा गया।
- दिन 6 से 8: समस्या निवारण (गायब फ़ील्ड, असंगत कोडिंग)।
- दिन 9 से 10: पहले DPPs लाइव होते हैं।
दो सप्ताह, तीन महीने नहीं। मामले का सार मैपिंग कार्यशाला है - यहीं पर डेटा की गुणवत्ता निर्धारित होती है।
क्या गलत होता है: सबसे आम समस्याएँ
कई सिस्टमों में उत्पाद मास्टर डेटा: SAP के पास आइटम नंबर है, PIM के पास छवियां और मार्केटिंग टेक्स्ट हैं, PLM के पास बिल ऑफ मटेरियल्स है। किसी के पास भी एक सुसंगत अवलोकन नहीं है। समाधान: परियोजना शुरू होने से पहले, यह परिभाषित करें कि प्रत्येक फ़ील्ड के लिए कौन सा सिस्टम प्राथमिक स्रोत है।
पीडीएफ के रूप में प्रमाण पत्र: आपूर्तिकर्ता GOTS, OEKO-TEX या REACH प्रमाण पत्र स्कैन किए गए पीडीएफ के रूप में प्रदान करते हैं। यह एक संरचित डेटा स्रोत नहीं है। समाधान: प्रमाणन निकाय इंटरफ़ेस के माध्यम से डेटा प्राप्त करने का विकल्प तेजी से दे रहे हैं (OEKO-TEX इस क्षेत्र में अग्रणी है, जबकि GOTS पीछे रह रहा है)। वैकल्पिक रूप से, डेटा को मैन्युअल रूप से दर्ज करें, लेकिन यह सुनिश्चित करने के लिए समाप्ति तिथि शामिल करें कि DPP में कोई भी समाप्त हो चुके प्रमाणपत्र न दिखाई दें।
फॉर्मूलेशन गोपनीयता: विशेष रूप से कॉस्मेटिक्स, खाद्य और फार्मास्यूटिकल्स में, पूरा फॉर्मूलेशन एक व्यापार रहस्य होता है। क्या DPP को उन्हें सार्वजनिक करना चाहिए? समाधान: ESPR का तीन-स्तरीय मॉडल। उत्पाद श्रेणी सार्वजनिक रूप से उपलब्ध है; नियामक प्राधिकरण पूरी फॉर्मूलेशन देख सकते हैं। यह शायद ही कभी कोई बाधा होती है, लेकिन इसे शुरुआती चरण में स्पष्ट किया जाना चाहिए।
आपूर्तिकर्ता के आधार पर CO₂ डेटा: आपका आपूर्तिकर्ता अपने पूरे पोर्टफोलियो के लिए एक औसत मान प्रदान करता है, न कि प्रति बैच। समाधान: इसे अस्थायी रूप से स्वीकार करें; दीर्घकाल में आपूर्तिकर्ता अनुबंधों को समायोजित करें। ESPR को एक विशिष्ट कट-ऑफ तिथि से उत्पाद-विशिष्ट मानों की आवश्यकता है, लेकिन वर्तमान प्रथा एक समझौता है।
स्थानीय भाषा संस्करण: आपके ईआरपी सिस्टम में केवल जर्मन और अंग्रेजी में उत्पाद का नाम होता है। 27 ईयू देशों के लिए, आपको और अधिक की आवश्यकता है। समाधान: एक शब्दावली डेटाबेस का उपयोग करके मशीन अनुवाद; इस पर हमारा एक अलग लेख है।
परियोजना से पहले पूछे जाने वाले प्रश्न
तीन आपूर्तिकर्ताओं को RFP भेजने से पहले, आंतरिक रूप से निम्नलिखित प्रश्नों का उत्तर दें:
- कितने उत्पादों/आइटम नंबरों के पास DPPs होने चाहिए? (10, 10,000, 10 लाख?)
- वर्तमान में कौन से सिस्टम DPP-संबंधी डेटा रखते हैं?
- इनमें से प्रत्येक सिस्टम का प्रबंधन कौन सा विभाग करता है?
- क्या आपके पास कोई इंटीग्रेशन लेयर है जिसका उपयोग किया जाना चाहिए?
- क्या आपके ERP के माध्यम से पहले से ही कोई इंटरफ़ेस संचालित हो रहा है?
उत्तर यह निर्धारित करेंगे कि तीन में से कौन सा दृष्टिकोण आपके लिए सही है।
उत्तर यह निर्धारित करेंगे कि किसी परियोजना में दो सप्ताह लगते हैं या छह महीने।
इस पोस्ट के बारे में प्रश्न
क्या REST इंटरफ़ेस पर्याप्त है, या हमें मिडलवेयर की आवश्यकता है?
इंटरफ़ेस पर्याप्त है। ये तीन पैटर्न इस बात में भिन्न हैं कि रूपांतरण कहाँ होता है, न कि इस बात में कि हम क्या स्वीकार करते हैं - हमारा इंटरफ़ेस एक तटस्थ JSON स्कीमा स्वीकार करता है, चाहे आपने इसे किसी भी तरह से उत्पन्न किया हो। एक आधुनिक ERP सिस्टम से पुल, एक इवेंट स्ट्रीम और एक मौजूदा इंटीग्रेशन लेयर सभी एक ही एंडपॉइंट पर समाप्त होते हैं। यदि आप पहले से ही कुछ मिडलवेयर चला रहे हैं और चाहते हैं कि यह तीसरे पक्षों के साथ संविदात्मक इंटरफ़ेस बना रहे, तो इसका उपयोग करना उचित है। यदि आपके पास वर्तमान में कोई मिडलवेयर नहीं है, तो केवल उत्पाद पासपोर्ट के लिए कोई मिडलवेयर न खरीदें।
मैपिंग कार्यशाला में क्या निर्णय लिया जाएगा?
कौन सा ERP क्षेत्र किस मास्टर डेटा क्षेत्र से मेल खाता है - और जब कई प्रणालियाँ एक ही मान रखती हैं तो कौन सी प्रणाली प्रामाणिक स्रोत है। कार्यशाला दिन 1 और 2 को आयोजित की जाती है और यह पूरे परियोजना का मूल है, क्योंकि डेटा गुणवत्ता पर निर्णय वहीं लिए जाते हैं, कोड में बाद में नहीं। सुनिश्चित करें कि आप केवल परियोजना के प्रभारी लोगों को ही नहीं बल्कि उन लोगों को भी साथ लाएँ जो सिस्टम का रखरखाव करते हैं - मास्टर डेटा, उत्पादन, गुणवत्ता और खरीद शायद ही कभी एक ही विभाग में होते हैं। इसके बाद जो कुछ भी आता है - निर्यात, सत्यापन और समस्या निवारण - वह केवल तकनीकी विशेषज्ञता का मामला है।
हमारे प्रमाणपत्र केवल PDF स्कैन के रूप में उपलब्ध हैं। हमें इनके साथ क्या करना चाहिए?
एक स्कैन संरचित डेटा स्रोत नहीं है और इसलिए पासपोर्ट के लिए अनुपयोगी है। आगे बढ़ने के दो तरीके हैं - प्रमाणन प्राधिकरण तेजी से API क्वेरीज़ प्रदान कर रहे हैं, और जहाँ ये उपलब्ध नहीं हैं, वहाँ मानों को मैन्युअल रूप से दर्ज करें, लेकिन हमेशा समाप्ति तिथि शामिल करें ताकि यह सुनिश्चित हो सके कि प्रकाशित पासपोर्ट में कोई भी समाप्त हो चुका प्रमाणपत्र न रहे। मैन्युअल प्रक्रिया को एक बार का काम न मानकर, एक आवर्ती कार्य के रूप में लें।
क्या हमारा आईटी विभाग कुछ भी साइन करने से पहले इंटरफ़ेस की जांच कर सकता है?
हाँ। संपूर्ण स्कीमा और सभी एंडपॉइंट्स API दस्तावेज़ीकरण में OpenAPI स्पेसिफिकेशन के रूप में उपलब्ध हैं, साथ ही नमूना अनुरोध, त्रुटि प्रतिक्रियाएँ और प्रमाणीकरण विवरण भी दिए गए हैं। इनमें से कोई भी बिक्री चर्चा के अधीन नहीं है, इसलिए आपकी इंटीग्रेशन टीम अनुबंध होने से पहले इसमें शामिल प्रयास का आकलन कर सकती है। यदि कोई प्रदाता इस चरण में अपनी API का खुलासा नहीं करता है, तो यह स्वयं एक उत्तर है।
जब हम प्रदाता बदलते हैं तो हमारे डेटा का क्या होता है?
वे शामिल हैं। इंटरफ़ेस एक स्वामित्व वाले प्रारूप के बजाय तटस्थ JSON स्कीमा स्वीकार करता है, और आपका संपूर्ण डेटा सेट CSV, XLSX, JSON-LD और SQL के रूप में या REST API के माध्यम से आउटपुट होता है। यह जानबूझकर किया गया है - आप जो प्रारूप भरते हैं वह पोर्टेबल होता है, इसलिए प्रदाताओं को बदलने के लिए सब कुछ शून्य से फिर से बनाने के बजाय केवल एक्सपोर्ट करना होता है। मैपिंग कार्यशाला से पहले हर प्रदाता से यही सवाल पूछें, क्योंकि तब आपके फील्ड नाम उनके मॉडल में शामिल हो जाएंगे।
वास्तव में कनेक्शन स्थापित करने में कितना समय लगता है?
हम जिन परियोजनाओं का समर्थन करते हैं, उनमें प्रक्रिया में दो सप्ताह लगते हैं: दो दिन मैपिंग के लिए, हमारे वैलिडेटर के माध्यम से पहली एक्सपोर्ट्स तक तीन दिन, समस्या निवारण के लिए तीन दिन, और पहले पासपोर्ट प्रकाशित होने तक दो दिन। लंबी अवधि कभी कोड स्वयं नहीं होती, बल्कि वैलिडेटर जो उजागर करता है - गायब फ़ील्ड्स, असंगत कोडिंग, और ऐसे मान जिनकी जिम्मेदारी कोई नहीं लेता। इन दिनों को छोटा करने के बजाय इन्हें अवश्य शामिल करें। जो प्रोजेक्ट इन्हें छोड़ देता है, वह अंततः इन खामियों को भी प्रकाशित कर देगा।
क्या हमें सभी उत्पादों को एक साथ लिंक करना होगा?
नहीं। पहले उन उत्पादों के साथ शुरू करें जिन्हें पास की आवश्यकता है, और एक स्रोत सिस्टम के साथ - न्यूट्रल स्कीमा आंशिक कैटलॉग को उतनी ही सहजता से स्वीकार करता है जितना कि पूर्ण कैटलॉग को, और इम्पोर्ट्स दोहराए जा सकते हैं, इसलिए बाद के रन इन्वेंटरी को अपडेट कर देंगे। यह मैपिंग कार्यशाला को दो दिनों में पूरा करने के लिए पर्याप्त छोटा रखता है। बाद में इसका विस्तार करना एक मैपिंग कार्य है, नया प्रोजेक्ट नहीं।
