उत्पादन लागत घटाना: किसी और की सुलझाई हुई समस्या को दोबारा मत सुलझाइए

उत्पादन में लागत घटाने को अक्सर नए विचारों की लगातार खोज की एक दौड़ के रूप में देखा जाता है। लेकिन पहले रुककर एक सवाल पूछने लायक है: क्या किसी कंपनी को सच में हर बार नए समाधान की ज़रूरत होती है, या ज़्यादातर समय किसी ऐसी समस्या को दोबारा सुलझाने में बीत जाता है जिसे कोई और इंजीनियर या कोई और फ़ैक्टरी पहले ही सुलझा चुकी है?

हर फ़ैक्टरी एक ही समस्या को बार-बार शून्य से सुलझाती है

जब कच्चे माल की कीमत बढ़ती है, तो तकनीकी विभाग किसी विकल्प सामग्री की तलाश करता है। जब मज़दूरी बढ़ती है, तो उत्पादन विभाग किसी एक चरण में लोगों की संख्या घटाने का तरीका ढूंढता है। जब साइकल टाइम बहुत ज़्यादा हो जाता है, तो इंजीनियर मशीन या प्रक्रिया सुधारने बैठते हैं। जब खराबी की दर बढ़ती है, तो QC और उत्पादन विभाग कारण ढूंढने निकलते हैं। इनमें से हर काम ज़रूरी और सही है — समस्या यह नहीं कि यह काम करना पड़ता है, बल्कि यह है कि लगभग हर बार शुरुआत बिल्कुल शून्य से होती है: मौजूदा हालात का विश्लेषण, कारण की तलाश, विचार-मंथन, परीक्षण, मूल्यांकन, और तब कहीं जाकर लागू करना।

इस बीच, इस तरह की समस्याएँ लोगों की सोच से कहीं ज़्यादा बार दोहराई जाती हैं, और ज़्यादातर को कोई न कोई पहले ही झेल चुका होता है। किसी मशीनिंग इंजीनियर ने कभी क्रम बदलकर किसी पुर्ज़े का कटाई समय घटाया था। किसी और फ़ैक्टरी ने कभी शीट पर कटौती की व्यवस्था बदलकर उसी तरह के उत्पाद पर सामग्री की बर्बादी घटाई थी। किसी रखरखाव इंजीनियर को कभी किसी लाइन के बार-बार रुकने का असली कारण ढूंढने में हफ़्तों लग गए थे। यह कोई दुर्लभ बात नहीं है — यह ज़्यादातर फ़ैक्टरियों में लगभग हर हफ़्ते होता है, बस कभी एक ही जगह एक ही समय पर दो बार नहीं होता।

समाधान कमी में नहीं हैं — वे बस बंद और जगह-जगह बिखरे हुए हैं

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

किसी कंपनी के पास लागत घटाने का बहुत बड़ा ज्ञान पहले से मौजूद हो सकता है — फिर भी ज़रूरत के ठीक उस पल सही हिस्सा ढूंढ पाने की क्षमता नहीं होती। कोई इंजीनियर नौकरी छोड़ता है या विभाग बदलता है, और समाधान उसके साथ चला जाता है। ज्ञान नष्ट नहीं होता, लेकिन उस अगले व्यक्ति की पहुँच से बाहर निकल जाता है जिसे उसकी ज़रूरत होगी।

बदलने लायक सवाल

लागत की समस्या के सामने आम सवाल होता है: "इसके लिए मैं क्या विचार सोच सकता हूँ?" पहले पूछने लायक सवाल अलग है: "क्या इस समस्या को पहले किसी ने सुलझाया है?"

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

Costdown कोई कंटेंट लाइब्रेरी नहीं है

एक कंटेंट लाइब्रेरी "वेल्डिंग लागत घटाने के दस तरीक़े" का जवाब दे सकती है। लेकिन असली समस्या का सामना कर रहे इंजीनियर को एक आम-सा लेख नहीं चाहिए — उन्हें अपनी ख़ास स्थिति का जवाब चाहिए।

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

यही वह सीमारेखा है जो आसानी से गड्डमड्ड हो जाने वाली दो चीज़ों के बीच है: कंटेंट पाठक को एक अवधारणा समझने में मदद करता है; संरचित डेटा किसी को अपनी परिस्थितियों के अनुरूप सही समाधान ढूंढने, तुलना करने और दोबारा इस्तेमाल करने में मदद करता है। Costdown दूसरी चीज़ के लिए बनाया गया है। यह न तो पढ़कर समझने की जगह लेता है, न ही इंजीनियर की अपनी सोच की — यह उससे एक कदम पहले मौजूद रहता है, उस बिंदु पर जो तय करता है कि इंजीनियर को शून्य से शुरुआत करनी है या नहीं।

किसी समाधान को उसे बनाने वाले के साथ ख़त्म नहीं होना चाहिए

Costdown एक धारणा पर बना है: लागत घटाने का साबित हो चुका समाधान प्रोजेक्ट, Excel फ़ाइल, या उसे बनाने वाले इंजीनियर के साथ ख़त्म नहीं होना चाहिए। एक सफल लागत-कमी प्रोजेक्ट को संरचित डेटा बनना चाहिए — ऐसा डेटा जो ढूंढा जा सके, जिसकी तुलना की जा सके, और जो साबित हो चुका है उसे अगली समस्या के लिए दोबारा इस्तेमाल किया जा सके।

एक फ़ैक्टरी ने एक समस्या सुलझा ली। दूसरी फ़ैक्टरी को शून्य से शुरुआत करने की ज़रूरत नहीं।