M365Con 2027 – मुफ़्त ऑनलाइन सम्मेलन · 11–22 Jan 2027 · 120 sessions→ m365con.net

2026-10-04

कंटिन्यूअस इम्प्रूवमेंट को बेहतर डेटा की ज़रूरत क्यों है

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

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

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

PDCA को एक वास्तविक जाँच चरण चाहिए
योजना, करो, जाँचो, कार्रवाई करो सुनने में सरल लगता है, लेकिन कई संगठन व्यवहार में योजना, करो और आगे बढ़ो चलाते हैं। PLAN में एक परखने योग्य समस्या, वर्तमान स्थिति, अपेक्षित सुधार और प्रतिकारी उपाय के पीछे की परिकल्पना परिभाषित होनी चाहिए। DO का अर्थ है वास्तविक उत्पादन परिस्थितियों में उपाय का परीक्षण करना और इतना संदर्भ दर्ज करना कि समझा जा सके वास्तव में क्या हुआ। CHECK का अर्थ है अपेक्षित परिणाम की तुलना वास्तविक उत्पादन प्रमाण से करना। ACT का अर्थ है जब प्रमाण समर्थन करे तो बदलाव को मानकीकृत करना, और जब न करे तो उसे अनुकूलित, सीमित या उलटना।
• क्या नुकसान वास्तव में घटा?
• क्या समस्या बस कहीं और खिसक गई?
• क्या उपलब्धता सुधरी लेकिन गुणवत्ता बिगड़ी?
• क्या यह अलग-अलग उत्पादों, टीमों और शिफ़्टों में काम करता है?
• क्या मेंटेनेंस, सामग्री, शेड्यूलिंग या किसी अन्य प्रक्रिया बदलाव ने परिणाम पर असर डाला?
एक सफल उत्पादन रन प्रमाण नहीं है। दोहराए जा सकने वाले सुधार को किस्मत वाली शिफ़्ट से अलग करने के लिए पर्याप्त साक्ष्य चाहिए।

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

गेम्बा से टीमें यह पहचानती हैं कि कहाँ देखना है और कौन से प्रश्न मायने रखते हैं। परिचालन डेटा उन प्रश्नों को वास्तविक उत्पादन पैटर्न पर परखता है। फिर मानक कार्य (स्टैंडर्ड वर्क) उस सीख को आगे ले जाता है ताकि अगली शिफ़्ट शून्य से शुरू न करे।

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

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

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

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

MES डेटा की फिर भी व्याख्या करनी होती है। लेनदेन देर से दर्ज हो सकते हैं, अलग-अलग टीमें कारण कोड अलग तरीके से उपयोग कर सकती हैं, और टाइमस्टैम्प उस सटीक भौतिक क्षण के बजाय यह दर्शा सकता है जब ऑपरेटर ने कुछ पुष्टि की। सिस्टम साक्ष्य देता है, लेकिन प्रक्रिया उस साक्ष्य को अर्थ देती है।

मशीन और IoT डेटा भौतिक प्रक्रिया की व्याख्या करते हैं
जब टीमों को समझना होता है कि किसी ऑपरेशन के भीतर क्या हुआ, तब मशीन डेटा महत्वपूर्ण हो जाता है। PLC और IoT संकेत मशीन अवस्थाएँ, चक्र समय, अलार्म, गति, तापमान, दबाव, इंटरलॉक, मोटर लोड, पुनः आरंभ व्यवहार और स्थिर उत्पादन तक का समय उजागर कर सकते हैं। MES दिखा सकता है कि कोई ऑपरेशन किसी विशेष समय पर पुनः आरंभ हुआ, जबकि मशीन डेटा समझा सकता है कि स्थिर उत्पादन लौटने से पहले के मिनटों में क्या हुआ।
• बार-बार आने वाले अलार्म
• पुनः आरंभ के बाद गति में कमी
• तापमान की पुनर्प्राप्ति
• मैन्युअल समायोजन
• इंटरलॉक
• अस्थिर चक्र समय
उत्पादन संदर्भ के बिना मशीन डेटा अब भी भ्रामक हो सकता है। कोई अलार्म तब अधिक उपयोगी बनता है जब उसे कार्य ऑर्डर, उत्पाद, ऑपरेशन, संसाधन, उपकरण स्थिति, सामग्री और उस घटना के आसपास के गुणवत्ता परिणाम से जोड़ा जा सके।

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

संरचित कोड घटनाओं को वर्गीकृत करने में मदद करते हैं। मानवीय संदर्भ उनकी व्याख्या करता है। इसलिए डेटा संग्रह को उत्पादन की वास्तविकता में फिट होना चाहिए, न कि उसमें बाधा बनना चाहिए। उपयोगी प्रश्न यह नहीं है कि कोई ऑपरेटर कितनी जानकारी दर्ज कर सकता है, बल्कि यह है कि सबसे छोटा मानवीय इनपुट कौन सा होगा जो अगले सुधार निर्णय को बेहतर बनाए।

आपको एक साझा फ़ैक्ट्री भाषा चाहिए
ERP, MES, मेंटेनेंस सिस्टम, हिस्टोरियन और स्प्रेडशीट एक ही उत्पादन घटना को अलग-अलग तरह से वर्णित कर सकते हैं। एक सिस्टम किसी संसाधन को “Line 3” कह सकता है, दूसरा “LINE03”, मेंटेनेंस लाइन के भीतर कई अलग संपत्तियों को ट्रैक कर सकता है, और हिस्टोरियन अब भी किसी पुराने PLC टैग का उपयोग कर सकता है। एक

Apple Podcasts · Spotify · YouTube · Deezer

Why Continuous Improvement Needs Better Data (English)