धारणाओं को तथ्य माने बिना बिजनेस मॉडल कैनवास का उपयोग कैसे करें
बिजनेस मॉडल कैनवास का उपयोग इस बात के दिनांकित मानचित्र के रूप में करें कि आपकी टीम वर्तमान में क्या मानती है। प्रत्येक महत्वपूर्ण धारणा को एक ID दें, उसे साक्ष्य से जोड़ें, परिणाम एकत्र करने से पहले एक परीक्षण निर्धारित करें, और रिकॉर्ड करें कि उसके बाद क्या बदलाव आया। एक पूर्ण कैनवास को अनिश्चितता को स्पष्ट रूप से दिखाना चाहिए। एक छोटी उत्पाद टीम के लिए, व्यावहारिक कार्य यह तय करना है कि आगे और अधिक विकास (development) समय लगाने से पहले क्या परीक्षण किया जाए। नीचे दिया गया वर्कफ़्लो कैनवास को एक धारणा रजिस्टर (assumption register), परीक्षण रिकॉर्ड और संशोधन लॉग (revision log) से जोड़ता है। शुरुआत करने के लिए एक साझा स्प्रेडशीट और दस्तावेज़ फ़ोल्डर पर्याप्त हैं।
कैनवास को क्या दर्शाना चाहिए?
बिजनेस मॉडल कैनवास यह वर्णन करता है कि कोई व्यवसाय मूल्य (value) का निर्माण, वितरण और अधिग्रहण कैसे करता है। इसके नौ ब्लॉक ग्राहक वर्ग (customer segments), मूल्य प्रस्ताव (value propositions), चैनल, ग्राहक संबंध (customer relationships), राजस्व धाराएं (revenue streams), प्रमुख संसाधन (key resources), प्रमुख गतिविधियां (key activities), प्रमुख साझेदारियां (key partnerships) और लागत संरचना (cost structure) को कवर करते हैं। Strategyzer का आधिकारिक बिजनेस मॉडल कैनवास मार्गदर्शन (https://www.strategyzer.com/library/the-business-model-canvas) एक बिजनेस मॉडल का वर्णन करने, उसे दिनांकित करने और संस्करण (version) देने, तथा साक्ष्य मिलने पर उसे फिर से तैयार करने की सलाह देता है।
एक पहचान योग्य ग्राहक समूह के लिए एक प्रस्तावित मॉडल से शुरुआत करें। उदाहरण के लिए, किसी प्रोजेक्ट हैंडऑफ टूल की खोजबीन करने वाली टीम उन छोटी डिज़ाइन एजेंसियों पर ध्यान केंद्रित कर सकती है जो डिज़ाइनरों और प्रोजेक्ट मैनेजरों के बीच काम का हस्तांतरण करती हैं। एक ही कैनवास पर एजेंसियों, स्वतंत्र डिज़ाइनरों और बड़े उद्यमों को मिलाने से यह बताना कठिन हो जाएगा कि कौन सा साक्ष्य किस ग्राहक पर लागू होता है।
ब्लॉक में संक्षिप्त विवरण लिखें, फिर धारणा ID संलग्न करें। "मासिक टीम सदस्यता — A-04" राजस्व विचार को ट्रैक करने योग्य बनाता है। "सेल्फ-सर्विस सेटअप — A-05" डिलीवरी से जुड़ी एक ऐसी धारणा को सामने लाता है जो ग्राहक संबंधों, गतिविधियों और लागतों को प्रभावित कर सकती है।
अज्ञात बातों को दृश्यमान रखें। किसी ऐसे सप्लायर का नाम लिखने की तुलना में जिससे टीम ने कभी संपर्क नहीं किया है, एक स्पष्ट प्रश्न के साथ खाली साझेदारी ब्लॉक छोड़ना अधिक उपयोगी है। कार्यशाला की सहमति एक साझा प्रारंभिक बिंदु स्थापित करती है; सहायक साक्ष्य एक अलग रिकॉर्ड से आने चाहिए।
आप कैनवास नोट्स को परीक्षण योग्य धारणाओं में कैसे बदलते हैं?
व्यापक विवरणों को ऐसे दावों से बदलें जो किसी ग्राहक, स्थिति और अवलोकनीय व्यवहार को स्पष्ट रूप से निर्दिष्ट करते हों। "आसान ऑनबोर्डिंग" परीक्षण करने के लिए बहुत अस्पष्ट है। अधिक उपयोगी दावा यह है: "एक छोटी डिज़ाइन एजेंसी का प्रोजेक्ट मैनेजर बिना किसी लाइव सहायता के एक प्रोजेक्ट बना सकता है और एक डिज़ाइनर को आमंत्रित कर सकता है।" प्रयोग की योजना बनाते समय उत्पाद का संस्करण और परीक्षण की शर्तें जोड़ें।
उन दावों को अलग करें जिनके लिए अलग-अलग साक्ष्यों की आवश्यकता होती है। "एजेंसियों को इसकी आवश्यकता है और वे मासिक भुगतान करेंगी" में कम से कम दो धारणाएं शामिल हैं। बार-बार होने वाली हैंडऑफ समस्या का साक्ष्य किसी विशेष समाधान के लिए भुगतान करने की इच्छा को स्थापित नहीं करता है।
प्रत्येक महत्वपूर्ण दावे के लिए, यह रिकॉर्ड करें:
स्पष्ट स्थितियों (statuses) के एक छोटे सेट का उपयोग करें: अप्रपरीक्षित (untested), परीक्षण जारी (testing), बताई गई शर्तों के तहत समर्थित (supported within stated conditions), बताई गई शर्तों के तहत विरोधाभासी (contradicted within stated conditions), और अनिर्णायक (inconclusive)। ये अनुशंसित वर्कफ़्लो लेबल हैं, न कि अतिरिक्त आधिकारिक कैनवास ब्लॉक। अप्रतिबंधित "सिद्ध" (proven) लेबल से बचें: उदाहरण के लिए, सहायता प्राप्त सेटअप के साथ प्राप्त परिणाम यह सिद्ध नहीं करता कि सेल्फ-सर्विस सेटअप काम करता है।
दो प्रश्न पूछकर धारणाओं को प्राथमिकता दें: क्या गलत होने पर अगला विकास निर्णय काफी हद तक बदल जाएगा? हमारे पास कितना प्रासंगिक साक्ष्य है? वहां से शुरुआत करें जहां परिणाम काफी महत्वपूर्ण हैं और साक्ष्य कमजोर हैं। महत्वपूर्ण परिकल्पनाओं पर Strategyzer का मार्गदर्शन (https://www.strategyzer.com/library/how-to-test-your-idea-start-with-the-most-critical-hypotheses) वांछनीयता (desirability), व्यवहार्यता (feasibility) और सक्षमता (viability) संबंधी धारणाओं में अंतर करता है, जिससे टीमों को ग्राहकों की मांग, डिलीवरी क्षमता और परिचालन अर्थशास्त्र की जांच करने में मदद मिलती है।
धारणा-से-साक्ष्य (assumption-to-evidence) तालिका में क्या शामिल होना चाहिए?
विस्तृत तर्कों को एक जुड़े हुए रजिस्टर में संग्रहीत करके कैनवास को पठनीय बनाए रखें। नीचे दी गई तालिका दर्शाती है कि वह रजिस्टर काल्पनिक हैंडऑफ टूल के लिए कैसे काम कर सकता है। प्रत्येक अवलोकन और मात्रा केवल प्रदर्शन के लिए गढ़ी गई है; ये शोध के निष्कर्ष या अनुशंसित नमूना आकार नहीं हैं। साक्ष्य ID उन रिकॉर्ड्स को दर्शाती हैं जिन्हें एक वास्तविक टीम बनाएगी और लिंक करेगी, न कि मौजूदा दस्तावेज़ों को।
वास्तविक रजिस्टर में, प्रत्येक साक्ष्य ID को अंतर्निहित नोट्स, कार्य रिकॉर्डिंग, घटना निर्यात (event exports), या समय लॉग से लिंक करें। जहां संभव हो, प्रासंगिक अनुभाग या टाइमस्टैम्प की ओर इंगित करें। "ग्राहकों को यह पसंद आया" कहने वाली एक प्रेजेंटेशन स्लाइड का ऑडिट करना कठिन होता है क्योंकि इसमें अवलोकनों और उनके संदर्भ को छोड़ दिया जाता है।
प्रत्येक साक्ष्य रिकॉर्ड में विधि, भर्ती मार्ग (recruitment route), पात्र प्रतिभागी या घटनाएं, पूर्ण अवलोकन, उत्पाद संस्करण, प्रदान की गई सहायता और बहिष्करणों की पहचान होनी चाहिए। अनुकूल परिणामों के साथ-साथ विरोधाभासी परिणामों को भी सुरक्षित रखें। यदि कई सारांश एक ही साक्षात्कार को दोहराते हैं, तो उसकी मूल साक्ष्य ID को बनाए रखें ताकि पुनरावृत्ति स्वतंत्र पुष्टि जैसी न लगे।
आप ऐसे परीक्षण की योजना कैसे बनाते हैं जो निर्णय को बदल सके?
परिणाम देखने से पहले परीक्षण योजना लिखें। Strategyzer का टेस्ट कार्ड (https://www.strategyzer.com/library/validate-your-ideas-with-the-test-card) चार तत्वों को स्पष्ट करता है: परिकल्पना, परीक्षण, माप और सीमा (threshold)। इसमें एक मालिक, एक समय सीमा और प्रत्येक संभावित परिणाम से जुड़ी कार्रवाई जोड़ें।
A-02 के लिए, एक उदाहरणात्मक योजना इस प्रकार हो सकती है:
इस उदाहरण में सीमा अगले छोटे कदम के लिए टीम द्वारा चुना गया एक मानक (gate) है। यह बाजार के प्रदर्शन का कोई सांख्यिकीय अनुमान नहीं है। निर्णय और गलत होने की लागत के अनुसार अपनी स्वयं की सीमा चुनें; "पांच में से चार" को एक सार्वभौमिक सत्यापन नियम के रूप में न अपनाएं।
विधि का मिलान दावे से करें। समस्या की जांच के लिए हाल के कार्य विवरणों का उपयोग करें, उपयोगिता (usability) की जांच के लिए देखे गए कार्यों का, खरीद व्यवहार की जांच के लिए एक डिलिवरेबल सशुल्क पेशकश का, और सहायता प्रयास की जांच के लिए परिचालन लॉग का उपयोग करें। निष्कर्ष को उस स्तर तक ही रखें जिसे विधि वास्तव में मापती है: एक न्यूज़लेटर क्लिक उत्पाद के बार-बार उपयोग को स्थापित नहीं करता है।
अस्पष्ट परिणामों को पहले से निर्दिष्ट करें। यदि बहुत कम पात्र प्रतिभागी परीक्षण पूरा करते हैं, तो रिकॉर्ड करें कि परिणाम अनिर्णायक क्यों है। यदि आप बीच में ही दर्शक वर्ग, कार्य, पेशकश या सीमा बदलते हैं, तो एक नया परीक्षण संस्करण बनाएं और मूल को बनाए रखें। अन्यथा, एक बदला हुआ प्रयोग चुपचाप एक भिन्न प्रश्न का अनुकूल उत्तर बन सकता है।
आप साक्ष्य और व्याख्या के बीच अंतर कैसे करते हैं?
प्रत्येक परीक्षण के बाद तीन अलग-अलग विवरण लिखें: क्या हुआ, यह क्या संकेत देता है, और टीम क्या करेगी। शोध सत्रों के विश्लेषण पर GOV.UK का मार्गदर्शन (https://www.gov.uk/service-manual/user-research/analyse-a-research-session) लोगों ने क्या कहा या किया, इसके अवलोकनों को निष्कर्षों और बाद की कार्रवाइयों से स्पष्ट रूप से अलग करता है।
उदाहरणात्मक सेटअप परीक्षण के लिए, वे विवरण इस प्रकार हो सकते हैं:
यह Strategyzer के लर्निंग कार्ड (https://www.strategyzer.com/library/capture-customer-insights-and-actions-with-the-learning-card) की संरचना का भी पालन करता है: परिकल्पना की पहचान करें, अवलोकनों को रिकॉर्ड करें, एक निष्कर्ष निकालें और तय करें कि कैसे कार्य करना है।
जब साक्ष्यों में विरोधाभास हो, तो परिणामों को मिलाने से पहले परिस्थितियों की जांच करें। अनुभवी उपयोगकर्ता वह कार्य पूरा कर सकते हैं जो नए उपयोगकर्ता नहीं कर सकते। काम करने वाला प्रोटोटाइप जारी किए गए अंतिम उत्पाद से अलग व्यवहार कर सकता है। जब वे अंतर निर्णय के लिए महत्वपूर्ण हों तो धारणा को विभाजित करें। समर्थित विवरण को इतना संकीर्ण रखें कि कोई अन्य टीम सदस्य यह ठीक से समझा सके कि यह कहां लागू होता है।
टीम को संशोधनों को कैसे ट्रैक करना चाहिए?
जब साक्ष्य किसी सार्थक निर्णय को बदल दे तो कैनवास का एक दिनांकित स्नैपशॉट सहेजें। धारणा ID को स्थिर रखें और साथ ही उनके शब्दों में हुए परिवर्तनों को रिकॉर्ड करें। यदि कोई दावा काफी हद तक बदल जाता है, तो एक नया संशोधन या लिंक की गई धारणा बनाएं ताकि पुराना साक्ष्य उसी विवरण से जुड़ा रहे जिसका उसने वास्तव में परीक्षण किया था।
एक उपयोगी संशोधन प्रविष्टि में पिछला विवरण, संशोधित विवरण, प्रेरित करने वाली साक्ष्य ID, प्रभावित कैनवास ब्लॉक, निर्णयकर्ता और अगली कार्रवाई शामिल होती है। काल्पनिक सेटअप परिणाम के लिए, यह इस प्रकार हो सकता है:
कैनवास v0.3 → v0.4। A-05 को "सभी एजेंसियों को 20 मिनट से अधिक सेटअप सहायता की आवश्यकता नहीं है" से संशोधित करके "आयात वाली और बिना आयात वाली एजेंसियों के बीच सहायता की आवश्यकताएं भिन्न हैं" किया गया। ट्रिगर: E-05। प्रमुख गतिविधियों, ग्राहक संबंधों और लागत संरचना को अपडेट करें। अगली कार्रवाई: आयात वर्कफ़्लो का अलग से परीक्षण करें।
जब भी कोई दावा बदले तो जुड़े हुए ब्लॉकों की जाँच करें। सहायता प्राप्त ऑनबोर्डिंग जोड़ने से उत्पाद वितरित करने के लिए आवश्यक कार्य और संबंधित लागत धारणाएं प्रभावित होती हैं। Strategyzer का कैनवास मार्गदर्शन (https://www.strategyzer.com/library/the-business-model-canvas) इन निर्भरताओं पर जोर देता है: मॉडल के एक हिस्से को बदलने के लिए अन्य जगहों पर भी बदलाव की आवश्यकता हो सकती है।
समीक्षा तिथियों के साथ-साथ ट्रिगर्स का भी चयन करें। जब लक्षित ग्राहक, मूल्य, अधिग्रहण चैनल, उत्पाद वर्कफ़्लो या सप्लायर व्यवस्था बदलती है, तो धारणाओं पर फिर से विचार करें। पुराने साक्ष्यों को सुरक्षित रखें, लेकिन पुनर्मूल्यांकन करें कि क्या उनकी स्थितियां अभी भी वर्तमान मॉडल से मेल खाती हैं।
साप्ताहिक कैनवास समीक्षा से क्या हासिल होना चाहिए?
एक छोटी टीम निर्णयों पर केंद्रित एक संक्षिप्त साप्ताहिक समीक्षा से शुरुआत कर सकती है:
एक ठोस निर्णय के साथ समाप्त करें: एक सीमित पायलट को जारी रखें, एक वर्कफ़्लो को संशोधित करें, ग्राहक वर्ग को संकीर्ण करें, अनुपलब्ध साक्ष्य एकत्र करें, या किसी असमर्थित दावे पर निर्भर काम को रोकें। उपयोगी आउटपुट वह है जो इस बात के बीच एक ट्रैक करने योग्य संबंध स्थापित करता है कि टीम क्या मानती है, उसने क्या देखा, और वह आगे क्या करना चुनती है।