अपने भागीदार नेटवर्क के लिए परिपक्वता मॉडल कैसे बनाएं

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

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

परिपक्वता मॉडल क्या है और यह विचार कहां से आया

नवंबर 1986 में, Carnegie Mellon University के Software Engineering Institute ने एक प्रक्रिया परिपक्वता ढांचा विकसित करना शुरू किया। यह काम अमेरिकी संघीय सरकार के अनुरोध के जवाब में किया गया था, ताकि उसके सॉफ़्टवेयर ठेकेदारों की क्षमता का आकलन किया जा सके। 1993 तक यह सॉफ़्टवेयर के लिए Capability Maturity Model बन गया, जिसके पांच परिपक्वता स्तर, SEI के अपने शब्दों में, “एक क्रमिक पैमाना निर्धारित करते हैं” [1]।

इसका मूल स्वरूप आज भी कायम है: विकास के एक अनुमानित, वांछित या सामान्य मार्ग का वर्णन करने वाले अलग-अलग चरणों की श्रृंखला [2]। हर स्तर बताता है कि उस तक पहुंचने के लिए क्या सच होना चाहिए, इसलिए आकलन से संगठन की स्थिति और अगला कदम सामने आता है। 2005 तक IT सेवाओं से लेकर ज्ञान प्रबंधन तक के क्षेत्रों में 150 से अधिक परिपक्वता मॉडल मौजूद थे [3]। फिर भी, जब Becker, Knackstedt और Pöppelbuß ने उनमें से 51 का अध्ययन किया, तो केवल नौ में डिज़ाइन प्रक्रिया का विस्तृत दस्तावेज़ीकरण था [2]। आगे दी गई विधि उसी शोध पर आधारित है, जिसे कार्यक्रम टीमों के लिए अनुकूलित किया गया है।

आठ चरणों में परिपक्वता मॉडल कैसे बनाएं

ये चरण de Bruin, Rosemann, Freeze और Kulkarni द्वारा किसी भी परिपक्वता मॉडल के विकास के लिए प्रस्तावित चरणों का अनुसरण करते हैं: दायरा तय करना, डिज़ाइन करना, सामग्री भरना, परीक्षण करना, लागू करना और बनाए रखना [3]। हर फ़ैसला अगले चरण की सीमाएं तय करता है, और पायलट के बाद आपको विवरण कम-से-कम एक बार फिर से लिखने होंगे।

1. तय करें कि मॉडल का उद्देश्य क्या है

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

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

2. आयाम चुनें

आयाम वे विषय हैं जिन्हें मॉडल कवर करता है: शासन, वित्त, डिजिटल कौशल, सुरक्षा और संरक्षण, युवाओं की भागीदारी। जटिलता सीमित रखने और आयामों को स्वतंत्र बनाए रखने के लिए उनकी संख्या कम रखें (de Bruin और उनके सहयोगियों के दो मॉडलों में क्रमशः छह और चार मुख्य घटक थे)। उन्हें परस्पर अनन्य और सामूहिक रूप से संपूर्ण भी बनाएं [3]: किसी साक्ष्य की गणना दो बार न हो, और आपके उद्देश्य के लिए ज़रूरी कुछ भी छूटना नहीं चाहिए। मेरा लक्ष्य चार से सात आयामों का होता है, और व्यापक विषयों को दो या तीन उप-आयामों में बांटा जाता है।

अपना मॉडल लिखने से पहले देखें कि पहले से क्या मौजूद है: Becker और उनके सहयोगियों ने नया मॉडल बनाने के लिए मौजूदा मॉडलों से तुलना को पहली ज़रूरत बताया था [2]। क्षमता सुदृढ़ीकरण के लिए, Venture Philanthropy Partners हेतु McKinsey का 2001 का ग्रिड सात तत्वों का एक मज़बूत शुरुआती आधार है [5]। हमारे भागीदार क्षमता आकलन गाइड में दिए गए छह क्षेत्र भी उपयोगी हैं।

3. चार या पांच स्तर चुनें

CMM में पांच स्तर हैं [1]; McKinsey के ग्रिड में चार [5]। संख्या से ज़्यादा अहम de Bruin और उनके सहयोगियों की यह शर्त है: चरण स्पष्ट रूप से अलग और अच्छी तरह परिभाषित हों, तार्किक रूप से आगे बढ़ें और हर चरण का छोटा-सा नाम उसका उद्देश्य बताए [3]।

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

4. हर स्तर को ऐसी स्थिति के रूप में लिखें जिसे देखा जा सके

अधिकांश मॉडल यहीं विफल होते हैं। विवरण ग्रिड के किसी एक खाने में लिखा पाठ होता है। Pöppelbuß और Röglinger उपयोगी परिपक्वता मॉडल के डिज़ाइन सिद्धांतों में ऐसे मानदंड शामिल करते हैं जिन्हें अलग-अलग लोग जांचकर सत्यापित कर सकें: विवरण इतना सटीक और स्पष्ट हो कि एक स्तर को अगले स्तर से अलग पहचाना जा सके [4]। सीधे शब्दों में: एक ही भागीदार को देखकर दो लोगों को एक ही खाना चुनना चाहिए।

तीन आदतें मददगार हैं:

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

5. हर स्तर के लिए साक्ष्य तय करें

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

6. भागीदारों के साथ मॉडल का सत्यापन करें

मसौदा उन लोगों को दिखाएं जिन्हें इसके साथ काम करना होगा। de Bruin और उनके सहयोगियों ने अपने मॉडल बनाने और जांचने के लिए डेल्फ़ी तकनीक और फ़ोकस समूहों का इस्तेमाल किया [3]; McKinsey ने लगभग एक दर्जन गैर-लाभकारी संगठनों के कार्यकारी निदेशकों के साथ अपने ग्रिड का परीक्षण किया [5]; CMM का संस्करण 1.1, संस्करण 1.0 पर आयोजित कार्यशाला से मिली प्रतिक्रियाओं के आधार पर तैयार हुआ, जिसमें लगभग 200 सॉफ़्टवेयर पेशेवर शामिल थे [1]। भागीदार नेटवर्क के लिए, शुरुआत आठ से दस तरह-तरह के भागीदारों के साथ दो घंटे की कार्यशाला से करें। पूछें: क्या आपको इसमें अपना प्रतिबिंब दिखता है? क्या यह आपकी भाषा है? क्या कुछ छूटा है? क्या कोई बात अपमानजनक लगती है?

7. पायलट चलाएं और मानकीकरण करें

तीन से पांच भागीदारों के साथ मॉडल को वास्तविक परिस्थितियों में लागू करें। de Bruin और उनके सहयोगियों का ज़ोर है कि उपकरण की वैधता और विश्वसनीयता जांची जाए, ताकि परिणाम सही और दोहराए जा सकें [3]। इसका व्यावहारिक तरीका यह है: दो लोग एक ही भागीदार को स्वतंत्र रूप से रेटिंग दें और हर असहमति को ऐसे विवरण की ओर संकेत मानें जिसे फिर से लिखना चाहिए। अगर पायलट में शामिल हर भागीदार स्तर 2 पर आ जाए, तो आपके स्तरों में अंतर करने की क्षमता नहीं है; अगर कोई भी स्तर 4 तक पहुंचने की कल्पना न कर पाए, तो वह सिर्फ़ इच्छाओं की सूची है। जो पैमाना हर किसी को एक ही खाने में रखता है, उसमें कोई जानकारी नहीं होती।

8. बदलावों का प्रबंधन करें और फिर से आकलन करें

Becker और उनके सहयोगियों का कहना है कि परिस्थितियों, तकनीक और ज्ञान में बदलाव के साथ हर परिपक्वता मॉडल पुराना पड़ता जाता है, और ज़रूरी बदलाव नए संस्करण में होने चाहिए [2]। अपने मॉडल को एक मानक की तरह संभालें: संस्करण संख्या रखें, साल में बदलाव के लिए एक अवधि तय करें, क्या बदला और क्यों बदला इसका लॉग रखें, और आकलन के दौर के बीच में कोई बदलाव न करें। जब संस्करण 1.1 में कोई खाना बदले, तो बताएं कि संस्करण 1.0 में भागीदार की स्थिति को नए संस्करण में कैसे दर्शाया जाएगा, ताकि वाक्य दोबारा लिखने के कारण किसी भागीदार का स्तर न गिरे। फिर हर 6 से 12 महीने में दोबारा आकलन करें। इन दौरों को कैसे चलाएं और स्तरों का औसत निकालकर एक अंक क्यों नहीं बनाना चाहिए, यह हमारी भागीदार क्षमता आकलन गाइड में बताया गया है।

भागीदार परिपक्वता मॉडल टेम्पलेट (निःशुल्क डाउनलोड)

यह टेम्पलेट आठ चरणों को चार A4 पृष्ठों में समेटता है: उद्देश्य और दायरा; आयाम और स्तर; विवरण ग्रिड, विवरण की जांच और मानकीकरण के नोट्स के साथ; और साक्ष्य योजना, सत्यापन योजना तथा संस्करण लॉग।

परिपक्वता मॉडल निर्माता टेम्पलेट डाउनलोड करें (PDF, 4 पृष्ठ)। इसे डिज़ाइन कार्यशाला में प्रिंट करें या इसके अनुभागों की प्रतिलिपि बनाएं।

उदाहरण: एक महासंघ का सदस्य डिजिटल परिपक्वता मार्ग

यहां टेम्पलेट Meridian Youth Federation के लिए भरा गया है—यह 26 राष्ट्रीय सदस्य संगठनों वाला एक काल्पनिक महासंघ है।

भरा हुआ उदाहरण डाउनलोड करें (PDF, 4 पृष्ठ)। इसके चार फ़ैसले अपनाने लायक हैं:

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

परिपक्वता मॉडल बनाते समय होने वाली आम गलतियाँ

1. उद्देश्य तय करने से पहले स्तर लिखना। किस फ़ैसले में मदद करनी है, यह स्पष्ट न हो तो मॉडल रैंकिंग में बदल जाता है और भागीदार भी उसे रैंकिंग की तरह लेते हैं।
2. प्रश्नावली को ही मॉडल समझ लेना। SEI को भी 1987 की अपनी परिपक्वता प्रश्नावली के मामले में यही समस्या आई थी; लोगों ने अक्सर प्रश्नावली को ही मॉडल समझ लिया [1]। मॉडल विकास का मार्ग है; प्रश्नावली उसे मापने का एक तरीका है।
3. देखी जा सकने वाली स्थितियों की जगह विशेषणों का इस्तेमाल। हर आकलनकर्ता के लिए “पर्याप्त” का अर्थ अलग होता है।
4. बहुत ज़्यादा आयाम। 40 संकेतकों वाला मॉडल कोई पूरा नहीं करेगा।
5. भागीदारों के लिए डिज़ाइन करना, उनके साथ नहीं। अगर स्तर 1 को नाकामियों की सूची की तरह लिखा गया है, तो भागीदार बातें छिपाना सीखेंगे।
6. आकलन के दौर के बीच में बदलाव करना। किसी एक विवरण को संपादित करने से इस दौर की तुलना पिछले दौर से नहीं की जा सकती।

Advancer.World में अपना परिपक्वता मॉडल बनाएं

Advancer.World का जन्म UNICEF और Airbus जैसे संगठनों के कार्यक्रमों के डिजिटल रूपांतरण से हुआ। इसमें किसी कार्यक्रम का ढांचा परिपक्वता मॉडल जैसा होता है: चरण आपके स्तर होते हैं, विषय और उप-विषय आपके आयाम, और हर खाने में एक विवरण होता है।

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

अक्सर पूछे जाने वाले सवाल

परिपक्वता मॉडल में कितने स्तर होने चाहिए?

ज़्यादातर भागीदार नेटवर्क के लिए चार या पाँच। अहम बात यह है कि हर स्तर अलग, स्पष्ट रूप से परिभाषित और उससे नीचे वाले स्तर से तार्किक अगला कदम हो [3]। अगर पायलट में मूल्यांकनकर्ता दो स्तरों के बीच फर्क नहीं कर पाते, तो उन्हें मिला दें।

परिपक्वता मॉडल बनाने में कितना समय लगता है?

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

क्या हम नया परिपक्वता मॉडल बनाने के बजाय किसी मौजूदा मॉडल को अपना सकते हैं?

अक्सर, हाँ—और सबसे पहले आपको इसी विकल्प पर विचार करना चाहिए [2]। लाइसेंस की जाँच करें, अगर संरचना आपके उद्देश्य के अनुकूल हो तो उसे बनाए रखें, और विवरणों को अपने नेटवर्क की भाषा में फिर से लिखें।

क्या कोई भागीदार अलग-अलग आयामों में अलग-अलग स्तरों पर हो सकता है?

हाँ, और आम तौर पर ऐसा ही होता है; यह प्रोफ़ाइल मॉडल का सबसे उपयोगी परिणाम है। किसी भागीदार को एक ही आयाम में स्तर छोड़कर आगे नहीं बढ़ना चाहिए—यह बात CMM के लेखकों ने अपने स्तरों के बारे में भी कही थी [1]।

स्तरों से नहीं, उद्देश्य से शुरुआत करें

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

संदर्भ

1. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis और Charles V. Weber, Software Engineering Institute, Carnegie Mellon University, “सॉफ़्टवेयर के लिए क्षमता परिपक्वता मॉडल, संस्करण 1.1” (CMU/SEI-93-TR-024), फ़रवरी 1993, https://www.sei.cmu.edu/library/capability-maturity-model-for-software-version-11/ (अक्टूबर 2026 में देखा गया)।
2. Jörg Becker, Ralf Knackstedt और Jens Pöppelbuß, “IT प्रबंधन के लिए परिपक्वता मॉडल विकसित करना: एक प्रक्रिया मॉडल और उसका अनुप्रयोग”, Business & Information Systems Engineering, 1(3), 2009, पृ. 213-222, https://doi.org/10.1007/s12599-009-0044-5 (अक्टूबर 2026 में देखा गया)।
3. Tonia de Bruin, Michael Rosemann, Ronald Freeze और Uday Kulkarni, “परिपक्वता आकलन मॉडल विकसित करने के मुख्य चरणों को समझना”, 16वाँ Australasian Conference on Information Systems (ACIS), Sydney, 2005, https://aisel.aisnet.org/acis2005/109 (अक्टूबर 2026 में देखा गया)।
4. Jens Pöppelbuß और Maximilian Röglinger, “एक उपयोगी परिपक्वता मॉडल किसे कहते हैं? परिपक्वता मॉडलों के सामान्य डिज़ाइन सिद्धांतों का एक ढाँचा और व्यवसाय प्रक्रिया प्रबंधन में उसका प्रदर्शन”, Proceedings of the 19th European Conference on Information Systems (ECIS 2011), जून 2011, https://aisel.aisnet.org/ecis2011/28/ (अक्टूबर 2026 में देखा गया)।
5. Venture Philanthropy Partners के लिए McKinsey & Company, “गैर-लाभकारी संगठनों में क्षमता निर्माण को प्रभावी बनाना”, 2001, https://www.bridgespan.org/getmedia/ef1ff943-173b-48ec-843a-b5ce85c6c807/effective-capacity-building-VPP.pdf (अक्टूबर 2026 में देखा गया)।

© 2026 Mourinho Solutions. सर्वाधिकार सुरक्षित।