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