हिमशैल

हर कोई जानता है कि एक हिमखंड क्या है - बर्फ का एक बड़ा टुकड़ा जो समुद्र में तैरता है। सभी को याद है कि आइसबर्ग में क्या गड़बड़ है - इसका केवल एक छोटा हिस्सा दिखाई देता है, जो पानी की सतह से ऊपर है, बाकी छिपा हुआ है। और कितना है, यह बाकी - कोई नहीं जानता।

ऐसी ही स्थिति स्वचालित प्रणालियों में डेटा के साथ है।

हम आमतौर पर डेटा ही देखते हैं। दस्तावेज़, जैसे डिलीवरी या रसीद चालान, स्थानान्तरण, भुगतान, आदि। निर्देशिकाएँ - नामकरण, प्रतिपक्ष, इकाइयाँ। हम कार्यों को देखते हैं, दोनों सामान्य और प्रक्रिया वाले। हम अवशेषों को देखते हैं - स्टॉक में कितना माल है, जो हमारे पास पैसा है, हमारे पास कितने घाटे हैं आदि।

व्यक्तिगत रूप से या संयोजन में कोई भी डेटा, एक निश्चित स्थिति बनाता है। उदाहरण के लिए, हमारा गोदाम, हर समय, किसी न किसी राज्य में है। हम ऐसा कहते हैं - गोदाम की स्थिति। या प्राप्य की स्थिति, या भुगतान, या कार्यों की स्थिति, या प्रक्रियाओं की स्थिति।

हम स्थिति का तुरंत आकलन करने में काफी सक्षम हैं - दोनों एक स्वचालित प्रणाली और जीवन में। अनुमान लगाया, भाग गए और भूल गए।

फिर, कुछ समय बाद, हम फिर से उसी डेटा, या स्थिति पर आते हैं। हम फिर से राज्य का त्वरित मूल्यांकन करते हैं - हम कहते हैं कि "सब कुछ अच्छा है" या "सब कुछ बुरा है"। यह एक दूसरे, तीसरे, एक सौ पच्चीस बार दोहराया जाता है।

यदि हम स्थिति को महत्वपूर्ण मानते हैं, तो, शायद, हम किसी तरह इसे सही करेंगे। और अगर नहीं? हां, स्थिति बहुत अच्छी नहीं है, लेकिन ऐसा लगता है कि आप रह सकते हैं। यह अक्सर परिचालन बैठकों में होता है - कोई व्यक्ति सवाल उठाता है, स्थिति बताता है, एक आकलन देता है। हर कोई कराहता है, या अपनी जुबान काटता है और ... क्या? एक नियम के रूप में, वे भूल जाते हैं। अगली बार, जब तक कोई और ध्यान न दे।

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

ऐसा क्यों हो रहा है? नकारात्मक स्थिति की जानकारी में क्या गायब है? एक त्वरित मूल्यांकन है, काफी उच्च-गुणवत्ता और विस्तृत। वाक्यांश "सब कुछ यहाँ बुरा है" कैसे जारी रखें, ताकि वह नए रंगों के साथ खेले और अधिक जानकारीपूर्ण बने?

वाक्यांश को जारी रखना बहुत सरल है: "यहां सब कुछ बुरा है, और लंबे समय तक।" राज्य का समय या अवधि एक पर्याप्त निर्णय के लिए आवश्यक जानकारी है।

जीवन में, हर कोई यह समझता है। मैं आपको कुछ उदाहरण देता हूं।

"मेरे पास पर्याप्त पैसा नहीं है" - एक त्वरित मूल्यांकन, सर्जिकल हस्तक्षेप की आवश्यकता होती है। "मेरे पास अब एक साल के लिए पर्याप्त पैसा नहीं है" - वाह, हमारे यहाँ एक प्रणालीगत समस्या है, जिस पर हमें कड़ी मेहनत करने और जीवन में कुछ बदलने की आवश्यकता है।

"कुछ मेरे पैर को चोट पहुँचाता है" - ठीक है, तुम कभी नहीं जानते, उसने समय पर काम किया हो सकता है, या मौसम गठिया को प्रभावित करता है। "मेरे पैर में अब छह महीने से दर्द हो रहा है" - तुरंत क्लिनिक में दौड़ें।

"एक बच्चा एक ड्यूस लाया" - अच्छी तरह से किया, यह उच्च समय है, संतुलन के लिए ड्यूस की आवश्यकता होती है। "एक बच्चा पूरी तिमाही के लिए केवल दो बार लाता है" - ओह, आप मूर्ख हैं एक नाबालिग, आप वहां क्या कर रहे हैं, कल मैं स्कूल जा रहा हूं, जहां आपके कक्षा शिक्षक का फोन नंबर है।

इसी तरह व्यापार प्रणालियों में।

"ग्राहक हमें एक लाख बकाया है" - ठीक है, भुगतान करें कि आप क्या कर रहे हैं। "ग्राहक अब हमें छह महीने के लिए एक लाख बकाया है" - आपकी माँ, आपने कहाँ देखा?

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

"प्रोग्रामर्स ने मेरे कार्य को पूरा कर लिया है" - हाँ वे सभी कार्य करते हैं, इसलिए चिंता न करें। कर लेंगे। "प्रोग्रामरों ने पहले ही दो महीने के लिए मेरे काम को पूरा कर लिया है" - यह लानत है, मैं लंबे समय से इन गधों को तितर-बितर करना चाहता था, वे वहां क्या कर रहे हैं?

जैसा कि आप देख सकते हैं, एक शर्त की अवधि, विशेष रूप से एक नकारात्मक एक, जानकारी को एक नया आयाम देती है। यह ऐसा था जैसे फ्लैट, उबाऊ जानकारी थी जिसके साथ यह स्पष्ट नहीं था कि क्या करना है, लेकिन एक तीन-आयामी चित्र प्राप्त किया गया था। किसी स्थिति का विश्लेषण करना और निर्णय लेना बहुत आसान हो जाता है।

यहाँ सब कुछ इतना स्पष्ट है कि मैं इस पर विश्वास भी नहीं कर सकता - क्या इस तरह के प्रतिबंध पाठ्यपुस्तक में एक अलग अध्याय के लायक हैं? इस प्रश्न का उत्तर देने के लिए, अपनी सूचना प्रणाली पर एक नज़र डालें।

क्या आप मापा अवधि के साथ कई स्थितियां पाते हैं? परंपरागत रूप से, हिमशैल सिद्धांत पर आधारित दो रिपोर्टें हैं: अस्वाभाविक संपत्ति और बकाया। क्या, वैसे, आपके पास अस्वाभाविक संपत्ति है? सभी में नहीं, यहां तक ​​कि सामान्य प्रणालियों में भी, अस्वाभाविक संपत्ति देखी जा सकती है।

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

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

तकनीकी शब्दों में, पार्टी दस्तावेज़ कई मुश्किलें पैदा करता है।

सबसे पहले, यह तालिकाओं में रिकॉर्ड की संख्या बढ़ाता है। एक प्रविष्टि "आस्तीन, 10 टुकड़े" दस प्रविष्टियों में बदल सकती है - "09/01/2017 से 1 पीसी आस्तीन", "12/09/2017 से 1 पीसी आस्तीन", आदि।

दूसरे, बैच निरस्तीकरण एल्गोरिदम की जरूरत है। उदाहरण के लिए, जब शिपिंग (यानी माल लिखना), तो आपको पता होना चाहिए कि किस बैच से शेष ऋण घटा है। या खरीदार से भुगतान करते समय, आपको यह इंगित करने की आवश्यकता है कि किस शिपमेंट दस्तावेज़ में पैसा आया था। दो दृष्टिकोणों का उपयोग किया जाता है: या तो बैचों की स्वचालित गणना या उनके मैनुअल संकेत। स्वचालित बैच चयन FIFO (पहले, सबसे पहले बैच) और LIFO (पहले, नवीनतम बैच) की प्रसिद्ध लेखन-बंद रणनीतियाँ हैं। मैनुअल बैच पहचान का उपयोग आमतौर पर भुगतान पोस्ट करने में किया जाता है।

तीसरी समस्या, बल्कि एक कार्यप्रणाली है, कि वास्तविक जीवन बैच रद्द एल्गोरिथ्म का पालन नहीं करता है। स्टोरकीपर शेल्फ से भाग लेगा, लेकिन वह नहीं जिसे प्रोग्राम ने चुना है। वह नहीं जानता कि FIFO क्या है।

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

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

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

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

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

तीसरा तरीका फसली स्थिति की गणना, अलग, स्टोर और ट्रैक करना है।

उदाहरण के लिए, आपके पास घाटे का बयान है - सामानों की एक सूची जिसे आपको खरीदने की आवश्यकता है। उत्पादन, बिक्री, मरम्मत आदि के लिए। पूरे घाटे वाले बयान की निगरानी करने का कोई मतलब नहीं है - काफी समय से समाप्त स्थिति। ये पिछले स्थान हाइलाइट करने लायक हैं, क्योंकि उनमें से कई नहीं होंगे?

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

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

एक व्यक्ति जो अतिदेय घाटे की देखरेख करता है, वह बस खुश होगा। सबसे पहले, वह अब नजर नहीं रख सकता है - बस देरी के बारे में एक अधिसूचना सेट करें। दूसरे, आपको अब यह पता लगाने की आवश्यकता नहीं है कि क्या विलंब लंबे समय तक दिखाई दिया है - अवधि स्वचालित रूप से दिखाई जाएगी। तीसरा, विलंब गायब होने के क्षण को ट्रैक करना आवश्यक नहीं है - सिस्टम आपको बताएगा कि चीजें कब ठीक होती हैं।

एक व्यवसाय प्रोग्रामर के रूप में, व्यवसाय प्रणाली में प्रतिक्रिया प्रक्रियाओं का निर्माण करना आपके लिए बहुत आसान होगा। जबकि अवधि की कोई समझ नहीं है, आप एक नकारात्मक स्थिति पैदा होते ही व्यक्ति को तुरंत खींचने के लिए मजबूर हो जाते हैं। और आपकी "चिकोटी" लाल चीर की तरह आपकी नाक के सामने लगातार लटकती रहेगी।

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

उसी समय, आप एक अपस्ट्रीम प्रतिक्रिया प्रणाली का निर्माण कर सकते हैं। उदाहरण के लिए, पहले आपूर्तिकर्ता को घाटे में देरी दिखाएं। एक दिन बाद, यदि आपूर्ति के प्रमुख को समाप्त नहीं किया जाता है। तीन दिन बाद, वाणिज्यिक निदेशक को। एक हफ्ते में - निर्देशक को।

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

इस पद्धति की मुख्य विशेषताएं: स्टेटस डेटा और उनके स्वचालित अद्यतन का अलग भंडारण। "ऑटो टास्क" के सिद्धांत का उपयोग करके तकनीकी रूप से लागू किया गया, जिस पर बाद में चर्चा की जाएगी।

इस प्रक्रिया में, आपको निश्चित रूप से राज्य की अवधि निर्धारित करने के अन्य तरीके मिलेंगे, अर्थात्। पानी के नीचे आइसबर्ग की भयावहता। आप उन प्रणालियों में प्रोग्रामिंग कर सकते हैं जहां मैंने जिन तरीकों को सूचीबद्ध किया है वे काम नहीं करते हैं - फिर आपको अपने लिए देखना होगा।

मुख्य बात - व्यापार प्रणाली की प्रोग्रामिंग करते समय "आइसबर्ग" के सिद्धांत के बारे में मत भूलना।

खासकर यदि आप विभाजन लेखांकन का उपयोग करना चाहते हैं - इसे डिजाइन के दौरान वापस रखा जाना चाहिए, पूर्वव्यापी रूप से इसे बड़ी कठिनाई के साथ तैनात किया गया है।

अवधि का एक त्वरित मूल्यांकन, "ऑटोटेक्स्स" की तरह, किसी भी समय शामिल किया जा सकता है। खैर, इसे भी बंद कर दें। इस हल्केपन में उनका फायदा है।

मैं अपने अभ्यास से आइसबर्ग का उपयोग करने के कुछ उदाहरण दूंगा।

पहला उदाहरण कार्य प्रबंधन प्रणाली है। कोई कार्य, या एक असाइनमेंट या एक ज्ञापन है। एक सर्जक है, एक कलाकार है। जब कार्य को कार्य में स्वीकार किया जाता है, तो सब कुछ स्पष्ट है - एक समय सीमा है, और आप जल्दी से यह निर्धारित कर सकते हैं कि कार्य के साथ सब कुछ अच्छा है या नहीं।

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

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

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

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

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

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

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

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

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

लेकिन कागज के ऐसे टुकड़े को चकमा देना आसान है। सेल्समैन बोला - तुम मुझे यहाँ किस लिए खिसका रहे हो? हाँ, सोमवार को पर्याप्त आस्तीन नहीं थे, तो क्या हुआ? पहले से ही मंगलवार को इतने सारे थे कि हर कोई बहुत कुछ होता! और आज जो आप सिस्टम में देख रहे हैं वह कल ही पैदा हुआ।

फिर उन्हें कागज के मामलों में भाग लेने के लिए भी मजबूर किया जाता है - वे केवल एक कमी नहीं छापते हैं, बल्कि आपूर्तिकर्ताओं को हस्ताक्षर के लिए भी देते हैं। और डिलीवरी की तारीखों के बारे में पूछा जाता है। आप समझते हैं कि कार्यकुशलता के मामले में प्रक्रिया बहुत अधिक है।

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

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

यदि यह आवश्यक था, उदाहरण के लिए, 100 झाड़ियों, और आपूर्तिकर्ता ने 70 का आदेश दिया, तो ऑटोटस्क बंद नहीं होता है, लेकिन बस समायोजित किया जाता है - अब आपको 30 स्थान रखने की आवश्यकता है। क्या महत्वपूर्ण है नकारात्मक स्थिति की शुरुआत की तारीख, अर्थात्। घाटा वही रहता है। एक व्यक्ति ने एक समय अंतराल के लिए 70 और दूसरे के लिए 30 पदों का आदेश दिया।

आइसबर्ग के आवेदन के साथ, समस्या बहुत जल्दी हल हो गई थी, क्योंकि कुछ भी छिपाना असंभव था। पहला, घाटे की अवधि का लेखा-जोखा पदों और मात्राओं के संदर्भ में किया जाता है, और दूसरा, ठेकेदार के संदर्भ में।तुरंत, निश्चित रूप से, एक निश्चित KPI आपूर्तिकर्ता के लिए पैदा हुआ था - वह कितने प्रतिशत पदों पर समय पर आदेश देता है (ऐसा लगता है कि उसे उस दिन को पूरा करना था, जिस क्षण से आवश्यकता उत्पन्न हुई थी)।

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

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

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

वर्तमान, दैनिक कार्यों की निगरानी के तरीकों से नकारात्मक अवशेषों के निर्माण को रोकना लगभग असंभव है। यहां तक ​​कि अगर आप नकारात्मक में राइट-ऑफ पर प्रतिबंध लगाते हैं, तो भी पल्ली का सुधार होता है। इसलिए, हमारा सभ्य प्रोग्रामर इंतजार करता है और इंतजार करता है।

उदाहरण के लिए, जून के अंत से पहले, प्रोग्रामर, अकाउंटेंट को कई बार याद दिलाता है कि कॉन्स को निकालना अच्छा होगा। समय सीमा के करीब, अधिक आक्रामक जवाब बन जाता है - बंद बकवास, यह आपका व्यवसाय नहीं है, हमें यह नहीं सिखाएं कि कैसे काम करना है, और अंत में, पूर्ण अवहेलना करें।

और फिर जुलाई आया, तिमाही को बंद करना आवश्यक है। अब समस्या को समय के दबाव मोड में हल किया जाना चाहिए - जितनी जल्दी हो सके और कुशलता से, क्योंकि अभी भी बहुत सारे काम करने हैं, सिवाय minuses के। यदि आपने कारखाने में प्रोग्रामर के रूप में काम किया है, तो आप जानते हैं कि इस समय क्या हो रहा है - कार्य जल्दी और खूबसूरती से लेखांकन से प्रोग्रामर तक पहुंचता है।

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

यह आमतौर पर इस तरह समाप्त होता है: प्रोग्रामर अपने हाथों से minuses को ठीक करने के लिए सहमत होता है, और प्रबंधक और लेखाकार समय के दबाव को खत्म करने के बाद इस प्रणालीगत समस्या से निपटने का वादा करते हैं। और इसलिए - हर बार।

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

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

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

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

यदि अनुबंध बहुत महत्वपूर्ण नहीं है और निदेशक के दृष्टि के क्षेत्र में नहीं है, तो समन्वय गतिशील रूप से अंतहीन होगा। और संधियों के सर्जकों के पास समय-समय पर मुख्य लेखाकार को चलाने के अलावा कोई विकल्प नहीं होगा कि यह पता लगाया जा सके कि महान संस्कार कब होगा।

हिमशैल तुरंत और जल्दी से समस्या हल करता है। इस मामले में, यह दो तिथियों को जानने के लिए पर्याप्त है - जब इसे अनुमोदन के लिए भेजा गया था, और जब यह हुआ। इस मामले में असंगति की स्थिति की अवधि की गणना प्रारंभिक रूप से की जाती है, और आप इस समय को सामान्य रूप से सामान्य कर सकते हैं।

मैंने अनुबंधों के समन्वय के साथ ऐसा किया, जहां श्रृंखला में कई लोग शामिल थे - यूनिट के प्रमुख, फाइनेंसर, एकाउंटेंट और वकील। प्रत्येक को अनुमोदन के लिए एक दिन दिया गया था, और आइसबर्ग ने इस अवधि में हिट का प्रतिशत 90% तक लाया।

फिर, समस्या दूसरी तरफ शुरू हुई - जब समझौते पर सहमति हुई और कागज पर हस्ताक्षर किए गए, तो दोनों प्रतियों को उसके हस्ताक्षर और मुहर लगाने के लिए प्रतिपक्ष को भेजा जाता है। तदनुसार, कागज का टुकड़ा फिर से कानूनी विभाग के संग्रह में आने के लिए वापस आना चाहिए।

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

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