ग्राहक साइन करता है, सेल्स टीम एक मैसेज भेजती है, और डिलीवरी टीम एक ऐसे ब्रीफ का इंतजार करती है जिसे लिखने की जिम्मेदारी किसी ने ली ही नहीं। फाउंडर बीच में आता है, लेकिन अगले ग्राहक के साथ वही बहस फिर शुरू हो जाती है। सब जानते हैं कि काम जरूरी है। असहमति इस पर है कि उसे आगे कौन बढ़ाएगा।
छोटी टीमों के लिए RACI मैट्रिक्स इन जिम्मेदारियों को साफ दिखाता है। यह काम को चार तरह की भागीदारी के सामने रखता है: रिस्पॉन्सिबल (काम करने वाला), अकाउंटेबल (नतीजा स्वीकार करने वाला), कंसल्टेड (जिससे सलाह ली जाती है) और इन्फॉर्म्ड (जिसे जानकारी दी जाती है)। एक बार-बार होने वाले वर्कफ़्लो से शुरू करें, कमियां पकड़ने के लिए नीचे दिया उदाहरण देखें, और खाली टेम्पलेट को एक साझा डॉक्यूमेंट में कॉपी करें। अगर फैसलों के अधिकार तय करना ही मुश्किल हिस्सा है, तो फ्रैक्शनल COO सेवाएं ऑपरेटिंग प्रोसेस पर मदद के बारे में बात करने का एक तरीका हैं।
1. मैट्रिक्स बनाने से पहले जिम्मेदारी का विवाद पहचानें
समस्या को एक दिखने वाली घटना की तरह लिखें: डिलीवरी को साइन किया हुआ एग्रीमेंट मिलता है लेकिन स्वीकृत स्कोप नहीं, या कोई लॉन्च इसलिए रुका है क्योंकि दो लोग सोचते हैं कि अप्रूवल दूसरा दे सकता है। "खराब कम्युनिकेशन" जैसे बड़े लेबल से बचें। मैट्रिक्स को ऐसा फैसला सुलझाना चाहिए जिसे कोई पहचान सके।
एक शुरुआत और एक अंत चुनें। ग्राहक हैंडऑफ में शुरुआत समीक्षा के लिए उपलब्ध साइन किया हुआ एग्रीमेंट हो सकती है। अंत यह हो सकता है कि डिलीवरी का जिम्मेदार व्यक्ति ब्रीफ स्वीकार करे और ग्राहक को अगला अपडेट देने की जिम्मेदारी ले। प्रॉस्पेक्टिंग और रिन्यूअल को इस पहले नक्शे से बाहर रखें।
इन दोनों बिंदुओं के बीच के आउटपुट की सूची बनाएं। डिलीवरी ब्रीफ तैयार करना, किसी अपवाद को मंजूरी देना और हैंडऑफ स्वीकार करना जैसी पंक्तियां रखें। "ग्राहक संभालना" नाम की पंक्ति इतनी बड़ी है कि उससे पता नहीं चलता कौन सा काम छूट रहा है। हर मैसेज के लिए एक पंक्ति इतनी बारीक है कि उसे अपडेट रखना मुश्किल होगा।
काम करने वाले लोगों को इस चर्चा में शामिल करें। पूछें कि आज वे किस काम को अपना मानते हैं, कहां इंतजार करते हैं और कौन से फैसले नहीं ले सकते। यह ग्रोथ ऑपरेशंस का हिस्सा है: हर स्थिति को फाउंडर की व्याख्या पर छोड़ने के बजाय बार-बार होने वाले काम को एक तय प्रोसेस में बदलना।
2. रिस्पॉन्सिबल और अकाउंटेबल को अलग रखें
Asana की RACI गाइड रिस्पॉन्सिबल को काम करने वाला व्यक्ति और अकाउंटेबल को फैसले का अधिकार रखने वाला व्यक्ति बताती है। यह डिलीवरी से पहले सलाह देने वालों और प्रगति की जानकारी पाने वालों में भी फर्क करती है। आप Asana इस्तेमाल किए बिना भी ये फर्क अपना सकते हैं।
- R, रिस्पॉन्सिबल: आउटपुट तैयार करता है, योगदान देने वालों के साथ तालमेल करता है और रुकावट आने पर बताता है।
- A, अकाउंटेबल: आउटपुट स्वीकार करने का फैसला उसके पास होता है और वह तय स्कोप के भीतर असहमति सुलझा सकता है।
- C, कंसल्टेड: फैसले से पहले जरूरी इनपुट देता है। लिखें कि कौन सा इनपुट चाहिए और कब।
- I, इन्फॉर्म्ड: जरूरी अपडेट पाता है। अपडेट मिलने से एक और अप्रूवल का पड़ाव नहीं बनता।
इस टेम्पलेट में हर पंक्ति के लिए एक अकाउंटेबल व्यक्ति और एक साफ रिस्पॉन्सिबल लीड रखें। दूसरे लोग योगदान दे सकते हैं, लेकिन पंक्ति से यह जवाब मिलना चाहिए कि काम को आगे कौन बढ़ाएगा। यह छोटी टीम के लिए काम करने का एक तरीका है, यह दावा नहीं कि हर संगठन RACI के एक जैसे नियम मानता है।
रिस्पॉन्सिबल और अकाउंटेबल का फर्क तब ज्यादा साफ होता है जब काम लौटा दिया जाता है। रिस्पॉन्सिबल व्यक्ति ब्रीफ दोबारा तैयार करता है। अकाउंटेबल व्यक्ति स्वीकृति का फैसला समझाता है और स्कोप का सवाल सुलझाता है। कोई भी अक्षर पहले की हर समस्या का दोष नहीं दर्शाता। भूमिका निभाने के लिए व्यक्ति के पास जरूरी एक्सेस, समय और अधिकार भी होने चाहिए।
3. छोटी टीम का यह RACI उदाहरण कॉपी करें
काल्पनिक उदाहरण: एक फाउंडर, एक सेल्स लीड और एक डिलीवरी लीड नए ग्राहक को संभालते हैं। ये भूमिकाएं हैं, किसी असली क्लाइंट के बारे में दावे नहीं। खाली सेल का मतलब है कि उस पंक्ति में उस भूमिका की नियमित भागीदारी जरूरी नहीं है। R/A का मतलब है कि वही भूमिका काम करती है और नतीजा स्वीकार करती है।
| आउटपुट या फैसला | फाउंडर | सेल्स लीड | डिलीवरी लीड |
|---|---|---|---|
| स्कोप और वादों का रिकॉर्ड तैयार करना | I | R/A | C |
| स्टैंडर्ड स्कोप से अपवाद का फैसला | A | R | C |
| डिलीवरी हैंडऑफ स्वीकार करना | C | R/A | |
| तय किया गया किकऑफ अपडेट भेजना | I | R/A |
हर पंक्ति को एक वाक्य की तरह जोर से पढ़ें। सेल्स वादों का रिकॉर्ड तैयार करती है, डिलीवरी से व्यावहारिकता पर राय लेती है और फाउंडर को जानकारी देती रहती है। जरूरी जानकारी मिलने पर डिलीवरी हैंडऑफ स्वीकार करती है। फाउंडर हर रूटीन हैंडऑफ मंजूर करने के बजाय सिर्फ स्कोप के अपवाद का फैसला करता है।
अपने वर्कफ़्लो के लिए यह खाली संस्करण कॉपी करें। हर खाली जगह में भूमिका लिखें, या जानबूझकर उसे खाली छोड़ें। एक अलग सूची रखें कि कौन सी भूमिका किस व्यक्ति के पास है, ताकि टीम को पता रहे कि हर कॉलम के पीछे अभी कौन है।
| आउटपुट या फैसला | भूमिका 1 | भूमिका 2 | भूमिका 3 |
|---|---|---|---|
| [पहला आउटपुट] | [R/A/C/I या खाली] | [असाइनमेंट] | [असाइनमेंट] |
| [स्वीकृति का फैसला] | [असाइनमेंट] | [असाइनमेंट] | [असाइनमेंट] |
| [अपवाद का फैसला] | [असाइनमेंट] | [असाइनमेंट] | [असाइनमेंट] |
अपनी कॉपी के नीचे एक छोटा नोट जोड़ें: वर्कफ़्लो का नाम, शुरुआती घटना, अंतिम घटना, मैट्रिक्स का मालिक, भूमिकाएं निभाने वाले लोग, बैकअप व्यवस्था और समीक्षा की तारीख। डेडलाइन और स्वीकृति के मानदंड वर्कफ़्लो के निर्देशों के साथ रखें। सिर्फ अक्षरों से यह पता नहीं चलता कि आउटपुट कब तैयार है।
4. बिना मालिक वाली पंक्तियां और दोहरे अप्रूवल सुलझाएं
बिना R या A वाली पंक्तियां खोजें
पूछें कि काम कौन करेगा और उसे कौन स्वीकार कर सकता है। सबको कंसल्टेड लिख देने से दोनों सवालों का जवाब नहीं मिलता। अगर किसी के पास समय नहीं है, तो उसे एक अक्षर के पीछे छिपाने के बजाय संसाधनों से जुड़ा फैसला दर्ज करें।
अलग अधिकार वाले फैसलों को बांटें
अगर सेल्स और डिलीवरी दोनों अकाउंटेबल दिख रहे हैं, तो देखें कि कहीं एक पंक्ति में दो फैसले तो नहीं हैं। स्कोप की कमर्शियल स्वीकृति और डिलीवरी की तैयारी दो अलग पंक्तियां हो सकती हैं, जिनके अकाउंटेबल लोग अलग हों।
भूमिकाएं सोच-समझकर जोड़ें
फाउंडर ही सेल्स लीड भी हो सकता है। जहां वही व्यक्ति काम करता और स्वीकार करता है, वहां R/A लिखें। सिर्फ कॉलम भरने के लिए नया अप्रूवर न बनाएं। स्वतंत्र समीक्षा की कोई असली जरूरत हो, तो उसे बनाए रखें।
काल्पनिक हैंडऑफ में मान लीजिए सेल्स ब्रीफ को पूरा बता देती है, लेकिन डिलीवरी काम शेड्यूल नहीं कर पाती क्योंकि वादा किया गया एक कस्टम फीचर अभी तय नहीं है। हैंडऑफ को अस्वीकृत रखें, अपवाद फाउंडर के पास भेजें और फैसला ब्रीफ में दर्ज करें। सेल्स के अपडेट को चुपचाप डिलीवरी का अप्रूवल न मान लें।
कॉलम भी देखें। अगर फाउंडर हर पंक्ति में अकाउंटेबल है, तो पूछें कि किन फैसलों को सच में फाउंडर के अधिकार की जरूरत है। अक्षर बदलने से पहले अधिकार को साफ तौर पर बदलें। मैट्रिक्स ऐसा फैसला नहीं सौंप सकता जिसे फाउंडर अब भी निजी तौर पर खुद लेने की उम्मीद रखता है।
5. जिम्मेदारियों को असली हैंडऑफ से जोड़ें
जहां काम शुरू होता है, वहां मैट्रिक्स का लिंक रखें। हर पंक्ति के लिए ट्रिगर, जरूरी इनपुट, स्वीकृति का सबूत और एस्केलेशन का रास्ता दर्ज करें। सेल्स से कस्टमर सक्सेस हैंडऑफ गाइड बताती है कि मालिकों के बीच ग्राहक का कौन सा संदर्भ जाना चाहिए; मैट्रिक्स यह तय करता है कि उसे कौन तैयार करेगा और कौन स्वीकार करेगा।
प्रक्रिया के लिए SOP लिखने का टेम्पलेट इस्तेमाल करें। RACI बताता है कि कौन भाग लेता है। SOP बताता है कि काम कैसे होता है और अच्छी तरह पूरा होने का क्या मतलब है। दोनों डॉक्यूमेंट जुड़े रहें तो निर्देश आपस में नहीं टकराते।
तय करें कि अगर कंसल्टेड व्यक्ति उपलब्ध न हो या अकाउंटेबल व्यक्ति छुट्टी पर हो तो क्या होगा। एक बैकअप का नाम लिखें और बताएं कि बैकअप कौन से फैसले ले सकता है। जब तक टीम ने उस फैसले के लिए साफ तौर पर यह नियम तय न किया हो, चुप्पी को अप्रूवल न मानें।
जब जिम्मेदारी साफ हो फिर भी कोई कदम विफल हो, तो खुद काम की जांच करें। अधूरी जानकारी, आपस में न चलने वाले सिस्टम या असंभव निर्भरता के लिए प्रोसेस इम्प्रूवमेंट की जरूरत हो सकती है। अक्षर बदलने से टूटा हुआ इनपुट ठीक नहीं होगा।
6. काम बदलने पर नक्शे की समीक्षा करें
अपनाने से पहले किसी असली काम को प्रस्तावित मैट्रिक्स से गुजारें। हर भूमिका निभाने वाले से पूछें कि वह आगे क्या करेगा, किस सबूत की उम्मीद करेगा और असहमति को कहां एस्केलेट करेगा। जिस पंक्ति से अलग-अलग जवाब मिलें, उसे बदलें।
इस्तेमाल के बाद अस्वीकृत हैंडऑफ, विवादित फैसलों और उन कामों की समीक्षा करें जिनमें अब भी फाउंडर को दखल देना पड़ा। ये बातें दिखाती हैं कि प्रोसेस में कहां देखना है। ये साबित नहीं करतीं कि प्रदर्शन में सुधार RACI की वजह से हुआ।
जब कोई भूमिका बदले, ऑफर बदले या कोई अपवाद रोज की बात बन जाए, तब नक्शे पर फिर से नजर डालें। एक ही मौजूदा कॉपी और बदलावों का छोटा नोट रखें। अगर वर्कफ़्लो का एक साफ मालिक है और अप्रूवल या सलाह को लेकर कोई उलझन नहीं, तो मालिक और बैकअप की सूची काफी हो सकती है। सबसे छोटा नक्शा रखें जो टीम के असली सवालों का जवाब दे।
एक विवादित वर्कफ़्लो से शुरू करें। हर आउटपुट को एक रिस्पॉन्सिबल लीड और एक अकाउंटेबल फैसला लेने वाला दें, इनपुट और अपडेट में फर्क करें, और तय करें कि अपवाद कैसे आगे बढ़ेंगे। फिर मैट्रिक्स को उस प्रक्रिया से जोड़ें जिसे लोग इस्तेमाल करते हैं।
अक्सर पूछे जाने वाले सवाल
छोटी टीम के लिए RACI मैट्रिक्स क्या है?
RACI मैट्रिक्स किसी वर्कफ़्लो को टीम की भूमिकाओं के सामने रखता है। हर पंक्ति बताती है कि काम कौन करेगा, नतीजा कौन स्वीकार करेगा, किसकी राय जरूरी है और किसे अपडेट मिलेगा। इसे बिज़नेस के हर काम के बजाय जिम्मेदारी की किसी खास समस्या के लिए इस्तेमाल करें।
रिस्पॉन्सिबल और अकाउंटेबल में क्या फर्क है?
रिस्पॉन्सिबल का मतलब है काम करना और उसे आगे बढ़ाना। अकाउंटेबल का मतलब है यह फैसला अपने पास रखना कि नतीजा स्वीकार करने लायक है। इस तरीके में हर पंक्ति में एक ही अकाउंटेबल व्यक्ति और एक साफ रिस्पॉन्सिबल लीड होता है।
क्या एक ही व्यक्ति रिस्पॉन्सिबल और अकाउंटेबल दोनों हो सकता है?
हां। जब एक व्यक्ति काम भी करता है और नतीजा भी स्वीकार करता है, तो R/A लिखें। जहां आपकी असली अप्रूवल या कंट्रोल की जरूरत अलग समीक्षक मांगती है, वहां अलग समीक्षक रखें और उस जरूरत को साफ लिखें।
क्या RACI मैट्रिक्स में दो अकाउंटेबल लोग हो सकते हैं?
इस टेम्पलेट में हर पंक्ति के लिए एक ही अकाउंटेबल व्यक्ति चुनें। अगर दो लोगों को अलग-अलग फैसले मंजूर करने हैं, तो पंक्ति को उन फैसलों में बांट दें। जहां सच में संयुक्त अप्रूवल जरूरी हो, वहां अप्रूवल का क्रम अलग से दर्ज करें।
RACI की जरूरत कब नहीं होती?
जब सबको पहले से पता हो कि काम कौन करेगा और सलाह या अप्रूवल पर कोई विवाद न हो, तब जिम्मेदार लोगों की एक सूची काफी हो सकती है। RACI तब इस्तेमाल करें जब उलझन कई तरह की भागीदारी से जुड़ी हो, और दायरा इतना छोटा रखें कि उसे अपडेट रखा जा सके।
यह तय करने में मदद चाहिए कि अगला कदम किसका है?
हैंडऑफ या अप्रूवल की कोई बार-बार आने वाली समस्या लेकर आइए। हम जिम्मेदारी की कमियों, उनसे जुड़े फैसलों और इस पर बात कर सकते हैं कि क्या एक सीमित ऑपरेशंस एंगेजमेंट सही रहेगा।
कॉल बुक करें