PESTLE Analysis — वह Tool जो कमरे में घुसने से पहले कमरा पढ़ लेता है

एक Saudi logistics company के Head of Strategy ने छह महीने एक पड़ोसी market में cross-border expansion design करने में लगाए। financial model मज़बूत था। operational plan detailed था। team में जोश था। launch के तीन महीने बाद, customs processing में हुए एक बदलाव ने हर shipment की लागत में करीब 40% जोड़ दिया और चुपचाप पूरे business case को खोल कर रख दिया।

यह कहानी आमतौर पर जिस तरह सुनाई जाती है, वह यहीं खत्म हो जाती है — बाहर कदम रखने से पहले बाहर देख लेने के एक सुथरे से सबक के साथ। लेकिन हुआ यह नहीं था। उन्होंने इसे आते हुए देख लिया था। एक regulatory analyst ने आठ महीने पहले ही, एक PESTLE review में, एक slide पर, Legal के नीचे इस आने वाले बदलाव को flag किया था। किसी ने उससे असहमति नहीं जताई। किसी ने उस पर action भी नहीं लिया। वह finding एक document की थी, किसी व्यक्ति की नहीं — और documents decisions नहीं लेते।

यह वही pattern है जिससे हमारा सामना उस pattern से कहीं ज़्यादा होता है जिसे ठीक करने के नाम पर PESTLE बेचा जाता है। हमारे अनुभव में organizations scanning में खास बुरी नहीं होतीं। वे scan जो लेकर लौटता है, उसे own करने में बुरी होती हैं।

वह PESTLE जो हर बात पर सही था

हमने वह original review देखने के लिए कहा। वह अच्छा काम था — सचमुच। छह columns, चालीस के करीब factors, sources cited, और customs risk वहीं साफ़ भाषा में बैठा हुआ, इस note के साथ कि consultation period पहले ही बंद हो चुका है।

"मैं बार-बार इसी बात पर लौट आती हूँ कि हम गलत नहीं थे," Head of Strategy ने हमसे कहा। "अगर आप वह document किसी competitor को थमा देते, तो उसके पास वह सब कुछ होता जो हमारे पास था। हमसे यह छूटा नहीं था। बस किसी का काम इस पर कुछ करना नहीं था। यह research थी। यह appendix में चली गई।"

यह research थी। इस वाक्य के साथ थोड़ी देर बैठने लायक है। analysis सटीक थी, current थी, और पूरी तरह निष्क्रिय — और उसकी यही सटीकता वह चीज़ थी जिसने ऐसा महसूस कराया कि काम पूरा हो गया।

यहाँ इसका असहज version है: जो PESTLE कुछ नहीं बदलता, वह आमतौर पर सही होता है। सही होना और actionable होना एक बात नहीं है, और जो framework आपसे सिर्फ़ सही होने के लिए कहता है वह आपको ठीक उसी बिंदु पर रुक जाने देगा जहाँ से मुश्किल हिस्सा शुरू होता है।

PESTLE असल में आया कहाँ से?

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

यह standard बयान है, और यह जानने लायक है कि जिस आत्मविश्वास के साथ इसे दोहराया जाता है, यह उससे कहीं ज़्यादा डगमगाता हुआ है। Aguilar ने PESTLE शब्द नहीं गढ़ा। "ETPS" का जो label नियमित रूप से उनके नाम कर दिया जाता है, उसे ढूँढना अजीब तरह से मुश्किल है — हमें ऐसा कोई source नहीं मिला जो उनकी किताब के किसी page का हवाला देकर बताए कि वह वहाँ मौजूद है, और जो practitioner histories इस वंशावली को सबसे सावधानी से ट्रेस करती हैं, वे खुलकर मानती हैं कि बीच के कदम undocumented हैं।

हम यह बात pedantic होने के लिए नहीं उठा रहे, बल्कि इसलिए कि यही इस tool को समझाती है। PESTLE कभी design नहीं हुआ। यह जमा होता चला गया। किसी ने बैठकर यह तय नहीं किया कि इसे क्या produce करना चाहिए, और ठीक इसी वजह से इसकी कोई राय नहीं है कि इसे भर लेने के बाद आपको क्या करना चाहिए। यह एक taxonomy है, method नहीं। यह दुनिया को छह boxes में छाँटता है और रुक जाता है। हर वह organization जो हमें PESTLE से निराश मिली, वह method की उम्मीद कर रही थी और उसे taxonomy मिली।

Framework: सातवाँ column

एक PESTLE grid में छह columns होते हैं — Political, Economic, Social, Technological, Legal, Environmental। Teams छहों भरती हैं, present करती हैं, और file कर देती हैं। जो column कोई नहीं खींचता, वह सातवाँ है:

इस पर action लेने के लिए हमें क्या कर पाना होगा?

page पर जो भी factor टिक जाए, उसके लिए तीन सवाल:

1. यह कौन सा decision बदलता है? यह नहीं कि "यह business के किस हिस्से को छूता है" — बल्कि कौन सा specific decision, जो किसी व्यक्ति ने, किसी तारीख को लिया। जो factor कोई decision नहीं बदलता, वह citation के साथ आई हुई trivia है। उसे delete कीजिए।
2. उस decision का owner कौन है? एक नाम, function नहीं। "Operations" कोई owner नहीं है; Operations ने आज तक एक बार भी किसी कमरे में घुसकर कुछ तय नहीं किया। अगर कोई नाम फिट नहीं बैठता, तो आपको असली finding मिल गई — वह decision unowned है, और वह external factor बस वह ज़रिया था जिससे आपको यह पता चला। (इस पर हमने विस्तार से Decision Drift में लिखा है; और PESTLE यह पता लगाने के सबसे भरोसेमंद तरीकों में से एक है कि आपके पास ऐसी एक decision है।)
3. हमें क्या कर पाना होगा? यह capability का सवाल है — वही जो एक scan को strategy में बदलता है। customs का बदलाव पढ़ लेना मुफ़्त है। supply chain को दोबारा route करना, contract book की दोबारा pricing करना, या एक regulatory affairs function खड़ा करना मुफ़्त नहीं है। यहीं से analysis दुनिया के बारे में होना बंद करके आपके बारे में होना शुरू होती है।

जो factor तीनों का जवाब देता है, वह intelligence है। जो एक का भी नहीं देता, वह एक slide है। ज़्यादातर grids नब्बे प्रतिशत slides होती हैं, और वे छह columns आपको यह बताने का कोई रास्ता नहीं देते कि कौन क्या है — क्योंकि उन छह columns से यह कभी माँगा ही नहीं गया।

गौर कीजिए कि सातवाँ column इस grid के साथ क्या करता है: वह उसे ढहा देता है। चालीस factors अंदर जाते हैं; तीन या चार बाहर आते हैं, एक decision, एक owner, और एक capability के साथ। यही वह prioritization mechanism है जो PESTLE में हमेशा से गायब रहा है। आप factors को importance के हिसाब से rank नहीं करते — वह बहस आज तक कोई नहीं जीता। आप उन्हें इस आधार पर rank करते हैं कि उनके बारे में कोई कुछ कर भी सकता है या नहीं।

अच्छी PESTLE analyses कुछ क्यों नहीं बदलतीं?

जिस कहानी से हमने शुरुआत की, उसे discipline की failure मान लेने का मन करता है। यह लगभग कभी होती नहीं। तीन ताकतें अपने आप ही किसी scan को जड़ता की तरफ़ धकेल देती हैं।

यह artifact अनाथ ही पैदा होता है। PESTLE लगभग हमेशा एक ऐसे function द्वारा commission किया जाता है जिसके पास कोई decisions नहीं होतीं — strategy, planning, कोई analyst, कोई consultant। जो लोग इस पर action ले सकते थे, वे जिनके हाथ में capital, headcount, pricing, या legal posture है, वे उस कमरे में थे ही नहीं जहाँ यह बना। इसलिए यह उन तक किसी और के homework की तरह पहुँचता है, और homework का अंजाम सब जानते हैं।

हर चीज़ का वज़न बराबर है, इसलिए किसी का नहीं। छह columns, चालीस rows, और यह कहने का कोई mechanism नहीं कि यह वाला मायने रखता है और वे सैंतीस नहीं। जिस grid में prioritization built-in नहीं है, वह neutral नहीं है — वह skim करने का न्योता है।

Scan पूरा कर लेना risk manage कर लेने जैसा महसूस होता है। यह चुपचाप काम करने वाली वजह है। PESTLE खत्म करना environment से निपट लेने का एक असली और साफ़ दिखने वाला एहसास पैदा करता है, और अंदर से वह एहसास सचमुच निपट लेने से लगभग अलग नहीं किया जा सकता। वह document उस बेचैनी को उतार देता है जो वरना किसी decision पर मजबूर कर देती। यही वजह है कि "हमने PESTLE किया तो था" इतनी बार उसी वाक्य में आता है जिसमें एक ऐसा surprise होता है जिस पर किसी ने कोई प्रतिक्रिया नहीं दी।

इनमें से कोई भी ज़्यादा जोर से scan करने से ठीक नहीं होता। आप ownership की problem को analysis से हरा नहीं सकते।

क्या Aramco और Netflix ने बाकी सबसे बेहतर scan कर लिया था?

नहीं। और यही तो पूरी बात है।

Saudi Aramco ने एक ऐसा macro environment पढ़ा जो किसी भी लिहाज़ से private नहीं था। April 2016 में launch हुआ Vision 2030 सार्वजनिक रूप से national direction को diversification की तरफ़ मोड़ चुका था। Oil price volatility industry की हर screen पर थी। Energy transition उस sector का सबसे ज़्यादा चर्चित trend था। 63% Saudi nationals 30 से कम उम्र के हैं (GASTAT, 2022 census) — एक demographic तथ्य जो किसी के भी लिए उपलब्ध था जो इसे देख लेने की परवाह करता। Aramco के हर peer वही छह columns पढ़ सकते थे, और उनमें से ज़्यादातर ने पढ़े भी।

Aramco के पास जो था, वह सातवाँ column था। जब scan ने कहा chemicals और petrochemicals में downstream diversify करो, तो उस पैमाने पर लगाने के लिए capital मौजूद था, एक shareholder उस direction के साथ aligned था, और उसके इर्द-गिर्द खुद को दोबारा खड़ा करने का structural authority भी था। Signal तो commodity था। उस पर action लेने की capacity नहीं थी।

यही बात Aramco को एक सचमुच काम का case बनाती है और एक बहुत बुरा model भी। अगर आपका निष्कर्ष यह है कि "environment को ध्यान से पढ़ो," तो आपने गलत सबक सीखा — सबने पढ़ा था। Aramco को जिस चीज़ ने अलग किया, वह तीसरे सवाल का उसका जवाब था, और वह जवाब सालों में बना था, scan चलाए जाने से बहुत पहले।

Netflix एक अलग पैमाने पर वही कहानी है। 190 से ज़्यादा देशों में उसके expansion को एक market-intelligence उपलब्धि की तरह सुनाया जाता है — यहाँ local content quotas, वहाँ purchasing-power के अंतर, कहीं और bandwidth की अड़चनें। लेकिन उसके competitors को भी उन quotas का पता था। Regulations छपी हुई होती हैं।

Netflix ने जो बनाया वह वह capability थी जिसकी तरफ़ scan इशारा कर रहा था: एक ही catalogue export करने के बजाय Korean, Indian, Spanish, और Arabic originals commission कर पाने की क्षमता, और एक अकेले global tier के बजाय local purchasing power के हिसाब से pricing कर पाने की क्षमता। "इस market को local content चाहिए" पढ़ने में एक दोपहर लगती है। दर्जनों भाषाओं में local content produce कर सकने वाली organization बन जाने में एक दशक लगता है और वह पूरी company की शक्ल बदल देता है। नतीजा: US और Canada के बाहर से आया revenue 2023 में $18.8 billion तक पहुँचा — Netflix के $33.7 billion कुल का 56% (FY2023 10-K)। business का कोई supplement नहीं। उसका बहुमत। वह आँकड़ा सातवें column का compounding है, scan का नहीं।

सातवाँ column कैसे भरें?

इसे अपनी सबसे हालिया PESTLE पर चलाइए — असली document पर, उसकी आपकी याद पर नहीं।

• हर उस factor को delete कीजिए जो कोई decision नहीं बदलता। row दर row जाइए और वह specific decision नाम से बताइए जो हिलती है। ज़्यादातर grids यहाँ अपनी आधी rows खो देती हैं और कुछ नहीं खोतीं।
• हर बचे हुए के आगे एक नाम रखिए। एक व्यक्ति, कोई department नहीं। जहाँ न रख पाएँ, वहीं रुक जाइए: आपको एक unowned decision मिल गई है, जो उस factor से ज़्यादा मायने रखती है।
• Capability वाला सवाल बोलकर पूछिए। "अगर यह होता है, तो हमें क्या कर पाना होगा?" जवाब को उस factor के बगल में लिख दीजिए। उस जवाब और जो आप आज कर सकते हैं, उसके बीच की दूरी ही आपका असली strategic agenda है — और यह वही सवाल है जो किसी भी असली people strategy में build, buy, borrow, या bot वाला choice है।
• Review पर तारीख डालिए। PESTLE बुरी तरह और अदृश्य रूप से पुराना पड़ता है। दो साल पुरानी grid किसी grid के न होने से ज़्यादा खतरनाक है, क्योंकि वह analysis का अधिकार और इतिहास का content साथ लेकर चलती है।
• बचे हुए factors उन लोगों तक भेजिए जो action ले सकते हैं, appendix तक नहीं। अगर इकलौता artifact एक document है, तो वह document ही outcome है।
• जब खोखला लगे तो और चौड़ा scan करने के लालच से बचिए। जिस column पर कोई action नहीं लेता, उसमें सातवाँ factor जोड़ देना इस problem की सबसे आम प्रतिक्रिया है और सबसे कम काम की भी।

खुद से पूछिए

• क्या आप एक decision — एक, तारीख के साथ — बता सकते हैं जो आपकी पिछली PESTLE की वजह से बदली? अगर नहीं, तो उसने आखिर बदला क्या?
• जो external factor आपको सबसे ज़्यादा परेशान करता है: उसके आगे किसका नाम है? अगर ईमानदार जवाब "strategy team का" है, तो वह unowned है।
• अपनी grid के सबसे बड़े खतरे का जवाब देने के लिए आपको क्या कर पाना होगा — और वह आज आप जो कर सकते हैं, उससे कितनी दूर है?
• आपकी PESTLE जिस environment का वर्णन कर रही है, वह वह है जिसमें आप हैं, वह जिसमें आप तब थे जब यह लिखी गई थी, या वह जो आपको पसंद आता?
• हाल में जब किसी बाहरी चीज़ ने आपको चौंकाया, तो क्या वह सचमुच आपकी analysis से गायब थी — या वह उसमें थी, बिल्कुल सही, और कुछ नहीं बदल रही थी?

सार की बात

PESTLE एक अच्छी taxonomy है और यह कभी strategy थी ही नहीं। यह बाहर की दुनिया को छह boxes में छाँटता है, और उन boxes में से हर एक ऐसी चीज़ का वर्णन करता है जिस पर आपका कोई control नहीं। आज तक जिस इकलौते column ने कोई outcome बदला है, वह वही है जो इस framework के पास है ही नहीं: इसमें से किसी के भी बारे में आपको क्या कर पाना होगा।

तो किसी environmental scan के अंत में सवाल यह नहीं है कि क्या हमने इसे देखा? ज़्यादातर organizations ने, ज़्यादातर बार, देखा ही था। सवाल यह है कि वह देखना किसी ऐसे व्यक्ति पर जाकर उतरा या नहीं जो action ले सकता था, और क्या वह ले सकता था। कमरा पढ़ लेना तो table stakes है — आपके competitors वही कमरा पढ़ रहे हैं, उसी public data से, उसी वक़्त। आपको अलग यह करता है कि किसी के "यह problem बनने वाली है" कह देने के बाद कुछ होता भी है या नहीं।