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

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

यह अब एक दशक पहले की तुलना में दो कारणों से अधिक मायने रखता है। पहला, तकनीक बदलाव की गति और लागत बढ़ गई है, इसलिए गलत जगह निवेश करने का दंड तेजी से बढ़ता है। दूसरा, संपदा अधिक वितरित है, जिसमें legacy प्लेटफॉर्म, पैकेज्ड सॉफ्टवेयर और cloud सेवाएं मिली-जुली हैं, जिससे सिस्टम-स्तरीय तर्क किसी व्यवसाय-स्तरीय सवाल का जवाब देने में और भी कम सक्षम हो जाता है। Capability-based planning इसलिए मायने रखती है क्योंकि यह नेताओं को एक ऐसी भाषा देती है जो योजना बनाने के लिए पर्याप्त स्थिर है और पूरे उद्यम में तुलना करने के लिए पर्याप्त अमूर्त है।

एक business capability इस बात की अभिव्यक्ति है कि कोई संगठन क्या करता है, जिसे जानबूझकर इससे अलग रखा जाता है कि वह कैसे, कहां या किसके द्वारा करता है। ग्राहक को onboard करना एक capability है। onboarding portal, KYC टीम और identity-verification सेवा उन चीजों में से हैं जो इसे साकार करती हैं। क्या को कैसे से अलग रखने का अनुशासन ही पूरी बात है, क्योंकि यही अलगाव है जो capability को स्थिर बनाए रखता है जबकि कार्यान्वयन उसके नीचे मंथन करते रहते हैं। एक सुगठित capability को एक स्थिर संज्ञा-उन्मुख क्षमता के रूप में नामित किया जाता है, इसे पूरे उद्यम के लिए एक बार परिभाषित किया जाता है, और यह वर्तमान परिचालन मॉडल या वर्तमान तकनीक को अपने भीतर सांकेतिक रूप से नहीं समेटती।

Capabilities को एक capability map में व्यवस्थित किया जाता है, जो उद्यम का स्तरों में एक संरचित विघटन है। स्तर एक में कुछ मोटे समूह होते हैं, आम तौर पर दस से बीस के बीच, जो पूरे व्यवसाय को समेटते हैं। प्रत्येक स्तर दो में और जहां उपयोगी हो वहां स्तर तीन में विघटित होता है, प्रक्रिया के विवरण में कभी प्रवेश किए बिना अधिक सूक्ष्म होता जाता है। यह map न तो प्रक्रिया मॉडल है और न ही org chart। एक प्रक्रिया समय के साथ चरणों के अनुक्रम का वर्णन करती है। एक org इकाई इसका वर्णन करती है कि कौन किसको रिपोर्ट करता है। एक capability एक स्थिर क्षमता का वर्णन करती है जिसका उपयोग कई प्रक्रियाएं करती हैं और जिसमें कई इकाइयां योगदान देती हैं। इन तीनों को भ्रमित करना ही किसी capability मॉडल को उसके जन्म पर ही बिगाड़ने का सबसे आम तरीका है।

Map अपनी उपयोगिता तभी सिद्ध करता है जब वह दो दिशाओं में जुड़ा हो। ऊपर की ओर, प्रत्येक capability उन रणनीतिक परिणामों और लक्ष्यों से जुड़ी होती है जिनकी वह सेवा करती है, ताकि इरादे का पता उन क्षमताओं तक लगाया जा सके जिन पर वह निर्भर है। नीचे की ओर, प्रत्येक capability उन एप्लिकेशनों, डेटा, लोगों और प्रक्रियाओं से जुड़ी होती है जो उसे साकार करती हैं, ताकि किसी क्षमता के बारे में लिए गए निर्णय का पता उन सभी चीजों तक लगाया जा सके जिन्हें वह छूती है। जब दोनों संबंध मौजूद हों, तो capability एक जोड़-बिंदु बन जाती है। एक रणनीतिक प्राथमिकता उन गिनी-चुनी capabilities में सुलझ जाती है जिन पर वह वास्तव में टिकी है, और उनमें से प्रत्येक उन ठोस सिस्टमों और टीमों में सुलझ जाती है जिन्हें बदलना पड़ेगा। heat map ही इसे कार्रवाई योग्य बनाता है: प्रत्येक capability को रणनीतिक महत्व, वर्तमान परिपक्वता, लागत, जोखिम और व्यावसायिक मूल्य जैसे आयामों पर अंक दिए जाते हैं, और इसे दृश्य रूप में प्रस्तुत किया जाता है ताकि capabilities का वह छोटा समूह जो अत्यधिक महत्वपूर्ण होने के साथ-साथ खराब ढंग से सेवित है, तुरंत स्पष्ट हो जाए। वह प्रतिच्छेदन, उच्च महत्व बनाम निम्न प्रदर्शन, वहीं निवेश का सही स्थान है।

Capability modelling नई नहीं है, लेकिन कई विकासों ने इसे एक आरेखण अभ्यास से हटाकर एक जीवंत योजना उपकरण की ओर बढ़ाया है। पहला है enterprise architecture repositories और portfolio tooling का ऐसे प्लेटफॉर्म में परिपक्व होना जो capability map को एक प्रथम-श्रेणी वस्तु के रूप में रखते हैं और उसे एप्लिकेशन और तकनीक की सूची से बांधते हैं। जब map इस बात के वास्तविक डेटा से जुड़ा होता है कि कौन से एप्लिकेशन किन capabilities का समर्थन करते हैं, किस लागत पर और किस तकनीकी स्वास्थ्य के साथ, तो heat map एक कार्यशाला की राय होना बंद कर देता है और संपदा का एक बचाव-योग्य आकलन बनने लगता है। अंक पूरी तरह से घोषित करने के बजाय आंशिक रूप से व्युत्पन्न किए जा सकते हैं, और यही वह चीज है जो किसी वित्त समिति के समक्ष उसे अधिकार देती है।

दूसरा है capabilities का value streams और product-उन्मुख परिचालन मॉडलों के साथ संरेखण। जैसे-जैसे संगठन वित्तपोषण को परियोजनाओं से हटाकर दीर्घकालिक product टीमों की ओर पुनर्गठित करते हैं, इस सवाल का एक स्थिर जवाब चाहिए कि प्रत्येक टीम किसके लिए जवाबदेह है, और capabilities वह जवाब देती हैं। एक product या एक value-stream चरण उन capabilities पर आधारित होता है जो वह प्रदान करता है, इसलिए परियोजना वित्तपोषण से स्थायी product वित्तपोषण की ओर बदलाव हर योजना चक्र में दायरे को फिर से गढ़ने के बजाय capability map को अपनी रीढ़ के रूप में विरासत में पाता है।

तीसरा है build-versus-buy तर्क का पैनापन जैसे-जैसे सॉफ्टवेयर subscription और cloud डिलीवरी की ओर बढ़ता है। जब अधिकांश capabilities को एक पैकेज्ड सेवा से संतुष्ट किया जा सकता है, तो रणनीतिक सवाल यह बन जाता है कि कौन सी capabilities वास्तव में विभेदक हैं और इसलिए बनाने या आकार देने योग्य हैं, और कौन सी आवश्यक लेकिन अविभेदक हैं और इसलिए खरीदकर मानकीकृत करना सबसे अच्छा है। Capability-based planning ही वह स्वाभाविक स्थान है जहां वह निर्णय विक्रेता-दर-विक्रेता के बजाय जानबूझकर लिया जाता है। चौथा विकास है AI और automation का संभावित साकारीकरण के रूप में आगमन। capability का नजरिया सवाल को अनुशासित रखता है: यह नहीं कि हम कहां मॉडल जोड़ सकते हैं, बल्कि यह कि किन विशिष्ट क्षमताओं में यदि संवर्धन किया जाए तो भौतिक रूप से सुधार होगा, और क्या वह क्षमता उस जोखिम को उचित ठहराने के लिए पर्याप्त महत्वपूर्ण है। हर मामले में map ही वह चीज है जो किसी सामान्य प्रवृत्ति को अंधाधुंध लागू होने से रोकती है।

एक ऐसे capability map, जो वर्षों तक निवेश का मार्गदर्शन करता है, और एक ऐसे map, जिसे चुपचाप छोड़ दिया जाता है, के बीच का अंतर लगभग पूरी तरह से design के अनुशासन में निहित है। पहला सिद्धांत यह है कि capabilities परिणामों का वर्णन करती हैं, संगठन का नहीं। यदि किसी capability को किसी विभाग या वर्तमान सिस्टम के नाम पर रखा जाता है, तो जिस क्षण उनमें से कोई भी बदलेगा, इसे फिर से बनाना पड़ेगा, और वह स्थिरता खो जाएगी जिसने पूरे दृष्टिकोण को उचित ठहराया था। Map को किसी पुनर्गठन से अछूता बचना चाहिए। यह पकड़ने वाला अकेला सबसे कठिन सिद्धांत है, क्योंकि कमरे में मौजूद लोग स्वाभाविक रूप से व्यवसाय का वर्णन उसी तरह करते हैं जैसा वे उसे अनुभव करते हैं, अपने ही कार्य के माध्यम से।

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

चौथा सिद्धांत किसी capability और उसके साकारीकरणों के बीच जानबूझकर बनाया गया one-to-many संबंध है। एक अकेली capability कई सिस्टमों द्वारा प्रदान की जा सकती है, और एक अकेला सिस्टम कई capabilities में योगदान दे सकता है। उस many-to-many mapping को ईमानदारी से संरक्षित रखना, न कि प्रति capability एक सिस्टम की एक साफ-सुथरी कल्पना थोपना, ही वह चीज है जो map को दोहराव और विखंडन को सतह पर लाने देती है। पांचवां सिद्धांत heat map से ही संबंधित है: इसके अंकन आयामों को स्पष्ट रूप से परिभाषित किया जाना चाहिए और सुसंगत रूप से लागू किया जाना चाहिए, और महत्व का आकलन रणनीति के विरुद्ध किया जाना चाहिए, न कि इसके विरुद्ध कि किसी capability को वर्तमान में कितना ध्यान मिलता है। एक capability व्यस्त, महंगी और अच्छी तरह से कर्मचारीयुक्त हो सकती है जबकि रणनीतिक इरादे में बहुत कम योगदान देती हो, और केवल एक ईमानदार महत्व-अक्ष ही इसे प्रकट करेगा। अंत में, map को एक स्पष्ट स्वामी के साथ एक जीवंत संपत्ति के रूप में शासित किया जाना चाहिए, क्योंकि एक अनुरक्षित न किया गया capability मॉडल एक ही योजना चक्र के भीतर एक ऐतिहासिक अवशेष में क्षय हो जाता है।

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

छद्म org chart। जब capabilities को पूरी तरह से विभाग प्रमुखों से, अपने ही क्षेत्रों का वर्णन करते हुए, निकाला जाता है, तो map अंततः वर्तमान संरचना का दर्पण बन जाता है। यह प्रशंसनीय पढ़ा जाता है लेकिन भंगुर होता है, और यह ठीक उसी अस्थिरता को फिर से ले आता है जिसे capabilities हटाने के लिए बनाई गई थीं। उपाय यह है कि क्षमताओं को इस तरह नामित किया जाए कि वे तब भी सच बनी रहें यदि पूरे संगठन को कल पुनर्गठित कर दिया जाए।

छद्म रूप में प्रक्रिया मॉडल। टीमें अक्सर capabilities से फिसलकर प्रक्रियाओं में चली जाती हैं, किसी क्षमता को उसके चरणों में विघटित कर देती हैं। Map क्रियाओं और अनुक्रमों से भर जाता है, विशाल हो जाता है, और वह अमूर्तता खो देता है जिसने इसे योजना के लिए उपयोगी बनाया था। एक capability इसका जवाब देती है कि व्यवसाय क्या कर सकता है; जिस क्षण यह इसका जवाब देना शुरू करती है कि किस क्रम में, यह एक अलग ही कलाकृति बन जाती है।

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

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

Nashua capability-based planning को एक निर्णय तक पहुंचने के साधन के रूप में देखती है, न कि अपने आप में एक पुरस्कार वाली मॉडलिंग परियोजना के रूप में। हम रणनीति से शुरू करते हैं, क्योंकि किसी capability map में कोई महत्व-अक्ष तब तक नहीं होता जब तक संगठन के इच्छित परिणाम स्पष्ट न कर दिए जाएं। नेतृत्व के साथ काम करते हुए हम यह स्थापित करते हैं कि व्यवसाय क्या हासिल करने की कोशिश कर रहा है और, उससे, वे परिणाम वास्तव में किन capabilities पर निर्भर हैं। यह अभ्यास को पहली कार्यशाला से ही परिणाम में लंगर डाले रखता है, न कि किसी उपयोग की तलाश में एक व्यापक map तैयार करता है।

फिर हम capability map का निर्माण करते हैं, जिसे उस गहराई तक विघटित किया जाता है जितनी वर्तमान निर्णयों के लिए उचित हो। हम design सिद्धांतों के प्रति सचेत रहते हैं: परिणाम-उन्मुख नामकरण, अमूर्तता का एक सुसंगत स्तर, और एक ऐसा map जो किसी पुनर्गठन से बचा रहे। हम प्रक्रिया के विवरण की ओर और org chart की ओर के खिंचाव का विरोध करते हैं, क्योंकि हमने देखा है कि दोनों कैसे चुपचाप परिणाम को बर्बाद कर देते हैं। जहां एक उपयोग-योग्य capability मॉडल पहले से मौजूद है, वहां हम फिर से शुरू करने के बजाय उसका आकलन और परिष्करण करते हैं, क्योंकि शब्दावली की निरंतरता स्वयं मूल्यवान है।

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

जो चीज Nashua को अलग करती है वह है रणनीति से capability, capability से सिस्टम, और सिस्टम से निवेश तक के चक्र को बंद करने पर, और उसे समय के साथ बंद रखने पर आग्रह। कई संगठन एक capability map तैयार कर सकते हैं। कम ही ऐसा तैयार कर सकते हैं जो उनकी वास्तविक एप्लिकेशन संपदा से बंधा हो, बचाव-योग्य साक्ष्य पर अंकित हो, और इससे जुड़ा हो कि धन वास्तव में कैसे जारी होता है, ताकि रणनीतिक प्राथमिकता में एक बदलाव साफ-साफ इस बदलाव में सुलझ जाए कि निवेश कहां जाता है। वह जोड़ने वाला काम, अनाकर्षक और सटीक, वहीं है जहां capability-based planning का मूल्य या तो साकार होता है या खो जाता है, और वहीं हमारे व्यवसायी अपना ध्यान केंद्रित करते हैं।

एक व्यावहारिक परिणाम भी है जो बदल देता है कि काम को क्या मान लेने की अनुमति है। जब किसी engagement को ऐसी capability की जरूरत होती है जो अभी मौजूद नहीं है, तो उसे किसी खरीद चक्र या किसी विक्रेता के roadmap पर प्रतीक्षा नहीं करनी पड़ती। enterprise platform को लगभग किसी भी सुविधा को तेजी से समायोजित करने के लिए बनाया गया है, agentic engineering के माध्यम से: जो चाहिए उसे सादी भाषा में वर्णित किया जाता है और जल्दी से उत्पन्न किया जाता है, लेकिन हमेशा दृढ़ architecture सिद्धांतों के भीतर और कठोर गुणवत्ता आश्वासन के अधीन, ताकि गति कभी भी सुसंगतता, सुरक्षा या नियंत्रण की कीमत पर न आए। इसका प्रभाव मात्र सुविधाजनक होने के बजाय रणनीतिक है। यह make-or-buy रेखा को खिसका देता है, विकल्पशीलता को सस्ता रखता है, और architecture को रणनीति का अनुसरण करने देता है, न कि रणनीति को इस पर झुकने देता है कि किसी शेल्फ पर संयोगवश जो कुछ भी मौजूद था।

यह संयोजन ही मायने रखता है। अपने आप में एक capability map एक आरेख है, और अपने आप में portfolio tooling बिना किसी व्यावसायिक अर्थ के एप्लिकेशनों का एक डेटाबेस है। Nashua दोनों को एक साथ लाती है: इस बात का स्थायी दृष्टिकोण कि व्यवसाय को क्या करने में सक्षम होना चाहिए, उसे उन सिस्टमों, डेटा और लागत की जीवंत वास्तविकता के विरुद्ध रखा गया जो उसे साकार करते हैं, और इस तरह शासित कि यह तस्वीर तब भी सच बनी रहे जब रणनीति और संपदा दोनों विकसित हों। हमारे ग्राहक जो परिणाम अपने पास रखते हैं वह कोई डिलीवरेबल नहीं बल्कि एक क्षमता है। नेतृत्व को बदलाव पर तर्क करने के लिए एक स्थिर भाषा मिलती है, एक heat map जो निवेश को शोर के बजाय वास्तविक जोखिम की ओर इंगित करता है, और यह विश्वास कि प्रतिबद्ध किए गए हर यूरो का पता एक ऐसी क्षमता तक लगाया जा सकता है जिसमें व्यवसाय ने जानबूझकर बेहतर होना चुना है। यही उस चीज में निवेश करने का अर्थ है जो व्यवसाय को करने में सक्षम होना चाहिए, और यही वह अनुशासन है जिसे बनाए रखने के लिए Nashua मौजूद है।