क्या बचत असली है? Bottleneck और वे तीन रास्ते जिनसे आंकड़ा पैसा बनता है

मशीन तेज़ करने से आमतौर पर कोई बचत क्यों नहीं होती, cost sheet का आंकड़ा कब असली पैसा बनता है, और cash saving को cost avoidance से कैसे अलग करें — finance के पूछने से पहले।

अद्यतन 1 सितंबर 2026

यह guide costing सिखाने के लिए नहीं है — वह काम industry guides करते हैं। यह उस सवाल का जवाब देता है जो हर cost sheet के पीछे खड़ा रहता है: आपने जो बचत निकाली है, उसका मतलब क्या यह है कि plant के पास सचमुच उतना पैसा ज़्यादा है?

ज़्यादातर जवाब ना ही होता है, और गणित में कोई गलती नहीं होती। पैसा समीकरण से तभी निकलता है जब plant **किसी असली चीज़ का भुगतान बंद करे** या **ज़्यादा बेचे** — और कोई improvement इनमें से कुछ करता है या नहीं, यह पूरी तरह इस पर निर्भर है कि वह flow में कहाँ बैठा है।

वह उदाहरण जो हर plant देख चुका है

आप एक operation सुधारते हैं और cycle time छह मिनट से चार मिनट हो जाता है। Sheet दो मिनट को machine hour rate और सालाना volume से गुणा करके एक अच्छा-सा आंकड़ा निकाल देती है।

लेकिन अगर वह operation कभी constraint था ही नहीं — अगर वह पहले से पिछले operation का या order का इंतज़ार कर रहा था — तो improvement के बाद plant उतना ही dispatch करेगा, उतनी ही तनख़्वाह देगा और उतनी ही बिजली खाएगा। बढ़ा सिर्फ़ **idle time** है।

वह improvement बेकार नहीं है: उसने खाली capacity बनाई है, और खाली capacity आगे चलकर पैसा बन सकती है। अभी वह पैसा नहीं है, और उसे पैसा बताकर पेश करना अपनी साख गँवाने का सबसे तेज़ तरीका है — जिस दिन finance आपके आंकड़े को books से मिलाएगा।

आंकड़े से असली पैसे तक के तीन ही रास्ते

सिर्फ़ तीन हैं, और कम से कम एक का नाम आपको ले पाना चाहिए:

कोई व्यक्ति या shift हटती है — तनख़्वाह देना सचमुच बंद होता है।
आप ज़्यादा बेचते हैं — खाली हुई capacity असली मौजूद orders से भरती है।
किसी ऐसी line का खर्च घटता है जिसका invoice आता है — कम material, कम बिजली, कम outsourcing।

तीसरा रास्ता सबसे भरोसेमंद और बचाव में सबसे आसान है, क्योंकि वह stores issue slip या supplier invoice पर निशान छोड़ता है। पहले दो के लिए किसी को फ़ैसला लेना पड़ता है; वे अपने आप नहीं होते।

अगर तीनों में से एक भी नाम नहीं ले पा रहे, तो आपके पास **खाली हुई capacity** है, बचत नहीं। यह साफ़-साफ़ लिख देना उस आंकड़े से ज़्यादा कीमती है — तजुर्बेकार पढ़ने वाला उसी रिपोर्ट पर भरोसा करता है जो अपनी सीमा ख़ुद बताती है।

Constraint ही पूरी line का output तय करता है

Bottleneck सबसे धीमा operation है, और पूरी line का output उसी के बराबर होता है। बाकी सारे operation, चाहे कितने भी तेज़ हों, आख़िर में उसी का इंतज़ार करते हैं।

इसके दो नतीजे निकलते हैं, और दूसरा ही छूटता है:

Constraint पर बचा हुआ एक घंटा पूरे plant के लिए एक घंटे का अतिरिक्त output है।
कहीं और बचा हुआ घंटा कुछ नहीं बदलता — जब तक आप उस खाली समय से shift न हटाएँ, आदमी न घटाएँ, या किसी ज़्यादा तंग resource का काम उस पर न डालें।

Constraint ढूँढ़ने के लिए time study नहीं चाहिए: line पर चलिए और वह operation ढूँढ़िए जिसके **आगे माल जमा है और पीछे कोई इंतज़ार नहीं कर रहा**। या पूछिए कि हमेशा overtime कौन-सा operation करता है।

Constraint घोषित कीजिए और system को जाँचने दीजिए

Labour और machine दोनों sections में एक field है जो पूछता है कि यह line constraint है या नहीं। वह गणित में हिस्सा नहीं लेता: उससे कुछ जोड़ा, घटाया या गुणा नहीं होता।

उसका इकलौता काम चेतावनी चालू करना है: अगर आप किसी line को constraint नहीं बताते हैं और वही line बचत दिखा रही है, तो system साफ़ कह देता है कि यह पैसा शायद सिर्फ़ idle time हो।

इस field की तीन हालतें हैं, और «घोषित नहीं किया» का मतलब «constraint नहीं है» नहीं होता। खाली छोड़ेंगे तो कोई चेतावनी नहीं मिलेगी — system आपकी तरफ़ से अंदाज़ा नहीं लगाता। जाँच होने के लिए घोषित करना पड़ता है।

इसलिए किसी line को «constraint नहीं» बताना आपका case कमज़ोर नहीं करता। वह आपसे सवाल **पहले** करवा देता है, reviewer के करने से पहले — और अगर आप फिर भी ऊपर के तीन रास्तों में से एक बता सकें, तो वह रास्ता verification section में लिख दीजिए और case टिक जाएगा।

Cash saving और cost avoidance एक ही दावा नहीं हैं

दोनों जायज़ हैं। दोनों आपस में बदले नहीं जा सकते, और पढ़ने वाले को पता होना चाहिए कि आप किसका दावा कर रहे हैं।

किस्म	मतलब	उदाहरण
Cash saving	कोई खर्च books से गायब हो जाता है	अब replacement parts नहीं खरीदने पड़ते; per part material कम
Cost avoidance	जो खर्च आने वाला था वह कभी आया ही नहीं	capacity काफ़ी थी इसलिए दूसरी machine नहीं लेनी पड़ी; इस quarter overtime नहीं हुआ

Cost avoidance असली है, पर वह एक मान्यता पर टिका है — कि वह खर्च सचमुच आने ही वाला था। वह मान्यता लिख दीजिए, पढ़ने वाले पर अंदाज़ा मत छोड़िए।

जब आंकड़ा बुरा दिखे और बदलाव फिर भी सही हो

कुछ improvements cost बढ़ोतरी के रूप में निकलते हैं और फिर भी सही होते हैं। सबसे साफ़ मामला batch size घटाने का है: साल में setup ज़्यादा, इसलिए per part setup cost बढ़ जाती है।

बदले में जो मिलता है — कम lead time, कम WIP, defect जल्दी पकड़ में आना — उसे unit cost sheet नाप ही नहीं सकती, और batch size घटा हुआ देखते ही system यह बात सीधे कह देता है।

आंकड़ा यहाँ बुरा दिख रहा है इसलिए अच्छा बदलाव मत छोड़िए। और आंकड़े को सजाइए भी मत: mechanism section में लिख दीजिए कि फ़ायदा वहाँ है जहाँ sheet की पहुँच नहीं है।

Publish करने से पहले पाँच सवाल

यह improvement constraint पर है या कहीं और?
अगर कहीं और है: पैसे तक के तीन रास्तों में से कौन-सा मैं सचमुच बता सकता हूँ?
यह cash saving है या cost avoidance? मैंने बताया है?
अगर cost avoidance है: उसके पीछे की मान्यता लिखी है?
क्या कोई फ़ायदा है जिसे sheet नाप नहीं सकती? क्या वह mechanism section में है?

इन पाँच में से कोई भी आपके आंकड़े को छोटा नहीं करता। ये उसे **सवालों के सामने टिकने लायक** बनाते हैं — और यही तय करता है कि कोई दूसरा plant कभी आपका काम copy करेगा या नहीं।