मैन्युफैक्चरिंग Downtime कैसे ट्रैक करें और Unplanned Stops कैसे घटाएँ

प्रकाशित: 28 मार्च 2026 · पढ़ने में 9 मिनट

Downtime की असली लागत

ज़्यादातर मैन्युफैक्चरर्स जानते हैं कि downtime महँगा है। बहुत कम जानते हैं कि असल में कितना महँगा। जब production line रुकती है, तो साफ़ दिखने वाली लागतें सामने होती हैं: खाली बैठे कामगार, छूटे shipments, और पिछड़ा काम पूरा करने के लिए overtime। छिपी हुई लागतें इससे बड़ी होती हैं: देर से जा रहे ऑर्डर्स के लिए महँगा expedited freight, ग्राहक की नाराज़गी, भविष्य के खोए ऑर्डर्स, और उन downstream operations पर असर जो आपके output का इंतज़ार कर रहे थे।

एक काम का मोटा नियम: अपने प्लांट का प्रति operating घंटा revenue निकालें, फिर अप्रत्यक्ष लागतों को जोड़ने के लिए उसे 2 से 3 गुना करें। अगर आपका प्लांट प्रति machine-hour $500 का revenue बनाता है, तो पूरा असर जोड़ने पर unplanned downtime का हर घंटा असल में $1,000 से $1,500 का पड़ता है। 10 मशीनों वाले प्लांट में, जहाँ औसत Availability (उपलब्धता) 85% है (यानी हर मशीन पर 8 घंटे की shift में 1.2 घंटे का downtime), downtime की सालाना लागत चौंकाने वाली होती है — छोटे operations में भी अक्सर $500,000 प्रति वर्ष से ज़्यादा।

समस्या यह नहीं कि मैन्युफैक्चरर्स को downtime की परवाह नहीं। समस्या यह है कि जो मापा नहीं जाता, उसे संभाला नहीं जा सकता। और ज़्यादातर प्लांट downtime को ख़राब तरीके से, असंगत ढंग से, या बिल्कुल नहीं मापते।

Manual बनाम Automated ट्रैकिंग

Manual ट्रैकिंग: काग़ज़ का log

छोटे और मध्यम प्लांट्स में सबसे आम तरीका है हर मशीन पर एक काग़ज़ का log या एक साझा spreadsheet। Operators दर्ज करते हैं कि मशीन कब रुकी, कब फिर चली, और (कभी-कभी) क्यों रुकी। इस तरीके की समस्याएँ अच्छी तरह दर्ज हैं:

• कम रिपोर्टिंग। अध्ययन लगातार दिखाते हैं कि manual logs असल downtime events का सिर्फ़ 40-60% ही पकड़ते हैं। छोटे stops (5 मिनट से कम) लगभग कभी दर्ज नहीं होते। जो operator किसी समस्या का troubleshooting कर रहा है, वह साथ-साथ यह नहीं लिख रहा होता कि वह troubleshooting कर रहा है।
• गलत timestamps। Operators event या shift के अंत में याददाश्त से समय दर्ज करते हैं। 23 मिनट का stop “लगभग 20 मिनट” बन जाता है। शुरू और ख़त्म होने के समय को नज़दीकी 5 या 10 मिनट तक गोल कर दिया जाता है।
• असंगत categorization। Reason codes की मानक सूची के बिना, एक operator लिखता है “jammed”, दूसरा “material jam” और तीसरा “feeder stuck”। ये एक ही failure mode हैं, लेकिन किसी भी analysis में तीन अलग categories के रूप में दिखते हैं।
• देर से दिखना। काग़ज़ के logs तब तक किसी को नहीं दिखते जब तक कोई उन्हें इकट्ठा करके, उतारकर किसी सिस्टम में दर्ज न करे। आम तौर पर यह जल्दी से जल्दी अगले दिन होता है।

Automated ट्रैकिंग: PLC-आधारित पहचान

हर आधुनिक PLC पहले से जानता है कि मशीन चल रही है या नहीं। मशीन की state का signal — चाहे वह किसी dedicated status register से आए, drive run signals और fault bits के मेल से, या PackML state machine से — downtime डेटा का सबसे भरोसेमंद स्रोत है। यह भूलता नहीं, आँकड़े गोल नहीं करता, कम रिपोर्ट नहीं करता, और इसके लिए operator को कोई मेहनत नहीं करनी पड़ती।

Automated पहचान हर एक stop event का शुरू होने का समय, ख़त्म होने का समय और अवधि पकड़ती है, जिसमें 90 सेकंड के jams और 3 मिनट के मटीरियल इंतज़ार भी शामिल हैं, जिन्हें operators कभी दर्ज नहीं करते। ये micro-stops अलग-अलग तो मामूली लगते हैं, लेकिन पूरी shift में जोड़ने पर अक्सर कुल downtime का 10-20% बनते हैं।

Automated पहचान की सीमा यह है कि PLC जानता है कि मशीन रुकी, लेकिन हो सकता है उसे यह पता न हो कि क्यों। कुछ PLC विस्तृत fault codes देते हैं जो सीधे root causes से जुड़ते हैं। दूसरे बस “not running” बताते हैं। यहीं operator का input काम का बना रहता है — यह बताने के लिए नहीं कि मशीन रुकी (सिस्टम पहले से जानता है), बल्कि बाद में एक reason code देने के लिए।

Downtime की Categories

अच्छी तरह डिज़ाइन किया गया downtime categorization सिस्टम श्रेणीबद्ध (hierarchical) होता है। ऊपरी स्तर बुनियादी रूप से अलग तरह के stops को अलग करता है। निचले स्तर root cause analysis के लिए ज़रूरी विवरण देते हैं।

Planned Downtime

ऐसे stops जो तय और अपेक्षित थे। इन्हें OEE Availability के कैलकुलेशन से बाहर रखा जाता है, क्योंकि उस दौरान उपकरण से प्रोडक्शन की योजना ही नहीं थी।

• तय maintenance — preventive maintenance, calibration और inspection
• कोई ऑर्डर नहीं — इस दौरान प्रोडक्शन की कोई माँग नहीं
• Breaks और भोजन — अगर breaks के दौरान मशीन बिना निगरानी के नहीं चल सकती
• Planned changeover — अगर आपका संगठन changeover को planned मानता है (नीचे नोट देखें)

Unplanned Downtime

ऐसे stops जो तय नहीं थे। ये सीधे OEE Availability पर असर डालते हैं और सुधार का मुख्य निशाना होते हैं।

• उपकरण breakdown — मैकेनिकल failure, इलेक्ट्रिकल fault, pneumatic/hydraulic failure
• Changeover और setup — एक प्रोडक्ट या job से दूसरे पर जाने में लगा समय (अगर unplanned माना जाता है)
• मटीरियल की कमी — कच्चे माल का इंतज़ार, upstream मशीन से line को सप्लाई न मिलना
• Tooling — tool बदलना, tool टूटना, tool calibration
• Quality hold — quality जाँच या inspection के लिए मशीन रोकी गई
• Operator उपलब्ध नहीं — शौचालय break, lunch से देर से लौटना, कोई operator असाइन नहीं
• Utilities — compressed air चले जाना, बिजली में उतार-चढ़ाव, coolant सिस्टम failure
• IT/Network — control सिस्टम की समस्या, network outage, software error

Changeover पर एक नोट

Changeover के समय को किस श्रेणी में रखें, यह OEE methodology के सबसे ज़्यादा बहस वाले मुद्दों में से एक है। कुछ संगठन इसे planned downtime मानते हैं (OEE से बाहर), क्योंकि changeovers production schedule का ज़रूरी हिस्सा हैं। दूसरे इसे unplanned downtime मानते हैं (OEE में शामिल), क्योंकि यह वह समय है जब मशीन प्रोडक्शन नहीं कर रही, और इसलिए SMED (Single Minute Exchange of Die) तकनीकों से सुधार का मौका है।

कोई सर्वमान्य “सही” जवाब नहीं है। अहम है एकरूपता: एक तरीका चुनें और सभी मशीनों पर एक जैसा लागू करें। अगर आप changeover को OEE से बाहर रखते हैं, तो उसे अलग से ट्रैक करें, ताकि आप उसे फिर भी माप और सुधार सकें। अगर शामिल करते हैं, तो पक्का करें कि उसका अपना reason code हो, ताकि वह breakdowns के साथ घुल-मिल न जाए।

Downtime कारणों का Pareto बनाना

Downtime analysis में Pareto सिद्धांत (80/20 नियम) हैरानी की हद तक लगातार सही बैठता है। ज़्यादातर प्लांट्स में 3 से 5 reason codes ही कुल downtime मिनटों का 70-80% बनाते हैं। Pareto chart — अवधि के घटते क्रम में लगा bar chart, साथ में cumulative प्रतिशत की line — तुरंत दिखा देता है कि कौन-सी समस्याएँ ध्यान के लायक हैं और कौन-सी सिर्फ़ noise।

असरदार Pareto बनाने के लिए:

• गिनती नहीं, अवधि इस्तेमाल करें। जो fault 50 बार होता है पर औसतन 30 सेकंड चलता है (कुल 25 मिनट), उसका असर उस breakdown से कम है जो दो बार होता है पर हर बार 90 मिनट चलता है (कुल 180 मिनट)। अवधि-आधारित Pareto सही समस्याओं को प्राथमिकता देता है।
• समय अवधि और मशीन से filter करें। पूरी तिमाही का प्लांट-स्तरीय Pareto रणनीतिक फ़ैसलों के लिए उपयोगी है। पिछले हफ़्ते का एक मशीन का Pareto, सोमवार सुबह की योजना बना रही maintenance टीम के काम का है।
• Planned और unplanned को अलग रखें। एक ही Pareto में planned और unplanned downtime मिलाने से असली संकेत धुँधला हो जाता है। तय break को आप “ठीक” नहीं कर सकते। Analysis को उन नुकसानों पर केंद्रित रखें जिन्हें आप सच में घटा सकते हैं।
• नियमित रूप से अपडेट करें। एक बार बनाकर छह महीने दीवार पर टँगा Pareto एक पोस्टर है, management tool नहीं। सबसे ऊपर के कारणों की हर हफ़्ते समीक्षा होनी चाहिए और शीर्ष 2-3 के लिए action items असाइन होने चाहिए।

Operators downtime कम क्यों रिपोर्ट करते हैं

काम करने वाला सिस्टम डिज़ाइन करने के लिए यह समझना ज़रूरी है कि manual ट्रैकिंग क्यों नाकाम होती है। Operators कई कारणों से downtime कम रिपोर्ट करते हैं:

• दोष से बचना। अगर downtime डेटा का इस्तेमाल प्रक्रियाएँ सुधारने के बजाय दोष देने में होता है, तो operators रिपोर्ट किए गए stops को कम से कम रखना सीख जाते हैं। यह management की समस्या है, operator की नहीं। Downtime डेटा से root cause analysis और प्रक्रिया सुधार होना चाहिए, सज़ा नहीं।
• मेहनत। हर stop event लिखना थकाऊ है, ख़ासकर जब operator साथ-साथ troubleshooting और मशीन दोबारा चालू करने में लगा हो। Automated पहचान यह मेहनत पूरी तरह ख़त्म कर देती है।
• अस्पष्टता। Operators पक्का नहीं जानते कि “downtime” में क्या गिना जाए। क्या 2 मिनट का मटीरियल reload एक stop event है? और forklift के लिए 90 सेकंड का इंतज़ार? साफ़ परिभाषाओं के बिना रिपोर्टिंग असंगत रहती है।
• कोई फ़ायदा नज़र न आना। अगर operators कभी नहीं देखते कि उनके दर्ज किए downtime डेटा का क्या होता है, तो वे स्वाभाविक रूप से मान लेते हैं कि इसका कोई मतलब नहीं। Feedback loop पूरा करना — operators को Pareto chart दिखाना, सुधार के नतीजे साझा करना, और जब उनके input से कोई समस्या ठीक हो तो उन्हें श्रेय देना — पूरी तस्वीर बदल देता है।

अपने-आप पहचान के लिए PLC state signals का इस्तेमाल

सबसे भरोसेमंद automated downtime पहचान मशीन के PLC state signal का इस्तेमाल करती है, जो MQTT और Sparkplug B के ज़रिए monitoring प्लेटफ़ॉर्म पर publish होता है। Implementation का तरीका सीधा है:

• PLC एक machine state tag देता है (जैसे एक integer, जहाँ 1 = Running, 2 = Idle, 3 = Faulted, 4 = Changeover, आदि)
• MQTT edge gateway state में बदलावों को cloud प्लेटफ़ॉर्म पर publish करता है
• प्लेटफ़ॉर्म हर state transition को millisecond तक सटीक timestamp के साथ दर्ज करता है
• Planned production time के दौरान जिस भी अवधि में मशीन की state “Running” नहीं है, उसे अपने-आप downtime event माना जाता है
• अगर PLC fault codes देता है, तो उन्हें शुरुआती reason code के रूप में ले लिया जाता है
• जिन events के लिए PLC fault code नहीं है, उनके लिए प्लेटफ़ॉर्म operator (या supervisor) से reason code देने को कहता है

यह hybrid तरीका आपको automated पहचान की सटीकता और पूर्णता देता है, साथ में वह संदर्भ भी, जो सिर्फ़ एक इंसानी operator दे सकता है। मशीन जानती है कि वह कब और कितनी देर रुकी। Operator जानता है क्यों।

Downtime की लागत कैलकुलेट करना

Downtime के मिनटों को डॉलर में बदलने के लिए आपको हर मशीन या production line के लिए प्रति मिनट लागत का आँकड़ा चाहिए। बुनियादी फ़ॉर्मूला:

Downtime लागत = Downtime मिनट × (प्रति मिनट revenue + प्रति मिनट श्रम लागत + प्रति मिनट overhead)

मोटे अनुमान के लिए, मशीन के सालाना revenue योगदान को सालाना operating मिनटों से भाग दें, और अप्रत्यक्ष लागतों (expediting, overtime, ग्राहक penalties आदि) के लिए 1.5 से 2.5 से गुणा करें। लागत का मोटा आँकड़ा भी downtime पर होने वाली चर्चा बदल देता है। “Line 3 पर 47 मिनट का downtime हुआ” अमूर्त लगता है। “आज downtime की वजह से Line 3 पर $2,800 का नुकसान हुआ” — इस पर ध्यान जाता है।

ट्रैकिंग से कमी तक

Downtime ट्रैक करना तभी काम का है जब उससे कार्रवाई हो। सुधार का मानक चक्र:

• मापें — automated पहचान सटीक, पूरा डेटा देती है
• वर्गीकृत करें — reason codes नुकसान का प्रकार बताते हैं
• प्राथमिकता तय करें — Pareto analysis मेहनत को सबसे बड़े नुकसानों पर केंद्रित करता है
• जाँच करें — root cause analysis (5 Why, fishbone diagram) असली समस्या पहचानता है
• कार्रवाई करें — countermeasures लागू करें (preventive maintenance, design बदलाव, procedure अपडेट, ट्रेनिंग)
• पुष्टि करें — उसी Pareto पर नज़र रखें और पक्का करें कि समस्या घटी है

यह एक बार का काम नहीं है। यह हर हफ़्ते की लय है। Pareto के शीर्ष 2-3 items के हमेशा असाइन किए गए owners और सक्रिय सुधार प्रोजेक्ट होने चाहिए। जैसे-जैसे शीर्ष items हल होते हैं, अगला स्तर ऊपर आता है और फ़ोकस बनता है। महीनों में यह अनुशासित तरीका जुड़-जुड़कर OEE में बड़ा सुधार बन जाता है।

PulseMQ downtime कैसे ट्रैक करता है

PulseMQ, MQTT के ज़रिए publish हुए PLC machine state signals से हर downtime event अपने-आप पहचानता है। हर state transition सटीक timestamps के साथ log होता है। प्लेटफ़ॉर्म आपके configure किए गए shift schedules और maintenance windows के आधार पर planned और unplanned downtime में फ़र्क करता है।

Unplanned stops के लिए operators configure की जा सकने वाली सूची से सीधे production dashboard पर reason codes दे सकते हैं — shop floor के tablet पर, अपने फ़ोन पर, या किसी भी browser में। PLC fault codes अपने-आप शुरुआती वर्गीकरण के रूप में ले लिए जाते हैं। AI agent पुराने डेटा से सीखे गए पैटर्न के आधार पर reason codes सुझा सकता है।

Built-in Pareto analysis downtime को कारण, मशीन, shift और समय अवधि के हिसाब से दिखाता है। दो clicks में प्लांट-स्तरीय view से किसी एक मशीन के downtime इतिहास तक drill down करें। गहरे analysis के लिए या अपने CMMS (Computerized Maintenance Management System) से integration के लिए डेटा export करें।

क्योंकि downtime ट्रैकिंग OEE कैलकुलेशन, job ट्रैकिंग और एनवायरनमेंटल मॉनिटरिंग से जुड़ी है, आप downtime events को production के संदर्भ से जोड़कर देख सकते हैं। क्या breakdown किसी ख़ास प्रोडक्ट run के दौरान हुआ? क्या आसपास का तापमान ज़्यादा था? क्या मशीन नई recipe चला रही थी? अलग-थलग downtime ट्रैकिंग tools से ऐसे संबंध देखना असंभव है।