PESTLE Analysis — कोठाभित्र पस्नुअघि नै कोठा पढ्ने Tool

एउटा साउदी logistics company का Head of Strategy ले छिमेकी market मा cross-border expansion design गर्न छ महिना खर्चे। Financial model बलियो थियो। Operational plan विस्तृत थियो। Team उत्साहित थियो। Launch भएको तीन महिनापछि, customs processing मा आएको एउटा परिवर्तनले हरेक shipment को लागतमा करिब 40% थपिदियो र चुपचाप सिंगो business case भत्काइदियो।

यो कथा सामान्यतया जसरी सुनाइन्छ, त्यहीँ टुंगिन्छ — बाहिर पाइला हाल्नुअघि बाहिर हेर्नुपर्छ भन्ने एउटा सफा पाठसहित। तर भएको त्यो होइन। उनीहरूले यो आउँदैछ भनेर देखेका थिए। एक जना regulatory analyst ले आठ महिनाअघि नै, एउटा PESTLE review मा, एउटा slide मा, Legal शीर्षकमुनि यो आउँदै गरेको परिवर्तन flag गरेकी थिइन्। उनीसँग कसैले असहमति जनाएन। उनको कुरामा कसैले काम पनि गरेन। त्यो finding कुनै व्यक्तिको होइन, एउटा document को थियो — र document हरूले निर्णय गर्दैनन्।

PESTLE जुन समस्या समाधान गर्न बेचिन्छ, त्योभन्दा धेरै बढी हामी यही pattern सँग ठोक्किन्छौं। हाम्रो अनुभवमा संगठनहरू scan गर्न खासै कमजोर छैनन्। तर scan ले जे फर्काएर ल्याउँछ, त्यसको ownership लिन उनीहरू कमजोर छन्।

सबै कुरामा सही ठहरिएको त्यो PESTLE

हामीले मूल review हेर्न मागेका थियौं। त्यो राम्रो काम थियो — साँच्चै। छ वटा column, चालीसभन्दा बढी factor, sources cited, र customs risk सिधा भाषामा त्यहीँ बसेको थियो — consultation period पहिल्यै बन्द भइसकेको note सहित।

"हामी गलत थिएनौं भन्ने तथ्यमा म बारम्बार फर्किरहन्छु," Head of Strategy ले हामीलाई भने। "त्यो document तपाईंले कुनै competitor लाई दिनुभएको भए, हामीसँग भएको सबै कुरा उनीहरूसँग हुन्थ्यो। हामीले छुटाएका थिएनौं। कुरा यत्ति हो कि त्यसमाथि केही गर्नु कसैको काम थिएन। त्यो research थियो। त्यो appendix मा गयो।"

त्यो research थियो। यो वाक्यसँग केहीबेर बस्नु सार्थक छ। Analysis सटीक थियो, ताजा थियो, र पूर्ण रूपमा निष्क्रिय थियो — र त्यसको सटीकता नै त्यो कुरा हो जसले काम सकियो जस्तो महसुस गरायो।

यहाँ असहज संस्करण छ: जुन PESTLE ले केही बदल्दैन, त्यो प्रायः सही नै हुन्छ। सही हुनु र actionable हुनु उस्तै होइन, र जुन framework ले तपाईंलाई सही मात्र हुन भन्छ, त्यसले ठ्याक्कै त्यही बिन्दुमा रोकिन दिन्छ जहाँबाट गाह्रो भाग सुरु हुन्छ।

PESTLE साँच्चै कहाँबाट आयो?

यसको वंशावली सामान्यतया Francis Aguilar सम्म पुर्‍याइन्छ। उनको 1967 को किताब Scanning the Business Environment — जुन उनले Harvard Business School को faculty मा हुँदा, professor बन्नुभन्दा चार वर्षअघि लेखेका थिए — ले company बाहिरका शक्तिहरूलाई चार वर्गमा समूहबद्ध गर्‍यो: economic, technical, political, र social। पछिका लेखकहरूले तिनलाई पुनः क्रमबद्ध गरेर PEST बनाए, अनि regulatory र climate जोखिम बढ्दै जाँदा legal र environmental छुट्याएर PESTLE मा विस्तार गरे।

यो मानक विवरण हो, र जुन आत्मविश्वासका साथ यो दोहोर्याइन्छ, त्योभन्दा यो कमजोर आधारमा उभिएको छ भन्ने जान्नु सार्थक छ। Aguilar ले PESTLE शब्द बनाएका होइनन्। उनलाई नियमित रूपमा जोडिने "ETPS" label अचम्मैसँग भेट्टाउन गाह्रो छ — उनको किताबको कुन पृष्ठमा त्यो देखिन्छ भनेर उद्धृत गर्ने कुनै स्रोत हामीले भेट्टाउन सकेनौं, र वंशावली सबैभन्दा सावधानीपूर्वक पछ्याउने practitioner इतिहासहरूले नै बीचका खुड्किलाहरू अभिलेखबद्ध छैनन् भनेर खुलेरै स्वीकार्छन्।

हामी यो कुरा pedantic बन्न होइन, बरु यसले tool लाई नै व्याख्या गर्ने भएकाले उठाउँछौं। PESTLE कहिल्यै design गरिएको थिएन। यो थुप्रिँदै गयो। यसले के उत्पादन गर्नुपर्ने हो भनेर कसैले बसेर तोकेको थिएन — र ठ्याक्कै यही कारण, तपाईंले यो भरिसकेपछि के गर्ने भन्नेमा यसको कुनै राय हुँदैन। यो एउटा taxonomy हो, method होइन। यसले संसारलाई छ वटा बाकसमा छुट्याउँछ र रोकिन्छ। PESTLE ले निराश बनायो भन्ने हामीले भेटेको हरेक संगठन method को अपेक्षा गरिरहेको थियो, र पाएको taxonomy थियो।

Framework: सातौं column

एउटा PESTLE grid मा छ वटा column हुन्छन् — Political, Economic, Social, Technological, Legal, Environmental। Team हरूले छैटै भर्छन्, present गर्छन्, र file गर्छन्। कसैले नकोर्ने column सातौं हो:

यसमाथि काम गर्न हामी के गर्न सक्ने हुनुपर्थ्यो?

पानामा बाँचिरहने हरेक factor का लागि तीन प्रश्न:

1. यसले कुन निर्णय बदल्छ? "यसले business को कुन भागलाई छुन्छ" होइन — कुन निश्चित निर्णय, कसैद्वारा गरिने, एउटा मितिमा। कुनै पनि निर्णय नबदल्ने factor भनेको citation भएको trivia हो। मेट्नुहोस्।
2. त्यो निर्णयको owner को हो? एउटा नाम, function होइन। "Operations" owner होइन; Operations कहिल्यै कोठाभित्र पसेर केही निर्णय गरेको छैन। यदि कुनै नाम मिल्दैन भने, तपाईंले असली finding भेट्टाउनुभयो — त्यो निर्णय unowned छ, र त्यो बाहिरी factor त तपाईंले यो पत्ता लगाउने माध्यम मात्र हो। (यसबारे हामीले Decision Drift मा विस्तृत लेखेका छौं; तपाईंसँग यस्तो निर्णय छ भन्ने पत्ता लगाउने सबैभन्दा भरपर्दो तरिकाहरूमध्ये एउटा PESTLE नै हो।)
3. हामी के गर्न सक्ने हुनुपर्थ्यो? Capability प्रश्न — त्यही प्रश्न जसले scan लाई strategy मा बदल्छ। Customs परिवर्तन पढ्न निःशुल्क छ। Supply chain पुनः रुट गर्न, contract book को re-pricing गर्न, वा एउटा regulatory affairs function खडा गर्न निःशुल्क छैन। यहीँबाट analysis संसारको बारेमा हुन छोड्छ र तपाईंको बारेमा हुन थाल्छ।

तीनवटै प्रश्नको जवाफ दिने factor intelligence हो। एउटाको पनि जवाफ नदिने factor एउटा slide हो। धेरैजसो grid नब्बे प्रतिशत slide हुन्छन्, र ती छ वटा column ले कुन के हो भनेर छुट्याउने कुनै उपाय दिँदैनन् — किनभने ती छ वटा column लाई त्यो गर्न कहिल्यै भनिएकै थिएन।

सातौं column ले grid लाई के गर्छ, ध्यान दिनुहोस्: यसले grid लाई खुम्च्याइदिन्छ। चालीस factor भित्र जान्छन्; तीन वा चार वटा निर्णय, owner, र capability बोकेर बाहिर निस्कन्छन्। त्यो खुम्चिने प्रक्रिया नै PESTLE मा सधैं नभएको prioritization mechanism हो। तपाईं factor हरूलाई महत्त्वका आधारमा rank गर्नुहुन्न — त्यो बहस आजसम्म कसैले जितेको छैन। तपाईं तिनलाई यो आधारमा rank गर्नुहुन्छ कि तिनमाथि कसैले केही गर्न सक्छ कि सक्दैन।

राम्रा PESTLE analysis हरूले किन केही बदल्दैनन्?

हामीले सुरुमा भनेको कथालाई discipline को असफलताका रूपमा पढ्न मन लाग्छ। तर त्यो लगभग कहिल्यै हुँदैन। तीन वटा शक्तिले scan लाई आफैं निष्क्रियता तर्फ धकेल्छन्।

Artifact जन्मँदै अनाथ हुन्छ। PESTLE लगभग सधैं यस्तो function ले commission गर्छ जससँग कुनै निर्णयको ownership हुँदैन — strategy, planning, कुनै analyst, कुनै consultant। जसले यसमाथि काम गर्न सक्थे — capital, headcount, pricing, वा legal posture बोक्नेहरू — तिनी यो बनाइएको कोठामा थिएनन्। त्यसैले यो उनीहरूसम्म अरू कसैको गृहकार्य बनेर पुग्छ, र गृहकार्यको नियति सर्वविदितै छ।

सबै कुरालाई बराबर weight दिइन्छ, त्यसैले कुनैलाई पनि दिइँदैन। छ वटा column, चालीस row, र यो एउटा महत्त्वपूर्ण छ र ती सैँतीस होइनन् भन्ने कुनै mechanism छैन। जुन grid भित्र prioritization निर्मित छैन, त्यो तटस्थ होइन — त्यो skim गर्न दिइएको निम्तो हो।

Scan सक्नुले जोखिम manage गरेजस्तो महसुस हुन्छ। यो चाहिँ चुपचापको हो। PESTLE सक्दा वातावरणसँग निपटियो भन्ने वास्तविक र स्पष्ट अनुभूति जन्मन्छ, र भित्रबाट हेर्दा त्यो अनुभूति साँच्चै निपटिसकेको अवस्थासँग लगभग अभिन्न देखिन्छ। जुन असहजताले निर्णय गर्न बाध्य पार्थ्यो, document ले त्यही असहजतालाई पन्छाइदिन्छ। यसैले "हामीले त PESTLE गरेकै थियौं" भन्ने वाक्य, कसैले प्रतिक्रिया नजनाएको एउटा अचम्मसँगै उही वाक्यमा यति पटक देखा पर्छ।

यीमध्ये कुनै पनि झन् कडा scan गरेर ठीक हुँदैन। तपाईंले ownership समस्यालाई analysis गरेर जित्न सक्नुहुन्न।

के Aramco र Netflix ले अरू सबैभन्दा राम्रो scan मात्र गरेका थिए?

होइन। र त्यही नै पूरै कुरा हो।

Saudi Aramco ले पढेको macro environment कुनै अर्थमा पनि गोप्य थिएन। April 2016 मा सुरु भएको Vision 2030 ले diversification तर्फको राष्ट्रिय दिशा सार्वजनिक रूपमै तय गरिदियो। Oil price को अस्थिरता उद्योगको हरेक screen मा थियो। Energy transition क्षेत्रकै सबैभन्दा धेरै चर्चा भएको trend थियो। साउदी नागरिकहरूमध्ये 63% ३० वर्षमुनिका छन् (GASTAT, 2022 census) — जो पनि हेर्न चाहनेका लागि उपलब्ध एउटा जनसांख्यिक तथ्य। Aramco का हरेक peer ले ती उही छ वटा column पढ्न सक्थे, र धेरैले पढे पनि।

Aramco सँग जे थियो, त्यो सातौं थियो। जब scan ले भन्यो downstream मा chemicals र petrochemicals तर्फ diversify गर, त्यो पैमानामा प्रतिबद्ध गर्न capital थियो, दिशासँग aligned एउटा shareholder थियो, र त्यसकै वरिपरि पुनर्संरचना गर्ने संरचनागत अधिकार थियो। Signal commodity थियो। त्यसमाथि काम गर्ने क्षमता थिएन।

यसैले Aramco साँच्चै उपयोगी case हो र भयानक model पनि। यदि तपाईंको निष्कर्ष "वातावरण ध्यानपूर्वक पढ" हो भने, तपाईंले गलत पाठ सिक्नुभयो — सबैले पढेकै थिए। Aramco लाई छुट्याएको कुरा तेस्रो प्रश्नको उसको जवाफ थियो, र त्यो जवाफ वर्षौं लगाएर, scan चलाउनुभन्दा धेरै अघि नै निर्माण गरिएको थियो।

Netflix फरक पैमानाको उही कथा हो। 190 भन्दा बढी देशमा भएको उसको विस्तारलाई एउटा market-intelligence उपलब्धिका रूपमा सुनाइन्छ — यहाँ local content quota, त्यहाँ purchasing-power को खाडल, अन्त कतै bandwidth को अवरोध। तर उसका competitor हरूलाई पनि quota बारे थाहा थियो। नियमहरू प्रकाशित हुन्छन्।

Netflix ले बनाएको कुरा भनेको scan ले संकेत गरेको capability थियो: एउटै catalogue निर्यात गर्नुको सट्टा Korean, Indian, Spanish, र Arabic originals commission गर्न सक्ने क्षमता, र एउटै global tier को सट्टा स्थानीय क्रयशक्तिविरुद्ध pricing गर्न सक्ने क्षमता। "यो market लाई local content चाहिन्छ" भनेर पढ्न एक दिउँसो लाग्छ। दर्जनौं भाषामा local content उत्पादन गर्न सक्ने संगठन बन्न एक दशक लाग्छ र त्यसले company नै पुनराकार गर्छ। नतिजा: US र Canada बाहिरको revenue 2023 मा $18.8 billion पुग्यो — Netflix को $33.7 billion कुल को 56% (FY2023 10-K)। Business को कुनै पूरक होइन। त्यसको बहुमत। त्यो आँकडा सातौं column चक्रवृद्धि हुँदै गएको हो, scan होइन।

सातौं column कसरी भर्ने?

आफ्नो सबैभन्दा पछिल्लो PESTLE माथि यो चलाउनुहोस् — वास्तविक document, त्यसको तपाईंको सम्झना होइन।

• कुनै निर्णय नबदल्ने हरेक factor मेट्नुहोस्। Row by row जानुहोस् र चल्ने त्यो निश्चित निर्णयको नाम लिनुहोस्। धेरैजसो grid ले यहाँ आफ्ना आधा row गुमाउँछन् र केही पनि गुमाउँदैनन्।
• बाँचेको हरेक factor छेउमा एउटा नाम राख्नुहोस्। एउटा व्यक्ति, department होइन। जहाँ सक्नुहुन्न, त्यहीँ रोकिनुहोस्: तपाईंले एउटा unowned निर्णय भेट्टाउनुभयो, जुन त्यो factor भन्दा बढी महत्त्वको छ।
• Capability प्रश्न ठूलो स्वरमा सोध्नुहोस्। "यदि यो भयो भने, हामी के गर्न सक्ने हुनुपर्थ्यो?" जवाफ factor को छेउमै लेख्नुहोस्। त्यो जवाफ र आज तपाईंले गर्न सक्ने कुराबीचको दूरी नै तपाईंको वास्तविक strategic agenda हो — र यो कुनै पनि असली people strategy मा हुने build, buy, borrow, वा bot छनोटकै प्रश्न हो।
• Review मा मिति हाल्नुहोस्। PESTLE नराम्ररी र अदृश्य रूपमा बुढो हुन्छ। दुई वर्ष पुरानो grid कुनै grid नहुनुभन्दा बढी खतरनाक हुन्छ, किनभने त्यसले analysis को अख्तियार बोक्छ र इतिहासको सामग्री।
• बाँचेकाहरूलाई काम गर्न सक्नेहरूकहाँ पठाउनुहोस्, appendix मा होइन। यदि एक मात्र artifact कुनै document हो भने, त्यो document नै नतिजा हो।
• पातलो लाग्दा झन् फराकिलो scan गर्ने प्रलोभन रोक्नुहोस्। कसैले काम नगर्ने column मा सातौं factor थप्नु यो समस्याको सबैभन्दा सामान्य प्रतिक्रिया हो, र सबैभन्दा कम उपयोगी।

आफैलाई सोध्नुहोस्

• तपाईंको पछिल्लो PESTLE का कारण बदलिएको एउटा निर्णय — एउटै, मितिसहित — को नाम लिन सक्नुहुन्छ? सक्नुहुन्न भने, त्यसले ठ्याक्कै के बदल्यो?
• तपाईंलाई सबैभन्दा चिन्ता लाग्ने बाहिरी factor का लागि: त्यसको छेउमा कसको नाम छ? इमानदार जवाफ "strategy team को" हो भने, त्यो unowned छ।
• तपाईंको grid को सबैभन्दा ठूलो खतरासँग जुध्न तपाईं के गर्न सक्ने हुनुपर्थ्यो — र त्यो आज तपाईंले गर्न सक्ने कुराबाट कति टाढा छ?
• तपाईंको PESTLE ले तपाईं अहिले भएको वातावरण वर्णन गर्दैछ, यो लेखिँदा तपाईं भएको वातावरण, कि तपाईंले चाहेको वातावरण?
• हालै कुनै बाहिरी कुराले तपाईंलाई अचम्मित पार्दा, के त्यो साँच्चै तपाईंको analysis बाट छुटेको थियो — कि त्यो त्यहीँ थियो, सही रूपमा, केही नबदली?

सार

PESTLE राम्रो taxonomy हो र यो कहिल्यै strategy थिएन। यसले बाहिरी संसारलाई छ वटा बाकसमा छुट्याउँछ, र ती हरेक बाकसले तपाईंले नियन्त्रण गर्न नसक्ने कुरा वर्णन गर्छ। आजसम्म कुनै नतिजा बदल्ने एक मात्र column framework सँग नभएको त्यही हो: यीमध्ये कुनै पनि कुरामाथि तपाईं के गर्न सक्ने हुनुपर्थ्यो।

त्यसैले environmental scan को अन्त्यमा प्रश्न के हामीले देख्यौं? होइन। धेरैजसो संगठनले, धेरैजसो समय, देखेकै हुन्छन्। प्रश्न यो हो कि त्यो देखाइ काम गर्न सक्ने कसैमाथि आइपुग्यो कि पुगेन, र उनीहरूले सक्थे कि सक्दैनथे। कोठा पढ्नु त प्रवेश शुल्क मात्र हो — तपाईंका competitor हरू उही सार्वजनिक data बाट, उही समयमा, उही कोठा पढिरहेका छन्। तपाईंलाई छुट्याउने कुरा यो हो कि कसैले "यो समस्या बन्न गइरहेको छ" भनेपछि केही हुन्छ कि हुँदैन।