प्रोग्रामर ओझा

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

मेरा लेख छोटी बुराई के बारे में है। कार्यान्वयन की तोड़फोड़ के बारे में, शाश्वत के बारे में "मैं सब कुछ ठीक कर रहा हूं, यह आपके दोष का कार्यक्रम है", ब्लोटिंग के बारे में, छोटे कॉर्पोरेट संबंध और बदलने के प्रतिरोध के बारे में।

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

बस कुछ उपकरणों और उदाहरणों का उपयोग करने का अनुभव है कि उन्होंने मुझे कैसे मदद की।

उपयोगकर्ता मापदंडों को समय मापदंडों के साथ रिकॉर्ड करना

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

सिद्धांत सरल है:

• जब उपयोगकर्ता प्रपत्र खोलता है (दस्तावेज़, निर्देशिका, रिपोर्ट, प्रसंस्करण);
• जब वह इसे बंद करता है तो नोट्स लेता है;
• रिकॉर्ड जब उसने इसे दर्ज किया (यदि यह एक संग्रहीत वस्तु है, जैसे कि दस्तावेज़ या निर्देशिका);
• रिकॉर्ड करता है कि यह एक नई वस्तु थी, या एक पुरानी थी;
• ऑब्जेक्ट के बारे में आपको जो कुछ भी जानना है, उसे रिकॉर्ड करता है - लिंक, टाइप नाम, उपयोगकर्ता नाम, फॉर्म नाम।

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

जब तंत्र काम आएगा तो मैं उदाहरण दूंगा।

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

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

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

तीसरा उदाहरण। लेखांकन कहता है - हमें कर्मचारियों का विस्तार करने की आवश्यकता है, हमने दस्तावेज़ प्रवाह बढ़ाया है। प्रबंधन, मेरी रिपोर्ट के प्रति सतर्क, पूछा जाता है - आंकड़े दें, वहां क्या और कहाँ बढ़े हैं।

माथे में पहली गिनती - दस्तावेजों की संख्या और उनमें लाइनों की संख्या - दिखाया गया है कि दस्तावेज़ प्रवाह में वृद्धि नहीं हुई।

ठीक है, मुझे लगता है, शायद दस्तावेजों में कुछ जटिल है, वास्तव में उन्हें खींचना अधिक कठिन हो सकता है।

मैं दो खातों के लिए "औसत जांच" और इसकी गतिशीलता को देखता हूं - नहीं, ऐसा लगता है कि यह बढ़ता नहीं है, यह गिरता नहीं है।

यह उस पर dawned कि एक लंबे समय से काम कर रहे एकाउंटेंट हाल ही में मातृत्व अवकाश पर चला गया था, और दो नए लोग उसकी जगह ले रहे थे। मेरे पास तीनों के लिए डेटा था, मैं तुलना करता हूं - बाह, यहां यह है। दो नए एकाउंटेंट एक से अधिक पुराने दस्तावेजों को धीरे-धीरे दर्ज करते हैं।

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

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

मीट्रिक मान रिकॉर्ड करें

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

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

लेकिन कुछ संख्याएँ केवल बैकअप डेटाबेस बढ़ाकर पुन: प्रस्तुत की जा सकती हैं। उदाहरण के लिए, यह पता लगाने का एकमात्र तरीका है कि आपके पास एक महीने पहले माल पर कितने नकारात्मक संतुलन हैं। जो लोग मेरे पिछले लेख पढ़ते हैं वे समझते हैं कि यह आइसबर्ग के बारे में है।

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

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

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

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

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

मैंने प्रत्येक आपूर्तिकर्ता के लिए व्यक्तिगत रूप से दो संकेतकों का रिकॉर्ड नीचे रखा है - सुबह ऑर्डर करने के लिए कितने आइटम उपलब्ध थे, उनमें से कितने दिन के दौरान ऑर्डर किए गए थे। और वोइला - "अच्छी" प्रबंधक (नीली लड़की) ने 85-100% का आदेश दिया कि सिस्टम को क्या चाहिए, "बुरे" वाले - 15%। सब कुछ, अनुशासन के साथ काम चला गया है। क्या दिलचस्प है - आपूर्तिकर्ताओं, इस रिपोर्ट को देखकर, उन्हें इसे उपयोग के लिए देने के लिए कहा गया था (आपूर्तिकर्ता स्वयं, और उनके पर्यवेक्षक नहीं)। मेरा और उनकी रिपोर्ट के बीच अंतर सरल था। उनकी रिपोर्ट में वर्तमान अवशेषों को दिखाया गया था, और मेरा अभी भी इन अवशेषों का "जीवनकाल" दिखाया गया था। सभी एक ही आइसबर्ग।

विचारों को ठीक करना

कई बार मैंने प्रोग्रामर्स से सुना है कि उनसे विचार चुराए गए थे, खासकर बॉस। वे इस विचार को सुनते हैं, फिर वे कहते हैं कि यह कुछ भी नहीं है, और कुछ समय बाद वे इसे अपना मानते हैं।

मेरे पास आमतौर पर बहुत सारे विचार हैं, मैं गुणवत्ता का न्याय नहीं करूंगा, लेकिन वास्तव में उनमें से बहुत सारे हैं। मैंने कुछ साल पहले देखा कि मुझे उनकी याद नहीं है। ऐसा होता है कि मैं कई बार एक विचार के साथ आता हूं।

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

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

लब्बोलुआब यह है कि विचार सार्वजनिक और निश्चित हो गए हैं, और उन्हें चोरी करना मुश्किल हो गया है। मेरा लगभग असंभव है, क्योंकि जिस समय यह सिस्टम उपयोगकर्ताओं के लिए खोला गया था, उसमें पहले से ही मेरे कई सौ रिकॉर्ड थे।

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

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

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

प्रदान किए गए डेटा, प्रक्रिया जमीन से दूर चली गई है।

डेटा कैप्चर

इस तंत्र का उद्देश्य संस्करण क्षमताओं का विस्तार करना है। आमतौर पर संस्करण (मानक और गैर-मानक दोनों) प्राथमिक डेटा में परिवर्तन को कैप्चर करता है - निर्देशिका, दस्तावेज, आदि। वास्तविक व्यवहार में, यह पर्याप्त नहीं है।

उदाहरण के लिए, "मक्खी" के विभिन्न रूपों के साथ "उड़ गया"। पारंपरिक तरीका या तो उन दस्तावेजों में बदलावों को देखना है जो प्रभावित कर सकते हैं, या बैकअप बढ़ा सकते हैं, एक्सेल पर विस्तार से अपलोड कर सकते हैं और क्रांतियों की तुलना कर सकते हैं।

समस्या यह भी है कि एक व्यक्ति को "स्पिन-ऑफ" के क्षण को ट्रैक करना चाहिए।

नतीजतन, उन्होंने एक सरल तंत्र बनाया जो क्रांतियों की जटिल संरचना को खूबसूरती से संग्रहीत करता है और परिवर्तनों पर प्रतिक्रिया करता है। और तय करने के लिए डेटा क्षेत्र, और दृढ़ संकल्प, और आवधिकता - एक क्वेरी के माध्यम से कॉन्फ़िगर किया गया है।

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

हां, और उसने "परिवर्तनों को स्वीकार करने" की अनुमति दी - यदि सब कुछ ईमानदार था, तो परिवर्तित डेटा संदर्भ बन गया, और परिवर्तन पर पहले से ही नज़र रखी जा रही थी।

पहले उपयोग का मामला। लोग गोदाम में वृद्धि के बारे में शिकायत करने लगे ("मैं सुबह 10 बजे देखता हूं, मैं दोपहर के भोजन पर 5 देखता हूं, और मैंने पहले से ही ग्राहक से वादा किया है, और मैं मूर्ख नहीं हूं, मैं देखता हूं कि एक सप्ताह तक कोई आंदोलन नहीं हुआ है")। लेखांकन कहता है - हमें इससे कोई लेना-देना नहीं है, सभी दस्तावेजों को एक दिन के भीतर निष्पादित किया जाता है, कोई सुधार पूर्वव्यापी नहीं। हम तंत्र - वॉइला को देखते हैं, आज संतुलन बदल रहा है, क्योंकि पिछले महीने की गति बदल गई है। आसपास झाँका - एक महीने पहले एकाउंटेंट ने एक नया दस्तावेज़ पेश किया। हम पूछते हैं - क्या कर रहे हो? मेरे पास समय नहीं है, वह कहती है।

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

नियंत्रण के लिए प्रश्न

कार्यात्मक नियंत्रण कार्य, परियोजनाएं आदि। उदाहरण के लिए, 1 सी में: दस्तावेज़ प्रबंधन, शायद बहुतों ने देखा है। वहां आप किसी भी (या लगभग किसी भी) ऑब्जेक्ट को नियंत्रित कर सकते हैं, एक तिथि निर्धारित कर सकते हैं, और एक अनुस्मारक पॉप अप कर सकते हैं।

मुझे यह पसंद नहीं आया, क्योंकि यह आपको नियंत्रण को बहु-मंच बनाने की अनुमति नहीं देता है - उदाहरण के लिए, रिमाइंडर को एक सप्ताह के अंतराल पर 10 बार पॉप अप करने के लिए। इसलिए, मैंने अपना सरल तंत्र बनाया, जिसका मुख्य अंतर यह है कि यह आपको नियंत्रण का इतिहास रखने और किसी भी लम्बाई के लिए इसे लंबा करने की अनुमति देता है।

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

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

स्वचालन लागत लेखांकन

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

हम प्रोग्रामर का वेतन लेते हैं और इसे एक महीने में हल किए गए कार्यों में वितरित करते हैं। यह एक विशिष्ट समस्या को हल करने की लागत का पता लगाता है। यह परियोजना द्वारा, ग्राहक द्वारा, इकाई द्वारा इकट्ठा किया जा सकता है।

उपयोग का पहला उदाहरण टक्करों के खिलाफ सुरक्षा है जैसे "वे हमारे साथ व्यवहार नहीं करते हैं, वे हमारी समस्याओं को हल नहीं करते हैं"। हम रिपोर्ट खोलते हैं, देखो - हाँ, कंपनी ने लेखांकन के स्वचालन पर 250 tr खर्च किए पिछले महीने के लिए। या 1.5 मिलियन रूबल एक वर्ष, उदाहरण के लिए।

यहाँ चाल यह है कि यह रूबल में मूल्यवान है - माप की एक इकाई जो निर्देशक के लिए समझ में आती है। यदि आप कहते हैं कि "हमने लेखांकन विभाग से 113 कार्यों को हल किया है", तो वह घुसना नहीं करेगा - वह कहेगा कि और अधिक करने की आवश्यकता है। और जब आप कहते हैं कि "आपने उनके कार्यों पर 1.5 मिलियन खर्च किए हैं", तो उन्हें यह कहने में शर्मिंदगी होगी कि "मेरे 2 मिलियन रुपये उन पर खर्च करें!"। अधिक बार नहीं, उन्होंने बुदबुदाया और बहीखाता कार्यालय से पूछा कि वे कौन से कार्य हैं जिनके लिए 1.5 मिलियन रूबल खर्च किए जाने चाहिए।

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

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

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

और हमने लागतों की गणना की है। मान लीजिए कि यह 30 tr है। हम मेटाडेटा को जानते हैं, जिन वस्तुओं को हम जानते हैं, हम एक को दूसरे में विभाजित करते हैं - यह पता चलता है कि हमारे सिस्टम में 30 टीआर एक मापने वाले उपकरण के लिए लेखांकन पर खर्च किए जाते हैं हालांकि मापने वाले यंत्र की कीमत 1 ट्रि है।

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

समर्थन लागत लेखांकन

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

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

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

अच्छा, तो यह आसान है। तकनीकी सहायता की कुल लागत पिछले पैराग्राफ से हमें ज्ञात है। हम पैसे को अपील के समय से विभाजित करते हैं, हमें यह आंकड़ा मिलता है - कंपनी किस तरह के व्यक्ति और विभाग को खुद पर खर्च करती है।

पहला उपयोग मामला आम है। जब कोई कहता है कि वे उसके सवालों का जवाब नहीं देते हैं, और वह बुरी तरह से कर रहा है, तो हम आंकड़ा दिखाते हैं। देखो, मेरे दोस्त, कंपनी आपके सवालों पर 20 tr खर्च करती है प्रति माह।

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

और अब एक लेखाकार है जिसे 30 tr का भुगतान किया जाता है। प्रति माह, करों को छोड़कर। और इस लेखाकार को प्रदान की गई तकनीकी सहायता की लागत है। उदाहरण के लिए, 20 ट्र प्रति माह - प्रोग्रामर महंगे हैं। यह पता चला है कि लेखाकार कंपनी की लागत 50 tr है प्रति माह। उदाहरण के लिए, उप मुख्य लेखाकार को एक ही राशि खर्च होती है।

निर्देशक इन आंकड़ों से थोड़ा निराश था। यह सुनना एक बात है: “हम 50 tr खर्च करते हैं। उपयोगकर्ताओं की तकनीकी सहायता के लिए प्रति माह ”- ठीक है, आपको करने की आवश्यकता है। एक पूरी तरह से अलग मामला - “इस लेखापाल की अक्षमता की कीमत हमें 20 tr है। प्रति माह। " तकनीकी सहायता के लिए कम कॉल हैं।

Nezabyvayka

, , — . , - , . , .

, « ». — .

— , , . .

, - , - , , . क्योंकि , — .

— . — . - .

, 1, CouchDB, — . — , , .

, , , , , . खैर, सिर्फ मामले में।

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

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

, view . , , , , . , . , — . — , , - — . — , , .

. , , DDoS' — , , . .

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

सहसंबंध स्वचालन और KPI

कई प्रोग्रामर, उनके वरिष्ठ और निदेशक व्यवसाय पर स्वचालन के प्रभाव के बारे में चिंतित हैं। प्रोग्रामर, पूरी की गई परियोजनाओं और हल किए गए कार्यों के लिए लागतें हैं। और लोगों, विभागों, दिशाओं और उनके नेताओं के KPI हैं।

यह माना जाता है कि स्वचालन लाभकारी होना चाहिए, या, जैसा कि वे मजाक में कहते हैं, "लाभ"। लेकिन वास्तव में क्या होता है आमतौर पर ज्ञात नहीं है।

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

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

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

KPI , , . , , 200 .. — KPI . , , , , , . . ?

, . , — , KPI . , .. , .

. , CRM , . , , .

, , .

, , — . — , . — , , , . , .

. , . , — .

, , . , - , .