Knowledge Problem

ईवा की वर्कशॉप में अचानक एक काम आता है। सूची उपकरण बताती है, लेकिन सहकर्मी को कुछ और भी पता है: उपयुक्त मशीन अभी खाली हुई है और ज़रूरी अटैचमेंट पड़ोस की वर्कशॉप में है। हायेक ऐसे खास समय और स्थान के ज्ञान पर ज़ोर देते हैं। तकनीकी पुस्तिका महत्वपूर्ण है, लेकिन अकेले नहीं बता सकती कि आज दोपहर क्या व्यवस्था हो सकती है। विशेषज्ञता और अनुभव यहाँ विरोधी नहीं हैं; निर्णय में अक्सर दोनों चाहिए। [1]

हायेक टिन का उदाहरण देते हैं: नई माँग या आपूर्ति में रुकावट उसकी कीमत बढ़ा सकती है। खरीदार तब बचत या विकल्प खोजते हैं, भले मूल कारण न जानते हों। कीमतें दूर के लोगों के फैसलों में तालमेल बिठा सकती हैं। इसके लिए हर व्यक्ति को एक ही रिपोर्ट पढ़ने की ज़रूरत नहीं। लेकिन कीमत पूरी कहानी नहीं बताती और हर प्रतिक्रिया त्रुटिहीन हो, यह ज़रूरी नहीं। Economic Calculation यानी मौद्रिक कीमतों से लागत और योजनाओं की तुलना इस संकेत का उपयोग करती है, उसे संपूर्ण ज्ञान नहीं बनाती। [1]

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

Economics and Knowledge में हायेक योजनाओं के मेल खाने और यह समझाने के बीच अंतर करते हैं कि लोग वहाँ तक कैसे पहुँचे। ईवा पुर्ज़े के आने की उम्मीद करती है और आपूर्तिकर्ता उसके स्वीकार करने की। मान लेना कि दोनों सब कुछ सही जानते हैं, उनके तालमेल को नहीं समझाता। इस उदाहरण में ऑर्डर की पुष्टि, बदला समय या देरी का संदेश देखना होगा, साथ ही यह भी कि लोगों ने योजनाएँ बदलीं या नहीं। पूरी सूचना वाला मॉडल उपयोगी हो सकता है, पर वास्तविक सीखने की प्रक्रिया समझाना बाकी रहता है। [2]

प्रोग्राम ईवा को पुर्ज़ा स्टॉक में दिखाता है। लेकिन प्रविष्टि किसी दूसरे ग्राहक की खरीद से पहले की हो सकती है या दूसरे मॉडल की हो सकती है। डेटाबेस पर लागू करें तो हायेक का सवाल बहुत व्यावहारिक हो जाता है: यह जानकारी कहाँ से आई, कब अपडेट हुई और ठीक किस चीज़ के बारे में है? तेज़ सॉफ्टवेयर दर्ज आँकड़े बेहतर संभाल सकता है, लेकिन उससे उनकी पूर्णता या उपयोगिता साबित नहीं होती। बात डेटाबेस को नकारने की नहीं, सहेजे हुए आँकड़े और खास निर्णय के लिए ज़रूरी ज्ञान के बीच अंतर की है। [1] [3]

मिस्त्री मशीन अच्छी तरह जान सकता है, लेकिन पुर्ज़े की बढ़ी कीमत या आपूर्तिकर्ता की परिवहन समस्या नहीं। विकेंद्रीकरण यानी निर्णय कई प्रतिभागियों में बाँटने के लिए उनके बीच संपर्क भी चाहिए। इसलिए हायेक स्थानीय ज्ञान को दूसरे संकेतों, विशेषकर कीमतों से जोड़ते हैं। काम के सबसे करीब होने से ईवा हमेशा सही नहीं हो जाती। उसे सूचना जाँचने, योजना बदलने और गलती से सीखने की गुंजाइश चाहिए। [1] [2]

वर्कशॉप ऑर्डर गिन सकती है, लेकिन ग्राहक का खोया भरोसा या अनोखी खराबी से जुड़ा कर्मचारी का अनुभव दर्ज करना कठिन है। The Pretence of Knowledge में हायेक चेताते हैं कि केवल उन्हीं बातों को महत्वपूर्ण न मानें जिनके लिए संख्याएँ उपलब्ध हैं। सटीक तालिका अपने आप सटीक भविष्यवाणी को उचित नहीं बनाती। अवलोकन, मान्यताओं और अब भी अज्ञात बातों को अलग करना उपयोगी है। मापन बेकार नहीं होता; उसकी सीमाएँ स्वीकार करनी होती हैं। [3]

ईवा Bitcoin स्वीकार कर सकती है और नेटवर्क के नियमों के अनुसार भुगतान सत्यापित कर सकती है। मिसाल के तौर पर, वह जाँच सकती है कि लेन-देन किसी ब्लॉक में शामिल है या नहीं। ब्लॉक लेन-देन का ऐसा समूह है जिसे नेटवर्क के नियमों के अनुसार स्वीकार किया गया हो। इससे यह नहीं पता चलता कि पुर्ज़ा आएगा या ग्राहक मरम्मत से खुश होगा। सत्यापित हो सकने वाला भुगतान रिकॉर्ड और बाज़ार का ज्ञान अलग काम करते हैं। वितरित नेटवर्क पूरी कारोबारी सूचना या त्रुटिहीन निर्णय की गारंटी नहीं देता। बिटकॉइन में भुगतान मिलने पर भी ईवा को आपूर्तिकर्ता से बात, मिस्त्री का अनुभव और योजना बदलने की क्षमता चाहिए। [1] [2] [4]