अगर आपको समझ नहीं आ रहा कि कहाँ से शुरू करें, तो इसका सिर्फ एक ही जवाब है: सिस्टम को व्यवस्थित (systematize) मत कीजिए। पहले यह सवाल पूछिए कि क्या हटाया जा सकता है।
पहले मैंने लिखा था कि सिस्टम डेवलपमेंट की विफलताएँ संरचनात्मक समस्या हैं, न कि प्रबंधकीय ज्ञान की कमी। उसी ढांचे पर आधारित, यह लेख उन वास्तविक शुरुआती कदमों पर चर्चा करता है जो ग्राहकों को उठाने चाहिए। जब आप अनिश्चित हों, तो "बस सिस्टम बना लो" का विकल्प चुनना आपके लिए सबसे महंगा निर्णय साबित हो सकता है। अगर आप क्रम गलत रखते हैं, तो आप बस अक्षम प्रक्रियाओं को स्वचालित करने में पैसा खर्च कर रहे होते हैं।
■ भ्रम: "सिस्टम बनाना = समाधान"
ग्राहकों के साथ परामर्श करते समय, पहली मांग लगभग हमेशा एक ही होती है: "हमारे ऑपरेशन अक्षम हैं, इसलिए हमें एक सिस्टम लागू करना है।" हालांकि, गहराई से देखने पर पता चलता है कि अधिकांश मामलों में वे अपव्यय (waste) मौजूद होता है जिसे किसी भी सिस्टम को लागू करने से पहले ही सुलझाया जा सकता था।
उदाहरण के लिए, एक कंपनी के कोटेशन (quotation) प्रक्रिया पर विचार करें। उन्होंने सेल्स स्टाफ को नए सिस्टम में कोटेशन बनाने की अनुमति दी थी, लेकिन आंतरिक मंजूरी के लिए अब भी कागजी फॉर्म छापने और उन्हें हाथ-हाथ घुमाने की जरूरत पड़ती थी। मंजूरी के बाद, स्टाफ को डिजिटल कोटेशन से रकम को दोबारा कागजी फॉर्म में हाथ से दर्ज करना पड़ता था। "सिस्टम बनाने" के बावजूद, समग्र वर्कफ्लो में एक कदम जुड़ गया: "सिस्टम में बनाएं, कागज पर कॉपी करें।" मूल कारण यह था कि सिस्टम बनाने से पहले किसी ने यह सवाल नहीं पूछा, "क्या हम कागजी मंजूरी की प्रक्रिया को पूरी तरह हटा सकते हैं?" लाखों रुपये निवेश किए गए, लेकिन जिस अपव्यय को काटा जाना चाहिए था, उसे स्वचालित करने के कारण उस लागत का अधिकतर हिस्सा बेकार चला गया।
■ जोड़ने से पहले काटें
व्यावसायिक सुधार के लिए एक पुराना सिद्धांत है जिसे ECRS कहा जाता है: Eliminate (क्या इसे हटाया जा सकता है?), Combine (क्या इसे मिलाया जा सकता है?), Rearrange (क्या क्रम बदला जा सकता है?), Simplify (क्या इसे सरल बनाया जा सकता है?)? इन चारों पर पूरी तरह विचार करने के बाद ही आपको Automate (सिस्टम बनाना/स्वचालन) पर विचार करना चाहिए।
कई प्रोजेक्ट मैनेजर इस क्रम को छोड़ देते हैं और सीधे "Automation" पर कूद जाते हैं। इसके परिणामस्वरूप, जिन कार्यों को हटा दिया जाना चाहिए था, जिन डबल एंट्रीज को मिलाया जा सकता था, और जिन मंजूरी प्रवाहों को सरल बनाया जा सकता था, उन्हें सीधे सॉफ्टवेयर में शामिल कर दिया जाता है। नतीजा होता है एक ऐसा सिस्टम जो बेकार के कार्यों को तेजी से और अधिक सटीकता से करता है। विडंबना यह है कि क्योंकि उन्हें लगता है कि उन्होंने "सिस्टम बना लिया है," इसलिए कोई भी उस छिपे हुए अपव्यय को नहीं देख पाता।
यह मेरे पिछले बिंदु से मेल खाता है कि सिस्टम डेवलपमेंट की विफलताएँ संरचनात्मक हैं, अज्ञानता के कारण नहीं। ECRS अनुक्रम को छोड़ देना उसी दोषपूर्ण संरचना का हिस्सा है।
■ निर्णय लेने के लिए चार सवाल
सिस्टम बनाने पर विचार करने से पहले, खुद से ये चार सवाल क्रम से पूछें:
- क्या इस कार्य को पूरी तरह हटाया जा सकता है? (Eliminate)
- क्या कई कार्यों या विभागीय वर्कफ्लो को मिलाया जा सकता है? (Combine)
- क्या केवल क्रम या जिम्मेदारी बदलने से सुधार किया जा सकता है? (Rearrange)
- क्या विधि को ही सरल बनाया जा सकता है? (Simplify)
इन सवालों के जवाब देने के बाद जो कार्य बचते हैं, वही सिस्टम बनाने के उम्मीदवार होते हैं। इसके विपरीत, अगर आप इन चारों पर विचार किए बिना ही रिक्वायरमेंट्स डेफिनिशन (requirements definition) में प्रवेश करते हैं, तो विफलता के बीज पहले से बो दिए जाते हैं।
■ गति की इच्छा को संबोधित करना
आप तर्क दे सकते हैं, "हमारे पास सोचने का समय नहीं है; हमें सिस्टम जल्दी लागू करना है।" हालांकि, ECRS विश्लेषण आमतौर पर केवल कुछ दिनों या हफ्तों का समय लेता है। इसके विपरीत, अगर जल्दबाजी में बनाया गया सिस्टम बाद में रिक्वायरमेंट्स डेफिनिशन को दोबारा करने की मांग करता है, तो आपको महीनों का नुकसान होता है। जल्दबाजी अक्सर भटकने का कारण बनती है।
एक अन्य आपत्ति यह हो सकती है, "हमारे ऑपरेशन बाहरी फ्रेमवर्क के लिए बहुत जटिल हैं।" लेकिन ECRS के लिए गहन संचालन ज्ञान की आवश्यकता नहीं होती है। विवरण जानने वाले लोग फ्रंटलाइन स्टाफ होते हैं; ECRS केवल प्रश्नों का एक अनुक्रम है जो उन्हें यह पूछने के लिए प्रेरित करता है, "क्या इसे हटाया जा सकता है?" या "क्या इसे मिलाया जा सकता है?" इसे विशेषज्ञता के बिना आज ही इस्तेमाल किया जा सकता है।
■ कल आप क्या कर सकते हैं
किसी विशाल संगठनात्मक बदलाव की आवश्यकता नहीं है। वर्तमान में जिस एक कार्य को आप "सिस्टम बनाना" चाहते हैं, उसे चुनें और ऊपर दिए गए चार सवालों के जवाब दें। अक्सर, पहला सवाल (Eliminate) आपको ऐसे विकल्प दिखाता है जिन पर आपने पहले विचार नहीं किया था।
"कहाँ से शुरू करें, यह न जानने" का वास्तविक कारण आमतौर पर यह नहीं होता कि सिस्टम बनाना है या नहीं, बल्कि यह होता है कि सिस्टम बनाने से पहले किस चीज़ का विश्लेषण करना है। अगर आप सही क्रम का पालन करते हैं, तो निर्णय लेना मुश्किल नहीं होता।
अगली बार, मैं प्रबंधकों के लिए सबसे सामान्य पीड़ा "लोगों का नौकरी छोड़कर जाना" (People quitting) पर चर्चा करूंगा। हम टर्नओवर दरों के पीछे की संगठनात्मक संरचनाओं पर बात करेंगे।
अगर आप रुचि रखते हैं, तो कृपया इस लिंक के माध्यम से मुझे DM करें।
■ संबंधित पिछले लेख
