कई फैक्ट्रियों में कस्टम सॉफ्टवेयर प्रोजेक्ट कोडिंग में ही नहीं, बल्कि “डिमांड स्पष्ट नहीं होने, रेंज लगातार बदलने, और लॉन्च होने पर कोई मानने में” ही विफल हो जाता है। सेल्स टीम कहती है कि ऑपरेशन की प्रगति दिखानी है, वर्कशॉप कहता है कि री-एसाइनमेंट की सुविधा चाहिए, फाइनेंस टीम कहती है कि वर्कऑर्डर कॉस्ट से अनुरूप होना चाहिए, और IT कहता है कि इंटरफ़ेस लिस्ट अभी फ्रीज़ नहीं हुई है। तीन महीने बाद जब सिस्टम लॉन्च होता है, तब भी फ़ील्ड में व्हाट्सऐप पर फ़ोटो और एक्सेल में वर्क रिपोर्ट भेजी जाती है। असली कमी फ़ंक्शन लिस्ट में नहीं, बल्कि रेंज फ्रीज़िंग, स्कीमा डिज़ाइन, डेवलपमेंट लैंडिंग से लेकर एक्सेप्टेंस तक के क्लोज्ड लूप के लिए एक्सेक्यूटेबल पाथ में है।
बिज़नेस प्रॉब्लम: आखिर क्यों “काम हो गया” है, लेकिन इस्तेमाल नहीं हो रहा है
डिस्क्रीट मैन्युफैक्चरिंग में आम परेशानियाँ ये हैं: वर्कऑर्डर ओपन है, लेकिन ऑपरेशन की प्रगति नहीं दिख रही; बैच लीडर मौखिक री-एसाइनमेंट करता है, लेकिन सिस्टम अभी भी पिछले स्टेशन पर रुका हुआ है; क्वालिटी कंट्रोल फ़ेल हो जाता है, पेपर बेस्ड क्लोज़ लूप बनता है, और कॉस्ट अकाउंटिंग अनुरूप नहीं होती। बॉस सॉफ्टवेयर खरीदते हैं ताकि रियल WIP (वर्क-इन-प्रोग्रेस) देख सकें, लेकिन अगर डिलीवरी पार्टी “मॉड्यूल लिस्ट” के आधार पर कोट करती है, तो बोर्ड, वर्क रिपोर्ट, स्टॉक और कॉस्ट को एक ही फ़ेज़ में शामिल कर देती है, जिससे रेंज इतनी बढ़ जाती है कि एक्सेप्टेंस ही नहीं हो पाती।
एक और तरह की विफलता यह है कि इंटरव्यू नोट्स को डिमांड स्पेसिफ़िकेशन समझ लिया जाता है । नोट्स में लिखा है “प्रगति देखनी है”, लेकिन यह स्पष्ट नहीं किया गया कि किस वर्क रिपोर्ट के आधार पर प्रगति देखी जाए, रीवर्क कैसे रिकॉर्ड किया जाए, और किस बैच के लिए री-एसाइनमेंट का अधिकार है। डेवलपर्स ने शब्दों के अनुसार लिस्ट पेज बनाया, लेकिन फ़ील्ड में इस्तेमाल करते ही यह फ़्रीज़ हो गया। सॉफ्टवेयर जो कुछ भी हल कर सकता है, वह इन नियमों को एक्सेक्यूटेबल स्टेट मशीन और परमिशन में बदलना है; जो हल नहीं कर सकता, वह है इस बात की संगठनात्मक तैयारी नहीं कि नियमों को फ्रीज़ किया जाए।
एक और अदृश्य लागत है: लंबे समय तक पैरेलल ड्यूअल ट्रैक चलना। पुराना एक्सेल चलता रहता है, नया सिस्टम पूरा नहीं होता, फ़ील्ड में सबसे आसान रास्ता चुना जाता है, सिस्टम का डेटा दिन-ब-दिन गंदा होता जाता है, और अंततः यह तय किया जाता है कि “सिस्टम अच्छा नहीं है”। ड्यूअल ट्रैक हो सकता है, लेकिन इसके लिए पुराने टेबल को बंद करने की तारीख और अकाउंटिंग रूल्स स्पष्ट रूप से लिखना जरूरी है, वरना लॉन्च करना सिर्फ एक और डिस्प्ले सिस्टम की तरह होगा।
- रेंज क्लीयर नहीं: फ़ेज़ 1 का लक्ष्य “पूरी डिजिटलाइज़ेशन” बन गया है।
- कलेक्शन का ब्रेक पॉइंट: प्रगति अभी भी मौखिक है, सिस्टम सिर्फ डिस्प्ले लेयर है।
- एक्सेप्टेंस का डिसलोकेशन: मेनू के आधार पर चेक किया जाता है, बिज़नेस रिज़ल्ट के आधार पर नहीं।
- ड्यूअल ट्रैक का अनकंट्रोल: पुराना टेबल चलता रहता है, नए डेटा का कोई मालिक नहीं है।
बिज़नेस को कैसे डिवाइड करें: पहले फ़ेज़ के वेरिफ़ाबल रिज़ल्ट्स को फ्रीज़ करें
सुझाव है कि फ़ेज़ 1 को एक मापनीय रिज़ल्ट पर फ़िक्स कर दें, जैसे “क्रिटिकल ऑपरेशन की वर्क रिपोर्ट डिले अधिकतम 30 मिनट तक, और प्लानर वर्कऑर्डर के अनुसार सेट और ब्लॉकेज के कारणों को देख सके”। बाकी स्टॉक डीप ऑप्टिमाइज़ेशन, कॉस्ट अलोकेशन और BI कैबिन फ़ेज़ 2 में रख दें। बिज़नेस डिवाइडिंग चार चेन्स के आधार पर की जा सकती है:
- वर्कऑर्डर चेन : ERP/MES से वर्कऑर्डर और ऑपरेशन डेफ़िनेशन लें, मेन डेटा के जिम्मेदार को स्पष्ट करें।
- वर्क रिपोर्ट चेन : कौन, कब, किस तरह स्कैन/क्लिक करके वर्क रिपोर्ट, रीवर्क, पॉज़ करता है।
- एनोमली चेन : मटेरियल की कमी, इक्विपमेंट का बंद होना, क्वालिटी का फ़्रीज़ होना आदि कैसे डाउनस्ट्रीम को ब्लॉक करते हैं।
- अकाउंटिंग चेन : डेली क्लीयरेंस के समय, सिस्टम प्रगति और फ़ील्ड इन्वेंट्री के बीच का अंतर कैसे समझाया जाए।
हर चेन के लिए स्पष्ट रूप से लिखें ट्रिगर इवेंट्स, जिम्मेदार रोल्स, टाइमआउट अपग्रेड । जो लिखा नहीं जा सकता, वह बताता है कि बिज़नेस अभी सिस्टम पर जाने के लिए तैयार नहीं है, इसलिए पहले इंस्टीट्यूशनल प्री-वार्मिंग करनी चाहिए, न कि डेवलपमेंट पर जोर देना। रेंज फ्रीज़िंग मीटिंग में सिग्नेचर डॉक्यूमेंट तैयार करना चाहिए: जो फ़ंक्शन फ़ेज़ 1 में हैं, उन्हें लिस्ट करें, जो नहीं हैं, उन्हें डिमांड पूल में डालें, बदलाव के लिए बदलाव ऑर्डर और टाइम एस्टीमेट लें।
कैसे डिज़ाइन करें: रोल्स, प्रोसेसेस, डेटा बाउंड्री
डिज़ाइन फ़ेज़ में तीन चीज़ें आउटपुट करनी चाहिए, न कि ढेर सारे वायरफ़्रेम्स: रोल मैट्रिक्स, स्टेट मशीन, इंटरफ़ेस कॉन्ट्रैक्ट। वायरफ़्रेम्स बाद में जोड़े जा सकते हैं, लेकिन जब तक पहले तीन चीज़ें नहीं हैं, कोई भी इंटरफ़ेस रिवर्क होगा।
रोल्स और परमिशन
कम से कम प्लानर, बैच लीडर, ऑपरेटर, क्वालिटी इंस्पेक्टर, स्टॉक मैनेजर और रीड-ओनली मैनेजमेंट को अलग करें। री-एसाइनमेंट और डिलीट के लिए डबल ट्रेस जरूरी है; ऑपरेटर सिर्फ अपने स्टेशन की रिपोर्ट करता है; प्लानर ब्लॉकेज पूल देखता है। परमिशन “पोस्ट+लाइन” के आधार पर बांधी जाती है, ताकि एक व्यक्ति का वन-मैन-अकाउंट न हो। अकाउंट और रिलीज़ के साथ ऑपरेशन वार्ड लिस्ट में जाना चाहिए, वरना परमिशन डेटा की विश्वसनीयता पर वापस आ सकता है।
प्रोसेसेस और स्टेट
ऑपरेशन इंस्टेंस स्टेट को सिंथेसाइज़ करने का सुझाव है: वेटिंग फॉर बिगिन, इन प्रोसेसिंग, वेटिंग फॉर इंस्पेक्शन, फ़िनिश्ड, रीवर्क, फ़्रीज़। स्टेट माइग्रेशन केवल लीगल बॉर्डर्स की अनुमति देता है; अनलीगल जंप के लिए रीज़न कोड लिखना जरूरी है। बोर्ड सिर्फ रीड-ओनली स्टेट मशीन का रिज़ल्ट देता है, वर्क रिपोर्ट के बिना स्टेट बदलने की अनुमति नहीं है। रीवर्क के लिए स्पष्ट रूप से बताना चाहिए कि किस ऑपरेशन पर वापस जाना है, और क्या सब-वर्कऑर्डर जनरेट हो रहा है, ताकि प्रगति “दिखती है, लेकिन असल में वापस आ रही है” से बचा जा सके।
डेटा और इंटरफ़ेस बाउंड्री
मेन डेटा (मटेरियल, प्रोसेस रूट, बैच) सोर्स सिस्टम द्वारा मेंटेन किया जाता है; एक्सीक्यूशन डेटा (वर्क रिपोर्ट, एनोमली) फ़ील्ड सिस्टम में जनरेट होता है। इंटरफ़ेस पोस्ट के आधार पर कट किया जाता है: ऑपरेटर तीन बटन से वर्क रिपोर्ट करता है, प्लानर ब्लॉकेज और सेट देखता है, मैनेजमेंट डिले डिस्ट्रीब्यूशन देखता है। ERP के सभी फ़ील्ड को वर्कशॉप टैबलेट पर न लाएं। जितने कम फ़ील्ड हों, उतना ही सटीक कलेक्शन होगा।
कैसे डेवलप और लैंड: इंटरफ़ेस, कलेक्शन, एक्सेप्टेंस
डेवलपमेंट ऑर्डर का सुझाव है: मेन डेटा सिंक → वर्क रिपोर्ट कलेक्शन → एनोमली ब्लॉकेज → वर्कऑर्डर के साथ अनुरूप क्वेरी → डेली क्लीयरेंस अकाउंटिंग रिपोर्ट। इंटरफ़ेस को प्रायोरिटी दें: वर्कऑर्डर बदलने के लिए वर्जन नंबर; वर्क रिपोर्ट के लिए बिज़नेस यूनिक की रोक दें। कलेक्शन एंड को वीक नेटवर्क के लिए एडैप्ट करें: लोकल लाइन, रिट्रांस और कंफ्लिक्ट अलर्ट। डिवाइस स्कैन और मैनुअल क्लिक एक साथ हो सकते हैं, लेकिन एक ही ऑपरेशन इंस्टेंस के लिए केवल एक “ऑथोरिटीव फ़िनिश इवेंट” हो सकता है।
यूनिटी टेस्टिंग के लिए “डर्टी डेटा स्क्रिप्ट” तैयार करना चाहिए: रिपीट स्कैन, नेटवर्क इंटरप्ट, वर्कऑर्डर के बीच में प्रोसेस बदलना, बैच री-एसाइनमेंट। ये विश्वसनीयता के लिए डिज़ाइन खामियों को ज़्यादा उजागर करते हैं। परफ़ॉर्मेंस के लिए, बोर्ड क्वेरी को लाइन के आधार पर ज़ोन करें, ताकि पूरे फ़ैक्ट्री की रियल-टाइम स्कैनिंग से बचा जा सके।
एक्सेप्टेंस को “फ़ंक्शन पॉइंट्स पर टिक करने” की जगह न लें। सीनारियो स्क्रिप्ट का इस्तेमाल करें: एक रियल वर्कऑर्डर ओपन करें, पूरी ऑपरेशन की वर्क रिपोर्ट करें; इंसान द्वारा मटेरियल की कमी बनाएं, डाउनस्ट्रीम के फ़्रीज़ को वेरिफ़ाय करें; बैच री-एसाइनमेंट के बाद, बोर्ड और वर्कऑर्डर के अनुरूप होने को देखें; तीन दिन की वर्क रिपोर्ट और फ़ील्ड इन्वेंट्री के बीच का डिफ़रेंस रेट लिमिट के अंदर होने को देखें। अगर नहीं होता, तो फ़ाइनल एक्सेप्टेंस पर साइन न करें, बल्कि कंडीशनल लॉन्च पर साइन करें।
डॉक्यूमेंट डिलीवरी में शामिल होना चाहिए: रेंज फ्रीज़िंग मीटिंग, स्टेट मशीन डिस्क्रिप्शन, इंटरफ़ेस लिस्ट, परमिशन मैट्रिक्स, सीनारियो एक्सेप्टेंस रिकॉर्ड, ऑपरेशन वार्ड और बदलाव फ़्लो। इनके अभाव में, बाद के ऑपरेशन वार्ड वोकल आर्कियोलॉजी बन जाएगा।
रिसोल्यूशन: डिलीवरी को “चलने योग्य नियम” के रूप में लें
डिमांड से लॉन्च तक, कोर नहीं फ़ंक्शन का ढेर है, बल्कि वर्कशॉप के डिफ़ॉल्ट नियमों को एक्सेक्यूटेबल लॉजिक में लिखना है, और कलेक्शन व एक्सेप्टेंस से इसके चलने को साबित करना है। फ़ेज़ 1 में केवल एक चेन को ब्रेक थ्रू देना, दस अर्ध-पूर्ण फ़ंक्शन मेनू से ज़्यादा मूल्यवान है। अगर आपकी फ़ैक्ट्री ऑपरेशन की प्रगति और वर्कऑर्डर के अनुरूप न होने की समस्या से जूझ रही है, तो ऊपर बताए गए पाथ के अनुसार फ़ेज़ 1 की रेंज को कम करके डेवलपमेंट शुरू कर सकते हैं।
Shandong XYN Information Technology Co., Ltd. (XYN Tech / XYN Tech) लंबे समय से विभिन्न इंडस्ट्रीज़ के लिए कस्टम सॉफ्टवेयर डेवलप करती आ रही है, रेंज, डिज़ाइन, डेवलपमेंट और एक्सेप्टेंस को डिलीवरेबल इंजीनियरिंग में तोड़ती है। अधिक जानकारी के लिए अबाउट अस पर जाएं।