“Tell Me About a Time You Improved a Process” (किसी प्रक्रिया को बेहतर बनाने का अनुभव) का उत्तर कैसे दें

प्रॉम्प्ट और लागू संदर्भ

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

Indeed के पास वर्तमान में “उस समय के बारे में बताइए जब आपने किसी प्रक्रिया में सुधार किया” के लिए एक समर्पित गाइड है, जो इस प्रॉम्प्ट को नए विचार प्रस्तावित करने, समस्याओं को हल करने और विवरण के साथ परिणामों का समर्थन करने से जोड़ती है। Aston Carter भी STAR पद्धति को प्रदर्शित करने के लिए इसी प्रोसेस-इम्प्रूवमेंट प्रॉम्प्ट का उपयोग करता है। Acedit की वर्तमान इनिशिएटिव-क्वेश्चन गाइड किसी प्रक्रिया या सिस्टम में सुधार को एक प्रतिनिधि रूपांतर के रूप में सूचीबद्ध करती है और इसे स्वतंत्र निर्णय लेने की क्षमता, साधन-संपन्नता (resourcefulness), और मापने योग्य परिणामों से जोड़ती है। Microsoft Careers STAR(R) की अनुशंसा करता है, जिसमें Situation, Task, Action, और Result के साथ Reflection (चिंतन/आत्म-मूल्यांकन) को जोड़ा जाता है। LinkedIn की चीनी बिहेवियरल-इंटरव्यू गाइड और Interview AiBox की वर्तमान चीनी गाइड भी विशिष्ट, संक्षिप्त और प्रासंगिक उत्तरों के लिए STAR की अनुशंसा करती हैं।

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

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

इंटरव्यूअर क्या मूल्यांकन करता है

पहला संकेत है समस्या की खोज (problem discovery)। एक मजबूत उत्तर की शुरुआत “मुझे लगा कि प्रक्रिया धीमी थी” से नहीं होती है। यह एक दोहराए जाने वाले संकेत की पहचान करता है: प्रतीक्षा समय (wait time), रीवर्क दर (rework rate), त्रुटियों की संख्या, हैंडऑफ्स, बैकलॉग, ग्राहकों की शिकायतें, या कर्मचारियों द्वारा प्रक्रिया को बायपास करना। इंटरव्यूअर को किसी एक आकस्मिक देरी के बजाय एक दोहराई जा सकने वाली अड़चन (bottleneck) के साक्ष्य की आवश्यकता होती है।

दूसरा संकेत है मूल कारण का निर्णय (root-cause judgment)। ऑटोमेशन, फ़ॉर्म में अधिक फ़ील्ड्स जोड़ना, और अधिक बैठकें करना केवल हस्तक्षेप (interventions) हैं, निदान नहीं। समझाएं कि कोई हस्तक्षेप कारण के अनुरूप क्यों था। क्या समस्या अधूरी जानकारी, क्रमिक स्वीकृतियां (serial approvals), अस्पष्ट ओनरशिप, डुप्लिकेट प्रविष्टियां, बहुत बड़े बैच, या कोई पुराना नियम था? इस कदम के बिना, “मैंने पुरानी प्रक्रिया को तेज़ बना दिया” का अर्थ यह भी हो सकता है कि त्रुटियां भी तेज़ी से आगे बढ़ीं।

तीसरा संकेत है उचित सीमाओं के भीतर पहल (initiative within sound boundaries)। सक्रियता का अर्थ किसी ओनर की उपेक्षा करना और एकतरफा नियम बदलना नहीं है। एक परिपक्व उत्तर यह बताता है कि आप क्या बदल सकते थे, किन सुरक्षा या अनुपालन (compliance) नियंत्रणों को बनाए रखना था, अंतिम अनुमोदन किसके पास था, और आपने समर्थन प्राप्त करने के लिए साक्ष्य और एक सीमित प्रस्ताव का उपयोग कैसे किया।

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

पांचवां संकेत है परिणाम का साक्ष्य (result evidence)। मजबूत परिणामों में आमतौर पर तीन स्तर होते हैं:

1. प्राथमिक परिणाम (Primary outcome): क्या साइकिल टाइम, त्रुटियों, लागत, आउटपुट, या ग्राहकों के प्रतीक्षा समय में सुधार हुआ?
2. गुणवत्ता नियंत्रण (Quality guardrail): क्या तेज़ काम ने सुरक्षा, अनुपालन, सटीकता, या ग्राहक अनुभव को नुकसान पहुंचाया?
3. सतत अपनाना (Sustained adoption): क्या प्रक्रिया उपयोग में बनी रही, इसका रखरखाव कौन करता है, और क्या इसका पायलट से आगे विस्तार हुआ?

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

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• क्या पूरे सुधार की शुरुआत मुझे ही करनी चाहिए थी? नहीं। आपको कोई मौजूदा समस्या विरासत में मिल सकती है, लेकिन यह स्पष्ट करें कि आपने क्या खोजा, विश्लेषण किया, डिज़ाइन किया, समन्वय किया या सत्यापित किया। यदि समाधान किसी अन्य व्यक्ति ने बनाया और आपने केवल निर्देशों का पालन किया, तो आपकी पहल (initiative) का संकेत कमजोर होता है।
• क्या प्रक्रिया का कई टीमों में फैला होना आवश्यक है? नहीं। एक जूनियर उम्मीदवार आंतरिक समीक्षा या हैंडऑफ का उपयोग कर सकता है। एक सीनियर उम्मीदवार को अधिक जटिल ओनरशिप, अधिक हितधारकों, या व्यापक रूप से अपनाए जाने वाली कहानी को प्राथमिकता देनी चाहिए, जब ऐसा अनुभव उपलब्ध हो।
• क्या परिणाम के लिए प्रतिशत आवश्यक है? नहीं। सुधार से पहले और बाद का हैंडलिंग समय, रीवर्क रिकॉर्ड, ऑडिट का परिणाम, उपयोगकर्ताओं द्वारा अपनाना, बैकलॉग का समाधान, या विशिष्ट गुणात्मक साक्ष्य काम कर सकते हैं। माप की परिभाषा सुसंगत और तर्कसंगत होनी चाहिए।
• क्या मैं ऑटोमेशन का उदाहरण उपयोग कर सकता हूँ? हाँ, लेकिन ऑटोमेशन केवल एक कार्रवाई है। बताएं कि इसने किस अड़चन को दूर किया, कौन सा मानवीय निर्णय बना रहा, विफलता को कैसे उलटा (rollback) जा सकता था, और क्या उपयोगकर्ताओं ने इसे अपनाया।
• क्या कोई अधूरा सुधार अभी भी एक अच्छी कहानी हो सकता है? हाँ। बताएं कि कौन सी धारणा विफल रही, आपने नुकसान को कैसे सीमित किया, कौन से हिस्से उपयोगी रहे, और आपने कैसे समायोजन किया। किसी मिश्रित परिणाम को झूठी सफलता के रूप में प्रस्तुत न करें।
• क्या मैं व्यक्तिगत उत्पादकता सुधार का उपयोग कर सकता हूँ? यदि अनुभव सीमित है तो कर सकते हैं, लेकिन दिखाएं कि इस पद्धति का अन्य लोगों द्वारा पुन: उपयोग कैसे किया गया या इसने विश्वसनीय डिलीवरी में कैसे सुधार किया। “मैंने एक टूल का उपयोग किया और समय बचाया” में आमतौर पर इसे अपनाने और हितधारकों से निपटने जैसी कठिनाइयों का अभाव होता है।
• प्रक्रिया सुधार सामान्य समस्या-निवारण (problem-solving) से किस प्रकार भिन्न है? प्रक्रिया सुधार बार-बार होने वाले काम के नियमों, क्रम, जानकारी या ओनरशिप को बदलता है और इसके बाद के उपयोग के साक्ष्य होते हैं। अगले चक्र को बदले बिना किसी एक अलग त्रुटि को ठीक करना एक सामान्य समस्या-निवारण प्रॉम्प्ट के लिए अधिक उपयुक्त है।

30-सेकंड का उत्तर ढांचा (Answer Framework)

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

यह ढांचा कार्य-कारण संबंध (causal chain) स्थापित करता है। पूर्ण उत्तर में, अधिकांश समय Action पर व्यतीत करें: आपने कारण को कैसे सिद्ध किया, विकल्पों की तुलना कैसे की, विरोध को कैसे संभाला, और यह कैसे तय किया कि पायलट व्यापक रूप से अपनाए जाने को उचित ठहराता है।

चरण-दर-चरण विस्तृत उत्तर

चरण 1: एक पूर्ण चक्र वाली आवर्ती कहानी चुनें

ऐसी मिसाल को प्राथमिकता दें जिसमें पांच विशेषताएं हों:

1. मूल प्रक्रिया बार-बार दोहराई जाती थी;
2. समस्या ने समय, गुणवत्ता, लागत, जोखिम, या ग्राहकों को प्रभावित किया;
3. आपने व्यक्तिगत रूप से निदान और सुधार में भाग लिया;
4. किसी को काम करने के स्थापित तरीके को बदलना पड़ा;
5. नई प्रक्रिया का एक परिणाम और समीक्षा मौजूद है।

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

तथ्यों वाला एक न्यूनतम वाक्य लिखें: “मूल प्रक्रिया ने [समय सीमा] के दौरान [वस्तु] को संभाला, और आवर्ती परिणाम [देखी जा सकने वाली समस्या] था।” यदि एकमात्र सबूत “लोगों को यह असुविधाजनक लगा” है, तो टिकट, रिकॉर्ड, कैलेंडर, रिपोर्ट, ऑडिट या उपयोगकर्ता प्रतिक्रिया से तथ्यों को पुनः प्राप्त करें।

चरण 2: एक बेसलाइन स्थापित करें और लक्षणों को बाधाओं से अलग करें

दस मेट्रिक्स के बजाय एक प्राथमिक परिणाम और एक गुणवत्ता नियंत्रण (quality guardrail) से शुरुआत करें।

• प्राथमिक परिणाम (primary outcome) यह उत्तर देता है कि प्रक्रिया को बदलना क्यों सार्थक है, जैसे कि सबमिशन से पूरा होने का औसत समय, साप्ताहिक रीवर्क, या प्रति केस हैंडलिंग समय।
• गार्डरेल (guardrail) यह सवाल करती है कि क्या गति ने किसी अन्य चीज़ को नुकसान पहुँचाया है, जैसे कि दोष, नीतिगत अपवाद, ग्राहकों की शिकायतें, डेटा सटीकता, या छूटी हुई समीक्षाएं।

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

फिर प्रक्रिया का ऐसा मानचित्र बनाएं जैसा वह वास्तव में चलती है। कौन सबमिट करता है? छूटी हुई जानकारी कहाँ जोड़ी जाती है? प्रत्येक प्रतीक्षा का कारण कौन बनता है? कौन सी जांचें समानांतर (parallel) हो सकती हैं? काम कहाँ से वापस लौटता है? इन्हें अलग करें:

• लक्षण (symptom): स्वीकृतियां धीमी हैं, कतारें लंबी हैं, त्रुटियां बार-बार होती हैं;
• प्रत्यक्ष कारण (direct cause): आवश्यक जानकारी गायब है, स्वीकृतियां क्रमिक हैं, प्रत्येक अनुरोध समान पथ का अनुसरण करता है;
• मूल कारण (root cause): फ़ॉर्म निर्णय लेने वाली जानकारी एकत्र नहीं करता है, जोखिम को विभाजित नहीं किया गया है, ओनरशिप अस्पष्ट है, या शासी नियम पुराना है।

समाधान तब तक डिज़ाइन न करें जब तक कि प्रत्यक्ष कारण पर्याप्त रूप से स्पष्ट न हो जाए। यदि यह स्पष्ट नहीं है, तो साक्षात्कार, अवलोकन, या एक छोटा रिकॉर्ड नमूना जोड़ें।

चरण 3: डिफ़ॉल्ट रूप से ऑटोमेशन चुनने के बजाय हस्तक्षेपों की तुलना करें

अनुशंसित बदलाव की तुलना में कम से कम एक सरल विकल्प पर विचार करें:

• ऐसा कदम हटाएं जो अब मूल्य पैदा नहीं करता है;
• कार्य को पुनः क्रमित करें ताकि स्वतंत्र जांच समानांतर चल सकें;
• वापस लौटने को कम करने के लिए जानकारी पहले एकत्र करें;
• जोखिम, राशि, या जटिलता के आधार पर रूट करें;
• टेम्प्लेट, चेकलिस्ट या प्रशिक्षण के साथ विविधता (variation) को कम करें;
• स्थिर, नियम-आधारित पुनरावृत्ति को स्वचालित करें।

कार्यान्वयन लागत, विफलता के परिणाम, परिवर्तनीयता (reversibility), रखरखाव ओनरशिप, और अपनाने में आने वाली बाधाओं की तुलना करें। कम आवृत्ति वाली प्रक्रिया के लिए केवल एक चेकलिस्ट की आवश्यकता हो सकती है। जब नियम बदल रहे हों, तो शुरुआती ऑटोमेशन गलत व्यवहार को कोडबद्ध कर सकता है। एक उच्च जोखिम वाले निर्णय में मानवीय अनुमोदन को बनाए रखते हुए स्वचालित प्रीफिल की अनुमति दी जा सकती है।

सिफारिश को एक परीक्षण योग्य परिकल्पना (hypothesis) में संक्षिप्त करें: “यदि सबमिशन के समय पूरी जोखिम जानकारी एकत्र की जाती है और कम जोखिम वाली जांचें समानांतर चलती हैं, तो योग्य अनुरोध नीतिगत अपवादों को बढ़ाए बिना कम प्रतीक्षा करेंगे।” “एक इंटेलिजेंट अप्रूवल प्लेटफ़ॉर्म बनाएं” की तुलना में इसका पायलट बनाना और बचाव करना आसान है।

चरण 4: एक सीमित पायलट डिज़ाइन करें

एक विश्वसनीय पायलट पांच तत्वों को परिभाषित करता है:

1. भाग लेने वाला दायरा, जैसे दो टीमें या एक अनुरोध प्रकार;
2. आरंभ और समाप्ति तिथियां;
3. प्राथमिक परिणाम और गार्डरेल;
4. रोकने या रोलबैक की स्थिति;
5. विस्तार को मंजूरी देने के लिए अधिकृत व्यक्ति।

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

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

चरण 5: विरोध को साक्ष्य के रूप में लें और स्वीकार्यता (adoption) बनाएं

विरोध को केवल “लोग बदलाव पसंद नहीं करते” के रूप में संक्षेप में प्रस्तुत न करें। कारण पहचानें:

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

समर्थन को स्पष्ट प्रतिबद्धताओं में बदलें: टेम्प्लेट को कौन अपडेट करता है, पायलट में कौन शामिल होता है, गार्डरेल की समीक्षा कौन करता है, विस्तार कब तय होता है, और प्रक्रिया का रखरखाव कौन करता है। बैठक में केवल सहमति होना कोई अपनाने का परिणाम नहीं है।

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

चरण 6: परिणामों की तीन परतों के साथ सुधार सिद्ध करें

समान परिभाषा का उपयोग करके बेसलाइन और पायलट की तुलना करें:

1. प्राथमिक परिणाम में बदलाव: साइकिल टाइम, त्रुटियां, लागत, या आउटपुट;
2. गार्डरेल में बदलाव: गुणवत्ता, जोखिम, या ग्राहक परिणाम;
3. स्वीकार्यता और स्थायित्व: उपयोग, कवरेज, ओनर, और समीक्षा तंत्र।

सहसंबंध (correlation) को अनन्य कार्य-कारण (exclusive causation) में न बदलें। यदि उसी समय स्टाफिंग में वृद्धि हुई, अनुरोध की मात्रा में गिरावट आई, या व्यावसायिक दायरा बदल गया, तो उन कारकों का उल्लेख करें। “हमने तुलनीय अनुरोध मात्रा के साथ पायलट के दौरान बदलाव देखा” यह दावा करने से अधिक विश्वसनीय है कि “मैंने पूरा सुधार अकेले किया।”

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

चरण 7: अपने योगदान को अलग करें और ओनरशिप स्थानांतरित करें

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

एक टिकाऊ प्रक्रिया हर किसी को आपके द्वारा याद दिलाए जाने पर निर्भर नहीं हो सकती। बताएं कि टेम्प्लेट या सिस्टम का रखरखाव कौन करता है, परिणामों की कितनी बार समीक्षा की जाती है, कौन सा बदलाव पुनर्मूल्यांकन को ट्रिगर करता है, और पुरानी प्रक्रिया को कैसे हटाया गया। यदि आपके जाने पर नई प्रक्रिया रुक जाती है, तो सुधार पूरा नहीं हुआ है।

चरण 8: फ्रेमवर्क को अपने वास्तविक अनुभव से बदलें

एक वर्कशीट तैयार करें जिसमें शामिल हो:

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

उन सटीक संख्याओं को हटा दें जिनके स्रोत की आप व्याख्या नहीं कर सकते। यदि कोई ऐतिहासिक डैशबोर्ड मौजूद नहीं है, तो टिकट का नमूना, समय रिकॉर्ड, ऑडिट साक्ष्य, या विशिष्ट गुणात्मक परिणाम का उपयोग करें। अंत में, दो मिनट में उत्तर बोलकर दें। जांचें कि Situation और Task संक्षिप्त हैं, Action में वास्तविक निर्णय शामिल हैं, और Result गति, गुणवत्ता और अपनाने को कवर करता है।

उच्च गुणवत्ता वाला नमूना उत्तर

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

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

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

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

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

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

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

उदाहरण को बदलते समय, एक्सेस-अनुमोदन कथानक का पुन: उपयोग न करें। 35 अनुरोधों, दो कार्य दिवसों, 18%, 60 रिकॉर्ड्स, दो टीमों, चार सप्ताह, 14 फ़ील्ड्स, पाँच फ़ील्ड्स, छह कार्य घंटों, 5%, और शून्य अपवादों को अपने अनुभव के तथ्यों से बदलें। कार्य-कारण संरचना को सुरक्षित रखें: बेसलाइन, कारण, वैकल्पिक तुलना, अधिकार सीमा, सीमित पायलट, प्रथम-संस्करण सुधार, तीन-स्तरीय परिणाम, सटीक श्रेय, और विशिष्ट चिंतन।

सामान्य गलतियाँ

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

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: आपने व्यक्तिगत रूप से क्या किया?

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

फॉलो-अप 2: क्या होगा यदि प्रक्रिया ओनर ने आपके प्रस्ताव को अस्वीकार कर दिया हो?

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

फॉलो-अप 3: गति प्राप्त करने के लिए आपने क्या त्याग किया?

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

फॉलो-अप 4: आप कैसे जानते हैं कि वॉल्यूम में गिरावट नहीं आई जिससे यह परिणाम मिला?

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

फॉलो-अप 5: पहले संस्करण में क्या विफल रहा?

एक वास्तविक त्रुटि चुनें: बहुत सारे फ़ील्ड्स, एक छूटा हुआ उपयोगकर्ता समूह, एक असंगत मेट्रिक, या कमजोर प्रशिक्षण। समझाएं कि ऐसा क्यों हुआ, आपने इसका पता कैसे लगाया, इसे ठीक करने की लागत क्या थी, और वह कौन सी जांच है जो अगली बार इसे पहले प्रकट करेगी। “लोगों को तालमेल बिठाने के लिए समय चाहिए था” अपने आप में पर्याप्त नहीं है।

फॉलो-अप 6: आपके जाने के बाद प्रक्रिया कैसे जारी रहेगी?

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

फॉलो-अप 7: यदि परिणाम में सुधार नहीं होता तो आप क्या करते?

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