कंपनी के भीतर सीमा नियंत्रण का स्वचालन

व्यावसायिक प्रोग्रामिंग पर एक पाठ्यपुस्तक का एक और टुकड़ा।

सीमा प्रक्रियाएं सबसे अच्छी स्वचालित हैं। यह सुनने में अटपटा लगता है, लेकिन ऐसी सिफारिश हमेशा लागू होने से दूर है।

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

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

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

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

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

इसलिए, हमें एक स्वचालित सीमा नियंत्रण प्रणाली की आवश्यकता है। इसकी कई महत्वपूर्ण आवश्यकताएं हैं।

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

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

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

दूसरी आवश्यकता यह है कि कतार को कार्यों से पहले विघटित किया जाना चाहिए, अर्थात्। सरल संस्थाओं के लिए जिन्हें समझने योग्य कार्यों की आवश्यकता होती है। ऐसा होता है कि कतार की पहचान की जाती है, लेकिन विभिन्न प्रक्रियाओं के कार्यों को इसमें मिलाया जाता है। इस मामले में, क्यू की नियंत्रणीयता और नियंत्रणीयता एक गंभीर प्रश्न है।

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

तीसरी आवश्यकता यह है कि कार्यों को पूरा करने की प्राथमिकताएँ स्पष्ट होनी चाहिए। सिद्धांत पिछले मानदंडों में समान है। यदि आप, पक्ष से कतार को देखते हैं, कार्यों का क्रम देखते हैं, तो प्राथमिकताएं स्पष्ट हैं। यदि आप या प्रक्रिया के उपभोक्ता, कर्मचारी को प्राथमिकताओं के बारे में पूछना चाहते हैं, या हर दिन इन प्राथमिकताओं को रीसेट करना चाहते हैं, तो कतार खराब तरीके से प्रबंधित की जाती है।

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

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

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

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

पांचवीं आवश्यकता कोई फर्क नहीं पड़ता कि कैसे ट्राइट, लेकिन कार्य के निष्पादक को पता होना चाहिए। यदि ठेकेदार की पसंद को एक स्वचालित एल्गोरिथ्म द्वारा विनियमित किया जाता है, तो इस एल्गोरिथ्म को निष्पादित करने के क्षण को समझा जाना चाहिए।

जब तक कार्य में कोई निष्पादक नहीं है, तब तक इसे हल नहीं किया जाएगा। ठेकेदार को प्रत्येक विशिष्ट कार्य को सौंपा नहीं जाना चाहिए - यह समझने के लिए पर्याप्त है कि पहचाने गए कतार के सभी कार्यों का समाधान एक विशिष्ट व्यक्ति को सौंपा गया है।

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

कसौटी सरल है: लाइन के किनारे से देखने पर, आपको यह पता होना चाहिए कि कार्य कौन करेगा।

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

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

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

आंशिक रूप से मदद प्रक्रिया नियंत्रण प्रणाली है जो एकल संस्थाओं में प्राथमिक दस्तावेजों की एक किस्म को "स्ट्रिंग" करती है। इस तरह से प्रोसेस कार्ड, कॉमन टास्क और एड्रेसिंग एंटिटीज दिखाई देते हैं।

लेकिन एक व्यावसायिक प्रोग्रामर के लिए, अफसोस, यह दृष्टिकोण बहुत उपयुक्त नहीं है।

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

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

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

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

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

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

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

"प्रबलित कंक्रीट" प्रक्रियाओं को खींचने का तरीका एक सहायक के रूप में इस्तेमाल किया जा सकता है, बहुत नुकसान नहीं होगा। या, इसे प्रोजेक्ट के अंत में कॉन्फ़िगर की गई प्रक्रियाओं को संरक्षित करने के तरीके के रूप में इस्तेमाल किया जा सकता है। अगली परियोजना तक।

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

"ऑटो टास्क" या इसी तरह के सिद्धांत का उपयोग करना बेहतर होता है जब आपके सिस्टम में ऐसी इकाइयाँ होती हैं जो चल रही प्रक्रियाओं में "संलग्न" कर सकती हैं और एक कतार में कार्यों का निर्माण कर सकती हैं। सिद्धांत स्वयं बाद में माना जाएगा।

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

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

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

अपनी स्पष्ट सादगी और स्पष्टता के बावजूद, सभी प्रक्रियाओं का ऐसा तात्कालिक मूल्यांकन अत्यंत दुर्लभ है। अब आप समझ गए क्यों।

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

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