ERP इंटीग्रेशन: SAP, Oracle, Dynamics में किस डेटा का मालिक कौन?

सेल्स एक सीधा-सा सवाल पूछता है: ऑर्डर 4711 का कितना बनाना बाक़ी है? ERP कहता है 320। प्लानर का शेड्यूल कहता है 308। शॉप फ़्लोर कहता है “हो गया”। तीन सिस्टम, तीन जवाब, और हर जवाब अपने नियमों के हिसाब से सही है। ERP इंटीग्रेशन को यही समस्या हल करनी होती है।

प्रोडक्शन प्लानिंग के लिए ERP इंटीग्रेशन का मतलब है अपने ERP सिस्टम (SAP, Oracle, Microsoft Dynamics 365 या कोई और) को उस टूल से जोड़ना जो प्रोडक्शन की प्लानिंग और शेड्यूलिंग करता है, ताकि ऑर्डर, स्टॉक और कन्फ़र्मेशन का मतलब दोनों में एक ही हो। मुश्किल हिस्सा शायद ही कभी तकनीकी कनेक्शन होता है। मुश्किल यह तय करना है कि कौन-सा सिस्टम किस डेटा का मालिक है, और हर संख्या का मतलब क्या है।

एक ऑर्डर, तीन जवाब

ऑर्डर 4711 में 500 अच्छी यूनिट चाहिए। अब तक मशीन 192 यूनिट प्रोसेस कर चुकी है: 180 अच्छी और 12 स्क्रैप।

• ERP अच्छी यूनिट घटाता है: 500 − 180 = 320 बाक़ी।
• प्लानिंग टूल ने मशीन से गुज़री हर चीज़ घटाई: 500 − 192 = 308 बाक़ी।
• शॉप फ़्लोर को इस हफ़्ते के 192 के रन का जॉब ऑर्डर मिला था। वह रन पूरा हो गया, इसलिए उनके लिए काम हो गया।

किसी ने टाइपिंग की ग़लती नहीं की। सब “बाक़ी” की अलग-अलग परिभाषा इस्तेमाल करते हैं। इंटीग्रेशन की शुरुआत इन्हीं परिभाषाओं पर सहमति से होती है, किसी एक फ़ील्ड को मैप करने से भी पहले।

एक पार्शियल कन्फ़र्मेशन, दोनों सिस्टमों में

100 ब्रैकेट के एक प्रोडक्शन ऑर्डर में तीन ऑपरेशन हैं: 10 कटिंग, 20 वेल्डिंग, 30 पेंटिंग। वेल्डर ऑपरेशन 20 पर 60 अच्छे पीस कन्फ़र्म करता है और घर चला जाता है।

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

अब दो चीज़ें जो असल ज़िंदगी में ग़लत होती हैं।

मैसेज दो बार चला जाता है। नेटवर्क में ज़रा-सी गड़बड़ी, एक री-ट्राई, और ERP में 100 में से 120 वेल्ड हुए दिखते हैं। हर कन्फ़र्मेशन को एक यूनिक ID चाहिए, ताकि पाने वाला सिस्टम डुप्लिकेट पहचानकर उसे नज़रअंदाज़ कर सके।

गिनती सुधारी जाती है। अगली सुबह इंस्पेक्शन में 60 में से 5 वेल्ड ख़राब निकलते हैं। कन्फ़र्मेशन अब 55 अच्छे और 5 स्क्रैप हो जाता है, यानी अब भी 45 चाहिए, 40 नहीं। किसी को तय करना होगा कि 5 पीस और काटे जाएँ या कस्टमर 95 ले। यह फ़ैसला इंसान का है, इंटरफ़ेस का नहीं।

माँगी गई, कैलकुलेट की गई और वादा की गई तारीख़

ज़्यादातर ऑर्डरों में तीन तारीख़ें होती हैं, और इन्हें एक-दूसरे को ओवरराइट नहीं करना चाहिए:

• माँगी गई (requested): कस्टमर ने जो माँगा, 10 मार्च। यह तभी बदलती है जब कस्टमर इसे बदले।
• कैलकुलेट की गई (calculated): प्लानिंग टूल के हिसाब से जो मुमकिन है, 14 मार्च। यह हर शेड्यूल रन के साथ बदल सकती है।
• वादा की गई (promised): कैलकुलेट की गई तारीख़ देखकर सेल्स ने जो कन्फ़र्म किया, 15 मार्च। यह तभी बदलती है जब कोई दोबारा वादा करने का फ़ैसला करे।

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

ERP इंटीग्रेशन में कौन किस डेटा का मालिक है

नियम: हर फ़ील्ड का ठीक एक मालिक होता है, यानी वह इकलौता सिस्टम जिसे उसे बदलने की इजाज़त है। दूसरा सिस्टम उसे सिर्फ़ पढ़ता है। एक आम बँटवारा:

आपका बँटवारा अलग हो सकता है। ज़रूरी यह है कि वह लिखा हुआ हो।

दो रसोइयों के बारे में सोचिए जो एक ही दाल में नमक डाल रहे हैं। दोनों चखते हैं, फीकी लगती है, नमक डाल देते हैं। दोनों ने समझदारी से काम किया। दाल बिगड़ गई। दो मालिकों वाले डेटा का भी यही हाल होता है।

मिथक: “अच्छा इंटीग्रेशन सब कुछ, दोनों तरफ़, रियल टाइम में सिंक करता है”

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

SAP, Oracle, Dynamics: सवाल वही

इनमें से कुछ भी ब्रांड पर निर्भर नहीं है। SAP, Oracle या Microsoft Dynamics 365, किसी के साथ भी आपको तय करना होगा कि “बाक़ी” का मतलब क्या है, कौन-सी तारीख़ कौन-सी है, और हर फ़ील्ड का मालिक कौन है। फ़ील्ड मैपिंग सिस्टम और कॉन्फ़िगरेशन के हिसाब से अलग होती है, इसलिए पहले मालिकाना तय कीजिए। अलग प्लानिंग लेयर की ज़रूरत ही क्यों पड़ती है, यह ERP को हर ऑर्डर 10 दिन का क्यों लगता है में समझाया गया है।

factory.online कैसे मदद करता है

factory.online का SAP और Microsoft Dynamics 365 के साथ इंटीग्रेशन है। अगर आप Oracle या कोई दूसरा ERP चलाते हैं, तो पूछिए कि आपके सेटअप के लिए कनेक्शन में क्या-क्या लगेगा। factory.online के अंदर प्लानर हर मैन्युफ़ैक्चरिंग ऑर्डर को उसके जॉब ऑर्डरों और हर ऑपरेशन के अच्छे व स्क्रैप कन्फ़र्मेशन के साथ देखता है, इसलिए वेल्ड हुए 60 ब्रैकेट और बाक़ी 40, दोनों कस्टमर ऑर्डर से जुड़े हुए दिखते हैं। बने हुए बैच अपना इतिहास रखते हैं, जो बैच ट्रेसेबिलिटी के लिए ज़रूरी है।

अगर आपका ERP, आपका प्लानर और आपका शॉप फ़्लोर तीन अलग जवाब देते हैं, तो डेमो बुक करें, और हम मिलकर ऐसे किसी एक ऑर्डर को ट्रेस करेंगे।